AI Agent 需要可替换——同时不丢失工作成果
这篇文章讲的是：当负责处理退款的 AI Agent 中途崩溃时，如何让接替它的新 Agent 安全接手，而不会重复退款。原来问题在于，Agent 会自己推理、临时决定，崩溃后新 Agent 可能重新想一套方案，甚至再退一次款，导致用户被退两次钱。作者的做法是：在发起退款前，先把这笔操作的金额、授权、幂等键和状态写进数据库（相当于先立一张可查的“操作底账”），新 Agent 只能继承这张底账，不能自己改写；支付接口前还有一层校验，只放行记录里已授权的操作。这样即使崩溃，也能靠同一个幂等键和操作编号查清到底发生了什么，避免重复退款。对读者的用处是：如果你在生产环境跑 Agent 处理支付、订单等有副作用的操作，可以用“持久操作记录+幂等键+边界校验”的思路提升可靠性。文中提到的 LangGraph、Temporal 能恢复执行，但不能判断外部是否已成功；Langfuse 和 ClickStack 可用于追溯，但都只是辅助证据，最终以支付方记录为准。
文中可用工具
- ClickHouse Managed Postgres存放业务数据和权威操作记录
- ClickStack查询应用遥测和日志
- Langfuse查看 Agent 调用链和工具调用记录
- LangGraph持久化执行进度并在失败后恢复
- Temporal持久化执行进度并在失败后恢复
- Langfuse MCP server让 Agent 按操作 ID 查询此前的调用链
- ClickStack MCP server让 Agent 检索同一时间窗口内的服务事件
评论 · 分享第一个看法