一句话摘要：MCP 给它手，Skills 给它规矩，Subagent 给它一间独立的房间。这篇用三层拆解 + 一组真问题 + 一个最小配置，帮你在 10 分钟内想明白手上的需求到底缺哪一样------以及大多数时候，为什么你三者都要，而不是三选一。
为什么会纠结
几乎每个把 AI 编程 agent 用进真实项目的人，都会在某天打开文档，看到三个名词：MCP、Skills、Subagent。再往下翻，三份文档都在说同样一句大白话------"扩展 AI 的能力"。都能连东西，都能带来新行为，都能改 agent 的用法。
于是你开始比较"哪个更强""哪个更新""用哪个以后不用后悔"。
这个比较本身走错了方向。它们不是三个候选方案，因为它们在纵向上叠着三层。 一个真实需求往往同时缺其中两层，真正的动作是"每层补一块"，而不是"三层里挑一层最强的"。
先记住三个动词，后面所有判断都从这三个动词长出来：
MCP 给它手，Skills 给它规矩，Subagent 给它一间独立的房间。
三层到底各管什么
MCP：给它手（连接层）
Model Context Protocol（MCP） 是 2024 年底由 Anthropic 开源、现已社区化治理的一套开放协议，用来把 AI 应用连到"它原本够不着"的外部系统------数据库、内部 API、第三方 SaaS、本地文件系统。
它解决的是够不着 的问题。没有 MCP，agent 推理能力再强，也拿不到你内网那张订单表；它只会编一张假的给你看。官方自己的比喻是"AI 应用的 USB-C 口"------定义一次接口，各家客户端都能插。最新规范迭代到 2025-11-25 版，加入了 OIDC 授权发现、JSON Schema 2020-12、实验性的 tasks 等能力，这里不展开。
记住一条就够了：如果你缺的是"访问"，你缺的是 MCP。
Skills：给它规矩（知识与流程层）
Agent Skills 是 2025 年 10 月 Anthropic 提出的做法，2025 年 12 月 18 日已经发布成开放标准 ，见 agentskills.io，不再只是某一家工具的私有格式。
一个 skill 的最小形态是一个目录里放一个带 YAML frontmatter 的 SKILL.md，写清楚"这件事该怎么做、按什么标准验收、有哪些坑"。它可以附带脚本和参考文件。
它解决的是不知道怎么做的问题------能力它本来就有，缺的是流程和规矩。比如"写发布说明时按团队格式来、金额要脱敏、章节顺序不能乱"这些规矩，只存在你同事脑子和某个 Confluence 页面里，模型的训练数据里根本没有。把它固化成一个 skill，它每次自动带上。
Skills 值钱的地方是渐进式披露 ：启动时所有 skill 只把 name 和 description 载入上下文，够模型判断"这个技能现在用不用得上"；命中了才读完整 SKILL.md；真要动手了才去翻附带的脚本。所以你可以挂几十个 skill，却几乎不占主上下文。
Subagent：给它一间独立的房间（执行与上下文层）
Subagent（子代理） 是一个在独立上下文窗口 里跑的执行体，有自己独立的 system prompt、可收窄的工具集、独立的权限。配置同样是带 frontmatter 的 Markdown，放在 .claude/agents/（项目级）或 ~/.claude/agents/（用户级）。
它解决的是**"这件事不该在主对话里做"的问题。注意它和 MCP、Skills 的关键差别：前两者解决的是"能力"问题，Subagent 解决的是"污染"问题**------把大段大段你不会再看的中间材料（翻几十个文件、跑一轮完整测试、读一堆日志）挡在主对话之外，让它在自己房间里处理完，只把一张干净的结论表带回给你。
一条能立刻用上的判断路径
与其记抽象定义，不如把你现在最想让 agent 做、但一直做不好的那件事拿出来，按顺序问自己三个问题：
问题一：它够不着什么吗？ 比如公司内部订单系统、要鉴权的内部 HTTP 服务、只有文件系统能触达的资源。写得出一个具体对象 → 缺 MCP。写不出来，说明不缺。
问题二：它做出来的东西符合你的标准吗？ 格式对不对、步骤全不全、知不知道该脱敏、知不知道你们团队的边界约定。常"差口气" → 缺 Skills。把标准写进 SKILL.md，让它每次自己带上。
问题三：这件事会产出大量你其实不想看的中间材料吗？ 要翻几十上百个文件、跑一遍完整测试看输出、读一堆日志 → 缺 Subagent。让它在自己窗口里翻，只回传结论。
三个问题都答"否"，说明你不缺任何机制------你缺的是把需求说清楚。这种情况比想象中常见，别为了用而上。
为什么顺序是固定的？ 把问题二提到前面会踩坑：如果它根本够不着数据，那它只能编，编出来的当然"不符合标准"------这时候你写再细的 skill 都没用。同理，把问题三提前，你会倾向于给每件事都开子代理，但该用 MCP 的场合开子代理，等于换了个房间继续够不着。
两张表帮你对号入座
三个候选的真实差别
| MCP | Skills | Subagent | |
|---|---|---|---|
| 所在层 | 连接层 | 知识与流程层 | 执行与上下文层 |
| 回答的问题 | 它碰得到什么？ | 它知道该怎么做吗？ | 这件事在哪个窗口里做？ |
| 典型形态 | 一个 server + 一组工具/资源 | 一个 SKILL.md 目录 |
一个 .claude/agents/*.md |
| 带来的是 | 新的访问能力 | 新的判断标准与步骤 | 新的上下文边界 |
| 常驻上下文成本 | 高：工具定义每轮都占 | 低：只占 name + description | 低：只占 description |
最后两行最该记。常驻成本的差别不是细节，它经常直接决定选型。 MCP 没有渐进式披露的待遇------接一个 server，暴露的工具定义就常驻在每一轮上下文里；接三个，四十多个工具定义还没开口就烧掉一块预算。
一个反直觉推论：如果你想固化的是"怎么做"而不是"能做"，用 Skills 通常比用 MCP 便宜一个数量级------哪怕这两条路表面上都能做到。
四个常见场景
| 场景 | 缺口 | 选什么 |
|---|---|---|
| 让 agent 查内部订单系统的实时数据 | 够不着 | MCP |
| 让 agent 按团队格式写发布说明 | 不知道规矩 | Skills |
| 扫全仓找某个废弃接口还剩多少调用点 | 中间材料太多 | Subagent |
| 把设计稿转成符合团队规范的组件 | 够不着 + 不知道规矩 | MCP + Skills |
注意最后一行：真实需求经常横跨两层，这时候不是二选一，是分工。
最典型、也最容易被做错的一个例子
扫全仓找调用点，是 Subagent 最典型的用武之地，也最容易做错。
做错的方式：开了子代理，但没规定回传格式。它老老实实翻完 40 个文件，然后把读到的内容大段大段倒回主对话------你什么都没省下，还多付了一遍 token。
规定回传格式是写子代理最关键的一步。 一个能用的最小配置长这样：
markdown
---
name: v1-usage-scanner
description: 扫描仓库中对废弃 v1 结算接口的调用点，只回传结构化清单。
tools: Read, Grep, Glob
disallowedTools: Write, Edit
---
你负责定位仓库中对 v1 结算接口的调用。
只回传下面这张表，不要附带文件原文，不要附带你的搜索过程：
| 文件路径 | 行号 | 调用的方法 | 迁移难度 | 一句话说明 |
超过 30 处时，只列出难度为"中"和"高"的，并在末尾给出总数。注意两点：tools 收窄到只读三件套，disallowedTools 明确挡掉写操作------一个负责调查的子代理不该有能力改代码。这些字段名会随版本变化，动手前用当前官方文档核对。
一个不该用任何机制的场景（容易被忽略）
有人想给 agent 加个"改完代码自动跑格式化"的能力，开始纠结做成 MCP 还是 Skill。
两个都不对。这件事不需要模型判断 ------改完就该跑，没有例外。凡是不需要判断的确定性动作，都应该交给 Hooks（Claude Code 里在工具调用前后自动运行的确定性脚本），而不是交给模型去"记得做"。模型是概率性的，你今天让它记得，明天它上下文一脏就忘了；Hook 是确定性的，它永远会跑。
判断路径里没有 Hooks，是因为它压根不在"扩展模型能力"这条线上------它是把确定性动作从概率机制里解放出来。
三个机制怎么在一件事里同时站着
回到开头那句完整需求：让 agent 从内部订单系统拉上周退款记录、按团队格式写周报、别把几千行原始数据倒进主对话。完整组合是：
- MCP 接内部订单系统，暴露一个
list_refunds工具。 - Subagent 拿着这个工具去拉所有退款记录、做初步归类，只回传一张不超过 30 行的汇总表。几千行明细留在它自己的窗口里。
- Skills 在主对话里被触发，按团队周报格式把那 30 行写成成稿，顺带处理脱敏规则。
三者各干各的，没有一处重叠。这才是它们的正常关系------不是互斥选项，是三层分工。
四个最容易栽的坑
坑一：把本该是 Skills 的流程包成 MCP 服务器。 你写了个 MCP server 暴露一个 generate_release_notes 工具，内部其实就是拼一段提示词。代价是工具定义从此常驻每一轮上下文，而它一周才用一次。同样的效果用 Skills 实现，平时只占 name + description。
坑二：把本该是 MCP 的访问写进 Skills。 反过来一样糟：在 SKILL.md 里写一段带 API token 的 curl。凭证进了一个会被加载进上下文的文本文件，鉴权、重试、错误处理全靠模型现场发挥。需要凭证和连接管理的事，交给 MCP。
坑三：什么都开子代理。 隔离不是免费的。子代理靠并行能解决单窗口装不下的问题，但 token 用量可能成倍上升------Anthropic 公开的多代理研究给出的量级，是单 agent 会话的近一个数量级（multi-agent research system）。加上摘要必然丢信息、子代理看不到你和主 agent 的讨论，短任务开子代理往往是净亏。
坑四：子代理的 description 越写越长。 description 是常驻主上下文的，模型靠它判断该不该委派。Claude Code 的经验阈值是所有自定义子代理的 description 合计别超过约 15000 token，超过了启动会直接警告。挂十几个子代理、每个 description 写成一段说明书，你会在干活之前就烧掉一块预算。把细节移到子代理自己的 system prompt 里------那部分只在它运行时才加载。
给自己的五分钟自检
打开你当前项目，数三个数：常驻工具几个、skill 几个、子代理几个。然后对着下面这张表逐行过一遍：
| 检查项 | 不合格的信号 |
|---|---|
| 常驻工具数量 | 超过 20 个，且你说不出其中三个的确切用途 |
| MCP 服务器 | 有服务器一个月没被调用过 |
| Skill 触发率 | 写了技能但模型从不主动加载（说明 description 没写清触发场景） |
| 子代理回传 | 返回超过 2000 token，或夹带大段文件原文 |
| 子代理 description | 全部 description 加起来超过 15000 token |
| 机制错配 | 有确定性动作（格式化、检查）却靠模型"记得做" |
如果你连"常驻工具几个"都数不出来，那已经不是选型问题，是可见性问题------你根本不知道上下文里装了什么。真正决定 agent 好不好用的，往往不是这三种机制选得对不对，而是它们加起来在你上下文里占了多少、留下多少空间干正事。
如果你读到这里还在困惑，多半不是这篇讲得不够清楚，而是你还缺一块更基础的拼图：上下文窗口到底是什么、为什么会被塞满、塞满了会怎样。这几个问题想明白，"该用哪个"很多时候会自己浮出水面。
我在自己的网站上把这些话题写成了成体系的中文短文，包括上面提到的基础概念和这里没法展开的实现细节，想接着往下读的话可以逛逛：
👉 felixsh.com/posts/ ------ 我的文章列表，每篇都能独立读完，也经常互相引用。
参考与进一步阅读
- Model Context Protocol 官方文档 ｜ 规范更新见 2025-11-25 changelog
- Equipping agents for the real world with Agent Skills --- Anthropic Engineering
- Agent Skills 开放标准 --- agentskills.io
- Subagents --- Claude Code 官方文档
- Effective context engineering for AI agents --- Anthropic Engineering
- Multi-agent research system 的 token 成本 --- Anthropic Engineering
三种机制的字段名、默认值与上限都会随版本变化，动手前请以你当前所用版本的官方文档为准。