AI @Codex 2026·07·09 ·

AICoding-AgentMCPSkills插件SubagentsHooks开发工具

AI Codex 2026·07·09

编码Agent插件与扩展生态实践

一、概述

编码Agent的核心能力不只来自模型，还来自它能接入什么上下文、调用什么工具、遵守什么流程、如何被团队治理。常见扩展方式包括：

扩展类型	解决的问题	代表生态
IDE/编辑器插件	让Agent进入开发现场，感知文件、诊断、diff和终端	Cursor、VS Code Copilot、Cline、Continue、OpenCode IDE
Skills/Commands	固化重复工作流和领域能力	Codex Skills、Claude Skills、Superpowers、OpenCode commands
MCP	标准化外部工具和数据源接入	Database、GitHub、Figma、Browser、Docs、Linear、Slack
LSP	给Agent提供代码语义、诊断、定义跳转、引用关系	OpenCode LSP、IDE内置LSP、LSP-MCP桥接
Rules/Memory	给Agent长期项目约束和偏好	`AGENTS.md`、`CLAUDE.md`、Cursor Rules、Cline Rules、Windsurf Memories
Hooks/Subagents	自动化流程控制和任务分工	Claude Code hooks/subagents、Codex subagents、OpenCode agents
Tool marketplace	快速安装第三方能力	Claude MCP connectors、Cursor MCP、Cline marketplace、Smithery

插件和扩展的目标不是“让Agent什么都能做”，而是让它在受控边界内更准确地完成工程任务。

二、扩展生态全景

graph TD
    A["Coding Agent"] --> B["Context<br/>Rules / Memory / Docs"]
    A --> C["Workflow<br/>Skills / Commands / Hooks"]
    A --> D["Tools<br/>MCP / LSP / Built-in Tools"]
    A --> E["Collaboration<br/>Subagents / Review / Handoff"]
    A --> F["Runtime<br/>CLI / IDE / Web / Desktop"]
    D --> G["GitHub / GitLab"]
    D --> H["Database"]
    D --> I["Browser / Search"]
    D --> J["Design / Figma"]
    D --> K["Issue / Linear / Jira"]

一个成熟团队通常会形成如下组合：

AGENTS.md 或 CLAUDE.md：记录仓库级稳定规则。
IDE Rules：按文件类型和目录补充局部规则。
Skills/Commands：封装TDD、review、release note、文档生成等流程。
MCP：接入GitHub、数据库、API文档、Figma、浏览器等外部上下文。
LSP：提供类型诊断、定义跳转、引用关系和符号级上下文。
Hooks/Subagents：对高风险动作、测试、格式化、评审做自动化控制。

三、Skills：把流程封装成能力

Skills适合表达“如何做某类任务”。它和Rules不同：Rules是长期约束，Skills是可调用流程。

维度	Rules	Skills
触发	常驻或按文件自动触发	相关任务时按需触发
内容	项目约束、命令、禁止事项	步骤、脚本、模板、参考资料
典型用途	不要跨层依赖、必须运行测试	写计划、做review、生成文档、系统调试
风险	上下文膨胀	安装来源、脚本权限、误触发

3.1 Skill典型结构

my-skill/
  SKILL.md
  scripts/
    validate.py
  references/
    checklist.md
  assets/
    template.md

文件	用途
`SKILL.md`	skill元数据、适用场景、执行步骤
`scripts/`	可复用脚本，避免Agent手写重复逻辑
`references/`	长参考资料，按需读取
`assets/`	模板、示例、静态资源

3.2 编写技巧

技巧	说明
触发描述要窄	不要写“用于所有开发任务”，要写“用于测试失败和异常堆栈排查”
主文件短	`SKILL.md`写流程，长资料放`references/`
步骤可验证	每个流程应包含验证命令或检查清单
优先脚本化	重复格式转换、渲染、校验用脚本，不依赖Agent临场发挥
明确边界	说明是否允许联网、写文件、调用外部服务
保持可移植	尽量避免硬编码个人路径和单一仓库细节

