第（二十九）篇｜从可恢复执行到可运营系统：Execution Journal、Reconciliation Engine、DLQ、Repair Queue 与 Operator Console

创见日期：2026年9月23日

第（二十八）篇解决了一个生产自动化中的核心问题：Capability 已经允许执行之后，跨 WordPress、GitHub、Cloudflare、Database 等多系统动作，怎样做到不重复执行、失败可补偿、长流程可恢复。

为此我们建立了：Command Bus → Execution State Machine → Idempotency → Saga → Compensating Action，并进一步引入 Outcome Unknown、Execution Journal、Transactional Outbox、Pivot、Forward Recovery 与 Reconciliation。

但到这里，系统仍然存在一个非常现实的问题：

谁来发现那些“理论上可恢复，但实际上一直没有恢复”的事务？

例如 Execution Journal 写着 SUCCESS，但 WordPress 实际已经 404；Command State 仍是 RUNNING，但 Worker 已经死亡 40 分钟；Saga 卡在 COMPENSATING；Database 记录为 published，但 Monitoring 从未创建。

这些事务并不一定会继续报错，它们更危险，因为系统可能已经停止报错，却没有真正达到正确状态。

因此，第（二十九）篇要解决的问题不再只是“失败以后怎样恢复”，而是：系统怎样知道自己还有哪些东西没有恢复？

这意味着 AI Agent 生产架构需要从 Recoverable Execution 进一步升级为 Operational Recoverability：系统不仅具有恢复机制，还能够主动发现偏差、隔离异常、生成修复任务、支持人工运营，并持续证明真实世界最终收敛到了预期状态。

一、最大的生产事故，往往不是 FAILED，而是“永远没有结束”

很多自动化系统只关注 SUCCESS 与 FAILED，因此监控也只盯 failed_jobs > 0。但进入长流程自动化以后，很多事故根本不会产生一个明确 FAILED。

最典型的是 RUNNING 一直存在。Worker 可能在请求发送后崩溃，数据库仍保留 RUNNING。如果没有主动检查机制，这个事务可能永远留在系统里：没有报错、没有重试、没有 DLQ、也没有人工处理。

这类任务可以称为 Orphaned Execution，即孤儿执行。

成熟运行系统必须理解：RUNNING 本身不是事实，只是系统最后一次知道的状态。随着时间推移，这个状态的可信度不断降低，最终必须重新验证。

二、Execution Journal 不是普通日志，而是事务的“控制账本”

普通日志回答“发生了什么”，Execution Journal 回答“这笔事务现在被系统认为是什么状态”。

workflow_id
saga_id
command_id
desired_state
recorded_state
observed_state
attempt
lease_owner
heartbeat_at
external_resource_id
external_version
last_transition_at
next_retry_at
deadline_at
compensation_state
reconciliation_status
repair_status
operator_status

这里最重要的变化，是增加 desired_state / recorded_state / observed_state。真正可靠的运行系统不能只保存“我们曾经做过什么”，还必须保存“我们希望世界现在是什么样”。

三、从 State Machine 升级到 Desired State Model

Execution State Machine 管理 QUEUED、RUNNING、SUCCESS 等执行阶段，但 SUCCESS 只是一个历史判断，不是当前事实。

例如 10:00 WordPress publish success，10:01 Execution Journal=SUCCESS，11:00 管理员手工删除文章。此时内部仍然 SUCCESS，外部现实却是 POST_NOT_FOUND。

因此长期运行的自动化系统需要同时维护：

Desired State
↓
Recorded State
↓
Observed Reality

当 Desired 与 Observed 不一致时，真正需要处理的是 DRIFT，而不是“最后一次命令是否返回 200”。

四、Reconciliation Engine：可靠系统必须持续“对账”

Reconciliation Engine 负责周期性回答三个问题：

1. What should be true?
2. What is actually true?
3. Are they the same?

Desired State
   ↓
Observe Reality
   ↓
Compare
   ├─ MATCH → HEALTHY
   └─ DRIFT → CLASSIFY → REPAIR

这类设计与 Kubernetes Controller 的 reconciliation 思路一致：Controller 持续观察当前状态，并推动实际状态向期望状态靠近。

