如何保障 Agent 系统稳定性？

核心回答

Agent稳定性要同时看两件事：服务能否在资源和时限内完成运行，任务是否真正达到要求。接口返回成功，只说明调用链没有以错误结束，不代表答案或操作正确。

我会重点做好五项：

1. 明确成功与停止条件：定义任务完成标准，以及失败、等待、取消和预算耗尽的状态。
2. 控制外部依赖：模型和工具设超时、并发限制及有限重试，持续故障时降级或停止调用。
3. 约束执行循环：校验工具参数与结果，限制步数、费用和总时长，检测重复无效动作。
4. 保存和恢复任务状态：保留必要检查点与产物，处理重复执行、取消和外部副作用。
5. 用观测与回归持续验证：关联模型、提示、工具和流程版本，跟踪任务结果、延迟、错误与成本，发布异常时可回退。

先覆盖真实任务的主要故障路径，再按并发量和任务重要性增加机制，不是把所有中间件都开启就算稳定。

展开说明

1. 先区分服务故障和任务失败

模型请求可能超时、限流或返回错误；即使请求正常，也可能选错工具、漏掉步骤、误读证据或交付损坏文件。因此要分别观察依赖可用性和端到端任务完成情况。

例如生成报告，除了模型接口成功，还要看报告是否覆盖要求、结论是否有依据、文件是否可读取。视频流程则可以结合实际要求检查音画同步、分辨率和字幕等结果。评价规则从业务交付出发，不能只用“有一段回答”作为成功。

2. 依赖调用需要总时限、分类重试和负载保护

连接、请求与流式等待的超时应与整项任务的截止时间配合，避免每层各等一遍，累计远超用户可接受范围。模型服务、工具接口和连接池的并发容量也要有限；高负载时排队、限制接入或尽早返回明确状态，不能无限堆积等待任务。

瞬时网络错误、限流或部分服务错误，可以在可重试且预算允许时退避重试，并加入抖动，避免大量请求同时冲击下游。参数错误、无权限或确定性业务拒绝，不应原样反复请求。明确主要重试层，避免SDK、工具包装和Agent外层都各重试多次，放大调用量。

依赖持续失败时，可以暂停该路径、使用满足契约的备用实现，或交付受限结果。备用模型要能处理相应上下文与工具格式；缓存资料也要符合时效要求。不能用“成功返回了”掩盖能力缺失或旧数据。

3. Agent循环要能识别无进展并正常收束

工具名、参数、权限和关键结果由程序检查，明确区分合法空数据、部分结果与异常。可计算、可解析或可检查的条件，尽量用相应程序验证；开放性答案再按证据和任务要求评估。

设置单步和总预算，记录累计调用、费用及剩余时间。重规划、子Agent和修正调用都计入同一任务预算，不能通过创建新子任务逃掉限制。连续重复同一动作、没有新证据或无法满足前置条件时，应改变策略、请求必要信息或结束，而不是无限“再试一次”。

例如搜索工具持续超时，有限尝试后仍不可用，可以换成允许的等价来源；若没有可靠替代，就保留已验证材料，明确缺失部分。不能把空结果改成一段看似完整的结论。

4. 状态恢复不能制造重复操作

长任务保存当前阶段、已确认结果、产物引用、预算和失败原因，恢复时从明确边界继续。需要跨进程恢复就使用适当持久存储；InMemorySaver只保存进程内状态。

检查点与外部系统之间仍有空隙。例如建单已成功但回执未保存就宕机，恢复后应通过业务幂等标识或查询原操作确认状态，不能因为本地还显示未完成就再建一单。超时也不证明外部动作没发生，重试和备用路径都要考虑这一点。

并行分支分别保存结果，再按规则归并，避免旧结果覆盖新任务状态。取消需要传递给在途模型、工具和子任务；对无法及时取消的外部动作，应记录状态并核对结果。前端断线和任务取消是不同事件，要由产品和执行策略明确处理。

5. 通过追踪、故障验证和版本管理持续改进

一次运行应能关联用户范围、任务、步骤和尝试，以及模型配置、提示、工具Schema和流程版本。记录必要输入摘要、结果引用、状态、错误、耗时与消耗，定位是依赖故障、参数问题、上下文缺失还是结果误读。内容记录按权限和脱敏策略处理，不需要把所有对话原文无差别写入日志。

指标至少覆盖任务完成、模型与工具错误、超时、P95延迟、队列积压、取消后消耗和每项任务成本，并按任务类型和版本观察。将真实失败加入回归集，针对限流、超时、重复提交、中途崩溃、取消及旧状态恢复等受影响路径验证；高并发场景再检查容量和排队。

发布对象包括代码、模型、提示和工具契约。先比较代表任务，再按场景逐步放量；在途任务继续使用兼容版本或在明确边界迁移。回滚配置不会自动撤销已经发生的外部操作，必要的查询、补偿和人工处理还需另行执行。

常见追问

temperature设为0就稳定了吗？

可以减少某些生成变化，但不能保证完全确定，更不能解决接口超时、检索错误、状态竞争和重复副作用。稳定性要覆盖整个执行与交付过程。

所有失败都重试，成功率不是会更高吗？

不会。不可修复参数和权限错误可能一直失败；下游过载时重试还会扩大故障；有副作用的请求可能重复操作。先分类，再按幂等性、剩余预算和依赖状态决定重试。

如何判断降级是有效的？

看它是否仍满足最低交付要求，并清楚表达降低了哪些能力。任务完成率、错误副作用、延迟和成本都要对照。只把错误吞掉、返回空字符串或编造答案，不能算可靠降级。

对应教程

参考资料