微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 多智能体AI系统的"信息传递之道":新加坡科技设计大学揭示如何让AI团队用更少的话干更多的事

多智能体AI系统的"信息传递之道":新加坡科技设计大学揭示如何让AI团队用更少的话干更多的事

2026-06-17 09:17
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-06-17 09:17 科技行者

这项由新加坡科技设计大学研究团队完成的研究,于2026年6月以预印本形式发布,论文编号为arXiv:2606.05304。有兴趣深入了解的读者可通过该编号在arXiv平台查阅完整论文。

当我们谈到AI大模型的时候,脑海中浮现的往往是一个单独的"超级大脑"在思考和回答问题。但现实中,越来越多的AI系统其实更像一支分工明确的团队——有人负责制定计划,有人负责挑错,有人负责修改,有人负责最终输出答案。这种由多个AI共同协作完成任务的方式,被研究者称为"多智能体系统"。

然而,这支AI团队有一个你可能没想到的烦恼:它们彼此之间怎么说话,怎么传递信息,直接决定了整个团队的效率和花费。就像一个施工团队,如果每个工人在交接工作时都要把自己今天所有的心路历程、犯过的错误、反复权衡的过程全都写成一本书递给下一个工人,那下一个工人光是读这本书就已经精疲力竭,根本没有多余的精力好好干活了。

新加坡科技设计大学的研究团队正是发现了这个问题,并花了大量精力系统地研究:这支AI团队里,每个成员到底应该把什么内容传递给下一个成员?他们的答案,就是这篇论文的核心——一个名为PACT(可以理解为"行动状态通信协议")的全新方案。

一、当AI团队变成"话痨联盟"

要理解这个问题,先从一个日常场景切入。假设你在一家餐厅打工,厨房里有四个岗位:点菜员、厨师长、主厨和摆盘师。每次一道菜要出餐,点菜员需要把顾客的需求告诉厨师长,厨师长再指导主厨,主厨做完传给摆盘师。

现在问题来了:点菜员在交接时,是把顾客说的原话、自己的全部思考过程、甚至自己当时心里的犹豫和猜测都一股脑说给厨师长听,还是只说"3号桌要一份不放香菜的红烧肉"?显然后者更高效。但如果点菜员只说"做好了",厨师长根本不知道该做什么菜,那也不行。

现实中的多智能体AI系统,面临的正是这个困境。每个AI在完成自己那部分工作后,会产生大量的输出内容,其中包括它思考问题的全过程(有点像人类的"内心独白")、各种反复推敲的痕迹、最终的结论,以及真正有用的工作成果。如果把这些内容全部打包传给下一个AI,下一个AI就必须先把这一堆信息全都读完,才能开始干自己的活。

更糟糕的是,在多轮对话中,这些信息会不断累积。第一个AI的输出传给第二个,第二个的输出传给第三个,到了第四个AI,它面对的可能是一个无比庞大的"聊天记录",里面夹杂着之前所有AI的思考碎片。这不仅让系统变慢、变贵,有时候信息太多甚至会让AI"消化不良",反而做出更差的答案。

研究团队把这个问题量化得相当具体:在某些设置下,使用"把所有内容都传过去"这种方式,一个问题要消耗的文字量(token,大致可以理解为计费单位)高达十几万甚至更多。而聪明地只传递关键信息,同样的问题可能只需要几千字就够了,效果却相差无几甚至更好。

二、五种传话方式的大比拼

为了找到最优解,研究团队设计了一个系统性的对比实验。他们选取了两种典型的多智能体合作模式,在三种不同规模的AI模型上,测试了五种不同的信息传递方式。

两种合作模式分别代表了截然不同的场景。第一种叫"证据分拆型对话":两个AI各自掌握解题所需信息的一部分,必须通过交流才能拼凑出完整答案,就像两个人分别看到了谜题的上半张和下半张,需要互相描述自己看到的内容。测试题目来自两个多跳问答数据集,每道题的答案需要综合多个文段才能得出。第二种叫"流水线型管道":四个AI依次接力工作,分别扮演规划者、审核者、修改者和解答者的角色,上一个的输出直接成为下一个的输入。测试内容覆盖了数学推理(包括颇具难度的AIME竞赛题)、科学推理(研究生级别的问答题)和常识问答。

