第十三章 Skill：Harness 的持续改进机制
核心命题：第十二章给出了度量 Harness 效果的工具——评估数据告诉你系统当前的行为分布是什么形状。但度量本身不产生改进；改进需要一种机制，将评估中识别的有效模式转化为可复用的知识，沉淀进 Harness 的持续演化。Skill 是这个机制：它是 Harness 的知识积累层，将跨任务的运行经验系统化保留和传播，使 Harness 的演化从”每次从头摸索”转变为”在已验证知识的基础上持续迭代”。
在单任务视角下，Skill 是 Context Engineering 的按需加载工具；在组织视角下，Skill 是 Harness 的演化引擎——它决定了一个团队能否将今天的经验转化为明天的结构性优势，还是只能在同样的问题上反复支付相同的搜索成本。本章将 Skill 从”运行时构件”重新定位为”演化机制”：其核心价值在于组织积累的规模效应，而非单次任务的效率增益。
13.1 Skill 的本质：从人类经验到 Agent 知识
人类在解决一类问题时积累了大量隐性知识：哪些行动序列有效、哪些上下文是关键的、哪些陷阱需要提前规避。这些知识通常散落在个人经验、团队惯例和文档之中，无法被 Agent 直接利用。Skill 是将这些已知经验显式化、结构化并同步给 Agent 的机制——它的价值不在于”制度”，而在于人类认知的可传递性。
Skill 设计模板：
# Skill: [名称]
## 适用场景
[何时使用这个 Skill]
## 前提条件
[使用前需要满足的条件]
## 步骤
1. [步骤一]
2. [步骤二]
## 常见陷阱
- [陷阱一及其避免方式]
## 不适用场景
[何时不应该使用这个 Skill]计算复杂性视角：Skill 作为记忆化搜索
Skill 的计算理论等价物是记忆化搜索（Memoization）或更广义的动态规划——将已解决的子问题的解缓存起来，避免重复展开搜索树。
一个没有 Skill 的 Agent，每次遇到相似问题时需要重新支付完整的搜索成本：在分支因子 、路径深度 的解空间中，搜索成本为 。Skill 将已知有效路径的重搜索成本压缩为 的检索——直接命中已验证的解路径，无需重新展开搜索树。这让 Skill 的”规模效应”有了比”经验复用”更精确的计算表述：Skill 库是对问题空间中已探索部分的 检索索引，而非仅仅是文档资产。
这也解释了 13.3 中”过期 Skill 比没有 Skill 更危险”的原因—— 检索假设缓存的解路径仍然有效；若 Skill 内容已过期， 检索给出了错误的起点，Agent 需要付出比从头搜索更高的代价（先沿错误路径执行，再回溯纠正）。
信息论视角：Skill 是一种被验证过的有损编码
记忆化搜索给出了 Skill 的计算成本结构，但它没有回答一个关键问题：为什么 Skill 不能由 Agent 自动更新，而必须经过人类审核？ 这个问题需要信息论的语言才能精确表述。
将 Skill 视为对”问题空间 → 解路径”映射的有损编码：完整的人类专家经验（信源 ，包含所有边界情况、隐含约束、领域直觉）在被写成一份 Skill 文档时，必然丢失部分细节——这正是 Rate-Distortion 理论刻画的失真（详见附录 A.1 与第六章 §6.1）。一份高质量 Skill 在 曲线上对应一个已被人类验证可接受的工作点：编码速率 （Skill 的字数/复杂度）足够紧凑，失真 （与人类专家判断的偏离）已被领域专家显式确认在容忍阈值内。
方法论声明 (b) 启发性模型：此处将 Skill 套入 框架是为了刻画”未验证更新引入失真”的结构性风险，而非给出可计算的失真度量。 在工程上无法直接测量；这个模型的价值在于解释为什么自动更新不是中性操作。
Agent 自动更新等价于在无失真预算下盲目移动 工作点。当 Agent 基于近期日志提出一个 Skill 修改时，它能观察到的只有一个有限样本上的”成功率”，而不是修改后的真实失真 。任何不经验证的更新，都把”已验证可信”的低失真编码替换为”未经验证的高失真编码”——在 平面上，这是一次失真上升而码率未必下降的次优移动。更危险的是：失真上升不会立即显现，因为 函数的工程对应物（任务质量评分）只在被尾部样本（low-probability、high-impact 的边界情况）触发时才会下跌；自动更新的”高置信度”恰恰来自于近期样本未触及尾部。
与学习理论的衔接：这一现象在统计学习理论中有对应名称——基于近期窗口样本对 Skill 做经验风险最小化，而忽略了原 Skill 所覆盖的长尾真实分布，是教科书式的样本选择偏差（sample selection bias）与对近期窗口的过拟合。§13.4 将这一论点与 Skill 化决策的最小样本量门槛具体化。
边界说明：Rate-Distortion 与样本选择偏差均来自各自理论框架的最坏情况分析；具体的失真上界与样本量阈值在工程实践中无法精确计算。此处使用这两个结论作为”为什么 Skill 自动更新结构上不安全”的理论根基，不用于定量预测某次具体更新的失败概率。
13.2 Skill 实现了”按需加载”
不同任务需要不同背景知识，但把所有知识塞进 System Prompt 既浪费 Context 带宽（成本上升）又降低相关信息的信噪比（质量下降）。Skill 实现按需加载——只在需要时才将相关知识注入上下文，是 Context Engineering 中动态注入原则的最优实践。在组织视角下，按需加载的另一层意义是：Skill 库的广度（覆盖多少类问题）决定了团队 Harness 的知识边界，而深度（每类问题的解法有多精确）决定了团队在该领域的竞争优势密度。
13.3 Skill 的生命周期：生成、验证、淘汰
Skill 不是永恒的。随着代码库、工具、规范的演进，曾经的”最优解”可能变成”反模式”。过期的 Skill 会误导 Agent，产生比没有 Skill 更高的纠错成本。淘汰信号：使用该 Skill 的任务失败率上升、Skill 中引用的工具或 API 已不存在、Skill 假设的约束条件已经改变。
Skill 生命周期的管理是组织级 Harness 运维的核心任务之一——它与评估（第十二章）深度联动：评估数据是 Skill 淘汰决策最可靠的依据，也是 Skill 更新内容的主要来源。
13.4 何时不应该使用 Skill
对于高度上下文相关的问题（每次情况差异很大），过早 Skill 化会导致”Skill 过拟合”——把特殊情况的解法固化为通用规则。判断标准：至少在 3-5 个相似任务中验证有效后才考虑 Skill 化；如果最近一次迭代与 Skill 内容差异 > 30%，考虑更新或废弃。
13.5 Agent 驱动的 Skill 迭代：从执行日志到知识升级
§13.1 描述的方向是单向的——人类将经验同步给 Agent。但这条通道也可以反向流动：Agent 的执行日志本身是对 Skill 有效性的持续检验，蕴含着人类事先未必掌握的模式。这是 Skill 作为”持续改进机制”的完整闭环：评估产生数据 → 日志揭示偏差 → Agent 提案 → 人类审核 → Skill 更新 → Harness 演化。
日志作为反馈信号：每次 Skill 被触发后，执行路径、工具调用序列、失败节点、人工纠正记录都沉淀在日志中。这些信息构成 Skill 的”运行时证据”——与 Skill 的预期路径对比，偏差即为改进信号。
三类迭代触发条件：
- 成功偏差：Agent 完成了任务，但走了一条 Skill 未描述的更短路径——这是候选的 Skill 更新内容
- 失败聚集：同一步骤反复出现纠错或重试——Skill 在该节点的描述不够准确或遗漏了关键约束
- 上下文漂移：日志显示 Agent 频繁判断 Skill 不适用而绕过——当前 Skill 的适用范围描述已与实际问题空间错位
Agent 参与摘要的边界：Agent 可以从日志中识别模式并起草 Skill 更新草案，但最终验证必须由人类完成。原因在于：Agent 无法区分”这条路径更好”与”这条路径恰好在此次上下文中有效”；过度自信的自动更新会引入系统性偏移，使 Skill 库向近期样本过拟合。正确的流程是：Agent 提案 → 人类审核 → 版本化提交。
这将 Skill 的演进从”人类主动发现问题后更新”变为持续的观察-提案-审核循环，使 Skill 库能够跟上系统的实际运行状态。
Skill 库的组织级价值：一个持续运转的 Skill 更新循环，其长期效应是指数性的——今日积累的解法降低了明日类似任务的搜索成本，而节省的成本又可以投入到更复杂任务的探索，产生新的 Skill。这是 §17.4 所描述的”正在积累优势的团队”的核心特征：Skill 库在积累，迭代成本在下降，团队的 Harness 能力形成结构性护城河。
章末案例剖析
一个后端工程团队 Skill 库的十一周建设史——三个阶段的进展，一次不可忽视的回归事件，以及流程在失败后的重建。评估数据（第十二章）在每个阶段都扮演了关键角色：它决定了哪些 Skill 值得投入、哪些更新方向是有效的、以及回归发生时如何精确定位根因。
背景：一个八人后端工程团队，使用代码审查 Agent 辅助 PR 审核。团队每周处理约 60 个 PR，Agent 的任务是识别安全问题、逻辑错误和数据库操作风险。初始 Harness 仅有通用 System Prompt，没有任何 Skill。评估基线（第 0 周）：
| 指标 | 基线值 |
|---|---|
| 质量评分（LLM-as-judge，满分 100） | 63/100 |
| 人工介入率（审查结果需人工修正） | 41% |
| 平均任务轮次 | 4.6 轮 |
| PR 后续发现的遗漏问题数/周 | 约 7 个 |
第一阶段：第一个 Skill 的诞生（第 1–3 周）
问题识别
团队成员注意到，Agent 在审查数据库迁移 PR 时反复犯同样的错误：
- 未检查
ALTER TABLE是否会在大表上产生表锁，导致 PR 合并后引发生产慢查询 - 未验证迁移是否包含回滚路径（
down()方法） - 未追踪外键级联删除的影响范围
这三个陷阱，资深工程师A已经在日常 Code Review 中形成了固定的心智检查清单。他将这个清单写成了团队的第一个 Skill：
# Skill: 数据库迁移 PR 审查
## 适用场景
PR 中包含 Alembic 或 Django migration 文件（*.py 在 migrations/ 目录下）
## 前提条件
已读取迁移文件内容和目标表的当前行数（通过 db_query 获取）
## 步骤
1. **表锁风险检查**：若迁移包含 ALTER TABLE，查询目标表行数
- 行数 > 1M：标记为高风险，建议改用 pt-online-schema-change 或 gh-ost
- 行数 < 1M：低风险，记录行数供审查者参考
2. **可逆性检查**：确认 down() 方法存在且逻辑正确（非空实现）
3. **外键级联检查**：若迁移涉及 DROP COLUMN 或 DROP TABLE，追踪所有引用该字段的外键约束
4. **索引并发创建**：若包含 CREATE INDEX，确认使用 CREATE INDEX CONCURRENTLY
## 常见陷阱
- `pass` 在 down() 中不等于"无操作可逆"，等于"不可逆"
- online schema change 工具本身有前提条件（无触发器、主键必须存在），需同步验证
## 不适用场景
仅修改初始数据（data migration）而不修改 Schema 的迁移文件评估数据的决策依据
Skill 上线后第 2–3 周，在 19 次数据库迁移 PR 审查任务中测量效果：
| 指标 | Skill 前（基线） | Skill 后（第 2–3 周） | 变化 |
|---|---|---|---|
| DB 迁移任务质量评分 | 61/100 | 79/100 | ↑18 |
| 人工介入率 | 44% | 11% | ↓33pp |
| 平均任务轮次 | 4.8 轮 | 2.6 轮 | ↓46% |
| 表锁风险漏报 | 3 次/周 | 0 次/周 | ↓100% |
质量评分从 61 跃升至 79（变化幅度超过评分方差的 2 倍标准差），人工介入率降至 11%——这远超团队事先预期的”可能改善 10–15%“。评估数据为团队提供了明确的决策依据：Skill 有效，值得投入建设 Skill 库。
团队决定将 Skill 库作为正式工程资产维护，建立 Git 仓库（team-skills/），所有 Skill 以 Markdown 文件形式版本化管理，变更通过 PR 流程审核。
第二阶段：日志分析循环的建立（第 4–8 周）
Agent 驱动的 Skill 发现
团队在第 4 周引入了 §13.5 描述的日志分析机制：Agent 每日分析前 24 小时的执行日志，识别三类迭代触发条件（成功偏差 / 失败聚集 / 上下文漂移），并将发现以 Skill 更新草案的形式提交到 team-skills/ 仓库（作为 PR，等待人工审核）。
第 5 周，Agent 提交了首个 Skill 草案：
日志分析发现，涉及认证代码（JWT 处理、权限检查）的 PR 在第 3 步（“识别安全模式”）有一个反复出现的成功偏差——Agent 在 Skill 未覆盖的情况下，总是额外检查 JWT 的过期时间边界处理（exp 字段为负数或超大值时的行为），并在 8 次任务中均有效发现了问题。这个检查步骤不在通用 System Prompt 中，是 Agent 基于训练数据习得的模式，但执行不稳定（8 次中有 2 次遗漏）。
Agent 的草案 PR 包含：
# Skill: 认证代码 PR 审查（草案，待人工审核）
## 来源：日志分析（2025-03-22，覆盖过去 31 次认证相关 PR）
## 有效案例：8/31（26%），漏报案例：2/8（25%）
## 步骤（草案）
...（含 JWT 边界检查步骤）...
## 待人工确认
- 是否需要覆盖 refresh token 的过期处理？（草案中未包含）
- 第 3 步的"超大值"阈值建议设为多少？人工审核过程：工程师A审查了草案，验证了 8 个有效案例的日志记录（确认均为真阳性），补充了 refresh token 的处理规则（Agent 草案中确实遗漏了），并将”超大值”阈值明确为 exp > now() + 30 days 视为异常。修改后批准合并。
评估数据的决策依据
第 6–8 周，auth_code_review Skill 上线后在 28 次认证 PR 任务中测量：
| 指标 | Skill 前（第 4–5 周基线） | Skill 后（第 6–8 周） |
|---|---|---|
| 认证 PR 质量评分 | 65/100 | 77/100 |
| JWT 边界漏报 | 2.1 次/周 | 0.2 次/周 |
| Agent 草案接受率（人工审核后合并） | — | 71%（5/7 个草案被采纳，2 个被否决） |
被否决的 2 个草案，Agent 将特定框架（FastAPI 的 Depends 注入模式）的局部解法推广为通用规则——工程师A在审查时发现这是过拟合（§13.4 的”Skill 过度使用”问题），用的样本量不足（仅 3 个任务），否决并在草案评论中记录了原因。这个”否决 + 记录原因”的流程成为 Skill 库治理的标准惯例。
第 8 周末，Skill 库已包含 6 个有效 Skill，整体 PR 审查质量评分从基线的 63 提升至 75，人工介入率从 41% 降至 18%。
第三阶段：自动化的边界——回归事件（第 5–10 周累积漂移）
案例中的数据（PR 数量、置信分、阈值、Skill 字段变更幅度等）均为基于作者工程实践的说明性示例，旨在量化呈现”小步累积漂移如何绕过单次审核直觉”的结构性风险。
流程变更的引入
新加入的团队工程师B，希望减少工程师A审核 Skill 草案的人工成本。他在第 5 周末为日志分析 Pipeline 增加了”小步自动合并”逻辑：
规则：若 Agent 提案的置信分 ≥ 0.85，且变更量 ≤ 原 Skill 内容的 20%，
则跳过人工审核，由 Pipeline 直接合并到 Skill 库这个规则在逻辑上看似合理——高置信度、小变更量，人工审核的边际价值应当较低。但它忽略了 §13.1 与 §13.5 提出的核心警告：自动更新等价于在无验证信号的情况下移动 Skill 在 上的工作点；单次小变更的”局部合理性”不构成对整体失真不增加的保证。
五次累积漂移的轨迹
db_migration_review Skill 在第 6 周到第 9 周之间，被自动合并机制接受了五次小幅修改。每一次单独看都有局部证据支撑，置信分都在 0.85–0.90 之间，变更量都在 20% 阈值以内。下表呈现这条漂移轨迹：
| # | 周 | Agent 触发依据（局部观察） | 修改内容 | 置信分 | 变更量 |
|---|---|---|---|---|---|
| 1 | 第 6 周 | 近 14 次迁移 PR 中，pt-online-schema-change 仅出现 1 次，团队普遍使用 gh-ost | 将”建议改用 pt-online-schema-change 或 gh-ost”简化为”建议改用 gh-ost” | 0.87 | 6% |
| 2 | 第 7 周 | 近 18 次 PR 中，所有 ALTER TABLE 均限定为 ADD COLUMN 形态，未见 MODIFY/DROP COLUMN | 将”高风险阈值”备注收窄为”针对 ADD COLUMN 场景，参考行数为目标表 50% 容量基准” | 0.86 | 11% |
| 3 | 第 8 周初 | 近 9 次涉及大表的 PR 全部走了灰度发布通道，未直接命中生产 | 在第 1 步追加注释：“若已通过灰度通道，行数检查可作为参考而非阻塞项” | 0.89 | 9% |
| 4 | 第 8 周末 | 近 11 次 PR 中，行数查询的 db_query 平均耗时 1.3s，被工程师A抱怨拖慢审查节奏 | 将”行数查询”从前置必做步骤改为”按需触发”——仅在 PR 描述含’迁移大表’关键词时执行 | 0.85 | 14% |
| 5 | 第 9 周 | 近 12 次 PR 均无表锁告警；前 4 次小修改稳定运行，未出现回归 | 将原”行数 > 1M：标记为高风险”的硬性规则降级为”参考性提示”，质量评分计算中不再扣分 | 0.88 | 12% |
累积效应：单次修改没有破坏性——第 1 次只是去掉一个少用工具，第 2 次只是收窄场景描述，第 3 次只是承认灰度通道的存在，第 4 次只是优化执行节奏，第 5 次只是软化告警等级。但这五次叠加之后：表锁风险检查的触发条件从”包含 ALTER TABLE 即触发”被层层附加前提条件，最终退化为”PR 描述明确提到大表 + 未走灰度通道 + 命中关键词”才会执行——一个原本无条件的安全检查，被改造为条件极其苛刻的可选项。
整个过程中，自动化指标看起来是”好的”：每次提案的近期窗口质量评分都未下降，置信分稳定在阈值之上，团队成员甚至赞许了第 4 次修改对审查节奏的优化。第 5 周到第 9 周，没有任何一次单次修改触发过 §12 设定的”质量评分滚动告警”——因为告警逻辑只对断崖式下跌敏感。
回归的发生
第 10 周第 2 天，Agent 审查了一个针对 orders 表（3,200 万行）的迁移 PR，包含 ALTER TABLE orders ADD COLUMN delivery_notes TEXT。这个 PR 的特点是：（a）描述中没有”迁移大表”关键词——提交者在 PR 描述中只写了”补充配送备注字段”；（b）未走灰度通道——直接走了团队默认的 staging→prod 流水线，因为提交者把它当作”加字段”这种小操作。
漂移后的 Skill 此时的执行链是：检查关键词→未命中→跳过行数查询→无大表证据→不触发表锁警告。Agent 给出”通过”结论。PR 合并后，迁移在生产数据库上执行，造成 orders 表锁定约 22 分钟，影响了订单服务的正常写入，触发了多个超时告警。
第十二章评估数据的告警作用：
回归并非通过人工发现，而是由监控系统触发的。第 10 周周一的日度质量报告显示：
[ALERT] DB 迁移 PR 质量评分（rolling_7d）= 65/100
基线（过去 30 天）= 77/100，下降 12 点，超过告警阈值（基线 -10）
[ALERT] DB 迁移 PR 的生产问题率 = 2/9（22%）
基线 = 0/38（0%），连续 2 周超过 5% 告警阈值工程师A通过追踪（§12.3 追踪层）拉取失败任务的执行记录，对比该任务的 Skill 版本与当前 Skill 库版本的差异，立即定位到”表锁检查被自动删除”。
第四阶段：流程纠正与预防机制（第 10–11 周）
即时修复
- 将
db_migration_reviewSkill 回滚至第 5 周末版本（漂移开始之前；Git 历史保证了可回滚性） - 关闭”自动合并”逻辑，所有 Skill 变更恢复人工审核要求
根因复盘
这次回归的关键不是”某一次自动更新的判断错了”，而是五次单次合理的修改，在累积尺度上把一条普遍适用的安全规则改造成了条件苛刻的可选项。每一步都满足”基于近期样本，置信分高，变更量小”的局部条件；但这些样本都来自一个被生产流程性质（团队恰好都走灰度通道、PR 主要是 ADD COLUMN 形态）筛选过的有偏分布——尾部样本（无关键词、不走灰度、又恰好在大表上的 ALTER TABLE）从未在近期窗口出现，自动化机制因此从未”看见”自己正在删除什么。
这正是 §13.1 信息论视角警告的现象：每次修改在 平面上看似只是把码率 （Skill 字数）轻微降低，但失真 在那条始终未被近期样本采样的尾部上单调累积上升。Agent 的”置信分”度量的是它在已观测样本上的局部一致性，无法度量它没看见的尾部失真——而正是尾部决定了规则在生产环境的真实价值。
§13.5 指出的”Agent 无法区分’此路在此次有效’与’此路应当普遍有效‘“在累积场景下被进一步放大：单次审核可能还能凭直觉拦下”明显的过拟合”，但对小步累积漂移，单次审核在结构上就是无效的——审核者每次只看到一次小修改，而漂移的危害只在叠加后才显现。
流程重建
团队在 Skill 库的 CONTRIBUTING.md 中明确了以下规则：
规则一：人工审核不可省略 所有 Skill 变更必须经过至少一名熟悉该领域的工程师审核，无论变更量大小和 Agent 置信度高低。置信度是优先级排序的依据（高置信度草案先看），不是跳过审核的许可。
规则二：Skill 变更必须标注决策来源 每个 Skill 变更在提交信息中必须注明：
来源：人类主导（[工程师姓名] 基于 [场景] 的直接判断）
或：Agent 草案 + 人类审核（草案来源：日志分析 N 个样本，审核人：[姓名]，
修改内容：[人类补充或修正了什么]）规则三：专项评估指标监控 为每个 Skill 建立独立的质量追踪指标（“Skill 命中任务的质量评分”），独立于通用质量评分报告，当某个 Skill 的命中任务质量出现统计显著下降时，在 24 小时内触发审查。
修复效果
第 11 周，Skill 恢复后，DB 迁移 PR 质量评分回升至 76/100（接近历史峰值 79），生产问题率归零。
四个阶段的评估数据纵览
| 阶段 | 关键事件 | DB 迁移质量 | 认证 PR 质量 | 整体人工介入率 |
|---|---|---|---|---|
| 第 0 周（基线） | 无 Skill | 61/100 | 65/100 | 41% |
| 第 3 周 | db_migration_review 上线 | 79/100 | 65/100 | 28% |
| 第 8 周 | auth_code_review 上线，库含 6 个 Skill；漂移已发生 3 次但近期样本未触发 | 77/100 | 77/100 | 18% |
| 第 9 周 | 漂移累计 5 次完成，近期样本仍未触发尾部 | 76/100 | 77/100 | 19% |
| 第 10 周 | 尾部样本（大表 ADD COLUMN，无关键词、未走灰度）触发回归 | 65/100（↓12） | 77/100 | 22%（↑4） |
| 第 11 周 | Skill 回滚至第 5 周版本，流程重建 | 76/100 | 77/100 | 17% |
评估数据在各决策节点的角色：
| 决策节点 | 评估数据提供的依据 |
|---|---|
| 第 3 周：是否值得投入建设 Skill 库 | 质量评分 +18 点、介入率 -33pp → 明确正收益，投入合理 |
| 第 5 周：Agent 草案是否可靠（71% 接受率） | 样本覆盖率（8/31）和真阳性率（100%）为接受提供了量化基础 |
| 第 5 周：2 个草案为何被否决 | 仅 3 个样本且均来自同一框架 → 样本量不足，过拟合风险 |
| 第 6–9 周：累积漂移期 | 每次单次评估窗口质量评分均未下跌（正是漂移得以延续的盲区）→ 揭示了”滚动告警对断崖式下跌敏感、对小步漂移失效”的度量结构性局限 |
| 第 10 周：回归发现 | 质量评分下降 12 点的滚动告警，24 小时内触发；追踪层对比五次 Skill 版本差异，精确定位”漂移轨迹”而非单次错误 |
| 第 11 周：流程修复效果验证 | 质量评分从 65 回升至 76，生产问题率归零 → 修复有效确认 |
本案例的核心工程结论：Skill 库的演化不是一次性设计，而是一个观察-提案-审核-验证的持续循环。评估数据在这个循环中不是事后报告，而是每一轮决策的前置依据——没有量化数据，“这个 Skill 有没有用”和”自动更新是否安全”都只能依赖直觉。§13.5 提出的”Agent 提案 → 人类审核 → 版本化提交”不是繁文缛节，而是防止 Agent 将局部有效的模式过拟合为通用规则的结构性保障。
回归事件提供了一个比”单次错误判断”更重要的教训：漂移可以累积，而每一步都看似合理。当人工审核被替换为基于近期窗口的自动化置信度时，置信度度量只能反映 Agent 在已观测样本上的局部一致性，无法度量它在未触及的尾部分布上正在制造的失真——这正是 §13.1 信息论视角警告的” 工作点在无验证下被盲目移动”的工程化表现。知道”此路在近期样本上有效”和知道”此路应当普遍有效”，是两种本质不同的知识：前者可以由 Agent 的日志分析给出，后者只能由理解系统全貌（包括尾部、包括没在近期样本中出现的边界情况）的人类确认。