Day 26：Human-in-the-loop 与 Agent 可控性

学习目标

昨天设计了一个 6 Agent 的行业研究系统，它能自动完成从行业分析到方案生成的全流程。但有一个问题悬而未决：如果 Agent 做出了错误的判断，怎么办？如果它推荐了一个实际上不可行的方案，报告已经发出去了，怎么挽回？

这就是 Human-in-the-loop 要解决的核心问题。不管 Agent 有多智能，在当前技术水平下，完全自主的 Agent 是不可靠的。我们需要在关键节点加入人工审核和干预机制，让人类能在 Agent 执行过程中进行检查、修正和批准。

今天的目标是建立系统化的人工介入设计能力。学完这一天，你应该能识别哪些节点需要人工审核、设计审核表单和确认机制、理解中断与继续的实现逻辑、建立可追踪的执行记录体系。

核心概念

为什么 Agent 需要人工审核

先回答一个根本性的问题：既然 Agent 这么智能，为什么还需要人工介入？

原因有三个，每一个都是当前技术的硬约束。

第一个原因是大模型的输出不完全可信。模型会产生幻觉，会生成看似合理但实际错误的内容。在行业分析场景中，模型可能虚构不存在的市场数据、错误描述某个行业的产业链结构、把过时的信息当成最新数据。这些问题如果不经过人工审核就输出给客户，后果可能很严重——轻则丢面子，重则丢客户。

第二个原因是决策中存在主观偏好。AI 方案的推荐不只是技术判断，还涉及客户的业务策略、风险偏好、预算约束、组织文化。模型不了解这些上下文，可能推荐一个技术上最优但客户组织无法落地的方案。人工审核的价值在于注入模型缺少的业务上下文和主观判断。

第三个原因是责任归属。企业级的 AI 应用必须有明确的责任链条。如果一份报告给了客户错误的建议，谁负责？如果全程自动、无人审核，责任无法追溯。加入人工审核环节，审核人就是该节点的责任人。这不仅是一个管理要求，也是企业客户的基本诉求。

从更宏观的角度看，Human-in-the-loop 不是一个临时补丁，而是 AI 系统设计的基本原则。在可预见的未来，AI 的能力边界决定了它在企业应用中必须有人类监督。这不是”不信任 AI”，而是”合理使用 AI”。

哪些节点需要人工审核

不是所有节点都需要人工审核。过度的人工介入会抵消自动化的效率优势。关键是识别出”必须由人来把关”的节点。

判断标准有三条。第一条，这个节点的输出如果出错，后果有多严重？严重就加审核。第二条，这个节点的判断是否涉及主观偏好或业务上下文？涉及就加审核。第三条，这个节点的输出是否会影响外部系统或人员？会影响就加审核。

拿行业研究系统的 6 个 Agent 来看：

Industry Research Agent 的输出（行业概览）：建议加审核。行业概览是后续所有分析的基础，如果底层数据错了，后面的分析全部建立在错误前提上。审核重点是数据的准确性和概览的完整性。

Role Analyst Agent 和 Process Analyst Agent 的输出：可以不加审核（除非客户特别要求）。这两个 Agent 的分析结果相对客观，而且后面还有 AI Solution Agent 和 Risk Review Agent 会交叉验证。

AI Solution Agent 的输出（AI 方案推荐）：建议加审核。方案推荐直接影响客户的投资决策，涉及技术可行性、成本估算、实施周期等判断，出错后果严重。

Risk Review Agent 的输出（风险审查）：必须加审核。风险审查是对整个方案的最终把关，审核人通常是项目负责人或领域专家。

最终报告输出：必须加审核。这是交付给客户的东西，必须经过人工确认。

总结一下，行业研究系统建议在四个节点加人工审核：行业概览生成后、AI 方案推荐后、风险审查后、最终报告生成后。从效率角度看，这意味着整个流程有四次暂停等待人工确认。如果觉得太频繁，可以合并后两个审核点：风险审查和最终报告一起审核。

审核表单设计

人工审核不是简单地看一眼说”行”或”不行”。它需要结构化的审核表单，让审核人能高效、全面地评估输出质量。

审核表单的设计原则是”降低审核人的认知负担”。审核人需要在尽量短的时间内做出准确判断。表单应该把关键信息高亮展示，把判断选项标准化。

一个好的审核表单包含四个区域。

