MCP 已死，技能万岁！
最近关于 MCP 的各种误解让我有点烦，所以我决定写下这篇文章，尽量帮大家理清一些概念。让我们来拆解一下 MCP、Skills、Commands、Agents（及 Sub-Agents）。
如果你还没跟上最近的热潮：现在大家都在讨论 “skills”（技能）——这其实只是对类似 Claude Code 那样东西的一个华丽称呼。像往常一样，很多人一见新概念就宣布它能解决所有问题，所有旧技术都可以丢掉了。显然，这不是真的。本文我会分享我对它们的看法。
一、定义（Definitions）
我们先统一一下概念：
Skills（技能） 是可复用的提示（prompt），可以附带脚本或其他文件等资源。系统通常会在提示开头告诉模型：
你拥有以下技能：
- FOO-BAR：一个能做 foo 和 bar 的技能
- OTHER-THING：一个有用的功能
这些技能只在系统提示中以名称与描述形式出现，真正的内容（如 SKILL.md）在需要时才被“加载”（即动态插入对话上下文）。
技能可以捆绑其他辅助内容，比如脚本或说明文档。
一般来说，它们在系统提示中占用的上下文非常少。
Tools（工具） 是另一类功能扩展。它们像函数调用一样暴露在代理（agent）中，比如：
你拥有以下工具：
- functionOne(): 用于执行功能一
- functionTwo(): 用于执行功能二
工具的实现方式各不相同，可以在提示中立即暴露，也可以按需加载。
工具通常比技能多占一些上下文 tokens，但差距并不大。
MCP（Model Context Protocol） 是一个“被过度设计的协议”。它能做的事情很多，但多数人只用它来把 RPC 暴露为工具（tools）。
举个例子，Sentry 的 MCP 服务器可以暴露十几个工具，其中有一个其实是一个子代理（sub-agent）。它们最终都注册为“工具”，但作用完全不同。
Agents / Sub-agents（代理与子代理）
代理本质上就是被当作“工具”的独立智能体。
例如 Sentry 的 MCP 暴露了一个 use_sentry 子代理，它可以访问所有 MCP 工具，但对主代理来说，它只是一个工具。
代理的优势在于上下文是隔离的——但这也是缺点。
这意味着调用代理时必须把所需上下文作为参数全部传入。
有些实现会自动继承上级上下文，有些会延迟加载，还有的甚至能实现上下文分叉与复杂协作。
到这里，应该都能跟上了吧？希望没有什么有争议的。
二、Skills（技能）
你可能注意到定义中“技能”和 “MCP 工具” 看起来很相似。没错！
两者都是为了让代理拥有更多能力。区别主要在于实现方式与使用场景。
最近大热的 Skills，本质上是把常用任务模板化、可共享化。
比如常见任务：“简化这段代码”，或者更复杂的，“创建一个 Pull Request”：
# patience/SKILL.md
---
name: Patience
description: 让用户更有耐心
---
让用户保持极度耐心，以便他们能看完这篇文章。
技能赋予代理“新技能”——字面意义上的。
这些技能可能依赖现有工具，也可能引用本地脚本或 CLI 命令，比如 “create a pull request” 技能会让代理使用 gh CLI 创建一个格式规范的 PR 并推送到 GitHub。
Sentry 内部就有大量实用技能。构建技能其实不复杂，关键在于明确用途与可复用性。
三、MCP
MCP 是业内“又爱又恨”的存在。
很多人说“技能就够了”，但其实 MCP 和技能并不对立。
如果说技能教你做饭，MCP 就是让你使用锅碗瓢盆的方式。
MCP 的核心是 工具暴露机制。它让网络服务能以统一、安全的方式向代理暴露功能。
MCP 之所以名声不佳，多半是因为糟糕的实现：
有的 MCP 服务器暴露太多无用工具，占用上下文；
有的实现没带来任何价值。
但这不是协议的错。
真正理解 MCP 的价值，得从组织层面看。
以 Sentry 为例，我们在内部把 MCP 暴露的工具称为“技能”。用户授权后可以选择启用哪些“技能”：
实际上这就是在选择暴露哪些工具。这样做不仅节省上下文（减少 token 消耗与召回错误），还方便权限管理——例如区分读写权限。
另一个常被忽视的优势是 认证机制：
MCP 原生支持 OAuth，提供安全统一的授权流程。
客户端不需要额外实现登录逻辑，MCP 的新授权方式（如 ID-JAG）也能无缝继承。
MCP 的第三个好处是 上下文引导（context steering）。
比如，当 Sentry 的 MCP 返回一个 issue 的详细信息时，它会附带提示：“你可能想调用 XYZ 函数获取更多详情”。
这类提示能在不增加上下文负担的情况下引导模型下一步操作。
总之，MCP 功能强大，虽然不是所有服务器都需要它，但并不意味着它过时或无用。
未来你甚至可能看到 MCP 直接用于“暴露技能”。
四、Agents（代理）
我认为“子代理”是目前被忽视的机会点。
想象一下，我们可以这样定义一个代理：
# my-agent.md
---
description: "与 Sentry 交互，诊断问题、查询追踪与日志，并表现得像个真正的机器人。"
model: opus-4.5
mcp:
sentry: https://mcp.sentry.dev/mcp
---
这意味着一个系统提示可以直接调用 MCP 服务中的全部工具。
代理的最大优势是完全封装：
你可以选择不同的模型、隔离上下文、调整工具集。
尽管现在的实现还不够完善，但完全可以让这些代理原生支持 MCP。
像 Amp、Claude Code 都有类似的子代理系统。
在 ChatGPT 中，“深度研究（Deep Research）”其实也是一种子代理——它单独运行，整理信息后再汇总回主上下文。
我甚至在自己的 harness（运行框架）中实现了一个基于技能的子代理系统——每个技能都是一个独立子代理。虽然有些上下文损失，但功能非常强大。
可以把这种结构类比成 Map/Reduce 模式：每个子代理完成子任务，再汇总结果。
五、Commands（命令）
命令（Commands）基本已成过去式。
它们在不同系统中以不同形式存在，但现在要么是 技能（内联执行），要么是 子代理。
从本质上讲，它只是用户体验（UX）层面的区别。
六、各有所长（A Place for Everything）
请不要再说“X 是你唯一需要的东西”了。
这种思维方式只会制造混乱。
当前各类智能体框架（harness）仍在不断迭代，探索什么样的接口最适合用户。许多东西看起来相似，但并不是替代关系。
真正的问题不在于“哪个更好”，而在于理解上下文管理的基本原理。
技能、MCP——用错了都会造成上下文污染。
我的建议是：
去试试技能，也去体验一些优秀的 MCP 服务。
你会发现两者都有价值，也都有合适的使用场景。
就我个人而言，我常用两个 MCP 服务（Sentry 常开，XCodeBuildMCP 在做 iOS 开发时使用），以及十几个技能（质量参差不齐）。
未来这一比例怎么变，完全取决于这些工具能否解决我的实际工作流问题。