SEO / GEO 工作自动化部署与实践规范（三十二）：Change Intelligence / Release Gate / Progressive Delivery / Canary / Feature Flag / Automated Rollback——让每一次生产变更先证明安全，再逐步扩大影响

创作日期：2026年9月27日

第（二十五）篇，我们建立了 Governance Engine，让系统能够回答：这个动作是否允许执行？

第（二十六）篇进一步加入 Evidence、Risk 与 Decision Trace，让治理决策不再只是静态规则判断。

第（二十七）篇通过 Action Gateway、PEP 与 Capability Token，解决 Governance 已经做出决策以后，怎样真正阻止 Agent 绕过治理直接修改生产环境。

第（二十八）篇进入 Command Bus、Execution State Machine、Idempotency 与 Saga，解决跨系统动作怎样可靠执行。

第（二十九）篇建立 Execution Journal、Reconciliation、DLQ 与 Repair Queue，让异常任务能够被发现和恢复。

第（三十）篇进一步加入 SLO、Circuit Breaker、Kill Switch、Break Glass 与 Incident Command，解决系统性事故怎样及时止损。

第（三十一）篇则把事故进一步转化成：

Postmortem
→ Causal Graph
→ Failure Mode
→ Action Item
→ Safety Invariant
→ Regression Guard
→ Chaos / Game Day

于是系统已经开始拥有：Learn Permanently。

但这里还有一个极其关键的问题没有解决。

假设我们已经知道：

Bulk publishing is dangerous.

Large configuration changes
have high blast radius.

Rollback must be available.

Canary must be used
for high-risk changes.

下一次 Publisher Agent 获得了一个合法 Capability：

ALLOW
+
Capability Token
+
Valid Payload

它是不是就应该立刻把 3,000 个页面全部更新？答案仍然是否定的。

因为：Authorized ≠ Safe to roll out globally。

一个动作可以完全合法、权限正确、输入格式正确、审批完整，但仍然可能因为业务语义错误、第三方 API 行为变化、生产流量差异、缓存机制、模板兼容性或未知交互而造成事故。

所以第三十二篇要解决的是另外一个问题：

已经被允许执行的 Change，怎样安全进入生产环境？

核心链路必须从：

Governance Decision
↓
Capability
↓
Execute

升级为：

Governance Decision
↓
Capability
↓
Change Manifest
↓
Change Risk
↓
Release Strategy
↓
Release Gate
↓
Limited Exposure
↓
Canary Evaluation
↓
Promote / Hold / Rollback
↓
Full Release
↓
Post-release Verification

这就是本篇要建立的：Change Intelligence Control Plane。

它负责把“可以执行”升级为“应该怎样执行、先影响多少、观察什么、什么时候继续、什么时候停止、什么时候自动回滚”。

1、Capability 解决的是 Authority，不是 Rollout Safety

第（二十七）篇建立 Capability Token，是为了保证 WHO can perform WHAT ACTION on WHICH RESOURCE in WHICH ENVIRONMENT during WHICH TIME WINDOW。

但即使 Capability 完全合法，也只能证明这个主体现在拥有执行这个动作的授权。它不能证明这个动作全量执行以后不会出问题。

Authorization Safety
≠
Release Safety

前者属于 Governance / Capability，后者属于 Change Intelligence / Progressive Delivery。

2、真正成熟的生产系统不能只有“Deploy”

传统自动化经常只有 BUILD → TEST → DEPLOY → DONE。这实际上把最大的未知留给了最后一步，因为真正复杂的问题往往只会在 Production 出现。

更成熟的模型应该是：

BUILD
↓
TEST
↓
ASSESS CHANGE
↓
SELECT RELEASE STRATEGY
↓
LIMITED DEPLOYMENT
↓
OBSERVE
↓
EVALUATE
↓
PROMOTE / HOLD / ROLLBACK
↓
VERIFY

3、第三十二篇的第一个核心对象：Change Manifest

Agent 不应该直接说 Please publish these pages。系统应该首先生成正式的 Change Manifest。

{
  "change_id": "chg_20260927_001",
  "requested_by": "seo-publisher-agent",
  "change_type": "WORDPRESS_CONTENT_UPDATE",
  "environment": "production",
  "resources": {
    "count": 824,
    "scope": "category:product-guides"
  },
  "payload_hash": "sha256:...",
  "source_version": "git:abc123",
  "policy_version": "policy-32.4",
  "decision_id": "dec_771",
  "capability_id": "cap_889",
  "rollback_plan": "snapshot-5582",
  "requested_at": "...",
  "release_strategy": null
}

从这一刻开始，Change 本身成为系统中的一等对象。

4、Command 与 Change 不是一个概念

Command 是 UPDATE_POST。Change 是 Update titles, descriptions, schema and internal links for 824 product-guide pages using content build abc123。

Command 是执行单位，Change 是风险与发布单位。

One Change
may contain
many Commands.

5、为什么一定要有 change_id？

因为未来我们需要问：Which deployment caused the traffic regression? Which posts belong to the same rollout? Which capability authorized this release? Which rollback snapshot belongs to this change? Which incident was linked to this change?

这些问题都不能只靠 command_id 回答。

6、Change Manifest 必须不可随意变更

假设审批时审核的是 824 pages，审批以后 Agent 又把范围扩大成 4,821 pages，即使 capability_id 没变，也已经发生 Approval Drift。