五种传话方式则覆盖了目前实践中最常见的选择。"全文转发"是最直接的做法,把AI生成的所有内容,包括思考过程,原封不动传递下去。"精简生成"是让AI直接用更简洁的模式输出,不产生冗长的内部推理。"仅结论"是只把最终答案或结论传给下一个AI,中间过程一概不传。"简短摘要"是让AI自己把自己的输出总结成一段简短的话再传过去。"仅成果"是只传递AI这个角色对应的核心工作产出,比如规划者只传他的计划,审核者只传他的审核意见,不附加任何说明。

实验结果相当有趣,可以用"没有一种方法是万能药"来概括。"全文转发"在所有情况下几乎都是花费最高的,而且表现并不是最好的,说明大量的思考过程传递过去基本就是在浪费——下一个AI并不需要读懂上一个AI的全部内心戏。"精简生成"在证据分拆型对话中表现不错,但在流水线管道中明显偏弱,因为中间环节的AI(比如审核者)需要输出真正有深度的审核意见,简单压缩就会让内容失去价值。"仅结论"在流水线中表现相对稳定,因为管道里每个角色的职责是固定的,下游AI通过角色设定就能猜到上游在做什么;但在证据分拆对话中表现很差,因为接收方不仅需要结论,还需要知道对方掌握了哪些证据、还缺少哪些信息。"简短摘要"表现波动最大,在某些情况下不错,在某些情况下莫名其妙地差,说明让AI自由发挥写摘要是靠不住的。"仅成果"的表现颇为微妙——它在证据分拆对话中有时能取得最好的准确率,在流水线中也相当有竞争力,然而它有一个致命缺陷:因为去掉了所有铺垫和说明,AI搞不清楚对话是否结束,导致对话轮数大幅增加,有时候反而比其他方式多用了三倍的信息量。

这个发现指向了一个核心洞察:真正有价值的信息是"以行动为中心的",也就是"你做了什么、基于什么依据、得出了什么结果",但光有这些内容还不够,还需要一个清晰的框架把它们组织起来,让接收方能准确理解这些信息意味着什么。

三、PACT协议:给AI团队制定一套"交接手册"

基于上述发现,研究团队提出了PACT协议。把它理解成一套标准化的工作交接手册会非常直观——不管哪个AI完成了什么工作,向下一个AI汇报时都必须按照同一个格式填写三个栏目。

第一个栏目叫"行动",用来说明自己做了什么,或者下一个AI需要做什么。这一栏的存在让交接变得明确,接收方不需要猜测发送方的意图。第二个栏目叫"状态",用来记录支撑这次行动的证据、观察到的环境信息或者工具调用的反馈。这一栏确保接收方拿到的不是一个凭空冒出的结论,而是有据可查的信息。第三个栏目叫"成果",就是这次行动的实际产出,比如检索到的事实、修改后的方案,或者工具执行的结果。

关键在于,PACT只约束什么东西可以进入AI们共享的"聊天记录",它完全不干涉每个AI内部怎么思考。每个AI仍然可以在自己的"草稿纸"上进行任意复杂的推理和反复权衡,只是在把结果递出去之前,需要按照这个格式提炼一下,把冗余的内部过程过滤掉。换句话说,PACT划定了"私人计算"和"公开通信"之间的边界。

这个设计有几个值得注意的特点。首先,它完全不需要重新训练AI模型,也不需要改造现有的多智能体系统框架——只是在每次AI输出后加一个"格式化提炼"的步骤。其次,它对不同场景有足够的灵活性:在证据分拆对话中,三个栏目可以写得比较详细;在流水线管道中,由于角色分工已经由系统结构决定,"行动"栏可以写得更简洁,让"成果"栏承担更多内容。这种灵活性让同一套协议能适用于截然不同的多智能体架构。

