第12章　持续演进：把运行经验变成可验证的新能力¶

状态：初学者展开试稿，待人工审阅（基于 Release Candidate 1 修订）

本章定位：承接第9章的生产 Harness、第10章的评估与可观测性和第11章的安全治理，说明怎样把已评价的运行经验变成知识、Prompt／Skill、程序／Harness或模型参数的候选更新。参数训练的具体方法见第13章。

本章回答的三个问题¶

一次运行留下的轨迹、用户反馈和环境结果，怎样变成可信的学习信号？
系统表现不好时，应更新知识、Prompt／Skill、程序／Harness，还是模型参数？
候选更新怎样经过离线验证、影子、金丝雀、回滚和长期整理，才不会把错误经验写进系统？

本章沿用第9—11章的退款教学案例：

用户说：“订单 O-2048 重复扣款，请退回重复的那一笔。退款前给我看金额；超过我的审批上限就转人工，不要重复退款。”

假设一次运行中，退款接口返回超时，旧版 Harness 换了新的幂等键重试，最终产生两笔退款。这里的订单、状态和故障均为教学示例，不是生产事故或仓库实测。我们将沿着这条失败轨迹完成“采集—评价—归因—修复—验证—发布—整理”的闭环。

证据类型说明

本章严格区分三类话语：教学示例用于解释机制；标为“本书建议”的内容是需要在具体系统验证的工程建议；只有明确指向论文、标准或仓库保存记录的内容才是限定条件下的实测结论。本章没有重新运行实验，也不提供虚构的成功率、成本、时延或通用发布阈值。配置中的大写占位符必须由项目依据风险和实测填写。

5分钟速读¶

持续演进（Continual Evolution）不是“模型每次回答后自动训练”，而是把运行证据经过评价、归因和独立验证，写入下一版知识、指令、程序或参数。
在线环负责服务当前任务并记录证据；离线环负责聚合、脱敏、归因、生成候选和验证。在线 Run 不应直接改正式 Prompt、代码、政策或模型。
轨迹（Trajectory）只是一次运行经过了什么；只有绑定环境结果、过程规则、用户反馈和证据位置后，它才可能成为学习材料。
用户点赞、模型反思和 LLM Judge 都不是业务真值。优先使用权威环境终态和确定性规则；开放质量才交给经人工校准的 Rubric。
找首个关键错误，不要只修最后一个报错。退款案例的首错是“不确定副作用下换键重试”，不是最后出现的第二条通知。
本书建议优先选择最可控、最容易回滚的载体：知识 → Prompt／Skill → 程序／Harness → 模型参数；但真正依据是问题的表示方式，不是机械套顺序。
事实和时效信息适合知识；可语言化策略适合 Prompt／Skill；权限、状态、计算和副作用不变量进入程序；难以显式表达且有合格数据时才考虑参数训练。
候选更新必须记录来源、范围、预期效果、风险、数据与配置版本、审批和回滚版本；生成者不能修改批准自己的验证器和发布门。
验证同时覆盖触发失败集、原本正常的保留集、对抗集和新鲜保留集；训练／调参数据与最终验证数据隔离，防止泄漏。
发布按离线回放 → 影子 → 金丝雀 → 有界放量 → 全量进行。影子版本从权限层禁写；安全违规、重复副作用等硬失败按预设门槛停止。
长期演进还包括遗忘：去重、处理冲突、过期旧规则、重建索引、撤销坏版本，并保留来源和删除能力。

一、先分清：保存经历不等于从经历学习¶

1.1 四个首次术语解释¶

轨迹（Trajectory）是一次 Run 中用户输入、模型输出、工具调用、环境观察、审批和验证结果组成的步骤序列。它回答“发生过什么”，不自动回答“什么做法值得复用”。

反馈闭环（Feedback Loop）是把运行结果送回改进流程，并用下一轮结果检验改动是否有效的循环。只有“记录反馈”而没有验证和回滚，不构成可靠闭环。

持续演进（Continual Evolution）是系统跨任务、跨版本地积累经过验证的能力。这里的“能力”可以位于知识、Prompt、Skill、程序、Harness或模型参数中。

在线改进（Online Improvement）在本章指生产服务运行时根据当前输入调整行为，例如补充上下文、重规划或读取已有 Skill；它服务当前 Run。离线改进（Offline Improvement）在与生产写权限隔离的流程中，聚合多条证据、生成候选版本并评估，之后才可能发布。这里的“离线”指不直接影响真实生产动作，不等于机器必须断网。

1.2 三件容易混淆的事¶

