原始来源：Trail of Bits
发现渠道：Hacker News · 原讨论
Trail of Bits 发布 patching-bugs 与 regression-hunt，分别帮助开发补丁和寻找补丁造成的新缺陷。“回归”在这里有严格含义：原来正确且受支持的行为，被这次改动破坏，而且真实用户或攻击者能够触达那条路径。旧缺陷、修复不完整和不受支持的用法，不能都算成新回归。
修补流程先复现报告，再围绕被破坏的安全约束修改代码，并采用三组验证：旧代码失败、补丁后通过、完全撤销补丁后再次失败。这样能更有力地区分“补丁确实修好”与环境或测试恰好变化。回归检查则从改动追到调用方和实际入口，在实际运行环境中复现前后差别，换一个新上下文的 Agent 重放，再由裁定步骤检查证据是否符合定义。每一步传递代码版本、原始证据和未解问题。
作者复查自己参与且已合入的 130 多个 PR，确认 21 个回归，涉及功能、性能、构建或测试。在这些已知案例上的初步比较中，regression-hunt 比仅提示基础 Agent 审查回归少产生 25% 的误报，报告的 95% 置信区间为 14%–38%。严格举证也使部分真实回归停留在证据不足状态；这个结果不能读成整体检出能力提高 25%。
可信度 65 · 重要性 88 · 新颖度 84
技术与主题
Agent 系统 · AI 编程 · 评测与基准 · Regression Testing · Proof of Concept · Agent Tools
Dan Guido（dguido）
在本文 HN 讨论中解释工具定位；Trail of Bits 负责人，与项目有关联。
忠实转述（非原句）：他认为漏洞到利用之间的成本正在降低，产品负责人需要提高收到报告后的修补速度。他甚至判断协调披露的作用正在缩小，建议采用团队的修补与回归检查工具。回应质疑时，他同意快速打补丁不能替代减少攻击面；即使设计更安全的软件，也需要响应新发现。
marcosdumay
回应 Dan Guido 对修补速度的强调；属于原则性反驳，不是插件实测。
忠实转述（非原句）：他反对把发现一个漏洞就修一个的做法，当作把脆弱软件变安全的充分方法。漏洞发现得更快，并没有改变这个问题。
编辑评读
最值得借用的是把“再检查一次”改成可以交换和重放的证据。新的 Agent 仍可能和前一个犯相同错误，但它面对的是具体版本、入口和运行记录，能够重新判断主张，而不是只读上一位的总结。三组验证还增加了撤销操作：若撤销以后错误没有回来，就需要重新检查所谓修复的因果解释。
这套方法与单纯增加审查意见数量有不同目标。原复查从 58 个候选中确认 21 个回归，说明工程师必须花时间处理大量未成立的发现；减少误报有真实价值。但这批案例来自团队已合入的安全补丁，且工具把部分真问题留为边界案例，不能据此保证任何仓库都获得同样净收益。
对维护团队而言，可迁移的做法是先写清受支持行为与安全边界，再要求重要结论附能复查的变化证据。验收对象仍是完整补丁：修好原问题、没有损害需要保留的行为、剩余疑点可以被人接手。这些检查是对速度的支持条件，不能靠一个“已完成”状态替代。