多个AI智能体一起解决一个问题，开会之前要不要把全部材料都发给每个人？

你有没有遇到过这种开会场景：公司要做一个跨部门项目，三个小组分别去研究不同的资料，最后汇总给项目负责人做决策。

正常情况下，三个小组会各自写一份报告，提炼出重点，再交给负责人。负责人读三份报告，然后做判断。

现在想象一下另一种做法：三个小组不写报告，直接把自己翻过的所有文件，原始资料、笔记、草稿，一股脑全部塞进负责人的办公室。负责人现在有三间屋子的资料堆在面前，还要在这堆纸里找到真正有用的那几页，才能开始做决策。

这听起来很荒谬，但这恰好是当前大语言模型多智能体系统正在面临的真实问题。

**AI智能体之间怎么“说话”，决定了整个系统的效率和准确率**

大语言模型驱动的多智能体系统，已经成了处理复杂任务的常见做法。

LLM多智能体系统*：由多个大语言模型（可以是同一个模型的不同实例）组成的协作团队，每个智能体负责任务的一部分，彼此之间需要交换信息才能完成整体目标。

比如FanOutQA这个基准测试里有一道题：“美国五个国土面积最大的州，最高海拔分别是多少？”要回答这个问题，得先从一篇维基百科文章里找出这五个州是谁，再分别去查每个州的最高海拔，这需要翻五篇文章。一个比较自然的做法是找四个智能体分头去读文章，然后把各自的发现汇总给一个负责整合答案的智能体。

问题就出在“汇总”这一步该怎么做。

过去的做法基本是靠文字。每个智能体读完资料后，写一段文字总结，发给负责汇总的那个智能体。这个办法看起来挺合理，文字简洁，人类也看得懂。但麻烦的是，文字是离散的符号，大语言模型内部真正“思考”时用的其实是连续的、信息密度更高的隐藏向量，把这些丰富的内部表示压缩成几句话，必然会丢掉一些东西。而且，生成文字这件事本身很慢，因为模型得一个字一个字往外蹦，这是自回归生成的硬性代价。论文里给了一个具体数字：让Qwen 3 8B这个模型生成三份文字消息，中位数耗时73.2秒。

这就是为什么最近有研究开始尝试一种新思路：不发文字，直接发送模型内部的“记忆痕迹”，也就是KV缓存。

KV缓存*：Key-Value Cache，大语言模型在处理一段文本时，会在每一层网络里为每个词（更准确说是每个“位置”）存一份键值对，用来记住上下文，供后续生成时参考。可以理解成模型读完一段材料后留下的详细笔记，比最终写出来的总结报告信息量大得多。

这类方法叫做“潜在通信”（latent communication），其中一个代表性工作叫LatentMAS，它让智能体不再生成文字，而是在隐藏表示上做“潜在推理步”，推理完之后，直接把整段KV缓存发给下一个智能体。这样做确实比文字快很多，论文提到LatentMAS在一些推理和代码任务上能把延迟降低4倍左右，准确率还能提高几个百分点。

但这里出现了一个新问题，而这正是本篇论文要解决的核心矛盾。

**全量发送KV缓存，等于把所有原始资料一股脑塞给负责人**

设想一下，三个智能体分别读了三篇不同的文章，每人攒了一大堆KV缓存。如果要把这些缓存原样发给负责汇总的智能体，会发生什么？

负责汇总的那个智能体，现在要同时承载三份完整的“阅读记忆”，加上它自己原本要处理的提示词。它的上下文窗口（也就是模型一次能处理的信息总量）迅速被挤满。论文把这个现象叫做“上下文再膨胀”（context re-expansion）。

这就好比，原本分头去读资料的意义，就是为了让每个人只需要消化一部分内容，减轻单个人的负担。但如果最后还是要把所有人读过的全部原始材料堂堂皇皇地搬到负责人桌子上，那“分头去读”这件事的意义就被架空了，负责人要处理的信息总量,跟没有分工时几乎一样多,甚至因为搬运和堆叠的开销,反而更麻烦。

论文的实验证实了这个直觉。在FanOutQA的测试设置下，用Qwen 3 8B这个模型，如果三个智能体把完整的KV缓存都发给负责汇总的智能体，上下文直接爆掉，负责人根本没有足够空间进行自己的生成任务,这种情况在每一道测试题上都发生了。

这里有个关键认知：

