SEO / GEO 工作自动化部署与实践规范（三十三）：Desired State / Configuration Management / GitOps / Drift Detection / Configuration Provenance / Policy Drift——让生产环境持续等于被批准的状态

创作日期：2026年9月27日

第（三十二）篇，我们建立了：

Change Manifest
↓
Change Intelligence
↓
Release Policy
↓
Release Gate
↓
Progressive Exposure
↓
Canary Evaluation
↓
Promote / Hold / Rollback
↓
Post-release Verification

核心原则是：

Exposure must be earned by evidence.

一个已经获得 Governance Approval 和 Capability 的 Change，也不能因此直接获得 100% Production Exposure。必须先 Limited Exposure → Observe → Verify → Promote。

到这里，我们已经能够比较可靠地回答：How should an approved change safely enter production?

但系统还有另外一个更隐蔽的问题。

假设一个 Change 在星期一已经完成：GitHub PR merged → Cloudflare deployed → WordPress updated → Release Gate passed → Production verified。

星期三，一名管理员进入 WordPress 后台手工修改了 canonical。

星期四，一个插件升级以后重新写入 robots meta。

星期五，Cloudflare Dashboard 中的一条 Route 被手工修改。

星期六，数据库里的某个 Automation Config 被另一个脚本覆盖。

星期日，一个 OPA 节点因为同步异常仍然运行旧 Policy Bundle。

这时系统可能没有任何新的 Change Request，没有 Release，也没有 Deployment，但生产环境已经发生了变化。

Last Verified State
≠
Current Production State

于是第三十三篇真正要解决的问题出现了：

系统怎样持续证明 Actual State 仍然等于 Approved Desired State？

核心链路必须从：

Desired State
↓
Apply
↓
Verify

升级为：

Desired State
↓
Apply
↓
Observe Actual State
↓
Normalize
↓
Diff
↓
Detect Drift
↓
Classify Drift
↓
Assess Risk
↓
Reconcile / Accept / Escalate
↓
Verify
↓
Update Provenance

这就是第三十三篇要建立的：

Desired State Control Plane

以及：

Continuous State Reconciliation

1、生产系统不能只记住“最后一次部署成功”

很多自动化系统实际上只有 deployment_status = success，然后默认 production still equals that deployment。

这是一个非常危险的假设。因为生产环境在 Deployment 结束以后仍然可能持续变化。

变化可能来自 Human、Agent、Plugin、API、Provider、Migration、Autoscaler、External Controller、Third-party System、Emergency Fix。

Deployment Success
≠
Persistent State Integrity

2、从 Change Control 进入 State Control

第（三十二）篇管理的是 Change Lifecycle。第三十三篇管理的是 State Lifecycle。

前者关注：一个变更怎样安全进入系统？后者关注：系统现在到底是什么状态？

3、最基础的模型只有两个状态

Desired State：系统应该是什么样。

Actual State：系统现在实际上是什么样。

4、Kubernetes 已经把这种思想做成核心控制模型

Kubernetes 将对象视为系统意图记录；对象的 spec 描述期望状态，而 status 描述当前状态，控制平面持续工作，使实际状态趋向用户声明的期望状态。Deployment Controller 同样根据声明的 Desired State，以受控方式推动 Actual State 收敛。

Desired State
↓
Controller
↓
Actual State
↓
Observe
↓
Compare
↓
Reconcile

5、SEO / GEO 自动化也需要这个模型

例如 Desired State：

canonical =
https://example.com/product-a/

Actual State：

canonical =
https://example.com/category-a/

这不是新的 Content Request，而是：Drift。

6、Drift 的本质

Drift
=
Actual State
-
Approved Desired State

更准确地说：任何未被当前 Desired State 所解释的生产状态差异。

7、Drift 不一定意味着错误

例如管理员进行了一个合法 Emergency Fix，Actual State changed，但尚未把修改反向写入 Desired State Repository。

此时 Actual ≠ Desired，但 Actual 可能反而是正确的。

Drift
≠
Automatically Wrong

Drift 首先意味着：状态出现了尚未被治理系统解释的一致性差异。

8、Drift Detection 与 Auto Rollback 不能画等号

最危险的实现之一是 Detect Diff → Immediately overwrite production。这可能把刚刚完成的紧急修复自动覆盖掉。

正确链路应该是：

Detect
↓
Classify
↓
Understand Provenance
↓
Assess Risk
↓
Choose Reconciliation Direction

9、第（三十三）篇首先需要建立 Desired State Registry

系统必须明确 What is the intended state? 不能依赖 whatever production looked like yesterday。

所以需要：Desired State Registry。

10、Desired State Registry 存什么？

resource_id
resource_type
environment
desired_payload
desired_hash
source
source_revision
approved_by
decision_id
change_id
release_id
effective_from
expires_at
schema_version
policy_version

11、例如 WordPress Desired State

{
  "resource_type": "wordpress_post",
  "resource_id": "1000058",
  "desired": {
    "slug": "change-intelligence-release-gate-progressive-delivery-canary-feature-flag-automated-rollback",
    "status": "publish",
    "canonical": "self",
    "robots": "index,follow",
    "category": "SEO"
  }
}

以后系统知道：这些字段不是“当前碰巧这样”，而是这些字段就是被批准的状态。

12、不是所有 WordPress 字段都应该进入 Desired State

例如 modified_gmt、view_count、comment_count、plugin-generated cache、runtime metadata 可能不适合。

因此必须区分 Managed Fields 和 Observed Fields。

13、Managed Field

表示 Governance System 声明这个字段应该保持什么状态，例如 slug、status、canonical、robots、schema type、template assignment。

