H7 · 如何保障 Agent System 的可靠性与故障恢复？ - Reliability

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：可靠性工程、故障恢复与容错架构专题研究
版本：v1.1
更新日期：2026 年 10 月 29 日
核心问题：当模型服务、工具接口、任务执行器、数据库与多个 Agent 都可能超时、失败、重复或产生不确定结果时，如何使 Agent System 在明确的安全与业务约束内持续提供服务、限制故障扩散，并在中断后正确恢复任务及外部副作用？

专题导读

本篇属 Engineering & Governance。Agent System 的可靠性不能简单理解为“请求失败就重试”。一个研究任务可能持续数小时，跨越多个模型、外部搜索服务、数据库事务、人工审批与报告发布操作。中途任何一次超时，都可能意味着操作没有发生、已经发生但回执丢失，或仍在执行。如果系统不区分这些状态，自动重试可能造成重复付款、重复发布、重复邮件，甚至在审批撤销后继续执行。

本文沿用“技术研究报告 Studio”案例：选题 Agent、调研 Agent、分析 Agent、审核 Agent 与发布 Agent 共同产出报告。研究重点是可靠性目标、故障分类、重试与幂等、超时与取消、持久化恢复、外部副作用、隔离与降级、灾难恢复、可靠性验证及工程实施路径。本文讨论系统能否在故障下正确完成或安全停止任务，而非单纯追求进程不崩溃。

章节关系： L1 - L2 - L3 提供运行与模型服务基础，L4 管理单 Agent Run，L5 负责任务依赖和协作，L6 提供应用接口；H1 记录运行证据，H2 强制安全边界，H3 评估质量，H4 定义持久状态与恢复语义，H5 绑定配置版本，H6 管理人工介入。H7 负责把这些机制组合为可量化、可验证的容错能力。可靠性不替代 H4 的状态模型，也不替代 H11 的部署运维。

阅读目标： 能制定 SLI/SLO、建立故障模型、设计任务与工具调用的恢复协议、识别重复副作用风险，并为真实 Agent System 编制故障注入和恢复验收计划。

一、可靠性的定义与系统边界

1.1 定义

Agent System Reliability 指系统在给定负载、依赖故障和操作条件下，持续满足预先定义的服务契约，并在故障发生时以可预测、可审计的方式恢复、降级或安全终止的能力。它至少包含四个维度：可用性（Availability）、执行正确性（Execution Correctness）、恢复能力（Recoverability）、故障遏制（Fault Containment）。

可用性高并不意味着执行正确。例如，API 始终返回 HTTP 200，但任务被静默丢弃，或者重复发布报告，仍是严重可靠性失败。反过来，系统在无法确认外部副作用时主动暂停并请求人工核验，虽然牺牲了即时完成率，却可能是正确的可靠性行为。

1.2 可靠性与邻近概念

概念	主要问题	与 H7 的关系
Availability	服务能否被使用	可靠性的一部分
Durability	已确认数据能否保留	依赖 H4 与存储层
Consistency	并发状态是否符合约束	决定恢复后的正确性
Resilience	遇到扰动能否继续服务	包含隔离、降级与恢复
Safety	是否阻止不可接受的行为	故障时必须维持安全约束
Observability	能否发现和解释故障	H1 提供证据
Evaluation	结果质量是否合格	H3 衡量任务价值

1.3 不应作出的保证

分布式系统无法通过一个简单开关保证“任意外部 API 只执行一次”。跨网络请求存在结果不确定窗口：请求已到达对方但响应丢失。所谓 exactly-once 需要严格限定于特定系统、事务边界或具备去重协议的外部服务。对普通 HTTP 工具调用，应默认可能出现重复请求，并通过幂等键、外部查询、对账或人工核验控制副作用。

二、从用户任务定义可靠性目标

2.1 三层服务契约

可靠性目标应同时覆盖：入口服务（任务是否被持久接受）、执行服务（任务是否按状态机推进）、交付服务（产物是否正确且可访问）。例如“创建任务 API 99.9% 可用”不能代表“99.9% 的研究报告完成”。不同目标需要不同的分母与观察窗口。

