一位开发者在 V2EX 分享了多 Agent 编排流程中遇到的一个边界问题。作者此前将多 Agent 编排流程封装成中英文两个可安装的 skill 发布，随后有用户在讨论区提问：收件器将 ack 延后到整批消息处理完才发送，保证一批中只要还有一条未处理完，就不会冲掉后面的消息；但如果某个动作已经执行完毕——合并了 PR、回了消息、改了文件——而进程在记录「已完成」之前崩溃，这一批仍处于未 ack 状态，动作效果却已落地。作者起初认为脚本层已做原子落盘（临时文件 fsync 后再 rename）足以应对，思考后才意识到：落盘保证的是不丢，提问指向的是不重复，两者在崩溃窗口内并非同一件事。作者随后梳理了原方案的边界：脚本提供 at-least-once 投递，批次原子落盘，按 message ID 去重，只自动 ack 纯心跳批次；它保证不丢、不重复唤醒、不丢证据，但「效果只发生一次」不在保障范围，而旧文档的写法让人误以为它管。为此作者做了三处修改：一是将 processing 状态的台账写在动作执行之前，注明动作与尝试次数；二是恢复时对卡在 processing 的记录先查真实状态——合并查 PR、回复看回执、文件改动读文件本身，据证据而非台账判断；三是效果无法从证据确立的交给人类，不盲目重跑。此外还补充了一个评测场景作为测试兜底。
事件分析
这篇文章触及分布式系统中的经典难题——exactly-once 语义在崩溃窗口内无法同时保证「不丢」与「不重复」，最终仍需依赖幂等设计或外部状态核验。作者提出的「先写意图、再执行动作、凭证据恢复」思路，本质上借鉴了数据库预写日志（WAL）与业务幂等键的成熟实践，并将其迁移到 Agent 编排场景。随着 AI Agent 从演示走向生产环境，消息投递语义、崩溃恢复、状态核验等工程细节正成为落地质量的分水岭。文中「证据优先于台账」的恢复策略，以及无法判定时交由人类兜底的设计，代表了当前 Agent 可靠性工程的务实路线。后续值得关注的是：此类模式能否沉淀为通用编排框架的内置能力，以及评测体系能否覆盖更多真实崩溃路径，而非仅停留在文档约定层面。
核心观点：Agent 编排无法靠设计消除崩溃窗口，只能靠证据核验与人类兜底，把「未承诺的事」诚实圈进边界。
原文链接：V2EX 分享发现
评论前必须登录！
立即登录 注册