第一个区域是上下文区。展示当前节点在整个流程中的位置、上游节点的关键输出摘要、本次审核的具体对象。审核人首先需要知道”我在审什么”和”上下文是什么”。

第二个区域是内容展示区。展示被审核 Agent 的完整输出。输出内容要格式化展示，关键数据加粗或高亮。如果是长文本，提供折叠/展开功能，让审核人能快速定位关键部分。

第三个区域是审核操作区。提供标准化的审核操作选项。最基本的三个操作是：通过（Approve）、修改后通过（Modify and Approve）、拒绝（Reject）。每个操作可以附加文字说明。

第四个区域是决策记录区。记录审核人、审核时间、审核决策、审核意见。这些记录是可追溯性的基础。

以”AI 方案推荐审核”为例，表单设计如下：

上下文区：行业名称（半导体）、行业概览摘要、已分析的岗位数量和流程数量。内容展示区：AI 方案列表，每个方案展示场景名称、应用类型、ROI 估算、实施难度、风险等级。关键指标用醒目颜色标注。审核操作区：对每个方案单独审核——通过 / 需修改 / 不通过。整体审核——全部通过 / 部分通过后继续 / 全部退回重做。意见输入框。决策记录区：自动记录审核人信息、时间戳、每个方案的审核结论、总体意见。

中断与继续

Human-in-the-loop 的核心技术挑战是”中断与继续”。Workflow 或 Agent 执行到审核节点时需要暂停，等待人工输入后再继续执行。这涉及到状态持久化和恢复机制。

中断的实现需要做三件事。

第一，保存当前执行状态。包括所有已完成的节点及其结果、当前正在等待审核的节点和内容、尚未执行的节点列表、全局上下文数据。这些状态必须持久化到可靠的存储中（数据库而不是内存），因为人工审核可能几小时甚至几天后才完成。

第二，通知审核人。系统需要通过合适的渠道（邮件、消息、通知）告知审核人有待审核的内容。通知要包含足够的信息让审核人判断紧急程度：什么任务、哪个节点、审核内容摘要、截止时间。

第三，释放计算资源。暂停期间不需要占用模型资源。系统应该优雅地释放当前的连接和上下文，等待恢复信号。

继续执行的实现也需要做三件事。

第一，加载保存的执行状态。从持久化存储中恢复之前的所有中间结果和上下文。

第二，注入审核结果。将审核人的决策和修改内容更新到全局上下文中。如果审核人做了修改（比如修改了某个 AI 方案的描述），修改后的版本覆盖原始输出。

第三，继续后续流程。从暂停点继续执行。如果审核结果是”通过”，继续下一个节点。如果是”修改后通过”，用修改后的内容继续。如果是”拒绝”，根据策略决定是重试当前节点还是中止整个流程。

中断与继续的设计中最容易忽视的是”超时处理”。如果审核人迟迟不审核怎么办？通常的做法是设置审核超时时间（比如 24 小时），超时后自动发送提醒。如果二次超时（比如 48 小时），可以配置默认行为：自动通过（低风险场景）、自动拒绝（高风险场景）、升级通知（通知更高级别的人处理）。

审批结果记录

每一次审批都需要完整记录，这是可追溯性和持续改进的基础。

审批记录应该包含以下字段：任务 ID、节点名称、提交审核时间、审核人、审核开始时间、审核完成时间、审核决策（通过/修改后通过/拒绝）、修改内容（如果有）、审核意见、后续动作（继续/重试/中止）。

这些记录有两个用途。

第一是事后追溯。如果最终交付物出了问题，可以通过审批记录回放整个审核过程，看是在哪个环节漏过了问题。

第二是数据分析。统计审核通过率、平均审核时间、最常见的拒绝原因。这些数据能帮助优化 Agent 和审核流程。比如如果某个节点的审核拒绝率长期超过 30%，说明这个 Agent 的输出质量需要改进。

审批记录应该是不可篡改的。一旦写入，不允许修改或删除。这是审计合规的基本要求。如果使用数据库存储，可以通过只读权限和审计触发器来保证。

高风险动作确认

除了常规的节点审核，还有一些”高风险动作”需要特殊的确认机制。

什么是高风险动作？就是一旦执行就不可撤回、或者撤回成本极高的操作。比如：发送邮件给外部人员、修改生产数据库、创建公开可见的内容、执行支付或转账。

高风险动作的确认机制比常规审核更严格，体现在三个方面。

