多 Agent 的通信协议：Agent 之间怎么对话？自然语言还是结构化消息

我第一次让两个 AI Agent 协作写代码时，犯了一个很低级的错误——我让它们用自然语言直接聊天。结果一个 Agent 说“请把那个函数放到 utils 里”，另一个回“好的，我放好了”。然后就没有然后了。它俩倒是聊得很开心，但代码仓库里什么都没有。后来我才意识到，让 Agent 之间用自然语言对话，就像让两个外卖小哥用写诗的方式交接订单——不是不行，但迟早会出大事。

这就是多 Agent 系统里最核心、也最容易被忽视的问题：通信协议。Agent 之间到底该怎么“说话”？是用人类能看懂的自然语言，还是用机器之间高效传输的结构化消息？这个问题，整个社区争论了快两年，踩过的坑比写出来的论文还多。

这篇文章，我会把两种路线的底层逻辑、各自的致命缺陷，以及真正能用的混合方案，一次性讲清楚。

自然语言通信：看起来很美，实际上很累

最早一批多 Agent 框架，比如 CAMEL 和 ChatDev，几乎不约而同地选择了纯自然语言对话。CAMEL 让两个 Agent 一个演“AI 用户”，一个演“AI 助手”，通过聊天完成复杂任务；ChatDev 则让一群 Agent 扮演产品经理、程序员、测试员，在聊天室里用自然语言协作开发软件。

这个方案的出发点很直接：既然大语言模型（LLM）最强的是理解和生成自然语言，那 Agent 之间当然也用自然语言沟通最自然。你不需要设计任何接口规范，Agent 想说什么就说什么，灵活性拉满。而且整个对话记录人类可读，调试起来一眼就能看懂哪里出了问题。

但问题也恰恰出在“想说什么就说什么”。

自然语言有一个要命的特性——歧义。当一个 Agent 说“我把数据更新了”，另一个 Agent 完全不知道它更新的是哪个字段、用什么方式、更新成了什么值。它只能靠上下文去猜，猜错了就全盘崩溃。更糟的是，LLM 在生成自然语言时天然带有随机性，同一个 Agent 面对同样的输入，两次输出的措辞可能完全不一样。下游 Agent 必须每次都重新解析意图，这简直是在给系统稳定性的棺材板上钉钉子。

我踩过的一个真实的坑：用 AutoGen 框架让两个 Agent 协作调试代码，一个 Agent 负责报错，另一个负责修复。有一次报错 Agent 生成了这样的输出：“你的代码在第 23 行附近崩了，可能是个空指针，你查查。” 修复 Agent 居然回了一句：“好的，我检查了第 23 行，没看出问题，可能是别的原因。” 然后它俩开始来回推诿，就像两个人类程序员在互相甩锅。事后看日志，报错信息里根本没有给出具体的异常类型，修复 Agent 也没有要求结构化信息，整个协作就烂在了自然语言的模糊地带。

所以，自然语言通信的致命伤可以总结为三点：解析成本高（每次都要靠 LLM 重新理解）、不可靠（随机性导致输出不稳定）、无法做自动化验证（你说“放好了”，代码仓库里到底有没有，另一个 Agent 没法直接 check）。

结构化消息：效率高，但把 Agent 当函数调

既然自然语言太“软”，那干脆走另一个极端，让 Agent 之间只传结构化消息，比如 JSON 或函数调用。这条路最典型的代表是 MetaGPT，它要求 Agent 在共享消息池里发布结构化文档，比如产品需求文档（PRD）、系统设计文档，而不是自由聊天。每个 Agent 只消费自己能解析的结构化数据，输出也必须是符合预定义 schema 的 JSON。

这个方案的优点是立竿见影的：确定性强，每个字段的含义明确，下游 Agent 不需要“猜”；可验证，你可以用代码直接校验消息格式和内容；效率高，不需要反复用 LLM 做语义解析，直接走程序逻辑就能路由和处理。

但结构化消息的代价是灵活性丧失。Schema 一旦定义好，Agent 能表达的信息就被锁死了。如果上游 Agent 发现了 bug 但 schema 里没有“bug 描述”字段，它要么强行塞进“备注”里，要么干脆不说——无论哪种，都会导致信息丢失。更要命的是，设计 schema 本身就变成了一个巨大的工程。你让一群 Agent 协作处理开放域任务，比如市场调研或者创意写作，你根本没法预先把所有可能的消息类型都定义好。

还有一个更深层的问题：当所有 Agent 都只发结构化消息，LLM 的推理能力就被降级成了 API 调用。Agent 不再是“智能体”，而是一个个被严格限制的微服务。你放弃了自然语言带来的那种模糊但有价值的推理弹性——比如一次试探性的“我觉得这个方案可能有问题，你们怎么看？”——这种开放式的协作，在结构化消息体系里几乎不可能发生。

就像 MetaGPT 的论文里写的，Agent 在接收到结构化文档后，依然要用自然语言去理解文档内容然后生成自己的输出，但 Agent 之间的传输通道已经变成了纯结构化的管道。这相当于把通信问题异化成了数据交换问题，Agent 之间的“对话”变成了“传文件”。

一张表说清两种路线的本质区别

混合方案：怎么把两种模式叠在一起用

真正工业级的做法，是把通信拆成两层：控制层用结构化消息，协作层用自然语言。举个例子：当一个 Agent 想请求另一个 Agent 执行某个任务，它发出的消息可以是这样的：

