让容器执行结果裁定漏洞是否复现

让 AI 复现 Bug，最容易踩的坑不是脚本跑不起来，而是脚本跑完了，系统却把错误结果标成成功。PatchPilot 的作者把裁判权交给 Docker 容器：模型负责写复现脚本，是否复现则由退出码、输出和目标报错判定。

这份开发记录值得读的，是它暴露了几个会让 Agent「假绿」的工程问题：检出了已经修复的代码、依赖没装、任务存储存在并发竞态。作者的结论很明确：先把成功标准和验证样本做扎实，再讨论用哪个模型。

模型负责写脚本，谁来证明 Bug 出现了

PatchPilot 的目标流程是：用户提交 GitHub issue 链接，Agent 在 Docker 中复现问题，再生成失败测试和修复 diff。第一版覆盖 Python、C++ 和 JavaScript，但文中用于验证的样本只有 Python，不能把结果直接推广到另外两种语言。

作者从 Phase 0 就决定使用确定性判定。模型读取 issue，编写复现脚本；系统根据容器里的退出码、运行输出，以及 issue 引用的报错是否出现，决定复现是否成功。模型不能自己宣布成功。

复现成功必须能指向具体证据，而不能只得到模型的一句确认。

这能减少模型顺着任务目标解释结果的问题，也方便排查：某次运行为什么被标为成功，应当能找到对应输出。不过，文章没有给出完整判定规则。例如，如何区分目标报错和脚本打印出的同名文本，文中没说清。确定性规则可以重复执行，但规则是否正确，仍然需要验证。

还要先理顺文章的时间线。正文保留了开发中的状态，开头补充了最新进展：文章最初于 11 月 6 日发布到 AWS Builder Center，当晚 Phase 3 通过验收。Qwen3-Coder 在真实环境中复现了 10 个样本中的 7 个，没有环境准备失败，随后成为默认模型，前端也已上线。

十个真实 issue，为什么比一片绿灯更有用

作者整理了 10 个真实 Python issue，每个都验证两次：在修复前的 base commit 上出现引用的报错，在 fix commit 上报错消失。样本保存在 scripts/fixture_issues.json。

这组验证用例（fixtures）揭穿了一个关键缺陷：Agent 实际克隆的是 HEAD，而非 base commit。拿到的代码已经包含修复，先前那些被标成「已复现」的结果因此失去依据，界面却仍然显示成功。

正反两端都验证，才能发现验证链路本身出了问题。只跑一份当前代码，很难分清「确实复现」「已经修好」和「判定器误报」。

整理样本还带出了另外两个缺陷：boto3 既没有固定版本，也没有安装，Bedrock 路径一旦真实执行就会失败；任务存储存在撕裂读取竞态，即写入尚未完成时，另一个请求读到了不完整状态。

这些问题不是靠盯着 Agent 代码发现的，而是被完整运行流程逼出来的。原正文记录 Phase 3 已有 79/79 个测试通过、ruff 检查通过、CI 全绿，但作者仍要求部署到 EC2，用真实 Docker 跑样本、覆盖所有判定路径，并在宿主机做恶意 issue 演练。

安全和成本限制，为什么要先于公开演示

GitHub issue 是陌生人提供的文本。作者在 Phase 3 构造了把文本伪装成命令的恶意 issue，演练通过；开头更新也确认宿主机上的演练已经通过。

他们采取的边界是：issue 作为数据交给模型读取，执行器运行的命令由程序按固定模板构造，不让 issue 文本直接进入命令执行位置。作者此前在 PRISM 中也遇到过类似风险：提交信息进入意图分析后，恶意内容可能影响下游输出。

这里需要保留一个问号。模型仍然根据 issue 生成脚本，固定命令模板只能说明执行入口受到约束，不能单独证明生成脚本的行为安全。容器权限、网络和挂载如何限制，文章没有展开。

成本控制同样提前做了。复现脚本先过语法检查，解析器能在毫秒级发现的错误，就不必启动更慢、更贵的 Docker。

公开演示还设置了同时只处理 1 个任务、每个 IP 每天运行 2 次、全局上限 3 次的限制。原文没有明确全局上限的统计周期。这些限制在 Phase 2 就已加入，早于复现循环完成；宿主机是使用 AWS Activate 额度支付的 EC2 实例。

我的判断

我认同作者把判定契约放在模型选择前面。对复现 Agent 来说，用户真正需要的是可信的失败证据。即使换成更强的模型，检错提交、漏装依赖或误判输出，照样会让整个系统失效。

但「相信容器」还得再拆一层：容器提供运行事实，判定器负责解释事实。退出码不一定对应目标 Bug，出现相同报错也未必走到了预期路径。作者给出了正确方向，尚未公开足够细节来证明判定覆盖得完整。

模型比较也只能有限解读。作者使用相同的 10 个 issue，通过 Bedrock 对比 Claude Haiku 5.5 和 Qwen3-Coder，按相同规则统计成功数。更新给出了 Qwen3-Coder 的 7/10，却没有披露 Haiku 的成绩、耗时和费用，因此不能据此判断 Qwen 普遍更强或更划算。

相比让模型阅读日志后自行评估，确定性判定更容易审计；但对于输出波动大、依赖交互或缺少明确报错的问题，它需要更具体的断言。作者关于「先做样本、先定契约」的建议有实际缺陷作支撑，十个 Python 样本之外的适用范围仍需验证。

能拿来做什么

• 给 JavaScript 或 Node 复现流程保留修复前后的提交，用同一份脚本分别运行，确认失败确实会随修复消失。
• 给日常 AI 编程任务定义可观察的完成条件，例如指定测试失败、目标断言触发，并保存命令、提交和原始输出供复查。
• 把 issue、日志和提交信息当作不可信数据处理，检查它们是否被拼进执行命令，同时审查模型生成脚本的执行权限。
• 如果要开放运行代码的演示，先加入语法检查、任务并发限制和调用配额，再接入真实容器运行流程。