行为	是否跨任务保留	是否改变正式能力	本章如何看待
当前 Context 中加入一条说明	否	否	当前任务适应
把原始对话存进日志或向量库	可能	不一定	保存证据或记忆
经过验证后发布新版 Skill／Harness	是	是	持续演进

模型完成一次推理后，参数不会自然改变；把一百条轨迹存起来，也不会自动比较哪些步骤有效、哪些成功只是偶然。原始书稿强调：学习发生在评价、比较、归纳和验证之后，而不是日志落盘之时。¹

1.3 一条安全的双环结构¶

在线执行环
认证与授权 → 执行任务 → 验证终态 → 记录脱敏证据 → 结束Run
                                      │
                                      ▼
离线演进环
采样与治理 → 评价 → 首错归因与聚类 → 选择载体 → 生成候选
    → 离线回归与安全审查 → 发布审批 → 影子／金丝雀／放量
                                      │
                                      └── 新版本与新失败回到下一轮

在线环可以依据当前工具结果重试或重规划，但不能自行修改生产权限、验证器、发布阈值和稳定版本。离线环也不是“无人监管区”：它使用测试身份和隔离环境，高风险候选仍需指定 Owner 审批。

本章对应模式 P17“失败回流与回归闭环”和 P18“外部能力优先更新”。⁶⁷

二、从轨迹得到学习信号¶

2.1 先看结果：现实世界到底发生了什么¶

学习信号（Learning Signal）是能够支持“保留、修复、拒绝或进一步调查”判断的结构化证据。第一层来自环境：测试结果、数据库状态、支付回执、文件 Hash、页面最终状态或用户明确确认。

退款案例不能以“模型说退款成功”为信号。验证器应读取支付系统，发现同一重复扣款对应两个退款 ID。这个终态证明发生了重复副作用，但还没有解释原因。

2.2 再看过程：是否用允许的路径完成¶

结果正确也可能路径错误，例如先退款后补审批。过程验证器检查：

身份、权限和租户是否正确；
预览与审批是否先于执行；
幂等键是否稳定并绑定准确载荷；
是否调用禁止工具或越权数据；
重试、预算、取消和终止是否符合合同；
最终陈述是否与外部动作一致。

这些可确定表达的规则应由程序检查。LLM 不能给自己补发权限，也不能用自然语言解释覆盖审计事实。

2.3 用户反馈和开放质量怎样使用¶

用户的纠正、投诉、点赞、接管和放弃都可能有价值，但含义不同：

点赞可能只表示回复礼貌，不代表退款合规；
没有投诉可能是用户尚未发现错误；
人工接管可能是系统失败，也可能是正确安全结果；
用户纠正可能指出事实错误，也可能与有效政策冲突。

表达清晰度、完整性等开放维度可以用预先定义的 Rubric（评分量表）和经人工校准的 LLM Judge 辅助判断。Judge 必须引用轨迹位置并允许输出“证据不足”；它不能独自裁决事实、授权或高风险动作。完整评估方法见第10章。⁴

2.4 把“一个总分”变成可学习记录¶

本书建议每次评价至少输出：

run_id: run_demo_refund_01
outcome: failed
process_verdict: failed
quality_verdict: not_scored
first_critical_error:
  event_id: tool_call_07
  type: runtime_idempotency
  evidence: "超时后以新幂等键发起第二次写请求"
environment_evidence:
  - "两个不同退款ID指向同一重复扣款"
confidence: high
requires_human_review: true

这是教学 Schema，字段名不是标准。confidence表达评价者对归因的把握，不是自动发布许可。原始证据应保持不可变；分析和标签可以版本化修订，并保留修改人和理由。

三、失败归因：先找到第一个让任务偏离的地方¶

3.1 为什么最后一个错误常常误导¶

故障通常级联：选错交易 → 退款超时 → 换键重试 → 两笔退款 → 发两条通知 → 用户投诉。若只按最后一条投诉修复通知文案，钱仍会退两次。

首个关键错误（First Critical Error）是轨迹中最早使后续任务无法按合同成功的可行动错误。它不是“最早出现的任何异常”，而是有反事实意义的转折点：若修复这一处，后面的失败链应当被阻断或改变。

3.2 一份初学者可用的归因表¶

类别	典型问题	优先检查的载体
Context	缺少当前目标、约束或已验证事实	Context构造、State
Retrieval／Knowledge	召回过期、冲突或越权资料	知识、索引、权限过滤
Model	在充分信息与接口下仍稳定判断错误	Prompt、Skill、参数
Tool	工具名称、Schema、参数或返回合同误导	工具接口、适配器
Policy／Approval	授权规则错误或批准未绑定准确载荷	政策网关、审批系统
Runtime／Harness	状态、重试、幂等、预算或恢复错误	程序、Harness
Environment	外部服务不可用、数据本身错误	运维、上游系统
Verifier	错判完成、漏掉副作用或评分漂移	验证器、数据集

