第 38 章 Research Brief：Reflection、Evaluation 与 Approval Patterns

要解决的读者问题

一个 Agent 得到评估失败、低置信度结论或一条反思建议后，最危险的捷径是把它们直接变成重试、改动或发布。读者需要一条能解释决策责任的闭环：哪些证据只允许再次收集，哪些证据可以形成候选改进，哪些情形必须由具名的人审查或决定停止，以及每个出口留下什么可回放的记录。

本章不重新定义第 14 章的人类参与、第 16 章的反思记录、第 17 章的评估规格，也不替代第 20 章的受控自改进。它从这些输入归纳可组合的模式：将反思、评估、批准、升级与回滚准备分层连接，而不让任何一层越权成为另一层的结论。

研究范围与非范围

读者问题	本章研究的回答	本章不回答
评估失败后何时可自动再试？	只有在任务范围、可重复性、预期副作用和重试预算都已声明，且失败不需要人工判断时，才把它路由为受限的再取证或再评估候选。	一个通用于所有工具、模型或风险等级的重试次数、延迟或成功率。
反思建议何时能改变系统？	反思先形成带证据和可证伪检查的候选；候选经过独立评估后，才进入批准或拒绝的决策入口。	模型自我批评、单一评分器或一次绿色检查已经证明根因和修复有效。
什么情形必须人工批准？	将影响范围、不可逆性、证据缺口、策略要求和回滚准备作为显式输入；路由器可以要求批准、补证、阻塞或升级。	用“人工在环”一词替代身份、授权、合规、责任分配或实际签署。
如何让之后的人理解决定？	为评估、候选、批准/拒绝、停止和复盘保留关联标识、依据、范围和未覆盖项。	真实事故管理、审计留存期、法定记录、生产回滚或组织问责流程。

已核验的一手资料与受限用途

本地键	来源明确表达的内容	允许用于本章的范围	不可外推
CH38-REF-01	Anthropic 的工程文章将 evaluator-optimizer 描述为“生成—评价/反馈”循环，并把清晰评估标准与可测的迭代价值作为适用条件；同文还将环境中的工具结果或代码执行结果称为 Agent 评估进展所需的 ground truth，并提到检查点、阻塞和最大迭代等控制。	说明自动反馈循环应依赖明确判定条件、外部证据和停止边界，而不是只看模型说明。	任何产品的默认工作流、评估器可靠性、模型能力、循环次数、真实 GitHub 问题修复或“人类审查必然充分”。
CH38-REF-02	NIST AI RMF Core 将 govern、map、measure、manage 说明为可按组织环境组合的风险管理功能，而非有序检查表；其中 govern 是跨功能的，measure 涵盖测试、评估、验证、确认及其记录，且独立审查可减轻内部偏差与利益冲突。	说明“评估结果不能脱离治理、记录和风险响应”这一风险管理背景。	法规义务、认证、固定审批步骤、固定阈值、双人复核人数或某一 Agent 产品的运行时行为。
CH38-REF-03	NIST AI RMF 1.0 将人机配置和 AI 系统监督的角色/责任区分、监督过程的定义与记录列为框架语境，并指出评估与记录结果可为管理决策提供可追溯基础。	说明批准模式应显式写出谁负责何种决定、依据何种证据，而不是用模糊的“人工确认”收口。	人必然优于系统、任一审批矩阵适合所有组织、可从框架推导具体权限或风险阈值。
CH38-REF-04	Google SRE 的事后分析实践将事件、影响、处置、成因和预防行动保留为书面记录，并强调复盘后的行动项审查和建设性、无责的学习语境。	说明反思/复盘记录需要关联影响、处置和后续行动，而不应只留下归咎式结论。	Agent 自动根因分析、Google 的组织阈值、事故流程、效果数据或任何团队的文化保证。

访问日期均为 2026-07-16。CH38-REF-01 至 CH38-REF-04 分别复用正式引用 REF-029、REF-062、REF-063、REF-059；局部来源的完整 URL、动态性和外推禁区见本章参考资料。Anthropic 页面与 NIST 在线 Core 页面可能更新，First Draft、Technical Review 与 Fact Check 必须在写作当天重读。

本书模式模型

下列名称是本书为教学与审查设计的 Pattern Card，不是 Anthropic、NIST 或 Google SRE 的现成配置、API、权限模型或组织流程。

