huaAgentStudyAgent

外观

zmh.life

H4 · 如何管理、保存和恢复系统状态？ - State Management ​

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：状态架构、持久化一致性与故障恢复专题研究
版本：v1.1
更新日期：2026 年 10 月 29 日
核心问题：在模型调用不确定、任务长时间运行、工具产生外部副作用、多个 Agent 并行协作的条件下，如何定义状态的所有权与生命周期，保证状态可持久化、可追溯、可恢复，并明确一致性、幂等与恢复能力的真实边界？

专题导读 ​

本篇属 Engineering & Governance。一个 Agent System 可能在任务执行到一半时进程重启，可能在模型返回后、工具执行前失去连接，也可能在外部系统已成功写入后、内部数据库尚未记录结果时崩溃。多 Agent 系统还可能同时修改同一份研究提纲。此时，“把对话存进数据库”远不足以解决问题：必须回答哪份状态具有权威性、哪些事件已经提交、哪些动作可能重复、如何在恢复时判断下一步，以及如何证明没有越过用户审批。

本文沿用“技术研究报告 Studio”作为贯穿案例：选题、检索、分析、审核、发布 Agent 共同完成研究报告。围绕 Task、Run、Step、Attempt、Artifact、Approval 与 External Action 建立状态模型，讨论快照、事件日志、检查点、事务、并发控制、外部副作用与恢复协议，并给出可执行的本地验证实验。重点是 Agent System 的横向状态治理；L2 Platform Services 提供数据库与消息设施，L4 Agent Engine 负责单个 Run 的推进，L5 Orchestration & Collaboration 负责协作调度，H4 则定义跨层状态语义和恢复约束。

阅读目标： 阅读后应能判断一个系统是否真正支持恢复、设计最小可行状态契约、选择持久化模式、处理重放与外部操作，以及制定故障注入测试，而不是仅依赖框架提供的“memory”或“checkpoint”功能名称。

一、状态管理究竟管理什么？ ​

1.1 定义：状态是未来行为所依赖的已确认事实 ​

Agent System State Management 是对系统执行过程中需要跨请求、跨步骤、跨进程或跨参与者持续有效的信息进行建模、持久化、读取、更新、校验、迁移、归档和恢复的工程体系。核心不是保存一切，而是定义哪些事实必须成为系统后续决策的依据。

必须区分四个概念：**State（状态）**是某一时刻可被系统使用的事实集合；**Event（事件）**描述已经发生且被记录的事实变化；**Checkpoint（检查点）**是可用于恢复的状态截面及必要执行位置；**Memory（记忆）**是为未来任务提供上下文的持久知识或偏好，不天然具备事务语义。Context（模型上下文）通常只是某次推理的输入视图，不能视为权威状态库。

对象典型内容权威来源主要风险
Task用户目标、约束、截止时间任务数据库目标被覆盖
Run执行状态、当前位置、预算运行记录重复启动
Step / Attempt调用参数、尝试次数、结果执行日志重复副作用
Artifact报告、数据、版本、校验值对象存储与元数据错版发布
Approval审批人、范围、决定、有效期审批记录越权恢复
Shared State提纲、研究证据、任务图共享状态服务并发覆盖
Memory可复用知识、偏好记忆存储污染与过期
External Action外部提交、回执、核验状态操作台账与外部系统不确定执行

1.2 状态的三种维度 ​

业务状态表示用户可理解的阶段，例如 awaiting_approval、researching、delivered。执行状态描述运行时位置，例如某个 Step 已准备、某个 Attempt 已发出请求。基础设施状态描述 Worker 租约、队列消息、数据库事务和连接状态。三者相互关联，但不能互相推导：Worker 离线不意味着任务失败，队列已确认不意味着外部操作成功，界面显示“完成”也不代表最终产物已持久化。

1.3 状态边界与邻近专题 ​

