第 20 章 Research Brief：自改进的工程边界与长期运行 Agent

要解决的读者问题

当 Agent 从失败轨迹中提出“我应该修改自己的 Prompt、Skill 或重试策略”时，什么能阻止它把一次偶然结果或一段自我解释变成未经审查的系统变更？本章把自改进限定为：产生一个可识别、可比较、可拒绝的候选变更，并通过独立验证、范围批准、监控计划与可回滚性检查后，才可被允许进入受控发布流程。

本章不训练模型、不修改权重、不提供递归自改进承诺，也不运行真实发布、持续监控、回滚或后台任务。第 16 章只产出反思候选；第 17 章只给出评估结论；第 18 章处理单次失败的重试与恢复；第 19 章处理长任务的上下文压缩。本章消费这些工件，为“是否允许改变 Harness”建立额外的治理边界。

计划中的可归因陈述

陈述	候选来源	使用限制
Harness 可以作为围绕模型的执行、工具、上下文、持久工件与评估的系统；自改进研究可把候选提出、评估与接受组织为循环。	REF-001	只作为作者文章的研究框架；不引用实验结果、未来预测或产品能力。
Canary 是部分、限时部署和评估，用于决定是否继续发布；可归因监控与小变更有助于降低发布风险。	REF-009	只作发布门与可观测性类比；不是 Agent 默认部署算法。
NIST AI RMF Core 的自愿风险管理语境包含持续风险管理、角色责任、上线后监控、恢复和变更管理。	REF-070	不写成法律义务、认证或固定流程；在线页面后续需重读。
配置实践强调变更追踪、所有权、渐进应用与回滚能力。	REF-071	只提供可审计变更的工程背景；不外推到全部 Agent 工件。

本书工程扩展

• 候选改进协议（Candidate Change Protocol）：候选 ID、目标、范围、基线、拟议变更、独立验证、批准、监控、回滚和停止条件组成的书面契约。
• 变更门（Change Gate）：候选只有在范围匹配的独立验证明确通过、批准明确覆盖该范围、回滚已准备且监控信号具名时，才返回 ready_for_controlled_release。
• 长期健康检查：用版本、漂移、资源预算、未决告警与人工所有者检查长期任务是否仍可继续；它是本书检查表，不是自动运维系统。

写作决策

问题	本章回答方式	拒绝的捷径
候选何时不是改进？	它没有独立验证、可比较基线或明确适用范围时，只是待研究假设。	把模型反思、一次评估通过或局部指标上升视作发布许可。
谁决定是否发布？	以范围明确的批准记录和指定责任人为门；纯函数只能返回缺批准。	从测试通过、Agent 自我报告或旧批准推断授权。
长期运行如何不失控？	设定预算、版本、监控、停机/升级与回滚工件。	让任务“持续优化”而不设退出或资源上限。

计划交付物

• 原创正文：区分反思、评估、恢复、改进候选和发布；给出长期运行治理边界。
• Mermaid 图：候选从失败证据到变更门、受控发布、监控和停止/回滚的本书模型。
• 纯内存示例：assessImprovementChange 只判断注入对象，不修改任何配置或外部环境。
• 事实核验、技术/图示/语言/终审记录：逐项记录来源边界和实际命令。

风险与核验策略

• 相关不等于因果： 失败聚类和一次通过不证明候选造成改善；要保留基线、范围、比较方法和不确定结论。
• 验证不等于批准： 独立验证通过后仍需范围批准；批准不覆盖生产或更大权限范围。
• 回滚幻觉： 只有“有版本号”不代表可恢复；需要明确目标、前提、演练或现实限制。
• 长期漂移： 环境、数据、模型、规则与成本均可能变化；没有健康检查和停止条件的循环不能称为受控。

阶段门

• [x] 已实际读取四项原始/官方候选资料，并限定其可归因范围。
• [x] 已将来源陈述、本书模型和教学案例分开。
• [x] 已明确第 16 至 19 章的责任边界。
• [x] 已计划示例与图示，且不把它们写成真实长期运行或自改进证明。