🤖 AI 速览

现在是 2026 年 6 月。距离 AutoGPT 和 BabyAGI 引爆多智能体热潮已经过去了三年。
📋 文章元数据
发布时间
2026-06-07
类型
posts
标签
AI, Agent, 多智能体, 通信效率, arXiv

Agent 快被自己「话太多」拖死了——多智能体通信效率的深层危机 链接到标题

2026-06-07 | 深度长文 | 基于 arXiv 2606.05304 + ICLR 2026 SupervisorAgent + 行业框架对照

现在是 2026 年 6 月。距离 AutoGPT 和 BabyAGI 引爆多智能体热潮已经过去了三年。

三年间，多 Agent 协作从一个「用 LangChain 串两个 LLM 调用」的实验品，变成了 Claude Code 里 1000 个 Agent 并发执行的工业级范式。 Anthropic 刚发布的 Dynamic Workflows 让用户在一个任务里调度上千个智能体； OpenAI Codex 把软件开发流程拆成了子代理链条； CrewAI 、 AutoGen 、 LangGraph 各有数万 GitHub Star——我们似乎已经默认了「一个 Agent 解决不了的，就放十个 Agent 一起去解决」。

但 2026 年 6 月 6 日，一篇来自新加坡科技设计大学（ SUTD ）的 arXiv 论文提出了一个让整个方向需要重新审视的问题：

「 What Should Agents Say?」——Agent 之间到底该说什么？

这个看似简单的问题，戳穿了多智能体系统（ MAS ）当前最深的隐形成本。而结合 ICLR 2026 上的另一篇相关工作、主流框架的通信模式分析、以及推理模型时代的新变量，我们会发现：Agent 之间的「话费」正在从优化项变成生存项。

一、问题的物理本质： O(n²) 的通信灾难 链接到标题

假设你有一个由 5 个 Agent 组成的顺序流水线（ Sequential Pipeline ），就像 2026 年最典型的 Agent 编排方式那样：