维度	示例 SLI	需要明确的口径
接入可用性	成功接受请求 / 合法请求	只计算已持久化的接受
任务终态率	达到合法终态 / 到期任务	排除用户主动取消的规则
恢复成功率	故障后合法恢复 / 可恢复故障	区分自动与人工恢复
重复副作用	重复外部操作事件数	必须以业务 ID 去重
恢复时长	故障发现到恢复的时长	p50、p95、p99
数据丢失	已确认事件的丢失数	按确认边界定义
故障影响面	被同一故障波及的 Run 数	按租户、服务、队列统计

示例目标（非行业标准）： 已持久接受的任务不应无记录消失；所有 Run 必须最终进入合法终态或可解释的人工待处理态；发布动作在不确定结果下不得盲目重复；关键任务在单 Worker 崩溃后可由其他 Worker 接管。实际 SLO 需依据风险、业务成本与实测基线确定。

2.2 错误预算与优先级

如果可用性目标为 99.9%，在 30 天窗口中对应约 43.2 分钟的理论不可用预算，但不能据此推导长任务的正确性目标。对报告发布、付款或删除操作，重复副作用的容忍度可能远低于普通模型回答失败率。应将正确性 SLO与可用性 SLO分开管理，避免用“高成功率”掩盖低频高损害事故。

三、建立面向 Agent 的故障分类体系

3.1 按发生位置分类

故障域	典型故障	首选处理方向
L1 运行环境	进程崩溃、节点失联、磁盘满	故障转移、容量与备份
L2 基础服务	数据库超时、消息重复、队列积压	事务、背压、重投递
L3 模型服务	429、5xx、流式中断、供应商故障	限流、退避、能力感知回退
L4 执行引擎	Run 中断、Step 卡死、工具超时	检查点、租约、恢复
L5 编排协作	依赖死锁、结果缺失、Agent 失联	DAG 校验、超时传播、补偿
L6 应用接口	断线、重复提交、Webhook 重发	幂等请求、事件游标
H 横向机制	凭据过期、审批失效、策略冲突	拒绝执行、重新授权

3.2 按失败语义分类

比“是否报错”更重要的是确定失败的可重试性和副作用确定性：

1. 明确未执行（Not Executed）：请求在可信边界前被拒绝，可以在满足条件后重新提交。
2. 明确失败且无副作用（Failed Without Effect）：可根据错误类型和预算重试。
3. 明确成功（Committed）：必须记录结果，不应重复执行。
4. 结果未知（Outcome Unknown）：请求可能已产生副作用，应先查询、对账或转人工。
5. 部分成功（Partial Success）：需按业务事务决定继续、补偿或人工介入。
6. 永久失败（Permanent Failure）：如权限拒绝、参数非法、资源不存在；不能靠无界重试解决。

模型输出不符合 JSON Schema 可能属于可修复的语义失败；但工具已经发布报告后模型生成摘要失败，不意味着可以重新发布报告。必须把“生成失败”与“外部副作用成功”分开记录。

3.3 故障传播路径

典型级联：模型供应商变慢 → Agent Step 占用并发槽 → 工具队列积压 → 任务超时 → 大量自动重试 → 供应商限流加重 → 整体雪崩。应在入口限流、每依赖并发上限、队列长度、重试预算、超时传播和熔断处设置独立控制点。

四、超时、重试与取消：先定义契约

4.1 超时的层级

一次任务可能具有：模型请求超时、工具调用超时、单 Step 截止时间、Run 截止时间、人工审批截止时间及全局业务期限。应从上级截止时间向下传递剩余预算，避免下游重试使任务超出总期限。

Task deadline
  └─ Run deadline
      └─ Step deadline
          ├─ Model request deadline
          └─ Tool request deadline

超时只表示等待方不再继续等待，不保证远端计算停止。尤其在取消或超时后，应标记结果未知并根据工具语义执行核验。

