AI代理的“语言战争”：模型上下文协议的挑战与未来生态重构

TL;DR：

模型上下文协议（MCP）作为大模型代理与外部工具通信的标准化尝试，其HTTP传输层设计暴露出复杂性、安全性和可扩展性等深层工程问题。在IBM和谷歌等巨头纷纷推出各自代理协议的背景下，当前技术栈的碎片化与底层工程缺陷，正严峻挑战着构建一个开放、高效“智能体互联网”的愿景，亟需行业回归稳健工程实践以避免技术债累积。

大模型代理的“神经中枢”：协议标准化与深层挑战

随着大型语言模型（LLM）能力的不断跃升，将它们从简单的对话引擎升级为能与世界互动的“智能体”（AI Agent）已成为下一代AI应用的核心趋势。这些智能体不再局限于生成文本，而是能够自主规划、调用外部工具、访问数据库并执行复杂任务。支撑这一宏大愿景的基石，正是其与外部环境进行高效、可靠交互的“语言”——通信协议。由Anthropic提出的模型上下文协议（Model Context Protocol, MCP）旨在成为AI应用程序的“USB-C端口”¹，提供一种标准化途径，让LLM连接到各种数据源和工具。然而，这项关乎AI未来基础设施的标准化尝试，正经历着一场对其底层设计和工程实践的深刻批判。

这种标准化的迫切性不言而喻。想象一个“智能体互联网生态系统”的愿景²，如同今天的Web，它将分散的AI智能体、工具和数据源连接成一个互联互通、协同工作的智能网络。在此背景下，统一的通信协议是实现智能流动与组合、构建集体智能的关键。但正如原始RSS文章所尖锐指出的，尽管各方投入数十亿美元训练模型，却在基础协议的工程实践上显得稚嫩，导致设计决策、文档质量和SDK实现都存在显著不足。这不仅是技术层面的挑战，更是关乎整个AI代理生态能否健康、可持续发展的哲学命题。

MCP 的技术审视：协议设计之殇

MCP的核心是一个基于JSON-RPC的协议，旨在为LLM与外部服务交互提供统一接口。然而，其在传输层，特别是HTTP传输方式上的选择，引发了广泛争议。原始作者在尝试用Golang实现MCP服务器时，就深陷“精神崩溃”的境地，因为缺乏清晰的文档，且需要对协议进行“逆向工程”¹。

传输层设计的固有缺陷：SSE与“Steamable HTTP”之谜

MCP主要提供了两种（或三种）传输协议：stdio、HTTP+SSE和“Streamable HTTP”。

• Stdio：作为本地模式，通过stdin/stdout管道进行通信，虽然在双向通信上不如socket直观，但其简单性得到一定理解。
• HTTP+SSE：这种模式为了实现全双工通信，要求客户端建立SSE会话读取响应，同时通过POST请求提交写入操作。服务器返回202 Accepted状态码，响应则从预先打开的SSE连接中读取。这种设计给服务器实现带来了巨大且不必要的负担，需要服务器在调用之间“join”连接，几乎强制使用消息队列来回复请求。在分布式系统中，这会引发复杂的状态管理问题，例如SSE流从一个服务器发出，而请求却发送到另一个服务器。
• “Streamable HTTP”：被描述为HTTP+SSE的“杜撰”演进版本，试图将REST语义与SSE结合，但却进一步加剧了复杂性。它允许多种方式发起会话、打开SSE连接和响应请求，例如一个GET请求或POST请求都可以开启SSE，响应也可以通过HTTP正文、新的SSE流或现有SSE事件返回。这种“灵活性”带来的复杂性是毁灭性的：
  • 复杂性提升：执行相同操作的多种方式极大增加了开发者的认知负担，代码理解、调试和维护变得异常困难。
  • 不一致性风险：不同实现之间存在不一致的潜在风险，导致互操作性问题和不可预测的行为。
  • 可扩展性瓶颈：服务器难以管理大量机器上的多种连接状态和响应机制，为可扩展性埋下隐患。
  • 安全隐患：复杂的状态管理在不同连接类型（HTTP和SSE）之间极易产生会话劫持、重放攻击、DoS攻击等漏洞。多个入口点也扩大了攻击面，混淆的控制流为恶意活动提供了可乘之机。

作者直言，这种尝试在SSE之上实现WebSocket行为，并冠以“Steamable HTTP”之名，试图让其显得“合理”的说法，是站不住脚的。与其如此，不如直接采用更成熟、更适合双向流式通信的WebSocket协议。WebSocket天然支持全双工通信，无需复杂的服务器状态管理，能够消除大量极端情况，极大简化实现。

工程实践与生态痛点

除了传输协议的深层问题，原始文章还揭示了更广泛的工程实践痛点：

• 文档质量低下：官方文档掩盖或忽略了协议的关键方面，缺乏对话流程示例，更像是SDK教程而非规范。
• SDK质量欠佳：缺乏官方Go SDK，现有示例主要依赖Python或JavaScript，且常以Docker容器提供，暗示了严重的依赖管理问题（“pip install 依赖地狱”）。对于需要可移植性和可靠性的本地运行程序，Go或Rust等编译型语言，或Java/C#等基于虚拟机的语言，显然是更优选择。
• 授权机制的主观性：最新版协议对授权有主观要求，区分stdio和HTTP传输，强制HTTP实现OAuth2，而stdio则允许使用API密钥，缺乏统一性和合理性。