`用户提需求 → Agent A 分析 → Agent B 编码 → Agent C 测试 → Agent D 部署 → Agent E 报告


在「无约束自然语言通信」模式下，每次交互的具体情况是这样的：

1. Agent A 接收用户需求，调用 LLM 。输出包含：需求理解、分析过程、初始方案建议。共约 2000 Token 。2.Agent B 收到的输入是：用户需求 + Agent A 的全部 2000 Token 输出。它再产生约 3000 Token （代码 + 解释）。3.Agent C 收到的输入是：用户需求 + A 的 2000 Token + B 的 3000 Token 。它再产生约 2500 Token （测试报告）。4.Agent D 的输入是：用户需求 + A(2000) + B(3000) + C(2500)。加上自己的 1500 Token 。5.Agent E 的输入是：用户需求 + A(2000) + B(3000) + C(2500) + D(1500)。加上自己的 1000 Token 。

累计 Token 消耗：每个下游 Agent 处理的上下文呈**线性增长**，但每次调用的 API 成本 = 输入 Token 价格 × 累积上下文大小。当一个任务需要 20 轮交互时，第 20 轮的输入可能已经达到数万 Token——而这些 Token 里起码有 70% 是冗余的。

这还没算推理模型。如果把 Agent C 换成 Gemini 3.1 Pro Thinking ，它单次内部思维链可能就有 8000 Token 的思考过程——而这些全会被塞进 Agent D 和 E 的共享历史里。

**这不是线性增长的问题，是复利**。

---

## 二、 PACT 论文的发现： Agent 不需要写小作文

SUTD 的 *What Should Agents Say?* 是第一个系统性地把「 Agent 间通信内容」作为独立变量来研究的论文。

### 2.1 五种通信策略，没一个能通吃

研究团队在两套 MAS 拓扑（分离证据交互 Split-evidence 和顺序流水线 Sequential Pipeline ）上测试了业界最常见的五种 Agent 间通信模式：

| 策略
| 做法
| 优点
| 致命缺陷
 |

| **全量透传（ Full Pass-through ）**
| 上游 Agent 的完整输出原样传给下游
| 不丢信息
| Token 消耗累积爆炸
 |

| **LLM 摘要透传（ Summary ）**
| 由另一个 LLM 先做摘要再传递
| 减少 Token
| 关键是「谁来做摘要」——又是成本；且摘要质量不稳定
 |

| **关键信息提取（ Structured Extraction ）**
| 只提取结构化字段传递
| 紧凑
| 容易遗漏语境化细节
 |

| **辩论式（ Debate ）**
| Agent 相互反驳，多轮后收敛
| 提升答案质量
| Token 消耗最大——每一轮反驳都在积累历史
 |

| **投票式（ Voting ）**
| 多个 Agent 独立输出，按多数票决定
| 简单鲁棒
| 并行调用成本高，且不解决「为什么要并行」的根本问题
 |

**核心发现：没有一种固定策略在所有场景下最优。但有一个共同规律——在所有有效的案例中，传递的都是「动作-状态」信息（ action-state ），而非「完整自然语言叙事」**。

换句话说： Agent 之间需要的是填表，不是写作文。

### 2.2 PACT ：把 Agent 通信变成状态更新

基于这个发现，研究团队提出了 **PACT （ Protocolized Action-state Communication and Transmission ）**。

PACT 的核心思想非常朴素：**把 Agent 间通信视为「公开状态更新」问题**。 每个非终端 Agent 在完成任务后，其输出不是直接推入共享历史，而是先经过一个「投影层」——被压缩成一个紧凑的 action-state 记录。这条记录只包含三件事：

- **做了什么**（ action ）
- **产生了什么状态变更**（ state delta ）
- **下游需要知道什么**（ dependency/flag ）

然后才将这条压缩后的记录写入共享历史，供后续 Agent 消费。

这个思路听起来像什么？**像 Git 的 commit message **。

Git 社区经过几十年演化形成的共识是： commit message 应该是一行 subject + 一段 body ，描述「做了什么」和「为什么做」，而不是把整个 diff 和开发者的思考过程塞进去。没人愿意读一个 3000 行的 commit message 。但多智能体系统目前的做法，就相当于把每个 Agent 的内部 diff 、思考笔记、甚至失败重试记录全部塞给下游。

### 2.3 量化效果：不是锦上添花，是质变

论文在生产级代码 Agent 框架上的实测数据非常有力：

- **OpenHands （生产级开发框架）**：使用 PACT 后，在 token-per-resolved 指标**降低 10%** 的同时，任务的 **resolve rate 提升了**。即：不仅省钱，还更准。
- **SWE-agent**：在维持同等 resolve rate 的前提下，**输入 Token 消耗减半**。

「 token 减半、成功率不降」——这在任何工程指标上都是第一优先级的事情。

---

## 三、 SupervisorAgent ：另一条路线，同样的目标

ICLR 2026 上另一篇入选论文 *Stop Wasting Your Tokens: Towards Efficient Runtime Multi-Agent Systems*，从不同角度攻击了同一个问题。

SupervisorAgent 的方案是：**在关键交互节点插入一个轻量级「监督 Agent 」**，它的工作不是参与业务逻辑，而是纯粹做三件事：

1. **过滤噪声**：把上游 Agent 输出中的废话、重复内容、失败重试记录剥离2.**纠正错误**：在错误信息污染下游上下文之前拦截3.**净化观察结果**：把传递的内容压缩为最小有效信息

关键是，这个监督 Agent 的触发是靠一个**免 LLM 的上下文过滤器（ LLM-free context filter ）**——也就是说，它本身几乎不消耗 Token 。

在 GAIA benchmark （多智能体系统最具挑战性的评测之一）上， SupervisorAgent 让 **Smolagent 框架的平均 Token 消耗降低了 29.68%，成功率零损失**。在数学推理、代码生成、问答等五个额外 benchmark 和多种 SoTA 基础模型上，效果一致。

如果把 PACT 和 SupervisorAgent 放在一起看，它们在说同一件事：**Agent 通信的默认模式（自由自然语言 + 全量透传）是错的**。 区别在于 PACT 从「协议层」解决问题（定义 Agent 应该传什么）， SupervisorAgent 从「运行时层」解决问题（在传递时过滤什么）。两者本质互补。

---

## 四、当前主流框架的通信模式：一个对照检查

这让我们有必要审视一下，当前最流行的几个 Agent 框架在通信这件事上到底是怎么做的。

### CrewAI

强制 Agent 顺序执行（ Sequential ）。什么意思？上一个 Agent 的全部输出，一字不改地作为下一个 Agent 的输入上下文。**这是 O(n²) 的 Token 指数陷阱**。 5 个 Agent 的流水线，第 5 个 Agent 的输入上下文可能已经是第 1 个的 5 倍大。

### AutoGen （微软）

基于群聊（ Group Chat ）模式，默认依赖完整对话历史。随着对话轮次增加，每次 API 调用的上下文呈**二次方爆炸**（所有 Agent 的所有历史发言互相可见）。官方已经意识到了这个问题，引入了 `max_turns` 限制和对话总结机制来截断长尾——但这本质上是「用摘要代替原始输出」，类似论文里测试过的那种方案，效果取决于摘要质量。

### LangGraph

基于图（ Graph ）和状态机。所有 Agent 围绕一个集中的 **`State` 字典**读写，只传递结构化状态而非自由文本。这是目前主流框架中在通信效率上最先进的——它天然实现了 PACT 想要做的事：**用结构化状态替代自然语言聊天**。 但 LangGraph 的局限在于，它要求开发者显式定义 state schema ，这增加了设计成本，也让它在处理高度非结构化的协作场景时不够灵活。

### Claude Code / Codex （ OpenAI ）

这两个 Agentic Coding 工具的 Agent 通信模式比较特殊。它们主要通过 MCP （ Model Context Protocol ）等协议直接与工具交互，内部 Agent 间的通信相对较少。更多时候采用的是「单体超大上下文」策略——把大量信息一次性喂给一个长上下文模型，让模型自己去理解和调度。这在当前阶段有效（因为 Gemini 3.1 Pro 有 200 万 Token 上下文窗口），但同样不可持续——上下文窗口虽然变大了，但注意力密度（ attention density ）会随窗口增大而稀释。

---

## 五、推理模型时代： Thinking Trace 的灾难性放大

如果前面讨论的问题还只是「优化项」，那推理模型的出现把这件事变成了「必选项」。

2026 年， OpenAI GPT-5.5 、 DeepSeek-V4 、 Gemini 3.1 Pro Thinking 、 Claude Opus 4.8 等推理模型都默认或可选地在内部执行长链思维（ Chain-of-Thought ）。单次推理可能产生几千到几万 Token 的隐式思维链：

`"嗯，让我重新考虑一下这个问题。从第一性原理出发..."
"等一下，我之前的推理有一个漏洞..."
"实际上，有另一种可能性..."
"综合考虑以上所有因素，我的结论是..."