4.2 重试决策表

场景	默认策略	关键约束
模型 429	有界指数退避	尊重 Retry-After 与预算
模型短暂 5xx	有界重试或合规回退	防止成本与质量漂移
工具参数 4xx	不自动重试	修正输入或权限
只读查询超时	通常可重试	仍需请求预算
发布请求超时	先核验后决定	禁止盲目重复
审批已过期	停止并重新审批	不允许重试绕过权限
数据库提交未知	以业务键查询事务结果	防止重复写入

4.3 指数退避与抖动

一个常见形式为 delay = min(cap, base × 2^attempt) × jitter，其中 jitter 可采用全抖动等策略，减少大量客户端同时重试。真正需要限制的是总重试次数、总耗时、并发数和累计费用。对不可重试错误、被取消任务和已过期授权必须立即停止。

4.4 取消的边界

取消应定义为一种协作式协议：停止创建新 Step、向支持取消的下游发送信号、释放租约，并将无法确认结果的副作用转为待核验。不能将“用户点击取消”解释为“所有已经发生的外部操作都被撤销”。取消与回滚是两回事。

五、幂等与外部副作用：可靠性的核心难点

5.1 四个不同的 ID

标识	表示什么	是否应跨重试保持
task_id	用户业务任务	是
run_id	一次逻辑执行	视恢复契约而定
attempt_id	一次具体尝试	否
operation_id	一次逻辑外部动作	是

一个发布操作 operation_id=publish-report-42-v7 可以经历多个 attempt_id，但不得因此变成多个逻辑发布动作。请求幂等键应绑定租户、动作类型、目标资源、参数摘要与版本；不能只靠随机字符串防重复。

5.2 建议的操作状态机

PREPARED
   │（权限、参数、版本检查）
   ▼
DISPATCHING ──响应确认成功──▶ COMMITTED
   │                             │
   ├──明确无副作用失败──▶ FAILED │
   │                             │
   └──超时/连接中断──▶ UNKNOWN ──┤
                             │   │
                 查询或对账确认   │
                     ├─成功──────┘
                     ├─未执行──▶ RETRY_ELIGIBLE
                     └─无法确认▶ NEEDS_REVIEW

这是参考状态模型，不是外部服务通用协议。若服务提供幂等键，须确认其有效期、参数冲突行为和错误处理语义；若不提供，系统需要业务查询或人工核验。不能凭本地数据库里没有成功记录就推断远端未执行。

5.3 Transactional Outbox

当系统必须同时写入数据库状态和发送消息时，可在同一数据库事务中提交业务状态及 Outbox 记录，由独立发布器异步投递。这样可以避免“数据库已提交但消息丢失”的一类故障；但发布器仍可能重复投递，因此消费者仍需幂等。Outbox 保证的是事务内状态与待发布意图的一致性，并不自动保证外部操作 exactly-once。

5.4 Saga 与补偿

跨系统操作通常无法获得全局 ACID 事务，可将其组织为带补偿步骤的 Saga。例如：创建草稿 → 上传附件 → 发布页面。若附件上传失败，可以删除草稿；但若页面已被外部用户访问，撤回页面也不能抹除已发生的传播。补偿是新的业务动作，必须记录其结果、权限和不可逆边界。

5.5 发布操作的可靠协议

研究报告 Studio 在发布第 7 版时，推荐执行：①冻结产物版本及摘要；②核验 H6 审批与 H2 权限；③创建唯一 operation_id；④持久化 PREPARED；⑤向发布服务发送带幂等键的请求；⑥记录远端资源 ID；⑦只有确认后转 COMMITTED；⑧超时进入 UNKNOWN，查询远端状态，不能直接再发。若报告内容在审批后改变，必须重新核验授权。

六、持久化恢复与 Worker 故障转移

6.1 恢复所需的最小信息

