我在四个生产环境 AI 代理运行中途让它们崩溃了。结果它们都没有记录下已经完成的工作。

在构建 agent 的过程中，我反复遇到同一个问题，于是我没有继续争论，而是去别人的代码里做了实测。四个公开的 agent 代码库，每个都锁定在一个特定 commit，每个都在执行动作的中途被强制终止，然后以 supervisor 或 worker pool 的方式重试。没有任何重新实现。如果必须做替换，我使用的是项目自身文档化的扩展点。计数来自一个账本（ledger），假服务在响应之前会对账本执行 fsync，所以一个在执行完动作后立刻崩溃的进程仍然会被计入"已执行"。整个过程从不询问 agent 自己做了什么。 结果如下： **Cua（computer-use）**：在结账过程中杀掉进程，重试后会再次扣款。在两个崩溃位置，每一次运行都是如此。分别在 cua-agent 0.8.4 和 0.9.0 上测试，结果完全一致。 **Skyvern**：步骤执行期间任何进程死亡都会导致任务永远停留在 running 状态。既不是 failed，也不是 errored，所以失败告警根本不会触发。唯一的出路是发起一次新的运行，而这会导致再次下单。 **Corsair**：两个副本共用同一个轮换的 OAuth refresh token。崩溃会导致存储的凭证损坏，每一次运行都是如此，用户必须重新连接集成。 **Inconvo**：一次被中断的回答会多花 60% 的模型调用费用，因为 checkpointer 记录的是图节点（graph node），而不是其下面的十五次模型调用。其中三次是崩溃导致的失败。 Corsair 则是另一种情况：没有任何东西崩溃，两个副本只是碰巧在同一时刻都去取了同一个 token。问题不同，但缺失的部分是一样的。 四种不同的失败，一个共同的原因：**它们都没有记录哪些动作已经完成**。重试时是一个全新的进程，历史为空，所以它会把工作重新做一遍。 在这个过程中我读到的最有价值的东西是 arXiv 2609.29095，该论文用 25,930 个 agent episode 对照已提交效果（committed effects）的账本进行评分。在 90% 的重复执行了效果的 episode 中，agent 自己报告为成功。所以你不能去问 agent，而任何基于自述 trace 进行评分的基准测试，都会把"重复执行了并且还撒谎了"的案例算作通过。 有一件事我不会声称已经解决：如果进程在动作落地和记录提交之间死亡，它仍然会重复执行。效果和记录存在于不同的系统中，没有任何东西能弥合这个缝隙。这也是那些报告零重复率的基准测试悄悄排除掉的那一行——它们只在已经提交的边界处制造崩溃。 测试框架和原始账本都是公开的，不需要 API key，因为所有调用都指向一个本地假服务。如果有人需要，我很乐意在评论区提供链接。 **披露**：我在这个问题上构建了一个运行时（runtime），所以我并非中立一方。每个案例中被测的都是他们的代码在某个锁定 commit 上的版本。 有两件事我是真心想知道的： 如果你同时运行多个 agent 操作共享状态，到底是什么阻止它们执行相同的动作？我在实践中见过的所有答案都是：锁、去重表、或者什么都不设。我想知道是否存在第四种方案。 另外，如果你运行的 agent 涉及资金操作或对外发送东西，你目前是如何处理重试的？是自己传入密钥（幂等键），还是干脆接受偶尔出现的重复操作？