企业代码库越长越大，被派去分析代码的人工智能智能体正在被压垮。这类任务动辄需要几十轮交互和大量工具调用，属于典型的长周期作业。把活拆给一队智能体分头干，看上去是最自然的解法，可现实中大多数多智能体系统都有一个致命缺陷：智能体之间没法在任务执行中途实时沟通。
针对这个问题，Coral AI Labs 与多所高校的研究者提出了 AgentRadio——一个异步消息传递层，让智能体在各自的执行步骤之间互相传话，同时又不打断手头的正事。在一项针对生产环境代码仓库的长周期问答基准测试中，用上 AgentRadio 的四个智能体团队，把任务准确率提升到了独立作业时的近两倍，并且超过了单个智能体搭载更强模型时的成绩。这项研究由 VentureBeat 记者本·迪克森（Ben Dickson）报道，论文已公开在预印本平台 arXiv 上。
单个智能体为什么会卡住
理解代码库是长周期任务中最极端的一种。智能体需要把软件构建起来、运行它、跨多个文件追踪执行路径，还要在很长的时间跨度内把证据综合到一起。在这种条件下，单智能体系统通常会栽在”覆盖问题”上。
论文的三位共同作者任新星（Xinxing Ren）、凯勒姆·福德（Caelum Forder）和彼得·卡罗尔（Peter Carroll）向 VentureBeat 解释说，单个智能体只能沿着仓库里的一条串行路径往下走，随着上下文不断膨胀，最初制定的计划越来越难修改，调查后期的新发现也未必能反向传导回去。模型执行单个步骤通常没问题，难点在于”让每一项待办、每一处依赖、每一条互相矛盾的证据，在漫长的调查过程中始终保持活跃”。
衡量这类能力的一个基准是 SWE-Atlas QnA，题目全部是针对真实生产仓库提出的长周期自然语言问题。这些题不是靠读代码就能答出来的，智能体必须把软件跑起来、执行多条命令才能找到答案。研究团队的实验显示，单个搭载 Opus 4.6 的编码智能体只能解决其中 32.3% 的任务；换成更先进的 Opus 4.8，成功率也只有 57.2%。
把工作量分摊给多个智能体，让每个智能体面对更小、更干净的上下文，是顺理成章的下一步。问题在于，多智能体方案带来显著收益的前提是任务”可以干净地拆分”——各部分能独立解决、最后合并即可。代码库理解恰恰很少满足这个前提，子任务之间高度互相依赖：某个智能体挖出的一个关键配置文件或一个缺陷，可能会彻底改写另一个智能体的整条探索路线。
研究者指出，现有多智能体系统大体落进三种有缺陷的模式：
- 并行但彼此隔离：智能体同时开工，全程零沟通。
- 并行但按轮同步：能沟通，但只能在严格对齐的轮次边界上进行。这迫使智能体停下来等同伴跑完一轮，才能交换中间发现。轮次制隐含了一个昂贵的假设——重要发现可以等到下一个通信阶段再说。
- 有名无实的异步：只提供有限的异步能力，比如自上而下派活，没有智能体之间的横向点对点通道，共享记忆也需要智能体主动暂停工作去读取更新。
按照论文的说法，当前多智能体系统的主要瓶颈就一句话：一个正在干活的智能体，没办法同时在听。研究者写道，就他们所知，还没有哪个系统能让并发工作的智能体通过一条横向的自然语言通道，获得对彼此的被动感知。
AgentRadio 怎么运作
为了打破”干活”与”倾听”之间的互斥，研究者做出了 AgentRadio。它是一层异步消息传递机制，可以直接插进现有的编码智能体框架里，为智能体提供三个原语：
create_thread：在参与的智能体之间开启一个会话线程。send_message：向线程追加一条消息，发出后立即返回，不阻塞发送方。wait_for_mention：阻塞进程，直到收到一条提及调用方的消息；消息送达时会附带所有线程的完整快照，让智能体立刻拿到上下文。
三者组合起来，智能体就进入了一种”被动感知”状态：可以继续做主线任务，同时在后台收发消息、更新自己掌握的信息。
AgentRadio 的代码以 Apache 2.0 协议开源在 GitHub 上，设计上足够轻量，不需要改动底层的 Claude Code、Codex CLI 等智能体框架。架构分两部分：一是消息服务器，作为独立进程充当中心枢纽，存放所有活跃线程、消息和提及记录；二是框架侧集成，智能体通过三个简单的 shell 脚本与服务器交互，每个脚本对应一个原语。
系统运行的唯一硬性要求，是智能体框架能把 shell 命令作为后台任务运行。智能体会在系统提示词里被要求常驻一个监听进程，并通过提供的脚本发消息。把 wait_for_mention 脚本放到后台跑，智能体就能一边继续工作一边异步收到通知。要接进现有技术栈，团队仍需写一个”轻量适配层，负责启动工作进程、分配身份、连接共享服务器并管理最终综合”，但这部分工作位于编码智能体的外围，不必改动底层模型。
实测：翻倍的准确率，和翻了六倍的账单
研究者在 SWE-Atlas QnA 基准的 124 个任务上验证了这套框架，覆盖系统设计、根因分析、安全和接口集成等领域。骨干模型选用 Claude Opus 4.6 和 DeepSeek V4 Pro，框架配置从单个编码智能体（B0）、经典分工的智能体团队（L1），一直排到使用 AgentRadio 异步协同的团队（L3）。
结果是：Opus 4.6 单智能体只解决 32.3% 的任务，完整的 AgentRadio 配置把这个数字提到 62.1%，接近翻倍，并且越过了 Opus 4.8 单智能体 57.2% 的成绩；DeepSeek V4 Pro 的成绩也从 29.0% 提升到 50.8%。
论文里有一个 MinIO 系统的真实案例很能说明问题。解题需要逐请求检查服务器日志，而智能体在初始规划阶段没预料到这一点。在只能协作、不能异步通信的 L2 配置下，两个智能体在执行命令时各自意识到需要这些日志，但因为无法在执行中途共享发现，一个默默放弃了，另一个也没向团队提出；到了评审阶段，整个团队一致同意了错误答案，丢掉五个评分项。启用 AgentRadio 之后，智能体做出了同样的中途发现，但其中一个立刻把服务端日志证据广播到共享工作日志上，其余智能体因为处在被动监听状态，马上吸收了这条新证据。最终这道题从不及格变成了 16 分满分。
研究者对此的总结是，关键差别在于时机：团队不需要多一个智能体，也不需要多一轮评审，它需要的只是让某个智能体的发现在其操作价值过期之前传到该传的人手里。
代价也是真金白银。固定规模的多智能体团队必然成倍推高 token 开销，研究者承认”这笔税是实实在在的”：平均每个任务的接口调用花费，从单个 Opus 智能体的 2.96 美元涨到 AgentRadio 完整方案的 19.45 美元。
不过更关键的对照实验证明，这不是单纯靠砸钱换来的。当研究者用 17.76 美元跑六次独立的 Opus 任务做算力对齐时，模型只解决了 37.9% 的任务，远低于 AgentRadio 的 62.1%。这说明 AgentRadio 的收益来自架构本身，而不是暴力堆规模。
什么时候该上多智能体
研究者同时给出了明确的边界：固定的多智能体团队不该成为所有工程任务的默认答案。判断是否需要多智能体，更有效的标准是任务里有没有”责任断点”——也就是那些”一名称职的工程师会主动叫上另一个人”的位置：工作跨越了归属边界、需要一个独立假设，或者风险高到值得单独验证。
按照他们的说法，当任务可以被拆解、拆出来的部分之间仍然互相依赖、单智能体成功率不稳定，而且答案不完整会带来实质的下游代价时，协同机制就非常合适。典型场景包括仓库级架构问题、陌生的遗留系统、跨服务的事故排查、安全分析、依赖迁移和多模块重构。反过来，对”边界清晰、影响局部、可以回滚”的活——比如一处已知的单文件改动或样板代码生成——单个智能体依然是更干净的选择。研究者的建议是：只要一份上下文还能诚实地扛住整个问题，就继续用一个智能体；只有当现有智能体不得不压缩掉证据、跨越独立的归属边界，或者需要自己验证自己的高影响结论时，才引入新的责任方。
未解的难题集中在”注意力治理与验证”上。被动感知让通信在执行期间随时可用，但它并不决定应该存在哪些智能体、哪条发现值得打断别人、该通知谁、证据强到什么程度才可以推翻原计划。如果每个智能体都收到每一条更新，通信层就退化成噪声；如果几个智能体本来就共享同一个错误假设，更快的通信只会让错误扩散得更快。
论文中一个基于 Grafana 平台的案例正好印证了这个局限：九项评分标准中有四项需要得出否定性结论，比如观察到某个数据源选择器不会自动选中。智能体跑完了相关测试，却没有一个形成那个缺失的否定假设，两种配置都在这四项上失分。研究者的评价是，被动感知能扩散某个人已经提出的想法，但它没法凭空供给一个团队里从未出现过的构想。
按照研究者的判断，下一代系统需要的是自适应的责任分配、基于证据的路由、冲突解决机制、明确的成本上限、权限管理、故障恢复，以及清晰的人工升级节点；最重要的是可追溯的来源记录，好让工程负责人能查清是哪个智能体给出了某项断言、某个动作为何被采纳。用他们的原话说：运行时间越长的智能体，让沟通变得越重要，也让追责变得更难作假。
AgentRadio 目前仍是一个使用固定四智能体团队和五阶段协议的受控研究实现，其中的原理正被改造成一款名为 Coral Code 的商业产品，思路从自上而下的刚性协议转为自下而上——工程师从自己现有的编码智能体起步，只有当证据本身需要时，才引入仓库范围的调查、专职责任分工和通信机制。
来源：VentureBeat《Four AI agents coordinating in real time outperformed Claude Opus 4.8 on enterprise coding tasks》，作者 Ben Dickson；论文数据来自 arXiv 预印本