第一，双重确认。高风险动作需要审核人确认两次。第一次是”确认执行”，第二次是”最终确认”。两次确认之间加一个短暂的等待（比如 5 秒），防止手滑误操作。

第二，操作预览。确认前展示操作的完整预览，让审核人清楚看到即将执行什么。比如发送邮件前展示完整的收件人、主题和正文。

第三，操作记录。高风险动作的执行必须记录详细日志，包括执行人（审核人）、执行时间、操作内容、执行结果。日志保留时间应该比普通审批记录更长。

在行业研究系统中，send_email_draft 和 create_task 这两个工具的调用属于高风险动作。虽然 send_email_draft 只是生成草稿不直接发送，但草稿生成后如果错误地触发了发送流程，后果同样严重。建议在工具调用前增加确认机制。

人工反馈回写

人工审核不只是”过或不过”的二元判断，它还是一个宝贵的学习信号。审核人的修改意见、拒绝理由、补充内容，都应该被系统捕获并用于改进 Agent。

人工反馈回写的流程分为三步。

第一步，捕获反馈。审核人在审核过程中的所有操作都要被记录：修改了哪些字段、修改前后的值对比、添加了什么补充内容、拒绝了什么以及拒绝理由。

第二步，分析反馈。定期（比如每周）汇总人工反馈数据，分析模式。常见模式包括：某个字段经常被修改（说明 Agent 这个字段的生成质量差）、某个类型的方案经常被拒绝（说明 Agent 的方案设计逻辑有偏差）、审核人经常补充某类信息（说明 Agent 的知识有盲区）。

第三步，优化 Agent。根据反馈分析结果调整 Agent 的 Prompt、工具或参数。比如发现 AI Solution Agent 经常推荐”过于激进”的方案，可以在 Prompt 中增加”保守偏好”的指导。发现 Industry Research Agent 经常遗漏”监管环境”信息，可以在输出格式中把”监管环境”设为必填字段。

人工反馈回写是一个持续的过程，不是一次性动作。系统运行时间越长，积累的反馈越多，Agent 的改进就越有方向。

可追踪执行

可追踪执行是整个 Human-in-the-loop 体系的底层支撑。它的目标是让 Agent 的每一次执行都”有迹可循”。

可追踪执行包含三个层面。

第一个层面是执行日志。记录每个节点的开始时间、结束时间、输入摘要、输出摘要、执行状态（成功/失败/跳过）、Token 消耗、工具调用记录。

第二个层面是审批日志。记录每次人工审核的完整信息，如前面所述。

第三个层面是变更日志。记录 Agent 输出被人工修改的所有变更，包含修改前后的对比。

这三个层面的日志组合起来，能完整回放任何一次任务执行的全过程：Agent 做了什么、人工审了什么、改了什么、最终输出了什么。

可追踪执行还有一个容易被忽视的价值：它是构建客户信任的工具。企业客户对 AI 系统的信任不是来自”系统很智能”，而是来自”系统透明可控”。当你能向客户展示每一次执行的完整记录，包括 AI 的分析过程和人工的审核决策，客户会更愿意接受和采用系统。

概念关系图

Human-in-the-loop 在行业研究系统中的位置

用户输入
  |
  v
[Phase 1] Industry Research Agent
  |
  v
== 人工审核点 1：行业概览 ==
  |-- 审核内容：产业链、市场规模、趋势判断
  |-- 审核操作：通过 / 补充修改 / 退回重做
  |-- 审核重点：数据准确性、信息完整性
  |
  v
[Phase 2] Role Analyst Agent + Process Analyst Agent（并行）
  |
  v
[Phase 3] AI Solution Agent
  |
  v
== 人工审核点 2：AI 方案推荐 ==
  |-- 审核内容：方案可行性、ROI 估算、实施建议
  |-- 审核操作：逐方案审核 + 整体审核
  |-- 审核重点：技术可行性、与客户业务匹配度
  |
  v
[Phase 4] Risk Review Agent
  |
  v
[Phase 5] 最终报告生成
  |
  v
== 人工审核点 3：最终报告 ==
  |-- 审核内容：报告完整性、数据一致性、措辞专业性
  |-- 审核操作：通过后交付 / 退回修改
  |-- 审核重点：客户视角的可用性
  |
  v
交付给客户

中断与继续的状态流转