14、Observed Field

表示我们需要监控，但并不直接控制。例如 crawl timestamp、Google index state、GA4 sessions、Core Web Vitals、server response time。

不能因为 sessions changed 就执行 reconcile sessions。

15、第三种字段：Derived State

例如 Rendered Canonical。它不是直接存储配置，可能由 WordPress post + Rank Math settings + theme + plugin 共同生成。这属于 Derived State。

16、SEO 系统特别需要 Derived State

因为搜索引擎看到的通常不是数据库字段本身。Googlebot 看到的是最终 Rendered HTML、HTTP Headers、Redirect Chain、Robots Rules、Structured Data、Canonical。

所以 Desired State 不能只覆盖 Database State，还必须覆盖 Externally Observable State。

17、于是形成三个层次

Configuration State
↓
Runtime State
↓
External Observed State

例如 canonical：

Rank Math Setting
↓
Rendered HTML
↓
Crawler-visible Canonical

三层都应该能够关联。

18、Desired State 不一定全部存 Git

GitOps 很重要，但 GitOps ≠ Everything Must Literally Be A YAML File。

OpenGitOps 的正式原则强调：GitOps 管理的系统应具备声明式 Desired State、版本化和不可变历史、自动拉取 Desired State，并持续观察 Actual State、尝试向 Desired State 收敛。

真正重要的是：Declarative、Versioned、Traceable、Reconciled。

19、因此本项目不应机械理解 GitOps

对于 Cloudflare Worker、Infrastructure Config、OPA Policy、Automation Config，Git 很适合成为 Authoritative Desired State Source。

但对于 WordPress Content、GSC Observations、GA4 Metrics，不能简单全部转换成 Git YAML。

20、需要建立 Source-of-Truth Matrix

Resource                 Source of Truth

Worker Code              Git
Workflow                 Git
Release Policy           Git / Policy Registry
OPA Policy               Signed Policy Bundle
WordPress Article        CMS + Content Manifest
SEO Critical Fields      Desired State Registry
Analytics Data           GSC / GA4
Execution State          Execution Journal
Release State            Release Journal
Incident                 Incident Registry

21、每一种资源都必须有唯一权威方向

系统最危险的情况之一是 Git says A、WordPress says B、Database says C、Agent Memory says D，然后没有人知道 Who wins?

22、所以每个资源必须定义 Authoritative Source

{
  "resource_type": "cloudflare_worker",
  "authoritative_source": "github",
  "reconciliation_direction": "SOURCE_TO_RUNTIME"
}

23、Reconciliation Direction 非常关键

Git → Production 表示 Production Drift 应该优先回到 Git。但对于 Emergency Fix，Production → Git 可能才是正确处理。

24、所以必须支持两种 Reconciliation

Forward Reconciliation 与 Reverse Reconciliation。

25、Forward Reconciliation

Desired
→
Actual

例如 Git replicas = 3，Actual replicas = 4，系统把 Actual 恢复到 3。

26、Reverse Reconciliation

Actual
→
New Desired

例如 Incident Commander 在事故中手工关闭某个功能。这个 Hotfix 被确认正确以后，Actual State 应该产生 Change Request → Git Commit → New Desired State，而不是被旧 Desired State 覆盖。

27、所以 Reconciliation 本身也是 Change

不能 Drift detected → silent repair，而应该：

Drift detected
↓
Reconciliation Decision
↓
Change / Repair Command
↓
Capability
↓
Execution
↓
Verification

28、GitOps 的核心其实是 Reconciliation

OpenGitOps 的第四项原则是 Continuously Reconciled。即 Agent 持续观察 Actual State，并尝试应用 Desired State。

这不是 Git commit → run deployment once，而是 Git ↔ Runtime 之间持续存在控制关系。

29、Argo CD 是典型例子

Argo CD 会比较 Git 中的 Desired Manifests 与 Cluster Live State；当两者不同，Application 会成为 OutOfSync，系统可以人工或自动同步回目标状态。它还支持可选的 selfHeal，在 Live State 偏离 Git State 时触发自动同步。

30、但 Self-Heal 不能直接复制到所有 SEO 系统

Kubernetes Resource 的 Desired replica count = 3 很适合自动 reconcile。但 WordPress editor changed headline 不能立即假定 unauthorized，因为编辑行为可能合法。

所以 SEO / GEO 平台必须建立：Drift Policy。

31、Drift Policy 回答

Which drift
may auto-reconcile?

Which drift
may only alert?

Which drift
requires approval?

Which drift
must trigger incident?

32、Drift 需要正式分类

EXPECTED_DRIFT
AUTHORIZED_DRIFT
UNAUTHORIZED_DRIFT
SYSTEM_GENERATED_DRIFT
EXTERNAL_DRIFT
UNKNOWN_DRIFT
CRITICAL_DRIFT

33、EXPECTED_DRIFT

例如 runtime timestamp、cache token、autoscaling replica count、temporary health metadata。这些变化可能是设计的一部分，不应该产生事故。

34、AUTHORIZED_DRIFT

例如 Emergency Fix 拥有 break_glass_id、incident_id、actor、expires_at。虽然 Actual ≠ Desired，但偏移具有授权依据。

35、UNAUTHORIZED_DRIFT

例如 canonical changed，但系统找不到 change_id、approval_id、capability_id、incident_id。这是非常不同的一类事件。

36、SYSTEM_GENERATED_DRIFT

例如插件升级后自动改变 schema markup。它不是人工操作，但同样不意味着 safe。

37、EXTERNAL_DRIFT

例如 Cloud Provider、Third-party SaaS、DNS Provider、Managed Database 自动发生的变化。这种 Drift 可能无法由本系统直接控制。

