AI Agent 工具对比：MCP 为什么只是个过渡产物
如果你做过 AI Agent 开发，大概率已经用过 MCP，也可能接触过 Agent Skill 的概念。我们不需要再解释它们是什么——这篇文章要回答的问题是：当两者都能实现"让 AI 调用工具"这件事时，为什么我认为 MCP 是一个会被淘汰的过渡态方案。
MCP 的根本局限：协议层无法承载语义
MCP 的设计逻辑是：给 AI 一个结构化的工具调用协议，工具发现、调用、解析全部走固定格式。
问题在于，这个协议设计是给人看的，不是给 AI 看的。
JSON Schema 能定义参数类型、返回值结构，但它无法传达这些信息：为什么这个参数通常传这个值、这个工具在什么前置条件下才能正常工作、它的失败模式大概是什么样子的。这些上下文才是 AI 在真实场景里做决策时最需要的东西，但 MCP 协议层根本承载不了。
结果是：用 MCP 构建的工具调用能力，体验高度依赖 prompt engineering——你需要在 prompt 里额外补充协议定义里没有的东西。这说明协议层设计有缺口，而这个缺口不是靠完善 schema 能解决的，因为它本质上是一个语义损失的问题，不是格式问题。
另一个现实问题是维护成本。每个新能力都需要一个独立的 MCP server，你需要维护 server 代码、schema 定义、网络连接。协议版本更新的时候，所有 server 可能都要跟着改。这套复杂度对于个人开发者或小团队来说，负担不轻。
Skill 为什么更接近 AI 真正需要的东西
Agent Skill 用 Markdown 作为能力封装的核心格式——用人类语言描述这个能力是什么、在什么场景下用、怎么用，附带脚本和参考模板。
AI 读取一个 Skill 文档，获得的不只是"这个工具叫什么名字、接受什么参数"，而是完整的决策上下文：什么时候该用它、什么时候不该用它、边界情况怎么处理。这些信息本来就需要给人类开发者看，现在直接给 AI 用，不需要二次转化。
对工程师而言，文件系统作为 Skill 管理的基础带来了一个额外的好处：这套工作流和工程师的日常完全对齐。Git 管理 Skill 目录，天然支持版本控制、分支、PR review。AI 需要什么能力就读什么文档，不需要理解任何协议层，也不需要维护一个运行中的 server 进程。
对普通用户而言，Skill 的优势更加直接。现在的 Agent 越来越完善，“harness engineering"已经出现——用户不需要理解技术细节，只需要描述自己需要什么能力。安装一个 Skill，可能就是一句话的事：AI 自动读取 Skill 文档，理解这个能力做什么、怎么配置，然后自动完成依赖安装、API 配置、权限验证这些原本需要技术人员才能搞定的事情。对用户来说，Skill 就是一个能力的说明书，而 Agent 是那个读完说明书就能执行的执行者。MCP 做不到这一点，因为它要求用户先理解 server、schema、协议版本这些概念——这些是工程师的语言，不是普通用户的语言。
Skill 的语义化封装让这种"零门槛安装"成为可能。当能力是用人类语言描述的文档时，Agent 才能真正替用户做那些技术决策。协议层越厚，这个代理成本就越高，而 Skill 恰恰是把这一层压缩到了最小。
| MCP | Agent Skill | |
|---|---|---|
| 新增一个工具 | 写 server + schema + 配置 | 写一个 Markdown 文件 |
| 语义表达能力 | 受 JSON Schema 限制 | Markdown 自由格式 |
| 上下文信息 | 需要 prompt engineering 补充 | 写在文档里，AI 直接读取 |
| 协议版本维护 | 需要 | 不需要 |
| 普通用户安装 | 需要理解 server 和协议概念 | Agent 读文档自动完成配置 |
| 调用方配置 | 需要配置 server 连接 | 直接读文件 |
MCP 的云端优势是一个伪命题
MCP 常被提及的一个优势是云端部署——server 独立运行，多个 Agent 可以共享。
这个优势是真实的，但它属于"网络调用"这个能力范畴，不属于 MCP 协议本身。Agent Skill 完全可以建立在 REST API 调用之上，Skill 文档里的脚本本来就能调任何 HTTP endpoint。云端部署这件事，Skill 并不缺失。
对于已有 REST API 的 SaaS 服务，这个对比更清晰：
- 用 MCP：写一个 server 把 REST API 包一层，维护 schema，跟 MCP 协议版本保持同步
- 用 Skill：写一个 Markdown 描述清楚这个 API 做什么、怎么调用，AI 读完直接用
MCP 要求你额外维护一套协议系统和 server 进程，而 Skill 用更少的成本覆盖了所有这些需求。 当一个更简单的方案能做到所有同样的事的时候，复杂的方案就该退场了。
Skill 的形态本身也在演进
但我必须承认，Markdown + 文件系统可能也不是终点。
这个方案有一个还没解决好的问题：Skill 的动态性。当一个 Skill 依赖的外部 API 变了，或者需要实时状态的时候，文件系统里的静态文档怎么跟上变化？目前的解法是靠脚本和模板，但脚本的执行环境、安全边界、状态管理这些问题都还没有标准答案。
另外，Skill 之间的依赖关系、优先级排序、以及多个 Skill 同时适用一个请求时的决策逻辑，这些也都是开放问题。
我的判断是：Skill 会演进，可能不再以文件系统的静态文件为核心，而是出现某种更动态的能力注册与发现机制。但这个机制大概率会是 Skill 设计思路的延续，而不是回到 MCP 的协议设计方向。
写在最后
MCP 不是坏设计。它在 AI 工具调用这个课题上迈出了重要的第一步，让"AI 连接外部世界"这件事从不可能变成了可能。
但可能和正确之间还有距离。当我们发现一种更符合 AI 认知方式的能力封装方案时，过渡态就应该退出舞台。
Agent Skill 是不是最终答案？我不确定。但它比 MCP 更接近 AI 真正需要的东西——语义、上下文、灵活性，以及一个不需要额外协议层的调用体验。这种封装方式对工程师友好，对普通用户更友好，因为它把技术复杂性藏进了文档层，让 Agent 替用户处理那些本不该需要人类操心的事。
这个方向的探索，值得认真对待。
最后贴上 2025 年我对 MCP 这个概念的剖 (tu) 析 (cao)。
