# 让 Agent 的进步留下可检查的痕迹 2026-10-17 · 独立研究笔记 给 Agent 换一套规则、让它多写几条审查意见，或者给训练任务准备更齐全的环境，都可能让演示变得顺畅。真正用起来，还会遇到另一组问题：旧任务有没有悄悄退步，人是不是花了更多时间检查，模型离开熟悉的辅助以后还能不能做。这几类困惑在知识库的不同讨论里反复出现，值得放在一起找切入点。 这期接着此前留下的三个方向，重新查看了相关工作。新的发现没有让它们失去价值，倒是改变了值得做的部分：预算内选测试已有工具，审查证据的价值已有研究议程，外部程序替模型完成决策也已有审计方法。我们可以借这些工作起步，把力气用在具体缺口、实用改进和有意思的复现上。 下面先讲别人做到了哪里，再列出几个可以继续探索的方向。如果想尽快动手，先看第一条；如果更关心人与工具怎样配合，第二条更合适；第三条适合从评测复现逐步走向训练研究。这些是选题线索，不是我们已经做出的实验结果，也不急着把它们定成完整课题。 ## 给 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 日：把失败留下来，也要看见退步](https://lcbreathe.github.io/ai-digest/reports/2026-10-16.html#connection-1) - [回看 Mason 的回复与编辑评读](https://lcbreathe.github.io/ai-digest/reports/2026-10-16.html#item-x-2110612969071714613) - [10 月 11 日：检查通过保证了什么](https://lcbreathe.github.io/ai-digest/reports/2026-10-11.html#connection-1) ### 来源与查新记录 - [Mason Mosen · 规则修改后的旧失败回放]() · 2026-10-17 · 本轮回读 10 月 16 日采集的公开回复与父帖语境；没有重新取得 X 实时页面，不作为效果实验。 - [原讨论 · CopperForgeAI 代码清理帖]() · 2026-10-17 · 用于保留回复语境，不把父帖规模说法当成本方向的验证。 - [Cortex · Measurement-Gated Evolution and Pruning]() · 2026-10-17 · 复查 v1 的执行暴露记录、保护任务和门禁部分；原论文已有回归保护，不声称缺少这项设计。 - [DeltaSelect · 项目与运行入口]() · 2026-10-17 · 查看预算选择、固定权重、导出与运行流程；未实际执行它的评测。 - [DeltaSelect · 方法与局限]() · 2026-10-17 · 查阅选择规则及 §6：相关性选择可能漏掉罕见能力；本文没有完成等成本选择器的全面比较。 - [Microsoft Research · Agent Skills Can Be Harmful]() · 2026-10-17 · 读取研究院论文介绍：已有技能差分归因及 SkillTriage。未声称检查过其完整实现。 ## 让审查机器人交证据，而不只是交意见 工程方向 · 人机协作 · Code Review / Human-AI Interaction / Executable Evidence 机器人发现问题之后，人的工作才刚开始。把改动、复现、检查范围和责任人放在同一条阅读路径里，可能比增加评论数量更值得做。 ### 他们已经做了什么 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，把父版本和候选版本的复现放在一起，问熟悉项目的人：哪些材料让你少找了一次上下文，哪些只是重复了你已经知道的事。若采用代码执行，分析环境与发布评论的权限应分开，不让待审代码拿到发布凭据。 ### 暂时不往哪里走 不把“用户更喜欢这个界面”直接写成“审查更准确”，也不把合并等待时间等同于人的实际工作时间。最新问卷已经提出证据包的研究议程；本方向的吸引力在具体实现、使用体验和可复查材料，而不在抢占一个全新的概念。 ### 回看线索 - [10 月 11 日：完成任务后，人还剩多少工作](https://lcbreathe.github.io/ai-digest/reports/2026-10-11.html#connection-3) - [10 月 13 日：Vapi 的实践与不同统计口径](https://lcbreathe.github.io/ai-digest/reports/2026-10-13.html#item-4d0e46591f3a8d65) - [10 月 13 日：生成、审查和交付](https://lcbreathe.github.io/ai-digest/reports/2026-10-13.html#connection-1) ### 来源与查新记录 - [Vapi · How an in-house review bot cut our PR merge time in half]() · 2026-10-17 · 回查原始工程文章，与库内 10 月 13 日记录对照；团队前后自报不是随机实验，本文不复述为普遍提效比例。 - [Plausible Is Not Enough · 论文与版本]() · 2026-10-17 · 确认 v1 发布于 10 月 15 日；239 人、31 国是问卷样本，不是界面对照实验。 - [Plausible Is Not Enough · 工作流讨论与局限]() · 2026-10-17 · 实际读取 §5.5 与 §6.1。作者已经提出证据包、来源归属及受控审查研究，故本轮不再宣称这一宽泛问题原创。 - [When Help Hurts · CHI 2026]() · 2026-10-17 · 读取 ACM 检索返回的界面比较、verification-load 和方法段落；对象是编程助手使用，不直接等同于 PR 审查。 - [MetaMateCR · 论文版本]() · 2026-10-17 · 本轮确认论文版本，结合此前工作台读取的展示方式研究作为相关工作；没有新做统计复核，不在本稿引用争议百分比。 ## 分清模型学会了，还是环境已经替它做了 研究方向 · 先看评测复现 · Agent Training / Scaffolding / Behavioral Evaluation / Transfer 长轨迹和高成功率不一定说明目标能力经过了练习。可以从已有的环境审计出发，观察哪些辅助让任务变得可学，哪些辅助把关键选择也一并拿走了。 ### 他们已经做了什么 TerminalHorizon 在构造终端训练任务时，会检查环境是否已经把本应由 Agent 完成的工作做好，再重建缺失的任务内容。它让“训练样本是否有足够工作可做”成为一个具体问题。但提供帮助并不天然有害：PATS 把技能当作可调整的训练辅助，随策略变化修改提示，并在部署时去掉辅助。两者提醒我们，不应只按提示多少或轨迹长短判断数据好坏。 这次找到的 The Double Measurement Confound in Agent Benchmarks 则更直接。作者区分关键决策由模型还是外部程序完成，同时检查评分器究竟在验证行为正确，还是只验证输出形式。它已经提供了 BenchAudit 的审计思路。因此，单纯提出“检查外部支架是否代替模型做事”并不新；有意思的是把这种检查带到训练数据选择和学习迁移的问题上。 ### 为什么把这些线索放在一起 10 月 14 日的知识库观察把 TerminalHorizon、分阶段起点和分枝训练放在一起，关心的是辅助之后还剩什么需要学习。另一个长期问题则提醒我们，检查通过未必覆盖想要的承诺。两条线在这里汇合：训练任务通过，和模型学会了我们希望它掌握的判断，并不是同一件事。 以时间处理为例，任务可能要求根据输入判断时区，但模板已经写死转换方式。模型仍能读文件、运行脚本、修格式，留下不少步骤。改变输入条件后，它会不会改变实际处理方式，比“有没有一大段推理”更值得看。这个例子是帮助选题的构造，不是 TerminalHorizon 已报告的失败。 ### 可以往哪些方向走 最容易起步的是复现一个“排行榜被环境掩盖”的小案例。沿着 BenchAudit 的思路，把外部程序替模型做的步骤和最终评分分别拆开，看结论会不会变化。这样的复现本身就有教学和评测工程价值，可以让人直观看懂一个高分究竟来自哪里。 更偏研究的方向是用任务的关键变化检查训练数据。输入事实发生变化时，正确动作应该随之改变；只改措辞时，动作则未必需要变。CheckList 早就使用过这类行为测试思路，不必发明新的术语。值得继续探索的是：这些检查能否帮助找到“看似完成、实际没练到目标能力”的训练样本。 再往前一步，可以研究辅助怎样逐渐撤掉，而不是简单比较有无辅助。对弱模型，完全没有支架可能根本拿不到有效反馈；对于已经掌握的步骤，持续给出答案又可能没必要。把 PATS 一类自适应辅助与环境审计联系起来，追问什么时候保留帮助、什么时候把选择还给模型，是比“支架越少越好”更有意思的方向。 ### 值得做在哪里 这条既有一个小而直观的复现入口，也有继续深入训练研究的空间。工程上可以做成数据集的审计说明，告诉使用者任务主要练什么、哪些步骤已经被工具代做。研究上更值得关心的是审计结果与新任务表现的关系，而不是只提出一个新分数。若能帮助筛出少量真正有训练价值的任务，即便不产生新模型架构，也可能很有用。 ### 从哪里开始看 先读 BenchAudit 的审计条件与局限，再回看 TerminalHorizon 的环境处理，最后读 PATS 的辅助调整思路。实践可以从一个数据清洗或接口适配任务开始：保留可执行环境，只改变一处会影响正确处理方式的条件，比较模型的实际动作。先弄懂一个案例，再决定是否需要训练实验。 ### 暂时不往哪里走 不把环境不一致、过期模板或运行失败都解释成模型没有学会；也不把额外辅助一律当作数据泄漏。现有近邻工作已经覆盖行为测试和支架审计，继续深入时应聚焦它们如何帮助训练，而不是再造同义的审计名字。 ### 回看线索 - [10 月 14 日：训练环境留下了哪些工作](https://lcbreathe.github.io/ai-digest/reports/2026-10-14.html#connection-1) - [10 月 11 日：一次通过的保证范围](https://lcbreathe.github.io/ai-digest/reports/2026-10-11.html#connection-1) ### 来源与查新记录 - [TerminalHorizon · Scaling Agentic Data for Long-Horizon Terminal Intelligence]() · 2026-10-17 · 复查环境构造与 §4.3 的实验范围，未据此声称已经隔离出所有环境因素的训练收益。 - [The Double Measurement Confound · BenchAudit]() · 2026-10-17 · 读取引言、审计卡与 §6 局限。已有决策归属和评分有效性的联合审计；跨领域及训练迁移不由该结果自动成立。 - [PATS · Policy-Aware Training Scaffolding]() · 2026-10-17 · 核对当前 v2 摘要及版本历史，确认动态训练辅助与部署时移除；未读取完整实现，不将它列为已跑通复现。 - [CheckList · Beyond Accuracy]() · 2026-10-17 · ACL 原始论文页提供既有行为测试背景；方向性变化与不变性测试不是本期新发明。 ## 暂不投入的方向 把上下文压缩做成另一个总成本排行榜：库内已经积累了缓存、回读和完整任务成本的讨论。单独再证明一次“少 token 不一定更便宜”，目前不足以形成新的推荐重点；以后若找到可复现的多语言检索失效或版本变化，可以按有用的专项复现重新选入。 为每个 RAG 失败都增加一套新组件：关于同名实体的社媒讨论很有启发，但纯向量、混合检索、业务过滤和重排解决的问题不同。没有可用失败集时，泛泛推荐“再加一个 Agent 或知识图谱”太空。先把真实失败和中间检索结果积累起来，比急着命名新架构更值得做。