MCP 集成
每个框架定义工具的方式都不同，就像各国插座标准不一。MCP 是 Anthropic 2024 年底发布的开放标准，为 AI 工具生态制定通用的“插座标准”——一次开发、处处可用。但每接入一个服务器，也等于把一段不受控的文本注入了上下文、常还把一份凭证交到别人手里。
在实际构建 agent 工具集时，一个现实挑战是：每个框架定义工具的方式都不一样（OpenAI function calling、Anthropic tool use、LangChain Tool），工具开发者要为不同框架重复适配——就像各国插座标准不同，旅行者得为每个目的地准备转换插头。Model Context Protocol（MCP）是 Anthropic 于 2024 年底发布的开放标准，统一 AI 模型与外部工具、数据源之间的通信——相当于为 AI 工具生态制定一个通用的“插座标准”。
MCP 采用客户端-服务器架构：MCP 服务器暴露一组工具，MCP 客户端（agent 框架或 IDE）通过标准化协议通信。三个关键设计：标准化的工具描述（每个工具用 JSON Schema 定义参数类型、约束、描述）、传输层灵活（本地 stdio、远程 Streamable HTTP）、资源与工具分离（除可执行的工具，还有只读的资源和可复用的提示模板——分别对应“模型可执行的操作”“应用可读取的数据”“用户可选用的模板”）。它的生态价值是一次开发，处处可用：一个 MCP 服务器能被任何兼容客户端使用。
MCP 的局限：仍是请求-响应
MCP 的工具调用主体上仍是请求-响应式——客户端发起、等待返回。协议提供了通知、进度、采样、征询等扩展原语，但它们都作用于保持连接的单个会话之内：通知能告诉客户端“资源变了”，却没有标准方式触发 agent 的思考循环，更无法唤醒一个当下没有运行的 agent。跨会话、多事件源、离线唤醒的事件驱动架构仍需在协议之上另行构建——这正是事件驱动的异步 Agent要解决的。构建方式是分层的：MCP 负责单次工具调用的标准化交互，agent 框架在其上通过事件队列管理调度、并发与外部事件源接入。
工具过多：从上下文开销到主动发现
MCP 生态快速扩张带来一个工程问题：仅 5 个 MCP 服务器就可能引入约 55,000 token 的工具定义开销，在 200K 窗口里还没开始对话就用掉近三成；而工具数量上千时，把全部 schema 一次性注入还会让模型的选择精度随之下降。缓解的总原则与 KV Cache 友好设计、Skills 渐进式披露一脉相承——默认少给，按需加载，两条路可叠加。
第一条是层次化组织：工具上百个时，扁平列表不如按信息源分类——搜索工具（网络 / 知识库 / 文件搜索）、读取工具（网页阅读、文档读取、数据库查询）、解析工具（OCR、视频分析、音频转录）、查询工具（天气、股票等结构化数据源）。在系统提示词里显式说明分类结构，能帮模型快速定位到相关工具组。Cursor 把工具描述同步到文件夹、默认只给 agent 看工具名索引、需要时再查定义，A/B 测试使 MCP 相关任务总 token 降 46.9%。
第二条是主动工具发现：让 agent 从被动接受者变成主动发现者——执行中意识到能力缺口时，用自然语言声明“我需要什么能力”，系统再动态匹配注入（Anthropic 实验显示这种按需检索使 Opus 4 在工具使用基准上准确率从 49% 提升到 74%）。工程上常见的做法是系统提示词只保留少数基础工具（web search、code interpreter）外加一个“工具搜索工具”，agent 描述需求即可检索加载（Anthropic 的 Tool Search Tool、OpenAI 的 tool_search + defer_loading、Codex CLI 默认开启的 BM25 tool_search 都属此类）。它有一个微妙代价：动态加载会破坏 KV Cache——若把工具定义放进静态前缀，每加载一个就使整段缓存失效。破解思路与 Skill 注入位置一致：把新工具的完整 schema 追加到上下文末尾、只在末尾维护一份工具名列表，让静态前缀保持稳定、缓存持续命中。schema 只在被发现的那一轮追加，此后固定在轨迹原位、成为普通历史消息。更轻的一条路是 Skills 的“按需查阅”——像查工具书一样顺着目录逐层读，连嵌入索引都不必维护。
值得注意的是，是否采用 MCP 作为互操作协议与是否在会话开始就暴露所有 MCP 工具定义是两个独立决策：后端可保留 MCP 的生态兼容，前端仍应以渐进式披露避免上下文膨胀。
信任模型与安全风险
MCP 让接入第三方工具前所未有地容易，但每接入一个服务器，就等于把一段不受自己控制的文本注入了上下文，往往还把一份凭证交到别人手里。四类主要风险：工具描述投毒（description 原样进上下文，恶意服务器可夹带指令——提示注入的一个变种，且每次会话都生效）、恶意或被劫持的服务器（供应链攻击，或远程服务器被入侵后篡改行为）、同名工具遮蔽（恶意服务器用同名工具把本应发给可信服务器的调用连同敏感参数路由到攻击者）、凭证管理风险（agent 代持 OAuth token / API key，一旦被诱导用于非预期操作损失即时）。缓解与软件供应链安全一脉相承：接入前把 description 当不可信输入来审计、锁定服务器版本拒绝静默更新、为每个服务器配最小权限凭证。运行时还可加一道防线——独立的安全审查模型（Sidecar）只看结构化的工具调用数据，不易被藏在描述里的话术操纵。评估一个 MCP 组合的整体风险，可参照 Simon Willison 的致命三要素（访问私有数据、暴露于不可信内容、对外通信能力）：三者齐备即构成一条完整攻击闭环，接入的服务器越多越容易集齐，而持久记忆会让影响跨会话持续、进一步放大风险。
工程实践
Zapvol 的 MCP 集成是一层运行时工具桥接：管理与各 MCP 服务器的连接生命周期，把远端工具接入 agent 的工具注册表，凭证经统一的凭证系统注入、并做权限过滤（按用户/租户裁剪可见工具）。它与本地工具走同一套 ServerToolConfig 契约，所以远端 MCP 工具与内建工具在提示词装配、压缩、客户端精简上表现一致。
主动发现在 Zapvol 的落地就是上面“默认少给、按需加载”：门控按工具数量而非窗口占用：单个 MCP server 的工具数超过 10（DEFAULT_MCP_PER_SERVER_DEFER_COUNT）就延迟该 server 的 schema，连接的 MCP 工具合计超过 30（DEFAULT_MCP_AGGREGATE_DEFER_COUNT）则全部延迟；被延迟的工具通过 activeTools 只在静态前缀保留工具名与服务器简述，完整 schema 待 agent 经 tool_search 按需发现后追加到上下文末尾（前缀缓存持续命中）。至于领域能力，Zapvol 走 Skills 的按需查阅（view_skill），把“工具选择”问题转化为 LLM 更擅长的“知识检索”。
相关阅读
- 工具设计——MCP 工具与内建工具共享的
ServerToolConfig契约。 - 加载 Skill——工具发现更轻的一条路：渐进式披露。
- KV Cache 设计——动态加载为何要把 schema 追加到末尾。
- 事件驱动的异步 Agent——MCP 请求-响应之外的跨会话、离线唤醒架构。