本页译自英文文档。命令、标识符和示例保持原样。运行时 7.24.4 · SDK 2.6.7。 英文原文

已验证的多模型变更

状态：生效 范围：当前状态 最近审阅：2026-08-21 负责人：AX Code 运行时

这是面向如下任务的工作流页面：“我有一处重要变更，我想对它做不止一次尝试，并且我想让仓库自己的检查决定哪一次尝试值得保留。”

模式参考——标志、配置键、排名输入——见 执行模式。本页是端到端任务。

何时值得

运行多个模型的成本是运行一个的数倍。当变更重要、而失败要到后来才发现会很昂贵时，这是划算的：跨越模块边界的重构、迁移、安全敏感代码中的修复，或你确实不知道哪种方法正确的变更。

一行编辑、重命名，或任何你读一遍就能验证的事情，不值得这样做。

两种不同的工具

使用 council 来决定做什么——它把设计或审阅问题扇出到多个已连接的提供方，并把答案汇总为共识、严格多数、少数和单例发现，可选匿名辩论轮次。它是建议性的。模型之间的一致不是正确性的证明；它是关于该问题争议程度的信号。

使用 arena 来决定保留哪种实现。

竞技场实现工作流

1. 准备

实现模式需要一个至少有一次提交的 Git 项目，以及干净的主工作树。参赛工作树从精确的基线提交创建，不能继承未提交的变更，因此请先提交或贮藏。

你还需要已连接提供方上至少两个可区分的可选模型（支持共享网关），以及 modes.arena.enabled: true。

2. 运行

/arena <task description>

每个参赛者得到从已记录基线提交创建的自己的 Git 工作树，实现智能体在其中运行。参赛者不会修改你的主工作树。

3. AX Code 对每个候选做什么

• 把参赛者已跟踪和未跟踪的变更快照到持久的分支提交中，包括智能体自己做出的任何提交。
• 运行检测到的项目验证命令——类型检查、测试、lint——但仅在捕获到非空补丁之后。空补丁不能获胜。
• 默认按验证优先排名：只有已完成、非空且通过验证的补丁才有资格获胜。在通过的候选中，它偏好更低风险和更多样的补丁。

4. 决定

报告给你工作树路径、分支名和提交范围。

AX Code 不会合并胜者。 请自行检查、合并或拣选。这是有意的：验证意味着“你配置的检查在这个补丁上通过了”，这是真实信号，但不能替代审阅。

5. 审阅，并在需要时撤销

候选进入你的树之后，证据命令照常适用：

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

见 执行证据。

这里的“已验证”精确指什么

它的意思是：项目检测到的类型检查、lint 和测试命令针对该候选的补丁运行，并且通过了。

它并不意味着变更正确、完整、安全或设计良好。如果你的测试套件没有覆盖被改变的行为，通过的候选只证明已经覆盖的东西没有坏。验证提高的是下限；它不认证上限。

它也不延伸到普通的交互式编辑。竞技场候选和受门控的重构应用会运行检查；常规会话中普通的 edit 或 write 不会自动运行。当你想为普通运行记录该证据时，运行 verify_project。

成本与失败模式

• 成本随参赛者增加。 每个都运行完整的实现智能体。
• 脏工作树会在其他任何事发生之前停止运行，这是设计如此。
• 少于两个可区分的模型使比较没有意义，工具会报告，而不是编造排名。
• 所有候选都可能验证失败。 这是有用的结果：通常意味着任务说明不足，或仓库的检查比智能体假设的更严格。

相关

• 执行模式——council、arena 和其他模式的完整参考
• 执行证据——审阅并撤销结果
• 为何选择 AX Code——为何验证优先排名是切入点
• 多模型路由最佳实践——拆分高价工作与支持工作