AgentRadio：异步协调四智能体在企业代码理解任务中超越Claude Opus 4.8

随着企业代码库规模不断增长，负责分析这些代码库的AI智能体正因需执行多轮交互和多次工具调用的长周期任务而不堪重负。将工作分配给一组智能体看似是显而易见的解决方案，但这引入了一个致命缺陷：大多数多智能体系统并未设计为支持智能体在任务执行过程中实时、自主地相互协调。

为解决这一问题，Coral AI Labs 研究人员与多所大学合作提出了 AgentRadio——一种异步消息传递层，允许智能体在其执行步骤之间进行通信，而不会中断其主任务。在子任务高度相互依赖的真实企业应用场景中，该架构使智能体能够及时进行中途修正，而非沿死胡同路径持续执行直至正式审查阶段。

在针对生产级代码仓库的长周期问题基准测试中，由 AgentRadio 驱动的一组智能体，使四名独立运行的 Claude Code 智能体的任务准确率几乎翻倍。它还超越了在更先进模型上运行的单个智能体。对AI实践者而言，AgentRadio 表明，恰当的协调结构可胜过原始算力与模型规模。

代码库理解的挑战

基于大语言模型（LLM）的智能体日益具备处理需与不同工具及环境交互的长周期任务的能力。代码库理解代表了此类挑战的极端形式：它要求AI智能体构建软件、执行该软件、跨多个文件追踪执行路径，并在长时间内综合证据。

在此类条件下，单智能体系统通常因“覆盖问题”而失效。 

“单个智能体沿着代码仓库中一条串行路径推进，”《AgentRadio》论文共同作者 Xinxing Ren、Caelum Forder 和 Peter Carroll 向 VentureBeat 解释道，“随着其上下文不断增长，初始计划越来越难以修订，且调查后期发现的信息并不总能有效传播。”模型通常能执行各个独立步骤，“但难点在于在整个长期调查过程中，始终维持所有义务、依赖关系及相互矛盾的证据处于活跃状态。”

一个有助于衡量AI在大型代码库上性能的基准是 SWE-Atlas QnA。该基准包含针对真实生产代码仓库的长周期、自然语言问题。这些问题无法仅通过浏览代码解决；AI智能体必须运行软件并执行多条命令才能找到答案。

据研究团队实验，单个运行于 Opus 4.6 的 Claude Code 实例仅能解决其中 32.3% 的任务。升级至更新、更先进的模型（如 Opus 4.8）仅将成功率提升至 57.2%。

一种自然的补救措施是将工作负载分摊至多个智能体，使每个智能体在更小、更清晰的上下文中工作。当任务可被清晰分解时（即各部分可独立求解并在最后合并），多智能体方案可带来显著的性能提升。

然而，代码库理解极少能被清晰分解。子任务高度相互依赖：一个智能体发现的关键配置文件或某个bug，可能彻底改写或重定向另一智能体的整个探索路径。由于这些依赖关系，智能体必须实时协调、协商并共享中间发现。

尽管存在这一需求，异步多智能体通信却十分罕见。研究人员指出，现有多智能体系统通常落入三种有缺陷的模式：

• 并行但孤立： 智能体同时运行，但完全不相互通信。

• 并行但按轮次同步： 智能体可以通信，但仅限于严格、同步的轮次边界处。这迫使智能体必须停止并等待彼此完成一轮后，才能展开辩论或交换中间发现。基于轮次的系统假设重要发现可等待至下一通信阶段，而当智能体正在处理实时系统的相互依赖部分时，这一假设代价高昂。例如，一名正在调查API症状的智能体可能发现一项证据，足以推翻存储智能体当前的假设。“若该信息需等到两名智能体均完成本轮才传递，存储调查可能已沿错误路径完成，”研究人员表示。

• 邻近形式的异步性： 这些系统仅提供有限的异步功能，例如自上而下的任务分派。它们缺乏智能体之间的点对点横向通信通道，也无须智能体主动暂停工作以读取更新的共享内存。

在论文中，研究人员指出，阻碍当前多智能体系统发展的主要瓶颈在于：“正在工作的智能体无法同时倾听。”

“据我们所知，尚无现有系统能为并发工作的智能体提供经由横向、自然语言通道实现的被动互知能力，”研究人员写道。