模式	输入与输出	解决的问题	不承担的责任
Evidence-first Retry	输入为失败类别、已知副作用、范围与预算；输出为 collect_more_evidence、retry_limited 或保守停止。	防止评估失败被无条件重试放大。	不实际调用工具、等待、重试或认定外部状态未变。
Reflection-to-Candidate	输入为 Reflection Record 与可证伪检查；输出为候选改进或待补证。	防止反思文本直接变更规则、代码或长期记忆。	不证明根因，也不写入候选改变。
Separated Evaluation	将候选改进与独立 Evaluation Spec、证据矩阵和未覆盖项关联。	防止生成者/反思者单独给自己放行。	不保证评估器独立、正确或代表真实环境。
Approval Gate	输入为风险、可逆性、影响范围、策略、证据和回滚准备；输出为 approval_required、needs_evidence、blocked 或有限的 ready_for_approval。	让人类决定有明确问题、范围与依据。	不授予身份、写入、合并、发布或法律授权。
Escalate-and-Replay	保存候选、证据版本、路由理由、决定与未决项；输出为升级记录或可回放决策包。	使拒绝、停止和人工覆盖也可解释。	不替代审计系统、事故响应、真实回滚或事后分析。

模式组合约束

1. 评估不是批准。 accepted 只表示指定的证据满足指定 Evaluation Spec；它不能跨越批准门或覆盖未测风险。
2. 反思不是修复。 Reflection Record 只能生成候选和检查计划；候选未经过独立评估与范围审查，不得成为执行指令。
3. 批准不是执行。 Approval Record 应关联候选、范围、证据和刷新条件；任何实际写入、部署或回滚仍受第 11、12、14、20、41、42 章的工具、权限与变更边界约束。
4. 升级不是失败掩盖。 证据冲突、影响不清、权限不足、不可逆风险或超出预算时，保留停止理由和责任入口，比继续推测更可靠。

计划案例、图示与纯内存示例

教学案例： 一个虚构的文档 Agent 报告相对链接失效。它可以把“目标文件未在注入的链接检查证据中通过”送入 Evaluation Spec；若改动只是受控的相对路径候选且没有来源事实变更，系统只形成候选和再评估请求。若候选会改变引用来源、章节事实或超出声明目录，系统必须输出 approval_required 或 needs_evidence。该案例不宣称真实 Markdown、链接检查器、文件写入、网络、Git、CI、审批人或回滚已经运行。

计划图示： Mermaid 图应展示 Observation / Evaluation Evidence → Reflection Record → Candidate Change → Independent Evaluation → Approval Gate 的主链；四个出口分别是有限重试、补证、人工批准/拒绝和升级记录。图中必须明确三条断点：评估通过 ≠ 已批准、已批准 ≠ 已执行、反思建议 ≠ 已验证修复。

计划示例： Example Implementation 阶段可实现纯内存函数 assessFeedbackApprovalRoute(input)。它只读取注入的 scope、evidence、candidate、risk、approval 与 rollbackReadiness 对象，返回上述教学路由之一及原因。测试应覆盖证据缺失、范围扩大、可受限重试、独立评估未完成、需要人工批准、拒绝/升级和记录完整性；不得调用模型、浏览器、网络、文件、Git、CI、真实审批或回滚工具。

风险、非范围与后续核验

• 阈值伪精确： 不为“置信度”“低风险”“两人复核”或“最多重试”捏造跨组织数字。后续正文若给出项目策略，只能把它写成教学输入或另附来源与适用范围。
• 人类橡皮图章： 人工节点若没有候选范围、证据、影响、备选项和拒绝出口，就不是有效的责任边界；但本章不评估人员资格或组织授权。
• 独立性幻觉： 生成者、反思者和评估者即使由不同组件实现，也可能共享相同提示、数据或错误前提；“Separated Evaluation”只要求显式记录，不能保证统计独立。
• 回滚混淆： 候选的 rollbackReadiness 只是待审查字段，不能被写成真实环境存在快照、备份、可逆操作或已完成回滚。
• TODO(verify)： First Draft 写作当天重读 Anthropic 与 NIST 在线页面，确认 evaluator-optimizer、govern/measure 和动态页面的当前措辞；不把更新后的产品/框架内容倒填为历史事实。
• TODO(verify)： 任何将来涉及真实批准、签名、部署、变更单、审计留存、账户、权限、事故或回滚的案例，须先核验所属组织的制度与实际工具；本章不提供执行许可。
• TODO(verify)： Example Implementation 前确认本仓 Node 测试入口与既有纯内存模式；没有安全隔离时，示例保留为数据契约，不模拟真实修复或批准。

下一阶段建议

Chapter Outline 应将五张 Pattern Card、四条责任断点、虚构链接案例、图示断点、测试出口和第 14/16/17/20/41/42 章的责任边界拆成逐节蓝图。每节须区分：来源背景、本书路由模型、虚构案例和未执行事实；不得把 NIST 的风险管理框架或 Anthropic 的工程建议改写为固定审批算法。