3.3 常见Skill类型

类型	用途
Planning skill	把复杂需求拆成spec/plan/tasks
TDD skill	强制Red-Green-Refactor
Debug skill	先复现、再定位、最后验证
Review skill	按P0/P1/P2输出风险
Document skill	生成并渲染验证文档
Migration skill	数据迁移、API升级、依赖替换

3.4 使用注意

Skills越多越好是误区。建议遵循：

团队每月最多沉淀少量高频skill。
每个skill都要有维护者。
安装第三方skill前审查脚本。
发现Agent反复犯同类错误，优先补Rules；发现流程反复重复，才补Skills。

四、MCP：把外部世界标准化成工具

Model Context Protocol（MCP）是当前编码Agent扩展外部工具的重要标准。它把工具、资源、提示模板、采样、根目录等能力用统一协议暴露给模型客户端。

4.1 MCP基本对象

对象	含义	适合场景
Tools	可调用动作	查询issue、执行数据库只读查询、创建PR、调用浏览器
Resources	可读取上下文	文档、schema、配置、项目知识
Prompts	可复用提示模板	代码评审模板、发布说明模板
Roots	客户端暴露的工作区边界	限制MCP server能访问的目录
Sampling	server请求模型协助	复杂工具内部需要模型判断
Elicitation	server向用户请求信息	缺少凭证、环境或选择项时

4.2 常用MCP类型

类型	典型用途	风险
GitHub/GitLab MCP	issue、PR、review、CI状态	写权限过大、误改PR
Database MCP	查询schema、只读排障	数据泄露、生产写操作
Browser/Search MCP	查资料、验证页面	网页不可信、引用污染
Figma/Design MCP	读取设计稿、token、组件	设计资产权限
Docs MCP	官方文档、内部知识库	版本过期、来源不清
Linear/Jira MCP	需求、任务、项目状态	自动改状态造成流程混乱
Filesystem MCP	跨目录文件访问	越权访问、误删文件

4.3 MCP使用技巧

技巧	做法
默认只读	数据库、issue、文件系统优先配置只读工具
分环境配置	dev/staging/prod使用不同server和凭证
工具命名清晰	`db_query_readonly`比`query`更安全
最小权限	只给当前任务需要的repo、项目、表或目录
增加审计	对写操作记录调用者、参数、时间和结果
用Resources承载大上下文	schema、API文档放Resources，避免复制到Prompt
明确失败模式	server返回可操作错误，不让Agent猜
高风险操作二次确认	删除、部署、写生产库必须人工确认

4.4 MCP设计反模式

反模式	问题	改法
一个万能工具	Agent难以判断参数和风险	拆成小工具，命名表达权限
直接暴露生产写权限	一次误调用可能造成事故	默认只读，写操作走审批
返回超大JSON	占满上下文	分页、过滤、摘要
不区分来源可信度	Agent可能引用错误数据	返回source、timestamp、版本
把secret作为结果返回	泄露风险	server侧脱敏

五、LSP：让Agent获得代码语义智能

Language Server Protocol（LSP）最初是编辑器和语言服务器之间的协议，用于提供 autocomplete、go to definition、find references、diagnostics 等语言能力。对编码Agent来说，LSP的价值是让模型从“文本搜索代码”升级到“按语义理解代码结构”。

5.1 LSP解决什么问题

能力	对人类IDE的作用	对编码Agent的作用
Diagnostics	实时提示类型错误、语法错误、缺失import	Agent编辑后能立即看到错误并自修复
Go to definition	跳到符号定义	减少全文搜索和误读同名函数
Find references	查找引用关系	评估重构影响面
Hover / type info	查看类型、签名、文档	帮助Agent选择正确API
Rename / code action	安全重命名、自动修复	降低手工字符串替换风险
Workspace symbols	全局符号索引	快速定位入口、接口和实现
Call hierarchy	调用链分析	排查复杂流程和副作用

