OpenClaw 工作流做久了，迟早会遇到一个问题：哪些事情可以自动做，哪些事情必须先问人。查资料、生成草稿、整理表格通常可以放手；发送消息、删除文件、改配置、批量更新客户信息，就不能只靠模型一句判断。
人工确认节点的价值就在这里。它不是给自动化泼冷水，而是给高风险操作加一道可解释的刹车。前面讲 定时任务设计 时提到过，日报、周报和异常提醒不要混在一条链路里；确认节点也是同样逻辑，不同风险要走不同路径。
先定义什么叫高风险
高风险不等于复杂。一个简单的“发送”动作，如果对象是客户群、公司大群或外部邮箱，就可能比复杂的内部查询更危险。建议先列一张风险清单：对外发送、删除或覆盖数据、修改权限、触发付款、批量操作、影响生产环境的配置，都默认需要确认。
这张清单应该和 权限与凭证管理 放在一起维护。凭证决定 Agent 能不能做，确认节点决定它什么时候可以做。
确认内容要让人能判断
很多确认流程失败，是因为弹出来的内容太空：“是否继续执行？”这对审批人没有帮助。一个合格的确认节点至少要显示任务目标、操作对象、预计影响、关键参数、可撤回方式和 Agent 的依据。
比如要给客户发送跟进邮件，确认信息里应该展示收件人、邮件主题、正文摘要、引用的客户背景和不确定点。这个设计可以直接复用 销售线索整理 里的草稿流程。
超时和拒绝也要有路径
确认节点不能只设计“通过”。审批人没看到怎么办，超时怎么办，拒绝后 Agent 要不要修改方案，是否通知发起人，都要提前定义。否则工作流会卡在一个没人处理的状态里。
对低时效任务，可以让它进入待办队列；对高时效提醒，可以设置超时后降级为通知；对高风险执行，超时应该默认不执行。这个原则和 日志复盘 也有关，失败状态必须能被查到。
确认记录要进日志
人工确认不是口头点头，而是一条审计记录。谁在什么时间看到了什么信息，选择了通过还是拒绝，执行结果是什么，都应该留在日志里。后面复盘时，团队才能判断是 Agent 判断错、确认信息不完整，还是人工审批没看清。
如果 OpenClaw 工作流已经进入团队协作场景，这些日志还可以反过来优化提示词和工具权限。确认次数太多，说明自动化颗粒度可能太粗；误拒绝太多，说明确认内容不够清楚。
总结
OpenClaw 人工确认节点要解决的不是“要不要自动化”，而是“哪些操作值得自动化到哪一步”。把高风险动作识别出来，把确认信息写清楚，把超时、拒绝和日志补齐，团队才能在效率和安全之间找到稳定边界。
