北京
在一个典型的AI Agent生产部署里，运维团队连通了五六个MCP服务器，并行启动A2A任务来处理那些需要长时间、多轮委派的流程，还要用计算机使用模式驱动一批根本提供不出API的老旧软件。每个连接点都是一段手写的胶水代码：自定路由、自制认证传递、自写输出解析、自建重试逻辑。每一家都这么写，每一家都自己维护，没有一份是共享的。
如果我们只看协议层的数字，走向是另一种叙事。2024年11月，Anthropic开源了MCP；到了2025年3月，OpenAI已经把它集成进了ChatGPT和Agents SDK。4月，Google发布A2A，一出场就带着50多家合作伙伴；8月，IBM的ACP协议并入A2A，协议之间开始合并。到2025年末，MCP和A2A双双进入Linux基金会。同一时间点，Anthropic的生态更新显示：活跃的公共MCP服务器超过1万个，SDK月下载量达到9700万次，官方注册中心接近1万条记录，GitHub上标记mcp-server话题的仓库约有1.6万个。A2A方面，到2026年4月，支持该协议的组织已超过150家。从任何标准看，这都是协议史上最快的标准化过程——快过了REST当年的胜利节奏。
于是，正方观点很自然地浮现出来：这就是工具层的终局。MCP让Agent能调用工具，A2A让Agent能彼此委派任务，数字化的大桥已经架好了。如此迅猛的采用曲线足以说明“标准”本身不再是瓶颈。如果谁还觉得缺什么，那多半是他的工程师还没跟上节奏。
但反方的证据恰恰藏在那些采用数字的背后。第三方调查显示，一个典型的MCP部署环境配置了2到7个服务器，可只要方案稍具规模，就必然同时跑着A2A的有状态代理任务——MCP天生不擅长处理多轮、带状态的委托。再叠上那些没有API、只能靠计算机操作驱动的长尾软件，整个技术栈就被三种互不兼容的通道贯穿。然而把它们连起来的不是协议，而是工程师一行一行写出来的胶水：定制路由、认证交接、输出解析、重试策略。这些胶水代码是每个团队的人肉负担，并且从未被标准化。
这正是当初A2A发布时社区的第一反应：“我们已经有了MCP，为什么还要一个标准？”诚实回答其实很清楚：它们解决的是同一枚硬币的两面。但诚实的问题更尖锐：为什么从来没有人去标准化那个把两面拼起来的中间层？
这已经不是理论层面上的疼痛。Zuplo在《2025年MCP状态报告》里给出的结论直白到近乎讽刺：安全与访问控制是MCP进入生产环境的最大障碍，排在所有能力差距之前。工具本身跑得通，可一旦要把它们组合起来一起运转，系统就开始往不可控的方向塌陷。问题的瓶颈发生了位移，业界却几乎没有人跟过去。
2026年“循环工程”讨论里最有启发的一个判断是：在任何Agent循环中，验证器才是瓶颈，不是模型。生成环节廉价而且可以无限自旋，但整条循环只有在有东西能够裁决“放行、重试、停止”时才会产生真实价值。Andrew Ng在谈评估器，Karpathy把这门手艺归结为生成与验证的关系，一线实践者笔下所有关于循环工程的推导都最终撞进同一条门闩。
现在把复杂性乘上组合层。一个代理、一条循环、一个验证器，已经够难却尚可理解。但当同一个目标下横跨N个代理、M种协议时，验证面立刻爆炸：哪一步失败了？输出到底有没有被结构化成可解析的形式？该调用的代理真的被调到了吗？它有没有权限执行这个动作？专门为单代理循环设计的工具从来就不需要回答这些问题，因为它们从来就被设定在一个更单纯的前提之下。
更麻烦的是聊天输出本身在放大这种混乱。当多代理的运行结果试图通过一段对话记录来表达时，错误、超时、凭证过期、结构不符合预期的信息会被压进一块不加区分的文本，验证变得越发困难，溯源几乎靠猜。单代理的循环或许还能靠强化的提示和验真机制勉强应对，但一旦涉足多协议、多步骤的长期任务，缺乏统一编织层的代价就从开发成本蔓延到了系统可靠性本身。
协议已经赢了，比任何人预料的都快。但下一次不靠手工胶水、真正让这些协议在一个完整的代理栈里无缝相处的标准，还停留在那张空白的白板上。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