一次可恢复 Run 至少需要：任务目标、Run 与 Step 状态、配置版本、输入输出引用、已提交操作、待确认操作、下一步可执行位置、权限/审批引用、截止时间和失败次数。只保存聊天历史不足以恢复外部工具副作用，也无法识别哪个 Step 已经提交。

6.2 Checkpoint 的安全边界

推荐在可解释的业务边界建立 Checkpoint，例如模型决策后、工具调用前、工具结果持久化后、人工审批等待前。Checkpoint 必须与外部操作记录协同，否则可能恢复到“即将调用工具”的位置，再次执行已经完成的操作。有关状态版本与 Snapshot/Event Sourcing 的详细机制见 H4。

6.3 Lease 与 Fencing Token

Worker A 获得 Run 租约后可能因网络分区失联，Worker B 在租约到期后接管；但 A 可能稍后恢复继续写入。需要单调递增的 fencing token，在状态提交和关键副作用网关处拒绝旧 token。单靠“租约到期”不能阻止旧 Worker 的迟到写入。

Worker A: lease=41 ──网络分区─────────┐
                                     ├─迟到写入 token=41 → 拒绝
Worker B: lease=42 ──接管并继续───────┘

对无法识别 fencing token 的第三方 API，应由内部工具网关控制操作所有权，并通过幂等与远端核验降低重复副作用风险。

6.4 恢复算法的原则

恢复时先读取权威持久状态，而不是根据内存或前端状态猜测；核验配置版本和权限；识别 UNKNOWN 操作；只调度满足依赖且尚未提交的 Step；对无法安全重放的步骤停在 NEEDS_REVIEW。模型生成过程通常不具备确定性重放保证，恢复目标应是业务状态正确，不是逐 Token 重现原轨迹。

七、隔离、背压、熔断与降级

7.1 Bulkhead：限制故障半径

为不同租户、任务优先级、模型供应商、工具类型设置并发池与配额，避免低优先级批量研究耗尽发布审批通道的资源。隔离边界可以是 Worker 池、队列、连接池、进程或服务；越强的隔离通常意味着更高的运营成本。

7.2 Backpressure：不要无限接收任务

当队列积压超过阈值时，入口应拒绝、延后或限流新任务，并向用户返回明确的排队状态。无限队列只是把失败从入口转移为长时间延迟和内存/存储压力。监测指标应包含队列深度、最老任务年龄、入队速率、出队速率及可用 Worker 容量。

7.3 Circuit Breaker：防止反复冲击故障依赖

熔断器常见状态为 CLOSED、OPEN、HALF_OPEN。触发阈值应综合错误率、延迟和样本量，并区分权限错误、限流和供应商故障。熔断后可以切换到满足能力、隐私、数据驻留和成本约束的备用模型；不能因为供应商故障就无条件把敏感数据发送到任意其他服务。

7.4 Graceful Degradation：可接受的降级

依赖故障	可接受的降级	不可接受的伪装
非关键检索源不可用	标记来源缺失、等待补查	编造引用
高级模型不可用	使用经评估的备用模型	隐瞒质量差异
实时事件通道中断	轮询持久任务状态	把断线当任务失败
审批服务不可用	暂停敏感动作	绕过审批继续执行
发布服务不可用	保存已审核产物待发布	宣称已经发布

降级必须满足明确的最低质量与安全契约。若无法满足，正确行为是停止并告知用户，而非制造表面成功。

八、多 Agent 协作中的可靠性

8.1 依赖失败与失败传播

任务 DAG 应定义每个节点的成功条件、可重试性、替代路径与失败传播规则。调研 Agent 失败后，分析 Agent 不应把空结果当成有效证据继续；审核 Agent 可以返回返工请求，但返工次数需要上限。动态生成的子任务还应防止无限递归和重复派发。

8.2 Fan-out/Fan-in 的部分结果

并行检索十个来源时，只有七个成功，不一定要整体失败，但必须根据任务契约判断七个来源是否足够。Fan-in 节点需要记录成功、失败、缺失和超时的子任务集合，明确结果覆盖率和证据完整性，而不是简单拼接已返回内容。

