工具层演进

开篇：协议的黄昏与机制的黎明

最近在技术圈听到不少人在讨论一个问题：MCP（Model Context Protocol）为啥不火了？答案或许藏在一个更宏观的趋势里 —— 工具接入方式正在经历第三次演进。

从早期的 REST API，到后来的 MCP，再到如今泛指的 skill 系统这一类智能扩展机制，每一次演进都在降低门槛、提升效率。MCP 的困境在于：它在协议化的道路上走得太远，而 skill 这种更直接、更智能的机制，才是 agent 时代的真实需求。

{  "type": "image-prompt",  "category": "timeline",  "title": "工具接入方式演进",  "stages": [    {      "label": "REST API 时代",      "time": "2022",      "visual": "传统的 API 接口图标",      "caption": "基础但繁琐，需要大量适配代码"    },    {      "label": "MCP 协议",      "time": "2024",      "visual": "标准化的协议图标",      "caption": "追求跨平台互操作性，但复杂度较高"    },    {      "label": "skill 机制",      "time": "2026",      "visual": "智能扩展图标",      "caption": "更直接、更智能、开发门槛更低"    }  ],  "direction": "horizontal",  "metaphor": "交通工具演进（马车→汽车→高铁）",  "style": {    "illustration_type": "flat illustration",    "background": "clean white"  },  "aspect_ratio": "21:9"}

REST API 时代：基础但繁琐

REST API 是 Web 服务的事实标准，但在 AI 时代，它的局限性逐渐暴露。让一个 LLM 调用 REST API 并不容易，开发者需要处理大量细节。

LLM 需要理解 API 文档。不是所有的 API 都有清晰的文档，即使有，LLM 也需要准确解析其中的参数定义、返回格式。如果文档更新了，系统还需要及时同步。

参数构造也是个难题。REST API 的参数类型多样，有的是简单的字符串，有的是复杂的嵌套对象。LLM 需要根据用户意图，正确构造这些参数。错误构造一个参数，整个调用就可能失败。

错误处理同样复杂。API 调用可能因为各种原因失败：网络问题、认证错误、参数错误、服务端错误。LLM 需要识别错误类型，判断是否需要重试，或者向用户反馈有用的错误信息。

{  "type": "image-prompt",  "category": "hierarchy",  "title": "REST API 调用的复杂流程",  "layers": [    {      "level": 1,      "name": "用户请求",      "visual": "用户说话的图标",      "description": "用户提出需求"    },    {      "level": 2,      "name": "文档理解",      "visual": "阅读文档的图标",      "description": "LLM 解析 API 文档"    },    {      "level": 3,      "name": "参数构造",      "visual": "组装零件的图标",      "description": "构造请求参数"    },    {      "level": 4,      "name": "调用与错误处理",      "visual": "齿轮和感叹号",      "description": "执行调用、处理各种错误"    },    {      "level": 5,      "name": "结果返回",      "visual": "返回结果的图标",      "description": "处理返回数据，反馈给用户"    }  ],  "metaphor": "工厂工厂流水线（原料→加工→质检→包装→成品）",  "direction": "bottom_up",  "style": {    "illustration_type": "flat illustration",    "background": "clean white"  },  "aspect_ratio": "16:9"}

举个例子，假设用户想查询北京的天气。开发者需要：

1. 1. 找到一个天气 API（比如 OpenWeatherMap）
2. 2. 阅读 API 文档，了解请求格式和认证方式
3. 3. 在代码中配置 API Key
4. 4. 编写代码将用户的自然语言查询转换为 API 参数
5. 5. 调用 API 并处理可能的错误
6. 6. 解析返回的 JSON 数据，格式化后展示给用户

这一套流程下来，简单的一个天气查询也需要不少代码。对于复杂的业务场景，开发成本会显著增加。

MCP 的理想与现实

MCP（Model Context Protocol）的出现，本意是解决这些问题。它的愿景很宏大：做一个像 USB-C 一样的标准化协议。无论是什么 AI 客户端，只要支持 MCP，就能连接任何 MCP 服务器。

MCP 的核心思想是：通过统一的工具描述和标准化的通信流程，让 AI 客户端能够发现、调用外部工具。这样，工具开发者只需要开发一个 MCP 服务器，就能被所有支持 MCP 的客户端使用。

{  "type": "image-prompt",  "category": "cover",  "title": "MCP 的愿景",  "subtitle": "Write once, run everywhere",  "visual_elements": {    "main_subject": "一个 MCP 服务器连接多个 AI 客户端",    "supporting_elements": ["Claudede", "ChatGPT", "Cursor"],    "mood": "科技感"  },  "style": {    "illustration_type": "flat illustration",    "color_scheme": ["tech blue", "green"],    "background": "clean white"  },  "aspect_ratio": "16:9",  "text_overlay": {    "enabled":true,    "language": "chinese"  }}

