让 Agent 的进步留下可检查的痕迹

给 Agent 的规则更新配一份“旧成功保护清单”

不只重跑以前失败的任务，也挑出最可能被新规则误伤的旧成功。已有工具能帮助少跑一些测试，值得补的是“这次改动最容易伤到谁”。

他们已经做了什么

知识库里的起点是一条很朴素的实践经验。Mason Mosen 在代码清理帖的回复中提到，自己改 prompt 后会回放同一批旧失败，避免把某一轮运气好当作进步。它提出了一个好习惯，但没有提供任务集或对照结果。Cortex 则把规则和技能更新做成了更完整的门禁：既看改善，也保护原本通过的任务，并记录规则是否真正进入了执行过程。它已经有回归检查，不能把“防止旧任务变差”说成一片空白。

这次查到的 DeltaSelect 更接近原先的预算设想。它利用历史运行结果，挑选一组在预算内、能反映整体表现的固定任务，支持对指令或技能改动做反复比较。作者同时提醒：与总体成绩相关的任务，不一定覆盖罕见能力。微软研究院的 SkillTriage 工作又从配对运行中归因技能带来的失败和额外成本。这些都是可以借用的基础，不必从零再造一套通用评测框架。

为什么把这些线索放在一起

旧观察一直在问：一次检查通过，到底排除了什么？放到规则更新上，问题就具体了。假如为了修复重复记录，给 Agent 加上“同一个 ID 只保留一条”的规则，原先需要保留同 ID 多次合法更新的任务可能反而出错。这个例子是我们构造的，但它对应的张力很真实：解决一个失败的经验，可能被推广到了不该适用的地方。

再接上知识库的成本线索，保护旧成功也不能简单理解成每次跑完整任务库。重点是让有限预算用在可能改变结论的地方：哪些任务与这条规则有关，哪些任务恰好是它的例外，哪些其实完全没被规则影响。

可以往哪些方向走

一个方向是把“规则—适用条件—例外任务”连起来。更新规则时，除了附上原失败，再附上少量容易被它误伤的旧成功。可以先由维护者写这些关系，后续再考虑自动推荐，不必一开始就训练复杂选择器。

另一个方向是把通用小测试集和专项保护集组合使用。前者帮助判断总体变化，后者专门盯少见却重要的约束，例如合法重复、已经转换过的时区、允许访问的本地测试服务。值得了解的是两种测试各自能抓到什么，而不是先假定新的选法一定胜过随机抽样。

还有一个很实用的方向是解释“本次没测出差别”。是规则没有被加载，还是相关任务没选进来，或确实没有明显变化？把这几种情况在更新记录里分开，往往比再给一个总分更能帮助开发者决定下一步。

值得做在哪里

这条更适合按工程价值判断。即使最终只是把 Cortex 的更新记录、DeltaSelect 的预算选择和人工维护的例外任务接起来，也可能减少 prompt 改动后的排错。它对频繁维护 AGENTS.md、技能文件和工具规则的人尤其有用。研究上的进一步空间在于：规则特有的风险信号，能否补上通用测试选择遗漏的部分；这可以留到有实际案例后再深挖。

从哪里开始看

先看 DeltaSelect 的任务选择与导出流程，再对照 Cortex 的保护任务和执行记录。找一次自己确实遇到过的规则改动，保留改动前后的版本、原失败和几个旧成功，用已有运行器重放，看看哪些变化能被解释清楚。能交付一份读得懂的差异报告，就已经是一个有用的小项目。

暂时不往哪里走

不把回归测试、预算选题或技能失败归因重新命名为创新；也不为了保护所有旧行为而阻止合理的新需求。规则的适用范围和任务目标都可能变化，清单要帮助人判断，不是把旧结果永久冻结。

让审查机器人交证据，而不只是交意见

机器人发现问题之后，人的工作才刚开始。把改动、复现、检查范围和责任人放在同一条阅读路径里，可能比增加评论数量更值得做。

他们已经做了什么

Vapi 的审查机器人会追踪代码、运行测试或小复现，再决定是否评论。团队的经验里，一个很重要的调整是提高误报的代价：每条多出来的意见，无论真假都需要人处理。因此，“让机器人提供可执行证据”已经有工程实践，不是新的概念。

这次还找到 10 月 15 日的 Plausible Is Not Enough。作者调查了 31 个国家的 239 位从业者，讨论 AI 生成的 PR——也就是待合并代码变更——怎样取得审阅者信任。论文不仅提到测试与上下文，也强调人要知道谁负责、哪些主张经过独立核验。它已明确建议研究证据包如何影响人的决定，所以不能把“给审阅者更多证据”本身包装成原创想法。

CHI 的 When Help Hurts 则把注意力放到使用编程助手时的核验负担，比较不同界面并记录行为。这些工作支持把人的检查过程当作设计对象，而不是只看模型输出是否漂亮；它们并没有替我们证明某一种代码审查页面一定更省事。

为什么把这些线索放在一起

这个方向不是从一篇新论文单独生长出来的。10 月 11 日的观察里，Simon 用语音完成一部分开发后仍要回到键盘审查；几天后，Vapi 的经验又说明大量建议可能增加核验工作。两者共同指出一种交接问题：机器知道自己刚才做过什么，人接手时却要重新拼上下文。

我更感兴趣的不是继续缩短摘要，而是减少人为了判断一条意见而来回找东西。比如“这个 PR 破坏了重复输入处理”是一句话，但审阅者还需要知道哪组输入能复现、父版本怎样、候选版本怎样、测试是否真的运行，以及这个缺陷是否本来就存在。把这些材料接起来，才可能减少一段真实工作。

可以往哪些方向走