L4 定义 Engine 的循环与 Step 执行；L5 定义 DAG、交接与共享任务；L6 定义面向用户的状态投影。H4 研究这些组件之间的权威状态、提交顺序、一致性、恢复规则。H1 Observability 的日志与 Trace 用于解释运行，不默认承担业务真相；H7 Reliability 研究可用性与故障策略，依赖 H4 的状态语义；H9 Data Governance 研究保留、删除与数据权利；H6 Human-in-the-Loop 研究人工决策流程，H4 保存决策及其效力。

二、先定义状态契约，再选择数据库 ​

2.1 最小实体与关联关系 ​

text
Tenant ── Task ── Run ── Step ── Attempt
                │      │
                │      └── ExternalAction
                ├── Approval
                ├── ArtifactVersion
                ├── TaskEvent
                └── Checkpoint

SharedWorkspace ── WorkspaceRevision ── Evidence/Outline

推荐让 task_id 表示用户目标，run_id 表示一次具体执行，step_id 表示逻辑步骤，attempt_id 表示该步骤的一次实际尝试。重试应生成新 Attempt，而不是覆盖旧 Attempt；恢复同一 Run 时也不应悄悄创建一份无法关联的新任务。tenant_id、schema_version、created_at、updated_at、version 应根据资源性质进入核心契约。

2.2 生命周期状态机 ​

以下是示例状态机，实际实现需按业务补充中间态和错误码：

text
Task: accepted -> running -> awaiting_approval -> running -> completed
                    |                 |                |
                    +-> failed        +-> rejected     +-> cancelled
                    +-> cancelling -> cancelled

Step: pending -> ready -> leased -> running -> succeeded
                                      |       |
                                      |       +-> retry_wait -> ready
                                      +-> unknown -> reconciling

状态转移必须有明确的前置条件、操作者、版本、时间和审计记录。例如 completed 应要求最终产物版本存在且已通过交付校验；awaiting_approval -> running 应要求审批决定仍有效，并与审批时绑定的操作内容哈希一致。终态是否允许重新执行应由新 Run 或显式重开流程表达，而不是任意回写终态。

2.3 状态不变量（Invariants） ​

系统设计时应先列出不可违反的规则，而非先画 UI：

  1. 同一 Task 的权威状态在任一提交版本上唯一；读模型可以滞后，但不能冒充权威。
  2. 同一外部副作用操作具有稳定的 operation_id，重试不得生成无关联的新业务动作。
  3. 已批准的动作必须绑定审批范围、目标对象和参数摘要；参数变更使原审批失效。
  4. 任何共享产物更新均具有版本或修订号，不能静默覆盖并发修改。
  5. 恢复过程不得把 unknown 的外部结果直接判为 failed 后盲目重试。
  6. 每个已发布 Artifact 必须指向不可变版本、校验值和来源 Run。
  7. 状态模式升级后，旧检查点要么可迁移，要么被明确拒绝并进入人工处理。

这些规则应落实到数据库约束、服务端状态机、权限校验和测试，而不能只写进 Agent 提示词。

三、状态分类：哪些必须保存，哪些应当丢弃？ ​

3.1 按生命周期分类 ​

瞬时执行态包括当前网络连接、局部变量、尚未提交的 token 流；一般允许丢失。可恢复执行态包括步骤位置、模型输入摘要、工具请求参数、重试计数、等待条件、已提交结果；必须跨进程保存。业务持久态包括任务、审批、报告版本、对外发布记录；需要事务性和审计性。长期记忆用于跨任务复用知识，应有来源、权限、失效与删除机制。派生投影包括进度条、仪表盘、搜索索引，可以从权威状态重建。

3.2 模型上下文不是状态数据库 ​

模型窗口中的消息序列可能被截断、摘要、压缩或重排。摘要可能丢失关键否定条件，例如“不得发布未经审核的引用”。因此，应把用户约束、审批状态、工具授权和已提交事实存入结构化状态，生成模型上下文时再按需投影。对话历史可作为证据或辅助上下文，但不应单独承担权限判断。

3.3 Memory 与 Checkpoint 的根本差别 ​

