多智能体系统里有个默认设置很少被摆上台面：一个成员犯的小错，会被其他成员当成事实接着用，等整条任务失败时，早就看不出最初错在哪一环。事后尸检写得再详细，这次任务也已经挂了；反复重跑试错，每次都从头再搜一遍修正，没有可复用的策略。10 月 14 日提交 arXiv 的 ARIA（编号 2610.20780）想教一个模型在运行中抢救：什么时候该干预、怎么接下去。
论文两位作者，归类人工智能与计算语言，代码已开源（LabRAI/ARIA）。做法分两步。先是数据：从 4 个多智能体框架、6 个基准、8 个宿主模型上采集超过 24000 条成功与失败轨迹，筛出「执行验证过的修复」——不是说得通，而是接上去之后整条轨迹真的跑完了——配对成 3953 对，每条写明错在哪、在哪干预、怎么续跑。论文称这是头一个把失败轨迹与执行验证修复大规模配对的数据集。然后是训练：用一个紧凑模型学「何时出手、怎么接」，目标是把修复策略迁移到没见过的框架与宿主模型上，而不是背下单条修正。
为什么「执行验证」是关键词
修复对的定义方式，决定了整套方法的天花板。如果修复的正确性由人工判断「看起来对」，数据里会混进大量纸面合理、一跑就崩的修正；ARIA 的做法是把修复接回原轨迹重放，跑成了才收。这把「修得好」从主观判断变成了可执行信号——和这两年 agent 圈把「任务完成」从答辩变成判题脚本，是同一个方向的努力。
另一个值得注意的设计是「紧凑模型」当修理工。它不需要是前沿大模型，需要的是认得出手时机：哪个错误会传播、哪一步还救得回来、续跑时该保留什么。这跟决策模型那条线（1027、1551）共享同一个直觉——频繁、有界的判断不该占用生成式模型的 token——但修理工的输入是整条执行轨迹，输出是干预点与续法，比路由判断重得多。
放进台谱里看
这条线站点铺了有一年。1076 用传染模型描述错误如何在智能体之间扩散与恢复；1933 的 CLASHarness 专门制造子智能体撒谎、抢锁、下达矛盾指令的考场；1549 给多智能体工作流的故障算成本，且主张故障归因要尽量免标签。ARIA 的位置在「诊断之后、重跑之前」：前面的工作回答「错怎么传、错在哪」，它回答「现在这一秒能做什么」。
把三篇连起来读，多智能体运维的轮廓就出来了：监控异常（1336 一类的可观测性货架）、定位传播路径（1076/1933）、估算故障成本（1549）、运行时抢修（ARIA）。目前缺的一角是「干预本身的审计」——谁允许一个模型在运行中改写别的智能体的动作，这个权限边界比修理工的能力更值得先想清楚。
几盆该浇的冷水
头一盆水泼在数据分布上：24000 条轨迹覆盖 4 框架 6 基准，失败类型的分布未必代表生产环境，3953 对修复对里「哪类错占大头」论文摘要未见说明。其次，验证器本身会错——执行验证只保证「跑完」，不保证「修得对」，跑完但结果错的轨迹会不会污染修复对，要看实现细节。再者，「对未见框架可迁移」的结论需要第三方复现，摘要只给了概括性表述。预印本、两位作者、未经同行评审，结论先停在「值得跟进」一侧。
给跑多智能体系统的团队一个立刻能用的动作：把过去一个月的失败轨迹按「错误刚冒头的回合」归类。如果相当比例的错误在出错后三个回合内还被同伴引用，你的系统缺的不是更强的模型，是一台抢修工——ARIA 的数据构造思路可以直接借。