所以 Change Manifest 应该生成 manifest_hash，Capability、Approval、Release Plan 都绑定这个 Hash。

7、真正进入生产之前，先做 Change Classification

不同 Change 不应该走同一条发布路径。例如 CONTENT_COPY、SEO_METADATA、INTERNAL_LINK、SCHEMA_MARKUP、TEMPLATE、ROBOTS_TXT、CANONICAL、REDIRECT、CLOUDFLARE_WORKER、DATABASE_SCHEMA、DNS、PERMISSION、EMAIL_SEND，它们的 Risk Profile 完全不同。

8、Change Type 必须成为 Canonical Taxonomy

不能让 Agent 自己随意产生 small-update、minor-fix、safe-change、content-tweak 这种自由文本。

必须使用稳定的 Change Taxonomy，例如：

CONTENT_UPDATE
SEO_METADATA_UPDATE
STRUCTURED_DATA_UPDATE
URL_ROUTING_CHANGE
INDEXING_CONTROL_CHANGE
APPLICATION_DEPLOYMENT
DATABASE_MUTATION
INFRASTRUCTURE_CONFIGURATION
PERMISSION_CHANGE
OUTBOUND_COMMUNICATION

9、Change Risk 不是原来的 Action Risk 的重复

第（二十六）篇的 Risk Engine 评估：这个动作本身有多危险？第三十二篇增加的是：这个 Change 以当前 Scope、Release Speed 和 Exposure 进入生产时有多危险？

因此增加：Release Risk。

10、Release Risk 至少取决于五个维度

Release Risk
=
Change Severity
× Exposure
× Velocity
× Detectability Gap
× Recovery Difficulty

例如同一个标题修改，1 page 和 30,000 pages 的 Action 类型相同，Release Risk 完全不同。

11、Exposure 是本篇极其重要的新变量

Exposure 可以理解为：当前变更一旦错误，会立即影响多少生产对象？

真正成熟的 rollout 系统不是一次跳到 0 → 100%，而是：

0
→ 1%
→ 5%
→ 20%
→ 50%
→ 100%

12、Release Velocity 也属于风险

假设每分钟只改 5 个页面，即使 Detection Time = 2 min，理论最大影响大约只有 10 个页面。如果每秒更新 100 个页面，两分钟就是 12,000 pages。

Blast Radius
≈
Exposure Rate
×
Detection Latency

13、Rollout Speed 应该成为 Governance 参数

例如 max_resources_per_minute、max_batch_size、pause_between_batches、max_concurrent_commands。以后这些不应该只是脚本内部参数，而应该成为 Governed Release Parameters。

14、建立 Change Risk Profile

{
  "change_id": "chg_8821",
  "change_type": "SEO_METADATA_UPDATE",
  "resource_count": 5000,
  "inherent_risk": "HIGH",
  "reversibility": "HIGH",
  "detectability": "MEDIUM",
  "control_confidence": "HIGH",
  "release_risk": "MEDIUM",
  "required_strategy": "PROGRESSIVE",
  "max_initial_exposure": 10
}

15、Release Strategy 不能由 Agent 自己随意选择

不能出现 Agent: I think full rollout is safe。Release Strategy 应由 Change Risk + Policy + Control Confidence + Historical Failure Mode + Environment 共同决定。

16、定义基础 Release Strategy

DIRECT
STAGED
CANARY
PROGRESSIVE
SHADOW
FEATURE_GATED
MANUAL
BLOCKED

17、DIRECT 只适合真正低风险动作

例如 single draft update、non-production metadata、read-only analytics config。即使如此，也应该 Execute → Verify，而不是 Execute → Forget。

18、STAGED Release

staging → production 适合 template、plugin、worker、application code。但必须认识到 Staging 并不能复制所有 Production Conditions，所以 Staging Passed 仍然不等于 Production Safe。

19、Canary 的真正意义不是“先发一点”

Small deployment without evaluation ≠ Canary。真正 Canary 必须是：

Limited Exposure
+
Evaluation
+
Decision

20、Canary 本质上是一场 Production Experiment

例如 Control: existing pages，Canary: new metadata pages。然后比较 render health、HTTP status、schema validity、CTR anomaly、indexability、conversion events、latency、error rate。

但 SEO 指标通常存在延迟，所以并不是所有指标都适合作为即时 Canary Signal。

21、区分 Fast Signal 与 Slow Signal

Fast Signals：

HTTP 200
content exists
canonical valid
robots valid
schema valid
template renders
internal links resolve

Slow Signals：

Google crawl
indexation
ranking
CTR
organic sessions
conversion

两类指标不能混为一谈。

22、Canary Gate 应优先使用 Fast Signals

不能要求 wait until ranking improves before deploying page 11。这会让 rollout 无限阻塞。

Fast Safety Gate
↓
Continue Rollout
↓
Slow Outcome Monitoring

23、建立 Release Gate

Release Gate 是 Rollout 从一个阶段进入下一个阶段之前必须通过的正式判断点。

CANARY_10
↓
RELEASE_GATE
↓
CANARY_50

24、Release Gate 与 Governance Engine 不同

Governance Engine 回答 May this change execute? Release Gate 回答 May this rollout advance? 这是两个完全不同的问题。

25、Release Gate 应读取实时生产证据

