为智能体构建安全的交付流水线
大多数智能体演示都忽略了一个至关重要的问题：如何让自主系统代表你发送内容，而不会导致重复发送或发送未经批准的工作？
重复发送并非罕见错误。当工作进程在任务中途崩溃时，这是简单队列的默认行为。一个工作进程发送了消息，但在记录成功之前崩溃了。系统认为任务失败，并指示一个新的工作进程重试。结果客户收到了两封邮件，而你收到了一个支持工单。
你无法防止每一次崩溃。你必须针对“执行动作”与“记录结果”之间的时间差导致的崩溃进行设计。
对于任何具有实际后果的智能体输出，请使用这个六阶段流水线：
• 生成 (Produce)：智能体生成完整的产物。此时尚未发送任何内容。 • 持久化 (Persist)：首先将意图和产物写入持久化存储。 • 评分 (Score)：为输出附加一个置信度分数。 • 审核 (Review)：将低置信度的项目路由给人工处理。 • 批准 (Approve)：使用“故障关闭 (fail-closed)”闸门。除非人工给出明确授权，否则系统会拦截所有发送行为。 • 发送与证明 (Send and Attest)：在租约 (lease) 机制下发送项目，然后写入证据收据。
每个阶段必须是一个独立的持久化转换。状态应存储在数据库中，而不是工作进程的内存里。
为了防止重复，请使用行级租约 (row-level leasing)。在 Postgres 中，使用 SELECT ... FOR UPDATE SKIP LOCKED。这可以确保一次只有一个工作进程拥有该任务。
最重要的规则是如何处理过期的租约。如果工作进程在发送外部消息时崩溃，不要自动重试。相反，应将该任务挂起以供人工审核。一个可见的卡住的任务，比一个隐形的重复发送要好。
你还必须遵循“故障关闭 (fail-closed)”原则：
- 发送默认关闭。必须通过单个标志位才能启用所有出站流量。
- 身份验证。系统必须在发送瞬间验证发送者地址和传输安全性。
- 每项操作都必须留下收据。未记录的发送即视为失败。
不要为内部日志等低风险任务构建此流程。仅在错误会导致金钱损失、引发法律问题或产生支持工单时使用它。
Optional learning community: https://t.me/GyaanSetuAi