一次成功的代理运行并不等同于验证。我们的一项相同模型消融研究完成了60/60个任务，但正确率为0/60。

如果你正在构建修改代码、调用工具或执行工作流的代理，我认为我们低估了一种失败模式：代理可以成功完成其工作流，却未产生可信的结果。我们在运行基准评估时深有体会： • 执行完成：60/60 • 拓扑正确激活：60/60 • 产物得出正确答案：0/60 这是一个以数学为重点的消融研究，而非生产编码基准，我并非声称该结果可推广到每个工作流。但架构上的启示不容忽视：执行成功 != 正确性自评 != 独立验证 与其让同一模型自行决定其补丁或输出是否有效，我们正转向更严格的职责分离： • 生成：代理产生候选结果、补丁或操作。 • 执行：结果在受控环境中运行。 • 验证：外部检查审查构建、测试、静态检查和其他配置的证据。 • 失败分类：当证据支持时，候选失败与运行器或环境失败保持分离。 • 证据收据：系统记录运行了什么、执行上下文、通过了什么、失败了什么以及仍待验证的内容。 模型拓扑并非信任边界。在一项针对302个单元的独立提供商受限配对评估中，采用门控设置在HotpotQA、MATH 500 / AIME和MMLU上显示了积极的测量增量。但我们也看到了负面的相同模型案例，这让我对未经外部验证的无条件辩论或集成循环越来越怀疑。我们正在转向的架构更像这样： 单一代理 → 外部验证 → 仅在证据不足时升级 而非：代理 → 自我反思 → 询问自己是否通过 → 信任结果 我们将此可靠性和验证层打包为AdaptOrch（披露：我是开发者）。对于在真实仓库或暂存环境中运行代理工作流的人：你今天的实际信任边界是什么？在代理操作被接受前，你是否依赖基于提示的自我批评、LLM判断、隔离执行、确定性检查、人工审查，或这些的某种组合？