AI Runtime Containment：如何让失控的 Agent 停下来，并安全恢复生产｜SEO / GEO 自动化治理（四十）

创作日期：2026 年 10 月 8 日

核心主题： AI Runtime Containment / Circuit Breaker / Kill Switch / Graceful Degradation / Safe State / Quarantine / Rollback / Compensating Action / Incident Command / Blast Radius Containment / Autonomous Recovery

系列定位： SEO / GEO / AI Agent 生产工程与治理体系

研究性质： 官方技术依据 + 分布式系统工程实践 + 本项目原创运行治理模型

---

第（三十九）篇，我们建立了一条重要的生产治理链：

Production Trace
↓
Online Evaluation
↓
Behavioral Drift
↓
Risk Recalibration
↓
Autonomy Budget
↓
Capability Adjustment
↓
Continuous Assurance

它解决了一个问题：

Does current production evidence still justify the level of autonomy we are granting it?

当前生产证据，是否仍然足以证明 Agent 值得拥有现在的自治权限？

这已经比传统的“上线前通过评估”前进了一大步。

但真正困难的问题，才刚刚出现。

假设系统已经发现：

• Agent 的行为明显偏离已批准的范围；
• Prompt Injection 使其尝试执行高风险 Tool；
• 在线评估发现事实错误率显著上升；
• 某个 MCP Server 开始返回异常工具定义；
• Publishing Agent 正在批量修改错误的 WordPress 页面；
• 一个生产工作流不断失败、重试，并扩大影响范围。

此时，Governance Engine 可以非常准确地判断：

Current Risk
>
Approved Risk

Decision:
REVOKE AUTONOMY

可是，这并不能证明系统真的已经安全。

因为在这个决定产生之前，Agent 可能已经发出多个 Tool Call。部分请求可能正在执行。某些队列任务可能已经被其他 Worker 领取。外部 API 可能已经接受了操作，只是还没有返回响应。更麻烦的是，Agent 可能已经触发了多个下游 Agent。

于是出现一个比“检测风险”更加重要的问题：

系统已经决定停止 Agent，但那些正在执行、已经排队、已经授权甚至已经产生外部影响的操作，究竟怎样停下来？

这就是第（四十）篇的核心：AI Runtime Containment。

我们要把第（三十九）篇的：

We know
the Agent should
lose autonomy.

推进到：

How do we
safely contain,
stop and recover
a running autonomous system
before damage propagates?

最终形成：

Risk Breach
↓
Containment Decision
↓
Circuit Breaker
↓
Capability Revocation
↓
Execution Fencing
↓
Isolation
↓
Safe State
↓
Rollback / Compensation
↓
Forensics
↓
Revalidation
↓
Controlled Recovery

一个真正可以进入生产环境的 Autonomous Agent，不仅需要证明自己有能力执行任务，还必须证明：当自己不再可靠时，系统有能力限制它、停止它、隔离它，并恢复已经受到影响的业务。

一、AI Runtime Containment：为什么停掉 Agent 进程还不够？

传统应用发生异常时，一个常见操作是：

Stop Service
↓
Restart Service

对于普通无状态服务，这可能是有效的短期处理。但对于拥有生产操作权限的 Agent，风险并不只存在于正在运行的进程中。

考虑一个自动发布工作流：

Research Agent
↓
Writer Agent
↓
Fact Check Agent
↓
Editorial Agent
↓
Publisher Agent
↓
WordPress REST API
↓
CDN / Search Engine

当 Publisher Agent 出现异常时，系统直接关闭它的进程，可能仍然留下：

1. 已发送但尚未确认的 WordPress 请求；
2. 已经创建的文章或页面；
3. 等待重试的队列消息；
4. 已签发但尚未过期的 Capability；
5. 已经启动的下游任务；
6. 其他 Agent 持有的授权副本；
7. 外部系统中已经生效的修改。

因此：

Process Stopped
≠
Authority Revoked

Authority Revoked
≠
In-flight Work Stopped

In-flight Work Stopped
≠
External Effects Reversed

这三个不等式，是理解 AI Runtime Containment 的起点。

我们必须把“停下来”拆解为不同层级，而不能把终止进程当成完整的安全控制。

二、官方依据：NIST 已明确要求 AI 系统具备脱离与停用机制

NIST AI Risk Management Framework 的 MANAGE 2.4 明确提出，应建立并应用相关机制，同时明确职责，使表现或结果不符合预期用途的 AI 系统能够被取代、脱离运行或停用。

这包括当风险超出容忍范围、现有措施无法充分降低风险，或者持续监测发现无法及时缓解的风险时，考虑安全地移除系统或相关组件。

NIST MANAGE 4.1 则进一步强调，部署后的 AI 监测计划应包含人工覆盖、停用、事故响应、恢复和变更管理等机制。

参考：NIST AI RMF Playbook — Manage

这给出了明确的治理方向：AI 系统必须能够被停止、被接管，也必须有可执行的恢复机制。

不过需要划清边界：NIST 没有在上述条款中定义本项目后面提出的统一 Agent Kill Switch 协议、Containment Receipt、Safety Epoch 或 Autonomous Recovery State Machine。这些属于我们根据 AI RMF、事故响应方法与分布式系统工程进一步构建的实现模型。

三、Containment、Shutdown、Recovery 是三个不同问题

为了避免设计混乱，需要先区分三个概念。

Containment：限制风险扩散。 目标不是立即让一切停止，而是阻止事故影响新的任务、资源、用户、站点或系统。

Shutdown：停止指定执行能力。 目标是终止、暂停或拒绝相关执行路径，尤其是高风险写操作。

Recovery：恢复可信业务状态。 目标是确认异常已经得到处理、外部影响已经核对，并在满足重新准入条件后恢复相应服务。

因此：Containment 不一定需要关闭全部服务；Shutdown 不保证已经恢复数据；Recovery 更不能简单等于重新启动进程。

四、建立第一个核心模型：Containment Control Plane

前面几篇已经建立了 Governance Engine、Authority Graph、Capability、Workload Identity 和 Continuous Assurance。

现在需要增加一个独立的控制层：Containment Control Plane。

其职责是把风险判断转化为可以被基础设施和执行网关强制落实的控制动作。

Continuous Assurance
        ↓
Risk / Incident Detection
        ↓
Containment Controller
        ↓
+--------------------------+
| Policy & Capability Gate |
+--------------------------+
        ↓
+--------------------------+
| Workflow Control         |
+--------------------------+
        ↓
+--------------------------+
| Tool / MCP Action Gateway|
+--------------------------+
        ↓
+--------------------------+
| External Effect Control  |
+--------------------------+
        ↓
Production Systems

这里有一条非常重要的设计原则：Containment Controller 必须在安全职责上独立于被它控制的 Agent。

不能让发生异常的 Agent 自己决定是否关闭自己。更不能只向 Agent 发送一句“Please stop executing further actions”，然后把模型是否遵守这句话作为唯一保护机制。

模型可以接收停止通知，但关键权限必须由独立的确定性控制层执行撤销或拒绝。

五、Agent Kill Switch 应该切断什么？

很多系统把 Kill Switch 设计成：

kill(agent_process)

这只是进程控制。

对于生产 Agent，一个真正有意义的 Kill Switch 至少需要覆盖五个层面。

第一层：Admission Control。 禁止新的任务进入指定 Agent 或 Workflow。

第二层：Authority Control。 撤销、暂停或拒绝相关 Capability。

第三层：Execution Control。 阻止正在执行的工作流继续发起后续操作。

