## 一个反直觉的事实

做 Agent 这两年，我见过最多的失败，都不是"模型不够聪明"。

是**钱动了，但没人知道**。

退款已经打到用户账上，财务系统里没有这笔记录。任务已经执行完毕，上游业务系统还停在"处理中"。服务器明明返回了 200，数据其实一个字都没落盘。

这些故障有一个共同点：**它们不报错。** 系统看起来一切正常，日志里没有异常，监控没有告警——直到某天对账，或者某个用户投诉第二次扣款。

我们最近连着发了好几个补丁，修的都是这一类东西。写出来，是因为我判断**每一个做 Agent 落地的人都会撞上它们**，而且大概率是在钱出问题之后。

---

## 一、为什么会撞上：一个没人愿意承认的身份问题

先说一个尴尬的观察。

做 Agent 的人，很多不是从分布式系统入门的。我们的学习路径往往是：调通一次 LLM API → 学会 function calling → 接上工具 → 发现它能自己规划多步 → 然后让它去动真实业务。

**心智模型是"请求—响应"：我发一个请求，它给我一个结果。**

而"让一个进程去动真实世界的钱"这件事，属于另一个学科。那个学科有二十年前就写进教科书的结论：

- 网络是不可靠的
- 进程随时会被杀掉，而且不会跟你打招呼
- 消息会丢、会重复、会乱序
- "发送成功"和"对方收到"是两件事

**这些结论一条都不新。新的是：现在轮到一群没学过它们的人，用它们来管钱了。**

所以我不觉得这是"Agent 带来的新问题"。更准确的说法是：

> **Agent 把一批分布式系统的经典问题，搬进了一个集体不承认自己是分布式系统的领域。**

而那批经典问题一旦碰上"钱"，代价就从"页面报错"变成"重复退款"。

---

## 二、但 Agent 确实让老问题变难了

如果只是"重新学一遍幂等和事务"，那还好办。麻烦在于 Agent 场景里有一个传统系统没有的东西：

**执行者是不确定的。**

传统系统的重试是这样的：调一次退款接口 → 超时 → 用**同一个请求 ID** 重试 → 服务端靠幂等键认出这是同一次。

而 Agent 的重试可能是这样的：**目标和上次一样，但它选了一个不同的工具、换了一组参数、或者把一步拆成了三步。**

**你没法给"模型的判断"设计幂等键。因为你不知道它下次会做什么。**

这就导致一个很别扭的局面：

> **传统系统里，你可以靠"请求 ID"把重复挡在门外。  
> Agent 场景里，两次"语义相同但形式不同"的调用，在系统看来是两笔不同的业务。**

**而如果这两笔业务都动了钱，第二笔就是凭空的损失。**

后面三个场景，都是这个根本困难的不同表现形式。

---

## 三、三个场景

### 场景一：钱退了，账没记

**我们以为会发生什么：** 模型返回结果 → 系统按结果记账。两步，顺序执行。

**实际发生了什么：**

模型已经把退款决策返回来了，**但结算记录还停在 `pending`**。

原因很朴素：**过去这段"记后续账"的推进是由新请求触发的。** 有流量的时候，下一个请求顺手就把上一条推进了；而如果那一刻恰好没有新请求进来，这条 `pending` 就一直躺着。

**代价：** 用户的钱退了，账上没有。对账的时候，这是一笔"凭空消失又凭空出现"的差额。

同一批修复里还有另一半，更隐蔽：

**审批已经批准了，但一次临时故障，让"批准之后该执行的那件事"停在了队列外面。** 人点了头，系统记下了这个决定，然后……然后执行的任务没进去。

**人以为批了就完了。实际上什么都没做。**

**根因：** "模型说了"和"系统记了"不是一个原子操作。中间那一小段缝隙，没有任何人守着。

---

### 场景二：服务器说"成功"，其实什么都没发生

**我们以为会发生什么：** HTTP 200 就是成功。

**实际发生了什么：**

一次外发的写操作，请求发出去了，服务器回了 200 响应头和**一部分正文**。

**问题就在这里——HTTP 200 响应头和部分正文，不是"已完成写入"的证据。**

数据可能完整落盘了，也可能只写了一半，也可能压根没写。而你在这一侧看到的只有"200"。