如果没有LSP，Agent通常只能依靠rg、文件读取和模型推断。对动态语言、小项目这可能足够；对TypeScript、Java、C#、Rust、Go这类类型和模块边界很重要的项目，LSP能显著减少“改了能编译吗”“引用有没有漏改”这类问题。

5.2 LSP与MCP的区别

维度	LSP	MCP
目标	提供代码语言智能	连接外部工具和数据源
对象	源码、符号、类型、诊断	GitHub、数据库、浏览器、文档、任务系统
协议来源	编辑器/IDE生态	Agent工具生态
典型调用	definition、references、diagnostics	query、create issue、read doc、browser action
权限风险	启动language server、读取项目代码	外部系统写入、数据泄露、越权
最佳形态	项目本地、只读语义索引为主	按任务最小权限配置

可以把LSP理解为“代码内部世界的语义雷达”，MCP理解为“代码外部世界的工具接口”。二者互补，不应混用。

5.3 编码Agent中的LSP集成方式

flowchart LR
    A["Coding Agent"] --> B["Read/Edit Tools"]
    A --> C["LSP Client"]
    C --> D["Language Server<br/>tsserver / pyright / gopls / rust-analyzer"]
    D --> E["Diagnostics"]
    D --> F["Definitions"]
    D --> G["References"]
    D --> H["Symbols"]
    E --> A
    F --> A
    G --> A
    H --> A

常见接入方式：

接入方式	说明	适合场景
Agent内置LSP客户端	Agent直接启动或复用language server	OpenCode这类强调LSP感知的工具
IDE转发LSP能力	IDE插件把诊断和符号上下文传给Agent	Cursor、Copilot Chat、Continue等IDE形态
LSP-MCP桥接	把LSP能力封装成MCP tools	CLI Agent需要通过MCP获取语义能力
外部诊断命令	用`tsc --noEmit`、`pyright`、`gopls`等命令模拟部分LSP反馈	LSP集成不成熟或CI已有命令

5.4 OpenCode、Codex、Claude Code中的LSP差异

工具	LSP支持情况	建议用法
OpenCode	文档明确支持LSP servers，可用diagnostics反馈Agent；也支持自定义LSP配置	优先启用项目语言服务器，确保诊断能在编辑后反馈给Agent
Codex	更偏向命令行、执行环境、MCP和Skills；LSP能力通常依赖IDE形态、外部命令或LSP-MCP桥接	用测试/类型检查命令兜底；需要语义能力时考虑接入LSP-MCP或IDE上下文
Claude Code	Claude Code生态中有LSP、MCP、hooks、commands组合实践；具体能力随版本和插件形态变化	用LSP/诊断工具补足代码导航，用hooks在编辑后自动跑类型检查
Cursor / Copilot IDE	IDE本身天然持有LSP上下文	让Agent优先使用IDE诊断、Problems面板和符号上下文
Cline / Continue	通过VS Code扩展可借助IDE诊断，也可接MCP	将LSP诊断和项目命令结合，避免只靠文本检索

需要注意：LSP支持状态会随工具版本快速变化。文档中应把“确定支持”“社区插件支持”“可通过MCP桥接实现”区分开，不要把社区方案写成官方内置能力。

5.5 LSP配置技巧

技巧	说明
先让IDE正常工作	如果本地IDE都没有诊断，Agent也很难正确使用LSP
使用项目本地依赖	TypeScript、Python、Rust等优先用项目锁定版本
配置初始化参数	monorepo、workspace root、tsconfig、python venv很关键
关注诊断延迟	大仓库language server启动慢，Agent可能读取到过期诊断
与测试命令互补	LSP诊断不是完整测试，仍要跑unit/integration tests
不滥用rename	自动rename前先查references，避免跨语言/字符串协议误改
限制server命令	LSP server本质是本地进程，配置文件中不要执行不可信命令

