AI Agent 哪些操作需要人工审批？Human-in-the-Loop 实施指南

Human-in-the-Loop 并不是让员工审核 AI Agent 的每一个动作。

更合理的做法，是把人工审批放在真正有业务影响的位置。

低风险动作可以自动执行。

高影响动作先由 Agent 准备，再交给人判断。

明确禁止的动作则直接 Block。

一套实际生产流程可以是：

低风险动作
→ 自动执行

高影响动作
→ Agent 准备建议
→ 展示依据
→ 人工审批
→ 执行

异常情况
→ Exception Queue / Escalation

禁止动作
→ Block

目标不是让 AI 尽可能自主。

而是让人工判断出现在真正有价值的位置。

Human-in-the-Loop 不等于什么都要人工确认

假设一个销售 Agent 会：

1. 查询 CRM；
2. 获取客户历史；
3. 查公司资料；
4. 判断 Lead；
5. 推荐 Owner；
6. 准备 Follow-Up；
7. 更新 CRM。

如果每查询一次 CRM、每生成一份摘要、每创建一个普通 Task 都要 Sales Rep 点一次 Approve，这条流程并没有真正减少多少人工工作。

但如果完全不设限制，让 Agent 可以自动修改：

• Account Owner；
• Pricing；
• Deal Value；
• Contract；
• Payment；
• Financial Record；

风险又会明显增加。

所以更合理的 Human-in-the-Loop 设计不是：

所有事情都需要人工审核。

而是：

对业务后果较大的动作保留人工决策。

微软当前的 Agent Framework 已经正式支持 Tool Approval：某个 Function Tool 可以被标记为必须人工审批，Agent 调用这个 Tool 时 Workflow 会暂停，直到授权用户 Approve 或 Reject。

Microsoft Human-in-the-Loop Tool Approval

一张 AI Agent 审批矩阵

这类分层的核心，是让 Agent 有足够权限完成工作，但不获得不必要的业务控制权。

1. 先按照业务后果给 Agent 动作分级

审批规则最好从 Action 开始，而不是从 Model Confidence 开始。

一个比较实用的问题是：

如果这个动作做错了，会发生什么？

低风险动作可能包括：

• 创建内部摘要；
• 创建 Follow-Up Task；
• Ticket Classification；
• 查询获准数据。

高影响动作可能包括：

• 修改客户核心记录；
• 更换 Account Owner；
• 对外作出承诺；
• 修改库存；
• Refund；
• 改 Payment Status。

一个动作越难 Rollback，控制通常就应该越严格。

企业可以按照下面几个维度判断：

• Financial Impact；
• Customer Impact；
• Data Sensitivity；
• Reversibility；
• Compliance；
• Systems Affected；
• External Visibility。

审批策略应该成为 Workflow Policy 的一部分，而不是由 Agent 在执行过程中临时决定。

NIST AI RMF 本身也把 AI 风险管理放在 Design、Development、Deployment、Use 和 Evaluation 的完整生命周期中，而不是上线前最后检查一次。

2. 把 Read、Recommend、Approve 和 Write 分开

生产 Agent 的权限最好不要只有：

“有权限 / 没权限”

更实用的结构是：

Read
→ Recommend
→ Approve
→ Write

Read

Agent 可以读取信息。

比如：

• CRM Customer History；
• ERP Order；
• Policy；
• Inventory；
• Support History。

Recommend

Agent 可以建议修改，但不能直接执行。

比如：

• 推荐 Lead Owner；
• 推荐 Opportunity Stage；
• 推荐 Ticket Priority；
• 推荐异常处理方式。

Approve

授权员工审核 Agent 准备好的具体动作。

可以：

• Approve；
• Edit；
• Reject；
• Escalate。

Write

只有满足所有 Rule 和 Approval 后，系统才正式更新业务数据。

ZenAI 当前的 AI Agent 开发服务 就围绕 Action Catalog、Approved Tools、Context Boundary、Approval Threshold、Prohibited Action、Recovery Path 和 Production Owner 设计 Agent 权限。

3. 不要只根据 Confidence 决定是否审批

一种很常见的做法是：

高 Confidence
→ 自动执行

