第（二十八）篇｜从 Capability 到可靠事务：Command Bus、Execution State Machine、Idempotency 与 Saga

创见日期：2026年9月23日

前面的治理链已经解决了一个极其重要的问题：Agent 不能因为“会调用工具”，就拥有直接修改生产环境的权力。

从 Evidence Plane、Risk Engine、Decision Trace，到 Action Gateway、Policy Enforcement Point，再到短生命周期、限定 Scope 的 Capability Token，我们逐步建立的是一条：Evidence → Decision → Authorization → Enforcement 链路。

但到了这里，系统仍然没有真正完成生产化。

因为 Capability Token 能证明“这一次动作被允许执行”，却不能证明“这一次动作最终只执行了一次”；也不能保证 WordPress 已成功、GitHub 超时、Database 已写入、Cloudflare 没有返回结果时，系统知道下一步到底应该继续、重试、暂停还是补偿。

更无法天然解决一个持续20分钟、2小时甚至跨越人工审批窗口的自动化任务，在 Worker 重启、网络抖动、API 429、进程崩溃以后，怎样从正确位置继续，而不是从头再来一次。

因此，第（二十八）篇要解决的是 Governance Engine 之后更接近生产系统本质的问题：Execution Reliability。

如果说第（二十七）篇解决的是 Who may cause a side effect?，那么第（二十八）篇解决的是 Once a side effect is authorized, how do we make the execution reliable?

这意味着，我们需要在 Action Gateway 之后继续增加一层：Execution Transaction Plane。

它至少由四个核心机制组成：Command Bus → Execution State Machine → Idempotency → Saga / Compensating Action，最终把一次“允许调用 Tool”，升级为一笔可追踪、可去重、可重试、可补偿、可恢复的生产事务。

一、真正危险的不是 Tool 调用失败，而是你不知道它到底有没有成功

传统脚本很容易写成：

call WordPress API
call GitHub API
update database
purge Cloudflare cache
send notification

理想情况下，A → B → C → D → E 全部成功。但生产环境真正发生的情况往往是：A 成功、B 成功、C 超时、D 未知、E 尚未执行。

这时最关键的问题并不是“C 报错了吗？”，而是：C 到底执行了吗？

例如 Agent 向 WordPress 发出创建文章请求，WordPress 已经完成文章创建，但响应返回途中连接断开。Agent 看到的是 Timeout。如果系统简单执行“timeout → retry”，第二次请求可能再次创建文章，于是同一任务产生两篇内容。

Timeout 并不等于 Failure，它也可能意味着 Outcome Unknown。

RFC 9110 对 HTTP 幂等方法的定义也说明了为什么这一点重要：当通信失败、客户端不知道请求结果时，幂等语义能够让请求被安全重试。但应用层的创建、发送、发布等副作用，并不会因为使用 HTTP 就自动获得业务幂等性。

因此，生产级执行系统不能只有 success / failed，而必须建立 Execution State Machine，并显式容纳 OUTCOME_UNKNOWN。

二、Capability 解决“允许”，Command 解决“这一次究竟要做什么”

Capability Token 本质上是授权凭证，它回答 Publisher Agent 是否有权在指定范围内创建 WordPress Draft。

但它没有完整描述：现在这一笔具体事务是什么？

因此 Action Gateway 不应该拿到 Capability 后直接调用 WordPress，中间还需要一个更稳定的执行抽象：Command。

{
  "command_id": "cmd_20260923_0028_01",
  "workflow_id": "wf_article_0028",
  "saga_id": "saga_publish_0028",
  "decision_id": "dec_0028_publish",
  "capability_id": "cap_wp_draft_7821",
  "command_type": "CREATE_WORDPRESS_DRAFT",
  "target": {
    "system": "wordpress",
    "resource": "post"
  },
  "payload_ref": "artifact://article/0028/v1",
  "idempotency_key": "wp:create:article-0028:v1"
}

HTTP Request 是传输行为，Command 是业务意图。单纯的 POST /posts 无法告诉系统，这是第一次创建、自动重试、人工重新触发，还是失败事务恢复后的再次执行。

三、Command Bus 不是简单 Message Queue，而是生产副作用的统一入口

这里的 Command Bus 不应该简单理解为 Kafka、RabbitMQ、SQS 或某个具体中间件。它首先是一种架构边界。