第四层：Effect Control。 在真正改变生产状态的边界上，重新验证授权，并拒绝未经允许的新写入。

第五层：Recovery Control。 阻止系统在没有重新获得授权和通过安全验证之前自动恢复高权限行为。

这五层共同构成：

Stop New Work
+
Revoke Authority
+
Stop Further Execution
+
Fence Production Writes
+
Block Unsafe Restart

Kill Switch 的真正目标不是关掉一个进程，而是关闭一条不再可信的生产权限路径。

六、先理解 Circuit Breaker：技术熔断不等于 Agent 安全熔断

Circuit Breaker 是分布式系统中成熟的可靠性设计模式。

以 Envoy 为例，官方文档描述的熔断控制可以限制上游连接数、并发请求数和排队请求数，从而在后端过载时快速失败、实施反压。

参考：Envoy Gateway — Circuit Breakers

这种机制解决的是：

Upstream Failure
↓
Request Pressure
↓
Resource Exhaustion
↓
Cascading Failure

但 AI Agent 的安全风险不一定表现为网络错误。

一个 Agent 可能 API 调用全部返回 200、平均延迟完全正常、CPU 和内存指标健康、WordPress 成功执行所有修改，与此同时它却在修改错误的页面。

因此：

HTTP Success
≠
Authorized Action

Infrastructure Healthy
≠
Agent Behavior Safe

所以需要在传统基础设施熔断之外增加 Semantic / Authority-aware Circuit Breaker。

这里的 Semantic Circuit Breaker 是本项目定义的治理层概念，并不是 Envoy 官方已提供的一种 Agent 语义熔断产品。

七、AI Agent Circuit Breaker 应该监测两类风险

第一类是基础设施异常：连续超时、请求失败率增加、上游不可用、资源消耗失控，以及重试次数异常。

第二类是行为和权限异常：

Unauthorized Tool Attempt

Unexpected Production Mutation

Policy Violation

Prompt Injection Detection

Unapproved Tool Catalog Change

Evidence Coverage Failure

Critical Evaluation Regression

Autonomy Budget Exhausted

两类信号必须区分处理。网络超时可能只需要暂停某个 API 的调用。但未经授权的内容删除尝试，可能要求立即撤销该 Agent 的全部生产写权限。

故障熔断应按故障域执行；权限熔断则应按风险和影响边界执行。

八、定义 Circuit Breaker State Machine

传统熔断器常见 CLOSED、OPEN 和 HALF_OPEN 状态。

Agent Runtime 可以借鉴这个思想，但不能直接把 HALF_OPEN 等同于恢复写权限。

本项目建议定义：

CLOSED
  ↓
TRIPPED
  ↓
OPEN
  ↓
PROBE_ONLY
  ↓
REVALIDATED
  ↓
CLOSED

CLOSED 表示正常允许经过授权的操作。TRIPPED 表示异常触发熔断。OPEN 表示禁止指定范围内的新操作。PROBE_ONLY 表示允许有限的健康检查、只读测试或沙盒评估。REVALIDATED 表示当前证据重新满足预定条件。最后才可以重新 CLOSED。

对于高风险写操作，禁止直接：

OPEN
↓
Timeout Expired
↓
FULL_AUTONOMY

原因很简单：时间流逝不是风险已经消失的证据。

尤其在安全事故中，自动重试之前必须明确区分“服务恢复正常”和“系统重新值得信任”。

九、Kill Switch 必须区分 Soft Stop、Hard Stop 和 Emergency Isolation

并非所有异常都需要同一种响应。

Soft Stop：有序停止

适用于没有发现恶意或严重失控迹象，但需要暂停执行的情况。

例如模型评估质量下降、知识库过期，或者业务规则需要重新审核。

系统可以停止接收新任务，允许已经通过授权且无风险的只读任务完成，并禁止开始新的写操作。

Hard Stop：强制终止后续执行

适用于已经出现明确权限异常或高风险行为的情况。

系统应撤销相关 Capability、阻止新的 Tool Call、取消可以安全取消的任务，并冻结相关队列的写执行。

Emergency Isolation：应急隔离

适用于存在持续未授权访问、数据泄漏、跨资源影响或其他严重风险的情况。

系统需要立即阻断指定 Agent 对相关外部系统的访问，撤销适用的短期凭证或授权，并隔离被怀疑失去可信性的工作负载和工具连接。

三者的选择需要取决于：

Risk Severity
+
Blast Radius
+
Reversibility
+
Current Execution State
+
Evidence Confidence

而不只是某个模型输出的“风险分数”。

十、Graceful Degradation：安全降级不等于全面瘫痪

真正成熟的 Agent 平台不能一出问题就停止所有业务。

我们可以把 Agent 能力拆解成不同等级：

FULL_AUTONOMY
↓
LIMITED_AUTONOMY
↓
HUMAN_APPROVED_WRITE
↓
DRAFT_ONLY
↓
READ_ONLY
↓
QUARANTINED
↓
DENY

对于 SEO / GEO 系统，这具有非常实际的意义。

例如 Publisher Agent 出现事实准确率回归时，我们完全可以：

• 停止自动发布；
• 继续允许研究资料采集；
• 继续允许文章草稿生成；
• 强制人工审核；
• 保留正常运行的网站；
• 保留 GSC、GA4 数据监测。

也就是说：失去一项高风险能力，不应该自动失去所有低风险能力。

但这也有前提：不同能力之间已经建立明确隔离，不会通过其他工具绕过被撤销的权限。

十一、Safe State 必须按业务定义，而不是统一设为 OFF

所谓 Safe State，是在异常或不确定性条件下，系统进入一个事先定义、风险可接受且可验证的运行状态。

不同 Agent 的 Safe State 可以完全不同。

这也意味着：

Safe State
≠
Every Component Disabled

一个好的 Safe State，应保留事故诊断、人工干预、证据记录和安全恢复所需的最小能力。

十二、SEO 系统中的一个特殊风险：错误的 Kill Switch 会造成更大的搜索事故

对于搜索营销基础设施，不能把“暂停自动化”理解成“关闭整个网站”。

Google Search Central 的网站暂停文档明确建议：如果只是暂时无法开展部分业务，应尽量保持网站在线，并限制受到影响的功能。

对于短期关闭网站，Google 提供了关于 503 Service Unavailable 的指导，同时警告长时间关闭网站可能产生显著搜索影响。

参考：Google Search Central — Temporarily Pause or Disable a Website

因此，SEO Publisher Agent 失控时，合理操作通常是：

Stop Automatic Publishing
↓
Freeze Risky Mutations
↓
Keep Public Website Available
↓
Preserve Existing Content
↓
Continue Monitoring

而不是：

Agent Failure
↓
Website Shutdown
↓
All URLs Return 503

尤其不能为了停止一个 Agent，就随意修改全站 robots.txt、添加 noindex、删除 sitemap 或撤销正常页面的公开访问。

对于 SEO 自动化，最小化 Blast Radius 还必须包括保护正常的 Crawlability、Indexability 与已有内容资产。

十三、现在进入真正困难的部分：In-flight Execution

假设系统在 10:00:00 发出了停止命令。

但在此之前：

09:59:57
Agent A:
Publish article X

09:59:58
Agent B:
Update article Y

09:59:59
Agent C:
Modify sitemap

10:00:00
Kill Switch Activated

此时立即停止三个 Agent 的进程，并不能证明这三个操作都没有完成。

外部系统可能已经接受了请求。其中某个请求可能已经写入成功，但响应在网络途中丢失。

因此必须区分：

Not Started

Accepted But Not Started

Running

External Request Sent

External Effect Confirmed