{
  "release_gate_id": "rg_882",
  "change_id": "chg_221",
  "phase": "CANARY_10",
  "signals": {
    "http_success_rate": 1.0,
    "render_validation": "PASS",
    "schema_validation": "PASS",
    "canonical_validation": "PASS",
    "error_delta": 0
  },
  "decision": "PROMOTE"
}

26、Release Gate 的基础结果建议固定

PROMOTE
HOLD
ROLLBACK
ABORT
REQUIRE_APPROVAL

不要自由输出 looks okay、probably fine、continue carefully。

27、PROMOTE

表示 Current phase validated. Move to next exposure level。例如 10 → 50。

28、HOLD

表示 Do not increase exposure. Continue observation。对于 insufficient evidence、noisy metrics、slow dependency、temporary uncertainty 非常重要。

29、ROLLBACK

表示 Current rollout has violated a rollback condition. Return affected resources to previous known-good state。

30、ABORT 与 ROLLBACK 也不同

ABORT = Stop future rollout。ROLLBACK = Undo already-applied change。可能 ABORT without ROLLBACK，也可能 ABORT + ROLLBACK。

31、Canary Evaluation 不能只比较“有没有报错”

Canary metric 需要代表性和可归因性，同时不能只依赖 canary/control 相对比较，还需要绝对 SLO 或安全阈值。

Canary Error Rate
=
Control Error Rate

不一定代表安全，因为 both may be bad。

32、所以 Release Gate 需要两类 Threshold

Relative Threshold
+
Absolute Threshold

例如 canary error rate must not exceed control + 0.5% AND absolute error rate must remain below 1%。

33、SEO / GEO Release Gate 也可以这样设计

Malformed Schema = 0
Unexpected Noindex = 0
Canonical Drift = 0
Critical Page HTTP Failure = 0
Rendered Title Missing = 0

其中某些指标甚至应该 zero tolerance。

34、不是所有指标都需要 Statistical Significance

对于 conversion rate、CTR、latency 可能需要统计判断。但 robots.txt accidentally blocks / 不需要任何统计显著性，一次就应该 STOP。

35、建立 Hard Guard 与 Soft Guard

Hard Guard：robots blocked、canonical invalid、500 error、security policy violated → ROLLBACK / ABORT。

Soft Guard：CTR variance、latency slight increase、crawl delay → HOLD / OBSERVE。

36、第三十一篇的 Safety Invariant 现在真正进入 Release Gate

例如第三十一篇产生：No production bulk publish without validated snapshot。

第三十二篇中它直接成为 Pre-release Gate。如果 snapshot.status != VALIDATED，那么 release = BLOCKED。

这就是 Incident Learning → Production Enforcement。

37、Regression Guard 也应该参与 Release Gate

例如之前出现过 duplicate publishing after timeout，于是建立 guard_duplicate_publish。下一次 Publisher Release 如果 guard status != PASS，则不允许进入生产 Canary。

38、这就是 Change Intelligence 的核心价值

不是简单地 look at this deployment，而是 retrieve everything the organization already knows about this kind of change。

39、Change Intelligence 应查询历史事故

例如 Change Type: CANONICAL_UPDATE，系统查询 Related Incidents、Related Failure Modes、Related Safety Invariants、Related Guards、Related Rollback Failures，然后重新计算 Release Risk。

40、系统应该能够知道“我们以前在这里出过事”

FM-018
Mass canonical drift

Related incidents:
inc_201
inc_442

Required controls:
canonical allowlist
sample validation
canary
snapshot
post-release crawl check

这样经验才能真正进入未来执行。

41、Release Plan 应该成为正式对象

{
  "release_plan_id": "rp_20260927_001",
  "change_id": "chg_882",
  "strategy": "PROGRESSIVE",
  "phases": [
    { "name": "CANARY", "resources": 10 },
    { "name": "WAVE_1", "resources": 100 },
    { "name": "WAVE_2", "resources": 1000 },
    { "name": "FULL", "resources": "remaining" }
  ]
}

42、Release Plan 不能只定义百分比

还必须定义 phase、scope、duration、required signals、promotion criteria、rollback criteria、approval requirements。

43、例如完整 Phase

{
  "phase": "CANARY_10",
  "max_resources": 10,
  "min_observation_time": "5m",
  "required_guards": [
    "http_health",
    "canonical_check",
    "schema_check"
  ],
  "promotion_policy": "AUTO",
  "rollback_policy": "AUTO"
}

44、Progressive Delivery 的关键不是 Traffic Percentage

对于 Cloudflare Worker，traffic percentage 很自然。但 WordPress 页面并不是流量切分问题。所以 Progressive Delivery 的本质应该定义成 Progressive Exposure，而不是 Progressive Traffic。

45、WordPress Progressive Exposure

例如 2,000 个页面：

10 pages
↓
50 pages
↓
250 pages
↓
1,000 pages
↓
remaining

每一个阶段都执行 publish → fetch → render → validate → observe → gate。

46、页面选择不能永远取“前 10 个”

Canary Population 必须有代表性。页面可以按照 template、traffic、language、device behavior、content type、product type、historical stability 进行分层抽样。

47、建立 Representative Canary Set

2 high-traffic pages
2 low-traffic pages
2 template-A pages
2 template-B pages
1 long-content page
1 structured-data-heavy page

这比 first 10 database IDs 有意义得多。

48、Canary Population 也属于 Risk Decision