所有真正会改变外部世界状态的动作，例如 WordPress Create / Update / Publish、GitHub Branch / Commit / PR / Merge、Cloudflare Purge / DNS / Configuration、Database Insert / Update、Email Send、Webhook Dispatch、Deployment，原则上都不再允许 Agent → Tool 直接执行。

Agent
  ↓
Decision
  ↓
Capability
  ↓
Action Gateway / PEP
  ↓
Command Bus
  ↓
Execution Orchestrator
  ↓
System Adapter
  ↓
External System

这样做以后，Agent 不再控制“怎么重试、重试几次、是否重复、失败是否补偿、执行进度存在哪里”。Agent 只表达 Intent，执行基础设施负责 Execution Semantics。

Agent 决定想做什么，Governance Engine 决定是否允许做，Execution Plane 决定怎样可靠地做完。

四、Execution State Machine：生产事务必须知道自己“现在在哪”

内容生命周期与执行生命周期是两件不同的事情。内容状态机管理文章处于 DISCOVERED、RESEARCHING、DRAFTED、APPROVED、PUBLISHED 还是 MONITORING；执行状态机管理某一个已经授权的 Command 到底执行到了什么阶段。

RECEIVED
↓
VALIDATING
↓
AUTHORIZED
↓
QUEUED
↓
DISPATCHING
↓
RUNNING
├─→ SUCCESS
├─→ RETRY_PENDING → RUNNING
└─→ OUTCOME_UNKNOWN
       ↓
   RECONCILING
   ├─→ SUCCESS
   └─→ FAILED
        ├─→ COMPENSATING → COMPENSATED
        └─→ NEEDS_REVIEW

这里尤其值得增加一个过去自动化系统经常忽略的状态：OUTCOME_UNKNOWN。

API timeout、connection reset、worker crashed after send、response lost，都不应该立刻解释成 FAILED，而应该进入 OUTCOME_UNKNOWN → RECONCILING，先检查外部系统：Did the side effect already happen?

五、Idempotency：不是“不重复发请求”，而是“重复请求不能产生重复业务效果”

真正的幂等目标是：

execute(command)
execute(command)
execute(command)

最终产生的业务状态仍然等价于：

execute(command)

也就是说，同一个业务命令无论因为 Retry、Worker Restart、Message Redelivery、Network Timeout 或 Operator Replay 被执行多少次，都只能产生一次预期业务效果。

因此更现实的生产目标通常不是抽象宣称 Exactly Once Delivery，而是通过 At-least-once execution + Idempotent consumer + Deduplication + Execution journal + Reconciliation 实现 Effectively-Once Business Effect。

六、Idempotency Key 必须表达“业务身份”，而不是随机身份

如果每次重试都生成新的 UUID，那么 try 1、try 2、try 3 对执行系统来说就是三个不同命令，根本无法去重。

合理的 Idempotency Key 应该来自 Business Operation Identity，例如：

wordpress:create:article-0028:v1
github:create-pr:article-0028:v1
database:publish-record:article-0028:v1
cloudflare:purge:article-0028:v1

同一个逻辑动作无论重新进入多少次，都映射到同一执行记录。第一次执行时无记录则执行并保存结果；第二次收到同一 key，如果 SUCCESS 已存在，则直接返回之前结果；如果 RUNNING，则等待或检查；如果 OUTCOME_UNKNOWN，则先 reconcile，而不是 execute_again。

七、Command Registry：每一个副作用都必须留下“执行收据”

普通日志回答“发生过什么”，Command Registry 或 Execution Journal 则回答：这个业务动作现在到底是什么状态？

command_id
workflow_id
saga_id
decision_id
capability_id
command_type
target_system
target_resource
idempotency_key
state
attempt_count
created_at
started_at
last_attempt_at
completed_at
request_fingerprint
external_resource_id
external_version
result_reference
error_class
error_code
next_retry_at
compensation_command
compensation_state
human_review_required
correlation_id
trace_id

其中 external_resource_id 尤其重要。例如 WordPress 第一次调用成功后得到 post_id=583，以后即使 Worker 崩溃，也可以通过 command_id → execution record → post_id 583 恢复上下文。

这就是 Durable Execution State，而不是 Process Memory。前者即使 Python process died、container restarted、server rebooted、worker moved，事务仍然存在；后者进程一死，系统就失忆。

八、Retry 不是“再试一次”，而是一套故障分类系统

自动化系统里非常危险的一段逻辑是 except Exception → retry。并不是所有错误都应该重试。

