第 14 章 Chapter Outline：Human-in-the-loop

本章把人类在环（Human-in-the-loop，HITL）写成原创的工程决策模型。NIST 的人机角色/监督结果项、OpenAI 工程指南中的触发示例、OpenAI Agents SDK Python 的暂停审批流程，以及 EU AI Act 的特定法规语境，只在各自范围内引用。行动卡、审批矩阵、审批记录、刷新条件和漏洞修复案例均为本书模型，不是厂商 API、法律意见、权限系统或真实审计记录。

章节契约

读者完成后的能力： 能将批准、复核、接管和事后纠错分开；能为一个候选动作写出行动卡与审批矩阵；能将批准约束为具体范围、证据版本和刷新条件；能在拒绝、超时、范围变化和效果未知时选择补证、阻塞或升级；能解释为什么“人同意了”不等于“系统有权执行且结果正确”。

前置知识： 已完成第 11 章，知道 Tool 请求、结果和效果不确定性不能混为一谈；已完成第 12 章，知道环境和权限是独立边界；已完成第 13 章，能识别来源与证据新鲜度。读者只需能读 Markdown 表格、键值对象和简单流程图。

章节边界： 不实现身份验证、访问控制、真实消息通知、审批队列、数字签名、外部 Tool、生产发布、漏洞扫描、法律判定或真实审计。批准并不执行动作，权限并不接受结果，拒绝也不自动指出修复方案。第 17 章负责验证结论，第 18 章负责重试恢复，第 41 章负责安全/权限/审计，第 38 章再归纳 Approval Patterns。

小节蓝图

1. 人在环不是一个按钮：先区分参与方式

• 读者问题： 为什么“所有高风险操作都弹确认框”既可能遗漏关键责任，也会制造无意义审核？
• 叙述任务： 区分批准（批准一次候选动作）、复核（判断证据/结论）、共同决策（人和系统共同选择）、接管（人接收控制权）和事后纠错（用结果修订策略）。说明它们的输入、输出、时间点和责任不同。以“Agent 建议升级一个依赖”为场景，说明人可以批准测试计划、拒绝发布、接管异常排查或复核验证，但这些不是同一件事。
• 证据边界： CH14-REF-01、CH14-REF-02 仅支持在 NIST AI RMF 1.0 风险管理语境中定义并记录人机角色、责任和监督。五种参与方式是本书分类。
• 计划工件： 参与方式对照表，列明解决的问题、最小输入、输出、不能推出的结论和负责章节。
• 验证： 给出“批准修复建议”“复核测试报告”“接管生产故障”三句话，读者能指出各自需要的工件及不能相互替代之处。
• 过渡： 参与方式明确后，下一步不是直接问人“是否同意”，而是让系统先交出可判断的行动上下文。

2. 行动卡（Action Card）：把待批准事项做成可审查输入

• 读者问题： 一句“允许修复吗？”为什么不足以让人作出负责任决定？
• 叙述任务： 定义行动卡的最小字段：意图、对象范围、动作类别、潜在效果、可逆性、依赖、证据摘要与新鲜度、替代方案、未知项、成功标准、请求者及关联标识。说明行动卡描述候选，不是已经执行的事件，也不能携带无限权限。
• 证据边界： CH14-REF-03 中的具体 Tool 参数和调用标识只用于说明某 SDK 能把审批绑定在具体调用上；本书行动卡字段不归因给该 SDK。
• 计划工件： 行动卡模板与“字段缺失时不得审批”的检查表；所有真实仓库、用户、漏洞编号和时间均用抽象占位符。
• 验证： 读者能拒绝缺范围、缺效果类别、缺证据时间或缺成功标准的请求，并说明需要补什么。
• 过渡： 完整行动卡仍不代表一律需要人工；需要一个透明的路由规则判断何时放行、何时升级。

3. 审批矩阵（Approval Matrix）：根据影响、可逆性、证据与不确定性路由

• 读者问题： 如何避免用模型自报“我有信心”作为自动执行的唯一阈值？
• 叙述任务： 将影响范围、可逆性、外部效果、证据强度/新鲜度、策略要求、失败/重试历史和未知项分开评估。构造本书矩阵的五种输出：自动候选、请求批准、补证、阻塞、升级。解释低风险并非“没有风险”，自动候选也仍必须经过第 12 章权限和第 17 章验证。
• 证据边界： CH14-REF-04 可作为该官方指南把失败阈值、高风险、敏感与不可逆动作列为人工介入触发示例的背景；本书字段、矩阵、分数和输出不是其原文规则。
• 计划工件： 影响/可逆性/证据/未知项决策表，以及 Mermaid 路由图。
• 验证： 读者能把“只读、范围窄、证据充分”“广泛写入但可回滚”“影响未知且已有超时”路由到不同出口，并写清所依据字段。
• 过渡： 路由到人工审查后，决定也需要有范围和有效期，否则旧批准会被错误复用。