Outcome Unknown

其中最危险的状态之一是 Outcome Unknown。

因为如果系统把 UNKNOWN 当作 FAILED，然后盲目重试，就可能制造重复发布、重复修改或其他二次影响。

十四、引入 Execution Fencing：阻止旧执行继续拥有写权限

仅有 Capability Revocation 仍然不够，因为已有执行可能持有一份尚未过期的授权。

我们需要进一步建立 Execution Fencing。

核心思想是：每次关键控制状态变化，都为相关执行范围增加一个不可回退的控制版本。

本项目可以称其为 Safety Epoch。

例如：

Safety Epoch = 41

Agent A:
Capability Epoch = 41

Agent B:
Capability Epoch = 41

当发生重大风险事件：

Containment Activated

Safety Epoch:
41 → 42

此后任何来自旧版本的写执行：

Request Epoch = 41

Current Safety Epoch = 42

Decision:
DENY

必须被拒绝。

这相当于给既有权限增加一个“已经失效的时代编号”。

需要注意：单纯把 Epoch 存在 Agent 内存中没有用。真正执行写操作的 Action Gateway 或下游 Effect Service 必须能够核验该版本。

十五、为什么 Safety Epoch 比普通 Token Expiration 更有意义？

Token Expiration 只能保证凭证最终过期，但对于正在发生的事故，等待过期可能太慢。

例如：

Token TTL:
15 minutes

Containment Triggered:
Now

Remaining Token Lifetime:
12 minutes

如果系统只能等待 Token 到期，就可能继续暴露 12 分钟。

Safety Epoch 可以让系统在每次高风险写操作的准入或提交边界，立即发现授权已经不再属于当前安全版本。

更重要的是，Epoch 必须与实际资源范围绑定，例如：

tenant_id
site_id
agent_id
workflow_id
resource_scope
safety_epoch

否则，一个站点的安全事件可能错误地冻结所有租户。

反过来，如果事件影响共享凭证、共享 MCP Server 或共享写网关，则只冻结某个 Agent 又可能不足以隔离风险。

十六、真正的执行验证应发生在产生外部影响之前

建议把写操作路径设计为：

Agent Decision
↓
Tool Call Proposal
↓
Action Gateway
↓
Capability Validation
↓
Safety Epoch Check
↓
Current Risk Check
↓
Autonomy Budget Check
↓
Effect Admission
↓
Production Mutation
↓
Effect Receipt

其中，Effect Admission 是一个关键点。

例如以下逻辑：

def authorize_effect(request, current_state):
    if current_state.containment == "ACTIVE":
        return "DENY"

    if request.safety_epoch != current_state.safety_epoch:
        return "DENY_STALE_EXECUTION"

    if not capability_is_valid(request.capability):
        return "DENY_CAPABILITY"

    if not action_is_allowed(request.action, request.resource):
        return "DENY_POLICY"

    if not within_autonomy_budget(request):
        return "REQUIRE_REVIEW"

    return "ALLOW"

上述代码只是说明控制逻辑的伪代码，不是可以直接接入生产环境的完整授权实现。

还要解决一个实际竞态条件：

如果授权检查刚刚通过，随后系统进入隔离状态，但外部写请求还没有发出怎么办？

因此对高风险操作，需要把最终写操作与强制授权校验尽可能放在同一个受控执行边界。

对于不能提供原子授权检查的外部 API，应使用串行化写网关、短期执行 Lease、二次提交检查和事后效果核对等措施缩小竞态窗口。

不要声称仅有一次远程策略查询就能保证绝对安全。

十七、Containment Controller 必须处理分布式传播

AI Agent 很少永远只运行在一个进程里。

典型的多 Agent 流程可能是：

Orchestrator
     ↓
Research Agent
     ↓
Content Agent
     ↓
Publisher Agent
     ↓
WordPress

还可能存在：

Publisher Agent
     ├── Website Publish
     ├── Sitemap Update
     ├── Social Distribution
     └── Monitoring Task

如果只对最初的 Orchestrator 发出 Stop 命令，已经接收工作的 Publisher Agent 仍然可能执行。

因此需要建立 Containment Propagation Graph。

它不是普通的任务依赖图，而是用于回答：

哪些下游工作流、授权、工具调用、队列消息与生产资源，已经受到这次风险事件的影响？

我们应当从第（三十六）篇的 Causality 和第（三十四）篇的 Resource Ownership 继续扩展：

Incident
↓
Affected Intent
↓
Affected Workflow
↓
Affected Agent
↓
Affected Capability
↓
Affected Tool Calls
↓
Affected Resources
↓
Affected Production Effects

只要不能确认影响已经被限定，就不能宣称 Containment Completed。

十八、Blast Radius 应该被明确建模

传统系统经常用受影响服务数量衡量故障范围，但 AI Agent 的 Blast Radius 应该更加具体。

至少包括：

Resource Radius： 影响了多少页面、文件、数据库记录和配置。

Tenant Radius： 影响了多少租户、站点或客户。

Authority Radius： 哪些权限可能被滥用。

Dependency Radius： 哪些下游 Agent、Tool 和 Workflow 可能继续传播影响。

Temporal Radius： 异常开始到有效隔离之间的时间范围。

Irreversibility Radius： 哪些影响无法简单撤销。

External Visibility Radius： 哪些修改已经被外部系统、用户或搜索平台观察到。

例如一个错误的自动发布，不应该只记录：

Affected Posts: 12

还应该知道：

Published Posts: 12
Indexed Posts: Unknown
External Shares: 3
Canonical Changes: 0
Sitemap Changes: 1
Downstream Jobs: 6

其中的 UNKNOWN 不能擅自填为 0。

十九、Bulkhead Architecture：为什么必须把 Agent 按资源和权限分舱？

AWS Well-Architected Framework 建议通过 Bulkhead 或 Cell-based Architecture 限制故障影响范围。

它的思路很直接：让不同工作负载在相对独立的单元中运行，尽可能避免某一个单元发生故障时波及所有其他单元。

参考：AWS — Bulkhead Architecture

对于 SEO / GEO Agent 平台，可以进一步采用：

Tenant Isolation
+
Site Isolation
+
Agent Isolation
+
Tool Isolation
+
Credential Isolation
+
Queue Isolation

例如：

Agent A
→ Site A
→ Capability A
→ Publishing Queue A

Agent B
→ Site B
→ Capability B
→ Publishing Queue B

当 Site A 出现事故时，系统应能够冻结 Site A 的写操作，而不必停止 Site B 的研究和正常发布。

但隔离不能仅停留在逻辑标签上。

如果两个站点实际共享一份拥有全部网站管理权限的长期凭证，那么所谓 Site Isolation 很可能只是表面上的。

Blast Radius 是由真实的权限边界和依赖关系决定的，不是由服务名称决定的。

二十、Quarantine：隔离和停止有什么区别？

Stop 主要控制执行。Quarantine 则处理信任问题。

如果系统发现一个 MCP Server 返回了异常工具定义，那么即使相关工作流已经停止，该 MCP Server 仍可能是不可信的。

如果一个 RAG Corpus 被污染，那么关闭当前 Agent 进程也不能清除被污染的数据。

因此隔离对象可能包括：

Agent Runtime

Workload Identity

Tool / MCP Server

Queue Messages

Prompt Version

Model Configuration

Knowledge Corpus

Retrieved Documents

Production Artifact

例如：

MCP Tool Definition Drift
↓
Quarantine MCP Server
↓
Disable High-Risk Tool Calls
↓
Preserve Manifest
↓
Investigate Provenance
↓
Revalidate Tool Catalog
↓
Controlled Re-admission