类型	示例	默认策略
Success	API 2xx + 已验证	Commit
Transient Failure	429、503、临时网络故障	Backoff + Retry
Permanent Failure	权限拒绝、Schema 错误	Stop
Business Failure	Quality Gate 未通过、状态冲突	Review / Reject
Outcome Unknown	Timeout、连接中断、Worker Crash	Reconcile First

Retry 之前先 Classify Failure；OUTCOME_UNKNOWN 更不能盲目重试。

九、Idempotency 只能解决“重复”，解决不了“部分成功”

假设一次发布事务包含：Database 创建发布记录、GitHub 保存内容版本、WordPress 创建文章、WordPress 正式发布、Cloudflare 清理缓存、Database 更新 published 状态、Monitoring 创建观察任务。

如果前三步成功、第四步失败，没有重复动作，Idempotency 全部工作正常，但系统仍然进入 Partial Success。

单数据库事务可以 ROLLBACK，但 WordPress、GitHub、Cloudflare、Database 不属于同一个事务域，不存在一个全局 SQL ROLLBACK。这就是 Saga 进入系统的地方。

十、Saga：跨系统事务不是一个大事务，而是一系列小事务

Saga 将一个跨服务事务拆分为一系列本地事务。每一步在自己的系统中完成；如果后续步骤失败，则通过补偿事务处理前面已完成步骤造成的业务影响。

T1 → T2 → T3 → T4 → T5

每一步定义 Forward Action + Compensating Action，例如：

T1: Create WP Draft
C1: Trash WP Draft

T2: Create GitHub Branch
C2: Delete Temporary Branch

T3: Create Deployment Record
C3: Mark Deployment Cancelled

如果 T1、T2 成功而 T3 失败，Saga 可以执行 C2、C1，把系统带回 Business-Consistent State。

十一、补偿事务不是“时间倒流”

Compensation ≠ Rollback。

现实世界的副作用经常已经被别人看见：文章已经发布3分钟，搜索引擎已经抓取，Webhook 已通知第三方，Email 已发出，用户已经访问，GitHub Commit 已被引用。此时无法 Undo history，只能创建新的动作抵消前面的业务影响。

例如 Publish Article 的补偿可能不是 Delete Article，而是 change status to draft、create incident record、invalidate cache、mark publication as withdrawn、trigger index monitoring。

因此真正应该设计的是 Semantic Compensation，而不是 Mechanical Reverse。

十二、必须给每一种 Side Effect 分类

Command Registry 最好进一步为动作定义四种事务属性：COMPENSABLE、RETRYABLE、IRREVERSIBLE、PIVOT。

动作	类型	处理思路
创建 WP Draft	Compensable	Trash / Abandon
创建临时 Git Branch	Compensable	Delete Branch
数据库写 staging record	Compensable	Cancel / Reverse Record
WordPress Publish	Pivot / Externally Observable	谨慎补偿
Cloudflare Purge	Retryable	重复完成即可
Monitoring Record	Retryable	幂等写入
Email Send	Irreversible	尽量放最后

这会导出一个非常重要的生产原则：Irreversible Action Last。

十三、Pivot：生产事务必须明确“不可回头点”

Prepare
↓
GitHub Version
↓
WordPress Draft
↓
Validation
↓
Human Approval
↓
──────────────
PIVOT
WordPress Publish
──────────────
↓
Cloudflare Purge
↓
Monitoring Registration
↓
Publication Record
↓
COMPLETED

在 Pivot 之前发生问题，可以优先 Backward Recovery / Compensation；Pivot 之后发生问题，则更应该优先 Forward Recovery。

例如 WordPress Publish 已成功而 Cloudflare Purge 超时，此时不应该自动 Unpublish WordPress，而应该 reconcile Cloudflare → retry purge → complete monitoring。

因为事务已经跨过 Point of No Return，系统目标应该从 Return to old state 切换为 Reach intended final state。

十四、跨 WordPress、GitHub、Database、Cloudflare 的完整例子

假设 SEO 自动化系统准备发布第（二十八）篇。Governance Engine 已经产生 Decision=APPROVED，Policy Engine 生成 Capability Token，Action Gateway 验证通过，然后进入 Saga：SEO_ARTICLE_PUBLISH_V1。

Step 1：建立 Execution Record

Database 创建 execution，记录 workflow_id、saga_id、article_id、version、decision_id、capability_id。这是整个事务的根。

Step 2：GitHub 固化版本

执行 ARCHIVE_CONTENT_VERSION，使用业务幂等键 github:article-0028:v1，成功后记录 commit_sha、branch、artifact_hash。失败时仍未对外发布，风险较低。

