当Agent被赋予执行写操作、发送通知、修改配置或审批退款等能力时，提示词中如果没有明确列出哪些步骤必须由人工确认，模型很可能基于训练数据中的行为模式自动完成全部流程。一个典型故障是Agent收到批量退款请求后直接调用支付接口同意全部申请，造成资金损失。要避免此类问题，不能只依赖模型自身的判断，而应在提示词模板中嵌入结构化的确认指令，让Agent在关键决策点主动暂停，等待用户明确输入后再继续执行。
为什么Agent需要人工确认节点
大模型Agent通常会连接工具、数据库或外部API，这些执行链路一旦自动运行，错误会迅速扩散。例如在客服工单场景中，Agent被允许关闭工单、发送回复邮件、修改用户标签；在运维场景中，Agent可以重启服务、调整配置、清理缓存。如果提示词只描述目标而缺少权限边界，模型可能把建议动作直接当成执行指令，省掉了最不该省的人工判断环节。
更关键的是，许多操作具有不可逆性或合规要求。删除数据、批量退款、对外发送正式通知、修改生产环境配置等行为，一旦执行错误，回滚成本很高，甚至无法回滚。监管和审计还要求关键操作必须有责任人签字或确认记录。Agent如果不具备暂停询问的能力，就无法满足这些约束。因此，在提示词模板中显式定义哪些步骤属于关键决策，并要求模型在触发这些步骤时输出确认请求而不是直接执行，是构建可信人机协作系统的基础。
人工确认节点还能显著降低模型幻觉带来的风险。当Agent对某个实体状态或业务规则不确定时，它可以先给出推断和依据，再请用户确认，而不是硬着头皮执行。这样既保留了自动化效率，又为高风险环节增加了人工护栏。
人机协作提示词模板的核心字段
一个可复用的Agent提示词模板至少应包含角色、目标、权限列表、关键决策规则、确认方式和异常处理六个部分。角色用于限定Agent的身份与语气，目标说明本次任务要完成什么，权限列表明确哪些操作允许自动执行、哪些必须经过确认。关键决策规则是模板的核心，它告诉模型在满足什么条件时必须停下来询问。
下面是一个用Python字典表示的模板结构，它可以直接转换成JSON或拼接到提示词中。注意其中critical_decisions数组专门用来定义需要人工介入的场景，每个场景包含触发条件、动作和询问文案。
agent_prompt_template = {
"role": "工单处理助手",
"goal": "分析客户工单并给出处理建议",
"permissions": [
"读取工单内容",
"生成处理建议",
"在获得用户确认后执行关闭操作"
],
"critical_decisions": [
{
"name": "关闭高优先级工单",
"trigger": "priority >= 4 and sentiment == 'negative'",
"action": "pause_and_ask",
"message": "检测到高优先级负面工单，建议关闭。请确认是否执行？"
},
{
"name": "批量退款",
"trigger": "refund_count > 1 or refund_amount > 10000",
"action": "pause_and_ask",
"message": "本次退款涉及多笔订单或金额较大，请人工审核后退款。"
}
],
"confirmation_style": "explicit_approval",
"fallback": "如果用户未在指定时间内回复，则保留当前状态并升级给人工处理"
}
在实际使用时，可以将这个结构转换成自然语言描述嵌入系统提示词。比如可以这样描述：当满足critical_decisions中的任意触发条件时，你必须停止当前任务，向用户展示询问文案，等待用户回复批准或拒绝后再继续。模型就能理解这些规则，并在运行时按照条件暂停。
如何设计关键决策点与确认流程
关键决策点的设计不能拍脑袋，而要基于业务风险等级和操作可逆性。通常可以把操作分为只读、可逆写、不可逆写三类。只读操作如查询数据、读取日志，可以让Agent自动执行；可逆写操作如创建草稿、添加备注，也允许自动执行但需要记录日志；不可逆写操作如删除记录、批量退款、发送正式通知，必须设置为关键决策点并强制人工确认。
确认流程需要明确三个要素：询问内容、超时策略和拒绝后的回滚动作。询问内容要包含Agent打算做什么、依据是什么、影响范围有多大，这样用户才能做出高质量判断。超时策略用于处理用户长时间不响应的情况，可以配置为自动升级给人工、保留现场等待或按预设安全策略回退。拒绝后的回滚动作则要告诉Agent如果用户不批准，应该执行哪些清理操作，避免留下半成品。
def execute_with_confirmation(agent_output):
for decision in agent_output["pending_decisions"]:
user_response = ask_user(decision["message"])
if user_response == "approve":
execute(decision["action"])
write_audit_log(decision, "approved")
else:
rollback_or_hold(decision)
write_audit_log(decision, "rejected")
这段伪代码展示了确认流程的基本逻辑：Agent产生待确认决策后逐个询问用户，批准则执行并记录审计日志，拒绝则回滚或保持现场。把这段逻辑与提示词模板配合起来，可以在工程层面保证确认机制不被模型忽略。另外，确认请求的措辞要避免歧义，不要只问“是否继续”，而要明确写出“我准备执行关闭工单操作，请回复批准或拒绝”。
实践中的常见误区与调优建议
第一个误区是过度确认。如果开发者在提示词中把所有步骤都设置成需要人工确认，Agent就会频繁打断用户，最终导致用户疲劳，反而忽略真正重要的确认请求。合理的做法是只对高风险、不可逆或合规要求的操作设置确认节点，其他操作让Agent自动执行并记录日志，用户可以事后审查。
第二个误区是确认词语义不清晰。有的提示词只让模型在不确定时询问，但没有给出询问格式和用户回复的解析规则，模型可能生成一段长文解释，而系统无法判断用户到底批准没有。应该在提示词中规定用户回复只能使用批准、拒绝、修改三个选项，并要求模型在遇到其他回复时再次询问。
第三个误区是忽视审计日志。人工确认不仅是为了阻止错误发生，也是为了事后追溯责任。每次确认操作都应该记录时间、操作内容、用户决策和最终执行结果，日志要持久化保存。这样即使出现争议，也能快速定位是哪个环节出了问题。最后，建议定期回顾Agent的确认请求频率和通过率，如果某个关键决策点长期没有触发或者触发后用户总是拒绝，说明提示词或业务规则需要调整。