8.3 Handoff 的可靠语义

Agent A 委托给 Agent B 时，应先持久化委托意图和关联任务，再投递消息；B 使用委托 ID 去重，完成后提交带版本的结果。A 的超时不意味着 B 未执行。对 B 的重复结果必须根据业务键合并，而不是覆盖已确认的更高版本产物。

8.4 避免“协作活锁”

多个 Agent 可能反复提出修改、审核不通过、重新生成而无法终止。应设置最大返工轮次、预算上限、明确的验收标准、停滞检测和人工升级路径。可靠性要求可解释地终止，不等于必须无限努力完成。

九、灾难恢复与数据保护

9.1 RPO 与 RTO

**RPO（Recovery Point Objective）**定义可接受的数据恢复点损失窗口；**RTO（Recovery Time Objective）**定义灾难后恢复服务所允许的目标时间。两者是业务目标而非自动获得的技术保证。必须区分数据库恢复、消息恢复、对象存储恢复及外部工具状态核验。

9.2 备份与恢复演练

仅有备份文件不等于具备恢复能力。需要验证：备份可读取、密钥可用、数据库 Schema 兼容、对象存储引用未失效、Outbox 可重放、重复消息可去重、UNKNOWN 操作能核验。恢复演练应在隔离环境进行，并记录实际 RPO/RTO 与缺口。

9.3 多区域部署的权衡

跨区域容灾可能改善可用性，但会引入复制延迟、冲突、成本、数据驻留和凭据管理问题。对有外部副作用的工作流，应确保同一逻辑操作在故障转移时仍有全局唯一的业务键与一致的授权检查。不能简单地将多活部署视为“天然更可靠”。

十、研究报告 Studio：端到端参考架构

用户 / 外部系统
       │
       ▼
API Gateway ──身份验证、请求幂等、接入限流
       │
       ▼
Task Service ──持久化 Task/Run、配置版本
       │
       ├──────────▶ Event / Outbox ──▶ Queue
       │                                  │
       ▼                                  ▼
State Store ◀──── Checkpoint ─────── Agent Workers
       │                                  │
       │                         Model Gateway（退避/熔断）
       │                                  │
       │                         Tool Gateway（权限/幂等）
       │                                  │
       │                           External Systems
       │                                  │
       ├──────── Operation Ledger ◀──────┘
       │
       └──▶ Observability / Audit / Recovery Controller

最小组件职责： Task Service 只在持久化成功后返回“已接受”；Queue 允许至少一次投递，Worker 必须去重；State Store 维护权威状态和版本；Operation Ledger 记录副作用及 UNKNOWN；Tool Gateway 强制授权和幂等；Recovery Controller 扫描租约过期、超时和待核验操作；Observability 关联 task_id、run_id、step_id、attempt_id、operation_id。

10.1 典型故障演练：发布成功但回执丢失

1. 发布 Agent 获取已审批报告第 7 版，生成固定 operation_id。
2. Tool Gateway 记录 DISPATCHING 并发送发布请求。
3. 远端创建页面成功，但网络连接断开。
4. 系统记录 UNKNOWN，不将任务标记为成功或失败。
5. Recovery Controller 使用远端幂等键或资源查询接口核验。
6. 若找到匹配页面且内容摘要一致，记录 COMMITTED；若确定未执行，则在预算与权限仍有效时重试；若无法确认，则转人工核验。
7. 最终产物中保存远端页面 ID、版本、确认时间与操作证据。

验收标准： 不因回执丢失重复创建页面；不在未经确认时宣称发布成功；恢复过程保留审计链；旧审批或过期权限不能被恢复流程绕过。

10.2 故障演练：Worker 崩溃

在工具结果持久化之后、下一 Step 创建之前强制结束 Worker。新 Worker 应从权威状态接管，不能再次执行已提交工具操作。若工具结果尚未持久化且远端结果未知，应进入核验路径。分别测试数据库提交前崩溃、提交后崩溃和租约竞争三种时序。

