码农早餐 · 2026-10-23

Trail of Bits 开源 patching-bugs 与 regression-hunt 两个 agent 插件

Trail of Bits 在 10 月 21 日发布两个插件：patching-bugs 负责复现 bug、写修复、跑测试，regression-hunt 负责检查改动有没有破坏此前正常且受支持的行为。两个插件都放在 GitHub 的 trailofbits/skills 仓库里，工程师可以指挥 agent 干活并审查结果，维护者可以把自己的安全假设和打补丁要求喂进去，让 agent 在项目规则内工作。原文给出的评估数字是：regression-hunt 比一个被要求「review the PR for regressions」的基线 Codex agent 少产生 25% 的误报，95% 置信区间 14% 到 38%。

这对插件的来历是 Trail of Bits 自己的补丁记录。9 月 15 日他们写过一篇文章，指出 1Password 的 AI patching benchmark 有误导性，因为自家 Patch the Planet 项目产出的补丁里就有引入回归的。之后他们复查了工程师编写、并被维护者合入上游的每一个补丁：130 多个合入的 PR 里确认了 21 个回归，其中 16 个功能性、1 个性能、4 个构建/测试，没有破坏安全防护。复查方式是让 agent 找潜在回归，用 PoC 在改动前后各跑一遍确认，再交给工程师看。这个流程噪音很大——21 个确认回归是从一次运行里的 58 个候选里挑出来的，精确率约 36%。原文由此得出两条结论：要有标准写法，也要有标准查法。

regression-hunt 的设计就是围绕「什么算回归」收紧的。它先把 diff 顺着调用方追到真实接口，列出候选回归；在系统真实部署上复现；由一个全新上下文的 agent 重放 PoC；最后判断证据是否满足回归的定义。举证责任压在 agent 身上，要排除误报、修不完整、潜伏 bug、既有 bug 等情况，全部通过才报。有威胁模型文档时，orchestrator 会把它作为全局上下文传给每一步。代价也写在原文里：严格的证据要求让一些已知回归停在「疑似」——识别到了但证据不够确认，所以误报变少的同时，能自信报出的已知回归数量也受了影响。原文说下一步要查这些案例为什么停在疑似。

放在最近几件事旁边看，问题指向同一个地方。10 月 17 日我们写过 Postgres 19 延期，原因是 AI 审查工具报出的问题数量超过了人能处理的速度；这里的 58 个候选对应 21 个确认、36% 精确率，是同一个问题的另一种量法。10 月 15 日 OpenCode 2.0 把终端 Agent 改成常驻后台服务，agent 从「问一句答一句」变成持续在仓库里动手的角色，它改了什么、改坏了什么，需要有独立的一层去查。10 月 18 日那篇讲 harness 决定缓存命中，说的是客户端拼 prompt 的方式直接决定账单和延迟；插件里「严格输入输出 schema、每步校验上一步而不是相信它的总结」是同一类工程约束，只不过约束的对象从 token 换成了补丁。

原文里还有一处值得单独拎出来：这 21 个回归没有一个是安全防护被破坏的。这个结论的范围要说准——它覆盖的是 Trail of Bits 工程师编写并经维护者合入的那 130 多个 PR，不是所有 AI 生成的补丁。对日常流程的实际牵动在于，agent 修 bug 这件事已经不只是「改对没有」，还要回答「还动了哪些没人看的地方」，而回答这个问题的成本目前落在人工筛候选上。

目前的状态是插件已公开，初步评估只跑了一个基线对比和一组 21 个已知回归。原文没有说这些插件在 Trail of Bits 之外的项目上跑过多少，也没有给出 patching-bugs 自身的量化结果——那部分正文被截断了，只有设计原则：尽量少的指令、模块化步骤、固定 schema、每个结论都要有对真实部署跑的 PoC。至于停在「疑似」的那些回归怎么处理，原文只说会继续查。

来源：

• Your AI agent fixed the bug, but what else did it change?

---

本文从过去 24h 的 X / Hacker News / GitHub Trending 共 53 条信息中选出这一件事展开。内容由 LLM 辅助生成并经事实校对，来龙去脉部分参考了本站往期内容，文末附原始来源链接，重要决策请交叉验证。