让 Agent 自我改进之前，先收回它的验收权

“让 Agent 自己反思、自己评测、自己优化”听起来很有吸引力。系统可以不断生成方案，分析结果，再把改进后的方案投入下一轮。人只需要设定目标，Agent 自己完成迭代。

但这里有一个容易被忽略的问题：如果生成方案、评测结果和达标判断都由同一个 Agent 掌握，它可能不是在改进能力，而是在改写自己面对的考卷。

这不是因为模型有意欺骗。只要目标函数不完整、评测样本固定、权限边界模糊，任何优化系统都可能朝着最容易提高指标的方向走。对 Agent 来说，这个过程发生得更快，也更难通过最终文字表面发现。

结合 Graph Engineering 实践和 Agent 评测资料，我想讨论一个简单但重要的原则：模型可以参与生成和分析，但能够被代码确定性验证的验收权，应尽量从模型手中收回来。（Graph Engineering 原文 ↗；Agent 评测方法论原文 ↗）

一、只看 badcase，Agent 很容易“修好考卷”#

Graph Engineering 文章讲了一个很有代表性的场景：系统根据商品 badcase 生成和优化体检规则。早期循环主要关注本轮 badcase 修复了多少。看起来，修复率上升就代表规则变好了。

但如果模型只能看到这一批 badcase，最省力的办法不一定是归纳业务规则，也可能是记住样本特征，把商品标题或具体枚举塞进规则。这样，当前样本的分数会提高，却没有形成可泛化的判断。

这个结果不能简单归咎于模型“作弊”。系统给出的目标本来就允许它这么做：只有修复样本被计分，正常样本有没有被误伤没有进入判据。模型找到了一个合法但不符合真实意图的优化方向。

这正是 Goodhart 风险在 Agent 系统中的具体形式：当一个指标变成目标，指标就可能不再准确代表目标。Agent 循环越快，目标偏差被放大的速度越快。

二、评测要同时看修复深度和附带伤害#

文章给出的改造很直接：把一次评测拆成两份不重叠的样本。

第一份是 badcase 集，观察本轮问题修复了多少；第二份是近期真实商品集，观察规则是否伤害了原本正常的样本。前者衡量修复深度，后者衡量泛化与附带影响。

可以用两个变化量表达：

• Δ_bad = 优化后 badcase 准确率 - 优化前 badcase 准确率
• Δ_pop = 优化后近期样本准确率 - 优化前近期样本准确率

再为两个方向配置阈值，就能形成四个结果区域：修复且无伤害、修复但有伤害、没有明显变化、两边都变差。

这里最值得注意的是“修复但有伤害”不能算成功。只看第一项时，它是一份漂亮的优化结果；加入第二项后，它应当被拒绝。因为这类方案隐藏得更深：它不是完全无效，而是在局部成功的同时破坏了系统原有能力。

这套方法不等于完整评测，也不意味着这些阈值适用于所有业务。阈值需要由业务风险和工程条件共同定义，样本还需要持续更新。它提供的是一个思路：验收要覆盖目标收益和主要副作用。

三、生成者不能自己给自己发合格证#

把生成与评测分开，不是为了增加组织流程，而是为了减少同一主体的盲区。

生成 Agent 负责提出规则、代码或测试方案；分析组件可以解释失败原因、归纳未覆盖的模式；代码评测负责执行测试、计算指标、比较阈值；发布负责人决定是否允许进入真实环境。每一层处理不同类型的判断。

模型仍然可以参与“这批失败样本可能有什么共性”这类语义任务。它也可以给出多个候选方案，并说明自己的假设。但“实际提升了多少”“是否超过阈值”“下一步进入哪个分支”，如果可以通过确定性计算得出，就不应该依赖模型自述。

原因很简单：模型的解释可以帮助人理解，却不能替代客观结果。一个候选方案说自己修复了 90% 的问题，不代表评测脚本真的得到 90%。如果系统根据这段文字继续发布，验收环节实际上被模型重写了。

这里还要区分“模型判断业务对象”与“模型判断自己是否达标”。商品是否符合某条开放语义规则，可能确实需要模型；但评测数量、阈值比较、状态迁移和发布门禁，往往可以由代码承担。把二者都叫作“判断”，容易把应当固定的部分一起交出去。

四、失败不是一句“不通过”#

如果评测失败后所有情况都回到“再试一次”，评测系统已经丢掉了最有价值的信息。

文章把失败拆成过拟合、badcase 未修复、规则形态作弊和无效等类型，并为它们设置不同路径。这个设计给我的启发是：评测不仅要给分，还要解释下一步应该改变什么。

过拟合需要检查正常样本与规则形态；未修复需要分析剩余 badcase 的共性；规则包含具体样本枚举，可能需要代码扫描；连续多轮无效，则应停止自动迭代并请求人工判断。

不同分析需要不同上下文。有的需要看商品内容，有的只需要看规则文本，有的只需要比较历史结果。把所有材料塞进一个超长 Prompt，既浪费上下文，也可能让确定性检查被模型摘要淹没。

因此，失败分析也应拆分：语义分析交给模型，格式、枚举、长度趋势、历史回归等可计算问题交给代码。最后由控制面汇总结果，而不是让一个 Agent 在长对话中自行决定下一步。