38、UNKNOWN_DRIFT

当系统无法判断来源时，provenance = UNKNOWN。不要让 LLM 猜 probably administrator，应该明确 UNKNOWN。

39、CRITICAL_DRIFT

例如 robots.txt 中出现 Disallow: /，或者 homepage noindex，或者 production credential permission widened。这种偏移必须直接进入 Incident Detection。

40、Drift Detection 不能只做文本 Diff

例如 index,follow 和 follow,index 语义相同。如果只做字符串比较就会产生大量噪声。

因此需要：State Normalization。

41、先 Normalize，再 Diff

Desired Raw State
↓
Normalize
      ↕
Normalize
↑
Actual Raw State
↓
Semantic Diff

42、什么叫 Normalization？

例如 URL https://example.com/a 和 https://example.com/a/ 是否等价，必须由 Canonicalization Rules 确定，不能每个 Agent 自己解释。

43、JSON / YAML 也需要 Normalize

{“a”:1,”b”:2} 与 {“b”:2,”a”:1} 不应该产生配置 Drift。

44、Cloudflare Rule 也可能需要语义归一化

Provider 可能 reorder fields、add defaults、normalize expressions，于是 Raw Diff 不一定等于 Semantic Drift。

45、Kubernetes 本身也说明了这个问题

Kubernetes Declarative Management 中，kubectl apply 会综合 Configuration File、Live Configuration 与 Last Applied Configuration 计算变更；服务端还可能给字段写入默认值，因此 Live State 并不总是与原始文件逐字符一致。

所以真正可靠的 Drift Detection 必须理解 System Defaults、Managed Fields、Ownership、Normalization。

46、于是需要 State Schema

{
  "field": "robots",
  "type": "set",
  "order_sensitive": false,
  "managed": true,
  "criticality": "P0"
}

这样 Drift Engine 才知道怎样比较。

47、建立 Drift Detection Engine

输入 Desired State、Actual State、State Schema、Resource Ownership、Provenance、Current Incident Context。

输出 No Drift、Expected Drift、Authorized Drift、Unknown Drift、Critical Drift。

48、Drift Detection 必须是持续的

不能只 after deploy，应该包括 Post-deployment Check、Scheduled Scan、Event-triggered Scan、On-demand Scan、Pre-change Scan。

49、Post-deployment Drift Check

第（三十二）篇 Release → Verify，第三十三篇增加：

Release
↓
Verify
↓
Register Desired State
↓
Start Continuous Reconciliation

50、Scheduled Scan

robots.txt
hourly

canonical templates
hourly

WordPress critical SEO fields
daily

low-risk content metadata
weekly

频率根据 Criticality + Change Frequency + Detectability Requirement 决定。

51、Event-triggered Drift Detection 更重要

例如 WordPress Webhook post_updated 立即触发 State Comparison，而不是等第二天批处理才发现。

52、Cloudflare / GitHub 等同样如此

理想模型 External Change Event → State Observer → Drift Engine。如果没有可靠事件源，Polling 作为补充。

53、Drift Detection 还应该在 Change 之前发生

假设准备发布 Change B，但 Production 已经存在 Change A 造成的未解释 Drift。如果继续执行 B，Expected Base State ≠ Actual Base State，那么 Change B 的 Diff 可能已经不可信。

54、所以增加新的 Precondition

No Unresolved Critical Drift
→
Change May Start

反过来：

Unresolved Critical Drift
→
Release Gate Closed

55、这和第三十二篇 Release Gate 直接结合

Release Preconditions 从 system_health、monitoring_health、rollback_ready、required_guards、capability、approval 增加 drift_status。

56、Drift Risk 也应该进入 Risk Engine

不是所有 Drift 一样危险。可以考虑 Resource Criticality、Semantic Scope、Unknown Provenance、Reversibility、Time Since Drift、Exposure、Policy Impact。

57、例如 Title Drift

单页面可能只是 P3，只需要 Alert。

58、Canonical Template Drift

一个 Template，Direct Resource = 1、Derived URLs = 20,000，可能是 P0。

Drift Risk
≠
Number of modified objects

59、需要 Semantic Drift Radius

第三十二篇已经建立 Semantic Blast Radius。第三十三篇对应建立 Semantic Drift Radius，即当前 Drift 实际可能影响多少业务和搜索行为。

60、例如 robots.txt Drift

changed resource = 1，但 semantic drift radius = SITE_WIDE，因此直接 CRITICAL_DRIFT。

61、Terraform 给出了另一类典型 Drift 模型

Terraform 将资源在工作流之外被修改、导致资源不再与 Terraform State 一致的情况称为 resource drift；refresh-only 操作可以用于检查实际基础设施与当前 state 的差异，而不直接修改远程资源。

检测到 Drift 后，需要判断是接受实际变化并更新 Configuration，还是重新应用 Configuration 把资源恢复到原状态。

Detect
≠
Automatically Revert

62、这也是本项目需要采用的原则

发现 Drift 后，Actual → Desired 和 Desired → Actual 都可能成立。关键是：Which state is authoritative now?

63、建立 Reconciliation Decision

{
  "drift_id": "drift_882",
  "resource": "robots.txt",
  "classification": "UNAUTHORIZED_DRIFT",
  "risk": "CRITICAL",
  "decision": "RESTORE_DESIRED_STATE"
}

64、另一个案例

{
  "drift_id": "drift_991",
  "resource": "worker-route",
  "classification": "AUTHORIZED_DRIFT",
  "incident_id": "inc_229",
  "decision": "PROMOTE_ACTUAL_TO_DESIRED"
}