这些 Thinking Trace 本身有价值——它让模型推理更深更准。但问题在于：如果 MAS 框架不隔离这些 Trace ，它们会被全量塞进共享历史。

后果是灾难性的：

  1. Token 账单失控：一个 2000 Token 的最终输出背后可能有 8000 Token 的思维链。下游 3 个 Agent 各自还要复制这 8000 Token 的上下文开销。2.跨 Agent 污染： Agent B 读到 Agent A 的内部纠结过程（「嗯，等一下…」「其实有一个问题…」），可能被 A 的犹豫误导，做出不必要的纠偏动作。3.注意力稀释：研究表明 LLM 对上下文中部的信息处理能力本就不足（ Lost in the Middle ）。当上下文中塞满了别人的思考过程，关键信息被淹没的概率急剧上升。

**PACT 和 SupervisorAgent 方案在推理模型时代的最大价值恰恰在这里：它们强制隔离内部思维链，只在 Agent 间传递最终结论或结构化的 action-state **。 这不是锦上添花——是推理模型参与多 Agent 协作的前提条件。

六、行业正在「重新发明 TCP 」： Agent 通信协议简史 链接到标题

2025-2026 年，业界已经意识到 Agent 间通信需要标准化，而不是每个框架自己搞一套。几大协议正在收敛：