4. 审批记录（Approval Record）：批准的是哪一次、在什么条件下

• 读者问题： 为什么“上周已经批准过”通常不能直接支持今天的同类动作？
• 叙述任务： 定义本书审批记录包含：行动摘要与关联标识、被批准/拒绝/要求补证的决定、作用范围、证据版本/时间、条件、理由、决定者角色、刷新条件与未覆盖范围。强调记录是审查工件，不验证身份、不授予系统权限、不保证人类已理解所有后果。
• 证据边界： CH14-REF-02 仅支持 NIST AI RMF 对角色/责任和监督过程定义、评估、文档化的语境；本书字段与刷新逻辑均为工程扩展。CH14-REF-05 仅用于提示某些法规语境可能对适用系统另有要求。
• 计划工件： 范围、条件与刷新条件对照表；“批准不是永久令牌”的反例。
• 验证： 读者能判断“目标文件列表扩大”“证据已过期”“动作从预览改为写入”为什么必须重新路由。
• 过渡： 一份范围正确的批准也只决定下一步是否可继续；暂停、拒绝和未知效果仍需要安全退出路径。

5. 暂停、拒绝、超时与效果未知：审批队列外的保守路径

• 读者问题： 人没有立即回复或拒绝后，Agent 是否该自动重试、换一种说法再请求，或继续执行？
• 叙述任务： 说明等待决定是状态，不是成功；明确拒绝应保留理由与可选后续；超时不等于默认同意；作用范围变化会使旧决定失效；外部效果未知时应先观察或升级，不能用批准覆盖历史不确定性。列出“补证、阻塞、接管、停止、重新请求”各自的触发条件。
• 证据边界： CH14-REF-03 仅支持该 SDK 可在审批处暂停、处理批准/拒绝并恢复运行的产品流程；本章不假定所有系统有中断对象、序列化状态或自动恢复。
• 计划工件： 审批状态表和异常/恢复表，明确每种状态不代表什么。
• 验证： 读者能拒绝“超时默认通过”“效果未知再执行一次”“批准范围变了但沿用旧决定”三种路径。
• 过渡： 抽象矩阵和状态表需要放到一个完整案例中，才能检验人工节点是否真能帮助控制风险。

6. 完整工程案例：依赖漏洞修复建议与人工发布门

• 读者问题： 如何让 Agent 加速漏洞分析，而不让它未经审查修改依赖、发布软件或虚构验证？
• 叙述任务： 构造教学案例：Agent 收到一份已核验的漏洞报告，整理受影响组件、变更候选、测试计划、回滚条件和未知项；人工根据行动卡批准“在隔离环境准备变更”和“发起测试”，但把生产发布、扩大依赖范围或证据过期的情况重新路由。明确案例没有扫描真实仓库、修改锁文件、运行测试、发布产物或查询漏洞库。
• 证据边界： 案例、影响等级、审批矩阵、回滚条件和结论均为教学设计，不引用具体漏洞、评分、产品策略或合规要求。
• 计划工件： 一张审批矩阵、一个行动卡、一个审批记录、一个恢复/拒绝记录，以及纯内存路由函数。
• 验证： 计划测试覆盖低影响自动候选、不可逆升级、缺证据、效果未知、过期决定、范围不符和拒绝；所有断言只证明注入对象上的判断。
• 过渡： 第 15 章将讨论 Observation 与状态感知，帮助把“需要补证”的出口变成可观察的系统状态。

章节工件状态

1. 已完成：Research Brief 与局部候选资料。产品、框架、风险管理与法规语境已分别限定。
2. 已完成：详细 Chapter Outline。各节均定义读者问题、叙述任务、来源边界、计划工件、验证和过渡。
3. 已完成：First Draft、Example Plan、纯内存示例、Mermaid 图源与 Technical / Diagram Review。示例仅处理注入对象，图只表达本书路由模型。
4. 已完成：Fact Check、Language Editing 与 Final Review。主线程仍需统一处理全局引用、目录、进度、状态和仓库总校验；这些共享项目不在本子任务写入范围。

Outline 完成检查

• [x] 覆盖参与类型、行动卡、审批矩阵、审批记录、刷新条件、暂停/拒绝/超时和完整案例。
• [x] 明确批准、权限、执行、外部效果与验证结论的区别。
• [x] 为每个主要小节给出来源边界、计划工件与可观察验证。
• [x] 未把 NIST、OpenAI SDK、工程指南或法规文本写成跨系统保证。
• [x] 相邻章节责任与后续整合边界已明确。