5.6 LSP安全注意事项

LSP看起来只是“读代码”，但language server是可执行进程，配置不当也有风险。

风险	说明	控制
恶意LSP命令	自定义`command`可执行任意程序	只接受可信仓库配置，审查LSP command
依赖安装副作用	某些server安装/启动会拉依赖或执行脚本	预安装、固定版本、禁用自动安装
大仓库资源占用	language server可能吃满CPU/内存	限制工作区、排除生成目录
隐私泄露	server插件可能上传代码或遥测	关闭遥测，使用可信server
过度信任诊断	LSP诊断不等于业务正确	保留测试和review gate

5.7 适合优先启用LSP的项目

项目类型	推荐程度	原因
TypeScript/JavaScript大型前端	高	import、类型、引用关系复杂
Go/Rust/C#	高	编译器和LSP诊断质量高
Java/Kotlin	高	符号、调用层级、重构依赖语义
Python中大型项目	中高	pyright/pylsp可发现类型和import问题
Shell/Markdown/简单脚本	低到中	文本工具和lint通常足够

六、Hooks、Commands与自动化控制

Hooks和Commands可以把“每次都要手动提醒Agent做的事”变成自动化流程。

扩展	代表工具	用途
Slash commands	Claude Code、OpenCode、Cursor	通过`/review`、`/test`调用固定流程
Hooks	Claude Code、部分CLI Agent	在编辑前后、命令前后触发检查
Custom commands	OpenCode `.opencode/commands/`	仓库内Markdown命令即slash command
Task recipes	Cline、Continue、Copilot	固化Prompt和上下文选择

6.1 常用Hooks场景

场景	Hook动作
写文件前	检查是否触碰禁止目录
写文件后	运行format或lint
执行shell前	阻断危险命令
测试失败后	自动收集日志和失败用例
提交前	检查secret、生成变更摘要

Hooks要谨慎。它们适合“确定性检查”，不适合复杂业务判断。复杂判断交给review或测试更稳。

七、Subagents与专用Agent

Subagents用于把复杂任务拆给专用角色。常见角色：

Agent	职责
Research Agent	只读代码、资料和issue，输出事实
Planning Agent	根据需求写计划和任务
Implementation Agent	只做指定范围的代码修改
Test Agent	复现问题、运行测试、收集日志
Review Agent	找bug、回归、安全和缺失测试
Release Agent	写release note、升级说明、迁移文档

graph LR
    A["Coordinator"] --> B["Research"]
    A --> C["Implement"]
    A --> D["Test"]
    A --> E["Review"]
    B --> F["Facts"]
    C --> G["Patch"]
    D --> H["Verification"]
    E --> I["Findings"]
    F --> A
    G --> A
    H --> A
    I --> A

使用技巧：

子任务要有明确输入、输出和禁止事项。
让review agent只审查，不修改。
同一文件修改任务尽量串行。
handoff只传事实和证据路径，不传整段长日志。
Coordinator负责最终验收，不能直接拼接多个Agent输出交付。

八、不同编码Agent的扩展差异

工具	扩展重点	优势	注意事项
Codex	`AGENTS.md`、Skills、MCP、Subagents、CLI/云端任务、IDE/外部LSP补充	与OpenAI生态和代码执行环境结合紧密	Skills和工具权限要按项目治理
Claude Code	`CLAUDE.md`、Skills、MCP、Hooks、Subagents、slash commands	工作流扩展成熟，hooks和memory能力强	成本和权限边界需控制
Cursor	Rules、MCP、Composer/Agent、IDE上下文	IDE体验强，文件级规则方便	规则过多会影响上下文质量
Cline	`.clinerules`、MCP marketplace、browser/computer use	VS Code内工具调用透明，社区MCP丰富	自动操作前要检查权限和成本
OpenCode	Provider无关、MCP、commands、agents、LSP	开源、模型供应商灵活、TUI强	插件生态仍需自行治理
GitHub Copilot	custom instructions、coding agent、review、PR集成	与GitHub issue/PR/CI流程结合好	仓库权限和CI反馈要配置清楚
Continue	IDE扩展、自定义模型、context providers	适合企业私有模型和RAG	需要维护上下文provider质量
Aider	Git-first、命令行、repo map	简洁稳定，适合小团队CLI工作流	插件生态和IDE集成较弱