这些问题共同构成了AI代理基础设施发展初期亟待解决的技术债。在一个快速迭代、高投入的AI领域，基础协议层面的工程瑕疵，可能在未来数年内持续拖累创新速度和系统稳定性。

代理通信协议的“春秋战国”：统一与分歧的产业生态

MCP并非唯一的玩家。AI代理协议领域正经历一场“春秋战国”式的群雄逐鹿。IBM推出了代理通信协议（ACP），谷歌也发布了Agent2Agent（A2A）协议。此外，还有开源社区的ANP（Agent Network Protocol）、牛津大学的Agora以及CopilotKit的AG-UI（Agent-User Interaction Protocol）等。²³⁴

• MCP：专注于单个AI代理与多个外部工具、数据源的交互，标准化工具调用和上下文管理。
• A2A：谷歌的A2A协议更侧重于企业内部多个代理之间的复杂协作和问题解决，通过“Agent Card”机制标准化代理能力描述，支持异步工作流和多模态交互。它代表了一种更强烈的内部生态整合倾向。
• ACP：IBM的ACP协议，原作者认为其更像是推广其“代理构建工具”BeeAI的一种尝试，并指出其功能很大程度上可以被MCP实现或作为MCP工具调用。这揭示了巨头在定义标准时，常常伴随着其商业产品和生态推广的策略考量。
• ANP：由开源社区主导，旨在实现不同代理之间的开放互操作性，构建一个去中心化、跨域的智能体协作网络，更具开放Web的精神。
• AG-UI：专注于解决AI Agent与前端应用之间的交互标准化，强调轻量级、事件驱动和实时双向通信，补充了代理与用户界面连接的空白。

这种协议的碎片化反映了行业对AI代理未来形态的不同认知和商业战略。一些协议强调“单个代理调用所有工具”（如MCP的早期设想），另一些则偏向“代理委托给专业代理”（如A2A），还有一些则致力于实现“跨组织代理互操作”（如ANP）。尽管这些协议声称“正交”，但它们的重叠和各自为战，无疑增加了开发者的选择困难和互操作性成本，形成了事实上的“语言战争”。

从商业敏锐度来看，谁能成功定义并推广其协议成为行业标准，谁就可能在未来的“智能体经济”中占据主导地位。这不仅仅是技术之争，更是生态主导权之争。巨头们深知，在基础设施层面建立标准，能有效地构筑竞争壁垒，并引导开发者走向其平台。

通往“智能体互联网”的路径：融合与进化

当前的协议格局正处于一个关键的十字路口。原始文章呼吁行业回归对最常见用例的优化，并采用成熟、稳定的传输技术，例如WebSocket。这种务实态度与MIT Technology Review所倡导的严谨工程精神不谋而合。将复杂的、易出错的HTTP+SSE/Streamable HTTP传输替换为简洁、高效的WebSocket，不仅能解决当前的设计缺陷，还能大大提升可维护性、可扩展性和安全性，为AI代理的广泛应用铺平道路。

未来，我们可能看到几种趋势：

1. 传输层面的趋同：随着工程实践的成熟，各协议最终会收敛于像WebSocket这样经过验证的、高效的双向通信机制。
2. 协议栈的层次化：不同的协议可能在不同的抽象层次上发挥作用。例如，MCP可以作为底层工具调用协议，而A2A或ANP则作为上层代理间协作和协调的协议，AG-UI则专注于与用户界面的连接。这种模块化和分层的架构将有助于构建一个更为健壮和灵活的智能体互联网。
3. 开源与协作的重要性：面对碎片化，像ANP这样的开源协议将扮演关键角色，推动跨平台、跨组织的互操作性，打破潜在的“厂商锁定”。只有通过开放标准和社区协作，才能真正实现“智能的流动与组合”。
4. 工程文化的重塑：从“在我电脑上能用就行”的临时方案，转向对可移植性、健壮性和高效率的追求，是AI软件工程成熟的必经之路。这意味着需要投入更多资源来编写高质量的文档、提供多语言SDK，并遵循成熟的软件开发最佳实践。

从Wired的哲学思辨角度来看，智能体通信协议的演进，不仅仅是技术层面的优化，更是对“智能体社会”如何组织、互动乃至最终影响人类社会的一次集体探索。谁来制定规则？这些规则如何保障公平、透明与安全？这些都是在技术发展初期就需要审慎思考的伦理与治理问题。

最终，构建一个真正健壮、开放、可信赖的“智能体互联网”，将需要技术开发者、企业巨头、开源社区以及政策制定者之间的共同努力。现在是时候正视基础架构中的工程挑战，确保AI的未来是建立在坚实而非摇摇欲坠的地基之上。

引用

• AI Agent
• 模型上下文协议
• 通信协议
• WebSocket
• 软件工程
• 产业生态