Agent 架构中的 MCP 与 Skill 技术解析
一直在用 Skill 给 opencode 配各种工作流，MCP 也接了不少。两者都往 Agent 里塞”能力”，但到底有什么区别，写代码时边界经常糊。这篇是我自己整理的笔记。
一句话区分
MCP 是协议，Skill 是一堆指令文本。
MCP 定义了 Agent 怎么调外部能力，里面分三类：Tools（工具调用）、Resources（静态数据）、Prompts（预设提示词模板）。它是传输层，类似给 Agent 开了个 USB 口，设备（工具）插上就能用。
Skill 更像针对某个领域写好的操作手册，比如”怎么处理 PDF””写代码要遵守什么规范”。它改的是模型想问题的路径，不是给它加新设备。
底层实现上，Skill 经常是借 MCP 的 Prompts 接口分发出去的。所以可以粗粗理解成：MCP 是管路，Skill 是管路里流的水。
动态加载不是免费的
不管 Skill 还是 MCP，工具多了之后都是”发现-加载-执行”几步走：
- 模型先看需求，发现自己缺工具或缺规范。
- 调用探测指令（如
get_skill）去查有什么可用。 - 框架把查到的 Skill 文本或工具定义塞回上下文。
- 模型带着新上下文再输出最终操作。
我实际用下来，最明显的感觉就是响应变慢。查一次、注入一次、再决策一次，每轮都烧 token 和延迟。工具少的时候无所谓，全量塞给模型就行；但接了几十个 skill 之后，光 schema 就占掉一大截上下文，模型开始”记不住重点”。
get_mcp：按需加载工具
顺着 get_skill 的思路，我在想工具是不是也能按需取：初始只带少数核心工具，模型意识到要操作某个系统（比如 AWS、数据库）时，再去动态拉对应的接口定义（JSON Schema）进上下文。
好处是模型始终只面对一小撮相关工具，上下文干净，幻觉和”注意力被稀释”的问题会少很多。代价是要多一次检索交互——不过反正加载 Skill 也已经这么干了，多一个 get_mcp 不算新鲜事。
如果以后做成系统
把这些串起来想，Agent 往后大概是这样：
- 预路由：请求到主模型之前，先让个轻量模型预判要加载哪些工具和 Skill，把”发现-加载-执行”多轮交互的延迟消掉一部分。
- 冷热分离：核心能力常驻（热），专业能力按需调（冷）。
- 协议统一：MCP 承载 Skill 的分发，能力和逻辑走同一个口。
这些都是我目前的想法，还没落地验证。MCP 解决的是”Agent 能连上什么”，Skill 解决的是”Agent 知道怎么干”——先把这两个搞清楚，后面的按需加载才有意义。