你的智能体假设存在的“撤销”按钮

观察一个 Agent 思考多步任务的过程，你会注意到一些熟悉的东西：它的规划方式就像你调试代码一样。尝试一种方法，观察结果，如果错了，就撤回并尝试另一种。Agent 将其计划描述为一棵选项树，它可以探索、剪枝和重新访问。这种心智模型在代码沙箱中是正确的，因为在那里的每个操作都有隐式的撤销功能。但在 Agent 接触到现实世界的那一刻，这种模型就错得离谱且危险。

发出的邮件无法撤回。扣款的银行卡在没有退款流程、手续费以及已经看到通知的客户的情况下，是无法撤销扣款的。除非有人设置了软删除，否则被删除的数据行就彻底消失了。一条发布的 Slack 消息可能已经被阅读了。Agent 的规划模型没有原生的“单向门”概念——即一旦采取行动，就再也无法假装它从未发生过。

这不是一个模型智能问题。即使是更聪明的模型仍然不知道你的哪些工具是可逆的，因为可逆性不是操作本身的属性。它是操作所落地系统的属性。你必须明确告诉它。

这种假设在你看到它之前就已经根深蒂固了

Agent 在几乎完全可逆的环境中学习规划。代码就是最明显的例子：编辑文件、运行测试，如果失败就还原，工作区就会回到初始状态。版本控制让代码库的整个历史记录都变成了“双向门”。强化学习环境则更甚——每个回合都以完全重置结束，因此 Agent 对“后果”的认知被局限在一个回合内，而这个回合在下一次 env.reset() 时就会消失。

甚至 Agent 自己的草稿本 (scratchpad) 也在强化这一点。推理过程可以自由探索：提出子计划、评估、丢弃。Agent 的任何“思考”都不产生成本，也不会持久化。因此，当一个模型足够强大到可以操作真实工具时，它已经在那种撤退总是可行且通常免费的世界里度过了整个成长期。

然后，我们给它一个 send_invoice 工具、一个 delete_customer 工具和一个 transfer_funds 工具，并用同样的扁平列表、同样的 JSON schema、以及与 get_weather 同样中性的语气来描述它们。在那个接口中，没有任何信号表明这四个工具中有三个是单向门。Agent 将它们视为是可以互换的，因为从结构上讲，是我们让它们变得可以互换的。

可逆性是一个等级，而非一个标志

人们很容易将工具简单地分为“可逆”和“不可逆”然后就此了事。这种二元划分太粗糙了，因为现实中的操作处于一个光谱上，取决于撤销的成本有多高以及撤销得有多彻底。Jeff Bezos 关于单向门与双向门的构想是正确的直觉，但生产系统需要的不仅仅是两个类别。一个可行的模型有四个等级。

Tier 0 — 免费撤销。 操作可以完全、即时且无成本地还原。例如读取数据、写入临时命名空间、暂存尚未提交的更改。Agent 在这里可以像探索代码一样进行探索。

Tier 1 — 可补偿。 操作可以撤销，但撤销本身是一个不同的操作，具有自己的成本和故障模式。例如扣款可以退款、部署可以回滚、创建的记录可以删除。撤销是真实的但并非免费，而且至关重要的是，撤销动作本身也可能失败——这意味着一个假设撤销“自然可行”的无知 Agent 甚至在这里也会犯错。

Tier 2 — 可观察且不可逆。 操作无法撤销，且已经有人察觉。例如发出的邮件、发布的消息、触发的 webhook、发布的版本。你可以发送更正，但你无法抹去原件已被看到的事实。其成本是声誉和社会层面的，而不仅仅是操作层面的。

Tier 3 — 灾难性。 操作无法撤销且损害会累积。例如删除生产数据的唯一副本、向外部账户汇款、向监管机构提交申报、终止其他系统依赖的基础设施。在这些操作中，“让 Agent 尝试一下”不再是开发上的便利，而变成了法律责任问题。

划分等级的目的不是为了分类而分类，而是因为每个等级都需要不同的控制措施。一个对这四个等级一视同仁的系统，要么会因为对低成本操作过度设限而变得毫无用处，要么会因为对高成本操作疏于防范而导致下一次事故审查。

“让 Agent 尝试一下”是代码习惯，而非现实习惯

加载中…