**压缩传输的字节数，不等于减少负责人要处理的信息量。**

就算你把每一份KV缓存压缩得再小、量化得再狠，负责人依然要把每一个“位置”（也就是原文里的每一个词或后续生成的每一步）都加载进自己的上下文窗口里。字节数小了，但“位置数”没有减少，而正是“位置数”在撑爆上下文、拖慢注意力机制的效率。这就像你把三间屋子的纸质文件扫描成电子版压缩打包,文件变小了，传输变快了，可负责人还是要把这三万页全部打开浏览一遍才能找到有用信息，节省下来的只是传输时间，没有节省负责人阅读和处理的工作量。

**解决思路：让负责人先说清楚自己要什么**

论文提出的核心思路其实很朴素,甚至朴素到让人觉得“这不是显然的吗”。

既然负责汇总的智能体不需要别人读过的全部内容,只需要跟自己任务相关的那一部分,那为什么不让负责人先把自己的需求说出来,再让发送方根据这个需求去挑选该发送什么？

论文把这个思路称为“接收者条件通信”（receiver-conditioned communication）。

接收者条件通信*：一种通信协议，消息的内容不是由发送方单独决定的，而是取决于接收方当下真正需要什么信息。接收方会传递一个“查询”（query）给发送方，发送方据此过滤和压缩自己要发送的内容。

这个设计思路，如果类比到开会场景里会非常直观。还是三个小组去调研不同资料的场景,如果负责人在会议开始前就告诉三个小组:“我这次要重点关注成本和风险这两方面,其他的先不用细讲”,那三个小组回来汇报的时候,自然会优先挑出跟成本、风险相关的部分来讲,而不是把三屋子资料全搬过来。如果没有这个前置的沟通,三个小组只能按照自己原来调研任务的侧重点去写报告,很可能漏掉负责人真正在意的那部分内容,或者反过来塞进去一堆负责人根本不需要的细节。接收者提前说清楚需求，是避免双方信息不对等、避免浪费精力去传递无用信息的关键一步。

论文把这套思路具体实现成了一个叫CacheBack的方法。

**CacheBack：用注意力分数给内容打分，挑出最该发的那部分**

CacheBack这个名字拆开看,其实挺形象,它的工作方式是“回头看”(back)发送方的缓存(cache),用接收方的查询去给缓存里的每个位置打分,挑出分数最高的那部分发送。

具体怎么打分呢？

发送方处理完自己的材料后，会在后面接上接收方传来的查询语句，然后计算这个查询对发送方缓存里每个位置的“注意力”。

注意力*：Transformer模型里的一种机制，衡量当前处理的内容对之前每一个位置的“关注程度”，关注度越高，说明这个位置对当前任务越重要。

这个思路实际上借用了已有的KV缓存压缩技术,论文里提到的一个参照方法叫SnapKV,它原本是用模型自己接下来要生成的内容去给之前的缓存打分,CacheBack的创新在于，把这个打分的“提问者”换成了接收方的查询，而不是发送方自己接下来要生成的内容。

但论文发现,单纯把查询里每个词的注意力取平均,会有一个隐藏的问题。

设想一道查询里包含好几层意思，比如“这五个州里，哪个州的最高海拔最高，哪个州人口最多”。如果某个资料位置只跟“海拔”这个词高度相关，跟其他词关系不大，那在平均之后，这个位置得到的分数会被“人口”“哪个州”这些不相关词的低分拉低，最终排名可能还不如一个跟所有词都有点模糊相关、但哪个都不特别突出的位置。论文配的那张图里举了个例子：位置A只被某一个查询词强烈关注，位置B被每个查询词都轻微关注，结果平均法会把B排得比A还靠前，尽管A才是真正该选的那个。

这就好比,如果你让一个客服系统根据顾客留言里所有词的平均重要性去打标签，一句“空调不制冷，但是服务态度很好”，可能会因为“服务态度很好”这几个字稀释了整句话的情绪强度，导致系统误判这是一条中性甚至正面的反馈，而真正该被优先处理的“空调不制冷”这个关键信息反而被平均掉了。如果不针对局部的强烈信号做特别处理,就会漏掉那些只在局部表现突出、但整体平均不起眼的重要内容。

CacheBack的解决办法是,给那些“在局部特别受关注，但整体平均不起眼”的位置额外加分。

