Agent Product 101｜04｜Human-in-the-Loop：把人放回流程

核心结论

Human-in-the-Loop 不是“模型不够强，所以让人补一下”。

在 Agent Product 里，Human-in-the-Loop 应该被看成一种产品机制：当任务风险、信息缺口、责任归属或组织规则要求人类参与时，系统把人类决策设计成明确、可追踪、可恢复的流程节点。

这句话有三个重点：

• 人类不是临时插进来的旁观者，而是流程的一部分。
• 人类参与不只是“确认一下”，也包括补充信息、纠正方向、审批动作、接管执行、升级给更合适的人、验收结果。
• 人类参与本身需要产品化：谁参与、何时参与、看到什么、能做什么、决策如何记录、Agent 如何继续。

如果没有 Human-in-the-Loop，Agent 产品容易走向两个极端：过度自动化，Agent 什么都敢做，用户最后才发现结果已经影响外部系统；过度打断，Agent 每一步都问，用户变成脚本执行器，自动化价值被消耗掉。

成熟的 Agent Product 不是在人和 Agent 之间二选一，而是设计一条清晰协作路径：低风险自动执行，中风险请求 review，高风险等待批准，异常状态升级或接管，最终结果由人类或制度验收。

Human-in-the-Loop 和 Control Plane 的区别

上一篇讲 Control Plane：Plan、Preview、Diff、Approval、Takeover、Rollback。这些是控制点。

Human-in-the-Loop 关注的是：这些控制点背后的人类如何参与任务。

例如 Approval 是一个控制点，但 Human-in-the-Loop 要继续回答：谁有权批准？批准人需要看到哪些信息？批准是否有时限？拒绝后 Agent 怎么继续？批准记录是否进入审计？多人意见冲突时谁说了算？

Takeover 也是一个控制点，但 Human-in-the-Loop 要继续回答：用户接管时能看到 Agent 已经做了什么吗？接管后 Agent 是暂停、旁观，还是继续辅助？人类完成动作后，Agent 如何恢复上下文？接管期间产生的外部状态是否被记录？

所以，Control Plane 是按钮、状态、界面和策略；Human-in-the-Loop 是人类角色、决策、责任和流程。

从真实产品看 Human-in-the-Loop

真实 Agent 产品里的 Human-in-the-Loop 形态差异很大。它可能是个人确认、开发者 review、团队审批、客服接管、管理员审核，也可能是企业流程里的责任节点。

ChatGPT Agent：敏感动作前的人类确认

Personal Agent 最典型的人类参与，是高风险动作前的确认和接管。

当 Agent 浏览网页、操作应用、提交表单、发送消息、访问敏感信息或准备执行不可逆动作时，用户需要明确机会决定是否继续。这里的人类参与不是因为 Agent 完全不会做，而是因为责任不能完全交给模型。

登录、支付、提交申请、发送邮件、修改账号设置，这些动作一旦发生，就可能影响真实账户、真实资金、真实关系或真实数据。

GitHub Copilot coding agent：Issue、PR 和 Review

Coding Agent 的 Human-in-the-Loop 通常发生在工程制度中。典型路径是 issue → branch → draft PR → review → merge。

这里的人类不是在聊天框里临时看一眼，而是在已有开发流程中审查 Agent 的工作：Issue 定义任务，branch 隔离修改，PR 暴露 diff 和讨论区，CI 给出测试结果，reviewer 做语义审查，merge 决定是否进入主线。

Human-in-the-Loop 在这里不是单个按钮，而是一套协作制度。Coding Agent 的成熟度不取决于它能不能直接 merge，而取决于它能不能把结果交给人类和 CI 共同审查。

Replit、Lovable、v0：Preview 和用户选择

AI App Builder 的人类参与通常发生在 preview、visual edit、plan approval 和 publish 之间。

用户不一定能 review 代码 diff，但可以 review preview；不一定能理解数据库结构，但可以指出应用行为不对；不一定能写 CSS，但可以通过 visual edits 纠正布局。

