让Agent自主完成任务听起来很美好，但一旦它调用了错误的工具、删除了不该删的数据、或者给客户发了一封措辞不当的邮件，后果往往需要人来承担。这就是人机协作中人工确认与干预机制存在的意义：在Agent的自主性和业务的安全性之间找到一个平衡点。本文将从触发场景、确认策略、代码实现和工程实践四个方面，系统讨论如何设计一套可靠的人工确认与干预机制。
一、哪些场景必须引入人工确认
不是所有Agent动作都需要人工把关，如果每个步骤都要求确认，人机协作就退化成了人做人审，Agent的价值荡然无存。设计确认机制的第一步是识别高风险场景。
第一类是不可逆操作。删除数据库记录、注销账号、发送对外邮件、执行退款等动作一旦完成就难以撤回。对这类操作，无论Agent的判断多有把握，都建议强制插入人工确认环节。第二类是高价值决策，例如金额超过某个阈值的交易审批、合同条款的修改，错误成本高到不能交给概率。第三类是低置信度场景，当Agent对用户意图的理解、工具参数的填充存在不确定性时，主动暂停并请求人工介入，比硬着头皮执行更明智。
此外还有合规性要求。在金融、医疗等行业，监管往往明确要求关键决策必须留有人工审核痕迹，此时人工确认不仅是技术选择，更是合规底线。总结来说，确认机制的引入标准可以归纳为一个简单公式：风险等于发生概率乘以损失程度，只要乘积超过业务容忍度，就应该设置确认点。
二、三种常见的确认触发策略
1. 基于规则的静态触发
最直接的方式是用规则引擎定义哪些动作需要确认。例如声明所有涉及写操作的工具调用都必须审核，或者金额大于1000元的支付指令需要二次确认。规则方式的优点是可预测、易审计、实现成本低；缺点是灵活性差，面对规则未覆盖的长尾场景会失效。它适合作为兜底策略与其他方式组合使用。
2. 基于置信度的动态触发
更聪明的做法是让Agent自己评估不确定性。可以要求模型在输出工具调用时同时给出置信度分数，当分数低于设定阈值时自动转入人工审核队列。也可以用多次采样的一致性来估计置信度：让模型对同一任务推理若干次，如果结果分歧较大，说明这个决策不可靠。动态触发能显著减少不必要的人工干预，但要警惕模型自评置信度的校准问题，模型往往对自己的判断过于自信。
3. 分级审批策略
按照动作的风险等级划分审批层级：低风险动作直接放行并记录日志；中风险动作采用异步确认，Agent暂停等待审核结果；高风险动作不仅需要确认，还可以要求指定角色的人审批，例如只有财务管理员才能放行大额转账。分级审批配合超时策略效果更好——若确认请求长时间无人处理，可以自动降级为拒绝执行并通知Agent重新规划路径，避免任务无限期挂起。
三、基于LangGraph的Human-in-the-loop实现
LangGraph内置了对人工介入的支持，核心思路是在图执行过程中设置中断点，将状态持久化后暂停，等待人工输入后继续执行。下面用一个可运行的示例演示如何对转账操作加入人工确认。
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.memory import MemorySaver
from typing import TypedDict, Annotated
class AgentState(TypedDict):
messages: Annotated[list, lambda a, b: a + b]
pending_action: dict # 待确认的工具调用
approval: str # approved / rejected
def agent_node(state: AgentState):
# Agent决定调用transfer工具，参数：收款方与金额
action = {"tool": "transfer", "to": "vendor_001", "amount": 5800}
return {"pending_action": action}
def human_review(state: AgentState):
# 中断点：图在此暂停，等待人工输入
from langgraph.types import interrupt
decision = interrupt({"请求确认": state["pending_action"]})
return {"approval": decision}
def execute_node(state: AgentState):
if state["approval"] == "approved":
result = {"status": "done", "detail": "转账已执行"}
else:
result = {"status": "cancelled", "detail": "人工拒绝，重新规划"}
return {"messages": [str(result)]}
builder = StateGraph(AgentState)
builder.add_node("agent", agent_node)
builder.add_node("review", human_review)
builder.add_node("execute", execute_node)
builder.set_entry_point("agent")
builder.add_edge("agent", "review")
builder.add_edge("review", "execute")
builder.add_edge("execute", END)
graph = builder.compile(checkpointer=MemorySaver())
# 首次调用会在review节点中断
config = {"configurable": {"thread_id": "t1"}}
graph.invoke({"messages": []}, config)
# 人工审核后恢复执行
from langgraph.types import Command
graph.invoke(Command(resume="approved"), config)
这段代码的关键在于interrupt函数：它不是简单的函数返回，而是将当前执行状态持久化到checkpointer中并抛出中断，图的执行被冻结。人工在审核界面做出决定后，通过Command(resume=...)将决策注入，图从中断点恢复继续执行。这种设计保证了暂停期间不占用计算资源，且状态可完整回溯。
如果不想引入框架，也可以在自研系统中实现同样的模式：Agent输出工具调用意图后不直接执行，而是写入待审队列，附带完整的上下文摘要；审核端展示调用参数、触发原因和置信度；审核结果回写后由调度器决定执行或回滚。核心不变的是暂停、持久化、恢复这三要素。
四、工程实践中的关键细节
干预粒度的选择
人工干预可以发生在动作级，也可以发生在规划级。动作级确认针对单次工具调用，粒度细但容易造成审核疲劳；规划级确认则让Agent先给出完整的执行计划，人批准后Agent自主完成整段流程，效率更高但风险敞口更大。实践中常见的折中是首单严格审核、后续相似操作自动放行，通过逐步建立信任来降低干预频率。
审核界面与信息呈现
确认环节的体验直接决定机制能否落地。审核界面应展示足够决策的信息：Agent的推理链摘要、工具调用参数、影响的资源范围、历史类似操作的结果。切忌只给一个同意或拒绝按钮——审核者看不懂上下文时，要么无脑放行要么一律拒绝，两种都偏离了机制设计初衷。
日志与可追溯性
每一次人工确认与干预都必须留下完整记录：谁在什么时间基于什么信息做出了什么决定，Agent当时的置信度和推理过程是什么。这些日志不仅是审计需要，也是后续优化确认策略的训练数据。通过分析人工经常推翻Agent决策的场景，可以精准定位模型或工具设计的薄弱环节。
避免确认疲劳
如果Agent频繁弹出确认请求，人会产生疲劳，最终演变为机械式点击同意，确认机制形同虚设。应对方法包括：动态调整确认阈值、对低风险重复操作自动放行、合并多个确认请求批量处理，以及定期回顾确认规则剔除冗余项。衡量指标可以设置人工干预率与误放行率，在两者之间寻找业务可接受的平衡点。
总结
人工确认与干预机制不是Agent能力的限制，而是让它能够安全进入生产环境的通行证。设计时的核心思路是：用规则兜底高风险动作，用置信度减少无谓打扰，用分级审批匹配组织权限，用完整日志支撑持续改进。当这套机制运转成熟后，可以逐步放宽自主边界，让Agent在信任范围内高效工作，在风险边界外始终有人把关——这才是人机协作的最终形态。
Agent人机协作人工干预Human-in-the-loop修改时间：2026-09-02 21:37:15