对于 AI Agent 自动化尤其重要，因为 Agent 往往天然偏向“再执行一个动作”，而 Reconciliation 思维要求的是：先观察，再行动。

五、Reconciliation 不是“重新执行一遍工作流”

错误实现是发现状态异常后直接 rerun workflow。因为 GitHub commit、WordPress post、Database record、Cloudflare cache、Email 等一部分可能已经存在，整体重放会重新制造副作用。

正确方式是：

Observe
↓
Diff
↓
Repair Minimum Drift

例如 Desired 为 WordPress=published、Monitoring Record=exists，而 Observed 为 WordPress=published、Monitoring Record=missing。系统应该只执行 CREATE_MONITORING_RECORD，而不是重新发布文章。

Reconciliation ≠ Replay；Reconciliation = State Diff + Minimal Repair。

六、SEO/GEO 自动化需要一套统一的 State Vector

为了让 Reconciliation 可规模化，不能让每个 Agent 临时判断。建议为每一个发布事务建立 Execution State Vector：

content.version = v29
github.commit = abc123
wordpress.post_id = ...
wordpress.status = publish
cloudflare.cache = refreshed
database.publication = confirmed
monitoring.registered = true
analytics.annotation = created

Reconciliation Engine 从各系统读取 Observed State Vector，再与 Desired State Vector 比较。这样系统得到的是精确的 drift 列表，而不是笼统的“整个 workflow failed”。

七、Reconciliation 必须区分 CONFIRMED、MISSING 与 UNKNOWN

外部世界并不总能返回简单的 YES / NO，因此 Observed State 至少应允许：

CONFIRMED
MISSING
UNKNOWN

WordPress 返回 200 可以是 CONFIRMED，404 可以是 MISSING，timeout 应该是 UNKNOWN。

UNKNOWN 绝不能被错误解释成 MISSING。否则一次读取超时就可能触发重复创建、重新发布或错误补偿。

八、Reconciliation Engine 的推荐状态机

PENDING
↓
OBSERVING
↓
COMPARING
├─ MATCH → HEALTHY
└─ DRIFT
   ↓
CLASSIFYING
   ├─ AUTO_REPAIR
   ├─ RETRYABLE
   └─ MANUAL
        ↓
     REPAIR_QUEUE
        ↓
      VERIFY
   ├─ HEALTHY
   └─ ESCALATE

Repair 后必须再次 Verify。Repair Command 返回 200 并不等于 Repair Outcome 成功。

九、孤儿任务需要 Lease 与 Heartbeat，而不是只看 RUNNING

一个 RUNNING 任务还必须回答“谁负责它”。因此建议增加：

lease_owner
lease_acquired_at
lease_expires_at
heartbeat_at

如果 Reconciliation Engine 发现 state=RUNNING、lease expired、heartbeat stale，就不应继续相信 RUNNING，而应转换为 ORPHAN_SUSPECTED，再去检查外部状态，决定 RESUME、RETRY、SUCCESS、REPAIR 或 MANUAL。

十、不要把 Worker Crash 当成 Workflow Failure

Worker Process 与 Workflow Execution 不是同一个生命周期。Worker 可以 crash、restart、scale down、move node、upgrade，但 Workflow 应继续存在。

Durable Execution 的核心原则之一是：Process death is not workflow death.

如果 Worker 消失，真正需要检查的是“谁应该接管 lease”，而不是“是否重新创建整个 workflow”。

十一、DLQ：失败任务不能无限重试

如果一个任务已经证明自动重试无法解决，就应该进入 Dead Letter Queue。

DLQ 的作用不是“存放垃圾”，而是 Quarantine Unresolved Work：把无法安全继续自动处理的任务从正常执行路径中隔离出来。

Main Queue
↓
Retry
↓
Retry
↓
Retry Budget Exhausted
↓
DLQ

进入 DLQ 并不意味着任务结束，而是任务退出自动执行通道，等待诊断、修复和受控 redrive。

十二、DLQ 不应该成为“失败坟场”

有 DLQ 不等于系统可靠。如果半年没人看、没有 Owner、没有 SLA、没有报警、没有修复，DLQ 只是 Failure Cemetery。