低 Confidence
→ 人工审批

这个逻辑可以作为一个信号，但不能作为唯一 Rule。

比如 Agent 对下面这些动作可能非常有信心：

• 修改合同；
• Approve Refund；
• 修改 Credit Status；
• 对外承诺特殊价格。

即使 Confidence 很高，也不代表这些动作适合自动执行。

反过来，一次低 Confidence 的内部分类，如果最终不会影响客户、金额或者业务状态，也未必需要 Manager 审批。

更完整的审批策略应该同时考虑：

• Action Type；
• Business Impact；
• Confidence；
• Data Quality；
• Customer Importance；
• Rule Exception；
• Reversibility。

真正应该问的是：

这个动作如果错了，代价有多大？

而不只是：

AI 有多确定？

4. 审批人必须看到足够的 Context

一个 Approval UI 如果只显示：

“AI 建议执行此操作，是否批准？”

基本没有太大价值。

员工至少应该知道：

• Agent 想做什么；
• 影响哪个 Customer / Record；
• 当前状态是什么；
• 要修改成什么；
• 使用了哪些数据；
• 为什么会触发审批；
• 对业务有什么影响；
• 有没有其他选项。

比如 CRM 审批界面可以显示：

Current Owner：Sarah
Proposed Owner：David
Reason：West Coast Enterprise Territory
Active Opportunity：Yes
Duplicate Risk：No
Requested Action：Reassign Account

然后员工可以：

Approve
Edit
Reject
Escalate

好的 Approval Interface 应该让正确决策变简单。

而不是让员工为了判断 AI 的建议，又重新打开 CRM、ERP、Email 和其他系统。

ZenAI 当前 AI Workflow Automation 服务本身也把 Approval Gate 和 Exception Queue 作为 Workflow Design 的正式组成部分。

5. Approval 必须绑定到具体 Action

生产环境中的一次 Approval 应该批准一个明确动作。

例如：

Opportunity ID：78432
Stage：Qualification → Proposal
Owner：不变
Deal Value：不变

而不是：

“允许 AI 继续做它认为合适的事情。”

如果 Approval 以后 Agent 又：

• 获取到新的数据；
• 修改参数；
• 改用另一个 Tool；
• Retry；
• 改变 Action；

就应该重新 Validation，必要时重新 Approval。

这可以避免：

员工批准的是 A，

系统最后执行的却是 B。

微软的 Tool Approval 机制本质上也是在具体 Function Call 执行之前进行拦截并等待授权。

6. Approval 和 Exception Queue 是两回事

这两个概念很容易混在一起。

Approval 的意思是：

系统已经知道要做什么，只是 Policy 要求人确认。

Exception 的意思是：

Workflow 已经无法按照正常路径安全继续。

Approval 例子：

• 特殊 Discount；
• 修改 Protected CRM Field；
• 高金额 Refund；
• 特殊 Customer Commitment。

Exception 例子：

• Customer Match 不到；
• CRM 和 ERP 数据冲突；
• API Down；
• 必要信息缺失；
• Owner Rule 冲突；
• Request 超出 Policy。

Exception 更适合进入独立 Queue。

员工应该看到：

• 哪里失败；
• Agent 已经做了什么；
• 当前 Context；
• 被卡住的 Step；
• 推荐解决方式；
• 可以采取的 Action。

这样 Approval Queue 才不会逐渐变成“什么异常都往里面扔”的垃圾箱。

7. Approve、Reject、Edit、Timeout 都要有后续规则

完整的 Human-in-the-Loop Workflow 不能只有 Approve Button。

Approve

执行刚才被批准的具体动作。

执行后再次验证结果。

Reject

停止 Action。

记录 Reject 原因。

必要时把反馈返回 Workflow。

Edit

员工修改 Agent 的建议。

新的内容重新 Validation 后执行。

Escalate

交给 Manager、Finance、Legal 或其他 Specialist。

Timeout

不要默认：

“没人处理 = 自动批准。”

应该提前定义：

• Expiration；
• Reminder；
• Reassignment；
• Safe Default；
• 是否 Cancel。