8.1 OpenCode、Codex、Claude Code扩展能力详解

这三类工具都支持“规则 + 工具 + 工作流 + 专用Agent”的组合，但命名和成熟度不同。选型时不要只问“支不支持插件”，而要看扩展点在哪一层。

能力层	OpenCode	Codex	Claude Code
仓库规则	`AGENTS.md`、OpenCode配置	`AGENTS.md`、`AGENTS.override.md`	`CLAUDE.md`、memory
Skills	支持Agent Skills标准和OpenCode生态能力，更多与commands/agents配合	Codex Skills，按任务加载instructions/resources/scripts	Claude Skills，支持创建、管理、分享和内置skills
MCP	`opencode.jsonc`中配置`mcp` server，可按名称提示调用	支持通过MCP接入外部工具，适合与Skills/Subagents组合	MCP支持成熟，常通过`/mcp`配置项目server
LSP	官方文档明确支持LSP servers和diagnostics反馈	主要通过IDE、外部诊断命令或LSP-MCP桥接补充	可通过生态插件、MCP或诊断命令增强语义能力
Commands	`.opencode/commands/` Markdown注册自定义命令	主要依赖提示、skills或环境内工具	slash commands成熟，项目/个人命令均可沉淀
Hooks	以插件/命令/外部脚本组合为主	主要依赖工具权限和执行环境控制	原生Hooks能力强，可在生命周期点执行shell、HTTP或LLM prompt
Subagents	`agents/`和内置agent，如只读research/scout类agent	Codex subagents和custom agents，适合并行探索与多步骤任务	subagents成熟，常与skills、hooks、commands联动
IDE集成	TUI、Desktop、IDE，LSP感知强	CLI、云端任务、IDE/桌面能力随产品形态变化	CLI为核心，可与IDE终端和仓库流程结合
Provider	Provider无关，支持多模型供应商	OpenAI模型为核心	Claude模型为核心

8.2 OpenCode适合怎么扩展

OpenCode的强项是开源、Provider无关、TUI体验、LSP感知和配置灵活。它适合希望在同一个编码Agent中切换OpenAI、Anthropic、本地模型或其他Provider的团队。

扩展点	典型用法	技巧
`opencode.jsonc`	配置provider、model、MCP server、权限	按项目提交基础配置，个人密钥放本地环境变量
MCP servers	接GitHub、数据库、文档、搜索、Figma	先启用只读server，稳定后再开放写操作
LSP servers	接入tsserver、pyright、gopls、rust-analyzer等语言服务器	先修好本地语言环境，再让Agent依赖diagnostics
`.opencode/commands/`	用Markdown注册`/review`、`/test`、`/release-note`	命令要短，长流程链接到文档或skill
Agents	创建只读调研Agent、review Agent、文档Agent	让只读Agent承担外部资料和依赖源码调研
LSP	获取语言诊断、符号和引用	先确保项目LSP正常，再让Agent做重构
Plugins/custom config dir	复用团队配置包	用`OPENCODE_CONFIG_DIR`区分个人、团队、项目配置

OpenCode实践建议：