因此：进入 DLQ 必须意味着有人或某个 Repair Agent 接手。

十三、Retry Queue、DLQ 与 Repair Queue 必须分开

队列	意义	默认动作
Retry Queue	暂时无法处理	等待后自动重试
DLQ	自动处理路径已经失败	隔离、诊断
Repair Queue	已经形成修复计划	等待修复或审批

Cloudflare 503 更适合进入 Retry Queue；WordPress permission denied 经过确认后可能进入 DLQ；认证修复后，再生成 Repair Queue 工作项进行受控 Redrive。

十四、每一条 Dead Letter 都必须携带“为什么死”

建议建立 Failure Envelope：

command_id
workflow_id
saga_id
failed_step
failure_class
failure_code
failure_reason
first_failed_at
last_failed_at
attempt_count
last_external_status
payload_reference
decision_id
capability_id
recommended_repair
human_review_required

Operator 打开任务时看到的应该是明确的业务上下文，而不是一条孤立的 Error 500。

十五、Redrive 不能等于“全部重新执行”

DLQ 修复后，不能简单 replay 原始请求，因为外部状态可能已经变化。正确 Redrive 前应再次执行 Reconciliation：

DLQ Item
↓
Observe Current State
↓
Re-evaluate Preconditions
↓
Revalidate Capability
↓
Generate Repair Command
↓
Redrive

Repair ≠ Replay。

十六、Poison Message 与 Environment Failure 必须区分

持续失败至少可能来自两类原因。

第一类是任务本身有问题，例如 invalid schema、malformed payload、unsupported field、bad content。这类属于 Poison Work Item，重复执行不会解决问题。

第二类是运行环境有问题，例如 WordPress outage、GitHub API unavailable、DNS issue、expired credential、Cloudflare rate limit。这属于 Environmental Failure。

因此 DLQ 分类至少应该区分：

DATA_ERROR
SCHEMA_ERROR
BUSINESS_RULE_ERROR
AUTH_ERROR
PERMISSION_ERROR
DEPENDENCY_ERROR
CONCURRENCY_CONFLICT
TIMEOUT_UNKNOWN
RESOURCE_MISSING
STATE_DRIFT
COMPENSATION_FAILURE

十七、Repair Queue：把“异常”转化成正式工作项

DLQ 解决的是自动执行不能继续，而真正修复问题需要 Repair Queue。Repair Queue 中放的不是原始 Command，而应该是 Repair Plan：

repair_id
source_command
source_saga
drift
root_cause
repair_action
risk_level
required_capability
approval_required
verification_plan
rollback_or_compensation

例如 Monitoring record missing，可以生成 CREATE_MONITORING_RECORD 的低风险修复任务，并在完成后重新 GET 验证。

十八、Repair Command 必须重新经过治理系统

系统出了问题，并不意味着 Repair Agent 应该拥有更高权限。Repair 仍然是 Side Effect。

因此 Repair Agent 也必须经过：

Evidence
↓
Risk
↓
Decision
↓
Capability
↓
PEP
↓
Command Bus

不能因为“这是修复”就绕过 Governance，否则 Repair Agent 会成为整个系统最大的后门。

十九、补偿失败必须成为一等状态

Saga 不能只设计 FAILED → COMPENSATING → COMPENSATED。现实中还会出现：

COMPENSATION_PENDING
COMPENSATING
COMPENSATED
COMPENSATION_FAILED
COMPENSATION_UNKNOWN

例如 Trash WordPress Draft 失败返回 403。如果系统没有 COMPENSATION_FAILED 状态，Operator 可能误以为事务已经回滚。

COMPENSATION_FAILED 应自动生成 Repair Item，而不是只写一行 Error Log。

二十、Operator Console：最终必须让人看见系统真正的问题

随着 Agent、Workflow 与 Command 数量增加，问题不能继续依赖 grep logs。

Operator Console 的目标不是漂亮的大屏，而是让运营人员快速回答：现在什么坏了？影响什么？为什么坏？系统做过什么？我能安全做什么？

二十一、Operator Console 第一屏应该是什么？