高风险 Change 应选择 representative but limited blast radius，不能选择 homepage + top revenue page + highest traffic landing page 作为第一阶段实验对象。

49、因此 Canary 需要 Risk-aware Sampling

Representative Enough
+
Low Enough Business Criticality

50、Cloudflare Worker 天然适合 Traffic Canary

Worker rollout 可以设计：

5%
↓
20%
↓
50%
↓
100%

51、但不是看到 Percentage 就机械使用

例如 SEO Publisher 是一个低频内部 Worker。如果一天只有 1 request，那么 5% traffic canary 可能根本得不到有效 Evidence。

此时更合理的是 Synthetic Request Canary 或 Scoped Functional Canary。

52、Change Strategy 必须适配 Workload

系统不能只有 CANARY_PERCENTAGE，而应允许：

TRAFFIC_CANARY
RESOURCE_CANARY
TENANT_CANARY
REGION_CANARY
COMMAND_CANARY
SYNTHETIC_CANARY

53、阶段化 rollout 的工程原则

Canary Deployment 可以按多个阶段逐步提升比例，并在阶段中执行 verify / analysis，再据此决定 rollout 是否推进。本项目借鉴这一工程原则，但不把任何具体云平台资源模型直接当作统一标准。

54、GitHub 的 Release Gate 也应该正式化

当前 GitHub workflow 不能只是 merge → deploy，而应该进一步发展成：

PR
↓
CI
↓
Change Risk
↓
Environment Gate
↓
Deploy
↓
Verify

55、GitHub Merge 与 Production Release 应解耦

一个 PR MERGED 并不意味着 PRODUCTION_ENABLED。

MERGED
↓
RELEASE_CANDIDATE
↓
CANARY
↓
PRODUCTION

56、Feature Flag 解决的就是这种解耦问题之一

传统模型：Code Deployment = Feature Exposure。

Feature Flag 模型：Code Deployment ≠ Feature Exposure。

代码已经存在生产环境，但功能 OFF，直到满足条件以后再开启。

57、Feature Flag 不应该被理解成 UI Toggle

它实际上可以控制 new ranking logic、new publishing strategy、new enrichment model、new parser、new schema generator、new audit rule、new Agent workflow。

58、Flag 可以让 Release 与 Activation 分离

deploy new SEO auditor
↓
feature flag OFF
↓
internal test
↓
5% sites
↓
20%
↓
100%

这使 Rollback 在很多场景下可以变成 Disable Flag，而不是重新部署代码。

59、Feature Flag Evaluation 抽象

Feature Flag 系统应该至少理解 Flag + Evaluation Context + Hooks：根据主体、应用、站点、环境等上下文进行动态评估，并在评估前后执行验证、Telemetry、日志和错误处理。

60、Feature Flag Evaluation 也必须可审计

{
  "flag": "seo-agent-new-publisher",
  "subject": "site_102",
  "value": true,
  "variant": "canary",
  "reason": "TARGETING_MATCH",
  "change_id": "chg_991",
  "evaluated_at": "..."
}

否则无法回答为什么这个站点用了新逻辑，而另一个没有。

61、Feature Flag 本身也是生产配置

Enable Flag、Disable Flag、Change Targeting、Change Percentage 都应该进入 Governance，不能让 Flag system 成为 backdoor around release governance。

62、Flag Change 同样需要 Capability

action:
UPDATE_FEATURE_FLAG

resource:
seo-agent-new-publisher

target:
5% → 20%

这样第（二十七）篇仍然有效。

63、Release Gate 与 Feature Flag 可以组合

Deploy code
↓
Flag OFF
↓
Enable 1%
↓
Observe
↓
Release Gate
↓
Enable 10%
↓
Observe
↓
Release Gate
↓
Enable 100%

64、Feature Flag 也有技术债务

每增加一个 Flag，就增加一个新的系统状态。两个布尔 Flag 有 4 states，10 个独立 Flag 最多形成 1024 combinations。因此 Feature Flags 不能无限增长。

65、建立 Flag Lifecycle

CREATED
↓
TESTING
↓
CANARY
↓
ACTIVE
↓
FULLY_ROLLED_OUT
↓
RETIRE_PENDING
↓
REMOVED

不能让 temporary flag 永久留在生产系统。

66、Feature Flag 应有 expires_at

例如 temporary migration flag expires in 30 days，超期后进入 FLAG_DEBT。

67、Change Intelligence 还必须知道 Reversibility

并不是每一个 Change 都能简单 rollback。Cloudflare Worker version 通常容易回退，但 database destructive migration 可能无法简单 rollback。

Reversible
Conditionally Reversible
Irreversible

必须明确标记。

68、不可逆 Change 应有更严格 Release Policy

例如 IRREVERSIBLE 可能自动触发 REQUIRE_APPROVAL + DRY_RUN + BACKUP + CANARY + LOW RATE + EXTENDED OBSERVATION。

69、数据库 Change 需要特别处理

例如 DROP COLUMN 不能简单 execute → if error → rollback。更安全的是：

Expand
↓
Dual Compatibility
↓
Migrate
↓
Verify
↓
Contract

即 Expand / Contract Migration。

70、先 Expand，再切换，再 Contract

add new column
↓
application supports old + new
↓
migrate data
↓
verify
↓
switch reads
↓
observe
↓
remove old column

71、这也是 Progressive Delivery