退款案例的首错位于 Runtime／Harness：写请求结果未知时生成新幂等键。支付服务超时是环境事件，不必然导致重复退款；错误恢复策略才把它放大成事故。

3.3 单条失败什么时候可以行动¶

“一条样本不能生成永久规则”是防止过拟合的好默认值，但不能变成拖延安全修复的借口。本书建议按影响区分：

高置信、高影响安全缺陷：一条可复现证据即可立即熔断相关能力、回滚或人工接管；永久修复仍需独立测试。
一般质量问题：先去重、按任务族聚类，寻找跨轨迹支持和反例。
证据不足：保留为待调查，不进入学习集。
无法保留生产原文：在不泄露数据的前提下构造最小合成复现，并记录它与原事件的对应关系。

不应虚构统一的“至少 N 条”门槛。样本量取决于风险、可复现性和证据强度，并应在项目质量计划中登记。

四、选择更新载体：把问题修在最合适的一层¶

4.1 一条实用的决策路径¶

是可查询、会变化的事实或案例吗？
  → 知识
是需要理解情境、可用语言表达的策略吗？
  → Prompt／Skill
是可确定检查的规则、状态转移、计算或副作用边界吗？
  → 程序／Harness
在充分信息和正确接口下仍稳定失败，且有足够数据与独立验证器吗？
  → 评估模型参数更新

这是工程建议，不是绝对层级。同一能力可以跨层组合：退款政策正文放知识库；解释例外的步骤放 Skill；身份、金额上限、幂等和审批由代码强制；自然语言风格可由参数提供。

4.2 更新知识：适合事实、政策和可检索经验¶

知识更新适用于会变化、需要引用来源的信息，例如最新退款时限、某接口版本的已知限制，或“在哪些前提下先查询幂等记录”的经验说明。正式知识条目至少应记录来源、适用范围、环境版本、Owner、权限、验证日期、冲突与过期条件。

不要直接把整条生产对话向量化后称为知识。更稳妥的三层是：不可变原始证据 → 每条 Run 的结构化分析 → 跨轨迹比较后形成的正式知识。索引是可重建的派生物，删除请求应能到达原文、分析和索引。

4.3 更新Prompt或Skill：适合可语言化策略¶

Prompt是每次或某类调用使用的指令；Skill是按任务需要加载的领域说明和流程。若多条轨迹都显示 Agent 在“何时澄清、何时转人工、怎样解释例外”上犯同类错误，可以提出局部指令补丁。

补丁应是最小 Diff，写明触发范围和反例，而不是重写整份系统 Prompt。全局规则只服务少数任务时，应优先放入按需 Skill，避免所有请求都携带无关规则。Prompt 和 Skill 是行为指导，不是权限边界；“不得重复退款”仍要在 Harness 中强制。

4.4 更新程序或Harness：适合确定性不变量¶

稳定、可执行、可测试的规则应进入程序：Schema 校验、工具路由、金额计算、权限、状态机、幂等、重试、熔断、预算和完成验证。

退款案例的候选修复应在 Harness 中实现：超时后保留原幂等键，先查幂等记录或权威退款状态；只有确认未执行、授权仍有效且预算允许时才有界重试。仅给模型追加一句“不要重复退款”，无法形成硬保证。

若 Coding Agent 生成补丁，它只能写隔离工作区或候选分支；不得修改稳定代码、生产凭据、审计日志、测试期望或批准自己的发布门。依赖安装和外部网络访问属于供应链动作，需要允许列表、锁定版本、扫描和相应审批。代码安全边界见第7章，生产恢复见第9章，治理见第11章。

4.5 更新模型参数：适合难以显式表达的广泛能力¶

感知、自然语言风格和隐式策略等高维能力，可能难以压缩成少量规则。只有在以下条件较完整时，才进入第13章的后训练评估：

观察空间、工具和知识已经充分；
外部载体仍在目标任务族上稳定失败；
有经授权、脱敏、去重和标注的数据；
训练集、开发集和独立保留集隔离；
能检测能力遗忘、安全漂移和不希望的泛化；
有模型、数据、训练配置、评估与回滚版本。

不要用参数记忆实时政策，也不要指望训练提供严格授权保证。参数更新成本和爆炸半径最大，具体的 SFT、偏好学习与 RL 见第13章。⁵

五、从失败到候选变更：贯穿案例¶

5.1 建立最小回归任务¶