它引入了一个修正系数，比较“平均之前”和“平均之后”的注意力差异,如果一个位置在平均前后的注意力差异很大(说明它只被某几个查询词特别关注),就给它乘上一个更高的加权系数。这个修正系数的数学形式论文里写得很清楚,简单理解就是：先对每个查询词单独算注意力，再看这些注意力彼此之间的差异有多大，差异越大(方差越大)，说明这个位置的重要性越依赖于查询里的某个具体部分，就越应该被优先保留。

**诊断实验：接收方查询真的能帮上忙吗？**

在正式上场测试之前，论文团队先做了一组小规模的诊断实验，用13个FanOutQA任务,改变Qwen 3模型的大小(1.7B、4B、8B、32B)，看看不同的筛选方法在不同压缩比例下，能保留多少“标准答案要用到的证据”。

结果挺有说服力。在把位置数压缩到原来的八分之一时，最强的“不看接收方需求”的基线方法只能保住68%的证据，而CacheBack能保住93%。压缩到128分之一(也就是只留原来不到百分之一的内容)时，CacheBack还能保住25%的证据，而其他方法只剩1%到3%。

还有一个有意思的发现：模型越大，接收方查询的指导作用越明显。

从1.7B到32B,查询对答案所在位置的识别能力明显增强,衡量这个的指标叫“金标答案词百分位数”,数值从0.61升到0.76,意味着大模型更擅长根据一句查询，精准定位到真正该看的那部分内容,而不是被无关内容分散注意力。

这个现象其实也符合直觉。模型越大，理解语义关联的能力越强，就越能准确判断“这个查询真正在问什么”,也就能更精准地从一堆资料里挑出该挑的那部分。小模型在这方面天然要弱一些，这也提示我们，CacheBack这类依赖注意力机制的筛选方法，效果会随着底层模型能力的增长而继续改善。

**真刀真枪的测试：在FanOutQA和LongBench v2上跑一遍**

诊断实验之后，论文团队在两个真实的长文本问答基准上，对比了CacheBack和文字通信的实际表现。

FanOutQA测试的是“并行汇总”结构：三个智能体分别读不同的维基百科文章，再把消息发给一个负责整合答案的智能体。

LongBench v2测试的是“接力传递”结构：四个智能体依次阅读同一份长文档的不同部分，每个智能体收到前一个智能体传来的消息后，再加上自己新读的内容，往下一个智能体传。

LongBench v2*：一个专门测试大语言模型在长文本（10万到24.6万词级别）场景下深度理解和推理能力的基准测试集。

实验结果在FanOutQA上相当亮眼。拿Qwen 3 8B来说，同等大小模型的文字通信方式，严格准确率是40.7%，中位完成时间是612秒。换成CacheBack，用4倍压缩比，准确率提升到55.3%，整整高了14.7个百分点，而中位完成时间降到192秒，快了3.2倍。

**也就是说，CacheBack在去掉75%原本要传给接收方的内容的同时，反而让答案更准、速度更快。**

这个结果乍一听有点反直觉，少发信息怎么还能更准确？但背后的逻辑其实不难理解。文字生成本身是逐字进行的，消息越长，生成耗时越久，而且在实验的并发测试场景下（50个任务同时跑），文字生成还会导致发送方的GPU排队更严重。CacheBack挑选的是模型已经计算好的内部状态，不需要再逐字生成，所以能在传输更多“有效信息密度”的同时，还省下生成的时间。

论文还专门测了一个指标叫“消息召回率”,衡量的是最终发送出去的消息里，到底包含了多大比例的标准答案所需证据。结果显示，在上面提到的那几个操作点上，CacheBack的消息召回率达到91.5%到95.8%，而同等大小的文字通信只有84.8%到91.1%。这进一步印证了,CacheBack不是靠“赌一把压缩比”蒙对的，而是真的更擅长抓住该传递的信息。

四个不同的模型家族,包括Qwen 3、Ministral 3、Gemma 4、Nemotron Nano 2，在FanOutQA上都表现出类似的规律:CacheBack相比同等大小的文字通信，准确率提高7.3到20.7个百分点，中位延迟降低1.3到8倍。

Mamba*：一种与传统Transformer不同的神经网络架构，在处理长序列时效率更高，Nemotron Nano 2用的就是这种架构和注意力机制混合的设计。