Progressive Delivery 不只是 traffic %，也可以是 schema state、data state、reader state、writer state 逐步迁移。

72、WordPress 也可以采用 Expand / Contract 思维

例如修改 ACF 字段，不要 delete old field → create new field，而是 create new field → dual-read → migrate → verify → switch → remove old field。

73、Redirect Migration 也类似

new URLs generated
↓
mapping validated
↓
sample redirects
↓
crawl validation
↓
limited rollout
↓
full redirect activation
↓
old URL monitoring

而不是一次性把 10,000 redirects 直接推入生产。

74、Robots.txt 属于极高风险 Change

因为 one file 可能控制 entire site crawling。这正说明 Resource Count 不是唯一 Blast Radius 指标。

75、建立 Semantic Blast Radius

robots.txt
resource_count = 1
semantic_scope = SITE_WIDE

所以 Release Risk 必须考虑 Semantic Scope。

76、Canonical Template 也是同样的问题

只修改 1 template，可能影响 50,000 URLs。所以 Change Intelligence 必须理解 Direct Resources + Derived Resources。

77、建立 Impact Graph

template.php
↓
product template
↓
12,842 URLs
↓
Google crawl surface

真正 Exposure 应由 Impact Graph 计算，而不是只看 changed_file_count。

78、这会让 Change Risk 更接近真实风险

1-line CSS fix 和 1-line noindex logic change 的代码 Diff 都是一行，风险完全不同。

Diff Size
≠
Change Risk

79、Change Intelligence 应理解“改了什么”

这就需要 Semantic Diff，不仅是 Text Diff。

80、Semantic Diff 的典型对象

SEO Title Changed
Canonical Changed
Robots Directive Changed
Schema Type Changed
Internal Link Target Changed
Redirect Destination Changed
Publishing Status Changed
Permission Changed
DNS Target Changed

81、未来可以建立 Change Analyzer Agent

输入 Git Diff、WordPress Diff、Policy Diff、Config Diff、Database Migration，输出 Canonical Change Manifest + Semantic Impact + Potential Failure Modes + Recommended Release Strategy。

但 Change Analyzer 只能提供 Evidence / Recommendation，最终 Release Policy 仍由确定性 Governance 处理。

82、Release Gate 不应该完全交给 LLM

LLM 可以帮助解释 why this change looks risky，但 HTTP failure = 100% 这种判断不需要 LLM。生产 Release Gate 应优先使用 Deterministic Rules + Structured Metrics + Explicit Policies。

83、自动 Promote 必须有明确条件

IF
all hard guards = PASS

AND
observation_time >= 5m

AND
error_delta < threshold

AND
no kill_switch

AND
capability still valid

THEN
PROMOTE

84、Promotion 也应该生成新的 Capability

不能因为第一阶段拥有 10-page capability，就自动拥有 10,000-page capability。

Canary Gate PASS
↓
Governance Re-evaluation
↓
New Capability
↓
Next Phase

85、于是 Capability 也变成 Progressive

cap_phase_1
scope = 10

cap_phase_2
scope = 100

cap_phase_3
scope = 1000

每一次 Exposure 扩张，都重新明确授权。

86、这可以称为 Progressive Capability

原则是：权限增长速度，不应该快于系统获得安全证据的速度。

Evidence ↑
↓
Confidence ↑
↓
Capability Scope ↑

87、这和 Autonomy Budget 完全接上了

低风险、历史稳定：larger initial scope + faster auto promotion。

高风险、历史事故多：smaller canary + longer observation + manual gate。

于是 Risk-adjusted Progressive Delivery 正式成立。

88、SLO 必须参与 Release Gate

第（三十）篇已经建立 SLO、Error Budget、Incident Detection。第三十二篇进一步要求：Rollout cannot ignore current service health。

89、系统本身已经不健康时，不应该继续发布

例如 error budget exhausted 或 current incident = SEV1，那么默认 CHANGE FREEZE。

90、建立 Release Freeze Conditions

active SEV1
active SEV2
kill switch active
control confidence low
P0 regression guard failed
critical monitoring unavailable
rollback unavailable
error budget exhausted

都可以阻止 new production rollout。

91、这就是 Change Freeze 的自动化版本

不是 Incident Commander 在群里说“大家先别发版”，而是系统直接 release_gate = CLOSED。

92、Emergency Fix 怎么办？

需要 Emergency Change Path，但不能 emergency = ignore all controls。

93、Emergency Change 应更加可审计

incident_id、break_glass_id、actor、reason、scope、expiration、rollback_plan、verification 全部必须记录。

94、Emergency Change 也尽量小

事故期间尤其需要小规模、可逆、容易验证的变更，不要把 emergency 理解成 giant unreviewed patch。

95、Automatic Rollback 必须是 Release Strategy 的一部分

不能等失败以后再问 Can we rollback? 应该在 Release Plan 生成时就确定 rollback_available、rollback_target、rollback_artifact、rollback_trigger、rollback_timeout、rollback_validation。

96、Rollback Trigger 必须预先定义

HTTP failure > 1%
→ rollback

unexpected noindex > 0
→ rollback

schema critical error > 0
→ hold / rollback

worker exception delta > threshold
→ rollback

97、不要让 Agent 在事故现场临时决定“是否回滚”

因为事故发生时 evidence noisy、pressure high、time limited。如果条件能够提前定义，就应该 pre-authorize safe rollback。