对于已经怀疑被恶意利用的执行环境，隔离还应防止其继续访问凭证或网络出口，并保留必要的取证证据。

需要注意：隔离环境不能继续持有原有高权限访问能力，否则所谓 Quarantine 不具备实际隔离意义。

二十一、暂停任务调度并不等于取消已经启动的工作

Kubernetes CronJob 官方文档明确指出：将 .spec.suspend 设置为 true，会暂停后续 Job 的执行，但不会影响 CronJob 已经启动的 Job。

参考：Kubernetes — CronJob

这个机制说明了一类非常普遍的工程问题：

Scheduler Paused
≠
Running Work Cancelled

对于 SEO 自动化系统，同样如此。

关闭每天 05:00 的发布任务，只能阻止后续定时触发。不能自动撤销：

• 已经被 Worker 领取的任务；
• 已经排入消息队列的任务；
• 正在执行的 WordPress API 请求；
• 已经注册的重试任务；
• 已经触发的后续工作流。

因此，Containment Controller 必须能够识别 Scheduler、Queue、Worker、Workflow 和 Effect Gateway 各自的控制范围。

二十二、队列中的 Poison Message 可能制造持续事故

假设某个错误任务会删除一批页面。执行失败以后，它被放回队列。系统重新启动，任务再次执行。又失败，又重试。

于是：

Bad Task
↓
Failure
↓
Retry
↓
Partial Mutation
↓
Failure
↓
Retry
↓
More Damage

这类问题不能靠无限重试解决。

对于明确违反策略、权限或 Schema 的任务，应当进入 Dead-letter / Quarantine Queue。

队列中的消息需要保留：

message_id
workflow_id
original_intent
capability_id
safety_epoch
attempt_count
failure_reason
payload_reference
effect_status

恢复过程中，不能简单地“重新消费所有失败任务”。

必须先区分：

Retryable Failure

Non-retryable Failure

Policy-denied Task

Unknown External Outcome

Poison Message

只有确认满足当前权限与业务条件后，才可以重新执行。

二十三、Rollback 与 Compensation：为什么分布式系统不能轻易承诺“全部撤销”？

假设一个自动内容发布工作流已经完成：

Create WordPress Post
↓
Publish Post
↓
Update Sitemap
↓
Send Social Message
↓
Trigger Monitoring

随后系统发现文章存在严重错误。

此时，“恢复到之前的状态”并不是一个简单的数据库事务。我们或许可以恢复 WordPress 文章内容，但已经发送出去的社交消息无法保证被所有用户撤回；搜索引擎可能已经抓取页面；缓存系统可能已经保存旧版本。

因此：

Rollback
≠
Erase All Historical Effects

这就需要引入 Compensating Action。

Temporal 的 Saga Pattern 文档明确讨论了多步骤分布式事务的补偿机制，包括对已经产生外部副作用的步骤注册对应补偿动作，并提醒补偿必须考虑幂等性、部分成功和重试。

参考：Temporal — Saga Pattern

二十四、Compensating Action 不是把数据库恢复到昨天

对于 WordPress 自动发布，可以建立：

Forward Action:
PUBLISH_POST

Possible Compensation:
RESTORE_PREVIOUS_REVISION
or
CHANGE_STATUS_TO_DRAFT

但这两种补偿并不等价。

恢复 Revision，可能使正文内容恢复。改成 Draft，可能使页面对外不再可见。两者造成的 SEO 后果也可能不同。

对于更高风险的操作：

Forward:
DELETE_PAGE

Compensation:
RESTORE_PAGE

即使恢复了页面，也需要继续验证 URL、HTTP 状态、Canonical、Internal Links、Sitemap 和结构化数据是否恢复。

更重要的是，某些操作本身无法完整补偿。例如发送邮件、向外部平台传播信息，或者让搜索引擎观察到错误内容。

因此，应明确区分：Fully Reversible、Partially Reversible、Compensable、Irreversible。

在赋予自治权限之前，就应该完成这种分类。

二十五、每个高风险 Tool 必须有明确的 Compensation Contract

前面的系列已经要求 Tool 有权限边界、Schema、Identity 和 Provenance。

现在进一步要求：Effect + Compensation Contract。

例如：

tool: publish_wordpress_post

effect:
  type: EXTERNAL_MUTATION
  system: wordpress

reversibility:
  class: PARTIALLY_COMPENSABLE

preconditions:
  - valid_capability
  - current_safety_epoch
  - approved_content

required_evidence:
  - post_id
  - previous_status
  - previous_revision
  - request_id
  - response_receipt

compensation:
  action: restore_previous_state
  human_review: conditional

verification:
  - rest_api_state
  - public_url_state
  - content_markers

limitations:
  - external_cache_may_persist
  - search_crawling_cannot_be_undone

这份 Contract 是本项目提出的工程 Schema 示例，并不是 WordPress 或 Temporal 的官方字段规范。

它的核心意义是：不能只设计一个工具如何成功执行，还必须预先设计它执行错误以后能够怎样止损。

二十六、补偿必须处理未知结果，而不是立即重试

这是一个很容易被忽视的细节。

假设：

POST /wp/v2/posts
↓
Server Created Post
↓
Network Timeout
↓
Agent Received No Response

Agent 看到的是 Timeout，但 WordPress 可能已经创建文章。

如果直接重试 POST，可能创建重复文章。

因此：

Timeout
≠
Operation Failed

正确处理方式应该是先核对外部效果。

例如使用预先确定的 slug、关联记录、业务唯一标识或其他可验证的关联条件，判断目标文章是否已经存在。

对于支持 Idempotency Key 的外部 API，可在其明确保证的范围内使用幂等键。

对于 WordPress 等未为某项操作提供相同幂等保证的 API，必须通过应用层的唯一性策略、冲突检测和执行结果回读补足。

Effect Reconciliation 应该优先于 Blind Retry。

二十七、引入 Effect Ledger：生产影响必须成为独立记录

到第（三十九）篇，我们已经有 Production Trace、Evaluation Evidence 和 Assurance State。

但真正发生事故时，还需要更具体的外部效果账本：Effect Ledger。

它应记录：

effect_id
intent_id
workflow_id
agent_id
tool_call_id
capability_id
safety_epoch

resource_id
action
request_id

effect_state
external_receipt
observed_at

compensation_state
verification_state

这样系统才能回答：哪个操作已经发送？哪个操作已经被外部系统接受？哪个操作确认生效？哪个结果仍然未知？哪个影响已经补偿？哪个影响无法补偿？哪个结果已经完成再次验证？

没有 Effect Ledger，事故恢复经常只能依靠查询多个日志和人工猜测。

而日志中出现 200 OK，也未必已经证明最终业务状态符合预期。

二十八、Incident Command：AI 事故不能由十几个 Agent 同时指挥

当一个生产事故涉及多个 Agent、Tool 和工作流时，很容易出现：

Agent A:
Rollback

Agent B:
Retry

Agent C:
Republish

Agent D:
Rebuild Sitemap

这四种动作可能互相冲突。

Google SRE 的 Incident Management 方法强调 Incident Commander、Operations Lead 和 Communications Lead 等明确角色，以及响应过程中的协调、沟通与控制。

参考：Google SRE Workbook — Incident Response

本项目需要继续把这套思想引入 Agent 治理：

Incident Command Authority 必须高于普通 Agent 自治权限。

在事故发生时，所有相关自动化必须服从统一的 Incident State 与 Control Policy。

二十九、建立 AI Incident Command Hierarchy

