# FDE进化36记-第14记-Human-in-the-loop到底该卡在哪些节点？

> AI能说不能做，企业到底放心到哪一步？

```text
[读者] 正在把客服Agent接入订单、支付、工单系统的FDE
[痛点] AI越权退款、乱改账号，人工审批又拖慢效率
[现在读] 需要在多企业多渠道下建立可配置的HITL矩阵
[读完] 掌握confidence threshold、approval gate、escalation reason和人工反馈的落地方法
```

```text
[旧方案] 所有Agent动作都靠人工最终确认
    |
    v
[新需求] 退款、补偿、账号修改、客户承诺、敏感信息要分级自动化
    |
    v
[冲突] 全自动风险高，全人工效率低，且不同企业规则不同
    |
    v
[后果] 要么频繁资损，要么客服团队被审批淹没
```

我是老李，一个在智能客服平台里来回救火的FDE。我们平台服务多企业、多项目、多语言、多渠道，Agent要连接CRM、订单、支付、物流、工单、知识库。最近一个客户要求在菲律宾、印尼和巴西上线退款Agent，业务方希望自动处理小额退款，风控方却要求所有退款必须人工审批。

这不是简单的“要不要人工”问题。同一套Agent，在A企业可以自动改地址，在B企业必须双人复核；在多语言场景下，模型置信度还不能直接用，因为小语种样本少，置信度整体偏低。

任务是：设计一套可配置的Human-in-the-loop矩阵，让AI仅建议、执行前审批、执行后抽查、异常转人工四种模式能按场景组合，并给退款、补偿、账号修改、客户承诺、敏感信息处理配置阈值、审批门和升级原因。

旧方案为什么失效？如果把所有动作都交给人工，Agent只是一个输入框，ROI无法体现；如果全部自动，一次错误退款就可能变成合规事故。

那么，HITL到底该卡在哪些节点？

要不要为每个场景单独写if-else？

如果选错模式，会带来什么后果？

# 01、故事

某个全球电商客户在大促期间把退款请求量推高了数倍。原来的客服系统里，Agent只能生成退款建议，然后由客服逐条点击确认。业务方发现，客服团队从早到晚都在看退款单，真正需要判断的欺诈和合规case反而被淹没。

我们把这个阶段叫V1：全人工最终确认。它保证了安全，却牺牲了速度。多渠道进来以后，同一个客户可能在App、WhatsApp、邮件里同时发起退款，客服看到的是三张工单，而不是一个客户视图。

变化来自企业策略差异。A企业允许100美元以下退款自动处理，B企业要求任何退款都要组长审批，C企业只允许白名单客户自动退款。原来的if-else审批流写死在代码里，每接一个企业就要改一次发布。

冲突很明确：AI需要执行权，企业需要控制权。HITL不是简单加一个“人工确认”按钮，而是要把动作、风险、置信度、审批门和升级原因组合成矩阵。

> 自动有边界  
> 人工有节点  
> 风险有价码  
> 效率有取舍

# 02、问题

旧方案失效的第一个表现是审批队列无优先级。所有退款请求都排在一个队列里，高金额欺诈风险和低金额改地址混在一起，客服只能按时间顺序处理。结果是低风险动作拖慢高风险动作，SLA全面超时。

第二个表现是Agent提议没有理由。客服看到“建议退款”却不知道模型为什么建议，也不知道订单是否已经退过款。审批人只能重新查一遍订单、支付和物流，审批成本比人工处理还高。

第三个表现是升级原因不统一。同一个“客户要求补偿”的场景，有的客服标为投诉，有的标为服务失误，有的标为欺诈。数据无法回流训练，也无法做管理看板。

我们需要的完成标准是：给定动作类型、金额、客户等级、语言、渠道、订单状态和模型置信度，系统能输出一个决策：仅建议、执行前审批、执行后抽查或异常转人工，并给出approval gate和escalation reason，同时记录人工反馈。

