走进 AI 的通讯世界:解密 Agent 之间的沟通协议
从通信架构的视角把 Agent 之间的对话拆成 H2A、A2S、A2A 三个维度,看 Agent Internet 如何复刻一遍计算机网络的历史。
TL;DR
当下的 AI Agent 发展阶段,像极了互联网诞生的前夜——早期的 AI 是一台台孤立的超级计算机, 算力强大但与世隔绝,而现在这些大脑正试图连成一张网。 互联网连的是人与人,物联网连的是物与物,Agent Internet 连的是智能与智能。 这篇从通信架构的视角把它拆成三条生命线: H2A 是人机交互,瓶颈已经从「模型听不听得懂」变成了带宽,也就是上下文窗口; A2S 是 Agent 与数字服务的连接,MCP 相当于给 AI 世界发明了 USB-C 接口; A2A 是最复杂的一层,路由、拓扑、共识机制几乎是把计算机网络的历史又走了一遍。
目录
最近看了很多代码,也读了一些关于多智能体系统的文章。当下的 AI Agent 发展阶段,像极了互联网诞生的前夜。
早期的 AI 像是一台台孤立的超级计算机,算力强大但与世隔绝。而现在的趋势是,这些超级大脑正在试图连成一张网。
如果说互联网连的是人与人,物联网连的是物与物,那么 Agent Internet 连的就是智能与智能。
要理解这张网是如何构建的,我们需要跳出聊天机器人的思维定式,从通信架构的视角来看待它。结合最近的学习,我把 Agent 的通信大致拆解为三个核心维度:H2A、A2S、A2A。这也是在设计复杂 AI 应用时,必须搞清楚的三条生命线。
H2A:不仅仅是 Prompt Engineering
H2A(Human-to-Agent)是我们最熟悉的领域:人与智能体的交互。
在产品经理眼中,这往往等同于聊天框或 prompt 设计。但在技术架构的视角下,H2A 正在经历一场从「非结构化」到「半结构化」的协议升级。
过去:用户发一段话,AI 回一段话。这就像早期的电报,信息是线性的、模糊的。
现在:开始引入结构化指令。比如在 OpenManus 等项目中,用户的一个请求不再只是简单的文本字符串,而被封装成了包含 messageId、role、session_config 的 JSON 对象。
H2A 的瓶颈不再是模型听不听得懂人话,而是带宽,即上下文窗口。正如网络带宽限制了视频的清晰度,Context Window 限制了 H2A 的交互深度。
为了解决这个问题,技术上引入了类似 TCP 流控的机制:滑动窗口(只记最近的对话)和记忆压缩(将旧对话摘要存储)。
这就解释了为什么我们的 AI 产品聊久了会变笨:因为它正在经历「上下文腐烂」,就像网络丢包一样。
技术实现上,H2A 通信通常通过 HTTP、WebSocket 等协议完成。
A2S:智能体的「手」与「USB 接口」
如果 Agent 只有大脑,那它只是个哲学家。要让它干活,它必须与现实世界的数字服务连接,这就是 A2S。在开发中,这通常被称为 Tool Use 或 Function Calling。
这里有一个正在发生的重大变革:MCP(Model Context Protocol,模型上下文协议)。
以前,让 Agent 连接一个数据库或 API,开发人员需要写各种胶水代码,就像以前给电脑接打印机要装各种驱动一样麻烦。而 MCP 的出现,就像是给 AI 世界发明了 USB-C 接口。
标准化:只要外部服务(不管是 Notion、GitHub 还是公司内部 ERP)遵循 MCP 标准,Agent 就能即插即用,自动读取数据、执行操作。
A2S 的本质:Agent 作为调用方,发送结构化的 JSON 请求(比如 {"tool": "search", "query": "latest ai news"}),服务方执行后返回结果。
A2S 决定了产品的能力边界。未来的 AI 产品壁垒,可能不在于用了哪个大模型,而在于你积累了多少独家的、标准化的 A2S 接口资源。
技术实现上,A2S 通信通常使用 HTTP、gRPC 等协议。
A2A:真正的智能互联网
这是最核心也最复杂的部分。当一个任务太复杂(比如「开发一个游戏」),单个 Agent 搞不定时,就需要多个 Agent 协作。这时候,Agent 之间怎么说话呢?
在一个契机之下,让我发现这一层好像就是计算机网络历史的完美复刻。
1、它们怎么找对方?(路由与拓扑)
在传统网络里,电脑通过 IP 地址找到对方。而在 Agent 网络里,路由是基于语义的。就像公司的组织架构一样,Agent 之间通常有三种主流的连接方式:
点对点通信:每个 Agent 直接与另一个 Agent 通信,适用于小规模系统。这就像是头脑风暴,大家自由连接,能产生惊人的创意(涌现),但也容易失控,导致吵架或者死循环。
中心化通信:所有 Agent 通过一个中央协调者进行通信,适用于任务复杂、需要全局调度的场景。最典型的是微软 AutoGen 的 GroupChat 模式,有一个管理员 Agent 坐在中间指挥:你先说,他再说。效率高,但管理员容易累到缺氧(上下文窗口溢出)。
共享黑板:所有 Agent 都可以把自己的数据写到共享的黑板上,其他 Agent 读取这些数据进行处理。这就像大家都不说话,而是把想法写在白板上,谁有能力谁就上去接着写。这种模式特别适合高度解耦的、复杂的异步协作。
2、它们怎么达成一致?(共识机制)
当产品经理 Agent 说要做红色的按钮,而程序员 Agent 说技术实现不了,系统听谁的?这时候就需要共识机制。技术界正在把分布式系统的算法(如 Raft、投票机制)搬到 Agent 里:投票是少数服从多数,辩论则是经过多轮互喷,真理越辩越明。
3、通信的语言
以前的软件之间传数据用二进制。现在的 A2A 通信,载体是自然语言加 JSON。
这是一个巨大的范式转移:语义即协议。Agent A 输出的自然语言思考过程,成为了 Agent B 的输入。
A2A 架构的设计,直接决定了产品的稳定性和成本:
- 稳定性:链路越长(A 传给 B,B 传给 C),首字延迟就越高,用户等待感越强。
- 成本:每一个 Agent 之间的每一次对话,消耗的都是真金白银的 Token。设计不良的 A2A 架构,会让 Token 像水龙头没关紧一样流失。
最后
架构是思维的载体,代码是实现的手段。
- H2A:懂得如何定义人机边界。
- A2S:看到能力扩展的可能性。
- A2A:预见群体智能的未来。
未来的 AI 产品经理,可能更像是一个组织架构师。需要设计的不仅仅是一个功能,而是一个由多个 Agent 组成的、高效沟通的数字化团队。
从理解代码开始,会发现自己看到了一个比 PRD 文档更广阔的世界。
核心结论
标注「判断」「假设」的是我的看法而非事实;标注「已推翻」的保留在这里,不删除。
H2A 的瓶颈不再是模型听不听得懂人话,而是带宽——上下文窗口。正如网络带宽限制视频清晰度,Context Window 限制了人机交互的深度,AI 聊久了会变笨,是因为它正在经历上下文腐烂。#
判断 · 把握较大
MCP 相当于给 AI 世界发明了 USB-C 接口。以前让 Agent 连一个数据库要写各种胶水代码,现在只要外部服务遵循 MCP 标准,Agent 就能即插即用。#
判断
未来 AI 产品的壁垒,可能不在于用了哪个大模型,而在于你积累了多少独家的、标准化的 A2S 接口资源。#
假设
以前软件之间传数据用二进制,现在 A2A 通信的载体是自然语言加 JSON。这是一个巨大的范式转移——语义即协议,Agent A 输出的自然语言思考过程,成为了 Agent B 的输入。#
判断
A2A 架构直接决定产品的稳定性和成本:链路越长首字延迟越高,而每一次 Agent 之间的对话消耗的都是真金白银的 Token,设计不良的架构会让 Token 像水龙头没关紧一样流失。#
判断
引用本文
晨旭,《走进 AI 的通讯世界:解密 Agent 之间的沟通协议》,晨光里的AI,2025-11-20
[晨旭:《走进 AI 的通讯世界:解密 Agent 之间的沟通协议》](https://chenxu.xin/writing/agent-communication-protocols)带进你的 AI 继续追问
这篇文章有一份干净的 Markdown 原文,可以直接交给任何模型读,不用复制粘贴。