AI代理需要可替换——且不丢失你的工作
内容提要
文章讨论AI代理崩溃后的恢复问题：代理执行退款等操作时若中途崩溃，替代代理可能自行推理并重复退款。解决方案是将业务操作（金额、授权、幂等键、状态）持久化到事务存储，工具边界依据该记录校验请求，替代代理继承原操作而非重新决策。结合ClickHouse统一存储业务数据、遥测与追踪，可关联操作与执行证据。结果不明时应升级处理，存储的批准仅是历史证据，需重新验证当前权限。
延伸解读
代理崩溃后的重复退款风险
文章指出，代理在退款操作中崩溃后，替代代理可能基于相同请求重新推理，选择不同参数或发起新退款，导致重复退款。与常规工作流不同，代理的自主推理使其不会自动从检查点恢复，而是可能重新决策。因此，必须将业务操作持久化，让替代代理继承原操作而非重新解释。
持久化操作记录与工具边界校验
解决方案是在派发退款前，将批准金额、授权、幂等键、操作标识和状态提交到事务存储。工具边界依据该记录校验每个出站请求，确保只有原始参数和身份的操作能到达支付提供商。这样，模型无法重新定义已批准的操作，替代代理只能继承而非重新生成。
统一存储关联操作与执行证据
ClickHouse统一存储业务数据、应用遥测和代理追踪，使操作ID能同时出现在Postgres行、Langfuse追踪属性和日志上下文中。通过单一标识符查询，可关联操作、代理运行和失败的HTTP调用。但替代代理必须从Postgres读取权威记录，而非CDC复制的副本，因为复制有秒级延迟。
结果不明时升级而非猜测
当支付结果不明时，替代代理应利用Langfuse和ClickStack的只读工具调查，但追踪不能证明提供商已提交退款，缺失追踪也不证明请求未发送。存储的批准仅是历史证据，需重新验证当前权限和账户状态。若结果仍不明确，应升级处理，而非猜测重试。
Q&A
AI代理执行退款时崩溃，为什么替代代理可能造成重复退款？
因为替代代理会自行推理，可能制定不同计划、选择不同参数或决定发起新退款，而不是继续已批准的操作。如果原退款已成功，第二次尝试就会导致重复退款。
如何确保AI代理崩溃后替代代理能安全继承原操作？
在派发操作前，将业务操作（金额、授权、幂等键、状态等）持久化到事务存储。替代代理检索该记录并继承已批准的操作，而不是重新生成。工具边界依据该记录校验所有出站请求，确保只有原始参数和身份的操作能到达提供方。
持久化操作记录中应包含哪些关键信息？
包括已批准金额、适用的授权、发送给支付提供方的幂等键、应用在提供方元数据中的操作标识符，以及状态（从created到dispatched，再到confirmed或failed）。
ClickHouse在代理恢复中起到什么作用？
ClickHouse Managed Postgres存储业务数据（包括权威操作记录），通过CDC复制到ClickHouse。应用遥测和代理追踪也存入同一ClickHouse服务，使得通过单一标识符查询即可关联操作、代理运行和失败HTTP调用，简化调查。
当退款结果不明确时，替代代理应该如何处理？
替代代理应使用只读工具（如Langfuse MCP查询代理追踪、ClickStack MCP搜索服务事件）调查证据，缩小失败窗口。但追踪不能证明提供方已提交退款，支付提供方仍是权威记录。若结果仍不明确，应升级处理而非猜测。
为什么存储的批准不能直接作为替代代理的行动依据？
存储的批准仅是历史证据，不是当前行动授权。替代代理必须重新验证当前权限，因为可退款余额可能变化、人工代表可能已处理退款、账户状态可能改变或授权可能被撤销。
