把流程交给 ChatGPT Work 这类带工具调用的工作台时，真正要先定下来的不是提示词写得多细，而是哪个动作可以由智能体直接按下、哪个动作必须停一下等人。判断标准只有一条：动作出错之后能不能撤回来。只读查询错了，重跑一次即可；写入草稿错了，改回来即可；对外发送、删除数据、发起付款、改动线上配置这类动作，一旦执行就没有回退按钮，只能靠人事先阻止。所以拆解、检索、草拟可以放开，审批和对外发送必须留在人这一侧。下面这套分法不依赖某个具体产品能力，你账号里实际可用的工具、权限和日志，需要结合环境确认后再套用。

可放手让工作台自动执行的，是那些出错后可以重来、可以删掉、没有第三方感知的动作：读文档、查库、拉取列表、生成草稿、做格式整理。必须人工确认的，是写入共享系统、修改他人可见状态、调用外部接口的动作。必须由人亲自做的，是对外发送、批量删除、权限变更和资金类操作。这条边界落地时要配三样东西：一份可自动执行的动作清单、一个能看到原文和影响范围的确认界面、一条写清撤回方式和责任人的补救路径。没有撤回路径的高风险动作，不要授权给智能体。

把流程里的动作按可逆性分成三类

分之前先把流程拆到“动词”粒度。“处理客户邮件”不是一个动作，“读取最近 20 封邮件”“按主题归类”“生成回复草稿”“把草稿写进草稿箱”“发送”是五个动作，可逆性完全不同。按可逆性分完之后，再按风险补一层：即使可撤回，如果影响的是一百个人的可见状态，也要往上升一级。

这张表的用途是给权限配置和工具白名单定调：只读工具可以直接挂给智能体，写入类工具挂但要求回传变更预览，不可撤回类工具不挂给智能体，只允许它生成待办或待发送内容。

把只读查询类动作先交给智能体自动跑

先从只读环节起步，目的是让团队在真实业务里观察它的检索范围和输出格式是否稳定，而不是一次性放开全流程。建议自动执行的动作范围先限定在这几类：内部文档与知识库检索、工单和任务系统的状态读取、日历空闲时间查询、表格或报表的只读拉取、把长文摘成结构化要点、按模板生成草稿文本。凡是需要调用外部系统并产生回执的接口，这一阶段一律不放。

每次执行后要有可核对的东西，否则你无法判断它的结论是来自工具返回还是自己编的。建议在工作台侧要求输出固定结构的执行回执，再人工抽查前若干条：

请按以下格式输出，不要省略字段：
动作：查了什么系统、什么查询条件
依据：命中的记录 ID 或文档标题列表（无命中就写“无命中”）
结论：基于上述依据得到的判断，一句话
不确定项：无法从工具结果确认的部分，明确列出
建议下一步：只生成建议，不要执行任何写入或发送

核对的重点不是“它答得对不对”，而是三条：依据里的记录 ID 能否在源系统里查到；无命中时它有没有硬编一个答案；不确定项有没有被如实写出来。抽查时如果发现它在无依据时仍在给结论，先收回该类工具，再重写提示词。

对写入、发送、删除类动作设置人工确认点

确认点要放在“动作执行前一步”，不是执行后再补审。工作台侧的常见做法是把工具拆成生成和执行两段：智能体只能调用生成段（产出草稿、产出变更预览），执行段的调用被拦下来，转成一条待确认条目推给人。确认点最稳妥的位置是调度层而不是提示词里，靠提示词写“请先问我”很容易在长对话里被绕过。通用的拦截判定可以写成这样，具体字段按你的工具命名替换：

def need_human_confirm(tool_name, args):
    if tool_name in READONLY_TOOLS:
        return False
    if tool_name in {"send_email", "send_message", "delete_record",
                      "share_external", "submit_approval"}:
        return True   # 不可撤回，强制人工
    if tool_name in {"write_doc", "add_tag", "append_note"}:
        return args.get("scope") != "draft"   # 只有草稿态可放行
    return True       # 未登记的工具默认拦下

确认时人需要看到四类信息，缺一项就容易点错：一是完整原文，包括收件人或目标对象的确切标识，不能只给摘要；二是变更前后的对比，写入类要显示覆盖了什么旧值；三是执行依据，即智能体引用了哪几条记录；四是重复执行的影响，即这个动作跑两次会不会发出两封邮件。被拒绝后的处理不要只写“拒绝”，建议明确三件事：拒绝原因回传给会话，让它改；被拒动作标记为终止态，不由它自己重试；超时未确认的动作默认作废，不要默认放行。

给每个高风险动作写一条撤回或补救路径

确认机制挡掉的是误触发，挡不掉人点错。高风险动作要各写一条补救路径，写在一份可被执行的清单里，而不是散在群里。清单至少包含撤回方式、责任人、可接受的响应时间。这里的时间由业务方自己定，不要照抄别人的数字：对外发信的撤回窗口通常以邮件系统支持为准，聊天消息类多数只能撤回有限时间内的内容，删除和权限变更往往无法自动还原，只能靠备份恢复。

- action: send_email_external
  owner: 客户成功组值班人
  revoke: 邮件系统撤回功能 + 电话或补充邮件说明
  fallback: 无法撤回时由值班人在确认后对外更正
  response_window: 由业务方按客户沟通要求确定
  check: 值班人确认收件人是否已读
- action: delete_record
  owner: 数据维护负责人
  revoke: 从近端备份恢复指定记录
  fallback: 无备份时登记为数据缺失并回溯影响范围
  response_window: 按备份周期确定
- action: share_external
  owner: 文档所有者
  revoke: 关闭外链或移除协作方权限
  response_window: 按对外协作约定确定

这份清单的验证方式是演练，不是阅读。挑一个可撤回的动作在内部环境走一遍：让人故意点一次错误的确认，看值班人能否在响应窗口内完成撤回，看撤回操作是否有日志留痕。跑不通的条目说明责任人或入口没落实，先把该动作的人工确认收紧，再谈扩大自动化范围。