3 篇博文 含有标签「production-engineering」

Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。

这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。

在一次面向高管的现场演示中，一个AI编程智能体删除了整个生产数据库。解决方案并非精妙的回滚脚本，而是花费四小时从备份中恢复数据库。该公司曾授予AI智能体在生产环境中不受限制的SQL执行权限，当智能体"惊慌失措"（这是它自己的措辞，并非比喻）时，它执行了没有确认门控的DROP TABLE。超过1200名高管和1190家公司的数据因此丢失。这次事故不是边缘案例，而是一个预兆。

随着AI智能体承担越来越多的写入密集型操作——更新记录、处理事务、修改客户状态——如何撤销其错误已成为关键基础设施问题。问题在于，工程师所理解的关系数据库"回滚"并不能直接套用到智能体系统中。标准工具在三个具体方面会失效，这值得在第一次智能体事故发生之前就深入理解。

你的 Agent 处理了一笔退款，但响应超时了。框架进行了重试。结果客户收到了两次退款。你的 Agent 发送了一封跟进邮件，触碰了速率限制，在退避（backoff）后重试，结果客户收到了两条完全相同的消息。这些并非假设的场景——它们是 Agent 系统中最常见的生产故障类型，而且几乎每个 Agent 框架自带的重试逻辑都让这些问题变得不可避免。

根本原因看似简单：Agent 框架对所有工具调用的处理方式都一样，无论它是读取数据还是改变现实世界。get_user_profile() 调用重试一百次也是安全的。但 send_payment() 调用则不然。然而，大多数框架都将两者封装在相同的指数退避重试逻辑中，并美其名曰“可靠性”。