65、第三种案例

{
  "classification": "UNKNOWN_DRIFT",
  "decision": "FREEZE_AND_REQUIRE_REVIEW"
}

而不是强行选择某一侧。

66、Reconciliation Decision 应固定输出类型

IGNORE
OBSERVE
ALERT
RESTORE_DESIRED
ACCEPT_ACTUAL
REQUIRE_APPROVAL
FREEZE
ESCALATE_INCIDENT

67、不要使用自由文本

例如 probably okay 在 State Control 中没有意义。

68、Auto-Reconciliation 应非常克制

可以自动修 known low-risk config、ephemeral runtime settings、well-tested reversible state。

但不应该默认自动修 content、canonical、robots、permissions、DNS、database、security policy，除非明确 Policy 允许。

69、Auto-Reconcile 也必须经过 Capability

不能因为叫 self-healing 就绕过第（二十七）篇。

Drift
↓
Reconciliation Decision
↓
Capability
↓
Action Gateway
↓
Repair Command
↓
Verification

70、Self-Healing 不是新的超级权限

No Valid Decision
→
No Capability

No Capability
→
No Production Mutation

71、Configuration Management 必须正式进入系统架构

NIST SP 800-128 将 Configuration Management 的目标描述为管理和监控系统配置，以降低组织风险并支持业务功能；NIST SP 800-53 的 CM-2 进一步要求建立、记录、维护并按条件更新当前 Baseline Configuration。

对于本项目，可以将其工程化为：

Configuration Baseline
+
Change Control
+
Continuous Monitoring
+
Drift Detection
+
Reconciliation

72、Baseline Configuration 与 Desired State 有区别

Desired State 可以非常细：this one article、this one worker、this one policy。

Baseline 更像一个系统或环境被批准的整体配置基线。

73、例如 SEO Publisher Baseline

Worker entry:
src/index.ts

Cron:
0 21 * * *

workers_dev:
true

preview_urls:
false

Git branch:
main

WordPress author:
SEO Publisher

Production direct publish endpoint:
absent

74、我们的文章发布流程本身就是一个实际案例

一次性发布期间：

wrangler.main
=
oneoff publisher

这是 Temporary Approved Drift。

发布完成后：

wrangler.main
=
src/index.ts

重新回到 Production Baseline。

75、如果一次性发布器没有被删除呢？

文章可能已经成功发布，但生产系统已经发生 Configuration Drift，甚至 Security / Control Drift，因为 /publish-now 仍然存在。

76、所以 Article Published ≠ Change Fully Closed

真正 Closure 还应该包含：

Target Outcome Verified
+
Temporary Config Removed
+
Baseline Restored
+
Drift Check Passed

77、这意味着第三十二篇的 Release Receipt 还可以再扩展

{
  "release_id": "rel_882",
  "final_state": "VERIFIED",
  "baseline_check": "PASS",
  "temporary_resources_removed": true,
  "post_release_drift": "NONE"
}

78、于是出现一个新的原则

No Baseline Verification
→
No Change Closure

79、Desired State 还必须版本化

不能只有 current desired state，应该有 v31、v32、v33，否则发生 Incident 时无法回答：当时系统本来应该是什么状态？

80、每次 Desired State 变化都应该形成 Revision

例如 desired_revision: ds_20260927_1142，并关联 change_id、approval_id、release_id、commit_sha、policy_revision。

81、这就是 Configuration Provenance

不能只问 What is the config? 还要问 Where did it come from? Who approved it? Which change created it? Which artifact produced it? Which policy evaluated it? When did it become effective?

82、Provenance 与普通 Audit Log 不一样

Audit Log 可能回答 Alice changed X at 10:00。Provenance 更强调 Current X derives from which source through which transformation under which approval using which artifact。

83、SLSA 的 Provenance 思路可以作为重要参考

SLSA 1.2 将 provenance 定义为能够把软件 Artifact 沿复杂供应链追溯到其来源的可验证信息，包括它在何处、何时以及怎样被产生；其 Build Provenance 将构建输出关联回生成它的源码和构建过程。

对于本项目，可以借鉴这种思想建立 Configuration Provenance，但这不是 SLSA 官方定义的 Configuration Provenance 标准。

84、例如 Worker Configuration Provenance

{
  "resource": "seo-publisher",
  "desired_revision": "ds_882",
  "source": {
    "repository": "seo-publisher",
    "commit": "abc123"
  },
  "change_id": "chg_771",
  "release_id": "rel_992",
  "decision_id": "dec_112",
  "artifact_hash": "sha256:...",
  "deployed_at": "...",
  "verified_at": "..."
}

85、WordPress 同样可以有 Provenance

{
  "post_id": 1000058,
  "source_article_revision": "article_32_v1",
  "publisher": "seo-publisher",
  "change_id": "chg_...",
  "release_id": "rel_...",
  "content_hash": "sha256:...",
  "published_at": "..."
}

86、以后如果正文被手工修改

新的 Actual Hash 为 sha256:B，Desired Hash 为 sha256:A，Drift Engine 可以立即知道 content drift detected。

87、但 Hash 只能告诉你“变了”

它不能告诉你 what changed，因此需要 Hash Check + Semantic Diff。

88、SEO Semantic Diff 应该有自己的模型

Title:
changed

Meta Description:
unchanged

Canonical:
changed

Robots:
unchanged

Schema:
changed

Body:
2 paragraphs changed

而不是只输出 HTML differs。

89、Semantic Diff 需要 Criticality

whitespace
LOW

copy
MEDIUM

canonical
HIGH

noindex
CRITICAL