> 队列有轻重  
> 理由有依据  
> 升级有原因  
> 反馈有回流

# 03、原理

HITL的底层原理不是“AI替代人”或“人监督AI”，而是把人的注意力配置到单位风险最高的节点。人的时间有限，因此人工介入不是越多越好，而是越准越好。

反直觉判断：置信度高不代表可以自动执行。一个退款动作即使模型置信度0.99，如果金额超过企业限额，或者订单状态读取不一致，仍然必须审批。置信度只说明模型对意图判断的把握，不说明动作在业务上是否安全。

反直觉判断：置信度低也不一定全部转人工。如果动作是可逆的、低风险的，例如仅建议话术或查询物流，低置信度可以降级为“仅建议”，由Agent给客服提示，而不是直接升级为人工工单。

微软Human-AI Interaction Guidelines强调，AI系统应明确能力边界，支持用户高效纠正，并在不确定或高风险时请求确认。LangGraph官方仓库则提供了human-in-the-loop的工程模式：通过interrupt在节点内暂停执行，借助checkpointer保存状态，等待人工批准、修改或拒绝后继续。两者结合，说明HITL需要状态持久化和可恢复的审批门，而不是弹窗确认。

因此，我们的矩阵需要四个维度：动作类型、风险等级、模型置信度、企业策略。输出四种模式：仅建议、执行前审批、执行后抽查、异常转人工。

> 置信归置信  
> 风险归风险  
> 状态要持久  
> 审批要可恢复

# 04、架构

```text
[输入] 客服请求/Agent提议动作
    |
    v
[模块] 风险分级器 + 模式路由器 + 审批门 + 抽查器 + 升级器
    |
    v
[数据/状态] 企业策略、动作类型、confidence、风险分、审批状态
    |
    v
[处理] 匹配HITL矩阵，决定自动/审批/抽查/转人工
    |
    v
[输出] 执行、待审批、抽样、人工工单、审计日志
```

架构边界：本模块不负责模型训练，也不负责支付通道。它只负责在Agent提议和系统执行之间做决策。企业策略从配置中心读取，订单、支付、CRM状态通过工具层查询。审批状态写入数据库，供LangGraph checkpointer恢复。

收益：同一套Agent可以服务不同企业，退款、补偿、账号修改、客户承诺、敏感信息处理都能用矩阵配置。代价：增加一次决策调用和状态存储，审批门会引入延迟。适用条件：动作可枚举、状态可查询、审批角色可定义。

下面是一个最小矩阵示例：

| 动作 | 默认模式 | confidence阈值 | approval gate | escalation reason |
| --- | --- | --- | --- | --- |
| 退款 | 小额抽查，大额审批 | >=0.90 | 金额<=企业限额且订单可退 | 支付渠道异常、重复退款、风控标记 |
| 补偿 | 仅建议或审批 | >=0.85 | 补偿类型和金额在模板内 | 重复补偿、客户投诉升级、监管地区 |
| 账号修改 | 执行前审批 | 不自动 | 身份验证通过且双人复核 | 手机、邮箱、密码等敏感字段变更 |
| 客户承诺 | 仅建议 | >=0.90 | 承诺内容在话术模板内 | 涉及SLA赔偿、法律责任、定制承诺 |
| 敏感信息处理 | 异常转人工 | 不自动 | 数据访问审批 | 合规地区、个人数据、支付信息 |

注意，阈值不是全局常量。小语种场景需要按语言校准，渠道差异也需要纳入。例如WhatsApp渠道的会话上下文更短，置信度可能偏低，不能直接套用App渠道阈值。

> 动作先分类  
> 风险再分级  
> 门禁卡不可逆  
> 抽查留证据

# 05、实战一次

环境：Python 3.11，依赖langgraph和langchain-core。以下代码先实现一个纯决策器，再说明如何用LangGraph interrupt接入审批门。未在当前环境实测，以下为预期结果。

依赖安装：

```bash
pip install langgraph langchain-core
```