Checkpoint 关注“这次运行恢复到哪里”；Memory 关注“以后可能需要记住什么”。Checkpoint 通常绑定 run_id、执行位置、状态版本与恢复策略；Memory 通常绑定用户、租户、知识主题、来源、可见范围和有效期。把长期记忆直接当作恢复点，会导致任务阶段、审批结果、外部副作用状态无法重建；把全部 Checkpoint 当作长期记忆，又会造成数据膨胀、隐私泄露和无意义召回。

四、持久化模式：快照、事件日志与混合方案 ​

4.1 快照（Snapshot） ​

将当前状态保存为一条记录或一组事务性记录。优点是读取简单、恢复快、实现成本低；缺点是单靠快照难以解释历史变化、追溯错误转移。适用于状态变化频率不高、审计要求适中、流程较简单的场景。快照写入必须携带版本条件，例如 UPDATE ... WHERE version = expected_version，并检查影响行数。

4.2 事件日志（Event Log） ​

以不可变事件记录状态变化，例如 TaskAccepted、StepStarted、ApprovalGranted、ArtifactPublished。通过事件重放生成当前状态。优点是追溯和重建能力强；代价是事件模式演进、重放副作用隔离、读取投影与存储治理更复杂。事件重放只能重建内部状态，不应重新调用真实外部工具。 事件中的模型输出或外部回执应被当作历史事实重放，而不是重新推理或重新发送请求。

4.3 快照 + 事件日志 ​

工程中常采用混合方案：事务性状态表负责权威当前状态，追加事件表负责历史和异步投影，定期 Checkpoint 降低恢复成本。并非每个系统都需要完整 Event Sourcing。需要先确定审计与恢复要求，再决定是否将事件流设为唯一权威来源。

方案优势代价适用条件
快照为主简单、读写直接历史追溯弱单体、低复杂度
事件为主可重建、可追溯迁移和投影复杂强审计、复杂流程
混合方案读写与追溯兼顾双写一致性设计多 Agent 生产系统

4.4 数据库事务与 Outbox ​

状态变更与“通知下游继续执行”必须避免双写裂缝。若先提交数据库再发消息，进程可能在发消息前崩溃；若先发消息再提交数据库，下游可能读不到新状态。典型解决方法是在同一个数据库事务内提交状态更新和 Outbox 消息，由后台投递器异步发布，消费者通过去重或幂等处理重复消息。Outbox 保证的是消息最终可被尝试投递的可靠基础，不自动保证“恰好一次业务执行”。

text
Transaction:
  1. 验证 task.version == expected_version
  2. 更新 task 状态和 version
  3. 追加 task_event
  4. 插入 outbox_message
Commit

Publisher:
  5. 读取未投递 outbox
  6. 发布到消息系统
  7. 标记投递结果；失败可重试

Consumer:
  8. 以 message_id / operation_id 去重并处理

若采用不同存储系统，需要另行设计跨存储一致性和补偿机制，不能假设数据库事务覆盖对象存储或第三方 API。

五、Checkpoint：保存什么，什么时候保存？ ​

5.1 检查点的最小结构 ​

json
{
  "checkpoint_id": "cp_017",
  "tenant_id": "tenant_a",
  "task_id": "task_123",
  "run_id": "run_008",
  "schema_version": 3,
  "engine_version": "1.4.0",
  "state_version": 28,
  "execution_cursor": {"step_id": "review_sources", "phase": "before_dispatch"},
  "pending_operations": ["op_551"],
  "artifact_refs": [{"id": "outline", "version": 7, "sha256": "..."}],
  "approval_refs": ["approval_34"],
  "created_at": "2026-10-29T10:00:00Z"
}

这是概念性数据契约，并非某个框架的实际 API。生产实现还需保证引用完整性、签名或完整性校验、访问权限、加密与迁移策略。execution_cursor 只描述下一步的位置，不代表挂起的 Python 栈或外部进程可以原地恢复。

5.2 检查点时机 ​