可以先做“可复查的审查卡”。每条重要意见直接连到相关改动、最小复现和父/新版本差异，明确哪些是运行结果，哪些只是机器人推测。修复建议可以保留，但不必抢在证据前面；审阅者首先需要决定问题是否成立。

第二个方向是按风险组织交接，而不是把所有发现平铺。普通样式建议与数据迁移、权限、并发错误需要的证据不同；把必须阻断合并的问题与顺手可修的问题分开，可能比给每条意见再加一个置信度更有用。

第三个方向可以从一次小型复现开始：让相同的发现分别以普通评论、完整证据页、先看关键差异的方式呈现，观察人在哪里来回翻页、哪些信息反而妨碍判断。这里值得积累的是具体交互经验。愿意进一步研究时，再讨论哪些人和哪些任务真正受益。

值得做在哪里

工程上可以把它做成 PR 模板、审查机器人插件，甚至只是一个静态报告生成器。它不要求新模型，价值来自更好的交接。研究上则可以继续追问“增加证据”和“增加阅读负担”之间的分界，但不必现在就把实验设计钉死。若只能完成一件事，我会优先做一份维护者能直接拿来核查的真实变更报告。

从哪里开始看

先读 Vapi 的实践文章，再看 Plausible Is Not Enough 的工作流讨论。挑一个可公开的小 PR，把父版本和候选版本的复现放在一起，问熟悉项目的人：哪些材料让你少找了一次上下文，哪些只是重复了你已经知道的事。若采用代码执行，分析环境与发布评论的权限应分开，不让待审代码拿到发布凭据。

暂时不往哪里走

不把“用户更喜欢这个界面”直接写成“审查更准确”，也不把合并等待时间等同于人的实际工作时间。最新问卷已经提出证据包的研究议程；本方向的吸引力在具体实现、使用体验和可复查材料，而不在抢占一个全新的概念。

分清模型学会了，还是环境已经替它做了

长轨迹和高成功率不一定说明目标能力经过了练习。可以从已有的环境审计出发，观察哪些辅助让任务变得可学，哪些辅助把关键选择也一并拿走了。

他们已经做了什么

TerminalHorizon 在构造终端训练任务时，会检查环境是否已经把本应由 Agent 完成的工作做好，再重建缺失的任务内容。它让“训练样本是否有足够工作可做”成为一个具体问题。但提供帮助并不天然有害：PATS 把技能当作可调整的训练辅助，随策略变化修改提示，并在部署时去掉辅助。两者提醒我们，不应只按提示多少或轨迹长短判断数据好坏。

这次找到的 The Double Measurement Confound in Agent Benchmarks 则更直接。作者区分关键决策由模型还是外部程序完成，同时检查评分器究竟在验证行为正确，还是只验证输出形式。它已经提供了 BenchAudit 的审计思路。因此，单纯提出“检查外部支架是否代替模型做事”并不新；有意思的是把这种检查带到训练数据选择和学习迁移的问题上。

为什么把这些线索放在一起

10 月 14 日的知识库观察把 TerminalHorizon、分阶段起点和分枝训练放在一起，关心的是辅助之后还剩什么需要学习。另一个长期问题则提醒我们，检查通过未必覆盖想要的承诺。两条线在这里汇合：训练任务通过，和模型学会了我们希望它掌握的判断，并不是同一件事。

以时间处理为例，任务可能要求根据输入判断时区，但模板已经写死转换方式。模型仍能读文件、运行脚本、修格式，留下不少步骤。改变输入条件后，它会不会改变实际处理方式，比“有没有一大段推理”更值得看。这个例子是帮助选题的构造，不是 TerminalHorizon 已报告的失败。

可以往哪些方向走

最容易起步的是复现一个“排行榜被环境掩盖”的小案例。沿着 BenchAudit 的思路，把外部程序替模型做的步骤和最终评分分别拆开，看结论会不会变化。这样的复现本身就有教学和评测工程价值，可以让人直观看懂一个高分究竟来自哪里。

更偏研究的方向是用任务的关键变化检查训练数据。输入事实发生变化时，正确动作应该随之改变；只改措辞时，动作则未必需要变。CheckList 早就使用过这类行为测试思路，不必发明新的术语。值得继续探索的是：这些检查能否帮助找到“看似完成、实际没练到目标能力”的训练样本。

再往前一步，可以研究辅助怎样逐渐撤掉，而不是简单比较有无辅助。对弱模型，完全没有支架可能根本拿不到有效反馈；对于已经掌握的步骤，持续给出答案又可能没必要。把 PATS 一类自适应辅助与环境审计联系起来，追问什么时候保留帮助、什么时候把选择还给模型，是比“支架越少越好”更有意思的方向。

值得做在哪里

这条既有一个小而直观的复现入口，也有继续深入训练研究的空间。工程上可以做成数据集的审计说明，告诉使用者任务主要练什么、哪些步骤已经被工具代做。研究上更值得关心的是审计结果与新任务表现的关系，而不是只提出一个新分数。若能帮助筛出少量真正有训练价值的任务，即便不产生新模型架构，也可能很有用。

从哪里开始看

先读 BenchAudit 的审计条件与局限，再回看 TerminalHorizon 的环境处理，最后读 PATS 的辅助调整思路。实践可以从一个数据清洗或接口适配任务开始：保留可执行环境，只改变一处会影响正确处理方式的条件，比较模型的实际动作。先弄懂一个案例，再决定是否需要训练实验。

暂时不往哪里走

不把环境不一致、过期模板或运行失败都解释成模型没有学会；也不把额外辅助一律当作数据泄漏。现有近邻工作已经覆盖行为测试和支架审计，继续深入时应聚焦它们如何帮助训练，而不是再造同义的审计名字。