Skills 与 MCP：工具调用架构的实践之争

在 AI Agent 的工具调用领域，关于 "延迟工具加载"（deferred tool loading）的讨论近期引发了不少关注。Anthropic 正在探索通过代码串联 MCP 调用，而这一方案被一些人视为未来的主流方向。但经过一个多月的实践验证，我认为：相较于复杂的动态 MCP 工具加载机制，以 Skills 为核心的能力摘要与自维护模式，在当前阶段反而更加高效、稳定且可控。

当 Agent 通过强化学习接触工具定义时，它会在合适的场景通过特殊 token 输出工具调用。但这里的限制是：工具定义只能出现在系统提示词中的特定位置，这意味着我们无法在对话中途动态注入新的工具定义。
虽然技术上可以在对话过程中压缩状态或更改系统消息中的工具定义，但代价极高——会丢失推理轨迹和缓存。以 Anthropic 为例，这会导致成本大幅上升：需要支付完整的 token 费用外加缓存写入成本，相比缓存读取，这是明显的性能倒退。
Anthropic 提出的 "延迟工具加载" 方案，虽然允许工具在系统提示词发出后才注入到对话中，但这些工具定义在整个对话过程中仍必须是静态的。也就是说，哪些工具可能存在，在对话开始时就已经确定。而且工具发现机制高度依赖正则表达式匹配，实际收益并不如预期。

相比复杂的延迟加载 MCP，Skills 系统的优势体现在几个关键方面：
本质差异：Skills 实质上只是对现有能力及其说明文件位置的简短摘要，会被主动加载到上下文中。Agent 能在系统上下文中知晓自己具备哪些能力，并获知如何使用这些能力的 "手册链接"。
内存效率：Skills 并不会真正把工具定义加载到上下文中。可用工具保持不变——bash 以及 Agent 已有的其他工具。Skills 所提供的，只是如何更高效使用这些工具的技巧和方法。
兼容性：让 Claude 系列模型成为优秀工具调用者的强化学习机制，恰好能帮助处理这些新发现的工具。这种组合方式更符合现有的技术栈。

既然 Skills 效果显著，那么能否将 MCP 完全转化为 Skills？答案是：可以，但效果并不理想。
存在诸如 mcporter 这样的方案，它能读取 .mcp.json 文件，将背后的 MCP 暴露为可调用的工具。从表面看，这非常像一个 LLM 可以调用的命令行工具。但核心问题在于：LLM 根本不知道有哪些工具可用，你必须专门教它。
这里面临一个更深层的困境：MCP 服务器根本没有维持 API 稳定性的意愿。 它们越来越倾向于将工具定义精简到极致，只为节省 token。这种做法有其道理，但对 Skills 模式来说却是致命的。
举个例子：Sentry MCP 服务器曾彻底将查询语法切换为自然语言。这对 Agent 来说是一次重大改进，但我之前关于如何使用它的建议反而成了障碍，而且我没能第一时间发现问题。
这正是当前 MCP 模式的尴尬之处：工具描述既太长，不便预加载；又太短，无法真正教会 Agent 如何使用它们。最终，你还是要为通过 mcporter 或类似方式暴露出来的 MCP 工具，手动维护这些 Skills 摘要。

基于这些实践观察，我得出了一个明确结论：选择最省事的方式——让 Agent 自己以 "Skills" 的形式编写所需的工具。
这种方案的优势显而易见：
可控性强：工具基本处于你的掌控之中。当它出问题或需要新增功能时，你可以让 Agent 去调整它。
维护成本低：虽然 Skill 可能有不少 bug，也需要不断更新，但由于是 Agent 自己维护的，整体效果反而更好。
资源消耗小：以 Sentry MCP 为例，直接在上下文中加载它会消耗约 8k 个 token，而通过 Skill 模式可以显著减少资源占用。
我之前使用 Sentry MCP（我认为它是目前设计得最好的 MCP 之一），但现在已经不再使用了。一方面是上下文占用问题，另一方面是我一直没能通过 mcporter 让它正常工作。现在我让 Claude 为我维护一个对应的 Skill，效果显著更好。

当然，这一切很可能在未来发生变化。但就目前而言，手动维护的 Skills，以及让 Agent 自行编写工具，已成为我的首选方式。
我认为，基于 MCP 的动态工具加载终将成为主流，但要实现这一点，可能还需要一系列协议层面的改进：
引入类似 Skills 的摘要机制
为工具内置使用手册
增强协议稳定性，避免工具描述随意更改
当前 MCP 服务器随意更改工具描述的做法，与那些已经固化下来的调用方式以及在 README 和技能文件中编写的外部工具说明很难兼容。这些问题如果不解决，MCP 在实际应用中的稳定性就会持续受限。
在技术选择上，务实往往比激进更重要。 Skills 虽然看似简单，但它解决了实际问题，这是最有力的证明。