建议在有意义的状态边界保存：任务接收后、每次外部副作用准备前、工具结果确认后、Agent Handoff 前后、进入人工等待前、审批生效后、最终产物提交后。每生成一个 token 都写检查点通常成本高且价值有限；只在任务完成后写又无法恢复长任务。应根据允许的重复计算量（Recovery Point Objective，RPO 的业务化解释）确定粒度。

5.3 恢复不等于继续执行同一段代码 ​

恢复器通常执行以下流程：读取权威状态与最新可用 Checkpoint；校验租户、版本与权限；重建待执行步骤；检查租约和未决外部操作；对未知结果进行核验；重建模型上下文；从明确的安全边界继续。恢复后的模型输出可能与中断前不同，因此必须保存已经对外承诺或影响副作用的决策结果，不能指望重新调用模型复现同一内容。

5.4 版本迁移 ​

检查点与事件的模式必须显式版本化。推荐记录 schema_version、engine_version、workflow_definition_version、model_configuration_version。升级时采用可测试的迁移函数，并对无法迁移的运行提供“固定旧运行时继续”“人工干预”“终止并补偿”等明确路径。部署新版代码不意味着旧运行自然兼容。

六、并发一致性：多 Agent 修改同一份状态 ​

6.1 先划分状态所有权 ​

每个 Agent 可以拥有自己的私有工作区，但共享研究提纲、证据清单、报告版本必须明确谁有写权限、如何合并，以及谁能发布。建议让“共享状态服务”负责写入验证，Agent 只提交变更提案，由服务端执行条件更新。

6.2 乐观并发控制（Optimistic Concurrency Control） ​

两个 Agent 同时读取提纲 v7：分析 Agent 提议添加行业数据，审核 Agent 提议删除无来源段落。若两者都直接覆盖全文，后提交者会抹掉前者修改。乐观锁要求写入携带 expected_version=7；第一份修改提交后变为 v8，第二份收到版本冲突，必须重新读取并合并，而非强制覆盖。

sql
UPDATE workspace
SET content = :new_content,
    version = version + 1
WHERE workspace_id = :id
  AND version = :expected_version;
-- 影响 0 行：并发冲突或资源不存在，需区分处理

6.3 合并策略 ​

可按字段或业务对象分区写入，例如每条 Evidence 有独立 ID 与版本；对可交换的集合操作进行去重合并；对高风险内容（最终结论、审批状态、发布版本）要求单写入者或人工仲裁。CRDT 适用于特定可交换数据类型，但不能自动解决“两个 Agent 对研究结论的语义冲突”。

6.4 租约、Fencing Token 与过期 Worker ​

Worker 获得租约后可能暂停很久，租约过期时新 Worker 已接管。旧 Worker 恢复后若继续写入，可能覆盖新结果。Fencing Token 为每次所有权分配提供单调递增代号，下游写入拒绝旧代号。仅有 TTL 租约而没有写入端的令牌校验，不能完全阻止“僵尸 Worker”产生副作用。对于不支持 fencing 的外部 API，还需使用幂等键、核验或其他业务级限制。

七、外部副作用：状态恢复中最危险的部分 ​

7.1 为什么“Exactly Once”需要限定范围 ​

内部数据库事务可保证某个事务内的原子性；队列可提供不同的投递语义；外部邮件、支付、发布、文件写入则受另一套系统控制。不能笼统宣称端到端“恰好一次执行”。通常可追求的是：至少一次尝试 + 稳定操作标识 + 外部幂等能力 + 状态核验 + 必要的人工对账。

7.2 外部操作台账 ​

text
operation_id: op_551
kind: publish_report
payload_hash: sha256(canonical_payload)
approval_id: approval_34
state: prepared | dispatched | confirmed | unknown | compensated
idempotency_key: publish:task_123:artifact_v9
provider_request_id: optional
last_verified_at: optional

在发起请求前持久化 prepared，发送后尽力记录 dispatched，收到可验证回执后记录 confirmed。如果在请求已到达外部系统、回执尚未持久化时崩溃，恢复时进入 unknown：先查询外部系统是否已完成，再根据供应商幂等契约决定是否重试。不能因为内部状态没有 confirmed 就断言外部未发生。