第一屏不应首先展示 Total Commands Today，而应该展示 Exceptions：

Open Incidents          3
DLQ                     7
Repair Queue            4
Stale RUNNING           2
Compensation Failed     1
State Drift             5
Approval Required       3

因为正常成功任务通常不需要人处理，真正稀缺的是 Operator Attention。因此 Operator Console 应采用 Exception-First Design，而不是 Activity-First Design。

二十二、每一笔异常至少需要展示哪些字段？

Workflow
Saga
Command
Business Object
Desired State
Observed State
Drift
Last Known Good State
Attempts
Failure Classification
Dead Letter Reason
Compensation State
Repair Recommendation
Risk
Required Approval
Decision Trace
Capability Trace
External Resource IDs
Related Logs
Trace ID
Timeline

Timeline 尤其重要。它能够让 Operator 看见从 APPROVED、PUBLISH、UNKNOWN、RETRY、DLQ、RECONCILIATION 到 REPAIR_CREATED 的完整演变，而不是只看到最后一个错误字符串。

二十三、Operator 能执行什么动作？

建议严格限制为：

RETRY
RECONCILE
REDRIVE
REPAIR
COMPENSATE
PAUSE
RESUME
CANCEL
MARK_RESOLVED
ESCALATE

不应该提供 Run arbitrary tool。Operator Console 不能成为生产 Shell。

每一个按钮都应该生成 Operator Command，并重新进入 Governance + Command Bus，保持权限、审计和幂等语义一致。

二十四、人工修复也必须幂等

Operator 点击 Repair 后浏览器卡顿，再点一次，系统不能执行两次修复。因此人工动作同样需要 repair_id 与 idempotency_key。

Idempotency 必须覆盖 Automation + Human Operations，而不是只存在于机器自动化路径。

二十五、Reconciliation 什么时候运行？

最稳妥的方式是 Event-driven 与 Periodic Sweep 结合。

Event-driven Reconciliation：command completed、worker restarted、external webhook arrived、repair completed 时立即 reconcile。

Periodic Sweep：定期扫描 RUNNING too long、UNKNOWN too long、DLQ too old、COMPENSATING too long、REPAIR_PENDING too long。

Event 驱动负责快，Periodic Sweep 负责兜底。

二十六、不要要求系统永远“立即一致”

分布式系统经常采用 Eventual Consistency。因此 Reconciliation Engine 需要 Consistency Window。

例如 WordPress Publish 成功后，Cloudflare edge 可能需要短暂时间传播。系统不应该在 10ms 后发现差异就直接触发 incident，而应允许 state=CONVERGING；超过合理窗口后再转换为 DRIFT。

这能避免大量 False Positive Repair。

二十七、还要防止“观察数据本身是旧的”

Reconciliation 还有更深层的问题：你读取到的 Reality 真的是 Reality 吗？Database replica、API cache、local worker cache、CDN API 都可能返回旧状态。

因此高风险 Repair 前最好明确 Observation Freshness：

observed_at
source
version
etag
resource_version

否则 stale observation 可能引发 incorrect repair。

二十八、Logs、Metrics、Traces 与 Execution Journal 不能互相替代

成熟系统至少需要四类运行数据：

• Execution Journal：What is the business transaction state?
• Logs：What happened inside a component?
• Metrics：How much / how often?
• Traces：How did one request travel through the system?

trace_id 应进入 Execution Journal，但 Trace 不能代替 Execution State。

二十九、需要建立哪些运行指标？

自动化 KPI 不应该只统计 Success Rate，至少还应该加入：

Stuck Execution Rate
Orphan Recovery Rate
State Drift Rate
Reconciliation Success Rate
DLQ Entry Rate
DLQ Age
Repair Queue Depth
Repair Success Rate
Mean Time To Repair
Compensation Failure Rate
Unknown Outcome Rate
Manual Intervention Rate

尤其重要的是 DLQ Age。DLQ size=1 看起来问题不大，但如果这个任务已经存在 17 天，风险可能远高于今天刚进入 DLQ 的 20 条临时任务。

三十、推荐建立 Automation Reliability SLO

示例：

