别急着给 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--transporthttpname--scopeprojectserver-urlTool 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 的区别可以这样理解能力SubagentsAgent 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。默认策略很简单先少接先只读先验证。