五、把“从哪一版继续”也从模型手中收回来#

一个容易低估的决定是：失败后，下一轮从哪一版规则或代码开始。

如果把所有历史版本和评测结果交给模型，让它自己选择基础版本，它可能优先选择最容易提高当前指标的版本，而不是最适合长期修复的版本。两者并不总是一致。

例如，一版规则虽然整体通过，但包含明显的硬编码；另一版暂时没有通过，却已经删除了硬编码，只剩下语义覆盖不足。下一轮从哪一版开始，实际上决定了工程方向。

这类选择可以由明确状态和函数处理：没有历史时从线上版本开始；上一轮通过时从上一轮版本开始；规则形态不合格时回到最后一个良好版本，并带入具体限制；连续失败达到上限时停止自动迭代。

这样做不是否定模型分析，而是把流程状态从自然语言叙述中分离出来。模型可以解释“为什么失败”，代码根据状态决定“允许从哪里继续”。

六、经验沉淀不能由方案生成者自评#

Agent 自我改进还会遇到一个记忆问题。每一轮失败反馈都可以告诉下一轮“不要重复这个方向”，但这种反馈只适合短期使用。长期经验则需要更谨慎地形成。

Graph Engineering 文章区分了两类信息：紧接下一轮使用的失败反馈，以及经过评测支持后写入经验库的反模式和有效策略。（原文 ↗） 这个区分很有用，因为临时上下文不一定值得长期保存。

更重要的是，生成方案的 Agent 不应同时为自己的方案写评价。否则只是把自评从当前响应移动到经验库，下一轮再把它当作“历史事实”召回。

经验应在评测完成后，由独立分析流程基于优化前后结果总结；写入时带上证据和适用范围；未来使用后还要根据结果修正、降权或撤回。能够影响后续动作的记忆，不应只保存一句成功宣言。

七、Graph 的价值不在画出更多节点#

“Graph Engineering”容易被理解成把 Loop 改写成图，把每一步画成节点。但如果节点内部仍由模型自由决定所有状态和分支，图的外观不会自动带来治理。

我更愿意把 Graph 理解为责任边界的显式表达：谁产生候选，谁验证结果，谁决定是否继续，谁负责发布，失败后有哪些出口，哪些状态可以回滚。

自由循环仍然有价值。探索未知问题、归纳样本共性和生成候选方案，可能需要模型多轮尝试。但循环应当处在一个外层控制面中，受到轮次、成本、环境、权限和验收条件约束。

因此，工程重点不是“Loop 还是 Graph”这个名词选择，而是确定性控制是否被外显。节点、边、状态和失败路由只是表达方式；真正重要的是它们能否被审查、测试和追责。

八、把自主权拆成动作，而不是整包授予#

“让 Agent 自主”不是一个二元开关。可以把自主权拆成不同动作：读取资料、提出候选、运行只读检查、修改工作区、提交变更、触发部署、改变阈值、批准上线。

这些动作的风险不同。模型可以在沙箱中自由探索；修改代码需要差异审查；写入外部系统需要幂等、权限和确认；改变评测阈值更不能由被评测的 Agent 自己完成。

我认为，权限边界应与证据边界一起设计。Agent 看到什么，决定它能提出哪些方案；它能执行什么，决定哪些副作用可能发生；系统如何验收，决定哪些结果可以进入下一状态。

如果只给模型更多工具，却不给出清晰的状态和回滚，所谓自主性可能只是把风险推给下一环节。如果只增加审批，而没有提供可理解的证据，人也会陷入审核疲劳。

九、如何设计一个不容易自欺的最小闭环#

如果从零开始，我不会一上来做完整的自进化平台，而会先选择一个目标明确、结果可验证的任务。

第一步，固定一个代表性任务集，并把正常样本、失败样本和边界样本分开。第二步，保留一个模型不能修改的验收脚本，输出结构化结果。第三步，允许 Agent 生成候选，但限制它只能修改工作区或候选配置。第四步，把失败拆成几类，分别进入分析路径。第五步，设置轮次和成本上限，连续失败时转人工。第六步，只有通过客观评测的候选才进入人工发布确认。

随后再补充长期记忆、版本对照和线上反馈。每次扩展都要问：新增能力是否也新增了可验证证据？如果只是让系统能做更多动作，却没有增加观察和恢复能力，可靠性可能反而下降。

评测集本身也需要维护。它不能永远固定，否则 Agent 会逐渐适应题库；也不能完全随机，否则结果难以比较。可以保留稳定回归集，同时加入近期自然样本和历史事故，并记录样本版本。

结语：先让验收独立，再讨论自我进化#

我并不反对 Agent 自我改进。相反，生成、反思和迭代可能是 Agent 获得长期收益的重要方式。但自我改进的前提不是“模型愿意反思”，而是系统有一套模型无法随意改写的验收机制。

模型擅长处理开放语义：归纳、解释、提出假设和生成候选。代码擅长处理确定规则：计数、比较、状态迁移、格式检查、版本约束和权限门禁。人负责目标、风险和高影响发布。

这三者不是谁替代谁，而是把不同类型的判断放到更合适的位置。

如果 Agent 既负责出题、答题，又负责宣布自己满分，我得到的可能只是更会适应考卷的系统。只有先把验收权收回来，系统才有资格谈自我改进。