99% commands reach terminal state within 15 minutes
99.9% high-risk commands have verified external outcome
100% DLQ items have owner
100% compensation failures create Repair Item
95% repair items resolved within SLA
0 orphaned production execution older than 24h

这些数字不应直接照搬，应根据系统风险、业务量与影响逐步设定。真正重要的是，系统开始为异常恢复能力建立可衡量的服务目标。

三十一、完整生产架构现在变成什么？

Agent
↓
Evidence Plane
↓
Risk Engine
↓
Governance Decision
↓
Decision Trace
↓
Capability Issuer
↓
Action Gateway / PEP
↓
Command Bus
↓
Execution State Machine
↓
Saga Orchestrator
├─ Idempotency Registry
├─ Transactional Outbox
├─ Retry Engine
└─ Compensation Engine
↓
Execution Journal
↓
Reconciliation Engine
├─ External State Probes
├─ Drift Detector
├─ Orphan Detector
└─ Consistency Window
↓
Healthy / Exception
        ↓
Retry Queue / DLQ
              ↓
        Repair Planner
              ↓
         Repair Queue
      ┌───────┴────────┐
      ↓                ↓
 Auto Repair      Operator Console
      └───────┬────────┘
              ↓
        Repair Command
              ↓
      Governance / PEP
              ↓
          Command Bus
              ↓
            Verify

这才形成真正完整的 Closed-Loop Execution System。

三十二、这里才真正出现“闭环自动化”

Trigger → Agent → Tool 并不是 Closed Loop，而只是 Open-Loop Automation，因为它缺少 Observe Outcome、Compare、Correct。

真正闭环应该是：

Decide
↓
Execute
↓
Observe
↓
Compare
↓
Repair
↓
Verify
↓
Observe Again

真正的 Agent 自动化并不是调用完成，而是状态收敛。

三十三、对当前 SEO/GEO 自动化项目意味着什么？

当前项目已经要求 Orchestrator 负责状态机、任务分配、依赖检查、Quality Gate、人工审批、Retry 与 Failure Escalation。

第（二十九）篇的意义，是把现有 Logging、Retry、Failure Escalation 继续升级为 Durable Journal、Reconciliation、Dead Letter Management、Repair Workflow 与 Operator Operations，也就是从“记录失败”升级成“管理失败直到最终关闭”。

三十四、Automation Job Schema 下一步应该增加什么？

execution_id
command_id
workflow_id
saga_id
desired_state
recorded_state
observed_state
lease_owner
heartbeat_at
lease_expires_at
external_resource_id
external_resource_version
last_reconciled_at
reconciliation_result
drift_type
dead_lettered_at
dead_letter_reason
repair_id
repair_status
repair_owner
compensation_state
operator_action
trace_id
correlation_id
resolved_at
resolution_type

Automation Job 不再只是 Job Log，而是逐步成为 Operational Execution Record。

三十五、需要禁止的八种新反模式

1. SUCCESS 就永远不再验证：外部状态仍然可能变化。
2. RUNNING 没有 Heartbeat：无法知道 Worker 是否已经死亡。
3. DLQ 无 Owner：失败任务进入无人负责状态。
4. DLQ 直接 Replay：不先 Reconcile 当前事实。
5. Repair Agent 拥有超级权限：以修复名义绕过 Governance。
6. Operator Console 可以任意调用 Tool：把 UI 变成生产 Shell。
7. Compensation Failure 只记录 Error：不进入 Repair Queue。
8. Logs 被当作 Source of Truth：通过 grep 推测当前业务状态。

三十六、本项目的原创判断：真正自治的系统必须“拥有自己的异常”

AI Agent 讨论 Autonomy 时，经常关注自己研究、自己判断、自己执行、自己调用工具，但成熟自治能力还需要一个更少被讨论的维度：Exception Ownership。

系统制造的异常，系统必须能够找到；系统能够找到的异常，必须能够进入一个明确的修复生命周期。

真正的自治应该至少包括 Autonomous Planning、Autonomous Execution、Autonomous Observation、Autonomous Reconciliation、Autonomous Repair 与 Human Escalation。

Autonomy 不是没有人，而是让人只处理真正无法自动安全收敛的不确定性。

