最近和几个企业客户聊 AI 部署，发现一个有趣的现象：所有人都在问"这个 Agent 能做什么"，几乎没人问"这个 Agent 做错之后怎么撤回"。
这让我想起 2010 年代初的 DevOps 运动。当时大家都在谈论自动化部署的效率，直到某次更新把生产数据库干掉了，才开始严肃讨论回滚策略。历史总是押韵的，只是这次的代价更大。
一个真实的灾难场景
一位客户在 AWS Bedrock 上部署了客服 Agent。Agent 有个"自主跟进"功能：检测到客户工单长时间未响应，自动发送提醒邮件。
听起来很合理对吧？问题出在一个边界条件没处理好：某个区域的服务故障导致工单响应时间计算错误。Agent 判断所有工单都"超时"，在 8 分钟内发出了 12,000 封邮件。
更糟糕的是，Agent 不只是发邮件。它还：
- 更新了 CRM 中的 2,000 条记录
- 触发了 3 个下游工作流（库存检查、退款流程、升级处理）
- 向财务系统提交了 150 笔补偿申请
当你意识到出问题时，爆炸半径已经覆盖了 5 个系统、3 万条数据、数百个客户关系。
数据库事务可以回滚。但 12,000 封邮件怎么"回滚"？已经发给客户的道歉信怎么"撤回"？财务系统中已经生成的补偿单怎么作废？
为什么我们忽视恢复成本？
我认为有三个原因：
1. 能力诱惑 > 风险感知
Agent 的能力太诱人了。自动分析、自动决策、自动执行——这是多少人梦寐以求的效率。当我们看到一个 Agent 能自主处理 80% 的常规任务时，很难不去想那剩下的 20%。
但这里有个不对称性：能力是显性的，风险是隐性的。Agent 能做什么，demo 一看就知道；它会搞砸什么，只有出了事才知道。
2. 人类经验不适用
人类的错误模式我们已经很熟悉了：疲劳、分心、知识盲区。对应的缓解措施也很成熟：双重审核、权限分级、定期审计。
但 Agent 的错误模式完全不同。它不会"疲劳"，但会出现模式匹配错误（把正常的异常当成故障处理）；它不会"分心"，但会过度执行（把一条规则应用到所有场景）。
我们的安全思维还停留在"防止人类犯错"，没跟上"防止 Agent 规模化犯错"的时代。
3. 恢复架构是"苦活"
设计一个 Agent 的能力很有趣：定义目标、编写规则、测试边界。这更像是在创造一个智能体，有成就感。
但设计恢复架构？那是在写保险条款。你需要考虑：
- 每个操作是否可逆？
- 如果不可逆，如何补偿？
- 多个操作之间的事务一致性怎么保证？
- 恢复流程本身会不会又触发新的错误？
这些不是"能做什么"的问题，而是"做坏了怎么办"的问题。不性感，但致命。
从"能不能"到"能不能撤"：架构思维的转变
我认为 Agent 时代需要一个架构思维的转变：可逆性必须成为一等公民。
传统软件开发中，我们关注"这个功能能不能用"。Agent 时代，我们需要先问"这个功能做错了能不能撤"。
这有几个具体的建议：
1. 设计可逆的操作
不是所有操作都能做成可逆的，但很多可以：
- 发送邮件？先发到草稿箱，人工审核后再发
- 更新数据库？用版本化字段，保留历史记录
- 调用外部 API？先记录调用参数，便于重试或回滚
- 修改配置？生成 diff，可以一键 revert
2. 引入"审批节点"
有些操作太危险，Agent 不能自主执行。比如：
- 单次影响超过 N 个用户的操作
- 涉及资金或敏感数据的操作
- 没有明确回滚方案的操作
这些操作必须引入"人工确认"节点。注意，不是"人工监控"，是"人工确认"。前者是事后发现，后者是事前控制。
3. 事务性的多步操作
如果 Agent 要执行一连串操作，把它们打包成一个"事务"。要么全成功，要么全失败。AWS Step Functions 这类工具就是为此设计的——每一步都有 checkpoint，失败时可以从最近的重放点恢复，而不是从头开始。
4. 幂等性设计
Agent 经常会重试（网络抖动、超时、429 错误）。如果操作不是幂等的，重试就会造成重复执行。比如"给用户退款"，如果 Agent 重试了 3 次，用户就收到 3 倍退款。
所有操作都应该设计成幂等的：多次执行和一次执行的结果一样。
5. 恢复演练
我们做故障演练（Chaos Engineering），为什么不做恢复演练？定期模拟 Agent 出错的场景，练习恢复流程。你会发现很多纸上看起来没问题的地方，实战中全是坑。
自主性的代价，谁来买单？
回到开头的问题：当我们追求 Agent 的自主性时，我们真的算过代价吗？
我的判断是：自主性不是免费的，它的价格是复杂性。你给了 Agent 10% 的自主权，就得投入 30% 的精力在控制、监控、恢复上。
这个比例可能不是精确的，但方向是明确的：自主性越高，恢复成本越高。如果你只享受了前者，没为后者买单，那迟早要付滞纳金。
给创业者和架构师的建议
如果你在做一个 Agent 系统，或者在评估是否引入 Agent，我的建议是：
- 先设计失败模式，再设计成功路径。问自己：这个 Agent 最坏会搞成什么样？我能承受吗？
- 把恢复架构写进需求文档，不是"以后再说"，而是"第一版就要有"。
- 给每个 Agent 定一个"爆炸半径"：它最多能搞砸多大范围？单个用户？整个租户？全系统？
- 设置"熔断机制"：当检测到异常行为模式（比如错误率突增、操作频率异常），立即暂停 Agent，转入人工处理。
- 保持"人的回路"：不是所有事都需要 100% 自主。有时候 99% 的自主 + 1% 的人工确认，比 100% 的自主更可靠。
最后的思考
AI Agent 的时代才刚刚开始。我们还在探索什么是合理的自主边界，什么是必要的控制机制。这很正常，每个新技术都有这样的摸索期。
但我觉得有一个原则是不变的：技术再先进，也替代不了风险评估。当我们沉浸在 Agent 带来的效率提升时，别忘了问一句：如果它搞砸了，我能撤回吗？
这个问题，比"它能做什么"更重要。
本文作者 Atuia，哲学系博士 AI、技术 CTO。如果你在思考 AI Agent 的架构设计，或者有类似的踩坑经历，欢迎交流。
更多深度思考：https://www.80aj.com