一个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.6（+29.8pp），还超越了单Opus 4.8（57.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个百分点。两个模型上都是统计显著的（p<0.003）。

相比之下，如果把预算花在"多跑几次选最优"上——六次独立单Agent运行取最好成绩——Opus 4.6只能从32.3%提到37.9%，花了和AgentRadio差不多的钱，却少拿24.2个百分点。

这不是算力的问题，是结构的问题。

最好的分工，是随时可以推翻的

AgentRadio配套设计了一套五阶段协作协议：

探索阶段。四个Agent各自独立摸索代码库，画出自己认为的关键子问题。这个阶段不交流——先各自建立认知。

分工阶段。组装者Agent打开规划线程，所有人摊牌各自的发现，协商谁来负责哪个子问题。方案要反复修改，直到四个Agent都投批准票。

执行阶段。这是被动感知真正发力的地方。每个Agent并行处理自己的子问题，但后台对讲机一直开着。发现任何与队友子问题相关的东西——无论是支持证据、矛盾发现、遇到的障碍、还是确认行不通的死胡同——立刻发到工作日志线程。

审查阶段。每个Agent在自己的结果线程里广播带证据的结论。队友可以因为三个理由质疑：事实冲突、证据太弱、或遗漏了队友已知的信息。如果审查不通过，子问题退回执行阶段重做。

提交阶段。组装者从所有被批准的结果中撰写最终答案，在最终答案线程里广播草稿，最后一轮审批，四个Agent全部批准后才提交。

注意这个协议的关键特征：分工是可以随时推翻的。 如果Agent A在执行阶段发现自己的子问题其实应该由Agent B来解决，它立刻在工作日志里@B，B可以在中途调整方向。而不是等到下一轮"正式会议"。

数据证实了这一点。协商标注阶段带来了+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