这说明 Human-in-the-Loop 必须匹配用户角色：给开发者 diff，给产品构建者 preview，给业务用户 record draft，给管理员 policy review。

Slack：多人协作中的人类节点

Slack 里的 Agent 展示了多人协作场景。Agent 可能在 channel 或 thread 里被召唤，读取多人讨论，生成总结，提出下一步，触发 workflow，或请求某个人批准。

这里的人类参与有几个特点：任务上下文天然多人共享；纠错可能来自不同人；审批人可能不是发起人；结果需要写回 thread、Canvas、workflow 或外部系统；Agent 的可见性本身就是产品设计问题。

例如 incident thread 里，Agent 可以整理时间线，但最终行动项可能需要 incident commander 确认。销售 thread 里，Agent 可以生成 CRM 更新草稿，但是否写回 CRM 可能需要 account owner 批准。

Copilot Studio 和 Agentforce：企业流程里的责任节点

企业 Agent 里的 Human-in-the-Loop 更接近业务流程治理。人类参与可能发生在 Agent 创建和发布前、action 启用前、访问某类数据前、执行高风险业务动作前、客服对话升级给真人前、销售或支持记录写回前、异常事件告警后。

企业环境里的问题不是“是否有人参与”，而是参与者是否有角色、权限和责任。一个普通员工不应该批准所有数据访问；客服 Agent 不应该在没有策略的情况下承诺退款；销售 Agent 不应该擅自修改关键 opportunity 阶段。

企业 Agent 的 Human-in-the-Loop 必须和身份、权限、审批链、审计日志和责任归属连接。

Human-in-the-Loop 的六种模式

可以把人类参与分成六种常见模式。

Clarify：让模糊任务变清楚

Clarify 是任务不清楚时的人类输入。Agent 不应该在关键约束缺失时盲目猜测。好的澄清问题应该具体、少量、可回答。不要问“你想让我怎么做？”，而要问“这个报告面向销售团队还是产品团队？时间范围是一周还是一个月？”

Review：让人检查语义和风险

Review 是对中间结果或最终结果的检查，适合可逆或可修改的任务阶段。例如 app preview、code diff、draft PR、email draft、CRM update draft、workflow change summary。Review 的目标不是让人类重新做一遍，而是检查关键风险和语义正确性。

Approve：让人承担高风险授权

Approve 是高风险动作前的授权。它比 review 更强，因为批准后系统可能执行外部动作：发送消息、发布应用、合并 PR、更新客户记录、发起退款、启用企业 connector、执行不可逆 API 调用。

Approval 需要清晰展示动作、影响对象、风险、可撤销性和审计记录。

Correct：把纠错当正常路径

Correct 是人类指出 Agent 偏离方向。纠错可能包括改变目标、缩小范围、选择另一种方案、修改生成内容、标记错误数据源、要求重试某一步。

好的纠错设计会让 Agent 把反馈转化为任务状态更新，而不是仅仅把用户新消息追加到聊天历史里。

Escalate：把任务交给更合适的人

Escalate 常见于权限不足、风险过高、用户无法判断、需要经理批准、需要法务/安全/财务/专业团队介入、客服 Agent 无法处理复杂例外。

升级给人时，不能只说“Agent 失败了”。应该带上任务目标、已完成步骤、关键证据、失败原因、建议选项和待决问题。

Takeover：人类直接接管执行

Takeover 适合浏览器操作、客服对话、事故处理、复杂调试、敏感表单或不可逆流程。接管后，Agent 不一定退出，它可以变成旁观记录者、建议助手、摘要生成器或恢复执行的协作者。

关键是接管边界清楚：谁现在负责执行，Agent 是否还会动作，何时恢复自动执行。

HITL 不是所有步骤都问人

Human-in-the-Loop 最常见的误区，是把它理解成“每一步都要用户确认”。这会破坏 Agent 产品的价值。