团队先把生产事件脱敏，在可重置支付模拟器中建立一个最小任务：第一次退款调用已经生效，但客户端收到超时；系统必须查询原幂等键和权威状态，不得发起第二笔退款。

测试身份只能访问合成订单，评估执行器没有生产凭据。模拟器每轮恢复固定初始状态；任何外部通知都进入测试接收器。若不能安全模拟真实副作用，只允许 Dry-run 或由获批人员在专用测试租户执行。

5.2 写一份可证伪的变更合同¶

change_id: refund-idempotency-lookup-v2
status: candidate
source:
  incident_refs: [sanitized_incident_demo]
  regression_case: refund-timeout-unknown-result-v1
root_cause: new_idempotency_key_after_unknown_write_result
carrier: harness
scope: refund_execution
expected_effect:
  - reuse_original_key
  - query_authoritative_state_before_retry
must_preserve:
  - retry_transient_read_failures_within_budget
  - enforce_identity_policy_and_exact_payload_approval
risks:
  - increased_latency_when_status_query_is_slow
  - blocked_runs_when_provider_state_is_unknown
validation:
  triggering_set: refund-failures-v1
  retention_set: refund-core-v4
  adversarial_set: refund-safety-v2
rollback_bundle: refund-agent-bundle-v41
owners:
  change: payments_runtime_team
  approval: payments_risk_owner

这仍是教学示例，不是可直接使用的组织配置。expected_effect是要被验证的预测，不是已经得到的实测结论。

5.3 生成候选时的权限边界¶

候选生成器可以读取：脱敏失败证据、稳定版本、必须保持的成功行为和过去被拒绝的提案。它只能写候选工作区，并受以下限制：

使用专用低权限身份，不持有生产写凭据；
网络默认关闭，确需依赖时按允许列表和锁定版本审批；
不得读取其他租户数据或未授权原始 Trace；
不得编辑验证器、保留集、发布阈值、审计记录和稳定备份；
工具调用、Token、时间、费用和并发均有硬预算；
生成的代码、Prompt、知识和模型都先标记为candidate。

5.4 完成证据是什么¶

“Agent 已经改完”不是完成。该候选至少要关联：

变更 Diff 与内容 Hash；
来源事件、首错证据和变更合同；
使用的数据集、模型、Prompt、工具、政策和验证器版本；
每级门禁的运行 ID、原始结果和未通过项；
安全／业务审批记录；
候选 Bundle 与回滚 Bundle；
影子／金丝雀范围、停止原因和最终决定。

若某项测试未运行、凭据不可用或环境无法重置，应明确写“未验证”，不能把静态阅读当作实测。

六、离线改进：在不影响真实用户的环境里学习¶

6.1 四组数据分别解决什么问题¶

本书建议至少区分：

触发失败集：候选是否修复已知问题；
保留集：原本成功的能力是否退化；
对抗与安全集：候选是否引入越权、注入、泄漏或副作用风险；
新鲜保留集：没有参与提案、调参或日常选择，用于检查泛化和过拟合。

数据之间要去重并检查近似泄漏。同一生产对话的改写版不能一边生成规则、一边当独立验证。公开 Benchmark 可以辅助比较，但不能替代私有业务任务。

6.2 公平对照与质量门¶

候选与稳定版应尽量使用相同任务、初始状态、模型、工具、权限、预算、超时和评分器。若同时改变多个组件，就只能声称比较的是整个 Bundle，不能把收益归给某一个 Prompt。

质量门沿用第10章与 P16：

Schema／Unit
→ Smoke
→ Offline Evaluation
→ Online Evaluation

Unit 检查超时路径保留原键；
Smoke 只确认最小集成路径可达；
Offline 在模拟器中注入“已执行但返回超时”；
Online 通过影子和金丝雀观察真实分布。

没有项目实测，本章不规定“提升多少才发布”。发布前由 Owner 写明 Outcome、Safety、延迟、每成功任务成本、Fallback、人工接管和回滚阈值；安全硬失败不能由平均质量抵消。

6.3 评价“更新有效”还要看是否被使用¶

一份正确 Skill 可能从未被加载；一个新工具可能被加载后没有正确遵循。因此长期评估应分层：

层次	问题	证据
候选有效性	提案本身是否通过独立验证	门禁结果、拒绝原因
激活	新知识／Skill／工具是否在正确场景被选中	检索、路由、工具 Trace
遵循	激活后是否按规则行动	轨迹与过程验证器
迁移与保留	未见任务是否改善，旧能力是否保留	新鲜集、保留集、安全集
运营代价	是否增加延迟、成本、复杂度和人工负担	指标、维护与事故记录