一个可行的组织结构是：

Human Incident Commander
          ↓
Incident Control Plane
          ↓
+---------------------------+
| Containment Controller    |
| Effect Reconciliation     |
| Recovery Coordinator      |
| Evidence Collector        |
| Communications            |
+---------------------------+
          ↓
Controlled Agents / Tools

其中：

Human Incident Commander 对高风险事故的处置方向和恢复授权承担最终责任。

Containment Controller 负责落实权限冻结、隔离、熔断和任务停止。

Effect Reconciliation 负责确认真实生产影响。

Recovery Coordinator 负责执行已经批准的恢复步骤。

Evidence Collector 负责保存 Trace、版本、操作记录和取证证据。

Communications 负责对内外部相关方传递准确的事故状态。

这里允许 Agent 辅助调查、摘要和提出建议，但不能让正在接受事故调查的 Agent 自己批准恢复全部权限。

三十、Incident Command 还需要防止 Recovery Race

所谓 Recovery Race，是多个恢复动作在同一资源上并发执行。

例如：

Recovery Agent A:
Restore Revision 12

Recovery Agent B:
Restore Revision 14

Human Operator:
Restore Revision 13

如果三者没有协调，就可能出现 Last Writer Wins，最终结果反而不确定。

因此恢复操作必须遵守此前建立的：

Resource Ownership
+
Lease
+
Lock
+
Authority Graph
+
Safety Epoch

在关键资源上，必须由明确的恢复执行者持有临时控制权。其他执行者只能观察、提出建议或等待。

这意味着从第（三十四）篇开始讨论的 Multi-Agent Coordination，在事故阶段成为强制性的安全要求，而不只是性能优化。

三十一、事故状态机：从异常发现到安全恢复

本项目建议建立以下 Runtime Incident State Machine：

NORMAL
↓
SUSPECTED
↓
CONTAINMENT_REQUIRED
↓
CONTAINING
↓
CONTAINED
↓
EFFECT_RECONCILIATION
↓
REMEDIATION
↓
RECOVERY_CANDIDATE
↓
REVALIDATION
↓
LIMITED_RECOVERY
↓
NORMAL

其中还需要允许：

ANY ACTIVE INCIDENT STATE
↓
QUARANTINED

以及：

RECOVERY FAILURE
↓
RE-CONTAINMENT

重要的是，状态迁移应当有明确的证据条件。

例如 CONTAINED 不能仅因为已发送停止命令就成立。

必须确认相关执行路径已经被限制，受影响的写权限已经被撤销或阻断，并且仍在执行或结果未知的操作已经被识别。

RECOVERY_CANDIDATE 也不意味着已经恢复正常。它只表示事故处理结果具备进入重新验证阶段的条件。

三十二、最重要的状态之一：CONTAINED

建议为 CONTAINED 设置严格的准入条件。

No New Unauthorized Admission

No Valid Stale Write Capability

Affected Tool Paths Blocked

High-Risk Queues Frozen

Affected Workflows Identified

In-flight Effects Reconciled
or Explicitly Marked Unknown

Containment Evidence Recorded

如果某个外部操作结果仍然未知，并且它可能继续造成影响，就不能轻易把事故标记为完全受控。

这里可以再增加一个中间状态：

CONTAINED_WITH_RESIDUAL_UNCERTAINTY。

它表示：主要风险传播路径已被阻断，但仍然存在尚未完成确认或补偿的历史影响。

这种表达比简单输出 CONTAINED: true 更有审计价值。

三十三、建立 Containment Receipt

前面的系列已经有 Execution Receipt、AI Decision Receipt 和 Evaluation Attestation。

第（四十）篇需要增加：Containment Receipt。

例如：

{
  "incident_id": "INC-040-001",
  "agent_id": "seo-publisher",

  "trigger": "UNAUTHORIZED_WRITE_ATTEMPT",

  "scope": {
    "site": "seo-cn",
    "actions": ["PUBLISH_POST", "DELETE_POST"]
  },

  "previous_safety_epoch": 41,
  "new_safety_epoch": 42,

  "containment": {
    "admission_frozen": true,
    "write_capabilities_revoked": true,
    "tool_gateway_fenced": true,
    "queued_work_quarantined": true
  },

  "effect_reconciliation": {
    "confirmed_effects": 3,
    "unknown_effects": 1,
    "compensated_effects": 2
  },

  "state": "CONTAINED_WITH_RESIDUAL_UNCERTAINTY"
}

示例数字纯属说明 Schema，不代表项目已经发生这些生产事故。

Containment Receipt 的核心价值不是让事故记录更漂亮，而是可以证明：控制措施具体执行到了哪个资源、哪个授权版本、哪个工具与哪个外部效果边界。

三十四、Forensics：事故恢复之前，不能先破坏证据

生产事故有一个典型的错误处理方式：

Something Went Wrong
↓
Delete Logs
↓
Restart Everything
↓
Hope It Works

这种做法可能破坏调查所需的证据。

对于 AI Agent，必须保留：

Intent Receipt

AI Configuration Identity

Model / Prompt / Tool Versions

Execution Trace

Capability Issuance

Authorization Decisions

Tool Calls

External Effect Receipts

Containment Events

Recovery Actions

同时还应保护日志和取证数据本身的完整性，记录时间、操作者、来源及关键数据的 Hash 或其他适用完整性证据。

但是，保留证据不代表把用户敏感数据、Secret、完整 Prompt 和内部文档无限制地写进普通日志。

应使用受控存储、访问审计、必要脱敏及合理的数据保留策略。

事故证据必须可用，但不能为了可追踪性制造第二个数据安全事故。

三十五、Recovery 不应立即恢复 Full Autonomy

事故得到控制以后，一个常见冲动是：

Problem Fixed
↓
Restart Agent
↓
FULL_AUTONOMY

这正是应该避免的恢复路径。

第（三十九）篇已经建立了 Continuous Assurance。

因此恢复也必须重新检查：

Approved AI Configuration

Corrected Failure Cause

Updated Evaluation

Current Tool / Corpus Integrity

Capability Policy

Red Team or Targeted Safety Test

Rollback Readiness

Human Approval

尤其在此前发生过未授权写操作时，不应该只通过一次普通质量 Benchmark 就恢复生产权限。

应该针对已经暴露的 Failure Mode 进行定向验证。

三十六、Controlled Recovery 应该分阶段进行

建议恢复采用：

QUARANTINED
↓
READ_ONLY
↓
SHADOW
↓
HUMAN_APPROVED_WRITE
↓
LIMITED_AUTONOMY
↓
FULL_APPROVED_AUTONOMY

每一个状态都有单独的准入门槛。

READ_ONLY： 确认系统能够安全读取、诊断和处理数据，但不能修改生产资源。

SHADOW： 允许 Agent 处理真实任务的复制输入，但输出不进入真实写操作路径。

HUMAN_APPROVED_WRITE： 允许执行受到明确人工批准的有限写操作。

LIMITED_AUTONOMY： 允许在严格限定的数量、资源范围和时间窗口内自主执行。

FULL_APPROVED_AUTONOMY： 只有在新的 Assurance Evidence 覆盖目标任务和权限范围时，才恢复完整的已批准自治能力。

需要强调：恢复更高自治权限，是一次新的授权决策，而不是事故状态清除后的默认行为。

三十七、什么是 Autonomous Recovery？

Autonomous Recovery 不应该理解成“AI Agent 自己修复一切，然后自动重新上线”。

在生产工程中，更合理的定义是：