核心实现：

```python
from dataclasses import dataclass
from enum import Enum

class Mode(Enum):
    SUGGEST = 'suggest'
    APPROVE = 'approve'
    SAMPLE = 'sample'
    ESCALATE = 'escalate'

@dataclass
class Action:
    type: str
    amount: float = 0.0
    confidence: float = 0.0
    reversible: bool = True
    sensitive: bool = False
    customer_tier: str = 'normal'

def decide(action: Action, policy: dict) -> dict:
    rules = policy.get(action.type, {})
    threshold = rules.get('confidence', 0.8)
    limit = rules.get('amount_limit', 0)
    if action.sensitive:
        return {'mode': Mode.ESCALATE, 'reason': 'sensitive_data_requires_human'}
    if action.type == 'refund':
        if action.amount <= limit and action.confidence >= threshold:
            return {'mode': Mode.SAMPLE, 'reason': 'low_amount_auto_sample'}
        return {'mode': Mode.APPROVE, 'reason': 'amount_or_confidence_gate'}
    if action.type == 'account_change':
        return {'mode': Mode.APPROVE, 'reason': 'identity_sensitive_change'}
    if action.type == 'promise':
        return {'mode': Mode.SUGGEST, 'reason': 'customer_commitment_template_only'}
    return {'mode': Mode.ESCALATE, 'reason': 'unknown_action_type'}

def build_policy():
    return {
        'refund': {'confidence': 0.90, 'amount_limit': 100},
        'compensation': {'confidence': 0.85, 'amount_limit': 50},
        'account_change': {'confidence': 1.0, 'amount_limit': 0},
        'promise': {'confidence': 0.90, 'amount_limit': 0},
    }

if __name__ == '__main__':
    policy = build_policy()
    action = Action(type='refund', amount=80, confidence=0.93)
    result = decide(action, policy)
    print(result)
```

预期输出：

```bash
{'mode': Mode.SAMPLE, 'reason': 'low_amount_auto_sample'}
```

如果接入LangGraph，可以把decide放在一个节点里，当结果为APPROVE或ESCALATE时调用interrupt，把审批所需上下文作为payload传入，checkpointer保存状态，人工通过API批准后再恢复图执行。

验证方式：修改amount为180或confidence为0.80，预期结果变为APPROVE。修改type为account_change，预期结果变为APPROVE。修改sensitive为True，预期结果变为ESCALATE。所有决策必须写入审计日志。

> 先跑通决策  
> 再接入审批  
> 再验证恢复  
> 再记录反馈

# 06、排查

现象一：大促期间出现同一订单重复退款。怀疑是Agent没有识别订单已退款。检查支付日志和Agent工具调用记录，发现两个渠道的会话几乎同时触发退款提议。

证据：订单状态查询存在延迟，两个提议都读到“未退款”状态。根因是缺少幂等键和状态锁，而不是模型置信度不足。

**错误尝试：** 直接把退款confidence阈值从0.90提高到0.99。为什么错误？因为重复退款是状态一致性问题，不是模型判断问题。提高阈值只会减少自动退款量，不能阻止两个高置信度提议同时执行。

修复：在approval gate之前增加幂等键校验和订单状态强一致检查；对同一订单建立短期锁；退款执行后立即写入幂等记录。

现象二：印尼语退款请求几乎全部转人工。怀疑是小语种模型能力差。检查置信度分布和语言标签，发现印尼语请求的confidence整体比英语低0.15左右。

证据：小语种训练样本少，模型对印尼语退款意图的置信度天然偏低。根因是全局阈值没有按语言校准，导致过度升级。

修复：按语言和渠道维护阈值偏移量；低置信度但低风险的动作降级为仅建议；高风险动作仍走审批门。

> 先查状态锁  
> 再查语言差  
> 莫怪置信低  
> 根因在配置

# 07、优化

基于第06章证据，V2做三件事。