Step 3：WordPress Draft

执行 CREATE_WORDPRESS_DRAFT，幂等键 wordpress:draft:article-0028:v1。成功后写回 post_id。如果 Worker 此时崩溃，恢复后不再 Create New Post，而是 lookup command → found SUCCESS → reuse existing post_id。

Step 4：Pre-Publish Validation

检查 title、metadata、schema、links、source citations、featured image、content hash。失败进入 NEEDS_REVIEW，而不是继续 Publish。

Step 5：Human Approval

审批本身必须进入 Execution Journal，并绑定 reviewer、approved_at、approved_version、content_hash。批准的不是抽象 article，而是 article_version + hash，避免 Approval Drift。

十五、Capability 也不能无限期复用：长事务需要重新验证授权

长期运行事务中的权限不是一次性事实，而是需要在关键执行边界重新验证的动态前提。

每个真正高风险副作用执行前，都应该重新检查：Capability valid? Decision still valid? Resource version unchanged? Policy changed? Approval still applicable?

形成：Authorize at workflow start + Revalidate at side-effect boundary。

十六、Step 6：WordPress Publish 成为 Pivot

在真正 Publish 之前，重新验证 capability、decision、content hash 和 current post state，然后执行 PUBLISH_WORDPRESS_POST。

如果返回成功，则记录 post_status、published_at、post_url、post_version，并把 Saga 进入 POST_PIVOT。从这一刻开始，后续故障默认策略不再是 Rollback everything，而应该优先 Forward Recovery。

十七、Step 7：Cloudflare Purge 失败怎么办？

如果 WordPress publish success，而 Cloudflare request timeout，错误做法是把整个发布事务标记为失败并回滚 WordPress。

正确状态应该是 ARTICLE_PUBLISHED / CACHE_STATE_UNKNOWN，然后让 Cloudflare command 进入 OUTCOME_UNKNOWN → RECONCILING。Cache purge 更适合作为最终一致性的后处理动作，重试即可。

十八、Step 8：Database 更新失败怎么办？

假设 WordPress 已发布、Cloudflare 已完成，但 Database Publication Record timeout。如果系统只看内部 Database，它可能错误判断“文章没发布”，下一轮任务再次发布。

Internal State ≠ External Reality。

因此必须引入 Reconciliation，对 WordPress reality、GitHub reality、Cloudflare reality 与 Internal journal 对账，由外部事实恢复内部状态，而不是再发布一次。

十九、Transactional Outbox：内部状态与消息也会发生“双写问题”

即使建立 Command Bus，还存在经典 Dual Write Problem。例如数据库把 command state 标记为 QUEUED，同时向 Message Bus 发送 command，这是两个不同写操作。

可能出现 Database commit success / Message send failed，也可能 Message sent / Database commit failed。

Transactional Outbox 的核心做法是把业务状态与 outbox_event 在同一个本地数据库事务中提交，再由独立 Relay 将 Outbox 内容送入消息系统。

BEGIN DATABASE TRANSACTION
INSERT command
INSERT outbox_event
COMMIT

Outbox Relay
↓
Command Bus

即使 Relay 崩溃，Outbox Event 仍然存在；重新启动后继续发送即可。如果消息重复发送，则由 idempotent consumer 去重。

二十、Saga Orchestration 还是 Choreography？

Saga 常见两种实现方式：Choreography 与 Orchestration。前者让参与服务通过事件自行协作，后者由中心协调器掌握事务流程并决定下一步。

对于 WordPress、GitHub、Cloudflare、Database、GSC/GA4 Pipeline、WeChat、Monitoring 这类并非围绕同一个 Event Domain 原生构建的系统，更适合采用 Orchestrated Saga。

Execution Orchestrator 显式掌握 next step、retry、timeout、compensation、pause、resume、human intervention，而不是让 WordPress 的事件去猜下一步应该通知 GitHub 还是 Cloudflare。

二十一、Compensation Registry：补偿动作不能失败时才临时想

生产级 Saga 最不能接受的是“发生事故后，再研究怎么回滚”。正确方法是在 Command Definition 阶段就明确 forward_action、compensation_action、pivot、retry_policy、verification。

CREATE_WORDPRESS_DRAFT

Forward:
  create draft

Verify:
  post exists
  expected hash matches

Compensation:
  trash draft

Compensation Verification:
  post status = trash