在预先批准的风险边界、操作集合与验证条件下，由系统自动执行可控的恢复步骤；对于超出边界或需要重新授予高风险权限的操作，仍然交由适当的人类或独立治理控制层批准。

例如下面这些场景可能适合高度自动化：

• 重启无状态只读 Worker；
• 清理安全且可重复执行的临时资源；
• 将特定非关键工作流切换到已验证的备用服务；
• 把失败任务隔离到 Quarantine Queue；
• 将 Publishing Agent 自动降级为 Draft Only；
• 对已明确成功且可幂等的状态核对操作进行重试。

但以下操作通常不宜在缺少额外授权的情况下自动执行：

• 批量删除页面；
• 修改大规模 Redirect；
• 修改 robots.txt 的全站规则；
• 恢复已被怀疑泄漏的凭证；
• 重新授予发生过严重越权行为的 Agent 完整权限；
• 大范围覆盖生产数据库或配置。

核心原则是：

Automate Safe Recovery Steps

Do Not Automate
Unbounded Recovery Authority

三十八、Recovery Agent 必须比正常 Agent 权限更清晰，而不是更宽

一个常见设计缺陷是：Normal Agent 权限受到严格限制，但 Recovery Agent 拥有近乎无限的管理员权限。

这可能把风险从业务 Agent 转移到恢复 Agent。

因此 Recovery Agent 必须具备：

Scoped Recovery Capability

Approved Recovery Plan

Resource Lock / Lease

Limited Execution Window

Execution Fencing

Independent Verification

Recovery Receipt

如果需要执行高权限操作，可以通过独立审批、短期凭证和专门 Recovery Capability 完成，而不是把长期管理员密钥直接交给恢复 Agent。

Recovery Authority 也是 Authority，也必须受到治理。

三十九、建立 Recovery Plan 与 Recovery Receipt

一个成熟的 Recovery Plan 至少应该明确：

incident_id: INC-040-001

target:
  agent: seo-publisher
  site: seo-cn

recovery_goal:
  - restore_safe_publishing
  - preserve_public_site

preconditions:
  - containment_verified
  - affected_effects_reconciled
  - root_cause_mitigated
  - approved_configuration_available

steps:
  - verify_wordpress_state
  - check_previous_revisions
  - validate_public_urls
  - run_targeted_evaluation
  - enable_shadow_mode
  - request_reauthorization

rollback_on_failure:
  - revoke_new_capabilities
  - return_to_quarantine

approval:
  required_for_full_autonomy: true

执行结束以后，必须生成 Recovery Receipt。

Recovery Receipt 不应只记录 status: success，还应绑定目标状态、实际恢复操作、验证证据、残余风险、授权人和恢复后的权限范围。

这样才能证明：系统不只是重新运行了，而且已经按照预先批准的恢复条件重新运行。

四十、用一个完整的 SEO Publishing Incident 串起全部机制

假设某天，SEO Publisher Agent 正在为一个工业设备网站批量发布内容。

正常工作流：

Research
↓
Draft
↓
Fact Check
↓
Editorial
↓
Publish
↓
Verify

但是在一次异常执行中，Agent 开始尝试对不属于当前任务的旧页面进行批量修改。

阶段一：Detection

Action Gateway 发现：

Requested Action:
UPDATE_EXISTING_POSTS

Approved Intent:
PUBLISH_ONE_NEW_ARTICLE

Mismatch:
TRUE

于是 Authorization: DENY。

与此同时，Continuous Assurance 检测到异常 Tool-use Pattern。

阶段二：Containment

系统执行：

Safety Epoch:
61 → 62

Publisher:
WRITE_DISABLED

Publishing Queue:
FROZEN

Related Capability:
REVOKED

所有新的写操作都必须重新经过当前 Epoch 检查。

阶段三：Execution Reconciliation

系统查找最近已经发出的请求：

Request A:
SUCCESS

Request B:
UNKNOWN

Request C:
DENIED

其中 Request B 需要通过 WordPress REST API 与 Effect Ledger 回读核对，不能直接重试。

阶段四：Safe State

Publisher 进入 DRAFT_ONLY。研究、写作、事实核验仍可以继续。网站前台正常运行。

历史页面保持可访问，除非某个具体页面本身需要采取经过评估的紧急内容处置。

阶段五：Remediation

事故调查发现：某个 Tool 的 Action Scope 配置错误，允许调用不符合当前发布意图的旧页面更新操作。

系统修复 Scope，更新 Tool Manifest，并重新执行相关 Evaluation。

阶段六：Revalidation

测试重点不只是内容质量，还应包含：

Intent-to-Action Binding

Resource Scope Validation

Unauthorized Tool Rejection

Safety Epoch Enforcement

Effect Reconciliation

Rollback Test

阶段七：Controlled Recovery

首先进入 SHADOW，比较新旧行为。

随后经人工审批，允许少量指定文章发布。

确认没有异常后，按照新的 Assurance Case 逐步提升 Autonomy Budget。

最终生成：

Incident Receipt
+
Containment Receipt
+
Effect Reconciliation
+
Evaluation Attestation
+
Recovery Receipt

这才构成完整的事故闭环。

四十一、建立一份真正可以执行的 Incident Response SOP

根据前面的架构，可以给 SEO / GEO Agent 平台设计一份标准事故响应流程。

Step 1：Declare Incident。 确定事故 ID、严重程度、初步影响范围与负责人。

Step 2：Preserve Evidence。 保护原始 Trace、配置版本、授权记录和关键外部效果证据。紧急止损不应因为等待证据收集而被无谓推迟；证据保全和隔离可以并行进行。

Step 3：Contain Authority。 冻结新任务准入，撤销适用权限，提高 Safety Epoch，并阻断高风险写路径。

Step 4：Contain Execution。 停止后续工具调用，暂停相关 Worker 和队列，识别仍在运行的操作。

Step 5：Map Blast Radius。 根据 Intent、Workflow、Agent、Capability 和 Resource 构建影响图。

Step 6：Reconcile Effects。 核对所有已发送、已确认以及结果未知的外部操作。

Step 7：Select Recovery Strategy。 按可逆性和实际影响选择恢复版本、补偿、人工处置或继续隔离。

Step 8：Execute Controlled Recovery。 通过专门 Recovery Capability 执行批准的恢复计划。

Step 9：Revalidate。 重新进行针对性测试、权限验证、功能验证与生产状态检查。

Step 10：Reauthorize。 按照新的 Assurance Evidence 恢复有限权限，再依据观察结果逐步提升自治能力。

Step 11：Post-Incident Review。 将事故原因、故障传播路径、控制缺陷和有效恢复措施写回知识库与标准流程。

这一套 SOP 与 NIST SP 800-61 Rev.3 关于把事故响应纳入网络安全风险管理、提高检测响应与恢复效率的方向一致。

参考：NIST SP 800-61 Rev.3（2025 年 4 月最终版）

但上述 11 步是本项目为 SEO / GEO Agent 组织的实践 SOP，不是 NIST 原文规定的统一十一阶段模型。

四十二、恢复后的生产状态还需要持续观察

即使 Recovery Gate 已经通过，也不能认为事故永远结束。

Recovered
↓
New Production Traffic
↓
Online Evaluation
↓
Drift Detection
↓
Risk Recalibration

如果同一类异常再次出现，应当能够立即回到 Containment State。

这要求 Recovery 和 Continuous Assurance 共享同一套证据体系。

不能形成两个彼此脱节的系统：

Monitoring Team:
System Is Unsafe

Recovery Team:
System Is Healthy

真正的目标是：只有当当前证据满足当前权限要求时，系统才可以继续保持相应自治状态。

