+29.8pp，四个弱模型组队打爆一个强模型：多Agent编程协作的新范式

一个Claude Code Agent独立理解大型代码库准确率32.3%。四个Claude Code Agent组队准确率62.1%。这还不是最离谱的。最离谱的是四个组队的Agent用的模型版本比单Agent还老一代——单Agent是Opus 4.8组队的是Opus 4.6。弱模型组队打爆了强模型单干。这是Coral Protocol团队在2026年7月30日发布的论文《AgentRadio: Passive Awareness for Long-Horizon Multi-Agent Collaboration》的核心数据。他们在SWE-Atlas QnA上跑了124道专业级代码理解题覆盖11个生产级代码库。每道题平均12.3个评分点错一个就算失败。四个Opus 4.6组队不仅远超单Opus 4.629.8pp还超越了单Opus 4.857.2%。这篇论文回答了多Agent编程领域一个被长期忽视的问题Agent之间的沟通方式比Agent本身的能力更重要。你的多Agent团队本质上是一群聋子现在的多Agent编程系统怎么协作两种方式。一种是阶段式交接——Agent A干完第一阶段的活把结果扔给Agent B干第二阶段。另一种是同步回合制——所有Agent干完一轮停下来开会交流然后开始下一轮。这两种方式有一个共同的问题干活的时候不能说话说话的时候不能干活。想象你在一个四人团队里做代码审查。你正在排查一个数据库连接池泄漏问题查了10分钟突然发现——这个泄漏的根源不是数据库配置而是上游的认证服务在特定条件下会返回重复的token。但你没法立刻告诉正在查认证模块的队友。因为现在不是沟通阶段。你得等到这轮排查结束所有人停下来开会的时候才能说。而你的队友可能已经沿着错误方向排查了20分钟。在AgentRadio之前所有多Agent系统都是这样工作的。这就是AgentRadio要解决的核心矛盾代码理解是一个长时程任务子任务之间高度相互依赖。一个Agent的发现可能彻底改写另一个Agent的工作方向。如果只能等阶段边界才能交流那就等于让四个人戴着降噪耳机各干各的然后每周五下午开一次会。Claude Code单Agent在SWE-Atlas QnA上只能解决32.3%的题目不是因为它不够聪明。是因为一个人排查11个生产级代码库的复杂问题精力根本覆盖不过来。但简单地把任务拆给四个Agent各自干提升也很有限——从32.3%到39.5%只涨了7.2个百分点。因为拆完之后四个聋子还是四个聋子。对讲机比扩音器好用一万倍AgentRadio的解决方案出奇地简单。它给每个Agent装了一个后台对讲机。不是那种需要你放下手里的活、专门拿起对讲机说话的对讲机。而是像办公室里同事在你旁边随口说了一句——你听到了但手没停。技术上AgentRadio提供了三个通信原语第一创建线程。给每个协作场景开一个命名对话频道比如工作日志线程“规划线程”“结果审查线程”。不同的事在不同的频道聊。第二发送消息。非阻塞操作。Agent发完消息立刻继续干活不用等任何人回复。消息可以特定队友。第三后台监听。这是整个设计的灵魂。一个独立的后台进程持续监听所有线程当有消息你的时候在下一次工具调用的间隙把消息浮上来。Agent不需要停下工作来听——消息会在它完成当前操作后自然出现。这三个原语的实现极其轻量。消息服务器是一个独立进程每个Agent通过三个精简Shell脚本访问。监听器是普通操作系统进程不消耗任何LLM调用。Agent只支付浮上来的消息的token成本。最关键的是不需要修改任何编码Agent框架本身。AgentRadio是一个外挂的消息层可以接入Claude Code、Codex、Cursor等任何编码工具。这个对讲机方案带来了什么效果当四个Agent在被动感知模式下协作时准确率从51.6%跳到了62.1%。光这一项改动就贡献了10.5个百分点的净提升。在DeepSeek V4 Pro上跑同样的实验也涨了11.3个百分点。两个模型上都是统计显著的p0.003。相比之下如果把预算花在多跑几次选最优上——六次独立单Agent运行取最好成绩——Opus 4.6只能从32.3%提到37.9%花了和AgentRadio差不多的钱却少拿24.2个百分点。这不是算力的问题是结构的问题。最好的分工是随时可以推翻的AgentRadio配套设计了一套五阶段协作协议探索阶段。四个Agent各自独立摸索代码库画出自己认为的关键子问题。这个阶段不交流——先各自建立认知。分工阶段。组装者Agent打开规划线程所有人摊牌各自的发现协商谁来负责哪个子问题。方案要反复修改直到四个Agent都投批准票。执行阶段。这是被动感知真正发力的地方。每个Agent并行处理自己的子问题但后台对讲机一直开着。发现任何与队友子问题相关的东西——无论是支持证据、矛盾发现、遇到的障碍、还是确认行不通的死胡同——立刻发到工作日志线程。审查阶段。每个Agent在自己的结果线程里广播带证据的结论。队友可以因为三个理由质疑事实冲突、证据太弱、或遗漏了队友已知的信息。如果审查不通过子问题退回执行阶段重做。提交阶段。组装者从所有被批准的结果中撰写最终答案在最终答案线程里广播草稿最后一轮审批四个Agent全部批准后才提交。注意这个协议的关键特征分工是可以随时推翻的。如果Agent A在执行阶段发现自己的子问题其实应该由Agent B来解决它立刻在工作日志里BB可以在中途调整方向。而不是等到下一轮正式会议。数据证实了这一点。协商标注阶段带来了67个净评分细则收益是所有阶段中最大的单层贡献。而分工阶段本身其实丢掉了59个评分细则——因为强制分拆让架构类题目变得碎片化。先破坏再重建。这正是真正有效的协作方式。SWE-Atlas的评分细则级别归因分析还揭示了一个更重要的模式被动感知的收益随任务难度增长。在阻塞协议下差4-5个评分细则的难题被动感知每道题能多拿2.0个评分点。差1-3个评分细则的简单题只能多拿0.3-0.5个。越难的任务中途修正的价值越大。两个被忽略的细节论文里有两个案例值得深挖因为它们揭示了AgentRadio的本质边界。MinIO案例16个评分点全部翻转。MinIO是一道关于分布式对象存储的题目5个评分细则需要服务器端请求证据。在分工阶段四个Agent制定的计划里全部遗漏了启用服务器端审计日志这一步。没有日志就无法验证数据一致性。阻塞模式下有两个Agent在执行过程中分别发现了这个问题。但因为当时不是沟通阶段这两个发现都没有传达给队友。审查时所有人都基于不完整的证据批准了错误结论。最终只拿到11/16个评分点。被动感知模式下第一个发现这个问题的Agent立刻在工作日志线程里广播了证据。负责服务器侧排查的Agent收到后台通知后马上启用了审计webhook。最终16/16满分。AgentRadio不会创造Agent不知道的东西。它只确保已知的不被遗漏。Grafana案例两轮都没救回来。这道题有4个评分点需要否定性结论——“证明某配置项不是性能瓶颈的根源”。但两轮实验中四个Agent没有一个形成了否定性结论这个概念。所以两轮结果完全一样5/9。被动感知模式也无能为力。AgentRadio能传递的仅限于Agent已经做出的发现。如果所有Agent都没看到某个角度旁听再久也听不到。这两个案例的启示很直接AgentRadio解决的是信息传递问题不是认知生成问题。它让你的团队不再因为沟通不畅而丢分但不会让你的团队看到原本就看不见的东西。这个思路可以复制到哪些场景AgentRadio的设计哲学——被动感知 异步通信 结构化线程——不只是给编码Agent用的。写技术文档时三个人分头负责不同模块任何一个人对术语定义的修改都可以立刻广播给另外两个人不用等到合稿阶段才发现命名不一致。做安全审计时两个Agent并行扫不同代码路径一个在扫认证模块时发现token生成逻辑有缺陷另一个在扫授权模块时立刻就能拿到这个线索调整自己的审计方向。做数据分析时一个Agent在清洗数据源A时发现某字段的含义和文档描述不符同时查数据源B的Agent马上收到通知避免基于错误理解继续建模。所有这些场景的共同特征都是一样的子任务相互依赖中途发现会改写工作方向但现有系统只支持阶段性交流。AgentRadio证明了给这个场景加上一个足够轻量的后台对讲机花不到一行代码的架构改动就能拿到10个百分点的净提升。你现在就能做的三件事第一别再用回合制协调你的多Agent系统了。如果你的Agent之间只能通过停下来开会来交流你损失的可能远不止10个百分点——你可能根本没意识到这些损失因为失败的题目看起来像Agent不够聪明而不是沟通方式有问题。第二把被动感知当成多Agent系统的基本需求来设计。AgentRadio的三个原语——创建线程、发送消息、后台监听——总代码量可能不超几百行。把它当成Agent基础设施的一部分像呼吸一样自然。第三接受四个弱模型可以打败一个强模型这个事实。如果你的单Agent在复杂任务上卡在30-40%的准确率上不去与其等下一个更强模型发布不如让几个当前模型组队。AgentRadio证明了结构优势可以弥补代际差距。最好的团队不是每个人都在说话。是每个人都在听。本文首发于「圈圈的AI工程笔记」CSDN 同步发布 · 2026-08-02