【LLM-Agent】【论文分享】LLM agent中的communication

Multi-agent使用的前提是：为了吃下长文本NNN，必须切分给www个 Agent（解决容量问题）。但是分给多个agents之后能不能加速呢？这要取决于任务类型。有的任务（k-hop）天生就是串行的，神仙也难加速。有的任务（recall）由于内部扫描attention看一眼就好了，所以不用agent加速。有的任务（State Tracking）是可以并行的，可以加速。对于可并行的任务，怎么组

鸿鹄一夏

854人浏览 · 2025-12-01 16:23:46

鸿鹄一夏 · 2025-12-01 16:23:46 发布

今天介绍：Benefits and Limitations of Communication in Multi-Agent Reasoning
这篇文章是ICLR2026的一篇在审，它的逻辑可能是：
“定义问题（数学化） $\rightarrow$ 寻找理论极限（最优解） $\rightarrow$ 分析为了达到极限必须付出的代价（通信成本）。

分布式计算：在保证结果正确的前提下，通过增加处理器数量（Parallelism）来尽可能获得加速比（Speedup）。

本文的本质就是把经典的“分布式计算理论”套用到了“大模型智能体”上，但是智能体的内部的“处理器”transformer，而不是CPU，所以在结论与传统计算截然不同。

我们不看具体分析方式，但是里面的结论很有趣，在此和大家分享。

背景

Chain-of-thought (CoT) prompting 想必大家都不陌生，它是通过让模型输出逐步推理过程，来提升模型在复杂任务上的表现。
但是如果上下文很长，或者问题很复杂，那么LRM的推理能力就会下降。
于是一个很自然的想法是：
把任务拆成很多更小的部分，交给不同的 agent 处理，各自解决一部分，再通过交流、协调或投票机制把结果组合起来，得到一个更强的整体解。我们知道多agent肯定可以解决context不够长的问题，但是我们也想知道这能不能让推理速度变快？以及它会带来多少的通信成本？

这篇文章探讨：

From an algorithmic perspective, are there tasks that provably benefit from communication and dynamic resource allocation in multi-agent reasoning systems?
即“投入更多 Agent 和通信量（一些任务的agent之间需要通信）”到底能不能换来“推理速度（深度）的提升”？

设定的MAS：

把大输入切分给不同 LLM（agent） → 每个 LLM 处理一块 → 通过通信协作 → 最后一个 manager 输出结果。
例子：用 10 个 agent 每人读 1 万 token，共同总结一个 10 万 token 文档。

由于不同问题的依赖不同，于是论文针对不同任务类型来解读一下它的agent砸进去有没有用。

Task 1：Recall

这类任务就是给你一堆键值对（key–value pairs），让你找某个 key 对应的 value。
最典型的例子就是让你从超长文档里把一个答案准确找出来。

多智能体做法：把文档切成几段，交给不同的 agent。谁先找到答案就喊一声，manager 负责公布最终结果。

通信成本 O(1)：
只需要“找到答案的那一个 agent”开口，其他 agent 完全不需要交流，所以和 agent 数量无关。
推理深度 O(1)：
大家同时扫描自己的 chunk，采用attention，就能确认有没有那个 key，不需要多轮讨论。

能无限扩展上下文长度。但如果上下文够大了，就不需要那么多agent。

Task 2：State Tracking

这类任务的特点是：你读到一个符号，就要更新当前状态；最终状态取决于前面所有符号。

实体跟踪→“it” 指代的实体会随着上下文变化
奇偶校验：读一个 1 就翻一次状态

乍看之下，这种任务好像只能串行做（你得先看前面 N−1 个符号才能知道当前状态），所以单模型做通常是 深度 Θ(N)。

但论文证明：
这种任务其实可以并行化，只是要用通信换速度。