AgentRadio 的工作原理

为消除“工作”与“倾听”之间的互斥性，研究人员开发了 AgentRadio——一种异步消息传递层，专为直接接入现有编码智能体框架而设计。

AgentRadio 为智能体配备了三项基础原语：

• “ create_thread ”原语在参与智能体之间开启一场对话。

• “ send_message ”原语将一条消息追加至某线程，并在不阻塞发送方智能体的情况下返回。

• “ wait_for_mention ”原语将进程阻塞，直至收到提及调用者的某条消息为止。该原语会交付该消息及所有线程的完整快照，使智能体即时获得上下文。 

这三项原语使智能体具备“被动感知”状态：它们可在后台持续传递消息并更新知识，同时继续执行其主要任务。

AgentRadio 的源代码依据 Apache 2.0 许可证发布于 GitHub。其设计轻量，无需直接修改底层智能体框架（如 Claude Code 或 Codex CLI）。 

该架构包含两个主要部分：

• 消息服务器： 一个独立进程，作为中心枢纽，为智能体群组存储所有活跃线程、消息及提及记录。

• 框架端集成： 智能体通过三个简单 shell 脚本与服务器交互，每个脚本分别对应一项原语。

该系统正常运行的唯一硬性要求是：智能体框架必须能够将 shell 命令作为后台任务运行。智能体在其系统提示词中被指示保持一个监听器持续运行，并通过所提供的脚本发送消息。在后台运行 wait_for_mention 脚本，可使智能体继续其工作并异步接收通知。

为将该技术集成到现有技术栈中，团队仍需要一个“轻量级适配器，用于启动工作进程、分配身份、将其连接至共享服务器，并管理最终的合成过程”，研究人员表示。这项工作围绕编码智能体展开，而非要求对底层模型进行修改。

AgentRadio 实际运行示例

为验证 AgentRadio 在现实世界中的实用性，研究人员在 SWE-Atlas QnA 基准测试的 124 项任务上测试了该框架。测试涵盖系统设计、根因分析、安全性和 API 集成等领域。

研究人员以 Claude Opus 4.6 和 DeepSeek V4 Pro 作为骨干模型。在执行框架（harness）方面，他们评估了多种配置：从单个 Claude Code 智能体（B0），到采用经典分工模式的智能体团队（L1），再到使用 AgentRadio 进行异步协调的智能体团队（L3）。

实验结果表明，AgentRadio 通信架构在性能上优于朴素的多智能体设置和单纯的计算资源扩展。

尽管仅使用 Opus 4.6 的单个 Claude Code 智能体仅解决了 32.3% 的任务，但完整的 AgentRadio 设置几乎使该指标翻倍，解决了 62.1% 的任务，并超过了在 Opus 4.8 上运行的单智能体（解决率为 57.2%）。它还将 DeepSeek V4 Pro 的结果从 29.0% 提升至 50.8%。 

为理解该技术对企业级 AI 的实际影响，论文重点介绍了一个涉及 MinIO 系统的真实任务。解决该任务需检查每个请求的服务器日志，而这一需求是智能体在初始规划阶段未能预见到的。

在 L2 设置下（智能体协作但缺乏异步通信能力），两名智能体在执行命令过程中各自独立意识到需要这些日志。由于它们无法在执行中途共享这一发现，其中一名智能体私下放弃，另一名智能体则未能向团队提出该需求。在评审阶段，团队一致同意了错误答案，遗漏了五项评分标准。

启用 AgentRadio 后，智能体同样在执行中途作出了相同发现，但其中一名智能体立即将所需的服务器端日志证据广播至共享工作日志。由于其他智能体处于被动监听状态，它们立即吸收了这一新证据。这种实时协调将原本失败的得分转变为满分 16 分（满分 16 分）。

研究人员表示：“关键区别在于时机。团队并不需要增加另一个智能体或再进行一轮评审；它只需要让某位智能体的发现，在其操作价值失效之前，及时传递给合适的同伴。”

研究人员指出，相同模式也出现在企业级事件处理工作中。例如，一名调查 API 异常症状的智能体可能发现某些证据，从而证伪存储智能体当前的假设。如果该信息需等到两个智能体均完成各自任务后才被共享，则存储智能体的调查可能已沿错误路径完成。“被动感知使第二名智能体可在其下一步工作中直接纳入该矛盾信息，而无需中断正在执行的命令”，他们表示。