这避免把“提案正确但未加载”和“提案本身错误”混为一谈。

七、在线改进：真实流量只能逐步扩大影响¶

7.1 五阶段发布¶

Offline Replay
→ Shadow
→ Canary
→ Bounded Rollout
→ Full Rollout

影子（Shadow）版本读取获准的真实输入或脱敏副本，结果不返回用户，也不改变生产状态。它必须从策略网关和凭据层禁写；Prompt 中写“不要执行退款”不算隔离。

金丝雀（Canary）让小范围真实任务使用候选版本。范围可以按租户、任务类型、影响等级或工具能力限制，但必须来自组织批准；用户进入实验组不会自动获得更多权限。

有界放量（Bounded Rollout）在观察窗口满足门槛后逐步扩大。每一步都保留旧 Bundle、开关、Owner和停止路径。

7.2 权限、凭据与审批不能随版本漂移¶

离线和影子使用测试凭据或无写权限身份；
金丝雀使用与任务匹配的最小、短时服务身份；
凭据由执行层代管，不进入 Prompt、轨迹、训练集和 Artifact；
高影响动作仍需要绑定准确载荷的业务审批；
发布审批批准的是候选 Bundle、范围、门槛和回滚计划，不替代每笔退款的业务授权；
新模型、新 Skill 或新工具不能自行扩大动作空间。

7.3 回滚前就要回答的问题¶

发布前必须知道：谁能停止、切回哪一套、在途 Run 怎样处理、Schema 是否兼容、已经发生的副作用怎样盘点。回滚 Bundle 包括代码、Prompt、模型路由、工具 Schema、政策、知识和索引版本，不只是模型名。

退款一旦发生，切回旧版本不会把资金自动收回。系统应停止新动作、查询权威状态，并按政策执行补偿或人工处理。回滚完成证据包括流量已切回、版本已核对、在途 Run 已处置、关键指标恢复和副作用清单已关闭。

八、长期整理：演进也需要遗忘、过期和重建¶

8.1 为什么“只追加”最终会失败¶

持续追加会产生另一种退化：Prompt 变成冲突的“铁律清单”，Skill 重复，知识互相覆盖，旧 API 经验仍被召回，索引保存已删除内容，多个临时 Harness 补丁相互作用。更多经验不一定带来更好行为。

8.2 一次离线整理周期¶

“睡眠学习”只是对离线整理的比喻，不要求夜间运行。一个周期可以是：

触发：按时间、已评价轨迹量、错误簇或存储压力启动；
盘点：读取当前知识、Prompt、Skill、代码和版本边界；
整理：去重、合并、标记冲突与适用条件，优先局部 Diff；
验证：在迁移、保留、安全和新鲜集上验证；高风险变更等待人工审批；
发布或淘汰：更新索引，把旧条目标记为过期、归档或删除，并保留来源与回滚版本。

8.3 数据生命周期与删除¶

生产经验不是无限期免费资产。每类数据应有用途、Owner、访问控制、保留期和删除路径。用户删除、法规保留和事故调查要求可能冲突，应由治理政策明确优先级和法律依据，而不是由模型决定。

原始证据、结构化分析、正式知识、训练样本、索引和模型版本之间要有派生关系。删除或撤销来源后，系统能找出并重建受影响的派生物；否则“删了原对话”却仍在向量索引或训练包中保留副本，只是表面删除。

九、经验污染与评估泄漏防护¶

9.1 经验污染从哪里来¶

经验污染（Experience Contamination）是错误、恶意、越权或不适用的内容被提升为长期能力。来源包括：

网页或邮件中的提示注入被总结为 Skill；
一次偶然成功被当作通用策略；
环境故障被误判为模型错误；
某租户的私有做法被复用到另一租户；
旧政策和新政策没有版本条件；
候选生成器修改测试，使自己“通过”。

摘要不是消毒。外部内容和模型总结始终是不可信数据；它们只能提出候选事实或规则，不能授予权限或直接成为生产指令。

9.2 训练与评估泄漏¶

评估泄漏（Evaluation Leakage）是候选生成或调参过程看到了用于最终判定的答案、Rubric细节或等价样本，导致分数虚高。控制措施包括：

按任务来源和近似内容去重，而不仅按文件名拆分；
训练／提案集、开发集和最终保留集由不同权限管理；
候选生成器不读取保留集答案和发布阈值实现；
验证器版本单独评审，不能由被评系统修改；
定期加入新鲜任务，审计公开数据是否已进入模型或提示；
报告已知污染限制，不把不可证的“绝无泄漏”写成事实。

9.3 可信根必须在演进边界之外¶