三十七、人类角色从“流程执行者”变成“异常决策者”

传统自动化：
人执行 → 机器辅助

初级 Agent：
机器执行 → 人审核

成熟 Agent：
机器执行
↓
机器验证
↓
机器修复
↓
机器再验证
↓
无法安全收敛
↓
Human Operator

人的核心工作不再是 Approve everything，而是 Resolve exceptions、Handle ambiguity、Change policy、Improve repair playbooks。

三十八、SEO/GEO 自动化真正要追求的不是 Success Rate，而是 Convergence Rate

Task Success Rate=98% 看起来很好，但那 2% 如果没有恢复、没有 Owner、没有告警、没有补偿、没有关闭，就不能证明系统可靠。

更合理的指标应该逐渐转向 Convergence Rate：最终有多少事务到达了被验证的正确状态。

过程中发生 retry、worker crash、temporary outage、compensation、repair 都不是最终重点。真正重要的是：最终状态是否正确。

因此可靠自动化的最终指标不是“第一次有没有成功”，而是“系统最终有没有收敛”。

三十九、从 Tool Execution 到 Operational Control Loop

第（二十七）篇解决谁可以执行；第（二十八）篇解决怎样可靠执行；第（二十九）篇进一步解决怎样持续证明执行结果仍然正确。

Tool Call
↓
Authorized Action
↓
Durable Command
↓
Recoverable Transaction
↓
Observed Transaction
↓
Reconciled Transaction
↓
Repairable Transaction
↓
Operationally Managed Transaction

Side Effect 最终被升级为 Managed State。

四十、最后一个关键判断：自动化不是“做完”，而是“闭环”

过去 API 200 就被视为 DONE；后来 Command SUCCESS 被视为 DONE；再后来 Saga COMPLETED 被视为 DONE。

真正生产化以后：

Desired State
=
Observed State
+
Verification
=
DONE

只有当期望、记录、现实三者一致时，事务才真正 CLOSED。否则，它仍然是一个 Open Operational Obligation。

结语：可靠系统最大的能力不是“永远正确”，而是“错误无法消失”

第（二十八）篇建立的核心思想是：可靠系统不是永远不失败，而是失败以后仍然知道自己在哪里。

第（二十九）篇进一步补充：可运营系统不是没有异常，而是任何异常都不能悄悄消失。

每一个 stuck command、orphan workflow、state drift、unknown outcome、dead letter、failed compensation、manual repair，都必须被发现、被分类、被分配、被修复、被验证、被关闭。

Execute
↓
Observe
↓
Reconcile
↓
Repair
↓
Verify
↓
Close

这是从 Durable Execution 进一步升级到 Operational Control Loop，也是 AI Agent 真正进入长期无人值守生产环境之前必须补齐的一层。

第（三十）篇预告

当 Execution Journal、Reconciliation Engine、DLQ、Repair Queue 与 Operator Console 建立之后，下一个问题自然出现：如果异常开始集中爆发怎么办？

例如 WordPress API 大面积异常、Cloudflare 配置错误、新版本 Worker 造成批量失败、错误 Policy 一次性授权大量 Command、新 Agent Version 产生系统性错误。这时问题已经不再是一笔事务如何 Repair，而是怎样阻止整个自动化系统继续扩大事故。

因此第（三十）篇将进入 SLO / Incident Detection / Circuit Breaker / Kill Switch / Break Glass / Incident Command，正式建立生产事故控制面。

来源与延伸阅读

• Kubernetes Documentation — Controllers
• Kubernetes Documentation — Objects in Kubernetes
• Kubernetes v1.36 — Controller Staleness Mitigation
• Amazon SQS — Dead-Letter Queues
• Azure Service Bus — Dead-Letter Queues
• Temporal Documentation — Durable Execution
• OpenTelemetry Documentation

标签：AI Agent, Agent Reliability, Reconciliation Engine, Execution Journal, Dead Letter Queue, DLQ, Repair Queue, Operator Console, Durable Execution, Saga, Incident Recovery, Automation Reliability, WordPress Automation, GitHub Automation, SEO Automation, GEO Automation