多数 AI Agent 框架只教两种结果：成功或失败。但在生产环境中，vertciti 创始人 Jiahui Miao 指出还有第三种状态：Unknown。请求已经发出，执行进程退出，没有人能证明外部操作是否发生。把它当失败重试，可能重复发帖、重复发邮件、重复扣款；把它当成功跳过，又可能静默丢失任务。作者认为，正确动作不是立即重试，也不是继续，而是 reconcile：先读回外部世界，确认发生了什么。
进程更替让长任务失去安全窗口
作者测量了自己运行个人 AI 的 worker 集群。72 小时内，执行任务的 worker 经历了 30 代更替；这是按运行时间戳测得的下限。每一代的中位存活时间约 2 小时，最短约 22 分钟。系统不存在一个足够安静、能让长任务完整跑完的窗口。
10 月底，两次长发布调用在执行中被进程更替中断，返回 unknown。任务并不能被证明失败，只是执行时间超过了执行者的存活时间。
盲目重试会重复执行副作用
增加重试、指数退避、直到成功，这类建议默认失败等于“没有发生”。这对读取操作通常成立，对带副作用的操作却不成立。当发帖、支付或邮件正在执行，调用方进程退出后，“没有发生”和“已经发生但回执丢失”从外部看几乎相同。
盲目重试会把两种情况压缩成同一个动作：一种是补救，另一种则会造成重复副作用。作者提到，Stripe 对未知结果的指引是先核对实际状态，而不是立即再次发起请求。反向错误同样存在：因为大概率成功就标记完成，可能让未发出的内容、未落地的备份被显示为已完成。Unknown 应该有独立处理分支，动作不是 retry，也不是 continue，而是 reconcile。
工业系统给出的共同结构
作者观察到，Temporal、Cloudflare Workflows、DBOS 和 LangGraph 四个系统走向了相似结构。这更像问题本身的形状，而不是厂商功能选择。
- 状态保存在比执行进程更持久的地方。
- 工作切成小步骤，每一步结果先写入记录，再进入下一步。
- 恢复时读取记录，跳过已完成部分，而不是重新开始。
但副作用与检查点记录并非原子操作。进程可能在外部世界已经改变、记录尚未写入时退出，于是再次进入 unknown。因此，仅有记录不够，副作用本身必须可安全重入：例如接收方承认的幂等键、可读回的草稿状态，或可对账的回执。作者还指出，跨系统不存在真正的 exactly-once delivery；可行的是 at-least-once delivery 加去重。
缺少的不是框架，而是纪律
作者发现，自己的系统已经在手工实现类似机制：watermark 是检查点，ledger 是事件历史，任务必须读回目标状态后才能报告完成。缺少的不是框架，而是把纪律写明：每一步都留下磁盘记录，说明尝试了什么、用了什么 key、有什么证据；预计超过约 20 分钟或带不可逆副作用的任务，从一开始就按这种方式设计。短且可逆的任务可以豁免，因为持久化有固定成本。
他由此提出三个问题：每一步是否会落盘？每个副作用是否可以安全重入？当结果 unknown 时，系统是否先核对再重试？评论区中，Auten 团队补充，如果副作用通过无 API 的 UI 完成，没有幂等键和回执，读回会更难。他们的做法是，点击前先记录成功后的屏幕应显示什么，例如信息流中的帖子或已发送列表中的消息；重试前，先检查这些目标是否已经出现。
对进入真实业务的 Agent 来说，可靠性不只是系统是否聪明，而是每一次外部动作都要可追踪、可核对、可重入。面对未知结果，先核对再行动，才能避免重复损失和静默失败。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-ai-agent-bu-zhi-dao-cao-zuo-shi-fou-cheng-gong-xian-du
