claude code skills subagents mcp 怎么选

改行为写 Skill、隔离上下文用 Subagent、连外部系统走 MCP。附三维决策口令与四类常见错选，并链到 Skills 与 MCP 差异文。

claude code skills subagents mcp 怎么选

Claude Code 里 skills、subagents、MCP 三条扩展线，问 claude code skills subagents mcp 怎么选，可以先记三条口令：改行为写 skill，隔离噪音用 subagent，连外部系统走 MCP。下面按这个框架展开代价与反例。

作者：CodePass 技术编辑

三维决策口令

你的目标 选谁 一句话理由
固化流程、改 agent 做事方式 Skill 按需加载，不占连接层
并行查资料、把大段中间结果挡在子窗口外 Subagent 独立上下文，结果只回主会话
读活数据、带认证写外部系统 MCP 协议连接，模型主动拉取或执行

这张表是本文的信息增益：遇到「该写配置还是该接服务」时，先对号入座再动手，比逐个读官方文档省一轮试错。Skills 与 MCP 在上下文开销上的分工，Skills 和 MCP 有什么区别 已展开；本文补上 subagent 这一维，并专门讲错选。

改行为：写 Skill

Skill 解决的是「同样的话你又粘贴第三遍」这类问题。官方判据很直白：你在反复粘贴同一份多步指令，或 CLAUDE.md 里某段已经从事实长成了流程，就该搬进 SKILL.md。

适合写 skill 的场景包括：发版前检查清单、代码 review 的固定维度、某类 PR 描述模板、团队统一的 commit message 规范。这些都不需要实时外部状态，只需要在触发时把步骤和判据注入上下文。frontmatter 里写好 description，模型会在清单预算内看到一行摘要；正文只在 skill 被调用时才全量加载。

不适合 skill 的边界同样清楚：你要查 Issue 当前是否已关闭、监控此刻的 P99、数据库里某张表行数，这些答案不在仓库里，skill 给不了活数据。还有一类常见误用是把整本团队手册塞进一个 800 行的 skill，触发后正文常驻会话直到压缩，token 账单会明显高于拆成多个按需 skill。流程类优先 skill，数据类留给 MCP。

手动才该触发的流程，加 disable-model-invocation: true，描述就不进常驻清单。共享仓库里别人写的 skill 想降级曝光，用 skillOverrides 的 name-only 或 off 比改 frontmatter 干净。

隔离噪音：用 Subagent

Subagent 跑在同一会话里，但有独立上下文窗口，干完活只把结论回报给主 agent，中间搜索日志和大段原文不会污染你的主对话。适合「帮我查一下这个库的 breaking change 再总结三条」：主会话继续写代码，子代理去翻 release note。

和 Agent Teams 的分工要分开看。Subagent 不能互聊，只能向主会话汇报；Claude Code Agent Teams 怎么开与场景 里写得很清楚，Teams 是多个独立实例、可互发消息、有共享任务列表，适合需要多视角对质、交叉审查的复杂活。只想快查、快验、要一份摘要回来，subagent 更省 token。

嵌套深度与 fleet 上限另有一套旋钮。Claude Code 嵌套子代理深度怎么配 记录了默认深度从 1 调回 3、workflowSizeGuideline: "medium" 建议少于 15 个 agent 等约束。子代理能再 spawn 子代理，但每多一层都是完整上下文实例，并行三个「查资料」子代理通常够用；再深往往是主 agent 拆任务失败，不是 subagent 不够用。

Subagent 也解决不了连接问题。它可以在子窗口里跑 Bash 调 gh，但那仍是命令输出，不是带 OAuth 的 MCP 工具面。需要结构化、可重复的写操作时，仍要 MCP 或 CLI，而不是指望子代理「代连」。

连外部系统：走 MCP

MCP 管的是模型怎么合规地摸到外部系统：JSON-RPC 连接、能力协商、工具定义与用户确认。Issue 状态、Sentry 堆栈、Notion 页面、自建 webhook，只要数据在会话外且会变，就属于 MCP 或等价 CLI 的范畴。

能用 CLI 顶掉的，官方成本文档建议优先 Bash。gh、aws、sentry-cli 不产生 per-tool 清单开销。一个只包了一层 REST 的 MCP server，收益常常不如一条维护好的 curl 或 CLI 子命令。只有需要 OAuth、复杂 schema、或团队统一封装工具面时，MCP 才值得常驻。

和 skill 混用时，常见健康形态是：skill 编排「先查 Sentry 再对照 release 再改测试」，MCP 负责真正取 issue 详情。据 dev.to 上一篇对比文（第三方博客，二手来源）的说法，skill 可以教 agent 怎么用你的 MCP 工具，两者不构成替代关系。

安全层必须算进选型：MCP 规范写明，来源不可信时工具行为描述应视为不可信内容，Host 须取得用户明确同意才调用。给团队铺 server 之前，这条比功能列表重要。

四类最常见错选

  1. 把静态流程硬接 MCP。发版检查、lint 顺序、review 维度，写进 skill 或 CLAUDE.md 的流程段即可。单独起一个 MCP server 只返回「跑 eslint 再跑 test」的文本，多了一层进程和工具 schema，上下文还占清单位。

  2. 用 skill 假装能读活数据。skill 正文是静态文件，不会自己 ping API。训练数据里的「上次 Issue 状态」会过期；要当前状态，必须 MCP、CLI 或人粘贴。

  3. 凡事都 spawn subagent。单步 grep、读一个已知路径的文件，主 agent 直接做更快。subagent 有 spawn 成本和汇总延迟；官方 Agent Teams 文档也提醒，快速验证用 subagent，需要讨论才上 team。

  4. 该用 subagent 隔离却堆进 CLAUDE.md。长篇调研指令、多源对比、会吐出几千 token 中间产物的任务，放进 CLAUDE.md 或常驻 skill 会让每轮对话都背着重量。派 subagent 收结论，主会话只留决策所需的三行摘要。

常见问题

已经有 MCP server，还要写 skill 吗？

要，如果除了「调用工具」之外还有固定顺序和判据。MCP 提供能力，skill 提供编排。只有工具、没有流程时，可以只靠 MCP；一旦步骤超过三步且会重复，skill 更利于 review 和版本管理。

Subagent 和 Agent Teams 怎么二选一？

需要队友互聊、认领共享任务、多视角辩论时选 Teams；需要主会话干净、只要一份汇总结论时选 subagent。token 成本上 Teams 更高，因为每个队友是完整实例。

清单挤爆了先砍谁？

据 Start Debugging 一篇二手解读（2026-07），以及 dev.to 同类对比文，优先顺序通常是：关掉未使用的 MCP server，给手动 skill 加 disable-model-invocation，再用 skillOverrides 降级低频 skill；subagent 没有「常驻清单」问题，不必为了省 token 而砍掉合理的并行查资料。

参考资料