四、实验数据说话:PACT的实际效果

研究团队用前面描述的六个测试基准,对PACT和三个对比方案进行了全面比较。三个对比方案分别是"智能体链"(每个AI只读上一个AI的输出,不保留更早的历史)、"文本多智能体"(角色分工明确但用自由格式传递信息,保留完整历史)和"多智能体辩论"(多个AI独立给出答案然后互相辩论,最后投票决定)。

在证据分拆型对话测试中,PACT在几乎所有模型规模和测试集上都同时实现了更高的准确率和更低的信息消耗。以最大的32B模型在HotpotQA测试集上的结果为例,PACT的F1得分达到61.5,而"多智能体辩论"是60.3,"智能体链"是54.2,"文本多智能体"只有50.1。与此同时,PACT每道题平均消耗约4821个token,而"多智能体辩论"需要12258个,"文本多智能体"需要8857个,"智能体链"需要5871个。PACT用最少的信息量取得了最好的成绩。

在流水线管道测试中,PACT同样表现出色。在数学推理的AIME2025题目上,使用32B模型时,PACT的准确率达到72.7%,高于"多智能体辩论"的75.8%,但相差不多;而"文本多智能体"只有60.4%,"智能体链"是71.2%。信息消耗方面,PACT每道题用约30970个token,而"多智能体辩论"需要高达157744个,是PACT的五倍多。在科学推理的GPQA-Diamond测试中,PACT用32B模型达到了68.5%的准确率,是所有方法中最高的,消耗的token也是最少的。

从整体统计来看,PACT在所有基准和模型规模上,平均比各基准方案减少了38.7%的token消耗,同时保持或提升了任务表现。

还有一个有趣的规律:模型规模越大,PACT的效果越突出。从8B到32B,PACT在流水线测试中的平均token消耗下降了21.1%,同时平均准确率提升了4.2个百分点。而其他方法在模型变大后,token消耗并没有明显下降,甚至有上升趋势。这说明更强大的AI模型更善于利用精简的信息,不需要看到上一个AI的全部思考过程就能接着干好自己的活;反过来,单纯把模型规模做大,并不能自动解决信息冗余的问题,必须在通信协议上做出约束。

研究团队还专门做了一个"拆零件"实验,来验证PACT三个栏目各自的贡献。在HotpotQA测试中,使用8B模型,完整的PACT(三个栏目都有)F1得分是69.9。去掉"行动"栏,只保留状态和成果,得分降到64.9,下降了5分。去掉"状态"栏,只保留行动和成果,得分降到65.2,下降4.7分。如果两者都去掉,只传递成果,得分降到64.3,而且token消耗反而增加了12.9%——因为没有明确的行动说明,接收方产生了困惑,需要更多轮次的交流来澄清。这说明三个栏目缺一不可,行动说明让接收方知道该怎么用这条信息,状态描述让接收方知道信息从何而来,成果本身才是真正被传递的内容。

五、从实验室走向真实战场:在代码助手上的验证

光在研究用的实验平台上表现好还不够,研究团队进一步把PACT移植到了两个真实世界的AI代码助手系统上进行验证。这两个系统都是用来自动解决真实GitHub代码仓库里的Bug问题的,测试平台是SWE-bench Verified,包含500个来自真实开源项目的编程问题。

第一个系统是OpenHands(使用其CodeActAgent模式),第二个是SWE-agent。两者都采用14B规模的模型。研究团队把PACT实现成一个"代理钩子"——不修改这两个系统的任何代码,只在每次AI输出之后和读取历史记录之前悄悄介入,按照PACT格式重写相关内容。具体来说,每次AI在执行工具操作之前,需要先输出一个结构化的摘要块,包含"需要执行的行动"、"观察到的状态"和"预期效果";系统在读取历史记录时,会把之前所有的AI输出替换成只保留这个摘要块和工具调用记录,删掉中间的推理过程和自由格式的说明文字,但工具执行的结果(比如代码运行的输出)保持不变。