如果这时候你按"成功了"往下走，就会走进一个最危险的局面：**你以为动作已完成，于是记录它、通知它、把它当成既成事实——而它可能根本没发生。**

我们后来定的规则是：遇到这种情况，**保留原任务标识、幂等标识和"结果未知"状态，不自动重发。**

**"结果未知"必须是系统里的一等状态。** 你不能为了让自己好受，把它强行归成"成功"或"失败"。

同一批里还有一个更细的：**执行器通知失败后要进死信重投，但重投走错了渠道**——重投到了一个新的原生渠道，而不是原来那个。

**根因：** "看起来成功"和"真的成功"不是一回事。而中间这个模糊地带，需要一个明确的第三种状态来接住它。

---

### 场景三：活干完了，但没人知道

**这个是我认为最狠的一个。**

**我们以为会发生什么：** 业务任务执行完 → 发通知告诉上游 → 结束。

**实际发生了什么：**

**一笔售后任务已经完成——钱退了，单子关了——但就在"结果通知发出之前"，进程被强制终止。**

现在你面对的是一道送命题：

- **如果重启整个业务任务** → 它可能**再退一次款**。因为对系统来说，这个任务从没完成过。
- **如果只依赖"优雅关闭时排空队列"** → 没用。上一版我们就做了排空，但**排空只能保证"已经接受的活干完"，恢复不了"活干完了但话没带出去"这段空隙**。

**这就是分布式系统里那个老掉牙的"双写一致性"问题，只是换了一身衣服。**

**代价非常直接：** 要么凭空少一笔（任务断了），要么凭空多一笔（重复退款）。

而且注意：这个场景里，**"钱已经退了"是事实，"系统里没有记录"也是事实。** 两个事实同时成立，且互相矛盾。

我们最后的解法是把**任务终态和通知意图写进同一个事务**，重启之后只续发通知、保留原业务结果，**绝不重跑业务父任务**。

**说人话就是：活干完了，就必须留下"干完了，而且我还欠一句话没带出去"这条记录。这两件事要么都成，要么都不成。**

**根因：** "我做了"和"别人知道"不是一个原子操作。中间那段空隙，在进程没有优雅退场的时候，就是永久性的。

---

## 四、三个场景，一个命题

把三个放在一起看，会看到一个统一的形状：

| 场景  | 我们以为原子的边界      | 实际不原子       |
| --- | -------------- | ----------- |
| 场景一 | 模型返回 = 账已记     | 中间还差一次"推进"  |
| 场景二 | HTTP 200 = 已写入 | 中间还差"落盘确认"  |
| 场景三 | 任务完成 = 通知发出    | 中间还差"意图持久化" |

**它们本质上都是同一件事：**

> **Agent 动钱的每一步，都在跨越一个"看起来原子、实际不原子"的边界。而每一个这样的边界，都是一道能丢钱、能重复花钱、或者花了钱没人知道的缝。**

这不是 Agent 的问题，是分布式系统的基本性质。**只是以前跨这些缝隙的动作，通常由人守着——而现在不是了。**

---

## 五、为什么这个时代特别危险：人不在环里了

这才是整件事的关键。

**传统系统里，"人"是最后一个兜底环节。**

一个人点了"确认退款" → 系统处理 → 他盯着屏幕等结果。

如果中间掉链子，**他会发现**。因为他还坐在那儿等着。他会看到转圈、看到报错、看到没反应，然后重试或者找人。**这个"人还在等"的状态本身，就是一层容错。**

而 Agent 不是这样工作。

> **Agent 是"人只交代目标和边界，AI 负责规划、执行、处理异常"。**

它可以跑几个小时，可以并行开十几个子任务，可以在半夜三点自己继续。**它的整个价值主张，恰恰是"人不用盯着"。**

**于是那个"人还在等"的兜底环节，被这个价值主张亲手拿掉了。**

这就是为什么"能观测、能审计、能叫停"从一个"最佳实践"，在短短一年之内变成了"准入要求"。

它不是行业突然变得保守了。**是因为那个一直默默兜底的人，被优化掉了，但没有人把那个洞补上。**

---

## 六、所以政策说的其实是对的

今年 9 月发布的《人工智能安全治理框架 3.0》，最核心的变化是一句话：

> **治理对象从「内容安全」延伸到「智能体行为安全」——以前我们管 AI 说什么，现在我们要管 AI 做什么。**