98、Rollback 本身也需要 Capability

ROLLBACK_WORDPRESS_CHANGE 和 PUBLISH_WORDPRESS_CHANGE 应该是两个不同 Action。

99、Emergency Rollback Capability 可以预签发吗？

可以设计 conditional capability，只有 rollback_condition = TRUE 以后才能消费。这能够减少事故发生后的授权延迟。

100、Rollback 以后还不能直接声明恢复

ROLLBACK
↓
VERIFY RESTORED STATE
↓
VERIFY FRONTEND
↓
VERIFY CRITICAL SIGNALS
↓
RECOVERED

继续遵守 No Verification → No Completion。

101、Release Receipt

{
  "release_id": "rel_882",
  "change_id": "chg_991",
  "strategy": "PROGRESSIVE",
  "phases_completed": [
    "CANARY_10",
    "WAVE_100",
    "FULL"
  ],
  "gate_decisions": [
    "PROMOTE",
    "PROMOTE",
    "SUCCESS"
  ],
  "rollback": false,
  "started_at": "...",
  "verified_at": "...",
  "final_state": "VERIFIED"
}

102、Execution Receipt 与 Release Receipt 不同

Execution Receipt = this command ran。Release Receipt = this change safely completed its rollout lifecycle。

103、Release State Machine

PROPOSED
↓
ANALYZED
↓
APPROVED
↓
READY
↓
CANARYING
↓
EVALUATING
↓
PROMOTING
↓
FULLY_DEPLOYED
↓
VERIFYING
↓
VERIFIED

异常路径包括 HELD、ROLLING_BACK、ROLLED_BACK、ABORTED、FAILED、INCIDENT。

104、禁止 APPROVED → VERIFIED

因为中间必须发生 deployment + observation + evaluation。

105、Release Journal 也应该存在

每一次 Phase 的 started、commands issued、signals observed、gate decision、capability consumed、promotion performed 都必须持久记录。

106、这样 Incident 才能够重建 Release Timeline

09:00 Release started
09:02 Canary 10
09:04 Gate PASS
09:05 Wave 100
09:07 Canonical anomaly
09:08 Gate HOLD
09:09 Rollback triggered
09:11 Rollback verified

Postmortem 不再依赖聊天记录。

107、Release 与 Incident 必须双向关联

如果 rollout 触发 Incident：release_id → incident_id，同时 incident_id → release_id。这样第三十一篇 Causal Graph 能直接连接变更证据。

108、Incident Learning 又会反向修改 Release Strategy

例如 Failure Mode: bulk canonical corruption。以后 CANONICAL_UPDATE 默认 CANARY REQUIRED，而不是重新依靠人类记住过去的事故。

109、这就形成真正的 Change Learning Loop

Change
↓
Release
↓
Observe
↓
Incident
↓
Postmortem
↓
Invariant
↓
Guard
↓
Release Policy
↓
Future Change

110、Release Policy 应该 Policy-as-Code

IF
change.type = INDEXING_CONTROL_CHANGE
AND
environment = production

THEN
require_snapshot = true
require_canary = true
initial_scope <= 5
auto_promote = false

111、再例如

IF
change.type = CONTENT_UPDATE
AND
resource_count < 10
AND
control_confidence = HIGH
AND
no_active_incident

THEN
strategy = DIRECT

112、Release Policy 应与 Governance Policy 分开

Governance Policy：Is action permitted?

Release Policy：How must permitted change be introduced?

两者职责必须清楚。

113、于是 Control Plane 进一步分层

Authorization Control
↓
Execution Control
↓
Release Control
↓
Reliability Control
↓
Learning Control

114、Change Intelligence 还应该检查 Dependency State

例如 WordPress 更新没有问题，但 Cloudflare degraded、Database lagging、Monitoring unavailable，这时也可能不适合发布。

115、建立 Release Preconditions

system_health = HEALTHY
monitoring_health = HEALTHY
rollback_ready = TRUE
required_guards = PASS
capability = ACTIVE
approval = ACTIVE
change_freeze = FALSE

只有全部满足，才能 START_RELEASE。

116、Third-party Dependency 也应该进入 Release Gate

例如 WordPress REST error rate rising、GitHub Actions queue delayed、Cloudflare API degraded，不应该继续增加自动化并发量。

117、Release Gate 可以实现 Adaptive Rate

normal:
100 resources/min

dependency degraded:
10 resources/min

critical degradation:
0 resources/min

这叫 Adaptive Release Velocity。

118、不是所有 rollout 都必须固定 10 → 50 → 100

根据实时 Evidence 可以 accelerate，也可以 slow down，甚至 hold。

119、Confidence 高，可以扩大下一阶段

例如 100 clean executions + no anomaly + high control confidence，下一阶段可以 100 → 1000。

120、Confidence 低，则扩大得更慢

例如 metric noise + third-party latency + previous failure，可能 10 → 20 → 50。

121、这叫 Adaptive Progressive Delivery

核心原则：Exposure growth should follow evidence growth。

Δ Exposure
∝
Validated Confidence

122、但不能让模型自己无限加速

必须存在 max_phase_growth、max_resource_count、max_rate、max_autonomous_scope，也就是 Autonomy Budget 仍然是硬边界。