身份系统、策略网关、核心验证器、审计日志、发布门和稳定备份构成演进系统的可信根。候选 Agent 可以提出修改请求，但不能使用同一身份直接修改并批准这些对象。需要升级可信根时，走独立的软件与治理流程，并由不同 Owner 审核。

十、失败模式与反例¶

10.1 反例一：一条差评自动追加永久规则¶

问题：反馈可能误解、恶意或只适用于旧环境。

控制：绑定轨迹与环境证据，按影响决定熔断或聚类，生成候选而非直接发布。

10.2 反例二：把全部成功轨迹当训练数据¶

问题：成功可能靠偶然、越权或错误验证器获得，失败轨迹反而包含关键边界。

控制：同时评价结果和过程，保留失败、部分成功、正确拒绝和系统故障分类。

10.3 反例三：用户满意度提高就算进步¶

问题：讨好用户可能伴随虚假承诺、规则违规或隐私泄漏。

控制：Outcome、过程、质量、成本和安全分别设门；安全硬失败不可平均。

10.4 反例四：用Prompt修复确定性重试错误¶

问题：模型可能忽略指令，权限和幂等仍未被强制。

控制：把不确定写结果的查询、稳定键和重试条件写进 Harness 并测试。

10.5 反例五：用训练记住最新政策¶

问题：更新慢、来源难追踪，也无法保证及时删除和准确授权。

控制：时效事实放可版本化知识库，授权由代码执行；参数用于合适的高维能力。

10.6 反例六：Prompt和Skill只增不减¶

问题：规则冲突、上下文膨胀、适用范围不清，旧规则仍可能覆盖新规则。

控制：稳定ID、局部Diff、冲突检查、过期条件、按需加载和定期整理。

10.7 反例七：影子版本不展示答案，所以允许写¶

问题：后台仍可能退款、发消息或改数据库。

控制：从权限层禁写，使用模拟器或隔离测试租户，记录被拦截的候选动作。

10.8 反例八：候选修改自己的测试和门槛¶

问题：它可以删除失败用例或降低标准，制造自证循环。

控制：可信根隔离，生成与验证身份分离，测试和发布门只读且有审计。

10.9 反例九：只验证触发失败¶

问题：补丁可能修好退款超时，却破坏正常退款或提高越权率。

控制：同时运行触发、保留、对抗和新鲜集，比较成本与运营复杂度。

10.10 反例十：把环境故障训练进模型¶

问题：上游短暂不可用被总结为“永远不要调用该工具”。

控制：先区分 Environment、Tool、Model 与 Runtime，记录服务和接口版本及时间范围。

10.11 反例十一：回滚只切回旧模型¶

问题：Prompt、工具、政策、索引和 State Schema可能已经改变，已发生副作用也仍存在。

控制：版本化整个 Bundle，演练数据与在途 Run 兼容，盘点并补偿外部动作。

10.12 反例十二：开放任务用单一分数自动自我强化¶

问题：研究价值、长期维护性和负面结果难以即时量化，系统容易优化评分外观。

控制：分离主张与证据，保留负面结果和多样候选，让人参与目标、评价标准和停止决定。

十一、实施检查清单¶

信号、数据与归因¶

[ ] 每条候选经验绑定 Run、环境终态、过程证据、版本和评价者。
[ ] 用户反馈与事实、合规和完成证据分开解释。
[ ] 低置信或证据不足案例不会自动进入学习集。
[ ] 已定位首个关键错误，并记录反事实理由与替代归因。
[ ] 高影响单例可先熔断；一般问题经过去重、聚类和适用范围分析。
[ ] 原始证据不可变，分析修订保留版本、作者和理由。

载体与候选¶

[ ] 已在知识、Prompt／Skill、程序／Harness和参数之间说明选择理由。
[ ] 事实与时效信息不被硬编码进参数；权限和副作用不变量不只写在Prompt。
[ ] 候选是最小、可证伪、可回滚的Diff，含预期效果、保持项和风险。
[ ] 候选生成器只能写隔离工作区，不能修改稳定版、验证器、阈值和审计。
[ ] 外部依赖、网络和代码执行经过沙箱、允许列表、锁定、扫描与审批。

权限、凭据与审批¶

[ ] 在线 Run 无权直接发布知识、Skill、代码或模型参数。
[ ] 离线、影子和评估身份没有生产写权限；测试凭据只访问测试资源。
[ ] 凭据由执行层代管，不进入 Prompt、轨迹、训练数据、Artifact或命令历史。
[ ] 发布审批绑定候选 Bundle、范围、门槛、期限和回滚方案。
[ ] 业务动作审批与版本发布审批分离；升级不扩大用户授权。
[ ] 可信根由不同身份和Owner管理，变更有独立审计。

