Agent 架构中的 MCP 与 Skill 技术解析

在构建基于大模型（LLM）的智能体（Agent）时，如何有效地扩展模型的能力和知识是核心课题。目前主流的解决方案可以归纳为两种技术路径：MCP（Model Context Protocol） 与 Skill（技能）。本文将从技术原理、交互机制、以及“动态能力检索”的未来演进方向进行深度剖析。

一、 技术定义：基础设施与方法论

1. MCP：标准化的“能力管道”

MCP 是由 Anthropic 等公司推动的开放标准，其本质是 Agent 的基础设施层。

• 技术组成： MCP 协议不仅包含 Tools（工具调用），还包含 Resources（静态数据读取）和 Prompts（预设提示词模板）。
• 角色定位： 它是 Agent 的“万能接口”。如果把 Agent 比作一台电脑，MCP 就是它的 USB 总线，定义了如何连接外设。

2. Skill：注入的“思维水流”

Skill 是针对特定领域优化的指令集和方法论，属于 Agent 的逻辑应用层。

• 技术本质： 它通过注入专家经验（如架构设计准则、代码规范）来对齐模型的思考路径。
• 二者关系： 在底层实现上，MCP 可以作为 Skill 的分发协议——即通过 MCP 的 Prompts 接口，将 Skill 这种“思维水流”灌输给模型。MCP 是管路，Skill 是水。

二、 交互机制：多轮回路与性能权衡

正如在实际工程中观察到的，动态加载能力并不是“免费”的。无论是加载 Skill 还是 MCP，通常都遵循一套**“发现-加载-执行”**的多轮交互闭环：

1. 意图识别： LLM 接收需求，发现当前环境缺乏必要的工具或专业规范。
2. 资源检索（第一轮）： LLM 调用探测指令（如 get_skill）查询资源。
3. 动态注入（反馈）： 框架将检索到的 Skill 文本或工具定义回传。
4. 最终决策（第二轮）： LLM 在新状态下输出最终操作。

核心洞察： 这种动态加载机制虽然灵活，但不可避免地带来了 Turn Overhead（轮次开销）。承认并优化这种多轮交互导致的响应延迟，是提升 Agent 用户体验的关键。

三、 进阶构想：从“全量加载”到 get_mcp

在工具数量较少时，我们将所有 MCP 工具的 Schema 一次性塞给 LLM 是可行的。但当工具箱扩展到成百上千个时，这种做法会导致“注意力弥散”和巨大的 Token 浪费。

1. get_mcp：动态工具检索

受 get_skill 的启发，Agent 架构应引入 “动态工具检索（Dynamic Tool Retrieval）” 机制，即 get_mcp：

• 按需获取： 初始状态下，模型只携带极少数核心工具。只有当模型意识到需要操作特定系统（如 AWS 或数据库）时，才会触发 get_mcp。
• 减少干扰： 框架根据模型的请求，动态地从工具库中调取相关的接口定义（JSON Schema）注入上下文。

2. 意义

这种方式将 MCP 从一种“静态配置”转变为一种“动态资源”。它解决了 LLM 面对大规模工具集时的幻觉问题，确保模型始终在最精简、最相关的工具集下工作。

四、 总结与前瞻：迈向 AI 操作系统

未来的 Agent 将不再是简单的“模型 + 插件”，而是一个具备动态调度能力的系统：

• 预路由（Pre-routing）： 在请求到达主模型前，由轻量级模型预先判定并加载必要的 MCP 工具和 Skill，以消除多轮交互的延迟。
• 冷热分离： 核心能力（热数据）常驻，专业能力（冷数据）通过 get_mcp 或 get_skill 按需调入。
• 协议融合： MCP 将成为承载 Skill 的标准协议，实现能力（Tools）与逻辑（Prompts）的统一分发。

结语：
MCP 解决了 Agent 的“连接性”问题，Skill 解决了“专业性”问题。而通过 get_mcp 这种动态检索机制，我们能够让 Agent 在保持无限能力扩张的同时，依然维持高效、精准的思维状态。

---

注：本文基于 opencode 与用户的技术交流记录整理。