值得一提的是，为了验证“接收方的查询到底有没有用”，论文做了一个对照实验：把接收方真正的问题，换成一个完全不相关的问题，比如“为什么Le Chaton Fat的小企业贷款申请被拒了”，再看结果会怎样。结果很明显,在16倍压缩比下，消息召回率从91%掉到65%，严格准确率从46%跌到23%。这说明接收方查询确实在实实在在地指导筛选过程,换一个不相关的问题，筛选质量会明显劣化,而不是说“随便传点内容过去也差不多”。

在LongBench v2的接力结构上，结果同样支持这个结论。Qwen 3 8B用相对压缩预算、4倍压缩比的设置时，准确率从同等大小文字通信的39.3%提高到54.0%，提升了14.7个百分点，中位延迟从884秒降到237秒，快了3.7倍。

这里值得多说一句接力结构里特有的问题。在这种链式结构里，每个智能体收到的消息，是前面所有智能体层层传递下来的，如果每个环节都不加控制地让消息越传越长，到了第四个智能体那里，消息长度理论上会随着链条长度线性增长，拖慢整个系统。论文为此设计了两种预算控制方式：一种是“相对预算”，每个智能体加入的新内容只按比例保留一部分；另一种是“固定预算”，消息长度封顶，一旦达到上限就不再增长，哪怕后面还有更多新内容要塞进来。两种方式都能有效遏制消息无限膨胀，相对预算在实验里整体表现稍好一些。

**代表性数据汇总**

| 模型（压缩比） | 文字准确率 | CacheBack准确率 | 提升 | 文字延迟 | CacheBack延迟 | 加速比 |

|---|---|---|---|---|---|---|

| Qwen 3 8B（4倍） | 40.7% | **55.3%** | +14.7pp | 612秒 | **192秒** | 3.2倍 |

| Ministral 3 14B（32倍） | 38.7% | **59.3%** | +20.7pp | 1537秒 | **193秒** | 8.0倍 |

| Gemma 4 12B（4倍） | 52.0% | **59.3%** | +7.3pp | 603秒 | **201秒** | 3.0倍 |

| Nemotron Nano 2 12B（8倍） | 38.7% | **50.0%** | +11.3pp | 131秒 | **102秒** | 1.3倍 |

**这个方法的边界在哪里**

论文作者挺坦诚地指出了这个方法的局限。

CacheBack故意设计得很简单，不需要额外训练，为的就是单纯验证“让接收方说出需求”这件事本身是否有用，而不是去堆砌一个复杂的学习模块来提升效果。这意味着它用的打分规则是固定的，混合架构模型里也只用了全局注意力层参与打分。换句话说，这只是一个起点，而不是这条路的终点。学习一个更智能的打分规则，或者利用模型更多的内部状态信息，很可能还能进一步提升筛选效果。

另外，论文里设定接收方的查询就是任务本身的问题，而且只在发送方计算完成后问一次，这其实简化了真实场景里可能出现的交互方式。真实世界里，接收方完全可能针对某个还没弄清楚的细节，追问发送方一次，或者先要个简要版本，发现不够用再要更详细的内容。这种动态来回的查询方式，论文没有涉及，留给了未来的研究。

还有一点值得记住，潜在消息是不可读的,它不是人类能直接看懂的文字，这意味着调试和审查会变得更麻烦，同时也带来一个值得警惕的问题:发送方原本私有的上下文信息，经过这种方式传递出去之后，并没有任何加密或隐私保护的保证。

Q&A

Q1：CacheBack是什么？

A：CacheBack是一种让AI智能体之间进行“接收者条件通信”的方法，接收方先把自己的信息需求（查询）告诉发送方，发送方根据这个查询，用注意力打分挑选出最相关的内部状态进行发送，而不是把全部内容一股脑发过去。

Q2：CacheBack相比直接发文字消息有什么优势？

A：在FanOutQA测试中，CacheBack能去掉75%的冗余内容，同时准确率提升14.7个百分点，完成任务的中位延迟降低到原来的三分之一左右，因为它不需要像文字那样逐字生成，而是直接复用模型已经计算好的内部状态。

Q3：为什么直接发送完整的KV缓存不是个好办法？

A：因为接收方要同时承载多个发送方的全部内部状态，加上自己原本的任务内容，很容易导致上下文窗口被挤满甚至溢出，实验中就出现了接收方因此没有足够空间完成自己任务的情况，这种现象被称为“上下文再膨胀”。