验证、发布、回滚与完成证据¶

[ ] 触发失败集、保留集、对抗集和新鲜保留集已版本化并防近似泄漏。
[ ] 候选与基线使用可比较的任务、状态、工具、预算和评分器。
[ ] Unit、Smoke、Offline和Online各自证明范围清楚，未运行项明确标记。
[ ] 影子从权限层禁写；金丝雀范围、监控和停止条件已审批。
[ ] 质量、成本、延迟、人工接管和安全分别设门，不用平均分掩盖事故。
[ ] 代码、Prompt、模型、工具、政策、知识、索引、Schema和在途Run有回滚方案。
[ ] 已发生副作用有查询、补偿或人工处置流程，不能假装回滚能抹除现实。
[ ] 完成报告包含运行ID、版本、Diff、数据集、门禁结果、审批、回滚验证和残余风险。

长期治理¶

[ ] 知识和规则有来源、Owner、适用条件、验证日期与过期条件。
[ ] 定期去重、合并、冲突检查、归档、删除和重建索引。
[ ] 用户删除、法规保留和跨租户隔离覆盖所有派生数据。
[ ] 被拒绝候选及原因得到保留，避免重复提出同一坏修复。
[ ] 长期观察激活、遵循、迁移、保留、安全和维护成本，而不只看最终分数。

知识检查¶

先用自己的话回答，再看参考解释。

为什么“保存轨迹”不等于“从轨迹学习”？
在线改进与离线改进的边界是什么？“离线”是否意味着完全断网？
用户点赞为什么不能单独作为退款 Agent 的学习信号？
什么是首个关键错误？退款案例为什么不应只修最后的通知问题？
知识、Prompt／Skill、程序／Harness和模型参数分别适合什么问题？
为什么“知识 → Prompt／Skill → Harness → 参数”不是机械的固定阶梯？
一条高影响失败为什么可以立刻触发熔断，却不能未经验证直接生成永久规则？
候选变更合同为什么要同时写expected_effect和must_preserve？
为什么只重跑触发失败集不足以证明候选变好？
影子版本不向用户展示输出，为什么仍不能持有生产写凭据？
发布审批与每笔业务动作的审批有什么区别？
为什么候选生成器不能修改批准自己的验证器和发布门？
回滚到旧版本后，为什么还要核对在途 Run 和外部副作用？
Prompt／Skill和知识为何需要过期、合并与删除，而不能无限追加？
怎样明确区分教学示例、工程建议和实测结论？

参考解释¶

第1题：轨迹只记录发生过什么，其中混有有效策略、偶然成功、错误归因和不可信输入。 只有经过结果与过程评价、跨轨迹比较、适用范围归纳和独立验证，才可能成为长期能力。

第2题：在线环服务当前Run并记录证据，离线环生成和验证下一版候选，不能直接影响真实生产动作。 “离线”指与生产副作用隔离；它可以在获批情况下访问模型服务或依赖仓库，但仍受网络、凭据和数据政策控制。

第3题：点赞可能只反映语气或短期感受。 它不能证明金额正确、审批有效、没有重复退款或没有越权，必须与权威环境和过程证据分开。

第4题：首个关键错误是最早使任务偏离成功合同的可行动转折。 本例中超时后换幂等键重试导致第二笔退款；第二条通知只是后果。

第5题：知识适合可引用事实和经验；Prompt／Skill适合可语言化的情境策略；程序／Harness适合确定性规则、状态和副作用；参数适合难以显式表达且需要广泛泛化的能力。

第6题：真正依据是能力怎样表示和验证。 同一能力可能跨层组合；一条稳定授权规则即使存在多年也应进代码，一种快速变化的语言风格也可能通过周期训练处理。

第7题：熔断是限制继续伤害的保守控制，永久规则则会长期改变大量任务。 后者仍要复现根因、检查反例、运行回归并经过审批。

第8题：expected_effect让改动可证伪，must_preserve防止修好一个问题却破坏原本成功的能力。 两者共同决定触发集和保留集的验证内容。

第9题：候选可能只记住该样本，或在其他正常、安全和未见任务上回归。 因此还需保留、对抗和新鲜集，并比较成本与运营影响。

第10题：隐藏文本不等于阻止工具。 影子 Agent 若持有写凭据，仍可退款、发信或改库，所以要在策略网关与身份层硬禁写。

第11题：发布审批允许某一Bundle在限定范围服务流量；业务审批允许某个主体对某个对象执行准确动作。 前者不能替代后者，也不能扩大用户权限。