| 协议 | 主导方 | 用途 | 与通信效率的关系 |

| MCP (Model Context Protocol) | Anthropic | Agent ↔ 工具连接 | 通过 JSON-RPC 标准化工具调用，大幅减少「解释工具怎么用」的 Prompt Token |

| A2A (Agent-to-Agent) | Google ，已捐 Linux 基金会 | Agent ↔ Agent 点对点编排 | 通过 Agent Cards 实现能力交换，定义了「 Agent 发现其它 Agent 」的标准 |

| ACP (Agent Communication Protocol) | IBM | 基于 Broker 的消息代理 | 中间人模式，减少点对点复杂度 |

| ANP (Agent Network Protocol) | 社区 | 去中心化 Agent 市场 | 可信 Agent 发现与能力协商 |

但这些协议目前解决的都是「怎么找 Agent 」「怎么连 Agent 」的问题——还没有一个协议在解决「 Agent 连上之后该说什么、该说多少」的问题。

PACT 论文的意义正在于此：它试图定义的是通信的内容层，而不是传输层或发现层。这和 TCP/IP 的四层模型类比很恰当：

  • A2A/ACP/MCP 解决的是「传输层」和「应用层」——数据怎么传、 Agent 怎么发现
  • PACT 试图解决的是「表示层」——数据该长什么样

就像 HTTP/2 引入头部压缩不是锦上添花而是让 Web 可以规模化的基础技术一样， Agent 通信内容压缩也不会是可有可无的优化——它是 Agent 数量从 5 个增长到 500 个的前提。

七、三点行动建议 链接到标题

如果你正在搭建或运营多 Agent 系统，以下三项检查是立即可执行的：

1. 审计你的 Agent 通信日志 链接到标题

随便抓一个多 Agent 任务的完整对话历史，数一数：有多少内容是冗余的？有多少 Token 是下游 Agent 根本用不上的？有多少「谢谢你的分析」「好的，让我来处理」这种社交礼仪在浪费 Token ？

2. 隔离 Thinking Trace 链接到标题

如果 Agent 使用了推理模型，确保思维链在传给下游之前被剥离。不要把「嗯，让我想想…」塞给下一个 Agent——它不需要知道你是如何纠结的。

3. 用结构化状态替代自然语言聊天 链接到标题

如果你在用 LangGraph ，你已经在做这件事了——但要确保 state schema 的设计是收敛的（只包含下游需要的信息），而不是扩张的（什么信息都往里扔）。如果你在用 CrewAI 或 AutoGen ，考虑在 Agent 之间插入一个类似 SupervisorAgent 的过滤层。

结语 链接到标题

2023 年的问题是「怎么让多个 Agent 一起工作」。

2024 年的问题是「怎么让多个 Agent 高效地一起工作」。

2025 年的问题是「怎么让 1000 个 Agent 高效地一起工作」。

2026 年， PACT 和 SupervisorAgent 这两篇论文告诉我们：答案不在于更好的编排——在于更少的废话。

Agent 通信协议可能是下一个基础设施级的机会。就像 TCP/IP 定义了互联网节点如何握手，Agent Communication Protocol 的「表示层」将定义 AI 代理如何在群体中高效协作。 而 PACT 这篇论文，可能是这个方向上最早的一块里程碑。

参考来源：

  • Chen Huang et al., What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems, arXiv: 2606.05304, 2026-06-06. SUTD.

  • Stop Wasting Your Tokens: Towards Efficient Runtime Multi-Agent Systems, ICLR 2026. SupervisorAgent.

  • A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP, arXiv: 2505.02279, 2025.

  • Anthropic, Claude Code Dynamic Workflows, 2026.

  • OpenAI, Codex Agent Architecture, 2026.

  • PACT 开源实现： https://github.com/iNLP-Lab/PACT