7.3 幂等键的作用域与局限 ​

幂等键应基于稳定业务意图而非随机重试次数；同一键必须绑定同一参数摘要。不同供应商对幂等键的支持、有效期和冲突行为可能不同，应按接口逐一核实。对不提供幂等能力的外部工具，应使用可查询的业务标识、预检查与事后对账；若无法确认，进入人工处理，避免盲目重复。

7.4 Saga 与补偿 ​

跨系统工作流可采用 Saga：每一步提交本地结果，失败时执行事先定义的补偿动作。但补偿不等于时间倒流：邮件发送无法真正撤回，公开报告被下载后不能保证完全消除影响。应区分可逆动作、可补偿动作、不可逆动作，不可逆动作前设置审批、双重校验或发布缓冲期。

7.5 人工审批的状态一致性 ​

审批应绑定具体 operation_id、参数摘要、资源版本、权限主体与过期时间。审批后如果 Agent 修改发布目标或报告内容，原审批必须重新确认。恢复时不能只检查布尔值 approved=true，还应校验批准的对象与即将执行的对象一致。

八、共享状态、消息与多 Agent 协作 ​

8.1 消息是通知，还是权威事实？ ​

“请审核报告 v9”可以是命令；“报告 v9 已通过审核”是事实事件；“审核 Agent 建议通过”只是提案。不同语义对应不同权限和状态转移。跨 Agent 消息即使格式正确，也不自动具有修改权威状态的权限。共享 Blackboard 可以作为协作视图，但最终发布状态仍需由受控服务提交。

8.2 Fan-out / Fan-in 的状态屏障 ​

并行检索任务 A、B、C 后，汇总节点不能只凭收到三条消息就认为三项完成：消息可能重复，结果可能来自过期 Attempt。应按逻辑 step_id 和有效版本记录完成集合，定义部分成功阈值、超时、取消与补做策略。合并时记录输入 Artifact 版本，以便追溯“这份报告由哪些证据构成”。

8.3 交接协议 ​

Agent Handoff 应至少包含任务标识、输入版本、目标 Agent、约束、截止时间、预算、已完成成果和待处理事项。交接的提交需要保证“原负责人释放”和“新负责人接管”之间没有不可解释的空档；可通过单一权威协调器、事务性状态转移或可恢复的交接状态机实现。不能仅依赖两条聊天消息完成责任转移。

九、状态架构参考：研究报告 Studio ​

9.1 建议的最小部署形态 ​

text
Web / API (L6)
      |
Task Service ---- Transactional DB (Task / Run / Approval / Event)
      |                         |
      |                      Outbox
      v                         v
Orchestrator (L5) <------ Message Broker
      |
Agent Engine (L4) ---- Checkpoint Store
      |                        |
      +---- Tool Gateway ---- External Systems
      |
      +---- Artifact Store (immutable versions)
      |
      +---- Memory / Search Index (derived or governed)

推荐将权威 Task、Approval、Operation Ledger 放在支持事务和唯一约束的数据库中；大文件报告放对象存储并通过不可变版本引用；缓存、向量索引、进度投影不作为最终权威。检查点可以与事务数据库共存，也可以独立存储，但必须有一致的恢复协议。

9.2 关键写入流程：完成审核并发布 ​

  1. 审核 Agent 生成建议和证据引用，提交待审版本 artifact_v9。
  2. Task Service 校验该版本完整性，创建 approval_request，任务进入 awaiting_approval。
  3. 用户审批 artifact_v9 与目标渠道；审批记录绑定参数摘要。
  4. 服务端事务性写入审批决定、任务状态和 Outbox 事件。
  5. 发布 Worker 获取租约与 Fencing Token，建立 operation_id，在外发前保存操作台账。
  6. Tool Gateway 校验审批仍有效、版本未变化、权限允许，随后调用外部发布 API。
  7. 依据外部回执确认结果；若结果不确定，进入核验流程。
  8. 发布成功后提交不可变发布记录和最终 Task 状态，异步更新 UI 投影。