90、这会显著降低 Drift Alert Fatigue

如果所有变化都 RED ALERT，最终人类会忽略整个系统。因此要建立 Drift Severity。

91、Drift Severity 可以是

INFO
LOW
MEDIUM
HIGH
CRITICAL

但不能只靠字段类型，还要看 Resource Scope、Business Criticality、Provenance、Reversibility、Exposure。

92、UNKNOWN Provenance 应提高风险

同样的 canonical change，approved change 和 unknown source 风险不同。因此 Unknown Provenance → Risk Penalty。

93、Provenance Freshness 也重要

例如系统知道 current state came from release X，但这个记录已经 30 days old，期间没有持续确认。这时 Confidence 不应该仍然是 100%。

94、所以可以建立 State Confidence

State Confidence
=
Observation Freshness
× Provenance Quality
× Control Coverage
× Verification Quality

这是本项目的工程抽象，不是行业标准公式。

95、State Confidence 低时应该怎样？

例如 Actual State Observation = STALE，那么系统不应该继续声称 IN_SYNC，更合理的是 STATE_UNKNOWN。

96、状态系统必须允许 UNKNOWN

Desired State 系统必须允许：

IN_SYNC
OUT_OF_SYNC
UNKNOWN
UNOBSERVABLE

97、Monitoring Failure 也会影响 Drift Detection

如果 Observer 已经停止，No Drift Alert 不能解释成 No Drift。它只能说明：We do not know。

98、所以增加 Observer Health

observer_last_success
observer_latency
resource_coverage
scan_error_rate
event_stream_health

99、如果 Observer Health 失效

则 State Confidence 下降，高风险 Action 可以自动进入 DEFER。

Policy Drift：比 Configuration Drift 更危险的一层

100、Policy 本身也是生产状态

第（二十五）篇已经建立 Policy-as-Code。但如果 Git policy = v42，生产 OPA 节点 policy = v39，会发生什么？

101、这不是普通配置问题

Same Request
+
Different Policy Version
=
Different Governance Decision

这意味着控制平面自身已经不一致。所以必须单独建立：Policy Drift。

102、Policy Drift 可以定义为

Approved Policy State
≠
Effective Enforcement Policy State

103、Policy Drift 的典型形式

old policy still active
wrong environment policy
partial rollout
unsigned policy
policy bundle missing
local override
bootstrap config override
policy data stale

104、OPA 本身提供了重要的版本和状态信息

OPA Bundles 可以让节点从远端加载和更新 Policy/Data；其 Status API 能报告已下载和激活 Bundle 的状态与 active revision，而 Decision Logs 还能够记录产生某次决策时所使用的 Bundle Revision。

这意味着决策系统可以真正回答：Which policy revision made this decision?

105、这应该成为本项目硬要求

每一个 Governance Decision 的 decision_id 必须关联 policy_revision，否则未来无法证明这个 ALLOW 当时到底依据哪套规则产生。

106、Policy Revision 不应该只存在控制面

Execution Receipt 也应保存 decision_id、policy_revision、capability_id。

107、这样才能检测 Decision / Execution Policy Drift

例如 Decision created under policy v41，但执行前 current critical policy = v42。如果 v42 已经撤销这种动作，old ALLOW 还能继续执行吗？

108、默认答案应该是重新评估

Critical Policy Changed
↓
Invalidate / Re-evaluate
Outstanding Capability

109、这叫 Policy Epoch

可以为关键 Policy 建立 policy_epoch。例如 epoch = 109，Capability issued_policy_epoch = 108。如果系统要求 latest_policy_required = true，则旧 Capability INVALID。

110、这样可以防止“旧授权穿越新规则”

09:00 ALLOW
09:05 security rule tightened
09:10 old capability executes

这种路径就会被阻止。

111、Policy Drift 不只是版本落后

还有 Policy Data Drift。例如 Policy Code 一样都是 v42，但 approved_domain_allowlist 一台节点是新版，一台节点是旧版，Decision 仍然可能不同。

112、所以 Policy State 应包括

Policy Code Revision
+
Policy Data Revision
+
Schema Revision
+
Runtime Configuration

113、OPA 的 Discovery 模型也说明配置本身需要中心化治理

OPA Discovery 可以让节点定期下载 Discovery Bundle，并据此集中配置 Bundle、Status、Decision Log 等插件；Discovery Bundle 还可以进行签名验证。

对于本项目，它提供的重要工程启发是：Policy Engine 的 Configuration 本身也必须成为 Desired State。

114、不能只监控“策略有没有更新”

还应该监控：Did every enforcement point activate the correct revision?

115、建立 Policy Fleet State

OPA-01   v42   ACTIVE
OPA-02   v42   ACTIVE
OPA-03   v41   DRIFT
OPA-04   UNKNOWN

116、出现不同版本时怎么办？

对于普通低风险 Policy 可以 ALERT。对于 Production Mutation Policy，FAIL CLOSED 可能更合理。

117、因为 Governance Consistency 本身是 Safety Invariant

No production write
may be authorized by
an unapproved policy revision.

Configuration Ownership

118、Drift 的根本问题之一是“谁能改”

如果同一个字段同时被 GitOps Controller、Human Admin、WordPress Plugin、Agent、Cron Job 修改，那么系统会不断发生 Configuration War。

119、所以每个 Managed Field 应有 Owner

robots:
SEO Control Plane

worker_code:
Git

wp_body:
Content System

wp_canonical:
SEO Governance

DNS:
Infrastructure Control Plane

120、Owner 不是“负责人姓名”

这里的 Owner 是：哪个控制系统对这个字段拥有最终写入权。

121、Kubernetes 也明确提醒管理方式冲突问题

