该内容为自助投放广告,真伪自辨
立即入驻

多步长任务智能体的中途确认设计:什么时候该让 Agent 停下来提问

广告也精彩

在构建需要多轮思考、工具调用和外部交互的智能体时,往往会出现「执行到一半」才发现上下文不完整或风险未知的情况。新一代 LLM 越来越强调 主动修正计划、提出澄清问题并寻求确认,这为我们提供了在关键节点让 Agent 主动停下来、等待人工介入的设计思路。

多步长任务智能体工作流示意图

为什么需要中途确认

  • 降低不可逆风险:写库、发送邮件、发起支付等操作一旦完成,错误难以回滚。

  • 提升交互效率:在信息不足的环节让 Agent 主动提问,避免盲目执行导致重复工作。

  • 增强可控性:人工介入的确认点可以嵌入业务规则或合规审查,满足企业级安全要求。

不可逆动作的硬确认

需要强制人工确认的典型节点

  1. 写入持久化存储(数据库、文件系统、云存储)。

  2. 发送外部通讯(邮件、短信、企业微信、社交媒体)。

  3. 发起金融交易(支付、退款、转账、结算)。

  4. 触发业务流程(订单创建、库存扣减、审批流启动)。

这些操作一旦完成即产生副作用,错误往往只能通过补救流程处理。因此在系统提示词或工作流中必须加入 硬确认(如 await_user_confirmation())并在 UI 层提供明确的“确认”或“取消”按钮。

可通过一次澄清的可回退节点

对于 查询、检索、数据预处理、工具调用的参数构造 等可重复的步骤,智能体只需要一次澄清即可继续。例如:

  • 搜索关键词不明确:Agent 可返回「请确认搜索关键词是 X 还是 Y?」

  • 数据格式转换:若输入文件类型未知,Agent 提问「请提供文件的实际格式」后再继续转换。

这些节点的确认可以采用 软确认(仅提示用户输入或选择),不需要阻断整个工作流,只要得到明确答案即可继续执行后续步骤。

在系统提示词中嵌入确认节点的写法

下面示例展示了如何在 系统提示词(system prompt)里声明两类确认机制。关键是把「何时需要确认」的判断逻辑写成可复用的指令块,而不是让模型自行猜测。

You are an autonomous agent tasked with a multi‑step workflow.
When you reach a step that involves any of the following actions, you must stop and request explicit user confirmation before proceeding:
- Writing to persistent storage (database, file, cloud bucket)
- Sending external communications (email, SMS, webhook)
- Initiating a financial transaction (payment, refund, transfer)
- Triggering a core business process (order creation, inventory deduction)

For all other steps, if you encounter ambiguous input or missing parameters, ask a clarification question and resume automatically after the user answers.

在实际实现时,可将上述指令块保存为变量 CONFIRM_RULES,并在每次生成下一步指令前先检查当前动作是否匹配列表,从而决定调用 await_user_confirmation() 还是 ask_for_clarification()

工作流层面的确认节点配置示例

下面以 LangGraph 为例,展示如何在工作流图中标记硬确认与软澄清节点。图中红框表示必须人工硬确认,蓝框表示仅需一次澄清。

系统提示词确认节点示例

from langgraph import Graph

graph = Graph()

@graph.node
def fetch_data(state):
    # 可能出现搜索关键词不明确的情况
    if not state.get("keyword"):
        return ask_for_clarification("请提供要搜索的关键词")
    return search(state["keyword"])

@graph.node
def write_to_db(state):
    # 必须硬确认
    return await_user_confirmation(
        f"即将把以下数据写入数据库:{state['result']}n确认吗?"
    )

@graph.node
def send_email(state):
    # 必须硬确认
    return await_user_confirmation(
        f"准备发送邮件给 {state['recipient']},主题为 “{state['subject']}”。确认发送?"
    )

graph.add_edge(fetch_data, write_to_db)
graph.add_edge(write_to_db, send_email)

通过上述方式,开发者可以在 系统提示词工作流节点 两层同时控制确认逻辑,既保证关键操作的安全,又不影响整体效率。

实践要点与落地建议

  1. 先列出所有业务动作,区分「不可逆」与「可回退」两类。

  2. 在提示词中统一声明硬确认规则,避免在每个节点重复写同样的判断。

  3. 在工作流框架中实现统一的确认函数(如 await_user_confirmationask_for_clarification),保持代码整洁。

  4. 为每个硬确认节点配备 UI 提示,明确展示将要执行的动作、可能的风险以及「确认」/「取消」选项。

  5. 日志记录:每一次人工确认或澄清都写入审计日志,便于事后追溯与改进。

把这些步骤套用到自己的业务流程后,就能得到一套 可复用的停点划分方法:关键的不可逆节点必须硬确认,信息不足的可回退节点只需一次澄清。这样既保障了安全,又保持了智能体的高效运行。

© 版权声明

相关文章

暂无评论

none
暂无评论...