2026年10月20日｜无人值守 Agent：上线前应验证的七类失败场景

从“能完成任务”到“出错后仍可控制”

一次顺利演示，通常只展示了 Agent 能走通哪条路径。无人值守运行面对的是另一组问题：服务不可用时会不会无限重试，审批之后任务内容改变了怎么办，外部动作已经发生但本地状态丢失后会不会重复执行？这些问题不能只看最终回答，需要观察执行过程和外部系统的实际状态。

MASA 的文章用一个检索资料、生成报告并申请发送邮件的 Agent，组织了七类故障与边界测试。它是一套实践检查思路，而非带有通过率的实验报告。值得关注的变化是评测对象：从模型给出的答案，扩展到工具、授权、持久化状态与外部副作用组成的完整运行系统。

从系统设计角度，下面把这组问题进一步整理成可落地的验证方法。关键不是给 Agent 多写几句“务必小心”，而是明确：谁能阻止动作、失败留在哪里、什么记录可以证明约束生效。

这个表把“表现看起来正确”和“约束实际生效”分开。Agent 说没有发送邮件，并不等于邮件没有到达；日志显示尝试恢复，也不等于恢复过程中没有重复操作。证据应尽量来自能观察实际结果的一方。

测试环境不必先接入真实邮箱和付费服务。一个可控制的检索端点、一个只记账的模拟发送接口，以及保存调用轨迹的执行器，就可以暴露许多问题。每个用例先规定初始状态、注入时刻、允许结果和禁止结果，最后同时比较报告与环境状态。

例如，同样是“检索失败”，临时服务故障与凭据无效需要不同处理。前者可能值得有限重试，后者通常需要结束这一访问路径或等待授权。若只注入一种错误，很容易把“不断换工具直到成功”误认为恢复能力。

AWS 对远程调用的分析指出，超时不代表副作用没有发生，重试也可能放大依赖服务的负载。退避、抖动和重试上限需要作为整体考虑。AWS Builders’ Library

放到 Agent 上，还要跨越模型规划层检查：一次工具重试失败后，模型可能重新规划，再以新的工具调用继续同一操作。因此，单个 SDK 的重试计数只是局部信息。我们的验证目标应是整个逻辑操作，而不只是某个函数调用。

考虑一个示意流程：用户批准发送某份报告，发送端接收请求，随后执行器崩溃。恢复时，队列里仍有“发送报告”这一项。此时最危险的判断是“本地没有成功记录，所以再发一次”。

更有用的设计问题是：批准记录、执行请求和接收端结果能否对应到同一个逻辑操作？对这个流程，可以检查以下链条：

确定动作内容 → 保存批准记录 → 分配操作标识
→ 执行请求 → 核对外部结果 → 保存完成状态

这不是新的系统架构，而是整理测试证据的顺序。改变附件后，原批准是否失效；重启后，同一操作是否被识别；遇到结果不明时，系统是否先核对外部状态，都可以沿这条链逐项验证。

幂等键是其中一种工具，但不能只要生成一个键就宣称获得了全局“恰好一次”。例如 Stripe 文档说明了其请求结果保存、参数比对和键保留范围；这些是特定服务的契约，不能自动套用到所有邮件、存储或部署接口。Stripe：幂等请求

对没有幂等支持的服务，测试应覆盖结果不明时的暂停和核对路径。宁可把不确定状态显式保留下来，也不要让模型用一段流畅解释代替已经发生的事实。

停止当前对话，只能说明某个交互结束。真正的运行控制还涉及等待中的请求、已领取任务的执行器和已经发往外部的动作。这里适合采用时间线分析：记录停止请求到达、停止状态生效、每次动作发出与外部确认的时间。

测试时可以先安排几个带延迟的模拟操作，再在不同时间点停止任务。预期结果不是“所有动作都消失”，而是区分已完成、无法撤回的在途动作，以及本应被阻止的新动作。重启后再次观察，是为了发现只存在于进程内存里的停止状态。

这种测试与混沌工程有直接联系：主动改变系统的时序与故障条件，验证预先定义的运行约束。它也需要一个正常执行对照；若系统在所有情况下都拒绝操作，虽然副作用很少，却没有证明它能够完成有用工作。

我更看重失败轨迹能否帮助定位责任边界，而不是把七类测试压成一个总分。每次失败至少应能回答：约束由谁实施、哪个状态发生分歧、最终哪个外部结果不符合预期。修复权限边界时重测所有替代访问路径，修改恢复逻辑时重测关键崩溃窗口，比机械地重复一个正常任务更有价值。

Agent 的执行路径存在变化，单次通过只能说明某次条件下没有观察到问题。Anthropic 的评测讨论强调多次运行，并结合执行轨迹和最终结果判断行为；这也适用于故障实验，但不能把少量重复转换成很低的线上失败率保证。Anthropic：Agent 评测

这篇文章值得读的地方，是把无人值守能力具体化为可观测、可阻止、可恢复的运行行为。 对 AgentOps 研究，更进一步的问题是：哪些故障会穿过多个组件，现有证据能否区分根因，以及修复是否只改善某条轨迹而损害其他正常路径。