四十三、需要重点监测的生产指标

传统事故响应关注 MTTR，即 Mean Time to Recovery。

但对于 Autonomous Agent，单一 MTTR 不足以衡量安全能力。

建议建立以下指标：

这些是本项目建议的治理指标，必须在实际系统中规定分母、起止时间、数据采集方式及统计口径，不能未经定义就把它们当成行业通用标准。

其中尤其值得关注：Containment Escape Rate。

如果系统已经宣称 Containment Complete，但旧 Agent 仍然可以产生新的生产写操作，那么 Containment 的有效性实际上存在问题。

四十四、Game Day：必须主动测试 Kill Switch 是否真的有效

一个 Kill Switch 从未经过演练，不能仅凭代码存在就认定它有效。

因此需要设计定期 Game Day。

场景一：Agent 拒绝停止

模拟 Agent 持续发起工具请求。验证 Action Gateway 是否独立拒绝。

场景二：旧 Capability 仍然有效

模拟使用旧 Safety Epoch 发起写操作。

预期：

DENY_STALE_EXECUTION

场景三：队列继续重试

模拟已暂停调度器，但消息队列仍持有待执行任务。验证队列隔离是否阻止新写入。

场景四：外部 API 部分成功

模拟操作已经生效但响应丢失。验证系统是否先核对 Effect，而不是直接重复写入。

场景五：Recovery Agent 越权

模拟恢复任务请求超出原定恢复范围的操作。验证 Recovery Capability 是否拒绝。

场景六：恢复过程中再次触发风险

验证系统能否重新进入 Quarantine，而不是继续提升自治等级。

每一次 Game Day 都应该形成：

Scenario
↓
Expected Behavior
↓
Observed Behavior
↓
Pass / Fail
↓
Evidence
↓
Remediation

测试范围应从沙盒开始，再逐步在经过隔离和批准的环境中开展，避免测试本身制造生产事故。

四十五、Kill Switch 的可用性也需要独立保证

到这里还存在一个容易被忽视的问题：如果 Containment Controller 自己发生故障怎么办？

例如：

Agent:
Unsafe

Containment Controller:
Unavailable

如果整个系统依赖一个在线控制中心持续回答“是否允许写入”，那么控制中心故障时就需要预先确定策略。

建议对高风险生产写路径采取：

Control State Unknown
↓
No New Privileged Write

而不是默认允许。

但是对于正常网站的公开读取、既有内容访问和安全诊断能力，则应设计独立的可用性保障。

这意味着需要明确区分：

Fail Closed for Privileged Mutation。

与：

Maintain Safe Availability for Read-only Services。

在工程实现中，除了控制层冗余，还应考虑本地有效期很短的策略快照、不可回退的版本信息、控制指令完整性校验和恢复路径。

注意：缓存过期的旧 ALLOW 决策不能绕过新的紧急撤销，尤其不能因为控制平面失联就自动恢复旧权限。

四十六、最终形成完整的 AI Runtime Containment Architecture

至此，我们可以把前面讨论过的各个模块组合起来。

                  CONTINUOUS ASSURANCE
                           │
                           ▼
                    RISK DETECTION
                           │
                           ▼
                   INCIDENT DECLARATION
                           │
                           ▼
                  CONTAINMENT CONTROLLER
                           │
            ┌──────────────┼──────────────┐
            │              │              │
            ▼              ▼              ▼
       CIRCUIT         CAPABILITY      WORKFLOW
       BREAKER         REVOCATION      CONTROL
            │              │              │
            └──────────────┼──────────────┘
                           ▼
                     SAFETY EPOCH
                           │
                           ▼
                    ACTION GATEWAY
                           │
                           ▼
                   EXECUTION FENCING
                           │
                           ▼
                    EFFECT BOUNDARY
                           │
                           ▼
                      SAFE STATE
                           │
                           ▼
                EFFECT RECONCILIATION
                           │
              ┌────────────┴─────────────┐
              ▼                          ▼
           ROLLBACK                  COMPENSATION
              │                          │
              └────────────┬─────────────┘
                           ▼
                    INCIDENT FORENSICS
                           │
                           ▼
                     REVALIDATION
                           │
                           ▼
                   CONTROLLED RECOVERY
                           │
                           ▼
                     REAUTHORIZATION
                           │
                           ▼
                  CONTINUOUS ASSURANCE

这个架构最重要的特征是：

Detection、Authority、Execution、Effect 和 Recovery 不再是五套互不相关的机制，而是同一个生产安全闭环的连续阶段。

四十七、Production Authority Eligibility 再次升级

第（三十八）篇要求：

Verified Identity
+
Approved AI Configuration
+
Valid Evaluation
+
Valid Intent
+
Valid Capability

第（三十九）篇增加：

Current Production Evidence
+
Acceptable Risk State
+
Available Autonomy Budget

到了第（四十）篇，还必须增加：

No Active Containment Denial
+
Current Safety Epoch
+
Valid Effect Authorization
+
Acceptable Runtime State

因此最终的生产写权限准入可以表示为：

Production Write Eligibility
=
Verified Identity
∩
Approved Software
∩
Approved AI Configuration
∩
Matching Evaluation
∩
Current Assurance
∩
Valid Intent
∩
Valid Capability
∩
Available Autonomy Budget
∩
Current Safety Epoch
∩
No Active Containment Denial
∩
Valid Effect Policy

这里的交集符号表示所有必要条件必须同时成立，不是某个官方标准已经发布的数学定义。

而一旦进入事故状态：

Containment Denial = ACTIVE

Production Write Eligibility = FALSE

即使 Model = Trusted、Prompt = Approved、Agent Identity = Valid，也不能继续执行被隔离范围内的生产写操作。

四十八、第（四十）篇新的 Safety Invariants

第一条：

Process Stopped
≠
Authority Revoked

第二条：

Scheduler Paused
≠
In-flight Execution Stopped

第三条：

Kill Switch Activated
→
No New Unauthorized Effect

第四条：

Stale Safety Epoch
→
No Privileged Mutation

第五条：

Unknown External Outcome
→
Reconcile Before Retry

第六条：

Containment Scope
must include
affected downstream execution paths

第七条：

Rollback
≠
Historical Effects Erased

第八条：

Unverified Compensation
≠
Recovered State

第九条：

Recovery Authority
must be separately governed

第十条：

No Matching Recovery Evidence
→
No Full Autonomy Restoration

第十一条：

Incident Closed
≠
Risk Permanently Eliminated

第十二条：

Control Plane Unavailable
→
No New High-Risk Write Authorization

这些 Invariants 的实际可执行性必须通过具体系统实现和 Game Day 验证，不能只作为文档声明。

四十九、这一篇真正改变了什么？

回顾此前的系列，Agent Governance 已经逐渐形成几个重要层次。

最开始，我们关注：Agent 能否完成任务。

后来，我们开始关注：Agent 是否在正确的身份、权限、意图和配置下完成任务。

第（三十八）篇进一步要求：能够验证影响 Agent 行为的完整 AI Supply Chain。

第（三十九）篇继续要求：持续证明当前生产行为值得拥有相应自治权限。

但这些都主要解决了信任与授权问题。

第（四十）篇真正推进的是：

当这些信任条件不再成立时，系统怎样强制停止错误执行，并控制已经产生的现实影响。

这意味着我们已经从：

Trust Decision
↓
Enforced Safety Control
↓
Verified Containment
+
Verified Recovery

一个成熟的 Agent 平台不能只具备快速执行能力。

它必须同时具备：快速阻断风险、准确核对影响、谨慎恢复业务，以及防止相同故障再次传播的能力。