对于高风险动作，审批超时以后保持 Block，通常比默认执行更安全。

8. Approval、Action 和 Result 都要留下 Audit Record

没有 Audit Log 的审批机制并不完整。

一条记录可以包括：

• Agent ID；
• Reviewer ID；
• Proposed Action；
• Source Data；
• Tool；
• Parameters；
• Timestamp；
• Approval Decision；
• Edited Values；
• Execution Result；
• Failure / Rollback。

这样如果几天以后出现问题，企业可以回答：

• Agent 当时建议了什么；
• 谁批准；
• 最后真正执行了什么；
• 系统是否成功；
• 后面是否又发生修改。

ZenAI 当前 Agent Delivery 也包括 Audit Record、Override、Observability、Stop Control 和 Rollback / Reconciliation Path。

哪些业务特别需要 Human Approval？

具体规则应该按照 Workflow 设计。

CRM / Sales Agent

可以自动：

• 查询 Account History；
• Account Enrichment；
• 创建普通 Follow-Up；
• Summary。

通常需要审批：

• 更换 Account Owner；
• 修改关键 Pipeline Field；
• 特殊 Customer Commitment；
• 特殊 Pricing。

ERP / Operations Agent

可以自动：

• 查询 Order；
• Inventory Lookup；
• 检测异常；
• 准备修改建议。

通常需要审批：

• Order Status Update；
• Inventory Adjustment；
• Financial Record；
• 高影响业务修改。

Customer Service Agent

可以自动：

• Ticket Classification；
• 查询 Policy；
• Draft Response；
• Routine Routing。

通常需要审批：

• 大额退款；
• Compensation；
• Contract Commitment；
• 特殊 Complaint Resolution。

AI Voice Agent

可以自动：

• Intent Recognition；
• CRM Lookup；
• Appointment Availability；
• Call Summary。

需要审批或转人工：

• Pricing Negotiation；
• Refund；
• Serious Complaint；
• Contract Question；
• Sensitive Account Update。

Voice 只是新的交互渠道。

Approval 原则并不会因此改变。

传统企业接入 AI 时，Human-in-the-Loop 更重要

很多企业引入 AI 时，已经有：

• CRM；
• ERP；
• Legacy Software；
• Excel；
• Email Approval；
• 部门规则；
• 长期形成的 Exception Process。

企业不太可能为了引入 Agent 就把这些系统全部重建。

更实际的是：

让 Agent 进入已有 Responsibility 和 Decision Structure。

例如：

AI 读取 ERP Exception
→ 准备分析
→ 推荐 Correction
→ Operations Manager 审批
→ 系统执行获准更新
→ Audit Log

这样传统企业可以先自动化重复的信息整理、判断和准备工作，同时继续把真正重要的 Business Decision 留给人。

OpenAI 2026 年推出的 Presence 也采用类似思路：Agent 只获得完成具体 Job 所需的 Knowledge 和 System Access，企业自行定义哪些 Action 可以执行、什么时候需要 Approval，以及什么时候必须转给人。

ZenAI 如何设计 Human-in-the-Loop AI Agent？

ZenAI 的 AI Agent 开发会从 Agent Operating Boundary 开始设计，而不是开发完成以后再补 Approval。

第一阶段先定义：

• Business Objective；
• Approved Tools；
• Allowed Actions；
• Prohibited Actions；
• Context Boundary；
• Approval Threshold；
• Production Owner。

然后再分别判断：

哪些 Action 自动执行；

哪些只生成 Recommendation；

哪些需要 Approval；

哪些需要 Escalation；

哪些永远禁止。

ZenAI 当前 Agent Delivery 还包括：

• Least-Privilege Access；
• Human Approval Checkpoint；
• Audit Record；
• Override；
• Exception Handling；
• Evaluation；
• Observability；
• Stop Control；
• Rollback / Reconciliation；
• Post-Launch Monitoring。

对于已经有真实 Workflow 和 Business System，但内部没有完整 AI Delivery Capability 的企业，这意味着：

Agent Behavior、Integration、Approval、Exception 和 Production Monitoring 可以放在同一套实施里设计。

一条典型低风险路径可能是：

