Agent 防重复扣款，关键在执行架构

Agent 重复扣款，可能只是因为一次超时：支付平台已经收到了请求，响应却在断线后丢失，编排器于是重试。作者借这个场景提出一个判断：换成 Rust，解决不了远程操作到底有没有成功的问题。

这篇短文的价值，是把内存安全、并发正确性和分布式执行正确性分开。对正在做 AI 工具调用的程序员来说，先分清故障属于哪一层，比先决定用什么语言重写更有用。

为什么超时之后，不能直接再付一次

作者给出的故障链条很具体：Agent 发起支付，支付平台接受请求，连接在响应返回前断开，工作进程等待超时，编排器再次发起请求，最终客户被扣了两次钱。

问题在于，本地看到的「超时」，无法证明远端没有完成操作。

Rust 的所有权模型能在安全代码中消除释放后使用（use-after-free）和数据竞争，却无法知道断线之前，远程 API 到底执行到了哪一步。这里缺少的是跨网络的执行证据。

超时是一种结果未知的状态，不能直接当成操作失败。

作者提出的处理方向包括持久化状态、幂等性和恢复协议。持久化状态用于留下可恢复的记录；幂等性要让重复请求不会造成重复业务效果；恢复协议则需要区分两类操作：只读搜索可以安全重试，支付这类操作需要核对执行结果，再决定下一步。

不过，给出的短文没有展开状态结构、幂等标识或具体核对流程，只提到完整文章还会讨论状态存储、队列、工作进程与恢复设计。不能把这些关键词当成已经交付的完整方案。

换成 Rust，速度收益可能没有想象中大

作者用一组示例数字说明：Agent 的耗时未必集中在编排代码里。

一次执行包含：

• 4 次模型调用，每次约 800 ms。
• 6 次工具调用，每次约 150 ms。
• 100 ms 的编排开销。

按这些耗时相加，总计约 4200 ms。即使把编排开销完全消除，也只节省约 2.4%。

这不是一次 Rust 与其他语言的性能对照测试。作者明确将它称为示例运行，作用是提醒读者先看耗时构成：如果时间主要花在等待模型和工具响应上，单纯加速本地代码，整体收益就有上限。实际改写也不可能自动消除全部编排开销。

作者更看好 Rust 在并发方面的价值：在固定内存预算下，一个工作进程能承载多少 Agent 会话，同时保持可接受的尾延迟，也就是最慢那部分请求的响应时间。

这里仍然没有提供实测对照数据。它提出了值得测量的指标，没有证明某个具体系统换成 Rust 后一定能承载更多会话。

我的判断

我赞同作者把三种正确性拆开讨论：Rust 保障安全代码的内存安全，帮助处理并发正确性，分布式执行正确性则要靠架构解决。这能避免团队把语言迁移误当成支付可靠性方案。

但文章中的两个论据需要分别看待。重复扣款场景解释了一个明确的故障机制；2.4% 则依赖给定的示例耗时，不能套到所有 Agent 系统。对于本地计算或编排逻辑占比较高的系统，需要重新测量。

同样，Rust 的并发优势在这里属于作者的工程判断，缺少相同负载、内存预算和尾延迟要求下的对照结果。它足以支持一次性能评估，还不足以支持一次重写决策。

相比直接迁移语言，先检查现有实现里的重试策略，并测量耗时、内存和尾延迟，更容易找到真正需要改动的位置。

能拿来做什么

• 如果你在 Node 服务中编排 AI 工具调用，先按操作性质检查重试策略。将只读搜索与支付等有业务副作用的操作分开处理，别让一个通用重试包装器决定所有失败后的行为。
• 为支付调用检查三件事：执行状态是否持久化、重复请求是否具备幂等保障、超时后是否有结果核对与恢复流程。不要仅凭异常信息就再次提交支付。
• 评估 Rust 迁移前，先记录模型调用、工具调用与编排代码各自的耗时；如果目标是提高并发承载量，再比较固定内存预算下的会话数量和尾延迟。