在OpenHands上,PACT的效果令人关注。原始系统在500个问题中解决了97个,解决率19.4%。加上PACT之后,解决了115个,解决率提升到23%,多解决了18个问题,提升了约18.6%。同时,每次AI调用生成的内容平均减少了5.3%,每解决一个问题消耗的总token从382万降到343万,减少了10.3%。换句话说,PACT不仅让这个系统更便宜,还让它更厉害了。

在SWE-agent上,结果略有不同。解决率从25.6%微降到24.2%,减少了7个问题,在统计上属于可以接受的小幅波动。但效率的提升非常显著:输入token从3.146亿降到1.56亿,减少了50.4%;每解决一个问题消耗的总token从246万降到130万,减少了47%。对于这个系统来说,PACT几乎以一半的成本实现了相近的效果。

两个系统的结果共同说明了一件事:PACT背后的原理——只把行动相关的信息放进共享历史——在真实复杂的工程场景中同样成立,而且不需要对系统做任何深层改造,只需要在信息流转的节点上加一个轻量的过滤和格式化步骤。

六、这项研究的边界在哪里

研究团队对自身工作的局限性相当坦诚。PACT最适合那些共享对话历史是主要成本来源的多智能体场景,对于交互轮次很少或者AI之间不需要反复读取历史记录的系统,它的收益就不那么明显了。另外,实验虽然覆盖了两种不同的多智能体拓扑结构和两个真实编程助手,但并没有涵盖所有可能的多智能体协作形式,比如完全开放式的辩论、需要大量工具调用的复杂规划任务,或者根据情况动态调整成员组成的智能体网络。这些场景下PACT是否同样有效,还需要进一步探索。

说到底,这项研究揭示的是一个朴素但容易被忽视的道理:在一个团队里,沟通本身是有成本的,沟通的质量比沟通的数量更重要。把所有人的全部思考过程都公开展示给所有人,并不能让团队工作得更好,往往只会让每个人都疲于应付无穷无尽的"阅读作业"。真正高效的团队交接,是把"做了什么、基于什么、得出了什么"说清楚,其余的留在自己脑子里。这个道理对人类团队适用,对AI团队同样适用。

随着多智能体AI系统越来越多地被部署到实际产品中,这项研究提出的问题——AI之间应该说什么——会变得越来越重要。毕竟,当每次AI对话都在产生真实的计算成本,当越来越多复杂任务需要多个AI协同完成,让这支"AI团队"学会高效沟通,就不只是一个学术问题了,而是实实在在影响到产品成本和用户体验的工程问题。有兴趣深入了解这项研究细节的读者,可以在arXiv平台通过编号2606.05304找到完整论文。

Q&A

Q1:多智能体AI系统中"全文转发"信息为什么反而会降低性能?

A:全文转发会让后续每个AI都要处理大量无关的内部推理痕迹和重复内容,就像让厨师长先读完点菜员今天的全部心理活动才能开始工作。这不仅浪费计算资源,过多的干扰信息还会分散AI的注意力,导致在有限的"上下文窗口"内真正有用的信息被稀释,最终让整个系统既慢又贵,效果还更差。

Q2:PACT协议需要重新训练AI模型才能使用吗?

A:不需要。PACT是一个无需训练的通信协议,只在AI输出内容进入共享历史之前加一个格式化提炼步骤,不改变AI模型本身的运行方式,也不改变多智能体系统的整体架构。研究团队在OpenHands和SWE-agent这两个真实系统上验证时,也只是加了一个轻量的代理钩子,没有修改任何底层代码。

Q3:PACT在流水线型和对话型多智能体系统上哪个效果更好?

A:两种场景下PACT都有效,但侧重点不同。在流水线中,PACT主要帮助减少冗余的推理内容,让下游AI直接获取精炼的工作成果;在证据分拆型对话中,PACT还额外解决了"接收方需要知道发送方掌握了什么信息、还缺少什么"的问题,通过明确的行动和状态字段提升了信息交换的质量。实验数据显示,两种场景下PACT都在减少token消耗的同时保持或提升了任务准确率。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-