真正的设计原则是：在需要人类判断、授权或责任承担的地方让人介入，在可自动、可撤销、低风险的地方让 Agent 执行。

产品设计原则

明确人类角色

不要只写“等待用户确认”。要明确是谁：发起人、对象 owner、reviewer、管理员、经理、安全团队、客服主管、account owner。不同角色看到的信息、拥有的权限、承担的责任都不同。

给人类足够上下文

人类参与时，应该看到任务目标、Agent 当前计划、已完成步骤、关键证据、影响对象、风险等级、可选决策、执行后是否可撤销。没有上下文的确认按钮，只是在转移责任。

让决策可恢复

人类选择 approve、reject、correct、escalate 后，Agent 应该知道如何继续。这需要把人类决策写入任务状态，而不是只保存在聊天历史里。

避免打断疲劳

如果每个低风险动作都需要确认，用户会机械地点通过。好的产品应该减少无意义打断，把用户注意力留给真正需要判断的节点。

记录责任和审计

团队和企业环境里，Human-in-the-Loop 必须留下记录：谁批准了什么、基于什么信息、何时批准、执行结果是什么。这些都应该进入 trace 和 audit log。

常见误区

把人类当兜底异常处理器

如果只有 Agent 失败后才找人，用户体验会很差。很多人类参与应该提前设计：任务澄清、计划确认、预览审查、高风险批准。

只设计单人场景

很多真实任务不是一个人完成的。Issue、PR、Slack thread、CRM case、审批流程里都有多人角色。Agent 产品需要设计多人决策，而不是假设所有反馈都来自同一个用户。

让用户承担模型不确定性

不要把模型不确定性简单转化成“你确认吗？”产品应该解释风险、提供证据、给出选项，让用户做有信息的判断。

不记录人类决策

如果人类批准只留在聊天文本里，后续调试、评估、审计都会很困难。Human-in-the-Loop 的决策应该成为任务状态的一部分。

PM 检查清单

• 哪些节点需要 Clarify、Review、Approve、Correct、Escalate、Takeover？
• 每个节点的人类角色是谁？发起人、owner、reviewer、admin、specialist 是否区分？
• 人类决策前，是否能看到目标、计划、证据、影响对象和风险？
• 批准或拒绝后，Agent 是否有明确恢复路径？
• 低风险动作是否避免过度打断？高风险动作是否强制人类授权？
• 多人场景下，谁有最终决定权？冲突如何处理？
• 人类决策是否进入任务状态、trace 和 audit log？
• Escalation 是否携带完整上下文，而不是只抛出“失败”？

小结

Human-in-the-Loop 是 Agent Product 的协作层。它解决的不是“模型不够强怎么办”，而是“真实任务中人类判断、授权、责任和协作如何进入 Agent 执行过程”。

成熟 Agent 产品会把人类参与设计成清晰流程节点：Clarify、Review、Approve、Correct、Escalate、Takeover。这些节点让 Agent 能在低风险区域自动推进，在高风险区域请求人类判断，在异常状态下升级或接管，并在整个过程中保留可追踪的责任记录。

如果 Task Surface 定义了用户能交给 Agent 什么任务，Control Plane 定义了用户如何控制 Agent，那么 Human-in-the-Loop 定义的就是：人类在什么时候、以什么角色、基于什么信息、做出什么决策。

下一篇会进入 Permission Model：Agent 能访问什么、能执行什么、谁授权、谁审计，以及为什么权限不能只写在 prompt 里。

参考资料

• OpenAI: Introducing ChatGPT agent
• GitHub Docs: About GitHub Copilot cloud agent
• Replit Agent Docs
• Replit: Checkpoints and Rollbacks
• Vercel v0 Docs
• Lovable Docs
• Slack Developer Docs: Building agents for Slack
• Microsoft Copilot Studio Overview
• Salesforce Agentforce