Kubernetes Declarative Management 文档指出，同一个对象应避免同时由不同管理方法竞争控制；从 declarative writer 转向 direct imperative writer，或反向迁移，都需要明确处理字段所有权。这对 Agent 系统尤其重要。

122、所以建立 Field Ownership Registry

{
  "resource": "wordpress_post",
  "field": "canonical",
  "owner": "seo-control-plane",
  "other_writers": "DENY"
}

123、未经 Owner 的写入可以直接产生 Drift Event

例如 source = wp_admin、field = canonical、owner = seo_control_plane，结果为 OWNERSHIP_VIOLATION。

124、这比普通 Diff 更有价值

因为系统不仅知道 what changed，还知道 who was allowed to change it。

Drift Suppression 也需要治理

125、现实系统中一定会有 Ignore Rules

例如 ignore generated timestamp、ignore autoscaled replica、ignore plugin cache key。这很正常。

126、但 Ignore Rule 本身非常危险

因为 Ignore canonical 就可以让一个重大 Drift 永远消失。

127、因此 Drift Ignore Rules 本身应该 Policy-as-Code

每一条 Ignore 的 field、scope、reason、owner、expires_at、approval 都必须可审计。

128、Temporary Ignore 必须过期

例如 ignore field X until migration complete 不能永久存在，否则临时例外会变成 permanent monitoring blind spot。

Configuration Baseline 与 Environment

129、Desired State 不能脱离 Environment

同样的配置 debug = true，在 staging 可能合理，在 production 可能错误。

130、所以 Desired State 必须绑定 Environment

resource
+
environment
+
desired revision

131、Environment Promotion 应复制 Artifact，而不是重新生成

build once
↓
test
↓
promote same artifact

这样可以减少 environment-specific build drift。

Drift 与 Secret

132、Secret Drift 不能通过明文 Diff

例如 WORDPRESS_APP_PASSWORD 不能为了 Drift Detection 把 Secret 全部存入 Desired State Repository。

133、Secret Desired State 应保存 Reference

secret_ref
version
provider
rotation_epoch
fingerprint

而不是 secret_plaintext。

134、需要区分 Secret Value 与 Secret Binding

我们真正需要确认的可能是 Worker uses secret version 42，而不是保存 Secret 内容。

Drift 与 Database

135、数据库 Drift 也不仅是 Schema Drift

Schema Drift
Reference Data Drift
Permission Drift
Trigger Drift
Stored Procedure Drift
Migration Drift

136、Reference Data 特别容易被忽略

例如 allowed_domains、risk_thresholds、site_registry 都可能保存在 Database。它们实际上属于 Control Configuration，应该进入 Desired State。

Drift 与 AI Agent

137、Agent Prompt 也可能是 Configuration

例如 publisher system prompt、auditor instructions、tool descriptions、model settings、temperature、schema。这些都会改变 Agent 行为，所以 Agent Runtime Configuration 同样需要版本化。

138、Model Change 也可能造成 Semantic Drift

假设 prompt unchanged、tool unchanged，但模型从 model A 切换到 model B，系统行为可能变化。因此 Model Version 也应该进入 Runtime Provenance。

139、这属于 Dependency Drift

CONFIG_DRIFT
POLICY_DRIFT
DEPENDENCY_DRIFT
MODEL_DRIFT
SCHEMA_DRIFT
PERMISSION_DRIFT
SECRET_DRIFT

140、但 Model Drift 不应该等于“模型回答变了”

这里只讨论生产配置中的模型或模型版本是否偏离批准状态，不是讨论模型统计行为监测。后者应该另建 Model Behavior Monitoring。

Continuous Reconciliation Engine

141、最终需要一个正式 Reconciliation Engine

它不是第（二十九）篇的 Execution Reconciliation Engine 的重复。

第（二十九）篇回答 Did the command actually finish?

第三十三篇回答 Does production still match the intended state?

142、两个 Reconciliation 必须分开

Execution Reconciliation 管理 Command State。State Reconciliation 管理 System State。

143、State Reconciliation Loop

READ DESIRED
↓
READ ACTUAL
↓
NORMALIZE
↓
DIFF
↓
CLASSIFY
↓
ASSESS
↓
DECIDE
↓
RECONCILE
↓
VERIFY
↓
RECORD
↓
REPEAT

144、每一次循环都需要 Reconciliation ID

例如 reconciliation_id: rec_20260927_0182，方便后续 Trace、Incident、Audit、Metric 关联。

145、Reconciliation 也应该产生 Receipt

{
  "reconciliation_id": "rec_882",
  "resource": "robots.txt",
  "desired_revision": "ds_42",
  "actual_hash_before": "A",
  "drift": "CRITICAL",
  "decision": "RESTORE_DESIRED",
  "execution_id": "exec_901",
  "actual_hash_after": "B",
  "verification": "PASS"
}

Drift Metrics

146、系统应该开始衡量 Drift

Drift Detection Rate
Mean Time To Detect Drift
Mean Time To Reconcile
Unknown Drift Rate
Critical Drift Count
Repeat Drift Rate
Auto-Reconcile Success Rate
Stale Desired State Rate
Policy Version Divergence

147、最值得关注之一是 Unknown Drift Rate

如果系统不断发现 something changed，但不知道 who / why / through which workflow，说明 Control Plane Coverage 存在严重缺口。

148、第二个关键指标是 Repeat Drift

例如 canonical 每天被 Plugin 重写，系统每天又修回来。这不是 self-healing success，而是 unresolved ownership conflict。

149、不要让 Reconciliation 掩盖 Root Cause