把项目规则写进AGENTS.md，不要只依赖会话Prompt。
把高频流程写成.opencode/commands/*.md，例如review.md和debug.md。
MCP按功能分组命名，例如github-readonly、db-dev-readonly。
外部资料调研交给只读agent，避免调研阶段误改工作区。
多Provider切换时记录“模型适合任务”，例如本地模型做搜索摘要，强模型做重构和review。

8.3 Codex适合怎么扩展

Codex的扩展重点是AGENTS.md、Skills、MCP、Subagents和执行环境。它更适合把工程流程沉淀成可重复的agent能力，并在代码执行、验证、review之间形成闭环。

扩展点	典型用法	技巧
`AGENTS.md`	写项目结构、命令、安全边界、交付要求	子目录可放局部`AGENTS.md`约束模块
Codex Skills	封装TDD、文档生成、代码审查、迁移流程	`SKILL.md`主文件短，脚本和长资料放子目录
MCP	接内部文档、Linear、GitHub、数据库、浏览器	工具描述要明确权限和副作用
LSP补充	通过IDE上下文、类型检查命令或LSP-MCP桥接获取语义反馈	把`tsc --noEmit`、`pyright`、`cargo check`等写入验证流程
Subagents	并行调研、审查、测试、实现拆分	同一文件修改串行，只读分析可并行
Cloud/CLI任务	长任务、后台任务、验证任务	给清晰目标和停止条件，要求输出验证结果

Codex实践建议：

AGENTS.md负责“项目事实”，Skills负责“做事流程”。
对复杂任务先生成plan，再执行；对小任务直接改。
MCP工具优先给只读权限，写操作保留人工确认或审计。
用Subagents处理“可并行且上下文独立”的工作，如多模块调研。
每个Skill都要有触发条件，避免所有任务都加载复杂流程。

8.4 Claude Code适合怎么扩展

Claude Code的扩展体系很完整：CLAUDE.md、Skills、MCP、Hooks、Subagents、slash commands和memory之间可以形成较细的工作流控制。它适合重流程、强自动化、需要命令生命周期控制的团队。

扩展点	典型用法	技巧
`CLAUDE.md`	项目记忆、命令、架构、偏好	用`/init`生成初始文件，再用`/memory`维护
Skills	领域任务、工作流、文档处理、review	Skill要面向任务，不要当作大号README
MCP	用`/mcp`配置项目需要的server	项目MCP写清用途和权限，不要默认全开
LSP/诊断	通过LSP、插件或类型检查命令提供符号和错误反馈	用hooks在编辑后跑轻量诊断，避免长任务后才发现类型错误
Hooks	在编辑、命令、提交等生命周期点触发检查	只做确定性动作，如阻断危险命令、跑格式化
Slash commands	`/plan`、`/review`、团队自定义命令	适合用户主动触发的固定流程
Subagents	专用review、security、research、test agent	让subagent角色单一，输出格式固定
Memory	记录长期项目事实和偏好	定期清理错误、临时、敏感记忆

Claude Code实践建议：

对大型改动先用/plan，避免直接进入编辑。
用Hooks守住安全底线，例如禁止rm -rf、检查secret。
用slash command承载“用户主动触发”的流程，用Hooks承载“自动触发”的检查。
用Skills沉淀可复用复杂流程，用CLAUDE.md沉淀仓库事实。
每个MCP server都要按项目配置权限，不要把个人全局server全部带入企业仓库。

8.5 三者的组合判断

需求	更适合OpenCode	更适合Codex	更适合Claude Code
多模型/多Provider切换	强	中	弱
开源可控和本地TUI	强	中	中
Skills标准化复用	中	强	强
Hooks生命周期自动化	中	中	强
Subagents并行调研	中	强	强
仓库级规则	强	强	强
MCP生态	强	强	强
LSP语义反馈	强	依赖形态	依赖形态
企业流程审计	取决于自建治理	强	强

实际团队不必只选一个。常见组合是：

IDE中用Cursor/Cline做快速上下文交互。
CLI中用OpenCode做Provider灵活的本地编码。
长任务或规范化任务用Codex/Claude Code跑plan、subagents和review。
通用规则统一写入AGENTS.md，Claude专有内容再补CLAUDE.md。

九、插件和扩展选型建议

需求	推荐扩展
让Agent知道项目规则	`AGENTS.md`、`CLAUDE.md`、Cursor/Cline Rules
让Agent访问外部系统	MCP
让Agent理解代码符号和类型	LSP
让Agent重复执行标准流程	Skills / Commands
让Agent自动拦截危险行为	Hooks
让Agent拆分复杂工作	Subagents
让Agent理解设计稿	Figma MCP 或设计插件
让Agent查询数据库	只读Database MCP
让Agent跟踪任务	Linear/Jira/GitHub MCP
让Agent写博客/文档	文档Skill + 渲染验证工具

十、推荐组合模板

10.1 个人开发者

AGENTS.md
.cursor/rules/
  project.mdc
MCP:
  github readonly
  docs search
LSP:
  project language server
Skills:
  review
  debugging

目标是低维护成本，不要上来就安装大量MCP。

10.2 小团队

AGENTS.md
docs/agent/
  architecture.md
  testing.md
  review-checklist.md
.github/copilot-instructions.md
.cursor/rules/
.clinerules/
MCP:
  GitHub
  Linear/Jira
  read-only DB
LSP:
  tsserver / pyright / gopls / rust-analyzer
Skills:
  TDD
  code review
  release notes

重点是统一规则来源，避免每个工具各写一套互相矛盾的规范。

10.3 企业团队

Central agent policy
Approved MCP registry
Approved LSP server list
Internal skills marketplace
Audit logging
Permission tiers
Security hooks
Spec-driven workflow
Review gate

企业场景要优先考虑权限、审计、数据边界和供应链安全。

十一、使用技巧清单

技巧	说明
先建规则，再装插件	插件扩大能力，规则限定边界
MCP先只读后写入	先验证读上下文收益，再开放写操作
LSP先诊断后重构	先让Agent读取diagnostics和references，再执行大范围改名/迁移
工具少而精	常用工具保留，不常用的按项目启用
把失败沉淀成规则	Agent反复犯错时更新Rules或Skill
对写操作留审计	MCP、Hooks、Subagents都应留下可追踪记录
分离个人偏好和团队规则	个人规则不要污染仓库
给Agent明确停止条件	测试通过、review无P1/P2、文档同步完成
高风险任务先Plan模式	先分析方案，再允许编辑
定期清理Memory	删除临时、错误、敏感记忆
为MCP工具写描述	描述越清楚，Agent越不容易误用

十二、安全与治理

插件越多，攻击面越大。重点治理如下：

风险	控制
Secret泄露	禁止MCP返回token，日志脱敏，限制读取`.env`
误删文件	文件系统工具只给必要目录，删除需确认
生产数据污染	数据库MCP默认只读，生产写操作走人工审批
第三方插件风险	只安装可信来源，审查脚本和权限
LSP命令注入	审查language server命令，禁用不可信仓库自动配置
Prompt injection	外部网页、issue、文档只作为不可信输入
权限漂移	定期审查MCP token、GitHub App权限
上下文污染	Rules和Memory定期清理，避免过期事实

十三、落地路线

flowchart TD
    A["Step 1<br/>AGENTS.md / CLAUDE.md"] --> B["Step 2<br/>IDE Rules"]
    B --> C["Step 3<br/>LSP诊断"]
    C --> D["Step 4<br/>只读MCP"]
    D --> E["Step 5<br/>Skills / Commands"]
    E --> F["Step 6<br/>Subagents / Review"]
    F --> G["Step 7<br/>写权限MCP + 审计"]

推荐顺序：

先写仓库级规则。
再补IDE规则。
启用LSP诊断和基础符号导航。
接入只读MCP。
沉淀Skills和Commands。
引入Subagents和Review gate。
最后开放写权限工具，并配审计和人工确认。

参考资料：

相关文档：

← 返回笔墨札记