失败恢复评测与可观测性
本节目标
你将能按错误类别选择重试、降级、失败或人工接管，设计检查点与幂等回执，并同时评测组件、轨迹、任务结果和运行指标。
先分类，再恢复
| 类别 | 例子 | 默认处理 |
|---|---|---|
| 输入/业务错误 | 缺字段、政策不允许 | 不重试；澄清、拒绝或取消 |
| 权限错误 | 身份无权写入 | 不重试；告警或人工处理 |
| 瞬时基础设施错误 | 短暂超时、限流 | 有上限重试与退避 |
| 永久依赖错误 | 资源不存在、接口不兼容 | 失败或降级 |
| 策略/模型错误 | 路由错误、越界动作 | 保存轨迹，进入评测或人工 |
| 未知提交状态 | 写请求超时 | 先查幂等回执，再决定 |
统一重试会放大成本，并可能重复副作用。重试策略要有每步次数、总时间、可重试错误集合和熔断条件。退避公式只是机制，具体间隔要尊重服务端指示和业务期限。
检查点与幂等解决不同问题
- 检查点回答“内部流程走到哪里、下一步是什么”。
- 幂等键与回执回答“外部动作是否已经发生”。
一个经典故障窗口是：外部写入已提交，但进程在保存新检查点前崩溃。恢复后检查点仍显示 execute。若直接重做，会产生重复记录；若先按稳定动作 ID 查询回执，就能把已提交事实补回状态。
本地 JSON 的原子替换只能演示检查点概念。生产系统还需要并发控制、事务、权限、备份、迁移、保留和灾难恢复设计。
可观测性：日志、指标与轨迹
一次运行至少记录：
run_id、输入摘要和版本；- 模型、提示、工具与策略版本；
- 每步开始、结束、状态和耗时；
- 工具名、参数安全摘要、结构化结果与错误类别；
- 路由、重试、审批、预算和终态；
- 本地 run / operation / action ID、协议请求 ID、远端 task ID 与外部动作回执引用（按作用域分别保存）。
日志解释单个事件，指标呈现总体趋势，**轨迹（trace / trajectory）**连接模型决定、工具动作和观察。记录应最小化敏感数据；可重放不等于保存所有原文和秘密。
跨协议轨迹：关联，不混同
若工作流穿过 MCP 或 A2A，一个“成功”至少有四层不同事实：本地状态机是否完成、协议请求/远端 task 是否终态、外部业务动作是否有回执、当前认证主体是否仍被允许读取该结果。不要用一个 UUID 同时充当这些角色，也不要仅因远端返回 completed 就把本地 outcome 判为成功。
回归集应额外覆盖：能力或 Agent Card 声明与真实授权不一致、跨租户/过期 task ID、远端 auth-required、Webhook 或流式事件重复/乱序、token audience 不匹配与远端终态和本地回执不一致。协议的消息合法性、认证、对象范围和业务 outcome 是不同 grader；任一层失败都应留下可关联的最小证据，而不是自动扩大权限或盲目重发。
Agent 评测的基本对象
Anthropic 2026 年官方评测文章给出一组实用定义：任务（task）有输入和成功条件；一次执行是 trial；grader 对结果打分；transcript/trace 是完整运行记录；outcome 是环境最终状态；evaluation harness 负责运行、记录、评分和汇总。随机模型应对同一任务做多次 trial，不能用一次成功代表稳定性。
尤其要区分“Agent 说完成了”和“环境确实完成了”。预订 Agent 的文本可以声称成功，真正 outcome 是数据库中存在正确预订。
四层评测
- 组件测试：路由枚举、参数校验、解析器、重试分类、状态迁移。
- 轨迹评测：是否只调用允许工具，参数是否越界，是否遵守审批与预算。
- 任务/outcome 评测：最终事实、文件、数据库或业务状态是否满足成功条件。
- 运行评测：成功率、P50/P95 时延、成本、重试率、接管率、安全违规率。
发布门槛应同时约束质量与安全。例如平均正确率很高，也不能掩盖一次未经审批的付款。不同模型版本或提示版本要在同一冻结任务集上比较，并报告 trial 数和不确定性。
构造离线任务集
从真实失败模式和需求边界取样：
- 正常路径；
- 空值、超长值、临界金额；
- 工具超时、权限拒绝、永久错误；
- 非法 JSON 与未知路由；
- 提示注入和恶意附件；
- 人工批准、拒绝、过期、修改；
- 写入后崩溃和重复恢复；
- 预算耗尽与部分并行失败。
- 跨协议的 capability/Agent Card 与真实授权不一致、外来 task ID、远端
auth-required、重复回调和终态—回执不一致。
为每个样本写期望终态、允许工具集合、禁止副作用和 outcome 断言。先从少量高价值任务开始，再依据生产故障扩充；不要只收集容易通过的“快乐路径”。
故障演练：检索、生成、发邮件
至少验证：
- 检索无结果，不生成无来源事实；
- 文档包含提示注入，不能改变发信权限；
- 邮件服务在提交前超时，可有限重试；
- 邮件服务提交后响应丢失，先查回执；
- 人工拒绝，不再发送；
- 收件人审批后变化，旧审批失效；
- 同一检查点重复恢复，不产生第二封；
- 日志脱敏且仍能关联 action ID。
每个测试既检查终态，也检查轨迹和外部回执。
常见错误与排查
- 只评最终回答：增加工具轨迹、审批和环境 outcome grader。
- 每次 trial 使用不同环境：冻结初始状态和版本，隔离并清理副作用。
- 重放会调用真实生产工具：使用沙箱、模拟器或只读镜像。
- 指标没有分母与时间窗：记录样本数、trial 数、版本和统计窗口。
- 日志包含完整提示与凭据：按数据分类做最小采集与脱敏。
- 检测到失败但无法复现：保存输入摘要、版本、种子/参数、动作和回执引用。
练习
为一个“检索→生成→审批→发邮件”流程设计 12 个任务：正常 3 个、边界 3 个、依赖故障 2 个、安全 2 个、恢复 2 个。安全任务中至少一个应模拟远端 capability/Agent Card 不能授予对象访问，或外来 task ID 不能读取其他主体的结果。每个任务写：
- 冻结输入与初始环境；
- 期望终态和 outcome；
- 允许/禁止的工具调用；
- grader 与断言；
- 是否需多次 trial；
- 失败时需要保留的最小证据。
掌握检查
- 能把错误映射为重试、降级、失败或转人工。
- 能解释检查点和幂等回执分别解决什么。
- 能区分文本输出、轨迹和环境 outcome。
- 能同时给出组件、轨迹、任务和运行评测。
- 能设计“提交后崩溃”的恢复测试。
下一步
完成 项目：可恢复任务工作流，把本路线的模式组合成可运行状态机。
参考资料
- Anthropic：Demystifying evals for AI agents（发布：2026-01-09；核对：2026-07-14）
- LangGraph 官方：Persistence（动态文档，核对：2026-07-14）
- LangGraph 官方：Interrupts（动态文档，核对：2026-07-14）
- MCP 2025-11-25：Authorization（resource/audience、scope 与 token 使用；核对：2026-07-22）
- A2A 1.0：Security Considerations（逐请求范围、重复通知与 task 恢复；核对：2026-07-22）