9.3 失败场景与预期行为 ​

故障点主要风险恢复策略
模型请求中断推理成本重复从安全边界重试
Checkpoint 写入失败恢复位置丢失阻止推进或回退
数据库提交后崩溃消息未发出Outbox 补发
工具请求后崩溃外部结果未知查询与对账
Worker 租约过期双 Worker 写入Fencing + 幂等
双 Agent 修改提纲丢失更新版本冲突与合并
审批后内容变化越权发布哈希失配拒绝
旧 Checkpoint 恢复版本不兼容迁移或人工处理

十、技术方案与框架的能力边界 ​

10.1 LangGraph Checkpoint ​

LangGraph 的持久化机制通过 Checkpointer 保存图执行状态，支持线程标识、恢复与人工中断等能力。其具体持久化粒度、并发语义、节点副作用与恢复行为需要结合当前版本和部署方式确认。使用框架 Checkpoint 不等于外部 API 自动幂等，也不意味着所有用户权限与审批状态已获得可靠保障。[R1]

10.2 Temporal Durable Execution ​

Temporal 通过 Workflow History 与确定性重放恢复 Workflow 的执行逻辑，Activities 用于封装外部副作用。Workflow 重放与 Activity 重试有不同语义；Activity 可能被再次执行，因此仍需设计业务幂等和超时。对长时间运行、复杂重试与人机等待流程，Temporal 是可选方案，但需要承担工作流版本管理与运行设施成本。[R2][R3]

10.3 PostgreSQL 事务与并发控制 ​

PostgreSQL 提供事务、隔离级别、唯一约束与行级锁等机制，可实现 Task 权威状态、审批、事件和 Outbox 的原子提交。不同隔离级别的并发异常与锁行为需要按官方文档和实际事务模式验证。数据库不能替第三方 API 提供跨系统原子提交。[R4][R5]

10.4 Redis 与消息设施 ​

Redis 可用于缓存、协调、短期状态与消息能力，但是否作为权威状态源取决于持久化配置、复制与故障切换语义。不要把“写入 Redis 成功”直接解释为所有部署拓扑下都已持久化。队列确认机制也不等于业务处理恰好一次。[R6]

10.5 选型原则 ​

场景优先方案必须补充
简单单 AgentDB 状态表 + Checkpoint工具幂等
多 Agent DAGDB + Outbox + Worker并发版本控制
长期跨天流程Durable WorkflowActivity 幂等
强审计业务事件日志 + 快照模式演进
高频协作编辑细粒度版本或 CRDT语义冲突处理

不要根据“是否使用 Agent 框架”决定状态架构，而应根据任务持续时间、外部副作用、审计要求、并发规模、可接受恢复损失和团队运维能力选择。

十一、最小验证实验：乐观锁与幂等操作 ​

下面的 Python 示例使用标准库模拟状态版本检查与操作幂等，展示两个必须成立的不变量。**示例是单进程内存实验，不是生产数据库实现，也不能证明分布式 exactly-once。**配套文件 H4-Agent-System-State-Management-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 H4-Agent-System-State-Management-v1.1-demo.py。

python
from __future__ import annotations

from dataclasses import dataclass

@dataclass
class Workspace:
    version: int = 1
    content: str = "outline-v1"

    def update(self, expected_version: int, new_content: str) -> None:
        if self.version != expected_version:
            raise ValueError("version_conflict")
        self.content = new_content
        self.version += 1

class OperationLedger:
    def __init__(self):
        self.results = {}

    def apply(self, operation_id: str, payload_hash: str, fn):
        if operation_id in self.results:
            saved_hash, saved_result = self.results[operation_id]
            if saved_hash != payload_hash:
                raise ValueError("idempotency_conflict")
            return saved_result
        result = fn()
        self.results[operation_id] = (payload_hash, result)
        return result

workspace = Workspace()
workspace.update(1, "outline-v2")
try:
    workspace.update(1, "stale-write")
    raise AssertionError("conflict not detected")