结语：真正可靠的 Autonomous Agent，必须具有“可停止性”

AI Agent 的发展正在持续增加其 Action Surface。

今天，它可以研究、写作、检索、分析数据。明天，它可能能够修改网站、发布内容、管理工具、部署代码、调整配置，甚至协调其他 Agent 共同执行复杂的生产流程。

如果我们只关心执行速度，就会不断扩大 Autonomous Capability。

但如果不能控制风险传播，能力的增加也意味着潜在影响范围的增加。

所以整个系列的治理原则必须再次扩展：

Execute Fast

Stop Faster

Recover Carefully

Learn Permanently

Release Progressively

Reconcile Continuously

Coordinate Explicitly

Identify Cryptographically

Propagate Context Verifiably

Verify Software Before Trust

Verify AI Behavior Before Authority

Continuously Revalidate Autonomy

Contain Before Damage Propagates

Recover Only With Evidence

本篇可以压缩为一条新的生产原则：

An Agent should never possess more authority than the system can safely revoke, contain, and recover from.

也就是：

不要授予一个 Agent 超出系统实际撤销、隔离与恢复能力的生产权限。

再进一步：

Detect Risk
↓
Revoke Authority
↓
Stop Execution
↓
Contain Effects
↓
Reconcile State
↓
Compensate Safely
↓
Prove Recovery
↓
Reauthorize Carefully

至此，我们把第（三十九）篇的 Continuously Assured Autonomous Agent 继续推进成为：

Containable and Recoverable Autonomous System。

这不是让 Agent 更会说“我已经停止了”。

而是让生产系统真正能够证明：

不该继续执行的操作已经被阻断；已经发生的影响已经被识别；能够修复的影响已经完成修复；仍然存在的风险已经被记录；重新授予的权限有新的、充分的证据支持。

这才是生产级 Autonomous Agent 所需要的可控性。

官方依据与工程边界说明

以下资料用于支撑本文的核心工程判断。本文提出的统一架构并非任何单一机构已经发布的行业标准。

1. NIST AI Risk Management Framework — MANAGE

NIST AI RMF 1.0 的 MANAGE 2.4 明确讨论对不符合预期用途的 AI 系统进行取代、脱离运行或停用的机制。MANAGE 4.1 涉及部署后监测、人工覆盖、停用、事故响应和恢复等安排。

官方来源：https://airc.nist.gov/airmf-resources/playbook/manage/

2. NIST SP 800-61 Rev.3 — Incident Response

2025 年 4 月发布的正式版本为 Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile，已取代 Rev.2。它为将事故响应、恢复和组织风险管理连接起来提供了基础。

官方来源：https://csrc.nist.gov/pubs/sp/800/61/r3/final

3. Google SRE — Incident Management / Incident Response

Google SRE 的公开实践强调事故指挥、协调、沟通与控制，以及 Incident Commander、Operations Lead 等角色的明确职责。本文将其思想延伸到 Multi-Agent Incident Command。

官方来源：https://sre.google/workbook/incident-response/

4. Envoy — Circuit Breakers

Envoy Gateway 文档描述了对并发连接、请求和待处理队列的熔断与反压机制。本文借用这一可靠性模式，提出进一步面向 Agent 权限、行为和生产效果的语义熔断机制。

官方来源：https://gateway.envoyproxy.io/latest/tasks/traffic/circuit-breaker/

5. AWS Well-Architected — Bulkhead / Cell-based Architecture

AWS 文档介绍了通过独立 Cell 和故障隔离边界限制影响范围的设计方式。本文将其扩展到站点、租户、Agent、Capability、队列与外部系统之间的隔离。

官方来源：https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html

6. Kubernetes — CronJob

Kubernetes 官方文档明确指出，暂停 CronJob 的后续调度并不会停止已经启动的 Job。本文据此强调 Scheduler Control 与 In-flight Execution Control 的区别。

官方来源：https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

7. Temporal — Saga Pattern / Compensating Actions

Temporal 的工程文档讨论通过 Saga 和补偿操作处理分布式工作流中的外部副作用，以及幂等性、部分执行、取消和补偿失败等问题。

官方来源：https://github.com/temporalio/documentation/blob/main/docs/design-patterns/saga-pattern.mdx

8. WordPress REST API — Posts / Revisions

WordPress 官方 REST API 提供文章创建、更新、状态管理及版本记录接口。本文将这些能力用于 SEO Publisher 的 Effect Reconciliation、Rollback 与恢复验证设计，但不把 WordPress 原生 Revision 机制等同于完整的分布式回滚。

官方来源：https://developer.wordpress.org/rest-api/reference/posts/

9. Google Search Central — Temporarily Pause or Disable a Website

Google 明确提醒，在网站短期停用或限制业务功能时，应考虑索引与搜索可见性影响，通常优先保持站点在线并限制受影响的功能。本文据此强调 SEO Agent 故障不应默认触发全站关闭、全站 noindex 或错误的爬取阻断。

官方来源：https://developers.google.com/search/docs/crawling-indexing/pause-online-business

10. OWASP Top 10 for Agentic Applications 2026

OWASP 于 2025 年 12 月发布面向 2026 年的 Agentic Applications Top 10，提供自治 Agent 相关安全风险与防护的参考。本文将其作为 Agent Tool、权限与自主执行风险的重要背景依据，而不将本文控制架构描述为 OWASP 官方产品规范。

官方来源：https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

本项目原创工程模型

以下概念属于本 SEO / GEO 工作自动化专项在上述标准和实践基础上提出的工程抽象：

AI Runtime Containment Plane、Semantic / Authority-aware Circuit Breaker、Safety Epoch、Execution Fencing、Containment Propagation Graph、Agent Blast Radius Model、Effect + Compensation Contract、Effect Ledger、Containment Receipt、Recovery Receipt、AI Incident Command Hierarchy、Evidence-gated Recovery、Recovery Capability、Containment Escape Rate、以及统一的 Containment–Reconciliation–Recovery Loop。

它们可以作为系统架构设计与实施规范使用，但不能被直接标注为 NIST、OWASP、Google、AWS、Temporal、Envoy 或 Kubernetes 联合制定的正式标准。

第（四十一）篇预告：Recovery Proof / Re-admission / Safe Replay / Evidence-driven Reauthorization

第（四十）篇解决了：系统出现异常时，怎样停止、隔离、补偿和恢复。

但仍有一个更加深入的问题：

即使 Recovery Controller 返回：

Recovery:
SUCCESS

我们凭什么相信这个结果？

尤其当系统经历过 Partial Failure、Unknown Effect、Non-deterministic Agent Decision、Stale Queue、State Divergence 与不同版本的生产配置时，简单的 success 已经不足以证明真正恢复了业务一致性。

因此第（四十一）篇可以继续进入：

Recovery Proof / State Reconciliation / Safe Replay / Deterministic Verification / Effect Equivalence / Recovery Attestation / Re-admission Gate / Evidence-driven Reauthorization / Post-Recovery Assurance

把：

The system
has recovered.

推进到：

Can we prove
that the recovered system
is in an acceptable state,
and that replaying work
will not recreate
the original incident?

最终形成：

Containment
↓
Effect Reconciliation
↓
Recovery Candidate
↓
State Verification
↓
Safe Replay
↓
Recovery Attestation
↓
Re-admission Gate
↓
Limited Reauthorization
↓
Post-Recovery Assurance

也就是从 Containable and Recoverable Autonomous System 继续进入：

Provably Recoverable and Safely Re-admitted Autonomous Agent。