123、完整 Change Control Plane

                    AGENT INTENT
                         │
                         ▼
                    CHANGE REQUEST
                         │
                         ▼
                   CHANGE MANIFEST
                         │
                         ▼
                  SEMANTIC ANALYZER
                         │
                         ▼
                   IMPACT GRAPH
                         │
                         ▼
                     RISK ENGINE
                         │
                         ▼
                 GOVERNANCE ENGINE
                         │
                         ▼
                      DECISION
                         │
                         ▼
                  CAPABILITY ISSUER
                         │
                         ▼
                CHANGE INTELLIGENCE
                         │
            ┌────────────┼────────────┐
            │            │            │
            ▼            ▼            ▼
       Past Incidents  Guards     Control Confidence
            │            │            │
            └────────────┼────────────┘
                         ▼
                   RELEASE POLICY
                         │
                         ▼
                    RELEASE PLAN
                         │
                         ▼
                    RELEASE GATE
                         │
                         ▼
                PROGRESSIVE EXPOSURE
                         │
                         ▼
                  CANARY EVALUATION
                         │
               ┌─────────┼─────────┐
               ▼         ▼         ▼
            PROMOTE     HOLD    ROLLBACK
               │                    │
               ▼                    ▼
          NEXT PHASE          RESTORE STATE
               │                    │
               └─────────┬──────────┘
                         ▼
                    VERIFICATION
                         │
                         ▼
                   RELEASE RECEIPT
                         │
                         ▼
                  OBSERVABILITY
                         │
                         ▼
             INCIDENT / LEARNING LOOP

124、到这里，“发布”已经不再是一个 API 调用

它变成了 Governed Production Transition：

Known State
↓
Controlled Change
↓
Limited Exposure
↓
Evidence Collection
↓
Decision
↓
Expanded Exposure
↓
Verified State

125、WordPress 最终应该怎样发布？

Create Change Manifest
↓
Analyze Impact
↓
Snapshot
↓
Generate Canary Set
↓
Issue Phase Capability
↓
Publish Canary
↓
Verify REST
↓
Verify Frontend
↓
Verify SEO Guards
↓
Release Gate
↓
Publish Next Batch
↓
Repeat
↓
Full Verification
↓
Release Receipt

126、GitHub 最终应该怎样发布？

Feature Branch
↓
PR
↓
CI
↓
Semantic Diff
↓
Change Risk
↓
Required Review
↓
Merge
↓
Release Candidate
↓
Deployment Gate
↓
Canary
↓
Verify
↓
Promote

127、Cloudflare 最终应该怎样发布？

New Worker Version
↓
Static Validation
↓
Deploy Version
↓
Limited Traffic
↓
Observe Errors / Exceptions
↓
Release Gate
↓
Increase Traffic
↓
100%
↓
Post-release Verification

128、Database 最终应该怎样发布？

Migration Plan
↓
Backup
↓
Compatibility Check
↓
Expand
↓
Limited Migration
↓
Data Verification
↓
Progressive Migration
↓
Switch
↓
Observe
↓
Contract

129、Email 最终也可以 Progressive

例如大批量运营邮件：

internal seed
↓
10 recipients
↓
100
↓
1,000
↓
remaining

校验 bounce、rendering、wrong recipient、wrong personalization、unsubscribe link、tracking。其思想与基础设施 Canary 相同：先限制影响，再获得证据。

130、Search Automation 最终需要一个统一 Release Abstraction

无论 WordPress、GitHub、Cloudflare、Database、Email、SEO Config、Schema、Redirect、Robots，最终都可以转换成：

Change
↓
Exposure
↓
Observation
↓
Gate
↓
Promotion

131、这会极大降低 Agent Tool Fragmentation

否则每一个 Tool 都有自己的 deploy logic、rollback logic、approval logic、canary logic，最终极难维护。

更合理的是 Unified Release Orchestrator + Provider-specific Adapter。

132、Release Orchestrator 不直接掌握生产凭证

它仍然通过 Action Gateway → Tool Adapter → Credential Broker 执行。第三十二篇没有绕过第二十七篇，而是构建在它上面。

133、Release Orchestrator 的职责

负责 phase planning、exposure control、observation window、gate evaluation、promotion、hold、rollback coordination、release journal。

134、Action Gateway 的职责仍然是

Is this concrete side effect currently authorized?

边界必须稳定。

135、Command Bus 的职责仍然是

reliably execute authorized commands。

136、Execution State Machine 的职责仍然是

track command lifecycle。

137、Release State Machine 的职责是

track change rollout lifecycle。这些不能全部塞进一个超级 Agent。

138、最终的生产安全体系开始真正完整

Evidence
↓
Risk
↓
Governance
↓
Capability
↓
Enforcement
↓
Reliable Execution
↓
Progressive Release
↓
Observability
↓
Incident Control
↓
Postmortem
↓
Learning
↓
Future Release Policy

139、第三十二篇最重要的新增原则之一

此前我们已经有：

No Valid Decision
→
No Capability

No Capability
→
No Production Mutation

No Execution Receipt
→
Action Is Not Complete

现在再增加：

No Release Gate
→
No Exposure Expansion

以及：

No Post-release Verification
→
No Release Completion

140、再增加一条

No Rollback Plan
→
No High-risk Release

尤其对于 bulk change、template change、routing change、indexing control、infrastructure change，这应该成为硬约束。

结语：成熟的自动化，不是“Agent 可以发生产”，而是“Agent 只能按证据逐步获得更大的生产影响范围”