except ValueError as exc:
    assert str(exc) == "version_conflict"
assert workspace.content == "outline-v2"

ledger = OperationLedger()
count = {"calls": 0}
def side_effect():
    count["calls"] += 1
    return "published"

assert ledger.apply("op-1", "hash-A", side_effect) == "published"
assert ledger.apply("op-1", "hash-A", side_effect) == "published"
assert count["calls"] == 1
try:
    ledger.apply("op-1", "hash-B", side_effect)
    raise AssertionError("payload mismatch not detected")
except ValueError as exc:
    assert str(exc) == "idempotency_conflict"
print("local invariants passed")

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

关键限制： 该台账在 fn() 成功后才记录结果；如果进程在外部副作用完成后、记录前崩溃，重新运行仍可能再次执行。真实实现必须使用持久化 prepared / unknown / confirmed 状态、外部幂等契约与核验流程。示例仅用于演示版本冲突与单进程去重，不可直接复制为生产 Tool Gateway。

11.1 故障注入测试矩阵 ​

建议至少进行以下测试：

  1. 在每个事务提交前后强制终止进程，检查是否丢失任务或出现重复派发。
  2. 在工具调用发送前、发送后、回执前、回执后分别崩溃，检查 unknown 状态与对账路径。
  3. 同时让两个 Worker 竞争同一 Run，检查租约与 Fencing Token 是否阻止过期写入。
  4. 并行让两个 Agent 更新同一 Artifact，检查版本冲突与合并机制。
  5. 在人工审批后修改发布参数，确认服务端拒绝执行。
  6. 用旧版 Checkpoint 在新版 Engine 恢复，验证迁移或明确拒绝。
  7. 模拟对象存储成功、元数据数据库失败，验证孤儿对象清理与不可见性。
  8. 模拟消息重复、乱序、延迟和消费端重启，验证状态机与去重规则。
  9. 模拟用户撤销权限、任务取消与审批过期，检查恢复后的授权再校验。
  10. 测试跨租户访问 Checkpoint、事件与 Artifact 的隔离，确认无越权读取。

11.2 验收指标 ​

应测量：恢复成功率、恢复耗时（RTO）、最大已确认工作损失、重复外部副作用次数、未知操作对账完成率、并发丢失更新次数、非法状态转移次数、审批失配拦截率、检查点存储开销、迁移成功率。具体目标阈值应由业务风险与服务等级确定，不应将示例阈值当作通用行业标准。

十二、常见反模式与纠正原则 ​

反模式一：将全部聊天记录当作状态。 纠正：拆分结构化业务状态、执行位置、上下文投影和长期记忆。

反模式二：每一步覆盖一条 JSON，没有版本。 纠正：使用状态机、乐观锁、事件历史和不可变产物版本。

反模式三：Checkpoint 保存后就认为任务“可恢复”。 纠正：验证代码版本兼容、外部副作用、待处理审批与租约恢复。

反模式四：任务失败后直接从头重跑。 纠正：区分可重算步骤与不可逆副作用，建立操作台账与核验流程。

反模式五：把消息队列当作权威状态。 纠正：明确命令、事件与投影，保证状态更新和消息派发的一致性。

反模式六：让 Agent 直接修改共享数据库。 纠正：通过受控服务执行鉴权、版本校验和业务状态转移。

反模式七：将 Memory 与 Checkpoint 混用。 纠正：分别管理生命周期、权限、来源、失效与删除。

反模式八：用重放重新调用模型和工具。 纠正：历史重放只消费已记录的确定性结果；新的外部动作必须通过正常授权与幂等路径。

十三、工程落地路线 ​

阶段 A：建立权威状态。 先实现 Task、Run、Step、Approval、ArtifactVersion、OperationLedger 的实体契约；定义状态机、不变量、唯一约束与租户隔离。此时即使只运行一个 Agent，也应保证任务可以被可靠查询与审计。

阶段 B：支持可恢复执行。 为 L4 Engine 增加持久化检查点、恢复游标和运行版本；在关键边界保存状态；恢复时重新校验权限、审批和外部操作结果。