Plugin changes canonical
↓
Controller changes it back
↓
Plugin changes it again
↓
Controller changes it back

这叫 Configuration Oscillation。

150、Configuration Oscillation 必须触发升级

如果 same drift repeats N times，系统应该 STOP AUTO-RECONCILIATION → ESCALATE → IDENTIFY WRITER CONFLICT。

151、否则系统可能无限消耗 API

甚至制造 incident。

Drift 与 Incident Learning

152、Drift 也应该进入第三十一篇 Failure Mode Registry

FM-021
Uncontrolled WordPress Admin Change

FM-022
Policy Bundle Version Divergence

FM-023
Plugin-generated SEO Metadata Drift

FM-024
Production Hotfix Not Backported

153、重大 Drift 应产生 Postmortem

如果 Drift 导致 indexing loss、traffic loss、security impact、production outage，就已经不只是 Configuration Event，而是 Incident。

154、Postmortem 又会产生新的 Safety Invariant

No production canonical
may be modified outside
SEO Control Plane.

155、再产生新的 Guard

例如 canonical hash monitor，于是 Drift → Incident → Learning → Stronger Drift Control。

GitOps 与本项目真正的结合方式

156、Git 不应该只是 Code Repository

对于可声明配置：Worker Config、Release Policy、Action Taxonomy、Risk Threshold、Schema、Automation Config、Infrastructure，Git 应逐渐成为 Governed Desired State Ledger。

157、但 Git Commit 本身仍不是批准

Commit
↓
PR
↓
Review / Governance
↓
Merge
↓
Release
↓
Verification

158、不能形成 Git Backdoor

如果 merge to main = automatic unlimited production mutation，那么第（二十五）到（三十二）篇建立的治理层会被绕开。

159、所以 GitOps 也必须经过 Action Gateway

Git Desired State
↓
Reconciler
↓
Governance
↓
Capability
↓
Action Gateway
↓
Production

对于低风险预授权资源可以简化，但高风险状态不能因为 it came from Git 就免除治理。

160、Git 是证据，不是万能权限来源

这是第三十三篇一个非常重要的边界。

161、完整架构

                     INTENT
                        │
                        ▼
                 CHANGE MANIFEST
                        │
                        ▼
                  EVIDENCE PLANE
                        │
                        ▼
                    RISK ENGINE
                        │
                        ▼
                GOVERNANCE ENGINE
                        │
                        ▼
                     DECISION
                        │
                        ▼
                    CAPABILITY
                        │
                        ▼
                  ACTION GATEWAY
                        │
                        ▼
                   COMMAND BUS
                        │
                        ▼
                EXECUTION ENGINE
                        │
                        ▼
                 RELEASE CONTROL
                        │
                        ▼
              PROGRESSIVE DELIVERY
                        │
                        ▼
                    VERIFY
                        │
                        ▼
               DESIRED STATE REGISTRY
                        │
           ┌────────────┴────────────┐
           │                         │
           ▼                         ▼
      DESIRED STATE             ACTUAL STATE
           │                         │
           └────────────┬────────────┘
                        ▼
                  NORMALIZATION
                        │
                        ▼
                 SEMANTIC DIFF
                        │
                        ▼
                 DRIFT ENGINE
                        │
                        ▼
                DRIFT CLASSIFIER
                        │
                        ▼
              RECONCILIATION POLICY
                        │
          ┌─────────────┼──────────────┐
          ▼             ▼              ▼
       ACCEPT        RESTORE         ESCALATE
          │             │              │
          ▼             ▼              ▼
   UPDATE DESIRED   ACTION GATEWAY   INCIDENT
          │             │              │
          └─────────────┼──────────────┘
                        ▼
                    VERIFY
                        │
                        ▼
               CONFIG PROVENANCE
                        │
                        ▼
                 STATE HISTORY
                        │
                        ▼
                LEARNING PLANE

162、于是系统形成三个时间尺度

第一层：Execution Time，秒到分钟，回答 Command 是否执行成功？

163、第二层

Release Time，分钟到小时，回答 Change 是否安全完成 rollout？

164、第三层

State Time，小时、天、月，回答 Production 是否仍然保持在被批准状态？

165、只有三层同时成立

才能真正声称 Production Controlled。

166、最终新的 Safety Invariants

此前已经有：

No Valid Decision
→
No Capability

No Capability
→
No Production Mutation

No Release Gate
→
No Exposure Expansion

No Post-release Verification
→
No Release Completion

第三十三篇增加：

No Desired State
→
No Reliable Drift Detection

167、再增加

No Provenance
→
No Trusted Configuration State

168、以及

No Current Observation
→
No Claim Of In-Sync

169、Policy 层再增加

No Approved Policy Revision
→
No Production Authorization

170、最后增加

Unresolved Critical Drift
→
No New High-risk Release

结语：真正可靠的自动化，不只是把正确的变更安全发布出去，而是让生产状态持续保持在被批准的边界之内

第三十二篇解决：

How does change
safely enter production?

第三十三篇进一步解决：

After it enters production,
how do we know
production still equals
what we approved?

这看起来只是多了一层 Drift Detection，实际上它改变的是整个系统的治理模型。

过去：

Deploy
↓
Success
↓
Forget

未来：

Declare
↓
Approve
↓
Release
↓
Verify
↓
Observe
↓
Compare
↓
Reconcile
↓
Verify Again

生产状态不再是一个发布动作留下的结果，而变成：一个被控制系统持续维护、持续验证、持续解释的状态。

真正成熟的 Autonomous SEO / GEO Platform 不应该只能回答 What did the Agent do? 还必须能够回答：

What should production
look like right now?

What does production
actually look like?