理论上，这确实很吸引人。但现实是，MCP 的使用体验并不如预期。为什么？

首先，开发一个 MCP 服务器并不简单。你需要搭建一个独立的服务器进程，实现 MCP 协议，定义工具列表，处理各种请求。虽然 MCP 官方提供了多语言的 SDK，但对于很多场景来说，这个复杂度还是太高了。

其次，客户端需要集成 MCP SDK。这也不是一件轻松的事。如果你的 AI 应用不支持 MCP，或者支持得不好，那么无论 MCP 生态多么丰富，对你来说都没有意义。

更重要的是，协议层增加了很多不必要的复杂度。MCP 通信走的是 JSON-RPC 2.0 协议，需要建立连接、发送请求、接收响应、处理错误。在单机环境或简单的集成场景下，这些抽象层反而成了负担。

{  "type": "image-prompt",  "category": "hierarchy",  "title": "MCP 的多层架构",  "layers": [    {      "level": 1,      "name": "AI 客户端",      "visual": "AI 助手的图标",      "description": "Claude、ChatGPT 等"    },    {      "level": 2,      "name": "MCP Client SDK",      "visual": "SDK 层图标",      "description": "集成 MCP 协议支持"    },    {      "level": 3,      "name": "JSON-RPC 通信",      "visual": "数据传输图标",      "description": "JSON-RPC 2.0 协议层"    },    {      "level": 4,      "name": "MCP Server",      "visual": "服务器图标",      "description": "独立的 MCP 服务器进程"    },    {      "level": 5,      "name": "实际工具/数据源",      "visual": "数据库图标",      "description": "真正执行任务的逻辑"    }  ],  "metaphor": "建筑层次（屋顶→楼层→地基）",  "direction": "top_down",  "style": {    "illustration_type": "isometric",    "background": "clean white"  },  "aspect_ratio": "16:9"}

还有一个现实问题：在实际使用场景中，”跨平台”价值有限。大多数开发者都只使用一两个主要的 AI 客户端，很少有人会在 Claude、ChatGPT、Cursor 之间频繁切换。为了一个理论上的”跨平台”好处，承担协议层带来的复杂度，这笔账算不过来。

skill 的崛起：更直接的新范式

skill 这类智能扩展机制的兴起，本质上是对 MCP 协议化倾向的反拨。skill 的核心思想很简单：既然大多数场景都只需要在特定 agent 中使用，那就直接集成到 agent 运行时中，去掉那些不必要的协议层。

skill 的本质是智能扩展机制。与 MCP 不同，skill 不是独立的服务器进程，而是直接嵌入在 agent 系统中的扩展模块。当你开发一个 skill 时，你是在为特定的 agent 编写扩展代码，而不是在开发一个通用的协议服务器。

这种设计带来了几个核心优势。

{  "type": "image-prompt",  "category": "concept",  "title": "skill 的核心优势",  "central_element": {    "visual": "skill 图标",    "label": "skill 机制"  },  "surrounding_elements": [    {"visual": "轻量级图标", "label": "开发门槛更低"},    {"visual": "直接连接图标", "label": "集成更直接"},    {"visual": "智能图标", "label": "更智能的上下文理解"}  ],  "relationships": "辐射",  "metaphor": "DJ 混音台（核心控制台连接多个功能模块）",  "style": {    "illustration_type": "flat illustration",    "background": "clean white"  },  "aspect_ratio": "4:3"}

第一个优势是开发门槛更低。不需要搭建独立的服务器进程，不需要实现 MCP 协议，不需要处理 JSON-RPC 通信。你只需要定义一个 skill 的元数据（名称、描述、能力声明），然后实现相应的逻辑。在很多 agent 框架中，这甚至可能只是一个配置文件加上一个简单的函数。

第二个优势是集成更直接。skill 与 agent 运行时天然融合，可以直接访问 agent 的上下文、用户状态、历史对话等信息。不需要额外的通信机制，不需要序列化和反序列化，直接函数调用即可。这大大简化了集成难度。

第三个优势是更智能。skill 不仅可以声明自己的能力，还可以通过元数据告诉 agent 自己适合处理什么类型的任务。agent 可以根据当前上下文和用户意图，智能选择最合适的 skill。这种能力在 MCP 协议中是很难实现的，因为 MCP 服务器与客户端的交互被协议层隔断了。

让我们用一个具体的例子来对比：实现一个”查询 GitHub 仓库信息”的功能。

用 MCP 的方式：

1. 1. 搭建一个 MCP 服务器进程
2. 2. 实现 MCP 协议的各个接口
3. 3. 定义工具列表（比如 get_repo_info）
4. 4. 在工具实现中调用 GitHub API
5. 5. 处理错误和返回结果
6. 6. 在客户端配置连接这个 MCP 服务器