第一，引入动作风险分。风险分由动作类型、金额、可逆性、敏感字段和企业策略共同计算。置信度只作为一个输入，不单独决定自动化。

第二，增加幂等键和状态校验。所有写操作在执行前检查订单状态、支付状态和幂等记录。审批门卡在不可逆动作之前。

第三，按语言和渠道校准阈值。小语种使用偏移量，低风险查询和话术建议允许仅建议模式，避免无效转人工。

修改后的决策流程：先查敏感动作，再查幂等和状态，再计算风险分，再匹配企业策略，最后输出模式和escalation reason。验证时用印尼语退款请求和高风险补偿请求分别测试，预期前者进入仅建议或抽查，后者进入审批或转人工。

> 风险算综合  
> 状态做前置  
> 阈值按语言  
> 反馈再回流

# 08、演进

```text
[同一输入] 退款请求
    |
    +--[V1] 全人工审批 / 慢但保守
    |
    +--[V2] 小额自动抽样+大额审批 / 快但有抽样风险
    |
[Trade-off]
得到：效率与风险平衡；失去：绝对安全；适用边界：企业策略可配置、订单状态强一致
```

正确性：V1不会自动退款，正确性依赖人工；V2对低风险动作自动抽样，需要幂等和状态校验保证正确性。稳定性：V1稳定但队列会积压；V2增加了状态存储和锁，复杂度上升。成本：V1人力成本高；V2需要审批系统、审计日志和抽样团队。适用范围：V1适用于强监管、高频欺诈场景；V2适用于有企业策略、订单状态可强一致的场景。遗留问题：多语言阈值偏移量需要持续校准，抽样比例需要根据人工反馈调整。

> 旧版重安全  
> 新版重平衡  
> 取舍看边界  
> 遗留靠反馈

# 09、洞见

## 9.1 HITL不是开关，而是矩阵

反直觉判断：把AI全部交给人审批，并不会降低风险，只会把风险转移到审批人的疲劳上。审批人面对大量低风险请求时，会形成点击通过的惯性，真正高风险请求反而被忽略。矩阵的价值是让人的注意力配置到不可逆、高金额、敏感信息节点。

## 9.2 置信度不是风险本身

反直觉判断：置信度越高，越要检查动作可逆性。退款、账号修改、客户承诺这些动作一旦执行，撤销成本很高。因此系统不能只问“模型有多确定”，还要问“这个动作做错了能不能低成本恢复”。

## 9.3 审批门要卡在不可逆动作之前

执行前审批不是形式，而是状态机的一道门。它必须能访问订单、支付、CRM和幂等记录，能返回批准、修改或拒绝，并把结果写入可恢复的checkpoint。LangGraph的interrupt和checkpointer提供了这种恢复能力，但企业策略和审计仍要自己实现。

## 9.4 抽查不是弱化控制，而是抽样审计

执行后抽查适合低风险、高频、可逆的动作。它把100%人工审批变成按比例抽样，前提是有完整审计日志和回滚能力。人工反馈要回写到矩阵，调整阈值、抽样比例和升级原因。

> 矩阵配注意  
> 可逆定门禁  
> 抽查靠审计  
> 反馈调阈值

# 10、系统落地

原来我们只有“全人工确认”和“全自动”两个极端，Agent在每个企业上线都要重写审批流。本篇新增了HITL矩阵：按动作类型、风险分、置信度和企业策略输出四种模式，并为退款、补偿、账号修改、客户承诺、敏感信息处理配置了confidence threshold、approval gate和escalation reason。

现在能做什么？同一套全球客服平台可以服务不同企业：A企业小额退款自动抽样，B企业大额退款审批，C企业账号修改双人复核。人工反馈可以回写到矩阵，用于调整阈值和抽样比例。

还缺什么？缺跨语言阈值自动校准，缺审批人疲劳监控，缺抽样审计的统计显著性设计，缺与LangGraph checkpointer深度集成的审批API。

下一步演进：把HITL矩阵配置化、版本化，接入A/B测试和人工反馈闭环，让阈值调整从手工配置走向数据驱动。