第（二十七）篇解决 Can the Agent execute?

第（二十八）篇解决 Can the execution remain reliable?

第（二十九）篇解决 Can abnormal execution be repaired?

第（三十）篇解决 Can a spreading incident be stopped?

第（三十一）篇解决 Can the system permanently learn from the incident?

第三十二篇最终解决：Can future changes use that accumulated knowledge before blast radius becomes large?

这一步极其关键。真正优秀的生产系统，不应该等 100% rollout → incident → rollback 才发现错误。

而应该：

1%
↓
Evidence

5%
↓
More Evidence

20%
↓
More Confidence

50%
↓
More Validation

100%
↓
Verified Release

更准确地说：

Authority
does not justify
Exposure.

Evidence
justifies
Exposure.

所以本篇最核心的原则可以压缩成一句话：

Exposure must be earned by evidence.

生产影响范围必须通过证据逐步获得，而不能仅仅因为 Agent 已经拿到授权就一次性放大。

最终，一个成熟的 SEO / GEO Autonomous Platform 应该能够回答：

What exactly is changing?
How many resources could this affect?
What is the semantic blast radius?
Have we failed here before?
Which safety invariants apply?
Which regression guards must pass?
What is the smallest representative canary?
Which signals decide promotion?
Which signals trigger rollback?
How far may the next phase expand?
Is rollback still valid?
Has the final production state actually been verified?

如果这些问题能够被系统自动回答，那么“自动发布”才真正从 API Automation 升级成 Progressive Production Governance。

Change
↓
Understand
↓
Constrain
↓
Release
↓
Observe
↓
Decide
↓
Expand
↓
Verify

第（三十一）篇的核心是 Learn Permanently。第三十二篇则进一步变成：

Learn Permanently
↓
Release Progressively

最终形成新的完整原则：

Execute Fast
Stop Faster
Recover Carefully
Learn Permanently
Release Progressively

当系统真正建立 Change Manifest + Change Intelligence + Release Gate + Progressive Exposure + Canary Evaluation + Feature Flag + Automated Rollback 以后，Agent 才不再是“拿到生产权限以后自动执行所有动作”，而是：

在已经获得授权的前提下，只能随着生产证据不断增加，逐步获得更大的影响范围。

这才是比“自动发布”更成熟的：Evidence-driven Autonomous Delivery。

官方依据与工程边界说明

本文提出的 Change Intelligence Control Plane、Change Manifest、Semantic Blast Radius、Progressive Capability、Release Gate、Release Receipt、Risk-adjusted Progressive Delivery、Reliability-aware Autonomy 等，是本 SEO / GEO 自动化项目在既有 Governance、Capability、Execution、Incident 与 Reliability Learning 架构上的进一步工程抽象，并不是 Google、GitHub、Cloudflare、OpenFeature 或 AWS 共同定义的一套统一 Agent Release Management 标准。

Google SRE — Canarying Releases：Google SRE 将 canarying 描述为对变更进行部分、限时的生产部署和评估，并强调 canary population、evaluation process 以及将 canary evaluation 接入 release process。其 Release Engineering 原则还包括 reproducible builds、automated builds、automated tests、automated deployments 和 small deployments。官方资料：https://sre.google/workbook/canarying-releases/

Google Cloud Deploy — Canary Deployment：Google Cloud Deploy 支持阶段化 Canary Rollout，可以按照配置的比例逐渐扩大部署，并支持在 Canary 阶段执行 verify 与 analysis，再决定 rollout 是否继续推进。官方资料：https://docs.cloud.google.com/deploy/docs/deployment-strategies/canary

Cloudflare Workers — Gradual Deployments：Cloudflare Workers Gradual Deployments 支持把流量逐步分配到新旧 Worker 版本，并结合 observability 观察异常，在发现问题时回到稳定版本。官方资料：https://developers.cloudflare.com/workers/versions-and-deployments/gradual-deployments/

GitHub — Deployment Environments / Protection Rules：GitHub Deployment Environments 可以通过 deployment protection rules 设置人工批准、等待时间、允许部署的分支，并可通过 GitHub Apps 接入第三方 observability、change management 或 code-quality 系统作为部署放行条件。官方资料：https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments

OpenFeature Specification：OpenFeature 提供 vendor-neutral Feature Flag Evaluation API，并正式定义 Evaluation Context、Providers、Hooks、Events 等机制。官方资料：https://openfeature.dev/specification/

AWS Well-Architected — Frequent, Small, Reversible Changes：AWS Well-Architected 运维指导强调采用频繁、小规模、可逆的变更，以降低变更范围，使故障定位与恢复更加容易。官方资料：https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_mit_deploy_risks_freq_sm_rev_chg.html

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

完成第三十二篇以后，下一层最自然的方向是：Desired State / Configuration Management / GitOps / Drift Detection / Configuration Provenance / Policy Drift。

第三十二篇已经解决：How should a change safely enter production?

第三十三篇可以继续解决：

After production has changed,
how do we continuously prove
that the real system
still equals
the intended system?

也就是正式建立：

Desired State
↓
Actual State
↓
Diff
↓
Drift Detection
↓
Reconciliation
↓
Policy Drift
↓
Configuration Provenance

把现在已经形成的“可靠发布”进一步升级为：持续保证生产环境没有悄悄偏离我们批准过的状态。