补偿动作也必须幂等。因为可能发生 Forward failed → compensation started → compensation timeout → compensation retry。若补偿本身不是幂等，系统会因为修复失败制造新的故障。

二十二、不要追求“任何错误都回滚”，优先 Forward Recovery

很多工程实现习惯“任何一步失败 → rollback all”，这仍然是在用单数据库事务思维理解分布式系统。

生产环境应该先判断：Can we continue forward safely?

Transient?
→ Retry

Outcome Unknown?
→ Reconcile

Forward path still safe?
→ Continue

Pre-pivot unrecoverable?
→ Compensate

Post-pivot?
→ Prefer forward recovery

High-risk ambiguous?
→ Human intervention

例如 WordPress publish success、Monitoring registration failed，更合理的是 Retry monitoring registration，而不是 Unpublish article。

二十三、Execution Lock：幂等也解决不了所有并发问题

假设两个不同 Command：publish article v3 与 update article v4 同时开始。它们拥有不同 idempotency_key，所以 Idempotency 完全正常，但仍可能发生 Worker B 先写入 v4，Worker A 随后又把 v3 覆盖回去。

这不是重复执行，而是 Concurrent Mutation。

因此还需要 resource version、expected version、optimistic lock、lease、semantic lock。执行前检查 current_version == expected_version；如果版本已经变化，则进入 CONFLICT → NEEDS_REVIEW，而不是继续覆盖。

二十四、Execution Plane 最终需要形成什么架构？

Agent Intent
      │
      ▼
Evidence Plane
      │
      ▼
Risk Engine
      │
      ▼
Governance Decision
      │
      ▼
Decision Trace
      │
      ▼
Capability Issuer
      │
      ▼
Action Gateway / PEP
      │
      ▼
────────────────────────────
    EXECUTION TRANSACTION PLANE
────────────────────────────
      │
      ▼
Command Bus
      │
      ▼
Execution State Machine
      │
      ▼
Saga Orchestrator
      │
      ├── Idempotency Registry
      ├── Execution Journal
      ├── Outbox / Inbox
      ├── Retry Engine
      ├── Compensation Registry
      ├── Reconciliation Engine
      └── Human Intervention Queue
      │
      ▼
System Adapters
      │
 ┌────┼────┬──────┬────────┐
 ▼    ▼    ▼      ▼        ▼
WP  GitHub DB  Cloudflare  Email

到这里，一次生产副作用才真正从 Tool Call 升级成 Governed Transaction。

二十五、这对 SEO / GEO 自动化为什么尤其重要？

SEO/GEO Automation 看起来不像银行支付系统，所以很多团队会觉得“发布文章而已，没有必要这么复杂”。这个判断只在每天人工执行一两个动作时成立。

一旦开始自动化每日 Intelligence → Research → Content Generation → GitHub Archive → WordPress Draft → Human Approval → Publishing → Cache → Monitoring → Refresh，每天几十、几百甚至几千个 Side Effect 后，小概率故障一定会不断出现。

真正需要防止的并不是“API 永远不失败”，而是：任何 API 失败以后，系统仍然知道自己在哪里。

二十六、对当前 SEO/GEO Automation 项目的落地标准

从本篇开始，每一个具有真实副作用的自动化，不再只定义 Input / Validation / Logic / Output，而应扩展为：

COMMAND
Command Type
Command ID
Workflow ID
Saga ID

DECISION
Decision ID
Capability ID
Required Permission

TARGET
System
Resource
Expected Version

IDEMPOTENCY
Business Idempotency Key
Deduplication Scope
Result Cache

EXECUTION
State
Timeout
Retry Policy
Concurrency Policy

VERIFY
Success Condition
Read-back Verification
External Resource ID

COMPENSATION
Compensable?
Compensation Command
Compensation Verification

TRANSACTION
Pivot?
Irreversible?
Forward-Recovery Policy

OBSERVABILITY
Trace ID
Correlation ID
Metrics
Logs

RECOVERY
Reconciliation Strategy
Manual Intervention Policy

这不是另起炉灶，而是把现有规范里的 Retry、Failure Handling、Rollback 从“字段要求”提升为真正的 Execution Architecture。

二十七、需要重点禁止的六种反模式

1. Agent → Production API：绕过 Command Bus。
2. timeout → blind retry：不区分 Outcome Unknown。
3. random idempotency key on every attempt：让所谓幂等形同虚设。
4. process memory = workflow state：进程死亡后任务彻底失忆。
5. failure → rollback everything：不区分 Pivot 与不可逆动作。
6. compensation = delete：把复杂业务恢复错误理解成机械反向操作。

