Cross-Examine：用确定性执行验证 AI 代理代码改动

在 AI 编码代理日益普及的当下，一个被忽视的问题逐渐浮现：代理生成的代码可能通过了既有测试，却悄悄改变了被替换行为本身。Cross-Examine 正是为解决这一痛点而设计的独立验证工具，项目源自 OpenAI Build Week 2026 的开发者工具赛道。

问题：测试全绿，但行为已变

代理编写的代码往往能通过仓库中已有的测试套件，却没有证据表明它所替换的行为仍然成立。模型修好一个 bug 的同时引入另一个 bug，而测试在全程保持绿色。对任何合并 Codex 生成 PR 的人来说，他们审核的只是一份 diff，看不到这份 diff 静默改变了哪些运行时行为。Cross-Examine 的核心主张是：测试通过不等于行为正确。

工具机制：基线捕获 + 对抗性执行

Cross-Examine 的运行流程可以概括为五步：

使用 Git worktree 隔离出 base 与 head 两个修订版本；
由 GPT-5.6 Sol 读取受控的 diff 与源码上下文，输出符合 schema 约束的「行为声明」（Claims）以及可选的探测计划（ProbePlans）；
在受信任输入边界内执行 base 与 head，记录实际输出；
由纯函数 aggregate() 基于执行证据给出 VERIFIED、REFUTED 或 ABSTAIN 的判定；
通过 FastAPI 服务与 React 前端呈现完整证据链，包括精确命令、base 输出、head 输出、期望值、实际值与复现输入。

关键设计在于：模型只负责「提议行为声明」，既不出具结论，也不下达判定；证据由模型外的执行环节提供，最终判定由确定性函数完成。模型本身被刻意约束为受限组件，而非裁判。当声明格式错误、目标未知或触碰禁止结构时直接拒绝，提案文本始终处于不可信状态。

人机分工：人类定原则，Codex 写实现

项目明确区分了人类与 Codex 的职责边界：

人类负责：问题选择、Python 范围限定、五阶段契约、风险规避策略、Layer-A 优先于 Layer-B 排序、信任输入执行边界、接口设计要求、证据原则与最终提交叙事。
Codex 负责：FastAPI/SQLite/React 技术栈选型、worktree 与子进程机制、边界目录与 Hypothesis 范围、持久化与 SSE 协议、CLI 表面与确定性 hero 构造、跨平台诊断与发布验证。

这种分工被项目作者视为判定结果可信的原因——左侧的原则约束了右侧代码能够得出的结论范围。Codex 还承担了多项容易被低估的调试工作，包括排查 Windows cp1252 子进程编码故障、detached worktree 中的 pytest-cache 重命名拒绝，以及依赖形态引发的误报等问题。

局限与平台支持

Cross-Examine 仅支持 Python 变更，且只能在本地运行完整五阶段流水线——Vercel Functions 无法提供所需的 Git 与本地运行时能力，因此仓库级分析被刻意限定为本地执行。项目提供 macOS、Linux 命令与等效的 Windows PowerShell 流程，CI 在三个平台上以 Python 3.12 验证。项目仓库附带了需求清单、目录映射、真实仓库运行记录、测试集与视频大纲，配套的在线 demo 实例允许无需克隆、无需安装、无需 API Key 即可在浏览器中检视一份明确标注的证据夹具。

值得提醒的是，文中提及的 GPT-5.6 属于黑客松背景下的实验性模型名称，模型本身的真实性与可用性需以 OpenAI 官方发布为准。