协调的成本与复杂性

AgentRadio 需要固定的多智能体团队预算，这本身就会成倍增加 token 成本。研究人员承认“这一开销真实存在”，并指出平均每项任务的 API 支出从单个 Opus 智能体的 2.96 美元上升至完整 AgentRadio 栈的 19.45 美元。

然而，单纯扩大规模并不等同于性能提升。当研究人员在计算资源匹配测试中，为六次独立的 Opus 运行投入 17.76 美元时，模型仅解决了 37.9% 的任务，而 AgentRadio 解决了 62.1% 的任务。这表明 AgentRadio 的架构优势属于结构性提升，而非仅靠暴力扩展实现。团队仍应警惕智能体之间的频繁切换。“通信既可将智能体引向更优证据，也可能使其偏离一条有效的路径”，研究人员警告道。

固定多智能体团队不应成为应对每一项工程任务的默认方案。研究人员表示，判断是否需要多智能体设置的更有意义的测试标准，是任务中是否存在“责任断点”。这些断点是指“一名胜任的工程师会引入他人参与的环节，因为工作跨越了所有权边界、需要独立假设，或风险足够高，值得单独验证。”

研究人员表示：“当任务可被分解、分解后的各部分仍保持相互依赖、单智能体成功率不可靠，且不完整答案将带来显著下游成本时，协调机制便尤为适用。”此类任务包括：面向整个代码仓库的架构问题、不熟悉的遗留系统、跨服务事件调查、安全分析、依赖迁移以及多模块重构。

相反，对于“范围明确、局部化且可逆的工作”，例如已知的单文件修改或样板代码生成，单智能体仍是更简洁的选择。 

研究人员表示：“只要一个问题仍能被单一上下文诚实地掌控，就应继续使用单个智能体；当现有智能体不得不压缩掉证据、跨越独立的所有权边界，或需自行验证其高影响结论时，才应引入另一项责任。”

从研究走向商业化：Coral Code

尽管 AgentRadio 是一种受控的研究实现，采用固定四智能体团队及五阶段协议，但其核心原理正被适配为一款名为 Coral Code的商业化产品。

Coral Code 并非对每张工单都强制应用僵化的多智能体协议，而是自下而上运作：工程师从其现有的编码智能体出发，仅当浮现的证据证明必要时，Coral 才引入面向整个代码仓库的调查、专业职责划分及通信机制。“Coral 将工程师已在使用的工具所涉及的运维关切打包封装，提供代码仓库上下文、范围限定的专业智能体、通信能力及证据层——这些功能位于执行框架（harness）外围，而非嵌入其内部”，研究人员表示。

这种动态方法通过聚焦相关单元——即完成一项可审查成果的成本——来优化开支。

自主软件工程的未来

尽管 AgentRadio 极大地提升了智能体编排能力，但仍存在需克服的障碍。研究人员指出的一个主要瓶颈是“注意力治理与验证”。

研究人员表示：“被动感知使通信可在执行过程中随时可用，但它并不决定哪些智能体应当存在、哪些发现值得中断当前流程、谁应接收该信息，或证据何时强到足以修订计划。”若每个智能体都接收全部更新，通信层便会沦为噪音；若多个智能体共享同一错误假设，更快的通信反而会加速错误传播。

例如，论文中一个案例研究涉及 Grafana 平台，九项评估标准中有四项要求得出否定性结论，例如观察到数据源选择器未能自动选择。代理运行了相关测试，但均未形成缺失的否定性假设。两种配置均未能通过这四项评估标准。 

研究人员表示：“被动感知可以传播某人所开发的一个想法，但它无法提供团队中任何地方都未曾出现过的概念。”

随着任务持续时间延长，沟通与协调变得至关重要。“下一代系统……需要具备自适应的责任分配、基于证据的路由、冲突解决、明确的成本限制、权限管理、恢复机制以及清晰的人类升级节点，”研究人员指出。最重要的是，它需要持久的溯源能力，以便工程负责人能够检查是哪个代理提出了某项主张，以及某项操作为何被接受。

他们表示：“运行时间更长的代理使沟通变得更加重要，同时也使问责更加难以伪造。”