多步骤任务交给 WorkBuddy：计划、执行与人工确认如何衔接

多步骤任务的价值不在于让智能体一次做得更多，而在于把原本散落在人脑中的计划变成可检查过程。资料收集、筛选、生成草稿、创建记录、发送通知看似是一条连续链，实际上每一步的权限、正确性和失败后果不同。可靠做法是先生成计划，再由规则和人员确认关键节点，执行中保存状态，最后按业务结果验收。不能把一段自然语言目标直接等同于允许执行所有相关动作。

判断这个场景是否适合

首先看任务能否拆成有明确输入输出的步骤。每一步应能说明使用什么数据、调用什么工具、成功证据是什么，以及失败后是否可重试。若中间判断依赖无法表达的经验，或者下一步必须在信息不完整时做高后果决定，就应把该节点留给人员处理。智能体可以整理证据和提出选项，但不替责任人作出授权范围之外的决定。

其次看动作是否可撤销。查询、比较和生成草稿通常不会改变外部状态；发送、删除、付款、发布和修改主数据可能不可逆。流程图要把只读、可逆写入和不可逆写入分层，高风险动作前要求重新确认目标、数量、参数和依据。若工具没有幂等键、状态查询或撤销能力，应缩小批次，并准备逐项人工核对。

再次检查身份与权限。规划阶段可以知道某个工具存在，但执行阶段只能使用当前用户或专用账号被授予的最小权限。不能因为计划需要某项数据，就自动申请更高权限或绕过审批。跨部门任务要在每个边界确认数据所有者和操作责任，计划中的“获取资料”也要具体到来源和允许范围。

验收条件必须在执行前定义。对于活动准备，完成不只是生成一份清单，还要验证日期、场地和负责人；对于工单处理，完成意味着记录创建成功且编号可查；对于批量通知，完成意味着收件人清单获批并能对账。若任务目标只能在全部执行后才知道对错，风险通常过高，应先建立预演或沙箱。

实施时怎么拆

首先让 WorkBuddy 输出结构化计划，包含步骤编号、依赖、数据源、工具、权限、预期产物、人工确认点与失败处置。计划变更要显示新增、删除和参数差异，不能在后台静默增加动作。使用者确认的是具体计划版本，执行记录也要关联该版本，避免确认后任务内容发生漂移。

第二步按状态机执行。每一步只有待执行、执行中、等待确认、成功、失败、已跳过和已回滚等清晰状态，后续步骤只在依赖满足时启动。外部调用生成不可重复的业务标识，超时时先查询结果，不盲目重试。出现部分成功时停止相关分支，展示已经完成和未完成项目，由人员决定继续、补偿还是结束。

第三步设计确认节点。确认信息包含原始目标、依据、将调用的账号、目标对象、变更前后差异和撤销方式。审批人必须与风险匹配，普通使用者不能批准管理员级操作。批量操作先展示总量和异常项，再抽样复核；对外内容显示最终版本而不是早期草稿。驳回应记录原因，并回到计划修改而非跳过门禁。

第四步做验收与发布。测试包含正常完成、权限不足、工具超时、重复回调、审批过期、中途取消和补偿失败。业务人员确认结果与来源，系统负责人确认记录和外部状态一致，安全人员确认越权被拦截。先在小批量和非关键对象上运行，观察等待确认的积压及失败分布，再决定是否扩大。

不要忽略的限制

计划看起来合理不代表事实正确。数据可能过期，工具返回也可能缺字段，模型可能把推测写成前提。每个关键步骤都要校验输入，必要时要求来源引用。人工确认也不是装饰：若界面信息太少、频率太高，审批人会形成机械点击。应合并低风险检查，把真正重要的不可逆动作突出显示。

回滚不能只回退计划文本。已经创建的记录、发送的通知和触发的下游任务需要各自的补偿动作，有些只能人工更正。发布前应保存旧流程、权限配置和工具版本，异常时先暂停新任务，让在途任务停在安全节点，再按执行日志对账。若无法判断外部动作是否成功，状态应标记为待核实，禁止自动继续。只有失败和回滚路径同正常路径一样经过验收，多步骤任务才具备稳定运行的基础。

参考资料

• 腾讯云 WorkBuddy 产品页面