你可能已经注意到了，最近一周关于 Agent 的新闻密度高得不太正常。

8 月 6 日，OpenAI 联合 AWS、Cursor、GitHub、VS Code、Vercel 五家，发布了 Agent Plugins 开放标准。当天帖子浏览量就破了 110 万。两天前，阿里云刚上线 One Key MCP 服务，把十四家生态伙伴的 MCP 服务统一到一个 API Key 后面。再往前推一周，Anthropic 发布了 MCP v5 规范，彻底转向无状态——官方定性为"该协议诞生以来规模最大、最具系统性的一次修订"。

这三件事发生在八天之内，不是巧合。

过去一年，开发者都在做同一件苦差事

我先说说自己踩过的坑。

去年底我开始做 Agent 项目，需求很简单：让 Agent 能搜网页、查数据库、发邮件。三个工具，听起来不多对吧？但每个工具都要按不同模型的格式写适配器。

接 OpenAI 的 function calling，得写 JSON Schema。切到 Claude，得重写成 tool use 格式。想试试开源的 Qwen Agent，好，再调成 huggingface chat template。身份认证、鉴权 token、计费逻辑，每个平台各搞一套。工具从三个变成八个的时候，我花在"适配"上的时间已经超过了写业务逻辑的时间。

MCP 就是奔着这个痛点来的。Anthropic 在 2024 年 11 月推出它时，想法很朴素：给 AI 模型和外部工具之间定一套统一的接口协议，就像 USB-C 之于硬件设备。你写一个 MCP Server，所有支持 MCP 的客户端都能用。

但第一代 MCP 有个毛病——有状态。每次对话要先握手建联，服务器端得维护 Session，客户端得处理连接池。单个 Agent 跑着还行，一旦涉及多 Agent 协作、工具链编排，状态维护的复杂度就让人头大。我有个同事试过用 MCP 跑五个 Agent 协作的任务，最后连接池爆了，查了半天才发现是会话没及时释放。

MCP v5：砍掉 Session，Agent 进入 Serverless 时代

7 月 28 日，Anthropic 发布了 MCP v5 规范。核心变化两个字：无状态。

这意味着什么？Agent 调用工具的方式，从"先打电话问你能不能接，再发请求"变成了"直接发请求，拿结果走人"。每次请求都是独立的，服务器端不需要记住任何上下文。水平扩展的门槛降到了零——你不需要关心"这个请求来自哪个会话"，加机器就行。

这对开发者来说，最直接的好处是部署成本降了一大截。有状态的 MCP Server 需要维护 WebSocket 长连接，跑在容器里要考虑会话亲和性，一不小心就出线上故障。无状态之后，MCP Server 就是一个普通的 HTTP 服务，丢到 K8s 里自动伸缩就行，运维复杂度直接降了一个量级。

有人可能会问：那 Agent 的对话上下文怎么办？答案是交给 Agent 框架自己管理，工具层只负责"请求-响应"这一件事。各司其职，比什么都往协议里塞要清爽。

Agent Plugins：MCP 有了"插头"

MCP 解决了协议层的问题——工具和模型怎么对话。但对话之外还有一堆事没解决：

怎么描述一个工具的能力范围？怎么把多个工具打包成一个"技能"？怎么在不同的 Agent 客户端之间共享这套配置？一个团队写好的工具集，怎么让另一个团队直接用？

Agent Plugins 做的就是这件事。它把 MCP Server 配置、Agent Skills 描述、工具元数据，全部打包成一个可移植的插件格式。你写一个 Plugin，就能在 Cursor 里用、在 VS Code 里用、在 OpenAI 的 Codex GUI 里用——只要客户端支持这个标准。

我打个比方：MCP 是电线，规定了电流怎么传。Agent Plugins 是插头，规定了插座的形状。电线再好，插头不统一，你还是得在每个房间拉不同的线。

这次联合发布方的阵容也值得琢磨。OpenAI 牵头，AWS 做云基础设施，Cursor 和 GitHub 代表开发者工具，VS Code 是编辑器入口，Vercel 跑前端部署。这六家凑在一起，基本上把"开发-部署-运行"整条链路都覆盖了。不是某个公司单方面推的标准，而是产业链上关键节点的共识。

阿里云的 One Key MCP 是另一条路——平台侧的统一。它不做新的协议或格式，而是把多个 MCP 服务的接入、鉴权、计费集中到一个入口。首批 14 家合作伙伴，覆盖搜索、数据库、办公协同、电商、金融、医疗六大领域。对于中小团队来说，这意味着不需要跟每个 MCP 服务商单独签合同、配密钥、对账——一个百炼 API Key 全搞定。

接下来半年，我猜会有三个变化

第一，MCP 和 Agent Plugins 会互相补充，而不是掐架。MCP 管通信，Agent Plugins 管分发。就像 HTTP 和 HTML 的关系——一个定义了怎么传，一个定义了传什么。如果后续有哪个团队能把两者整合成一套开箱即用的工具链，那会是开发者体验的一次大跃升。

第二，平台级的 MCP 市场会出现。阿里云已经开了个头，AWS 大概率会跟进。开发者不需要自己维护 MCP Server 的部署和运维，从市场里选一个，配好 Key 就能用。这有点像当年 Docker Hub 对容器生态的推动作用——标准先定好，市场再跟上。

第三，工具调用的安全层会成为一个独立赛道。这次 Claude Code 的 Auto Mode 测试数据很说明问题——人类在重复审批中会逐渐麻木，拒绝率从 13.6% 跌到 5% 左右。而自动模式用独立的分类器审查命令，拦截率达到了 89%。我注意到已经有团队在做 cMCP 这样的开源中间件，用 Rust 编写，给 Agent 的工具调用加一道审批锁，每次拒绝都带签名回执。这个方向在企业级场景下会越来越重要，毕竟没人想看到 Agent 误操作删了生产数据库。

说说我的真实感受

从去年第一次接触 MCP 到现在，我最深的感受是：Agent 行业正在经历一个从"手工作坊"到"标准化流水线"的转型期。去年这个时候，大家还在争论"Agent 到底是不是伪需求"，今年已经在讨论"怎么让 Agent 更好地调用工具"了。进步确实很快。

但标准化从来不是终点。当一个 Agent 能轻松调用几十上百个工具时，编排和协调的复杂度会成为新的瓶颈。你同时让五个 Agent 各自调用工具，它们之间怎么同步进度？怎么避免资源冲突？怎么保证数据一致性？这些问题，光靠协议和标准回答不了。

你觉得 Agent 的下一步瓶颈会是什么？是工具还不够多，还是工具太多了不知道怎么管？欢迎评论区聊聊。