十一、参考实现：纯函数重试判定与副作用状态

以下 Python 代码是教学级确定性示例，用于展示重试决策和 UNKNOWN 状态不能直接重试的约束；它不包含数据库事务、真实网络请求、跨进程锁或外部幂等服务，不能直接作为生产级操作账本。配套文件 H7-Agent-System-Reliability-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 H7-Agent-System-Reliability-v1.1-demo.py。

from __future__ import annotations

from dataclasses import dataclass
from enum import Enum

class Outcome(str, Enum):
    NOT_EXECUTED = "not_executed"
    FAILED_NO_EFFECT = "failed_no_effect"
    COMMITTED = "committed"
    UNKNOWN = "unknown"

@dataclass(frozen=True)
class RetryContext:
    outcome: Outcome
    attempts: int
    max_attempts: int
    authorization_valid: bool
    deadline_remaining_ms: int
    idempotency_supported: bool
    is_side_effecting: bool

def retry_decision(ctx: RetryContext) -> str:
    if not ctx.authorization_valid:
        return "stop_authorization"
    if ctx.deadline_remaining_ms <= 0:
        return "stop_deadline"
    if ctx.outcome == Outcome.COMMITTED:
        return "stop_committed"
    if ctx.outcome == Outcome.UNKNOWN:
        return "reconcile_first"
    if ctx.attempts >= ctx.max_attempts:
        return "stop_budget"
    if ctx.is_side_effecting and not ctx.idempotency_supported:
        return "require_effect_verification"
    return "retry_eligible"

assert retry_decision(RetryContext(
    Outcome.UNKNOWN, 1, 3, True, 1000, True, True
)) == "reconcile_first"
assert retry_decision(RetryContext(
    Outcome.COMMITTED, 1, 3, True, 1000, True, True
)) == "stop_committed"
assert retry_decision(RetryContext(
    Outcome.FAILED_NO_EFFECT, 1, 3, True, 1000, True, False
)) == "retry_eligible"
print("local reliability checks passed")

本地执行通过：输出 local reliability checks passed。

该示例故意采用保守策略：对于 UNKNOWN，即便对方支持幂等键，也先进入核验路径。真实系统可以在确认外部服务幂等协议与有效期后制定更精细的重试策略。

十二、可靠性测试与故障注入

12.1 测试层级

测试层级	验证对象	示例
单元测试	状态机与重试规则	UNKNOWN 不盲目重试
契约测试	模型/工具错误语义	429、超时、幂等冲突
集成测试	数据库与队列	Outbox 重投递、消费去重
故障注入	Worker/网络/依赖	崩溃、延迟、断连、分区
恢复演练	Checkpoint 与副作用	重启后不重复发布
容量测试	背压与隔离	队列积压、租户公平性
灾备演练	备份与区域切换	RPO/RTO 实测

12.2 必须覆盖的故障矩阵

A. 提交边界： 数据库事务前/后崩溃，消息投递前/后崩溃，工具请求发出前/后断线，远端成功但回执丢失。
B. 并发边界： 两个 Worker 争抢同一 Run，旧租约持有者迟到写入，重复 Webhook，多个 Agent 同时提交产物。
C. 权限边界： 审批撤销后恢复、凭据轮换后重试、租户切换、配置版本变化。
D. 资源边界： 模型 429、持续 5xx、工具长尾延迟、数据库连接耗尽、队列积压、对象存储不可用。
E. 质量边界： 备用模型缺少工具能力、检索来源缺失、部分任务完成但证据不足。

12.3 验收指标与判定

一次可靠性演练至少记录：故障注入时间、预期状态、实际状态、恢复时长、重试次数、外部操作次数、是否存在重复副作用、是否违反授权、是否产生未解释终态。通过测试的前提是检查最终业务状态与外部系统事实，而不只是检查进程是否恢复。

建议建立故障演练记录模板：scenario_id / build_version / config_revision / task_id / injected_fault / expected_invariant / observed_state / external_effect_evidence / recovery_duration / verdict / follow_up。