只要这些模式仍然存在，系统就仍然是“自动执行脚本”，而不是“可靠事务系统”。

二十八、本项目的原创判断：真正的 Agent Reliability 不是模型更聪明，而是副作用具有事务语义

AI Agent 领域很容易把 Reliability 理解为模型少犯错、Prompt 更严格、Reasoning 更强、Tool Selection 更准确。这些属于 Decision Reliability，而不是 Execution Reliability。

一个模型完全可能判断正确、权限正确、工具正确、参数正确，最后仍然因为 timeout、duplicate delivery、worker crash、partial success、concurrent update 制造生产事故。

因此成熟 Agent Architecture 需要至少区分：Reasoning Reliability、Governance Reliability、Execution Reliability。

第（二十六）篇
Evidence / Risk / Decision Trace
↓
为什么允许

第（二十七）篇
Action Gateway / PEP / Capability
↓
谁被允许执行什么

第（二十八）篇
Command Bus / State Machine / Idempotency / Saga
↓
允许之后怎样可靠完成

于是 Agent 系统才从“AI makes decisions and calls tools”升级成：

AI proposes actions
Governance authorizes actions
Capabilities constrain authority
Command Bus serializes intent
State Machine persists progress
Idempotency neutralizes duplication
Saga manages partial failure
Compensation restores business consistency
Reconciliation repairs uncertainty
Humans handle irreducible ambiguity

这才是真正适合生产环境的 Governed Durable Execution。

二十九、最终架构判断

第（二十七）篇结束时，我们可以说：没有 Enforcement Point，Policy 只是建议。

第（二十八）篇结束以后，还需要再增加一句：没有 Durable Execution，Authorization 只保证动作“合法开始”，却不能保证它“可靠结束”。

真正成熟的自动化系统不能只回答 Can this Agent execute?，还必须持续回答：

• Has this command already executed?
• What exactly succeeded?
• What remains unfinished?
• Is the result unknown?
• Can it be retried safely?
• Should we continue forward?
• Should we compensate?
• Has compensation succeeded?
• Did an external system diverge from our internal state?
• Can the transaction resume after the process dies?
• Does a human need to intervene?

只要其中任何一个问题系统无法回答，所谓 Fully Autonomous Agent 都仍然只是一个能够连续调用 API 的程序，而不是一个真正能够承担生产责任的执行系统。

三十、从“安全调用”到“可靠事务”

Tool Call
↓
Authorized Tool Call
↓
Governed Command
↓
Durable Command
↓
Idempotent Command
↓
Saga Transaction
↓
Recoverable Production Workflow

系统的关注点也从“执行成功了吗？”升级成：“这笔生产事务当前处于什么状态，系统是否知道事实，是否可以安全继续，最终是否能够收敛到一个一致状态？”

可靠系统并不是“从来不失败”的系统，而是即使任意一步失败，它仍然知道已经发生了什么、下一步应该做什么，以及怎样安全地恢复。

第（二十九）篇预告

当 Command Bus、Execution State Machine、Idempotency、Saga 与 Compensation 建立以后，下一个问题自然出现：如果内部状态写着 SUCCESS，但 WordPress 实际不存在；如果 Worker 永久死亡留下 RUNNING 任务；如果补偿只完成一半；如果 DLQ 中积累了几十个无人处理的命令，系统怎样主动发现这些“幽灵事务”？

第（二十九）篇将进入：Execution Journal / Reconciliation Engine / Dead Letter Queue / Repair Queue / Operator Console，解决状态漂移、孤儿任务、永久失败、补偿失败和人工修复的问题，把 Recoverable Execution 进一步升级为 Operational Recoverability。

来源与延伸阅读

• Microsoft Azure Architecture Center：Saga Distributed Transactions Pattern
• Microsoft Azure Architecture Center：Compensating Transaction Pattern
• AWS Prescriptive Guidance：Saga Patterns
• AWS Prescriptive Guidance：Saga Orchestration
• AWS Prescriptive Guidance：Transactional Outbox Pattern
• RFC 9110：HTTP Semantics — Idempotent Methods

标签：AI Agent, Agentic Workflow, Command Bus, Execution State Machine, Idempotency, Saga Pattern, Compensating Transaction, Durable Execution, Transactional Outbox, Reconciliation, WordPress Automation, GitHub Automation, SEO Automation, GEO Automation