Agent 链路可靠性：把重试写成状态机

工具循环的可靠性可以从两个数开始：单步成功率 $p$ 和步数 $n$。若各步独立，整条链一次完成的概率为：

$$P_{\text{chain}} = p^n$$

$p=0.95$、$n=8$ 时约为 66%。这意味着系统必须有检查点或重试，否则长任务会频繁失败。

重试的副作用

单步失败后重试 $r$ 次，预期调用数增加。如果写操作没有幂等键，重复执行会产生第二笔订单、第二个文件或第二次通知。粗略风险暴露可以写成：

$$R \approx (1-q)(1-p)r$$

其中 $q$ 是幂等覆盖率。

最小控制集

• 总截止期与单步超时；
• 最大步数与最大重试数；
• 所有外部写操作的幂等键；
• 成功、失败、未知三种状态；
• 可恢复检查点与补偿动作；
• 包含 request id 的审计日志。

打开 工具循环预算 比较参数。把幂等覆盖率降到 50%，观察风险指数如何变化；再把重试次数提高，观察它并不必然提高业务成功率。

结论不是“Agent 不可靠”，而是“可靠性必须被显式设计”。模型的规划能力不能替代执行层的状态机。

一个工具环的可靠性模型

工具循环可以看成串联系统。如果一次任务需要经过 $S$ 个独立步骤，每一步成功率为 $q$，那么整条链路的成功率为：

$$P_{\text{chain}} = q^S$$

当 $q=0.95$、$S=8$ 时，成功率约 66%。这意味着每一步看起来都很可靠，但链路会积累失败。重试能改善单步成功率，却会增加调用次数和副作用窗口。为了不把一次网络抖动放大成重复写入，写操作必须带幂等键，并在执行前查询是否已经完成。

实验中的四个输入分别代表：

• 步数：任务需要调用的工具数量；
• 单步成功率：工具返回可接受结果的概率；
• 重试次数：每步失败后最多再调用几次；
• 幂等覆盖率：写操作中有多少比例能够安全重放。

读风险指标

“链路成功率”是串联模型的保守估算，假设步骤独立且没有中途修复；“预期工具调用”用来估算预算和副作用窗口；“重复副作用暴露”不是攻击成功率，而是提示未幂等写操作在重试下的相对风险。若重试次数增加但链路成功率没有明显上升，说明失败并不是瞬时的，继续重试只是在消耗预算。

一个安全的默认策略是：

1. 读操作可以有限重试；
2. 写操作必须幂等或有补偿；
3. 总截止期到达时停止循环；
4. 未知结果交给用户确认；
5. 每一步写审计摘要，而不是只记录最终错误。

实验边界

这个模型没有模拟模型规划错误、并发任务、工具返回的结构化程度和多租户权限。它也无法预测某个提示注入是否会成功。它适合比较“增加重试”“提高幂等覆盖率”“减少步数”对风险暴露的方向性影响，不适合作为安全认证。真实系统还需要在隔离环境做故障注入和攻击测试。

使用实验时，先固定业务截止期，再调整幂等覆盖率与重试；不要反过来用一个漂亮成功率掩盖无限循环或重复副作用。Agent 的可靠性来自可观测、可停止和可恢复的执行器，而不是来自更乐观的概率假设。

从数字到执行器

如果把风险指数从 20% 降到 5%，必须要能指出下降发生在哪里：是减少了步骤、提高了单步成功率、增加了幂等，还是缩短了重试窗口？不同改动对应的工程成本完全不同。减少步骤可能需要重写任务分解；提高单步成功率可能需要更可靠的工具；幂等需要服务端支持；缩短截止期可能牺牲完成率。实验只能帮你排序，不能替你决定业务上可接受的交换。

一个最小的可靠执行器可以先实现三件事：每一步有超时；每次写操作有唯一幂等键；任何未知状态都进入人工恢复队列。然后再增加重试、并行和补偿。顺序反过来，先追求“自动完成”，往往会把不可观测的副作用藏进日志里。把失败当成正常状态处理，才是 Agent 工程成熟的标志。

当任务可以由多个 Agent 并行时，还要防止共享资源和重复认领。每个工作单元需要独占租约、可见状态和取消信号；上游不能只根据“已经发出指令”推断下游完成。实验页的串联模型是基础，真实系统还要补上分布式一致性、消息幂等和人工回滚流程。

如果要把实验放进面试题，可以要求候选人先解释为什么每一步 95% 成功率的链路仍然会失败，再设计一个带截止期和幂等键的执行器。比背出“多试几次”更有价值的，是能说明重试何时安全、何时必须停止，以及如何证明副作用只发生一次。

测试时不要只给工具返回成功和失败，还要构造“超时但已执行”“重复请求”“返回 schema 被污染”等状态。只有这样，可靠性模型才会覆盖真实系统最危险的部分。

把未知状态显式暴露给调用者，往往比自动猜测更安全。

执行器的可停止性、可恢复性和可审计性，最终比任何单次成功率数字都更能决定 Agent 能否进入生产。

把这三项能力做成默认组件，而不是每个项目临时补丁。