> 旧极端要拆  
> 新矩阵要配  
> 能执行能审批  
> 缺校准缺闭环

# 11、小结

```text
Q1 → HITL卡在哪些节点？
Q2 → 如何为不同动作配置阈值和审批门？
Q3 → 怎么避免全自动与全人工的极端？
状态 → 全球客服HITL矩阵V1可运行
```

Q1的答案是：卡在不可逆、高金额、敏感信息、客户承诺和跨企业策略差异节点。Q2的答案是：按动作类型配置模式、confidence阈值、approval gate和escalation reason，并让企业策略可覆盖。Q3的答案是：用四种模式组合，低风险仅建议或抽查，高风险审批或转人工，而不是二选一。

> 问题变矩阵  
> 阈值变策略  
> 极端变组合  
> 能力可运行

# 12、作业

## 12.1 理解题：为什么置信度高仍然需要审批门？

参考答案：置信度只代表模型对意图判断的把握，不代表动作在业务上安全。退款、账号修改等动作涉及资金、身份和合规风险，必须结合金额、可逆性、订单状态和企业策略决定是否审批。

## 12.2 实战题：为“补偿”动作设计一个HITL配置。

参考答案：补偿默认仅建议或审批；confidence阈值0.85；approval gate要求补偿类型和金额在模板内；escalation reason包括重复补偿、客户投诉升级、监管地区。执行后按比例抽查，人工反馈回写。

## 12.3 排障题：同一订单重复退款，先查什么？

参考答案：先查幂等键和订单状态锁，再查支付日志和工具调用记录。不要先提高置信度阈值，因为重复退款属于状态一致性问题。

## 12.4 架构判断题：抽查模式能否替代审批门？

参考答案：不能。抽查适用于低风险、高频、可逆动作，依赖审计日志和回滚能力。审批门用于不可逆、高金额、敏感信息动作。两者是互补关系，不是替代关系。

> 理解看边界  
> 实战配矩阵  
> 排障查状态  
> 架构分互补

# 13、思考

回到核心冲突：AI需要执行权，企业需要控制权。HITL矩阵不是给每个动作加人工，而是把人工放到单位风险最高的节点。退款、补偿、账号修改、客户承诺、敏感信息处理需要不同的confidence threshold、approval gate和escalation reason。

可复用的工程判断是：先定义动作可逆性，再定义风险分，再定义企业策略，最后决定自动化模式。置信度只是输入，不是结论。人工反馈必须回流到矩阵，否则阈值会僵化，升级原因会失真。

> 执行权有界  
> 控制权有门  
> 风险配人眼  
> 反馈调矩阵

我是老李，一个在智能客服平台里来回救火的FDE。我们平台服务多企业、多项目、多语言、多渠道，Agent要连接CRM、订单、支付、物流、工单、知识库。最近一个客户要求在菲律宾、印尼和巴西上线退款Agent，业务方希望自动处理小额退款，风控方却要求所有退款必须人工审批。

FDE进化36记-第14记-Human-in-the-loop到底该卡在哪些节点？

从全球客服平台出发，拆解AI仅建议、执行前审批、执行后抽查、异常转人工四种模式，并给出退款、补偿、账号修改等场景的阈值与审批矩阵。

架构师

人工智能

架构设计

后端

设计一套可配置HITL矩阵，按动作类型、风险分、置信度和企业策略输出仅建议、审批、抽查、转人工四种模式，为退款等场景配置阈值和审批门，实现效率与风险平衡。

2026上云采购 | AI焕新·智启新局

腾讯云BI特惠9.9元起！


lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

FDE进化36记-第14记-Human-in-the-loop到底该卡在哪些节点？-腾讯云开发者社区-腾讯云

FDE进化36记-第14记-Human-in-the-loop到底该卡在哪些节点？

FDE进化36记-第14记-Human-in-the-loop到底该卡在哪些节点？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