12.4 渐进式混沌工程

先在本地和隔离环境验证单一故障，再进入预发布环境，最后对生产环境开展受控、可回滚的小范围实验。生产实验必须具备停止条件、责任人、观察窗口、告警与回退预案。对真实付款、删除、发布等不可逆动作，优先使用沙箱服务或可控测试租户。

十三、实施路线与架构决策

阶段一：建立可靠性基线

定义任务状态机与终态；为每个 Task、Run、Step、Attempt、Operation 分配关联 ID；确保“已接受任务”具有持久化凭据；建立关键 SLI、错误分类与告警；对发布、付款等动作默认关闭自动盲重试。

阶段二：实现可恢复执行

引入 Checkpoint、Worker 租约与 fencing、Operation Ledger、Outbox、幂等消费；实现 UNKNOWN 核验和人工待处理状态；补齐重试预算、取消传播、超时层级和故障演练。

阶段三：实现隔离与弹性

按租户和依赖划分容量池；配置背压、熔断与降级策略；建立供应商能力感知回退；实施备份恢复演练与 RPO/RTO 测量。

阶段四：持续可靠性治理

建立 SLO 和错误预算评审、故障复盘、恢复演练日历、可靠性回归门禁。对每次严重事故追溯“哪条不变量被破坏、为何现有控制未阻止、如何用测试防止复发”。

常见反模式

1. 无限重试： 将临时故障放大为级联故障，并造成成本失控。
2. 只靠日志恢复： 无权威状态与操作账本，无法判断副作用是否已发生。
3. 把 HTTP 超时当成远端失败： 导致重复发布或重复付款。
4. 仅依赖分布式锁： 锁过期后旧 Worker 仍可能写入；需要 fencing 或等效约束。
5. 跨模型无条件回退： 破坏隐私、能力、输出契约或质量要求。
6. 将消息队列当成 exactly-once： 忽视消费者重复处理与外部副作用。
7. 只验证系统重新启动： 不核验业务结果、数据一致性和外部事实。
8. 将补偿等同回滚： 忽视不可逆副作用和补偿自身失败。
9. 以完成率掩盖安全失败： 将未经审批的成功操作计为合格完成。

研究结论

第一，可靠性首先是业务契约与状态不变量，而非单一基础设施指标。 对 Agent System，任务被持久接受、执行可解释、结果可确认、授权不被绕过，比表面上的 HTTP 成功率更重要。

第二，外部副作用的不确定性是可靠性设计的关键边界。 网络超时无法证明远端未执行。应以逻辑操作 ID、幂等协议、Operation Ledger、远端核验和人工介入处理 UNKNOWN 状态，而不是简单增加重试次数。

第三，可恢复执行必须联合状态管理与并发控制。 Checkpoint 解决“从哪里继续”，操作账本解决“哪些动作已经发生”，租约与 fencing 解决“谁有资格继续”，审批与配置版本解决“是否仍被允许继续”。

第四，容错能力必须控制故障半径。 限流、背压、熔断、隔离、降级和预算约束共同防止局部失败演变为系统雪崩。降级必须保持最低安全与质量要求。

第五，可靠性需要以故障注入和恢复演练证明。 只有在数据库提交边界、网络回执丢失、Worker 竞争、权限撤销及灾难恢复等场景下验证最终业务事实，才能对系统可靠性作出有依据的判断。

附录 A：参考文献与原始资料

以下优先列出规范、官方文档与技术原始资料。它们为本文的机制分析提供依据，但不同系统的实现与保证边界并不完全相同；实际落地时应核对所采用版本。