{"intent": "task_request","task_id": "fix_bug_12","parameters": {"file": "utils.py","function": "calculate"},"rationale": "这一行会抛出 KeyError，因为 dict 里没有 'price' 这个键。你可以在访问前加一个 .get() 兜底。"}

这里 intent, task_id, parameters 是结构化字段，保证消息可以被可靠路由、验证、排队；而 rationale 字段是自然语言，允许上游 Agent 附着解释、上下文、建议，下游 Agent 可以用 LLM 去理解这些“软信息”，但不会因为解析失败就阻塞整个流程。

这种混合模式在微软的 AutoGen 框架里其实已经实现了，只是很多人没注意到。AutoGen 的 Agent 对话中，消息可以是纯文本，也可以包含“function call”格式的结构化指令。在实践中，经验丰富的开发者会刻意让 Agent 在关键节点输出结构化动作，而把中间推理过程留在自然语言通道里，供人类审计和调试。

另一个更极致的例子是 Anthropic 的 MCP（Model Context Protocol）。虽然它本身是给工具调用设计的，但它的核心思想完全适用于多 Agent 通信：Agent 不需要知道彼此的内部状态，只需要通过一个标准化的上下文协议交换“能力”和“结果”。MCP 用 JSON-RPC 作为传输层，消息体里既有结构化参数，也有文本描述。这个平衡点踩得非常准。

为什么“全自然语言”或“全结构化”都会失败

我在实际项目中试过两种极端，都吃过亏。有一次为了快速上线，我们让四个 Agent 完全用自然语言在 Slack 频道里协作做数据分析。前三天效果很好，Agent 甚至能自己讨论出分析维度。但第四天开始，对话历史越来越长，Agent 开始忘记前面说过的事，开始重复提问，甚至一个 Agent 生成了错误报告，另一个 Agent 基于错误报告继续分析，导致雪崩。根源就在于没有结构化的状态锚点——所有关键信息都淹没在几千字的聊天记录里，LLM 自己都找不到。

后来我们又试了另一个极端，把 Agent 之间的通信全部改成 JSON 事件流，每个事件都有严格的 schema。结果发现，Agent 在遇到 schema 没覆盖的边缘情况时，会直接跳过或抛出异常，而人类开发者需要不断维护 schema，开发成本指数级上升。更讽刺的是，因为消息太“干”，Agent 在推理时失去了上下文，输出质量反而下降。

这两个坑让我想通了一件事：多 Agent 通信的本质不是“让 Agent 说话”，而是“让 Agent 的状态可传递、可组合、可恢复”。自然语言适合传递复杂的、一次性的、需要推理的意图；结构化消息适合传递确定的、可重复的、需要验证的数据。把两者分开，放在不同层级，才是正解。

什么时候该用哪种？一个决策框架

如果你正在设计一个多 Agent 系统，下面这个简单的决策流程可能对你有用：

1. 任务是否高度不确定、需要探索性协作？ 如果是，让 Agent 用自然语言进行头脑风暴，但在关键决策点用结构化投票或总结来收束。参考 ChatDev 的“讨论-总结”模式。
2. 任务是否有明确的输入输出 schema？ 比如 API 调用、数据库操作、文件生成，果断用结构化消息。Agent 之间传 JSON 或函数调用，避免任何自由文本干扰。
3. 是否需要人类介入审计？ 把自然语言对话作为“解释层”，把结构化消息作为“执行层”。人类看自然语言日志，机器看结构化指令。
4. 系统规模是否会超过 5 个 Agent？ 超过这个数量，纯自然语言对话的上下文管理会爆炸，必须引入结构化消息做消息路由和状态管理，否则 Agent 们会陷入“集体失忆”。

几个常见误解

“自然语言通信就是让 Agent 像人一样聊天”

不是。Agent 之间用自然语言通信，不是为了拟人，而是为了利用 LLM 的零样本推理能力。它们的“聊天”更像是两个工程师在共享白板上写笔记，而不是社交对话。如果把多 Agent 当成聊天机器人联机，你会很快发现它们只是在礼貌地兜圈子。

“结构化消息能解决所有可靠性问题”

不能。结构化消息只能保证消息格式正确，不能保证消息内容合理。上游 Agent 依然可能在 JSON 里填上错误的数据，下游 Agent 如果不加验证，照样会崩。Schema 只是减少了“解析错误”，不是“逻辑错误”的银弹。

“混合方案就是简单地在 JSON 里加个 text 字段”

远不止于此。好的混合方案要定义清楚：哪些字段是必须被解析的（结构化），哪些字段是仅供 LLM 理解的（自然语言）；消息路由是基于结构化字段，还是也要解析自然语言内容；以及当自然语言与结构化字段发生冲突时，以谁为准。这些细节才是工程的魔鬼。

所以，Agent 之间到底该怎么对话？

我的判断是：未来两到三年，主流的多 Agent 系统会收敛到“结构化骨架 + 自然语言血肉”的模式。骨架负责确定性、可靠性和效率，血肉负责灵活性、解释性和创造力。纯自然语言方案会逐渐退化为原型验证或小规模实验，而纯结构化方案会退化为传统微服务架构的一种特化形式，失去“智能体”的本意。

如果你今天要开始一个多 Agent 项目，我的建议是：从结构化消息开始，用自然语言做补充，而不是反过来。因为从确定性往灵活性迈，你只是在增加一个可选字段；从灵活性往确定性迈，你得推翻整个通信栈。这个方向的选择，决定了你未来会不会在凌晨三点被 Agent 之间的“聊天死循环”叫醒。