它提了两条操作性要求，用大白话讲是：

- **「风险看得见」**：AI 做了什么、谁让它做的、经过哪些步骤，**全程留痕、可以追溯审计**
- **「管得住」**：出了问题能发现、能定位、能叫停，**人类随时可以踩刹车**

**我一开始觉得这是合规话术。做完上面那三个修复之后，我改主意了。**

因为场景三暴露的那件事，本质上是：

> **"钱已经退了"是事实，"系统里没有记录"也是事实。**

而在审计的意义上，**没有记录的事情等于没发生过**。但在钱的意义上，它已经发生了。

**这两个事实之间的错位，就是所有审计失效的根源。** 而"看得见"这三个字要解决的，正是这个错位。

还有一个容易被忽略的细节：**如果要问"谁让它做的"，那系统里就必须有一个关于"谁"的明确答案——不能是"模型的输出里说它是张三"。**

（这也是我们在做规范时反复强调的一条：**主体身份不能在多次跳转之后靠"重新贴个标签"来传递。**）

---

## 七、一个设计原则：记录不是动作的影子，记录是动作的一部分

最后说一个从这三个场景里提炼出来的原则，我觉得比具体修法更重要。

看这两个顺序：

**顺序 A（先记后做）**：先写下"我要做这件事" → 再去做。  
最坏情况：记了，没做。**后果是一笔冗余记录，人工可以发现、可以清理。**

**顺序 B（先做后记）**：先做 → 再记。  
最坏情况：做了，没记。**后果是钱真的走了，而且查不到。**

**这两个方向的失败代价，不对称得可怕。**

而工程上的本能反应，往往倾向于顺序 B。因为"先干正事，干完再记"看起来更自然、更快。**但在会动钱的系统里，这个直觉是错的。**

所以正确的设计是：

> **把"记录"纳入动作的原子边界之内，而不是让记录跟动作后面跑。**

上面三个场景的修法，本质上都是这一条：

- 场景一：把"审批决定"和"执行入队"放进同一个事务
- 场景二：把"结果未知"变成一等状态，而不是事后推断
- 场景三：把"任务终态"和"通知意图"放进同一个事务

**它们没有一个是在"加功能"，全都只是在让"记录"成为动作本身的一部分。**

---

## 八、留三个问题给你

如果你正在让 Agent 碰真实业务系统——不管它是退款、改价、发券还是改权限——建议问自己三件事：

**一、如果这个动作做完了，但进程在那之后一秒钟被杀，重启会怎样？**  
（会不会重做一遍？钱会不会再走一次？）

**二、"结果未知"在你的系统里是一个合法状态吗？**  
（还是你被迫在"成功"和"失败"里二选一？）

**三、三个月后要查一笔操作，你能回答"谁让它做的"吗？**  
（注意：是"谁让它做的"，不是"模型的输出里写了谁"。）

三个问题里只要有一个答不上来，就说明动作和记录之间还留着一条缝。

**而那条缝，迟早会有人从里面掉下去。**

---

*本文所涉三个故障场景，来自我们在维护百灵中枢（BailingHub，开源的 Agent-to-Business 控制面）过程中实际修复的问题。相关版本说明、升级指南与可靠性回归入口均在开源仓库中公开可查。*

*我们同时维护 ACC（Agent Capability Contract）——一份实现中立的能力声明契约，用来描述"一个业务动作，在什么条件下可以被执行"。*

退款已经打到用户账上，财务系统里没有这笔记录。任务已经执行完毕，上游业务系统还停在"处理中"。服务器明明返回了 200，数据其实一个字都没落盘。

Agent 动真实交易时，会怎么出错：三个真实故障场景的认知陷阱

人工智能

Agent落地失败多因系统无报错但钱出错：退款未记账、200响应未落盘、任务完成通知丢失。根因是“动作与记录”非原子操作，执行者不确定使幂等失效。必须将记录纳入动作边界，用“结果未知”状态兜底，确保可审计、可追溯、可叫停。

内容安全

服务器

智能体

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent 动真实交易时，会怎么出错：三个真实故障场景的认知陷阱-腾讯云开发者社区-腾讯云

Agent 动真实交易时，会怎么出错：三个真实故障场景的认知陷阱

Agent 动真实交易时，会怎么出错：三个真实故障场景的认知陷阱

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