别急着给 Claude Code 接一堆 MCP
很多人熟练使用 Claude Code 之后，会自然进入下一步：
既然 Claude Code 能读项目、能跑命令、能记规则，那是不是应该把 GitHub、Sentry、数据库、Figma全接上，再装几十个 subagents，让它自己分工？
这一步很诱人，也很容易把 Claude Code 用乱。
因为 MCP、Subagents、Agent Teams 不是“高级功能清单”。它们解决的是三个不同问题：
MCP：外部信息和工具从哪里来？ Subagent：谁去消化一块独立任务？ Agent Team：多个独立会话要不要互相协作？核心问题很直接：Claude Code 连接外部世界和分工协作时，MCP、Agents、Subagents 到底该怎么分工。
先说结论：MCP 管连接，Subagent 管消化
先给一个最短判断表：
| 问题 | 更像该用什么 | 典型例子 |
|---|---|---|
| 信息不在代码库里，我不想手动复制 | MCP | 从 GitHub issue、Sentry、数据库、Figma 取上下文 |
| 任务会读很多文件，容易污染主会话 | Subagent | 让 reviewer、researcher、test-runner 独立探索后返回摘要 |
| 多个独立工作流需要互相通信和协调 | Agent Team | 安全、性能、测试三个 reviewer 同时审 PR 并交换发现 |
| 只是项目长期规则 | CLAUDE.md | 用 pnpm，不要改生成文件，测试命令是什么 |
| 只是可复用流程 | Skill / Command | 安全修 Bug、发布检查、生成模块说明 |
| 需要强制限制行为 | Settings / Permissions / Hooks | 禁止读密钥、限制危险命令、提交前跑校验 |
这张表把项目规则、外部连接、独立消化和强制控制放在同一个判断面上。
一个很实用的记法是：
CLAUDE.md：让 Claude 知道项目长期事实 Skills：让 Claude 调用可复用流程 MCP：让 Claude 拿到外部上下文和工具 Subagents：让 Claude 把独立任务拆出去 Agent Teams：让多个 Claude 会话协作不要把所有东西都塞进一个巨大的 prompt。也不要把所有外部系统都接给主会话。
为什么需要 MCP：真实开发信息不只在代码里
排查 Bug 或实现需求时，只贴一行报错往往不够。更可靠的做法，是写清现象、复现、期望、边界和验证。
但真实工作里，这些信息经常散在代码库外面：
- GitHub issue 里有用户反馈和讨论。
- Sentry 里有堆栈、版本、浏览器、用户路径。
- 数据库里有真实数据分布。
- Figma 里有设计约束。
- Slack 或飞书里有产品决策。
如果每次都靠人复制粘贴，Claude 得到的上下文很容易过期、残缺、失真。
MCP 的价值就在这里。它把外部系统变成 Claude Code 可以连接的工具和数据源。官方文档里给的例子很直接：从 issue tracker 实现功能、分析 Sentry/Statsig 数据、查询 PostgreSQL、根据 Figma 设计更新模板，甚至通过外部事件把消息推入 Claude Code 会话。
换句话说，MCP 解决的是：
Claude 要做这件事，正确上下文到底从哪里来？它不是“更长的记忆”，也不是“更强的 prompt”。
CLAUDE.md适合放稳定项目规则，比如“测试命令是什么”“不要改生成文件”。MCP 适合拿实时或外部上下文，比如“这个 issue 最新讨论是什么”“生产错误最近 24 小时怎么分布”“设计稿现在长什么样”。
这两者不要混。
MCP 不是安全边界
这里要压住一个冲动：能接，不代表应该立刻接。
官方 MCP 文档明确提醒，第三方 MCP server 需要自己判断信任，尤其是会读取不可信内容的 server，可能带来 prompt injection 风险。
这件事很好理解。
过去 Claude 只能看你贴进去的内容。接入 MCP 后，它可能能读取 issue、日志、数据库、文件、设计稿，甚至能调用外部工具。能力边界变大，风险边界也变大。
所以对开发者来说，MCP 的正确起手式不是：
把所有常用服务都接上。而是：
先选一个明确场景，接一个可信 server，尽量只读，限制 scope，验证输出。比如你只是想让 Claude 阅读 GitHub issue，就不要一上来给它数据库写权限。你只是想分析最近错误，就先让它读 Sentry，不要让它自动发布修复。
可以把 MCP 配置当成“外部系统入口”，而不是普通依赖。
$ 示例：项目级 MCP server。发布前请核对官方最新文档和团队安全要求。 claude mcpadd--transporthttp<name>--scopeproject<server-url>Tool Search 降低上下文成本，但不解决信任问题
现在的 Claude Code 官方文档提到，MCP Tool Search 默认启用。简单说，MCP 工具名会在会话开始加载，完整工具 schema 可以按需进入上下文。
这能缓解一个现实问题：MCP server 多了以后，工具定义本身会占上下文。
第一条实践原则是：
MCP 先少接，先只读，先验证。为什么需要 Subagent：不是所有信息都该塞进主会话
有了 MCP 之后，新的问题来了：
如果外部信息、项目文件、日志、设计稿都能进来，主会话会不会变得越来越重？
会。
这时 Subagent 的价值就出现了。
官方对 Subagent 的定义很清楚：它有自己的上下文窗口，可以独立读文件、探索代码、做任务，完成后只把相关结果返回给主会话。
这意味着它不是一个“更大的 Skill”，也不是一个“角色扮演 prompt”。它真正有价值的地方是隔离。
适合交给 Subagent 的任务通常有四类：
| 场景 | 为什么适合 |
|---|---|
| 研究量大 | 需要读很多文件，但主会话只需要结论 |
| 任务彼此独立 | 可以并行探索，不互相等待 |
| 需要新鲜视角 | 独立 review 不受主会话假设影响 |
| 验证性任务 | 改完代码后，让 reviewer 或 test-runner 单独检查 |
比如你正在修一个登录问题。主会话负责最终决策和修改，但可以让一个 subagent 专门读认证模块，让另一个 subagent 检查测试覆盖，再让一个 reviewer 看 diff 是否有安全风险。
主会话不需要吞下所有探索过程，只需要接收结构化结论：
发现了什么？ 证据在哪个文件？ 风险等级是什么？ 建议下一步是什么？ 有哪些不确定点？这才是 Subagent 的重点。
Subagent 不适合什么任务
Subagent 不是越多越好。
如果一个任务只有两步，而且强依赖当前对话上下文，让 subagent 去做反而增加沟通成本。
如果多个 subagents 会同时改同一个文件，也容易制造冲突。
如果你只是想复用一套固定流程，那可能应该做 Skill，而不是 Subagent。
如果你希望某个规则强制执行，那也不是 Subagent 的职责，应该单独交给 settings、permissions 或 hooks 设计。
所以更稳的做法是：
先建 2-3 个真正高频的专门角色。比如：
issue-reader：只读外部 issue 和需求，返回事实和开放问题。code-reviewer：只做 diff review，返回风险和证据。test-runner：只负责测试命令、失败摘要和复现结果。
够用了。
一个最小 Subagent：外部 issue 摘要员
假设你经常从 GitHub issue、Jira ticket 或产品文档开始任务，可以先做一个只读 subagent。
放在项目里：
.claude/ agents/ issue-reader.md示例：
--- name: issue-reader description: Use when a task starts from an external issue, ticket, design note, or monitoring link. Read context only and return facts, constraints, open questions, and acceptance criteria. Do not modify files. tools: Read, Grep, Glob model: sonnet --- You are an issue reader for this project. Your job is to turn external task context into an engineering brief. Return: 1. Problem statement. 2. User-visible symptom or requested behavior. 3. Evidence from the issue, ticket, note, or linked files. 4. Acceptance criteria. 5. Constraints and risks. 6. Questions that still need a human answer. Do not edit files. Do not propose broad refactors. Do not invent missing requirements.如果你后面真的要让它读取 GitHub、Sentry 或内部系统，再结合团队批准过的 MCP server 来做。不要一开始就把读写权限全打开。
再加一个独立 Reviewer
接受 AI 修改前一定要看 diff。
有了 Subagent，可以把独立 review 做得更干净一点：
.claude/ agents/ code-reviewer.md示例：
--- name: code-reviewer description: Use proactively after code changes. Review the diff for bugs, regressions, security risks, missing tests, and scope creep. Return findings with file paths and evidence. tools: Read, Grep, Glob, Bash model: sonnet --- You are a strict code reviewer. Focus on: 1. Behavior changes. 2. Edge cases. 3. Security and data exposure. 4. Missing or weakened tests. 5. Scope creep beyond the task. Prefer findings with concrete evidence. If there are no findings, say so and list residual risks. Do not rewrite the implementation unless explicitly asked.这个 reviewer 和人工 diff 检查不冲突。人工负责最终接受，Subagent 负责提供隔离上下文里的独立视角。
Agent Teams：先知道它是什么，不要默认使用
Subagent 只向主会话汇报。它们之间不互相聊天。
如果你需要多个 Claude Code 会话互相通信、共享任务列表、协调工作，那就是 Agent Teams 的位置。
官方文档把 Agent Teams 标成实验性能力，默认关闭，并说明需要 Claude Code v2.1.32 或更高版本。它和 Subagents 的区别可以这样理解：
| 能力 | Subagents | Agent Teams |
|---|---|---|
| 上下文 | 每个 subagent 有自己的上下文 | 每个 teammate 是独立 Claude Code 会话 |
| 通信 | 只向主会话返回结果 | teammates 可以直接互相通信 |
| 协调 | 主会话管理 | 有共享任务列表和团队协调 |
| 成本 | 相对低一些 | 更高，随 teammate 数量增长 |
| 适合 | 独立研究、review、验证 | 多假设调试、跨层新功能、复杂并行 review |
什么时候真的需要 Agent Teams？
比如一个 PR 很大，你希望安全、性能、测试三个 reviewer 同时看，而且它们需要互相挑战结论。或者一个跨层功能要同时看前端、后端、测试，每个 teammate 有明确文件边界和产物。
什么时候不需要？
修一个小 Bug 不需要。改一个函数不需要。写一段 README 不需要。顺序很强、多个角色都要改同一个文件，也不适合。
Agent Teams 适合先放在边界判断里。真正日常起步，还是先把 MCP 和 1-2 个 Subagents 用稳。
MCP 和 Subagent 怎么配合
一个常见错误流程是：
主会话接上所有 MCP 主会话读取所有外部信息 主会话直接修改代码 主会话自己 review 自己这会让主会话越来越重，也让判断链路变模糊。
更稳的流程是：
外部系统 -> MCP 只读获取上下文 issue-reader -> 摘要事实、约束、验收标准 主会话 -> 制定计划并做最小修改 code-reviewer -> 独立审查 diff 主会话 -> 跑测试、看结果、总结取舍常见误区
第一个误区：MCP server 越多越强。
不是。MCP server 越多，外部入口越多，权限和审查成本也越高。即使 Tool Search 能降低上下文成本，它也不能替你判断 server 是否可信。
第二个误区：Subagent 越多越专业。
也不是。角色太多，description 重叠，Claude 反而更难判断该委派给谁。先从少量高频角色开始，比安装一整套陌生 agent collection 更稳。
第三个误区：把 Subagent 当安全系统。
Subagent 可以限制工具访问，可以隔离上下文，但它不是完整安全边界。涉及敏感文件、生产系统、删除、发布、写数据库，还是要靠 permissions、settings、hooks 和人工确认。
第四个误区：把 Agent Teams 当默认并行。
Agent Teams 的强项是多独立会话互相通信和协作。它有额外成本，也有任务协调复杂度。小任务用它，往往是把简单问题变复杂。
第五个误区：让所有角色都能改代码。
很多角色应该只读。issue-reader不需要写文件，code-reviewer默认也不需要改实现。权限越克制，结果越容易 review。
接入前检查清单
准备给 Claude Code 接 MCP 或加 Subagent 前，先问这 8 个问题：
- 这个信息真的不在代码库里吗？
- 我是否能先用只读方式接入？
- 这个 MCP server 是否可信，谁维护，访问哪些数据？
- 它应该是个人 user scope，还是团队 project scope？
- 这个任务是否会读很多文件，污染主会话？
- 是否存在一个单一职责的 subagent 可以消化它？
- subagent 的输出格式和验收标准是否明确？
- 这件事真的需要 Agent Team 互相通信，还是普通 subagent 就够了？
如果只能记住一句话：
MCP 管连接，Subagent 管消化，Agent Team 管协作。先少接，先只读，先验证。
最后
Claude Code 的扩展能力不要按功能数量堆，而要按边界拆：稳定项目规则放进CLAUDE.md、Skills 或 Commands；外部上下文用 MCP；独立研究、Review、测试交给 Subagent；只有多个独立会话必须互相通信和协调时，才考虑 Agent Teams。
默认策略很简单：先少接，先只读，先验证。
