Apodex-1.0：作为多智能体验证的深入研究

Apodex-1.0 将深度研究重新构建为多智能体验证问题，而不是更长的单智能体 ReAct 循环。经过训练的模型可以单独运行，但论文真正的系统主张是 Apodex-1.0-H：一个异步智能体团队，其中专门的子智能体独立探索，报告在共享证据池中积累，单独的验证者智能体加上全局验证者决定证据实际支持的内容。训练管道很重要，主要是因为作者希望子智能体的生成、协调和验证成为本机模型行为，而不仅仅是包裹通用模型的外部脚本。

• MAS 是推理单元：这篇文章最有力的举措是将推理单元从一个上下文窗口转移到特定问题的团队。主智能体分解查询，派遣研究人员、分析师、开发人员和领域专家子智能体，然后从共享池中读取他们的报告，而不是强迫每个分支都通过一条拥塞的轨迹。这样探索可以分支：每个子智能体都有自己的提示、工具和上下文，因此一个失败或缓慢的分支不会毒害整个运行。

• 验证在结构上是外部的：Apodex 通过将验证分配给不产生原始推理轨迹的智能体，和普通自我反思拉开距离。验证者团队分为冲突审查者、事实检查者和报告草稿审查者，分别针对不同失败模式：相互矛盾的证据、不受支持的主张，以及薄弱的最终综合。对于 MAS 设计来说，这是核心教训：可靠性不太来自智能体“辩论”，更多来自为审查智能体提供独立背景、独立工具，以及拒绝工作智能体结论的许可。

• 异步是协调原语：报告池不只是存储；它是系统的因果支柱。子智能体把状态为“已排队”、“进行中”和“准备就绪”的报告放入池中，而协调器在部分证据到达时继续生成、验证或综合。这将探索、验证和综合变成独立控制循环，这也是作者能声称在一项任务中部署多达 150 个子智能体、超过 15,000 个步骤的原因。

• 全局验证更改选择：重型模式不仅仅对多个候选答案进行投票。为了进行深入研究，全局验证者构建了一个声明证据图，其节点是原子发现和初步声明，具有支持边和矛盾边。最终答案是通过对图表进行证据推理而不是答案受欢迎程度来选择的，对于研究任务来说，这是更好的 MAS 模式，其中重复的发现不应超过缺失或矛盾的证据。

• AgentOS 是系统边界：运行时参数是智能体团队需要一个与任务无关的内核，而不是每个基准测试的定制循环。 AgentOS 将调度、模型和工具路由、事件流、检查点、跟踪、成本核算和权限保留在狭窄的节点上下文外观之下，而工作流、角色、工具、skill、MCP 服务器和验证器组件则作为其上方的 plugin 存在。这是构建者应该窃取的部分：保持协调基础的通用性，并让每个智能体拓扑成为工作流程/plugin 决策。

为什么重要：这篇文章对于 MAS 来说，与其说是一种模型训练方法，不如说是一种以验证为中心的智能体基础设施的蓝图。其最强有力的设计原则是，智能体规模不应该意味着“一个智能体有更多轮次”；它应该意味着独立的上下文、异步证据流以及从工作智能体轨迹之外审核工作的审阅者。主要的开放问题是可重复性：公共 repo 当前在标准 ReAct 模式下公开了 Apodex-1.0 的评测工具，而重型 MAS 运行时和全局验证器实现仅在系统报告级别进行描述。论文 | 博客 | 评测代码 | 模型