Where are they different?

Is the difference expected?

Who or what caused it?

Was that actor authorized?

Which approved change
explains the state?

Which policy revision
is active?

Which state is authoritative?

Should we restore production?

Should we accept production
as the new desired state?

Is this drift dangerous enough
to freeze future changes?

当这些问题能够被机器回答以后，Git、WordPress、Cloudflare、Database、Policy、Automation Config、Agent Runtime 才真正开始进入同一套 Desired State Governance。

这时 GitOps 也不再只是 Git push → automatic deploy，而变成：

Versioned Intent
↓
Governed Change
↓
Controlled Release
↓
Observed Reality
↓
Continuous Reconciliation

第三十二篇的核心是 Release Progressively。第三十三篇增加 Reconcile Continuously。

于是目前完整原则可以继续扩展为：

Execute Fast
Stop Faster
Recover Carefully
Learn Permanently
Release Progressively
Reconcile Continuously

最终，一个真正成熟的 Agent Production Platform 不应该把“系统现在是什么样”交给猜测。它应该始终拥有：

Desired State
+
Actual State
+
Diff
+
Provenance
+
Ownership
+
Reconciliation Policy

因为：如果系统不知道自己“本来应该是什么样”，它就永远无法真正知道自己是否已经偏离安全状态。

而当 Desired State、Configuration Provenance、Drift Detection 与 Policy Drift 被正式纳入 Control Plane 后，SEO / GEO 自动化才真正从 Automated Change System 升级为：

Continuously Governed Production System

官方依据与工程边界说明

本文提出的 Desired State Control Plane、Desired State Registry、Semantic Drift Radius、State Confidence、Drift Policy、Reconciliation Decision、Configuration Provenance、Policy Epoch、Policy Fleet State、Field Ownership Registry 等，是本 SEO / GEO 自动化项目在前述 Governance、Execution、Release 与 Reliability 架构上的工程抽象，并不是 CNCF、OpenGitOps、Kubernetes、Argo CD、HashiCorp、OPA、NIST 或 SLSA 共同定义的一套统一 Agent Configuration Governance 标准。

OpenGitOps Principles：OpenGitOps v1.0.0 将 GitOps 原则明确为 Declarative、Versioned and Immutable、Pulled Automatically、Continuously Reconciled。本篇采用的 Desired State → Observe Actual State → Reconcile 框架与这一控制思想一致，但扩展到了 WordPress、SEO Config、Policy、Agent Runtime 等非 Kubernetes 资源。官方资料：https://opengitops.dev/

Kubernetes Desired State / Controller Model：Kubernetes 把对象作为系统意图记录，以 spec 描述 Desired State、以 status 描述 Actual State，并由控制平面持续推动 Actual State 接近 Desired State；Deployment Controller 则以受控方式执行这种状态转换。官方资料：https://kubernetes.io/docs/concepts/overview/working-with-objects/

Argo CD Drift Detection / Self-Healing：Argo CD 会比较 Git 中的 Target State 与 Cluster Live State，状态不同则标记 OutOfSync，并可以通过人工或自动 Sync 将系统重新同步到 Desired State；可选 selfHeal 能对 Live State 偏离触发自动同步。官方资料：https://argo-cd.readthedocs.io/en/stable/

Terraform Resource Drift / Refresh-only：Terraform 将工作流外发生的资源变化视为 Drift，并允许通过 refresh-only operation 检查 Actual Infrastructure 与 State 的差异，而不立即修改远端资源。官方资料：https://developer.hashicorp.com/terraform/tutorials/cloud-get-started/cloud-refresh-only

NIST Configuration Management：NIST SP 800-128 将 Security-focused Configuration Management 的目标定位为持续管理和监控系统配置、降低风险；NIST SP 800-53 CM-2 要求建立、记录和维护当前 Baseline Configuration，并在规定时间或系统发生重要变化时进行更新。官方资料：https://csrc.nist.gov/pubs/sp/800/128/upd1/final

Open Policy Agent：OPA Bundles 支持远程分发 Policy/Data；Status 能报告 Bundle 激活状态和 Revision；Decision Logs 能记录某次决策所使用的 Bundle Revision 与 decision_id，为 Policy Provenance 与 Policy Drift Detection 提供底层机制。OPA Discovery 则提供集中管理 OPA 配置和 Bundle 来源的机制。官方资料：https://www.openpolicyagent.org/docs/management-bundles

SLSA Provenance：SLSA 1.2 将 Provenance 定义为可以把 Artifact 沿供应链追溯至其来源的可验证信息，描述 Artifact 在何处、何时以及怎样产生。本文借鉴这一思想构建 Configuration Provenance，但本文的 Configuration Provenance Schema 属于项目架构设计，而不是 SLSA 官方标准。官方资料：https://slsa.dev/spec/v1.2/provenance

第（三十四）篇自然承接方向

第三十三篇建立以后，我们已经知道：

What should the system be?
What is the system now?
Where has it drifted?

下一层最自然的问题是：

Who owns each resource?
Who owns each field?
Who may delegate authority?
How do multiple Agents
avoid fighting over the same state?

因此第（三十四）篇可以正式进入：

Resource Ownership / Lease / Lock / Conflict Resolution / Multi-Agent Coordination / Authority Graph

核心问题从 Desired vs Actual 继续推进到 Agent A、Agent B、Human、Controller、Plugin、External System 同时尝试改变同一个资源时：谁拥有写入权、谁必须等待、谁可以抢占、怎样防止双写、怎样解决冲突，以及怎样把 Agent 群体从“多个自动脚本”升级为真正有边界的多 Agent 生产协作系统。