从失败到工程资产

失败只有变成 Schema、Validator、Gate、Linter 或回归测试才算修完；在 prompt 里加一句警告，等于把约束交给了下一次的概率。

失败只有变成 Schema、Validator、Gate、Linter 或回归测试，才算修完。在 prompt 里加一句「注意不要……」什么也没修——它只是把约束交给了下一次的概率。

加一句警告不等于修

从失败到资产的链路是固定的：Failure → Incident → Root Cause → Corrective Action → Test/Eval → Rule/Gate/Binding/Tool/Experience → 发布与回滚。

四条规定要一起守：记录失败场景、期望行为、实际行为和证据；优先修改系统结构；把修复转化成回归测试或 Eval；不允许只用 prompt 警告完成根因修复。

为什么 prompt 警告不算修？因为它既没有执行机制，也不产生信号——拦不住下一次，也没法告诉你它是否曾生效。而 Gate 和 Validator 两者都有：能拦，也能统计拦了多少次。

顺带一条最容易踩的坑，来自 Skill 的四层验证：结果正确，但绕过了关键校验步骤——下次必翻车。结果对了不代表修好了，路径对了才算。

回归用例有两种形态

失败回流成回归用例有三条采集通道：用户明确纠正、用户点踩，以及事后由状态检查、规则验证器或 LLM 评审发现的问题案例。三条都要先经失败归因再沉淀成用例。这个来源成本最高，准确性也最高——它直接来自用户真的遇到过的问题 ai-agent-book。

沉淀下来的用例有两种形态。端到端回归从初始状态一路跑到最终断言，覆盖完整但慢；轨迹前缀回归把已有的上下文、对话、工具返回和环境状态冻结，只要求 Agent 输出下一步或接下来几步可观察动作，成本更低，而且能把问题隔离到单个策略或单个工具。对要求高可靠的生产 Agent，前缀回归集往往比端到端回归集更值得先建——前提是你先有一套能按类切片的失败分类体系，上线看什么指标 里的四类冒烟失败就是一个起点 ai-agent-book。

归因记录本身要结构化，不能只留一句「失败原因」：用 JSON 或 YAML，引用具体步骤号、工具名和观察证据，区分根因与后果，并判断是否可恢复、给出置信度。一个典型例子：edit_file 返回 old_string 匹配失败，之后 Agent 连续三次重试仍未写入文件——主因是「文件编辑与工具调用错误」，那三次重试是后果，不是三个独立根因；多个类别同时出现时，取最早且能解释后续失败的那个做主因，其余留作次因。规模化时用「规则先筛、LLM 再定位」的分工，比把全部轨迹喂给 LLM 更便宜也更准。有三类筛子可以直接写成规则：完成声明与实际执行命令交叉核对、diff 是否触及测试断言或 skip 标记、diff 是否改动了公开 API 或 schema 却没有迁移文件 ai-agent-book。

从 Lesson 到 Active Rule

升级链路是 Incident → Lesson → Cross-case Pattern → Candidate Rule → Regression Eval → Scoped Activation → Active Rule。

两个关键点决定了这条链是资产还是负担。第一，pattern 必须在多个独立 case 中验证，不能按固定出现次数自动升级——同一根因出现三次，可能只是同一任务被跑了三次。第二，P0/P1 升级由人批准，Candidate Rule 必须写清 scope、owner、误拦风险和执行机制。

P0/P1 规则还要有三样东西：稳定的 Rule ID 和版本号、确定性检查优先于模型 Grader 的执行机制、固化到 Workflow 或 CI 的阻断 Gate，并且要防止 Agent 自己跳过适用的 Gate。

Anthropic 那次事故之后的处置就是这个形状：收紧 system prompt 变更流程，每次改动跑全套 per-model eval 加持续 ablation，新建 prompt 变更审计工具，把改动按模型 gate 住；凡是牺牲智能换性能的改动，一律加 soak period 和灰度 anthropic-postmortem。

更极端的样本来自 Steve Yegge：他用 50–60 个 agent 组成开发组织，这套组织自发建成了 450 个「法律工件」——宪法、判例、裁定，以及 fence、gate、ratchet、tripwire 这类执行机制。规则生命周期是 custom → advisory → written law → mechanical enforcement，每被重新违反一次就收紧一级，终点是程序直接拒绝。他最重要的发现是另一条：规则体系必须持续修剪，否则熵增 yegge-fences。

经验的生命周期

经验的完整链路是：Trace 采集 → 脱敏与 Trajectory 组装 → 失败聚类 → 候选经验 → 离线 Eval → Shadow/Canary → 激活 → 召回 → 监控 → 降权/暂停/回滚。

四条红线：自动挖掘的结果先标 CANDIDATE，经过独立 Eval 才能进 ACTIVE；不要让生产运行自动生成并立即激活经验；必须支持一键暂停和回滚；经验不得绕过安全、权限、审批或业务规则。

召回的顺序也不能反：先做权限和范围过滤，再做相关性排序；只注入少量、可执行的经验，并设召回 token 预算；不要把完整历史 Trajectory 灌进当前上下文——那是在用最贵的方式制造噪声。

一个可复制的实现：阿里把 SKILL.md 的自进化做成了四层 Gate——Target（要修的至少变好一个）→ Guardrail（原本做对的一个都不能错）→ Holdout（每五轮查一次从未参与诊断的隐藏集，F1 掉超 1% 就拒）→ Verify（文本质量达标）。诊断全用确定性规则，LLM 只负责把结论转写成 diff；再配一张 taboo 黑名单，被拒 patch 的签名跨版本跨分支共享，回滚也不清空 alibaba-skill-evol。四层 Gate 与数据三分割如何嵌进评测闭环、哪些约束不可省，在线与离线两条腿 给出完整版。

Harness 熵与规则债

强模型时代，冗余指令从中性浪费变成了主动的质量损失：过度规定会缩小模型的搜索空间、被字面执行、导致过度触发。维护重点因此从「规定路径」转向「定义成功判据」——目标、判据和约束写死，路径留给模型。

定期体检清单：规则文件的长度、重复与冲突规则、无命中规则、失效命令和 Skill、断开的文档引用、Gate 长期被跳过或恒定通过、知识与代码的版本漂移。

删除同样要守纪律：清理任务要生成 diff 和证据，删除规则和 Gate 也要跑回归 Eval。只加不减的规则体系，最后会变成没人读得完、也没人敢动的债。

飞轮的阶段定位

自进化分三层，先想清楚你在哪一层：Artifacts 迭代（打草稿，不沉淀）/ Harness 自改进（主战场：记忆、Skill、Prompt、工具配置，改一次后续全受益，即时生效可回滚）/ Model 进化（成本最高，仍在研究阶段）。多数团队该投的是中间那层。

核心论断只有一句：评测的可信度 > 系统的复杂度。错误的正反馈会让 Agent 加速学错——相当于加速开往悬崖。所以顺序是先把评测校准好（人机一致率达阈值才允许机评规模化），再谈自动进化，而不是反过来。

取舍要讲明白：飞轮的代价是基建（trace、Eval、灰度、回滚）加持续修剪的人力；它不适用于任务输出无法客观判定对错、或一个月跑不了几轮的团队。检查方法很朴素——数一下过去一个月的失败里，有多少变成了 Gate、Validator 或回归测试。这个数接近零，说明系统没有在变好，只是在变旧。