Agent 可靠性要从控制回路设计，而不是准确率补丁开始

type

Post

status

Published

date

May 7, 2026

slug

pub_topic_20260506_agent_reliability_control_loops_001_notion_001

summary

生产级 agent 的可靠性不是单步准确率竞赛，而是控制回路设计：重试预算、幂等、死信、交接、失败分类和可回放状态，决定多步链路能不能扛住真实运行。

从准确率到控制回路

很多人把 agent 可靠性理解为「让模型更聪明一点」，但这只是冰山一角。真正的可靠性在于系统如何处理失败、约束副作用和管理状态。一个能上线的 agent 工作流，至少要回答五个关键问题：

什么时候重试，最多重试几次？

重试没有预算，就会把短暂抖动放大成资源消耗。系统需要有明确的重试策略：重试次数限制、指数退避、抖动控制，以及最重要的——退出条件。

哪些动作必须幂等，如何记住第一次现实？

写操作不做幂等，就会把一次不确定变成多次真实副作用。系统需要识别哪些操作可能产生副作用，并确保这些操作在重复执行时不会造成意外的结果。

失败任务如何隔离和回放？

没有死信区，连续失败的任务会反复占用热路径。失败的任务应该被移出主流程，在合适的时候被重新处理，而不是不断重试同一个问题。

人类或其他 agent 接手时拿到哪些检查点？

当需要人工介入时，系统应该提供足够的上下文信息。这包括当前状态、已执行的操作、待完成的任务，以及失败的具体原因。

系统如何区分真实失败、正常截断和外部限流？

工具返回被截断、权限失败、网络超时、业务拒绝如果被混成同一种失败，系统就无法判断该重试、回滚、交接还是停止。需要精细的失败分类机制。

可靠性的控制回路组件

重试预算（Retry Budget）

不是简单地无限重试，而是有预算控制的负反馈。每次重试都要消耗预算，预算耗尽后需要降级或人工介入。这避免了一个小的抖动耗尽整个系统的资源。

幂等约束（Idempotency）

对于可能产生副作用的操作，必须确保多次执行的效果与单次执行一致。这需要系统记住「第一次现实」，后续操作基于这个现实进行验证和约束。

死信处理（Dead Letter Queue）

无法正常处理的任务应该被路由到死信区，而不是阻塞主流程。死信区的任务可以被定期检查、人工分析或降级处理。

交接机制（Handoff）

当系统无法继续处理时，需要有清晰的交接机制。包括状态快照、上下文信息、失败原因，让其他 agent 或人类能够接手处理。

失败分类（Failure Classification）

不是把所有失败都当成错误，而是进行精细的分类：

真实失败：系统问题，需要修复

正常截断：预期的边界情况，需要调整逻辑

外部限流：暂时不可用，需要重试或等待

为什么 verifier 不是可靠性主体

verifier 有价值，但它不是可靠性的主体。它只能在某个时刻给出判断，不能替代状态机、退出条件和副作用管理。真正决定生产质量的是负反馈回路：失败能被分类，动作能被约束，状态能被回放，错误不会无限传染。

verifier 的边界

它能检查结果，但不能替代控制面

它能评估质量，但不能修复系统问题

它能发现问题，但不能预防失败发生

控制回路的优势

能处理未预期的失败模式

能在系统负载变化时自动调整

能在问题发生后快速恢复

能提供可预测的系统行为

核心判断

把 agent 可靠性押在更强模型或更多 verifier 上，会低估生产系统里状态、退出条件和副作用管理的决定性作用。真正的可靠性来自于精心设计的控制回路，而不是简单的准确率竞赛。

小系统的实用建议

即使是小规模系统，也需要考虑这些可靠性组件：

重试预算：避免无限重试消耗资源

幂等设计：防止重复操作产生副作用

死信区：失败任务不要阻塞主流程

清晰的失败分类：知道该什么时候重试，什么时候放弃

状态快照：支持任务交接和故障恢复

记住：生产环境的可靠性不是理想状态，而是失败管理能力。

---

*这篇文章从控制回路的角度重新定义了 agent 可靠性，强调了比模型能力更重要的状态管理和失败处理机制，为生产级 agent 系统提供了实用的设计指导。*