执行中 ---> 遇到审核节点
              |
              v
           保存状态到持久存储
              |
              v
           通知审核人
              |
              v
           等待（释放资源）--- 超时 ---> 提醒 ---> 再超时 ---> 默认处理
              |
           审核完成
              |
              v
           加载状态
              |
              v
           注入审核结果
              |
              v
           继续执行

高风险动作确认流程

Agent 请求执行高风险动作
  |
  v
系统识别为高风险（工具权限表标记）
  |
  v
展示操作预览（完整展示将要执行的操作）
  |
  v
第一次确认："确认执行此操作？"
  |
  v
短暂等待（5 秒）
  |
  v
第二次确认："最终确认，此操作不可撤回"
  |
  v
执行操作 + 记录详细日志

实战分析

实战任务一：给 Agent Workflow 加入人工审核节点

基于昨天设计的 Multi-Agent 系统，在关键位置加入人工审核。具体设计如下。

在 Orchestrator Agent 的调度逻辑中，定义三个审核检查点：

检查点 1（行业概览审核）：在 Industry Research Agent 完成后、启动 Role Analyst 和 Process Analyst 之前。审核内容是行业概览的完整性和数据准确性。通过后继续，退回则 Industry Research Agent 重新生成。

检查点 2（AI 方案审核）：在 AI Solution Agent 完成后、启动 Risk Review Agent 之前。审核内容是 AI 方案的可行性和业务匹配度。通过后继续，退回则 AI Solution Agent 重新设计（可能需要补充信息）。

检查点 3（最终报告审核）：在报告生成完毕后。审核内容是报告的整体质量。通过后交付客户，退回则根据问题定位到对应 Agent 重新生成。

实战任务二：设计审核表单

以”AI 方案推荐审核”为例，详细设计审核表单。

表单标题：AI 方案审核 - [行业名称] - [日期]

上下文区：

行业名称：半导体
分析范围：封装测试环节
已识别岗位：8 个
已分析流程：5 个

内容展示区（每个方案一个卡片）：

方案编号和名称
应用类型标签（Copilot/Agent/Workflow/RAG）
方案描述摘要
ROI 估算：投资 XX 万，年节省 XX 万，X 个月回本
实施难度：高/中/低
风险等级：高/中/低
需要的数据和系统
展开查看完整描述

审核操作区：

对每个方案：
- 通过（Approve）
- 修改后通过（需要填写修改内容）
- 不通过（需要填写理由）
整体操作：
- 确认审核结果，继续流程
- 全部退回，重新设计方案
审核意见输入框

决策记录区（自动生成）：

审核人：[姓名]
审核时间：[时间戳]
方案 1：通过
方案 2：修改后通过（修改了 ROI 估算）
方案 3：不通过（理由：技术可行性不足）
总体意见：方案 1 和修改后的方案 2 可以继续，方案 3 需重新评估

实战任务三：设计高风险工具调用确认机制

为 send_email_draft 和 create_task 设计确认流程。

当 Agent 请求调用这两个工具时：

第一步，系统检查工具权限表，识别为”高风险”级别。

第二步，暂停执行，向 Orchestrator 报告”需要人工确认的高风险操作”。

第三步，展示确认界面，包含：工具名称、Agent 名称、完整参数（收件人、主题、正文等）、操作预览。

第四步，等待审核人确认或拒绝。

第五步，确认后执行工具调用，拒绝后向 Agent 返回”操作被拒绝”信息。

第六步，记录操作日志。

当日产物说明

《Human-in-the-loop 设计》

这个文档描述行业研究系统中人工审核的整体设计，包括：为什么需要人工审核、审核点位置及理由、审核流程设计、中断与继续的状态管理、超时处理策略。

质量标准：文档能让一个不了解项目的人理解人工审核的设计逻辑和实现思路。审核点的选择有明确的判断标准支撑。

《人工审核表单》

三个审核点的完整表单设计文档。每个表单包含四个区域的详细设计：上下文区、内容展示区、审核操作区、决策记录区。

质量标准：表单设计可以直接交给前端开发实现。所有字段、操作按钮、交互逻辑都有明确定义。

《高风险动作确认机制》

send_email_draft 和 create_task 两个高风险工具的确认流程设计。包含：识别规则、暂停机制、确认界面设计、执行/拒绝后的处理逻辑、日志记录格式。

质量标准：确认流程覆盖了误操作防护（双重确认）、操作可见性（预览）、事后追溯（详细日志）三个安全维度。

常见误区与避坑