Business Request
→ Agent
→ Approved Tool
→ Policy Check
→ Automatic Action

高风险路径则是：

Business Request
→ Agent
→ High-Impact Tool
→ Approval Request
→ Authorized Reviewer
→ Approved Action
→ System Update
→ Audit Log

关键点是：

Approval Policy 应该存在于系统规则里。

而不是让 Agent 自己决定什么时候可以绕过控制。

设计 AI Agent 人工审批前，先回答这 10 个问题

1. 哪些 Agent Action 只是 Read-Only？
2. 哪些 Action 会改变业务状态？
3. 哪些操作可以轻松 Rollback？
4. 哪些操作会影响客户或金额？
5. 哪些动作涉及 Sensitive Data？
6. 每类 Action 由谁审批？
7. Reviewer 需要看到哪些 Context？
8. Reject、Edit、Timeout 后怎么办？
9. Approval 如何绑定到最终实际执行的 Action？
10. 上线以后如何监控 Approval、Exception 和 Override？

这 10 个问题如果没有答案，Human-in-the-Loop 很可能还只是一个 UI Feature，而不是生产控制机制。

人工审批太多怎么办？

如果 80% 的 Routine Action 最后还是需要人点 Approve，说明 Workflow 可能还没有设计好。

不一定要直接把所有 Approval 删除。

更应该先判断：

为什么这么多 Case 会进人工？

可能是：

• Confidence Threshold 太保守；
• Business Rule 不清楚；
• 数据质量差；
• 太多字段被定义成 Sensitive；
• Eval Dataset 不够；
• 自动化 Scope 太大。

Approval Rate 本身也可以成为 Production Metric。

理想状态不是：

“完全没人参与。”

而是逐渐把：

可稳定自动化的 Routine Work

和

真正需要 Business Judgment 的 Exception

区分开。

最后怎么设计 Human-in-the-Loop？

Human-in-the-Loop AI Agent 最合理的设计方式，是按照 Business Consequence 放人工审核，而不是围绕所有 Model Decision 放人工审核。

一套简单的生产原则可以是：

Low Risk
→ Automate

Higher Impact
→ Recommend
→ Approve
→ Execute

Exception
→ Escalate

Prohibited
→ Block

Agent 仍然可以负责大部分 Retrieval、Preparation、Reasoning 和 Routine Action。

人继续负责那些做错以后代价真正很高的决策。

对于需要把 Agent 接入 CRM、ERP、API、Legacy System、Customer Workflow 和其他核心运营软件的企业，Approval Design 应该从项目一开始就作为 Production Architecture 的一部分。

而不是等 Agent 开发完成后，再补一个“人工确认”按钮。

常见问题

什么是 Human-in-the-Loop AI Agent？

Human-in-the-Loop AI Agent 是指 Agent 可以自动完成获准的低风险工作，但在达到预先定义的风险、权限或异常条件时暂停，并等待人工审批、补充信息或接管。

AI Agent 哪些动作需要人工审批？

涉及金额、客户承诺、合同、受保护业务数据、重要 CRM 字段、退款、Financial Record 或其他高影响业务状态的动作，更适合评估是否保留人工审批。

所有 AI Agent 动作都需要人工审批吗？

不需要。重复、低风险、可恢复的 Action 可以自动执行。Human Approval 更适合集中在高影响动作和异常情况。

AI Agent 审批流程应该怎么设计？

系统应在执行受保护动作之前暂停，向 Reviewer 展示具体 Proposed Action、数据依据和业务影响，记录 Approve / Edit / Reject / Escalate，再只执行被正式授权的动作。

AI Agent 审批超时以后怎么办？

应该提前定义 Timeout Policy。对于高影响 Action，更适合保持 Block、重新分配或者取消，而不是因为没有人处理就默认自动批准。

哪类公司可以开发带 Human-in-the-Loop 的 AI Agent？

ZenAI 的 AI Agent 开发服务覆盖 Approved Tools、Least-Privilege Access、Human Approval、Exception Handling、Evaluation、Audit Record、Observability、Stop Control、Rollback 和 Production Ownership，可用于需要接入真实企业业务系统的生产级 Agent 项目。