用 skill 的方式：

1. 1. 定义 skill 元数据（名称、描述、能力）
2. 2. 实现一个简单的函数，调用 GitHub API 并返回结果
3. 3. 在 agent 配置中注册这个 skill

后者不仅代码量更少，而且开发体验更直接。开发者不需要关心协议细节，只需要关注业务逻辑。

{  "type": "image-prompt",  "category": "comparison",  "title": "同一个功能：MCP vs skill",  "left": {    "label": "MCP 实现",    "visual": "复杂的服务器架构，多个图层叠加",    "caption": "服务器进程 + 协议层 + 业务逻辑"  },  "right": {    "label": "skill 实现",    "visual": "简单的函数模块，一层结构",    "caption": "元数据 + 简单函数"  },  "comparison_style": "side_by_side",  "style": {    "illustration_type": "flat illustration",    "background": "clean white"  },  "aspect_ratio": "16:9"}

为什么 skill 更符合 agent 时代的需求？因为 agent 系统本身就是一个高度集成化的环境。在这个环境中，工具扩展应该是运行时的一部分，而不是外挂的独立进程。skill 这种直接嵌入的设计，恰恰抓住了这个本质。

三种方案的深度对比

从开发复杂度看，REST API 最复杂，需要处理 API 文档、参数构造、错误处理等大量细节。MCP 次之，虽然解决了工具描述和通信的问题，但协议层仍然增加了复杂度。skill 最简单，只需要定义元数据和实现核心逻辑。

从集成难度看，REST API 需要为每个场景编写适配代码。MCP 需要客户端集成 MCP SDK 并处理协议通信。skill 只需要在配置中注册，由 agent 运行时自动管理。

从灵活性看，skill 最灵活，因为它与 agent 运行时紧密集成，可以直接访问上下文信息，实现更智能的调度逻辑。REST API 次之，虽然调用方式固定，但至少在不同场景下自由度较高。MCP 相对最不灵活，因为协议定义了严格的交互方式。

从适用场景看：

• • REST API 适合传统的 Web 服务集成，特别是那些已经有成熟 API 的服务
• • MCP 适合需要跨多个 AI 客户端共享工具的场景，但这样的场景其实不多
• • skill 适合在特定 agent 系统中深度集成的场景，这正是大多数 agent 应用的需求

{  "type": "image-prompt",  "category": "comparison",  "title": "三种方案的多维度对比",  "left": {    "label": "REST API",    "visual": "传统 API 图标",    "caption": "基础但繁琐，适合传统 Web 服务"  },  "right": {    "label": "MCP",    "visual": "协议图标",    "caption": "追求标准化，但复杂度较高"  },  "center": {    "label": "skill",    "visual": " "智能扩展图标",    "caption": "简单直接，最符合 agent 时代需求"  },  "comparison_style": "three_way_comparison",  "style": {    "illustration_type": "flat illustration",    "background": "clean white"  },  "aspect_ratio": "16:9"}

总结与展望

MCP 的困境在于协议化的道路上走得太远。在大多数实际的 agent 应用场景中，”跨平台”价值有限，而协议层带来的复杂度却是实实在在的。

skill 的兴起说明了一个事实：简单、直接、智能才是王道。过度抽象和复杂化并不总是好事。

{  "type": "image-prompt",  "category": "metaphor",  "abstract_concept": "技术方案的演进方向",  "metaphor_theme": "乐高积木",  "scene": {    "setting": "工作台",    "main_character": "开发者",    "props": ["乐高积木桶", "复杂的机械装置", "简单的积木搭建"],    "action": "搭建模型"  },  "labels": [    {"element": "散落的零件", "meaning": "REST API 时代的碎片化"},    {"element": "复杂的机械装置", "meaning": "MCP 的过度抽象"},    {"element": "简单的积木搭建", "meaning": "skill 的直接高效"}  ],  "style": {    "illustration_type": "flat illustration",    "tone": "friendly",    "background": "clean white"  },  "aspect_ratio": "16:9"}

未来，工具层会继续向更智能、更自动化的方向发展。skill 机制可能会进一步演进：更智能的能力匹配和调度、自动化的参数推断和补全、内置的错误恢复和重试机制、更丰富的元数据表达和约束验证。

MCP 仍然有翻身机会吗？在特定的企业场景中，比如需要统一管理多个 AI 应用、严格的安全审计、标准化的工具治理，MCP 仍然有其价值。但对于大多数开发者来说，skill 或类似的机制会是更务实的选择。

技术演进往往遵循类似的路径：最初追求标准化和通用性，后来发现简单直接才是真正的生产力。从 REST API 到 MCP 再到 skill，这个趋势还会继续。下一个是什么？答案或许就藏在你我正在写的代码里。