人在回路中的AI：工作原理及适用场景
人在回路中的 AI（HITL）是一种设计模式：将人的判断力直接嵌入 AI 系统的决策或执行周期中，用于标注训练数据、审核模型输出，或在代理操作生效前批准这些操作。简而言之：只要 AI 可能触发现实世界中的副作用、错误难以逆转且代价高昂，或监管问责要求由明确指定的人对决策负责，就应当使用它。
本文将全面介绍这一主题，从技术上如何构建闭环，到如何设计一个能够在生产环境中经受考验的系统。
目录
- 人在回路中的 AI 究竟如何运作？
- HITL 为什么重要：准确性、安全性与信任
- HITL 应用在哪里：真实世界案例
- 如何设计生产级 HITL 系统？
- HITL、人在监督回路中与人在回路之上的区别
- 大规模运行 HITL 面临哪些真正的挑战？
- 部署 HITL 系统的实用检查清单
- 当前研究如何看待 HITL 的未来？
- 关键要点
- 大多数团队对 HITL 的错误理解
- Deskhero 将人工监督置于 AI 客服的核心
- 实用来源
- 常见问题
人在回路中的 AI 究竟如何运作？
这里的“回路”并不是比喻，而是一系列具体的检查点：人的输入会在这些检查点进入系统，系统要么等待输入，要么以异步方式接收并处理输入。
人在其中参与的阶段主要有两个：
训练阶段的 HITL包括由人标注原始数据、评估模型输出质量，以及提供偏好信号。基于人类反馈的强化学习（RLHF）是其中的典型例子，也是大多数大语言模型对齐工作的基础技术。标注员对模型回复进行排序；这些排序会转化为奖励信号；模型再依据该信号进行微调。主动学习是相关模式：模型会标记自己最没有把握的样本，由人工标注员优先处理，从而让有限的标注预算发挥更大作用。
运行时 HITL是当今大多数生产价值所在。随着代理从演示走向生产环境，在发送电子邮件、写入数据库等可能产生副作用的操作之前进行审批，已经成为企业采用这类技术的基本要求。其工作机制如下：
“HITL 中间件可以暂停代理的工具调用，并显示一个中断提示，列出需要审核的操作；系统会持久化代理状态，使执行能够在人类做出决定后安全恢复。通常支持的决策类型包括：批准、编辑、拒绝、回复；条件中断则允许根据工具参数进行拦截。” — LangChain HITL 文档
实际流程大致如下：
- 标注原始数据或模型输出，并添加人工标签
- 重新训练或微调模型，使其学习经过修正的样本
- 部署更新后的模型或代理到生产环境
- 对高风险工具调用执行中断，将其转交人工审核员
- 做出决定（批准 / 编辑 / 拒绝 / 回复），然后恢复执行
- 将该决定记录为结构化反馈，并将其送回训练流程
同步处理与异步处理之间的区别在这里非常重要。同步（阻塞式）拦截会完全暂停执行，直到审核员采取行动。异步（非阻塞式）模式则允许代理在审批等待期间继续处理其他任务。生产级运行时必须持久化状态，因为审批可能需要几分钟、几小时，甚至几天；因此，除了本地测试之外，内存状态都不足以支撑实际使用。
代理配置可以将特定工具标记为需要审批，并设置判断条件，使得只有某些调用参数会触发中断。这种粒度能够让审核队列保持可控，并防止提醒疲劳。
HITL 为什么重要：准确性、安全性与信任
在 AI 中引入人工监督的商业价值并非抽象概念。在生产部署中，以下三项具体收益始终十分明显。
边缘案例的准确性。当现实发生变化，或输入超出训练分布时，基于历史数据训练的模型会逐渐失效。人工审核员能够发现异常；如果修正结果被妥善记录，就会成为训练数据，帮助改进下一版本模型。正是这个闭环让系统能够自我纠正，而不是在错误发生时保持沉默。
更安全的操作。能够发送邮件、更新记录或处理退款的 AI 代理，如果依据错误分类的输入采取行动，可能造成真实损害。在可能产生副作用的工具调用之前设置审批门，是直接有效的缓解措施。HITL 在将人工审核保留给高影响决策时最为有效，而不是审核每一个输出。因此，在成熟部署中，基于风险的路由——使用置信度阈值和风险评分——已成为标准做法。
审计轨迹与可解释性。在一个记录完善的 HITL 系统中，每一次人工决策都是带时间戳的记录：谁审核了它、做出了什么决定，以及代理接下来执行了什么。监管机构、合规团队和事后事件审核人员都需要这些日志。没有这些记录，你拥有的只是一个由人对输出进行机械盖章的黑箱，而这两者并不是一回事。
此外，还有一项经常被低估的复合收益。当人工反馈被当作运营数据来处理——被采集、治理并送回重新训练或微调流程，而不是存放在彼此割裂的队列中——它的价值会最大化。对审核员修正进行系统记录的团队，会看到模型性能随着时间推移而改善；依赖静态训练集的团队则无法获得这种效果。
HITL 应用在哪里：真实世界案例
这种模式出现在各个行业，但人的角色会因领域不同而有很大差异。
医学影像。放射科医生会在诊断结果进入患者病历前，审核 AI 标记的异常。AI 缩小检查范围，临床医生做出最终判断。单独使用任何一方都不如二者结合可靠；在美国，包括 FDA 针对 AI 医疗器械的指导在内的监管框架，要求许多诊断应用具备有记录的人工监督。
内容审核。平台使用分类器标记可能违规的内容，然后将边界案例转交人工审核员。分类器负责处理规模，人工负责理解细微差异、上下文和申诉。这里的挑战在于，审核员的决定本身也是训练数据，因此不一致的审核会导致不一致的模型。
客服代理。在客服工作流中，AI 与人的协作尤其值得关注。能够起草回复的代理很有用；能够发送回复、更新订单或发放退款的代理则更强大，但风险也更高。在这些写入操作之前设置审批门，是有用工具与潜在责任之间的分界线。人工审核拟议操作，批准或编辑后，再由代理执行。
欺诈调查。欺诈模型会为交易评分并标记高风险交易。人工分析师审核被标记的案例，做出最终判断，而该决定会反馈给模型。分析师的领域经验能够发现模型此前未见过的模式。
数据标注流程。这是最初的 HITL 使用场景：众包标注员或领域专家为图像、文本或音频添加标注，从而创建监督式训练集。Scale AI 和 Amazon Mechanical Turk 等服务将这一流程规模化，但如何对标注员进行质量控制仍然是重大的运营挑战。
专业提示：具体到客服场景，HITL 价值最高的时刻不是起草回复，而是在任何会改变账户状态的操作之前进行审批。无论模型置信度如何，都应始终将这些操作转交人工。
如何设计生产级 HITL 系统？
要让 HITL 在生产环境中真正发挥作用，不能只增加一个“审核”步骤。架构必须将状态持久化、审核员路由、超时处理和反馈采集作为一等公民来设计。
持久化执行与状态保存
持久化执行是可中断代理的核心设计要求。系统应持久化执行图，并在接收到人工输入后恢复执行，以避免审批需要数小时或数天时丢失上下文。测试时，内存保存器完全够用；生产环境则应使用 AsyncPostgresSaver 或 MongoDBSaver 等持久化检查点保存器。如果系统在中断与人工决定之间崩溃或重启，代理状态必须能够保留。
审批门模式
| 审批门类型 | 适用场景 | 权衡 |
|---|---|---|
| 按工具审批 | 高风险工具（发送邮件、写入数据库） | 控制精准；配置开销更大 |
| 全局标记 | 敏感代理中的所有工具调用 | 启用简单；可能让审核员应接不暇 |
| 条件判断 | 根据参数值进行拦截（例如金额阈值） | 精准；需要编写判断逻辑 |
| 有序中断队列 | 一次运行中存在多个待处理审批 | 保持执行顺序；增加延迟 |
路由与升级
提前决定谁审核什么。领域专家的成本高于通用审核员，且可用时间更少，因此应进行相应路由。为人工响应时间设置 SLA，并定义未达到 SLA 时的后备行为：代理是无限期暂停、升级给高级审核员，还是采取安全的默认操作？没有明确后备方案的超时，是生产事故的常见来源。
审计日志与审核员界面
设计审核员界面时，应着眼于产生高质量决策，而不只是获取批准。带有受限选项（批准 / 编辑 / 拒绝）的表单，比自由文本评论框更能生成干净的训练数据。记录每一个决定，包括时间戳、审核员 ID，以及中断发生时的代理状态。这份日志既是审计轨迹，也是训练数据集。
专业提示：将审核员界面视为数据采集工具。你在决策表单中增加的每个字段，都是下一版本模型可以使用的特征。应在构建代理之前设计好界面，而不是事后补做。
对于专门构建聊天机器人转人工流程的团队，同样的原则也适用：持久化对话状态，将对话路由给合适级别的客服人员，并记录转接原因。
HITL、人在监督回路中与人在回路之上的区别
这三个术语描述的是确实不同的监督模式。混淆它们会导致设计被错误应用。
| 术语 | 时机 | 人的角色 | 是否阻塞执行？ | 最适合 |
|---|---|---|---|---|
| 人在回路中（HITL） | 同步 | 在操作前批准或编辑 | 是 | 高风险、会产生副作用的操作 |
| 人在监督回路中（HOTL） | 异步 | 监控并可进行干预 | 否 | 高数量、低风险的输出 |
| 人在回路之上（HOverT） | 战略层面 | 制定政策、审计结果 | 否 | 治理与受监管系统 |
被动监控（HOTL）与同步把关（HITL）存在根本区别。设计人员应根据风险等级与吞吐量匹配监督模式。混合系统通常会结合多种方式：写入操作使用 HITL，只读输出使用 HOTL，政策和模型治理使用 HOverT。
Stanford HAI 与行业专家建议将人视为决策者，这种理念有时被称为“人类掌权”，而不是简单地把人插入数据流程。这一区别会将设计重点从减少人工接触点转向可审计性与人工工作流。由 AI 充当助手、同时由人保留最终权力的系统，与仅仅把人当作另一种数据来源的系统，在架构上完全不同。
选择模式时可参考以下指导：
- 高风险 + 不可逆操作：始终使用 HITL
- 高数量 + 可逆输出：使用带升级路径的 HOTL
- 受监管行业 + 董事会层面的问责：使用 HOverT 负责治理，并针对特定决策类别使用 HITL
- 低风险 + 高置信度：可考虑在监控的前提下完全移除人工审核
大规模运行 HITL 面临哪些真正的挑战？
HITL 的成本是真实存在的，而且在设计阶段经常被低估。
可扩展性。同步审批门会增加延迟，并需要占用人工资源。随着数量增长，审核队列会成为瓶颈。缓解方法是基于风险进行路由：利用置信度阈值和风险评分，只升级高影响、不确定或受监管的决策。把所有任务都交给人工，会违背自动化的初衷。
偏见放大。这是更隐蔽的风险。基于人工修正训练的模型会继承人的偏见。更糟的是，一个对齐良好的模型可能会在规模化运行中放大这些偏见。这里的对齐与互补之间的张力十分重要：完全对齐的模型可能强化人的错误，而能够利用不同优势的互补模型，可能比任何一方单独工作都产生更好的结果。审核员多样性、校准培训和评分者间一致性检查，都是相应的运营缓解措施。
隐私与数据治理。人工审核员会看到真实数据。在客服、欺诈检测和医疗领域，这些数据通常包含个人身份信息。应建立数据最小化政策：对审核员无需查看的字段进行编辑或假名化。明确审核员决定及其所依据数据的保留政策。
人的疲劳与不一致。审核员每天做出数百个决定后，其判断标准会逐渐漂移，决策质量也会下降。缓解措施包括：
- 根据任务复杂度，将每名审核员的每日审核量限制在有理有据的阈值内
- 定期开展校准会议，让审核员对相同案例评分并比较结果
- 将评分者间一致性（Cohen’s kappa 或类似指标）作为运营指标跟踪
- 让审核员轮换不同任务类型，避免形成思维定式
- 安排强制休息，并标记批准率明显偏离基线的审核员
成本。人工审核成本高昂。HITL 的商业价值取决于避免错误的成本与审核员时间成本之间的比较。在决定对每个操作都设置同步审批门之前，应明确建立成本模型。
部署 HITL 系统的实用检查清单
在发布 HITL 系统之前，请按以下顺序逐项完成。
- 风险评估。列出代理能够采取的每项操作。根据可逆性和影响对其分类。只对高影响且难以逆转的操作设置拦截。
- 定义审核员。确定谁审核什么。是领域专家、通用审核员，还是分级升级？明确其访问权限、SLA 和后备方案。
- 界面设计。在构建代理之前，先构建受限的决策表单。确定需要哪些结构化响应类型（批准 / 编辑 / 拒绝 / 回复），以及要采集哪些元数据。
- 持久化策略。为生产环境选择持久化检查点保存器。在正式上线前，明确测试状态恢复能力。
- 反馈采集。从第一天起，就将审核员决定接入受治理的数据流程。彼此割裂的队列意味着你支付了人工审核成本，却无法获得模型改进收益。
- 治理。明确谁负责审核员团队、谁审计决策日志，以及谁有权更改路由规则。
上线后应跟踪的关键指标：
- 审核率：触发人工中断的代理操作占全部代理操作的百分比
- 决策耗时：从中断到人工决策的延迟中位数和第 95 百分位数
- 批准比例：被中断的操作中，直接批准、编辑或拒绝各占多大比例
- 模型改进率：审核员修正如何随着时间推移改变模型性能
- 评分者间一致性：不同审核员针对相同输入做出决定的一致程度
何时减少人工审核：使用置信度阈值开展受控实验。如果高于某一置信度分数的操作，在持续一段时间内几乎没有编辑或拒绝，那么该阈值就可能适合自动化。逐步降低阈值，并监控模型是否发生漂移。
当前研究如何看待 HITL 的未来？
目前最有趣的研究并不是如何把更多人加入回路，而是如何让人工接触点变得更加智能。
关于自适应集成的研究表明，根据上下文在对齐模型和互补模型之间进行路由，可以让人机团队的结果超越任一模型单独实现的效果。关键在于，你并不总是希望 AI 与人保持一致。有时你希望它发现人遗漏的内容，而这需要不同于纯粹对齐的模型架构。
Stanford HAI 提出的“人类掌权”理念正在政策圈和工程团队中获得更多关注。它将设计问题从“如何减少人的参与”重新定义为“如何让人的权力具有实质意义并且可审计”。这一转变会带来真实的架构影响：相比优化吞吐量，它更重视决策记录、审核员工作流和升级路径。
在 2025 年和 2026 年逐渐成为主流的实用运行时模式包括：
- 以基于中断的审批门为基础，并将持久化执行作为任何能够采取副作用操作的代理的默认架构
- 使用结构化人工响应表单限制审核员的选择，并生成干净的训练数据
- 采用基于置信度的路由，根据模型确定性和历史批准率动态调整哪些操作需要人工审核
- 使用关注互补性的模型集成，根据任务更适合对齐还是独立判断，将任务路由到不同模型变体
值得开展的一项实验是：分析当前审批队列，按工具类型和置信度区间统计编辑率与拒绝率。结果几乎总会显示，少数工具调用贡献了绝大多数编辑。这正是 HITL 投入真正产生价值的地方，而且通常并不是你原先预想的位置。
专业提示：按置信度十分位跟踪批准比例。如果最高置信度区间的批准率接近 100%，说明你正在为不需要的人工审核付费。如果最低区间的拒绝率接近 100%，说明模型需要重新训练，而不是增加更多审核员。
如果你的团队正在构建生产级 HITL 工作流，可以了解 Interval AI 如何将人工判断与代理运行时结合起来。
关键要点
人在回路中的 AI 的最高价值，在于将人工判断嵌入会产生副作用的操作的运行时审批门，而不仅仅是用于训练流程；同时，还要将审核员的决定作为受治理的数据采集下来，用于改进模型。
| 要点 | 详情 |
|---|---|
| HITL 是运行时模式，而不仅是训练技术 | 在代理执行可能产生副作用的操作前设置审批门，已经成为生产部署的基本要求。 |
| 基于风险的路由让 HITL 保持可扩展 | 利用置信度阈值，将同步人工审核保留给高影响、不确定或受监管的决策。 |
| 持久化执行不可妥协 | 生产系统必须在中断期间持久化代理状态；当审批需要数小时或数天时，内存保存器会失效。 |
| 人类掌权胜过人类处于数据流程中 | 围绕人的权力和可审计性进行设计，比单纯减少人工接触点能带来更好的结果。 |
| Deskhero 原生实现 HITL | Deskhero 的 AI 会起草回复，并在不确定时转交人工；每个自动化操作都会被标记并记录。 |
大多数团队对 HITL 的错误理解
有一种 HITL 采用方式，从外部看似乎正确，但内部却在悄悄失败。团队增加了审核步骤，审核员没有认真阅读便对 95% 的输出点击批准，于是组织宣布系统“受到人工监督”。审计轨迹存在，治理复选框也已勾选，但由于反馈是噪声，模型始终没有改进。
这种失败源于把 HITL 当作责任防护盾，而不是学习机制。审批门当然是为了捕捉错误，但其更深层的目的，是生成关于模型在哪里出错以及为何出错的结构化、受治理数据。真正理解这一点的团队，会构建能够记录操作被编辑的原因的审核界面，而不只是记录操作被编辑过。他们会跟踪评分者间一致性，开展校准会议，并将审核员团队视为数据质量问题，而不是人员数量问题。
另一个被低估的问题是“人类掌权”这一理念。大多数 HITL 实施方案都希望随着时间推移减少人的参与，这作为效率目标是合理的。但在高风险领域，目标应当是随着系统成熟，让人的权力变得更有实际意义，而不是让人的存在感越来越弱。这意味着要为审核员提供更好的工具、更清晰的升级路径，以及能够让人真正改变模型行为的治理结构，而不仅仅是批准单个输出。
最能从 HITL 中获益的团队，会把它视为一种组织能力，而不是一个技术功能。技术反而是最容易的部分。
Deskhero 将人工监督置于 AI 客服的核心
如果本文的检查清单描述了优秀 HITL 的样子，那么 Deskhero 正是围绕这些原则为客服团队打造的。AI 会起草回复并读取附件，但除非你主动选择启用，否则任何内容都不会自动发出。每个自动化操作都会被标记并记录。AI 一旦不确定，就会立即转交人工，因此绝不会编造答案。
知识库只会从团队批准过的内容中增长：已解决的工单和你自己的网站页面会转化为 AI 可以使用的 FAQ 条目，但必须在客服人员确认后才会生效。这个审批门在实践中就是 HITL，而不只是理论上的 HITL。对于电商团队，Shopify AI support 集成会让人工继续掌控账户和订单变更，正是因为这些属于最重要的副作用操作。
Deskhero 可以直接在 Gmail、Google Workspace 或 Microsoft 365 中运行，无需迁移。无需信用卡即可开始30 天免费试用，了解以 HITL 为先的帮助台在实践中如何运行。
实用来源
以下来源先按实用性、再按研究深度排列。如果你正在构建系统，可以先阅读文档和行业文章；如果需要理论基础，再阅读学术论文。
| 来源 | 涵盖内容 |
|---|---|
| LangChain HITL 文档 | 中断机制、决策类型、持久化模式，以及按工具配置审批 |
| inference.sh HITL 运行时文档 | 单标记审批门配置、持久化执行和生产环境持久化要求 |
| Databricks HITL 博客 | 基于风险的路由、将反馈作为运营数据，以及 HITL 与 HOTL 的权衡 |
| IBM：什么是人在回路中的 AI？ | 企业视角、代理副作用风险和采用模式 |
| Stanford HAI：什么是人在回路中的 AI？ | 人类掌权思维、政策视角和监督设计原则 |
| Stanford HAI：人在回路中——交互式 AI 系统的设计 | 关于交互式 AI 系统设计与人机协作模式的研究综述 |
| AAAI：在对方希望时对齐，在需要时互补 | 互补与对齐研究、自适应集套路由，以及人机团队表现 |
| MIT HDSR：人在回路中的数据科学与工程 | HITL 在数据流程中的学术研究、标注质量和反馈闭环 |
| NCBI/PMC：临床 AI 中的 HITL | HITL 监督在医学影像与临床决策支持中的应用 |
常见问题
AI 中的“人在回路中”是什么意思？
人在回路中的 AI 是一种系统设计：将人纳入 AI 的决策或执行周期，用于标注训练数据、评估输出，或在代理操作生效前批准这些操作。其定义性特征是，系统会在明确的检查点等待或纳入人工输入，而不是完全自主地行动。
人在回路中与人在监督回路中有什么区别？
人在回路中（HITL）使用同步审批门，在人做出决定前阻止代理执行；人在监督回路中（HOTL）则允许系统自主行动，同时由人进行监控并可异步干预。HITL 适合高风险、不可逆的操作；HOTL 适合高数量、低风险的输出，因为对这类输出进行实时阻塞审核并不现实。
对于 AI 代理来说，人在回路中是什么意思？
对于能够执行副作用操作（发送邮件、更新记录、处理交易）的 AI 代理，HITL 意味着在这些操作执行前插入审批门。代理会暂停，将拟议操作呈现给人工审核员，只有在收到批准、编辑或拒绝的决定后才会恢复执行，并且代理状态会在整个过程中持续保存。
AI 中的“人在监督回路中”是什么意思？
人在监督回路中是一种监督模式：AI 系统自主运行，由人监控输出或日志，并在出现问题时介入进行纠正或覆盖。与 HITL 不同，它不会阻止执行，因此更适合高吞吐量场景，在这些场景中，同步审核会造成不可接受的延迟。
Deskhero 如何为客服团队实现人在回路中的 AI？
Deskhero 的 AI 会起草回复并运行聊天机器人，但在不确定时会转交人工；除非团队主动启用，否则绝不会自动发送任何内容。每个自动化操作都会被标记并记录，知识库也只会使用客服人员明确批准过的内容，从而让人工始终掌控 AI 可以说什么。