我搭了一个多智能体系统来运营一家小公司。智能体负责起草工作，部分产出会直接发送出去——给真人发邮件、导出文档、交付成品。后来因为市场原因，我把这家公司关掉了，但整个交付管道如果重做一遍，我不会动一行代码。它解答了一个大多数智能体演示都避而不谈的问题：如何让一个自主系统以人的名义发送内容，同时绝不重复发送、不误发、不发出任何未经批准的东西？

这篇指南就是把这个模式提炼出来，剥离掉它当年跑的业务。适用于任何让智能体产出关键交付物的场景——客户邮件、外发消息、导出记录，所有“发两次”或“未经签字就发”都不是表面bug、而是会造成实际损失的事。

打开网易新闻 查看精彩图片

一句话概括：把每一个对外操作都处理成一笔持久化、带租约、故障即阻断的交易，加上人工审批闸门和证据回执，同时让崩溃恢复路径默认拒绝重发。这篇文章就是把这句话彻底拆开。

一个发邮件的智能体为什么会把邮件发两次？重复发送不是罕见的边缘案例。一个裸用队列的系统，当第一个工人进程在发送中途挂掉，重复发送就是默认行为。工人领取一个发送任务，把邮件交给邮件服务器，然后被杀掉——内存溢出、一次部署、一次重启——就在它写下“完成”之前。任务看起来仍未完成，于是下一个工人取走任务，再发一次。客户收到两封邮件，你收获一张工单。

下面每一条安全交付决策的存在，都是为了封住这个时间窗口。这不是运气问题，是结构性问题：最大的危险窗口，存在于“副作用已经在外部世界发生”和“系统记录下它已经发生”之间的间隙。进程恰好在这个间隙崩溃，重试就成了重复。你无法将这个间隙缩短为零，所以你只能设计系统，让它在这个间隙里崩溃时依然不出错。

这个受控交付管道由六个阶段串成一条主链。规则很明确：任何一项有后果的发送，都不能跳过审批闸门、单次发送闸门和证明闸门。打分和复核这两个阶段用来决定哪些项目需要人类优先审阅，而不是用来卡住每一次发送。六个阶段，每一步都在下一步开始前确保持久化完成。

第一阶段，生成。智能体把制品完整生成出来——如果是邮件，就是一份完整的RFC 5322格式邮件——并暂存。生成阶段绝不内联发送。第二阶段，持久化。在离开进程之前，先将发送意图写入持久化存储，包括暂存的制品、一条队列记录和一份回执。如果在这一阶段崩溃，意图依然存留，可以随时检查。

第三阶段，打分。给输出挂上一个置信度分数。这是用来指导复核路由的，不是让它单独充当闸门。第四阶段，复核。将低置信度的项目路由到人工复核队列。高置信度项目也不能绕过下一阶段。第五阶段，审批。一个故障即阻断的审批闸门。发布动作默认阻塞，只有获得明确的、被记录的授权才能继续。第六阶段，发送并证明。在租约保护下恰好发送一次，然后对账并写一份证据记录。