夜雨聆风一、Codebase 理解的难题 —— 单 agent 的”覆盖力天花板”
基于 LLM 的 agent 越来越擅长长时任务——但 codebase 理解是这类任务的”极端版本”。它要求 agent 编译代码、跑起来、跨多文件追踪执行路径、并在长时间跨度内综合证据。
在这种条件下,单 agent 系统通常会撞上一个“覆盖力问题(coverage problem)”。
“单 agent 在仓库里走的是一条串行路径,“论文共同作者 Xinxing Ren、Caelum Forder、Peter Carroll 告诉 VentureBeat。”随着上下文不断膨胀,初版计划越来越难修订,后期才有的发现也不一定能传回来。模型单步执行通常没问题——真正难的是让所有约束、依赖、矛盾证据在整个长调查过程中都保持’活着’。”
衡量大代码库 AI 表现的一个基准是 SWE-Atlas QnA——由针对生产仓库的长时自然语言问题组成,光读代码答不上来,AI agent 必须真的把软件跑起来、执行多条命令才能找到答案。
研究团队实验给出:单个 Claude Code 跑在 Opus 4.6 上,只能解 32.3% 的任务;升级到更强的 Opus 4.8,只提到 57.2%。
一个直觉的修复是把工作量摊到多个 agent 上,让每个 agent 手里只持更小、更干净的上下文。当任务能被干净拆分(各自解决、最后合并)时,多 agent 能给出明显增益。
但 codebase 理解几乎从来不是可干净拆分的——子任务高度互相依赖。一份关键配置文件,或一个 agent 挖出来的 bug,会彻底改写或重定向另一个 agent 的整条探索路径。正因为这种依赖,agent 必须实时协调、谈判、共享中间发现。
但现实里,异步多 agent 通信非常罕见。研究者指出,现有的多 agent 系统大多落入三种有缺陷的模式:
- 并行但互相隔离(parallel but isolated)
——agent 同时跑,但完全不通信 - 并行但轮询同步(parallel but round-synchronized)
——agent 能通信,但只能在严格同步的”轮”边界通信。这强制 agent 必须停下等别人跑完一轮,才能辩论或交换中间发现;一旦”重要发现”必须等到下一轮,这个假设在处理活系统的相互依赖片段时就非常贵。比如一个查 API 症状的 agent 挖到证据,可能直接把 storage agent 的当前假设推翻。”如果这条信息得等到两边都跑完才传,storage 那条调查很可能已经走错路,“研究者说 - 相邻形式的”异步”
——这类系统提供有限的异步特性,比如 top-down 任务分发,没有 agent 之间的横向对等通道,也没有需要 agent 主动暂停工作去读更新的共享记忆
研究者在论文中点出,当前多 agent 系统的核心瓶颈是:“一个正在干活的 agent,没法同时在听”。
“据我们所知,现有系统没有任何一个能让并行工作的 agent 拥有横向的、自然语言通道来被动感知彼此,“研究者写道。
二、AgentRadio 怎么工作 ——3 个 primitive + 一个 server
为了化解”干活”和”听话”之间的互斥,研究者做了 AgentRadio——一个异步消息传递层,设计成能直接挂到现有编码 agent harness 上。
AgentRadio 给了 agent 三个 primitive:
create_thread—— 在参与 agent 之间开一条对话 send_message—— 把消息追加到 thread,发完立即返回,不阻塞发送方 wait_for_mention—— 阻塞当前进程,直到一条@自己的消息到来,一并把整份 thread 快照送过来,让 agent 拿到即时上下文
这三件套给 agent 提供了“被动感知(passive awareness)”这种状态——继续干主活的同时,后台传递消息并更新自己的认知。
AgentRadio 代码以 Apache 2.0 协议开在 GitHub 上。它的设计原则是轻量、不要求改底层 agent harness(Claude Code / Codex CLI 都行)。
架构由两块组成:
- 消息服务器(message server)
——一个独立进程,充当中心枢纽,存着这组 agent 的所有活跃 thread、消息和 mention - Harness 端集成
——agent 用三个简单的 shell 脚本跟服务器交互,每个脚本对应一个 primitive
整套机制能跑起来唯一硬性要求是:agent harness 必须能以”后台任务”的形式跑 shell 命令。Agent 在 system prompt 里被指示:保持一个 watcher 在跑,所有消息都通过提供的脚本发。把 wait_for_mention 跑在后台,agent 就能边干主活、边异步收通知。
要把这套东西塞进现有栈,团队还需要一个”薄适配器”——启动 worker、分配身份、连到共享 server、最后做综合,研究者说。这层工作包在编码 agent 外面,而不需要去改底层模型。
三、AgentRadio 实测 —— 4 agent 跑赢 Opus 4.8
为验证 AgentRadio 的真实价值,研究者在 SWE-Atlas QnA 基准的 124 个任务上做了测试——覆盖系统设计、根因分析、安全、API 集成几类领域。
底模用的是 Claude Opus 4.6 和 DeepSeek V4 Pro;harness 配置上,他们从单个 Claude Code agent(B0)、到经典分工的 agent 队(L1)、再到用 AgentRadio 异步协调的 agent 队(L3) 几档都跑了。
实验结论很直接:AgentRadio 的通信架构,同时跑过了”朴素多 agent”和”堆算力”两种打法。
单个 Claude Code + Opus 4.6 只解了 32.3%;完整的 AgentRadio 套把这个数几乎翻倍到 62.1%,超过了单 agent + Opus 4.8 的 57.2%。DeepSeek V4 Pro 的成绩也被从 29.0% 拉到了 50.8%。
为了看这是不是单纯靠”算力”换来的,研究者在等开销(compute-matched)的条件下做了对照——同样花 2.96,全套 AgentRadio 栈飙到 $19.45。
但堆规模不等于堆性能——compute-matched 那组对照已经证明。多 agent 团队不该成为每个工程任务的默认响应。研究者给出的判断更准:看任务里有没有”责任断点(responsibility breakpoint)”——这种地方”一个称职工程师都会拉另一个人进来,因为工作跨过了所有权边界、需要独立假设,或者风险大到需要单独验证”。
协调结构的强适配场景(研究者列的):
仓库级架构问题 不熟的遗留系统 跨服务的事件调查 安全分析 依赖项迁移 多模块重构
反过来,单 agent 仍是更干净的选择——”有界的、局部的、可逆的工作”,比如已知的一个文件改动、或者 boilerplate 生成。
“当一个上下文还能诚实地’拥有’整个问题,就用一个 agent;“研究者说。”当现有 agent 不得不压缩证据、跨越独立所有权边界、或要核验自己高影响的结论时,再引入另一个责任。”
五、从研究到商业化:Coral Code
AgentRadio 是”固定 4 agent 队 + 5 阶段协议”的研究实现;同样的底层原理正在被装进一个商业产品 Coral Code。
Coral Code 不在每个 ticket 上都套用僵硬的多 agent 协议,而是自下而上——工程师先用自己已有的编码 agent,Coral 在证据确实需要时再引入仓库范围的调查、专门职责、通信。
“Coral 把围绕工程师现有工具的’运营层’打包起来,在 harness 外面提供仓库上下文、范围化的 specialist、通信和证据层,而不是在 harness 里面改它,“研究者说。
这套动态做法把成本优化对准了”真正该花的那个单位”——一个已完成、可 review 的产出。
论文里有一个 MinIO 系统的真实案例,很能说明 AgentRadio 的价值。任务要求核对每个请求的服务端日志——这个需求 agent 们在初始规划时根本没预料到。
在 L2 配置(agent 能协作但没异步通信)下,两个 agent 独立跑命令时各自意识到了需要这些日志。因为没法中途共享发现,一个 agent 私底下放弃了,另一个没把这条信息提给团队。到了 review 阶段,团队全体一致选了错误答案,丢了 5 个 rubric。
打开 AgentRadio 之后,agent 们做了同样的中途发现,但一个 agent 立刻把”需要服务端日志”这条证据广播到共享 worklog。其他 agent 都开着被动监听,立即吸收了这条新证据。实时协调把一个本来要失败的分数救成了 16⁄16 满分。
“关键的区别是时机,“研究者说。”团队不需要更多 agent,也不需要再来一轮 review——它需要的是让一个 agent 的发现,在它还值钱的时候到达对的同伴那里。”
六、自主软件工程的未来 —— “注意力治理”才是真瓶颈
AgentRadio 给 agent 编排上了一档,但仍有硬仗要打。研究者点出的最大瓶颈是“注意力治理 + 验证(attention governance and verification)”。
“被动感知让’通信’这件事在执行过程中可用——但它不决定哪些 agent 应该存在、哪条发现值得打断、谁该收到、证据强到能修订计划,“研究者说。”每个 agent 都收到每条更新,通信层就变成噪音;几个 agent 共享同一个错误假设,更快的通信只会更快扩散错误。”
论文里 Grafana 平台的案例就中了这一条:9 个 rubric 里有 4 个要求否定性结论——比如观察”datasource picker 不会自动选某项”。Agent 们跑了相关测试,但没有任何一个 agent 形成那条”缺失的否定假设”。两种配置都在这 4 条上全失败。
“被动感知能把一个人想出来的点子分发给其他人,但它生不出一个’团队里从来没人想过的概念’,“研究者说。
任务时长越拉越长,通信和协调就越关键。研究者写到:“下一代系统需要:自适应职责分配、证据感知路由、冲突解决、明确的成本限制、权限、恢复、以及清楚的人类升级点“。最重要的是可审计的 provenance——让工程 lead 能查清哪个 agent 提的什么主张、为什么某个动作被接受。