阶段 C：支持协作与并发。 为 L5 增加 Outbox、消息去重、共享状态版本、租约与 Fencing Token；明确 Agent Handoff 的权威提交点。

阶段 D：验证故障语义。 通过故障注入覆盖数据库提交裂缝、工具未知结果、过期 Worker、并发覆盖、审批失配和旧版 Checkpoint。先证明关键不变量成立，再扩大并发规模。

阶段 E：持续治理。 建立状态模式迁移、数据保留与删除、敏感状态加密、审计追溯、容量与成本监控，并将故障恢复结果纳入 H3 Evaluation 与 H10 Testing & Validation。

研究结论 ​

  1. 状态管理的首要工作是定义权威事实和不可违反的不变量。 数据库、队列和框架只是实现这些语义的工具。
  2. 模型上下文、长期记忆、业务状态和执行检查点属于不同的数据对象。 它们的用途、生命周期、权限和恢复要求不能混同。
  3. 可恢复执行需要同时保存执行位置和外部副作用证据。 仅保存中间消息或图节点位置，无法安全处理“外部已成功但内部未知”的情形。
  4. 多 Agent 共享状态必须处理并发覆盖与过期执行者。 版本控制、状态所有权、租约和 Fencing Token 是重要基础；语义冲突仍需业务合并或人工仲裁。
  5. 端到端恰好一次不可轻率承诺。 应将幂等、重试、核验、补偿与人工对账组合为可验证的业务保障。
  6. 状态恢复是横向工程能力。 H4 贯穿 L2 - L6，并与 H1 可观测性、H2 安全、H6 人工参与、H7 可靠性、H9 数据治理 和 H10 测试 共同工作。
  7. 设计是否可靠，要由故障注入而非正常路径演示证明。 只有在崩溃、重复消息、并发冲突和审批失配下仍保持不变量，才具备可交付的状态管理能力。

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

以下优先列出官方技术资料。引用说明对应技术机制或能力边界；文中的 Studio 架构、状态机、操作台账及工程路线属于综合设计建议，不应误认为某一来源的原文规范。

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

B.1 证据分级 ​

  • 官方机制资料： PostgreSQL 事务与隔离、Temporal 工作流/Activity、LangGraph 持久化、Redis 持久化，参见 [R1] - [R6]。
  • 架构模式资料： Outbox 与 Saga 的设计模式，参见 [R7] - [R8]；跨产品实现须重新验证。
  • 本文综合推导： 状态分类、Task/Run/Step/Attempt 模型、Studio 流程、状态不变量与分阶段落地路线是面向 Agent System 的工程综合设计，不是某一框架的官方标准。
  • 概念性示例： JSON Checkpoint、SQL 更新和 Python 实验用于说明契约与边界，不能直接视为生产方案。

B.2 验证声明 ​

本专题的 Python 示例仅验证单进程乐观锁冲突与内存幂等去重，不验证跨进程事务、持久化恢复、分布式 Fencing、外部系统幂等、真实 Agent 框架或生产安全性。任何工程部署前，必须完成数据库事务测试、故障注入、权限测试、恢复演练和真实外部 API 契约验证。

B.3 适用边界 ​

本文面向具备长任务、工具调用、协作、审批或外部副作用的 Agent System。纯无状态问答服务可采用更轻量的状态架构；金融支付、医疗、法律合规和其他高风险场景需要额外遵循所在行业的法规、审计、数据保留及安全要求。本文不提供普遍适用的 RPO/RTO 数值，也不承诺特定框架在任意部署环境下提供端到端 exactly-once。

B.4 后续研究衔接 ​

下一专题为 「H5 · 如何管理 Agent System 的配置与版本？ - Configuration」。H4 解决运行状态的权威性和恢复问题；H5 将进一步研究模型、Prompt、工具、工作流、策略与运行环境的配置版本如何被锁定、发布、回滚和审计，并直接影响旧 Checkpoint 的恢复兼容性。