第12题：否则系统可以删除失败用例、降低阈值或篡改证据，从而制造“自己证明自己进步”的闭环。 可信根必须由独立身份和流程维护。

第13题：旧版本可能读不懂新State，在途任务也可能继续运行；退款、消息等现实动作不会因代码回滚自动消失。 完成回滚必须核对版本、流量、任务和副作用。

第14题：无限追加会产生冲突、过期、检索干扰和上下文膨胀。 长期演进既要积累，也要有来源驱动的合并、过期、归档、删除和重建。

第15题：教学示例只说明机制；工程建议要用“本书建议”等限定并在项目中验证；实测结论必须给出可复核记录、条件和边界。 没有运行证据时应明确写“未验证”，不能虚构数字。

小结¶

持续演进不是让生产 Agent 边工作边重写自己，而是建立一个受控的证据与发布系统。在线环完成当前任务、验证终态并保存最小必要证据；离线环对失败做脱敏、评价、首错归因和聚类，再选择知识、Prompt／Skill、程序／Harness或模型参数作为载体。所有产物先成为候选，经过触发、保留、对抗和新鲜数据验证后，才沿影子、金丝雀和有界放量进入生产。

回到退款案例，真正的进步不是“下次提醒模型小心一点”，而是把不确定写结果的查询与稳定幂等键落实到 Harness，用隔离模拟器证明不会重复退款，同时证明正常恢复、权限和审批没有回归。发布时凭据最小化、审批范围明确、整套 Bundle 可回滚；发布后继续观察真实结果。长期还要清理过期经验、处理冲突、兑现删除，并让可信根始终位于自我修改边界之外。

本章把第10章的评估证据和第11章的治理边界接成改进闭环。下一章将深入参数更新：当外部知识、指令和程序不足以表达目标能力时，怎样准备数据、训练模型并检查遗忘与安全漂移。

来源与证据¶

原始书稿第9章是本章主来源，系统讨论了从轨迹取得学习信号、知识／Prompt与Skill／程序／参数四种更新载体、在线执行与离线演进双环、安全边界和长期整理。本章保留这些主线，删除了无法在本章完整复核或易过期的产品数字。¹
原始书稿第7章提供评估环境、验证器、失败归因、生产反馈与统计边界；蓝皮书第10章将其组织为 Outcome、Trajectory、System、Economics和Safety五层评估。²⁴
原始书稿第8章提供从 bad case 到 SFT／偏好学习／RL 的参数更新方法；蓝皮书第13章承接具体后训练内容。本章只定义“什么时候应把候选交给参数训练”。³⁵
P17给出“脱敏生产失败 → 首错归因 → 最小回归任务 → 候选修复 → 离线验证 → 灰度”的闭环；P18给出外部能力优先的载体选择。⁶⁷
Reflexion表明自然语言反思可作为语言反馈参与后续尝试；它不支持把模型反思本身当作环境真值或未经验证直接发布。⁸
Voyager在Minecraft环境中组合自动课程、环境反馈和可执行技能库，是“验证后保存可复用能力”的研究案例；其环境结果不能直接外推为企业生产系统的安全保证。⁹
本章没有执行新的实验。仓库第9章相关实验卡在第9章最近一次核对中仍有待证据审查项目，因此本章不把标题、计划或原稿中的量化结果当作已验证结论。¹⁰

原始中文书稿，../../book/chapter9.md，尤其是“从执行轨迹中获得学习信号”“Agent持续进化的四种方法”“构建可长期运行的持续进化闭环”“持续进化的安全边界”和“睡眠学习”。 ↩↩
原始中文书稿，../../book/chapter7.md，尤其是“自动化评估方法”“失败归因”“从评估到改进”和生产轨迹回流相关内容。 ↩
原始中文书稿，../../book/chapter8.md，尤其是“从bad case到后训练”“奖励设计”和“何时选择Mid-training、SFT与RL”。 ↩
蓝皮书，10-evaluation-observability.md。 ↩↩
蓝皮书，13-post-training.md。 ↩↩
模式卡，../patterns/P17-failure-regression-loop.md。 ↩↩
模式卡，../patterns/P18-external-first-update.md。 ↩↩
Shinn, Noah, et al. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. https://arxiv.org/abs/2303.11366 ↩
Wang, Guanzhi, et al. “Voyager: An Open-Ended Embodied Agent with Large Language Models.” arXiv:2305.16291, 2023. https://arxiv.org/abs/2305.16291 ↩
蓝皮书第9章实验卡目录，../experiments/cards/chapter9/；证据状态与使用边界见第9章“来源与证据”。 ↩

第12章 持续演进：把运行经验变成可验证的新能力¶