误区一：每个节点都加人工审核

过度审核会让系统退化成”人工操作，AI 辅助”。效率大幅下降，审核人也容易疲劳，反而降低审核质量。只在真正需要的节点加审核，其他节点依赖自动化质量检查（输出格式校验、数据合理性检查）。

误区二：审核只有”通过”和”不通过”两个选项

现实的审核场景比二元判断复杂得多。审核人可能觉得”大方向对但细节要改”，或者”这部分可以，那部分不行”。表单必须支持”修改后通过”和”部分通过”等中间状态。强制二元选择只会逼审核人要么全盘接受、要么全盘否定，两种极端都不好。

误区三：不处理审核超时

审核人可能出差、请假、或者单纯忘了。如果没有超时机制，整个任务就永远卡在那里。必须设置审核超时时间和超时后的默认处理策略。超时策略应该根据节点风险等级区分：低风险节点超时可自动通过，高风险节点超时应该升级通知。

误区四：忽视人工反馈的价值

审核人的修改和拒绝理由是改进 Agent 的最佳数据源。如果只是”审完就过了”，这些反馈就浪费了。建立定期分析反馈数据的机制，把审核人的智慧回写到系统中。

误区五：审核记录不完整

审核只记录”通过”或”不通过”，不记录审核人看了什么、改了什么、为什么做这个决定。这种残缺的记录无法支持事后追溯和持续改进。审批记录要越详细越好，宁可多记不可少记。

延伸思考

Human-in-the-loop 是连接技术系统和业务实践的桥梁。它不仅是一个技术设计问题，更是一个组织管理问题。

在实际项目中，审核人的选择直接影响系统质量。审核人需要同时具备两方面的能力：对 Agent 分析领域的专业判断力，以及对 AI 系统局限性的理解。一个纯技术人员做审核，可能忽视业务合理性；一个纯业务人员做审核，可能无法判断 AI 输出的技术可行性。

从 Week 5 的角度看，Human-in-the-loop 的设计会影响系统的成本模型。每次人工审核都意味着时间成本和人力成本。如果审核频率太高，系统的运营成本可能超过它节省的成本。评估系统 ROI 时要把人工审核成本计算在内。

从 Week 7 商业化的角度看，Human-in-the-loop 也是产品包装的卖点。当你向客户展示”AI 自动分析 + 专家审核把关”的双保险模式时，客户的接受度会远高于”完全自动”的模式。企业客户需要的安全感不是”AI 永远正确”，而是”出了问题有人兜底”。

还有一个值得思考的方向：随着系统运行时间增长、反馈数据积累，可以逐步减少人工审核的频率。初期每个关键节点都审核，等 Agent 的输出质量稳定后，只保留最高风险节点的审核。这种”渐进式放手”的策略，既保证了初期的安全性，又兼顾了长期的效率。

自测问题

为什么 Agent 需要人工审核？三个原因分别是什么？
判断一个节点是否需要人工审核的三条标准是什么？
一个好的审核表单应该包含哪四个区域？每个区域的作用是什么？
中断执行时需要保存哪些状态信息？为什么不能只保存在内存中？
继续执行时需要做哪三件事？
审核超时应该怎么处理？低风险节点和高风险节点的超时策略为什么不同？
高风险动作的确认机制比常规审核多哪三个保障？
人工反馈回写的三步流程是什么？反馈数据怎么用于改进 Agent？
可追踪执行包含哪三个层面的日志？它的价值是什么？
为什么说 Human-in-the-loop 不仅是技术问题，也是组织管理问题？

关键词

Human-in-the-loop：在 AI 系统执行过程中引入人工审核和干预的设计模式
审核节点：系统中需要暂停等待人工确认的执行点
审核表单：结构化的人工审核界面，包含上下文、内容展示、操作和记录四个区域
中断与继续：系统暂停等待审核、恢复后继续执行的机制
审批记录：对每次人工审核的完整日志，用于追溯和分析
高风险动作确认：对不可撤回操作的特殊双重确认机制
人工反馈回写：将审核人的修改意见用于改进 Agent 的持续优化机制
可追踪执行：对 Agent 每次执行的完整记录体系，支持事后回放
审核超时：审核人在规定时间内未完成审核时的默认处理策略
渐进式放手：随着 Agent 质量提升逐步减少人工审核频率的策略

MindCarver Blog

MindCarver

探索

Day26-Human-in-the-loop与Agent可控性