MCP 的文档看起来很完美：写一个 JSON 配置文件，Agent 就能自动发现和调用你暴露的工具。真正上手集成的时候，我发现有三个问题文档里没写。
在 MCP 之前，Agent 的工具接入是这样的：每个框架（LangChain、CrewAI、Dify）都有自己的工具定义方式。你在 LangChain 里写好的工具函数，切到 Dify 时要重新实现一遍。
MCP（Model Context Protocol）是 Anthropic 在 2025 年 11 月提出的开放协议。核心思想很简单：工具提供方只需要实现一个 MCP Server，任何支持 MCP 的 Agent 都能自动发现和调用。
到 2026 年上半年，OpenAI、Google、Microsoft 陆续表达了支持意向。MCP 的采用速度比我想象的快——一个协议从提出到成为行业标准候选，用了不到一年。速度本身就是一个信号：行业确实需要它。
但"需要它"和"用它不出问题"是两码事。
MCP 标准定义了工具的通信格式，但没有定义工具描述怎么写。而实际上，工具描述的措辞对 Agent 是否准确调用有巨大影响。
我有个亲身经历。我写了一个查询汇率工具，描述写的是：
"get_exchange_rate": 获取货币汇率Agent 经常在需要汇率的时候去调用别的工具，或者在不需要的时候乱调。改成：
"get_exchange_rate": 当用户询问两种货币之间的兑换比率时使用此工具。
例如：人民币兑美元、欧元兑日元。"调用准确率从大约 60% 提升到了 85% 以上。
这件事告诉我：MCP 标准化的是通信协议，不是工具质量。同样一套 MCP 接口，工具描述写得好不好，Agent 的表现可以差几个档次。协议本身不解决这个问题。
MCP 的文档里写了支持的传输方式：stdio（本地子进程）和 HTTP+SSE（远程）。看起来很简单——本地开发用 stdio，生产环境用 HTTP。
实际上，让一个 MCP Server 跑在远程服务器上并让另一个服务器上的 Agent 调用它，你需要解决：
我试过在两个不同的开发环境之间通过 HTTP 调用 MCP Server。从配证书到调通，花了一下午。不是 MCP 的问题——任何跨网络服务集成都这个复杂度。但因为 MCP 的文档看起来太简单了，我在心理上没准备好这个复杂度。
教训： MCP 的 stdio 模式（本地子进程）确实简单——启动一个进程就能用。但一旦跨越网络边界，复杂度跟其他任何分布式系统一样。
一个 MCP Server 暴露的工具列表是动态的——今天返回 3 个工具，下个月新增了 2 个，或者修改了某个工具的参数结构。Agent 这边怎么知道自己用的工具版本和 Server 的版本是否匹配？
MCP 协议目前没有定义版本协商机制。Server 返回什么工具就是什么工具，Agent 按照上一次获取的工具列表去调用。如果 Server 更新了工具参数但 Agent 还在用旧的 Schema，调用就失败。
这个问题的严重程度取决于你的部署方式：
截止 2026 年中，这个问题还在社区讨论中。我的做法是在每次 Agent 启动时重新获取工具列表，同时缓存上次成功调用的工具版本，在版本不一致时报警。
2026 年 6 月 Google 发布了 A2A（Agent-to-Agent）协议。两者的定位不同：
| 协议 | 解决的问题 | 类比 |
|---|---|---|
| MCP | Agent 怎么调用工具 | USB-C（设备连接标准） |
| A2A | Agent 之间怎么对话 | HTTP（服务间通信标准） |
两者结合构成 Agent 生态的完整通信层。MCP 让 Agent 能调用工具，A2A 让 Agent 能与其他 Agent 协作。目前 MCP 更成熟（已经有一年多的实践），A2A 还在早期。
一句话： MCP 是一个好的协议，但协议标准化的只是通信层。工具质量、部署运维、版本管理——这些需要你自己解决的问题，一个都没少。
💬 评论