创新点：做法利用了前缀和（Prefix Sum）思路：把输入分给不同 agent，各自先算“自己的局部状态”，再按树状结构逐层合并（类似平行前缀和算法）。这种方式采用一种层级化的方式去communication，而不是扁平化的讨论组。在算法理论上，扁平化的“Majority Voting”是无效的（Paper 里证明需要指数级的 Agent才能达到相似的准确率），只有层级化的结构才能在保证质量的前提下加速。
以下 $N$ 是总任务量， $w$ 是 Agent 数量。

通信成本 Θ(w)：
agent 越多，大家之间需要的合并通信越多。
推理深度降为 O(log w + N/w)：
用更多 agent 换更短的推理时间，比单模型的线性深度快得多。

这是“可以通过多智能体真正加速”的任务类型。用agent换推理时间。

Task 3：k-hop Reasoning（多跳推理）

典型例子：
“找出 A 的老板是谁；再找老板的老板是谁；再找下一层是谁……”
也就是一步依赖一步的链式推理。

这种任务麻烦在于：
你下一步要查的东西，必须等上一步结果出来才知道。

在多智能体环境里，事实（facts）被切分给不同 agent 保存：

假设 A→B 在 agent1
B→C 在 agent2
C→D 在 agent3
……

问题是：
agent1 在算出 “A 的老板是 B” 之后，根本不知道“下一跳在哪个 agent 手里”。
所以它只能把结果丢给 manager，让 manager 再广播给所有 agent，看看下一跳在哪。

最坏情况就是：每一步恰好落在不同 agent 身上，于是你必须：

找 A 的老板
广播
找 B 的老板
广播
找 C 的老板
广播
……

这就是所谓的 Iterative Lookup（迭代查找）。这种情况下：

通信成本 Θ(k)： 每跳都必须通信。
推理深度仍然是 O(k)： 不管你加 5 个 agent 还是 5000 个，每一跳都等上一跳。
意义： 多智能体解决不了这类任务的“算得快”。agent只能缓解存不下的问题。

直觉上：这是“天生串行、加多少 agent 都无法加速”的任务类型。

总结

Multi-agent使用的前提是：为了吃下长文本 $N$ ，必须切分给 $w$ 个 Agent（解决容量问题）。但是分给多个agents之后能不能加速呢？这要取决于任务类型。

有的任务（k-hop）天生就是串行的，神仙也难加速。
有的任务（recall）由于内部扫描attention看一眼就好了，所以不用agent加速。
有的任务（State Tracking）是可以并行的，可以加速。

对于可并行的任务，怎么组织 Agent（通信结构）是关键。

乱组织（Majority Voting） $\rightarrow$ 没用
好组织（Prefix Sum Tree） $\rightarrow$ 极大加速（Depth 变小）

但是加速不是免费的，代价是通信量（Total Communication）会随着 Agent 数量线性增加。
所以对于Multi-agent的使用，我们应该先看需不需要（任务类型；文本长度）；如果是State Tracking 任务，那么别搞扁平化，去搞树状通信结构。

后续思考：也许可以争对State Tracking / Complex Logic 这类“可并行化”的任务，看看如何自适应的调整agent数量。如何限制communication传输的内容，减少token overhead的风险。

任务类型	代表性任务	特点	通信开销	深度 (时间复杂度)	结论
Type 1: 联想回忆（Associative Recall）	Key-Value 检索 / 大海捞针	任务可完全并行化	O(1) (极低)	O(1)	纯收益：增加 Agent 可以线性扩展处理的上下文长度，且不增加时间成本
Type 2: 状态追踪（State Tracking）	奇偶校验（Parity） / 代码执行	需要多步推理，但在合并结果时可以并行（类似前缀和 Prefix Sum）	Θ(w) (随 Agent 数量增加)	O(logw + N/w)	Trade-off：可以通过增加 Agent 和通信量来换取更快的推理速度（减少深度）
Type 3: k-hop 推理（k-hop Reasoning）	多跳问答 / 逻辑链	下一步的输入依赖上一步的输出	Θ(k) (随跳数增加)	O(k)	无加速：增加 Agent 无法减少推理时间，必须串行通信。多智能体仅能帮助处理更大的知识库