• [R1] Google SRE Book - Service Level Objectives：SLI、SLO 与可靠性目标。sre.google/sre-book/service-level-objectives/
• [R2] Google SRE Workbook - Error Budget Policy：错误预算与发布治理。sre.google/workbook/error-budget-policy/
• [R3] AWS Builders’ Library - Timeouts, retries, and backoff with jitter：超时、重试与退避的系统性分析。aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
• [R4] AWS Builders’ Library - Making retries safe with idempotent APIs：幂等 API 与重复请求语义。aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
• [R5] Microsoft Azure Architecture Center - Circuit Breaker pattern：熔断模式。learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
• [R6] Microsoft Azure Architecture Center - Bulkhead pattern：故障隔离模式。learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead
• [R7] Microsoft Azure Architecture Center - Compensating Transaction pattern：补偿事务及不可逆操作边界。learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
• [R8] Microservices.io - Transactional Outbox pattern：数据库事务与消息发布意图的一致性模式。microservices.io/patterns/data/transactional-outbox.html
• [R9] Temporal Documentation - Workflow Execution：持久工作流、活动执行与恢复语义。docs.temporal.io/workflow-execution
• [R10] Temporal Documentation - Activity Execution：活动重试、超时与执行约束。docs.temporal.io/activity-execution
• [R11] LangGraph Documentation - Persistence：Checkpoint 与状态持久化。docs.langchain.com/oss/python/langgraph/persistence
• [R12] PostgreSQL Documentation - Transaction Isolation：事务隔离与并发行为。www.postgresql.org/docs/current/transaction-iso.html
• [R13] OpenTelemetry Documentation：跨服务指标、日志与追踪。opentelemetry.io/docs/
• [R14] Kubernetes Documentation - Leases：租约机制及协调用途。kubernetes.io/docs/concepts/architecture/leases/
• [R15] Google SRE Book - Addressing Cascading Failures：级联故障与过载。sre.google/sre-book/addressing-cascading-failures/

资料使用说明： [R1 - R2] 支持可靠性目标与错误预算；[R3 - R4] 支持重试、超时和幂等原则；[R5 - R8] 支持隔离、熔断、补偿及 Outbox 模式；[R9 - R12] 为持久工作流和数据库一致性提供实现参考；[R13 - R15] 支持观测、租约和级联故障分析。部分资料属于模式或产品文档，不能据此断言所有框架天然提供相同保证。

附录 B：研究证据、验证声明与适用边界

B.1 证据等级

• 规范或官方文档支持： SLO、超时/退避、幂等 API、熔断、隔离、事务、工作流持久化等基础机制；以附录 A 为索引。
• 工程综合推导： Agent 专用 Operation Ledger、UNKNOWN 状态治理、跨 H2/H4/H6 的恢复约束、研究报告 Studio 的端到端参考架构；属于基于通用分布式系统原理的架构建议，而非某一框架的强制标准。
• 示例性设计： 状态机、接口标识、SLO 示例、实施阶段和故障演练流程；需依据实际业务、供应商协议及合规要求调整。

B.2 验证声明

本文包含一段不依赖第三方库的 Python 确定性示例和三个断言，用于展示重试判定原则。它不验证真实网络时序、数据库原子性、供应商幂等有效期、分布式租约竞争或生产环境容灾能力。只有实际执行相应实验并保留证据，才能宣称这些能力已通过验证。

B.3 适用范围

适用于具备模型调用、工具执行、长任务、人工审批或多 Agent 协作的 Agent System。对于完全无状态、只读且不涉及外部副作用的简单问答应用，可采用更轻量的方案。对金融、医疗、工业控制等高风险场景，需额外满足行业规范、审计、测试和人工监督要求。

B.4 仍需通过实测回答的问题

1. 当前模型供应商的限流与重试协议、幂等能力及账单语义是什么？
2. 现有数据库与消息队列的确认边界、复制模式和故障恢复行为是什么？
3. 关键工具是否提供操作查询接口、幂等键及其有效期？
4. 在 Worker 崩溃、网络分区和主库切换时，是否仍满足状态不变量？
5. 业务允许的 RPO、RTO、重复副作用阈值及人工恢复时间是多少？
6. 备用模型能否满足质量、工具能力、数据驻留和成本约束？

下一专题： 「H8 · 如何管理 Agent System 的资源、成本与预算？ - Resource Management」。