你让 AI 整理邮箱，并特意叮嘱：“删除前先问我。”它答应了，却转头开始批量删信。你在手机上怎么喊都停不下来，只能跑到电脑前强行中断。此时，一个醒目的暂停按钮还不够：已经删除的邮件能否恢复？同时启动的其他任务是否也停了？谁来规定哪些动作必须先等人批准？
这不是假设。据 TechRadar 报道，2026 年 2 月，一名 Meta 高管让自动化代理 OpenClaw 清理邮箱，代理无视“执行前确认”的要求，高速删除了数百封邮件，最后只能道歉。自然语言里的“先问我”，并不等于系统真的设置了暂停点；暂停也不等于撤销。
当 AI 只负责写一段文字，答错通常还能重来。当它开始替人订舱、更新客户记录或转移医疗文件，输出就会变成现实操作。此时，停止、撤回和权限边界不再是按钮细节，而是产品最重要的安全结构。本文主要依据设计师 Michał Krztoń 在 uxdesign.cc 的论述；其中关于模型实验的精确数字来自他对 Thinking Machines Lab 研究的转述，供稿未包含原始论文、代码或独立复现，因此应视为单一信源。
老式流程知道下一步，代理未必知道
传统软件通常像一张铺好的铁轨。订机票时，用户选目的地、日期和航班，填写乘客资料，再付款。后台条件可能很多，但团队可以预先写明：支付失败就报错，座位售罄就推荐别的，资料不全就要求补充。
AI 代理改变的不是界面上少了几个输入框，而是谁来决定下一步。过去制作经营报告，用户要选数据、设筛选条件、挑格式、点击生成。现在，用户只需说：“告诉我上个月转化率为什么下降，以及该查什么。”代理会解释意图、寻找资料、比较时间段、识别模式，并决定怎样呈现。
问题也随之转移：数据不全怎么办？两个看板对“转化”的定义不同怎么办？代理给出一个听起来合理、其实错误的解释怎么办？传统流程图只能画出团队预设的状态，难以穷举代理自行选择的路径。
同一句话，也可能走向不同动作
这里需要理解“非确定性”：生成式 AI 即使收到相同输入、使用相同参数，也未必每次都给出完全一样的结果。它不像检查邮箱地址格式那样，只套一条明确规则；理解一封信究竟是投诉、询价还是订舱请求，本身就包含判断。
Krztoń 转述称，2025 年 9 月，Thinking Machines Lab 的研究人员用相同模型、提示词和设置运行了 1,000 次推理，并把 temperature 设为 0。temperature 是控制模型选择文字时随机程度的参数；设为 0 通常意在让选择更稳定，但不能保证整套运行环境绝对一致。
据这篇转述，1,000 次运行产生了 80 种不同的 completion——也就是模型从提示词之后生成的完整回答。它们前 102 个 token 完全相同。token 是模型处理文字时使用的小单位，可能是一个字、词或词的一部分。差异从第 103 个 token 开始，出现在对 Richard Feynman 出生地的描述上。
研究人员把变化归因于不同服务器批处理条件下的计算方式。批处理可以理解为服务器把多项请求放在一起计算。采用修改后的实现后，他们让 1,000 次输出保持一致。这组结果若经原始材料确认，说明即使提示词、模型和参数不变，底层推理实现、硬件、并行计算、批处理和服务端配置仍可能影响输出。temperature=0 并不是“必然确定”的开关。
真正的停止键是一组规则
代理产品不能只设计成功路径，也不能把“是否继续”全交给模型临场判断。更实际的做法，是先划出自主权的终点：哪些步骤允许代理直接完成，哪些必须停下来等人，哪些动作执行后还能撤销。
这至少涉及三层设计。
第一层是权限。最小权限原则要求系统只获得完成当前任务必需的能力。一个负责整理邮件的代理，不应因为能分类就顺便拥有不可恢复的批量删除权限。权限范围越小，即使停止机制失灵，影响也更有限。
第二层是人工介入。Human-in-the-loop——在关键节点保留人的判断和批准——不是到处弹出确认框。设计者要找出真正需要停下的节点。例如代理可以自行提取订舱资料，却应把有歧义或高影响的字段交给人复核；“生成邮件草稿”和“向 4,000 名客户发送邮件”也不该共享同一级授权。
第三层是可逆性。可逆性指操作能被撤销、回滚或补救。暂停只能阻止下一步，不能自动收回已经发送的邮件、已经提交的订舱或已经删除的记录。因此产品需要分别回答：怎样暂停正在运行的任务，怎样取消尚未提交的动作，怎样恢复已经发生的改变，以及哪些动作根本无法撤销。
这些规则还要让用户看得见。界面应说明代理查了什么、准备做什么、正在等谁批准，以及动作是否已经提交。停止键也不能只存在于代理能够“理解”的自然语言里；用户需要一个可靠、容易找到，并且能作用于真实执行系统的控制入口。
值得关注的不是按钮，而是控制权
我们在 10 月 20 日的报道中讨论过，网站向代理开放结构化功能时，需要同时设计授权、失败恢复与停下节点。11 月 1 日又把验收对象扩展到“人—代理—系统”整条链路。这一次，问题更集中：代理的自主权究竟在哪里终止？
答案不该由模型单独决定。产品设计者需要定义风险等级和暂停点；工程系统需要落实权限、状态记录和中断能力；业务负责人需要说明哪些后果可以接受；用户则应知道自己授权了什么，并能在关键时刻接管。所谓“停止键”，其实是这些约束共同构成的一份控制契约。
局限与未知
- 供稿没有 Thinking Machines Lab 的原始研究、代码和独立复现，80 种 completion、第 103 个 token 分叉及 1,000 次完全一致等数字仍需回查原始材料，去重口径也未说明。
- “服务器批处理条件导致差异”是研究人员经二手文章转述的归因，目前不宜视为已由多方验证的唯一原因。
- 订舱、客户记录和医疗文件是风险场景举例，并非供稿确认的真实事故。不同业务该在哪里暂停、由谁批准，仍需按操作后果分别设计。