2026-10-17

本期研究想法

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

工程探索 · 可从复现开始 · Agent Skills / Regression Testing / Evaluation Budget

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

他们已经做了什么

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

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

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

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

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

可以往哪些方向走

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

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

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

值得做在哪里

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

从哪里开始看

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

暂时不往哪里走

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

回看线索

来源与查新记录

回看:10 月 16 日:把失败留下来,也要看见退步

回看:回看 Mason 的回复与编辑评读

回看:10 月 11 日:检查通过保证了什么