Runtime Assurance Architecture：模型已经验证，为什么生产中的 AI Agent 仍可能越过安全边界？｜SEO / GEO 自动化治理（四十六）

核心主题： Runtime Assurance Architecture / Model–Implementation Conformance / Runtime Monitor Synthesis / Safety Envelope / Shielded Execution / Verified Controller / Fallback Controller / Online Conformance Checking / Continuous Attestation / Assurance Drift / Runtime Recovery

研究日期：2026 年 10 月 23 日

系列定位： SEO / GEO 自动化、AI Agent 生产工程、分布式治理、形式化方法、运行时保证与可信自动化

研究性质： 官方技术资料核验 + 系统工程研究 + 本项目原创 Runtime Assurance 架构与实施规范

---

一家中国出口企业建立了一套 AI 驱动的独立站内容管理系统。

Research Agent 负责信息检索，Writer Agent 负责文章撰写，Fact Check Agent 负责事实核验，Editorial Agent 负责最终审核，Publisher Agent 负责 WordPress 发布。

随着自动化程度提高，系统又增加了 Policy-as-Code、Evidence-bound Authorization、Effect Gateway、Governance Quorum 和 Runtime Containment。

为验证整套流程，工程团队还建立了形式化状态机。

它对以下规则进行了建模：

未经批准的文章不能发布。

实际发布内容必须与批准版本一致。

Containment 期间不能执行普通生产写入。

旧 Safety Epoch 下签发的权限不得继续执行新操作。

同一个业务 Intent 不应产生未经授权的重复 Effect。

经过有限状态检查，模型没有发现违反这些约束的路径。

工程团队认为系统已经具备较强的安全保证。

但正式运行后的某一天，Writer Agent 完成了一篇 B2B 设备采购指南。

文章经过事实核验与终审，并成功获得 Publisher 的发布授权。

随后，一个常规内容清理程序对文章做了少量修改，包括调整产品参数的描述、删除重复段落以及补充内部链接。

与此同时，Publisher Agent 已经取得较早生成的发布请求。

真正调用 WordPress 时，系统出现了一个细小但关键的偏差。

形式化模型要求：

Approved Artifact
=
Published Artifact

而生产实现实际检查的是：

Approval Status
=
APPROVED

它没有在最后一次 WordPress 写入前重新计算正文摘要。

于是，系统正式发布了一份没有经过对应版本审核的内容。

整个过程中：

Policy Engine 返回 ALLOW。

Publisher Agent 没有违反自身指令。

WordPress REST API 正常返回成功。

自动化任务显示 Completed。

模型检查报告也仍然是通过状态。

没有明显的系统崩溃。

但是，生产行为已经偏离了被验证的模型。

问题不是形式化方法没有价值，而是：

模型所验证的行为，与生产系统实际执行的行为，没有形成足够严格的持续约束关系。

这正是第（四十六）篇要解决的核心问题。

第（四十五）篇，我们研究：

怎样系统性寻找状态机与治理规则组合中的危险路径？

第（四十六）篇，进一步研究：

怎样将已验证的安全性质落实到真实执行路径，并持续发现和处置模型与生产之间的偏差？

我们将从 Formally Specified and Runtime-Assured Autonomous System 推进到 Continuously Monitored and Runtime-Enforced Autonomous System。

一、Formal Verification 之后，为什么还需要 Runtime Assurance？

形式化验证通常围绕一个明确的模型进行。

模型可以规定：

PublishAllowed
=
ValidApproval
AND
ArtifactDigestMatched
AND
CurrentSafetyEpoch
AND
ValidResourceAuthority
AND
EvidenceAccepted

模型检查器通过探索指定模型中的状态和转换，分析是否存在违反约束的路径。

但是，真实生产系统运行的是具体软件。

它包含 Cloudflare Worker、WordPress REST API、GitHub Actions、Agent Workflow，以及各种状态存储、队列、网络请求和第三方服务。

这些组件具有模型可能没有完全覆盖的行为。

例如模型假设：

Authorization Check
→
Atomic Publish

但生产中可能发生：

Authorization Check
       ↓
Network Delay
       ↓
Artifact Modified
       ↓
WordPress Publish

也可能：

WordPress Write Succeeded
       ↓
HTTP Response Lost
       ↓
Publisher Retries
       ↓
Duplicate Effect

或者：

Policy Updated
       ↓
Old Worker Still Running
       ↓
Old Authorization Reused

因此，形式化模型中的安全结论，必须通过额外机制约束真实运行。

我们需要回答：

生产系统是否正在执行模型允许的动作？

系统是否仍满足这些动作的执行前提？

一旦发现偏差，是否能够在产生危险效果之前采取有效控制？

Runtime Assurance 就是围绕这些问题建立的运行时保证体系。

二、Runtime Assurance 并不是“多装一个监控系统”

传统监控主要回答：

系统是否正常运行？

CPU、内存和网络是否异常？

API 是否返回错误？

任务是否执行成功？

这些监控重要，但不能自动回答：

当前操作是否仍处于被允许的安全行为范围？

例如：

HTTP Status = 201

只说明某次 WordPress 请求得到成功响应。

它不说明文章获得有效批准、内容与批准版本一致、Publisher 具有对应站点权限、写入符合最新 Safety Epoch。

因此需要区分：

Runtime Assurance 不只是检测，还要将检测连接到控制行为。

Unsafe Action Proposed
          ↓
Runtime Monitor
          ↓
Unsafe Condition Detected
          ↓
Safety Controller
          ↓
Action Blocked

进一步：

Risk Detected
          ↓
Execution Authority Reduced
          ↓
Controlled Fallback
          ↓
Evidence Collected
          ↓
Recovery Evaluation

这里的关键设计思想是：

高级自治控制可以不完全可信，但最终安全边界必须由更可信的机制执行。

三、NASA Runtime Assurance：为什么 Simplex Architecture 值得研究？

NASA 在自主无人航空系统 Runtime Assurance 相关研究中讨论 Simplex 架构。

其中包含两个控制角色。

Advanced Controller（AC） 负责复杂、高性能的控制任务。

Reversionary Controller（RC） 在特定安全条件下接管控制，承担受信的回退职责。

Runtime Monitor 负责监测系统是否接近或违反指定安全性质，并触发必要的控制切换。

此类架构要成立，需要满足重要前提，例如监测足够及时，且回退控制器确实具备可信的安全控制能力。

官方研究：

https://ntrs.nasa.gov/citations/20240007986

对 AI Agent 治理可做概念映射：

Advanced Controller
        ↓
AI Agent Workflow

Runtime Monitor
        ↓
Governance Runtime Monitor

Reversionary Controller
        ↓
Trusted Fallback Controller

但是，NASA 面向航空安全系统的 Runtime Assurance 架构，不等于 WordPress 或 SEO Agent 的安全认证体系。

本项目借鉴控制结构与工程约束思想，不声称获得航空级认证。

四、Simplex 对 AI Agent 最重要的启示

传统 Agent 设计：

Agent Thinks
     ↓
Agent Decides
     ↓
Agent Executes

即使增加 Prompt 和操作规范，最后执行权往往仍集中在 Agent。

更严格的运行时架构：

                  Business Intent
                         ↓
                 AI Agent Controller
                         ↓
                   Proposed Action
                         ↓
                  Runtime Assurance
                         ↓
             ┌───────────┴───────────┐
             ↓                       ↓
         SAFE ACTION             UNSAFE ACTION
             ↓                       ↓
       Effect Gateway         Fallback Controller
             ↓                       ↓
       WordPress Effect        HOLD / RECONCILE

重点不是让 Runtime Monitor 再运行一个大语言模型对原 Agent 进行第二次判断。

而是：

将关键安全约束表达为确定性、可验证、独立于 Agent 意愿的执行条件。

例如 Publisher 认为文章已准备好，最终发布仍须通过：

Approved Digest
=
Current Digest

这不需要大模型重复解释，而需要可信摘要计算、审批记录和不可绕过的执行门禁。

五、Runtime Assurance Architecture 的四个核心组件

1. Advanced Agent Controller

现有 AI Agent 或 Multi-Agent Workflow，负责研究、写作、技术分析、生成 SEO 建议和提出配置修改请求。

可以使用复杂模型、Prompt、工具和知识检索。

但不能单方面判定自身是否满足安全要求。

2. Runtime Assurance Monitor

监测执行状态、授权有效性、Artifact 一致性、策略版本、资源所有权、Safety Epoch、Effect Budget 和关键证据新鲜度。

识别动作是否处于 Safety Envelope 内。

3. Safety / Fallback Controller

当操作不符合安全要求时，执行受限控制。

例如阻断正式发布、禁止修改站点、限制只读、保存已授权内部草稿、启动 Effect Reconciliation、转人工或触发 Containment。

4. Protected Effect Gateway

负责最终外部效果，包括 WordPress 文章创建与修改、Canonical、Redirect、Robots 或 Sitemap 变更。

真正产生高风险 Effect 的路径必须受到可信执行边界约束。

Monitor 发现问题但无法阻止写入，不构成完整的预防性保证。

六、Safety Envelope：Agent 必须处于可定义的安全范围

第（四十五）篇研究 Safety Property。生产系统还必须把这些性质转换为可计算约束。

本项目提出多维度 Safety Envelope：

Safety Envelope
=
Identity Boundary
∩
Authorization Boundary
∩
Artifact Boundary
∩
Evidence Boundary
∩
Runtime State Boundary
∩
Effect Boundary

Identity：执行主体可验证。

Authorization：主体可对指定站点执行指定 Action。

Artifact：实际内容匹配批准版本。

Evidence：关键内容证据符合准入要求。

Runtime State：当前允许写入。

Effect：满足 Effect Budget、资源所有权与防重复要求。

全部强制条件满足：

WITHIN_SAFETY_ENVELOPE

否则：

OUTSIDE_SAFETY_ENVELOPE

Safety Envelope 是本项目的组合性运行时治理模型，不是官方 SEO 标准。

七、Safety Envelope 应按照风险分级

普通草稿与全站 Robots 修改不能使用相同强度的安全边界。

这是项目风险分级建议，不是 Google 或 WordPress 的官方分级。

影响范围越大，Safety Envelope 的条件越严格。

八、Runtime Contract：怎样把形式化模型变成生产规则？

第（四十五）篇使用模型层表达：

[] NoUnauthorizedEffect

Cloudflare Worker 不能直接把该符号表达式当成完整授权逻辑。

需要 Executable Runtime Contract，明确检查项、证据、负责组件、检查时机和失败动作。

contract_id: SEO-PUBLISH-RTA-001
version: 1.0.0

protected_action:
  type: wordpress.publish

requirements:
  identity:
    verified: true
  approval:
    required: true
    digest_match: true
  evidence:
    critical_claims_accepted: true
  runtime:
    current_safety_epoch: required
    containment_inactive: true
  resource:
    authorized_site: required
  effect:
    unique_intent: required
    budget_available: true

failure:
  invalid_approval: HOLD
  missing_evidence: REQUIRE_REVIEW
  stale_epoch: DENY
  uncertain_external_effect: RECONCILE
  policy_unavailable: DENY

provenance:
  formal_property: NoUnauthorizedEffect
  model_ref: SeoPublishing
  governance_review: required

这是项目级 Schema 示例，并非现成的 TLA+ 编译器输出。

把模型约束转成 Runtime Contract，不代表完成形式化等价证明。 仍需要 Conformance Testing。

九、Runtime Monitor Synthesis：能否由模型生成监测器？

从形式化规范生成运行时监测逻辑，是 Runtime Verification 领域的一项研究方向。

需要区分三种性质。

第一类，可直接在执行前计算：

approval_digest == artifact_digest

第二类，需要观察历史状态或事件：

Containment 之后，
旧 Capability 不得再次执行新 Effect。

第三类，涉及未来进展：

每个接受的任务，
最终达到某种终止状态。

第三类通常不能仅凭当前时刻判断最终是否违反，因为：

NOT COMPLETED YET
≠
NEVER COMPLETES

Monitor Synthesis 需要考虑性质类型、可观察事件、时间界限与环境假设。

对 SEO/GEO 自动化，建议优先从前置检查和有界超时性质开始：

PUBLISH requires approved digest match.

Effect remains UNKNOWN beyond threshold
→ ESCALATE

这些更容易真正进入生产系统。

十、Shielded Execution：不让 Agent 的危险动作到达真实系统

Runtime Monitoring 可以发现异常，但若要控制生产效果，就必须建立 Shielded Execution。

Shield 是保护层概念，强调实际执行前约束 Agent 动作。

例如 Writer Agent 请求：

{
  "action": "wordpress.publish",
  "site": "SITE-A",
  "content_id": "ARTICLE-046"
}

系统不能因为请求来自 Writer Agent 就自动认为合法。

Trusted Context Builder 应从受信服务读取：

Workload Identity。

Approval Record。

Artifact Digest。

Policy Version。

Safety Epoch。

Effect Budget。

Resource Authority。

然后形成供 PDP 判断的受信上下文。

如果任一强制条件不满足：

DENY

或进入明确的受限处理流程。

尤其防止：

{
  "approval_valid": true
}

直接被视为可信证据。

Agent 自我声明不能代替独立验证。

十一、Shield 与普通 Prompt 约束的区别

Prompt：

请不要发布未经审核的内容。

Shield：

Approval Digest Mismatch
→
Gateway refuses write

Prompt：

系统进入事故隔离后，请停止操作。

Shield：

Capability Epoch
≠
Current Safety Epoch
→
DENY

Prompt：

不要重复发布文章。

Shield：

Intent already consumed
→
No new publish request
→
Reconcile previous effect

前者依赖模型理解并遵守规则，后者在执行边界强制控制。

但 Shield 也不能解决所有问题，例如仅凭文章摘要不能证明设备参数真实。这仍然需要独立事实证据与核验。

Shield 应执行可明确表达的约束，不能被夸大为替代所有业务判断。

十二、Fallback Controller：安全回退不是立即撤销一切

Simplex 架构启发我们引入可信回退控制器。

但在网站自动化中：

ERROR
→
ROLLBACK EVERYTHING

并不一定安全。

有些 Effect 已被外部系统接受。

例如 WordPress 创建成功，但网络响应丢失。Publisher 无法确定文章是否已存在。

直接重试可能造成重复；直接删除可能误删正确发布的内容。

所以 Fallback 需要按效果状态处理：

Fallback Controller 不一定负责完成业务任务；它首先负责阻止风险扩大，并使系统进入可验证的处置状态。

十三、设计有限的 Runtime Assurance 状态机

建议为 Publishing RTA 定义：

NORMAL
   ↓
RESTRICTED
   ↓
HOLD
   ↓
CONTAINMENT
   ↓
RECONCILIATION
   ↓
RE-ADMISSION
   ↓
NORMAL

这只是示意，不代表生产中必须顺序经过所有状态。

NORMAL：允许符合完整 Policy 和 Safety Envelope 的动作。

RESTRICTED：只允许预定义低风险动作，例如只读分析或特定草稿操作。

HOLD：特定操作暂停，不新增对应外部效果。

CONTAINMENT：撤销或限制受影响主体的生产能力。

RECONCILIATION：核对外部效果与内部 Ledger。

RE-ADMISSION：完成恢复证明和重新授权后，决定是否恢复。

这些状态不能由 Agent 自己自由修改。

特别不能出现：

Agent detects its own risk
→
Agent declares risk resolved
→
Agent restores its own authority

恢复必须遵守 Separation of Duties、Recovery Proof 和 Governance Policy。

十四、Runtime Switching：何时切换到 Fallback？

可以定义运行时决策：

IF
  Safety Envelope violated
OR
  Current authority cannot be verified
OR
  Model–Implementation mismatch detected
OR
  Protected effect enters uncertain state
THEN
  Activate scoped fallback

但要分清：

危险已经发生 与 危险即将发生。

如果 Monitor 在文章发布后才发现 Digest 不匹配，对于“未经对应版本批准不能发布”，监测已太晚。

某些性质必须在 Effect 之前强制检查。

NASA 对 Runtime Assurance 的讨论强调及时监测与可信回退控制器的重要性。

对于 SEO 自动化：

Monitor 必须在不可接受的 Effect 发生前，拥有真正有效的拦截机会。

已发生且不可直接撤销的外部效果，则需 Reconciliation 与 Recovery。

十五、Model–Implementation Conformance：模型和生产怎样持续一致？

第（四十五）篇已经指出模型正确不等于实现正确。

现在建立 Model–Implementation Conformance Registry。

每项高风险性质都应有明确的生产执行责任。

如果：

Formal Property exists

但找不到：

Production Enforcement Point

就存在：

CONFORMANCE GAP

这种差距必须在发布前审核。

十六、Conformance 不能只检查功能是否存在

例如模型要求：

Check Safety Epoch before effect.

生产代码确实有：

checkSafetyEpoch()

但它在：

WordPress POST

之后才运行。

从静态代码搜索看函数存在，系统语义却已被破坏。

因此 Conformance Testing 必须核对：

是否在正确边界执行？

是否使用受信输入？

是否覆盖所有生产路径？

失败时是否真正阻断？

是否有绕过入口？

存在安全检查代码，不等于安全检查控制了真实生产效果。

十七、TOCTOU：为什么最后一次写入前要重新检查？

Time-of-check to Time-of-use 是第（四十三）篇已讨论的问题。

T0:
Article Approved

T1:
Policy Evaluation = ALLOW

T2:
Article Modified

T3:
WordPress Publish

T1 的授权不能无条件复用到 T3。

需要 Pre-effect Verification：

最新 Artifact Digest。

当前 Safety Epoch。

当前资源所有权。

审批有效性。

目标资源版本。

Effect Budget。

但即使执行前重新检查，检查与实际外部 Effect 之间仍可能存在竞态。

需结合事务化状态保留、资源版本检查、Fencing 与最终效果核验。

跨系统尤其要明确：

本地原子事务不能自动覆盖 WordPress 这类外部服务。

十八、Effect Ledger：Runtime Assurance 的事务基础

对于正式发布，建议建立独立 Effect Ledger，每个受保护效果拥有唯一 Intent ID，并记录：

Action
Site
Artifact Digest
Approval ID
Safety Epoch
Resource Version
Effect State
External Post ID

状态设计：

PREPARED
    ↓
RESERVED
    ↓
DISPATCHED
    ↓
OBSERVED
    ↓
VERIFIED

异常分支：

DISPATCHED
    ↓
UNKNOWN
    ↓
RECONCILING
    ↓
VERIFIED / ESCALATED

外部请求超时，不等于外部操作没有发生。

TIMEOUT
≠
SAFE_TO_RETRY_CREATE

应先进入：

EFFECT_UNKNOWN

再对外部状态进行核验。

十九、Cloudflare Queues：为什么重复投递必须进入模型？

Cloudflare Queues 官方文档说明，Queues 默认使用 at-least-once delivery。

这表示消息在某些情况下可能被重复投递。

官方资料：

https://developers.cloudflare.com/queues/reference/delivery-guarantees/

如果 Publishing Worker 简单采用：

Receive Message
→
Create WordPress Post

而没有独立 Idempotency Control，就可能导致重复发布。

可以设计：

Idempotency Key
=
Site ID
+
Intent ID
+
Action Type

但仅有该字段不够，还必须由可信持久化状态和原子保留机制执行。

否则两个并发消费者都可能认为：

Idempotency Key unused

并同时写入 WordPress。

Idempotency 是必须实现并验证的事务语义，不是添加一个字段就自动获得的功能。

二十、Durable Objects 能提供什么，不能提供什么？

Cloudflare Durable Objects 提供实例级的私有、事务性、强一致存储能力。

官方资料：

https://developers.cloudflare.com/durable-objects/best-practices/access-durable-objects-storage/

可用于受保护资源的协调，如：

SITE-A / ARTICLE-046

记录当前 Intent、Effect Reservation、资源代际与状态转换。

但：

Durable Object 内部存储的原子性，不意味着 WordPress 外部写入自动纳入同一事务。

例如：

Durable Object:
RESERVED

WordPress:
POST CREATED

Worker:
CRASHED

内部与外部状态可能不一致。

不能因为 Durable Object 强一致就宣称 WordPress 发布实现了端到端 Exactly-once Effect。

还需要 External Effect Correlation、Post Readback、Revision Validation、Idempotency Reconciliation 与失败恢复。

二十一、真正的生产控制逻辑应该是什么样？

简化 TypeScript 风格伪代码：

async function protectedPublish(request, services) {
  const identity = await services.identity.verify(
    request.workloadToken
  );

  const context = await services.context.buildTrusted({
    identity,
    intentId: request.intentId,
    siteId: request.siteId,
    artifactId: request.artifactId,
  });

  const decision = await services.policy.evaluate(context);

  if (decision.result !== "ALLOW") {
    return services.fallback.handle(decision, context);
  }

  const reservation = await services.ledger.reserveAtomically({
    intentId: context.intentId,
    siteId: context.siteId,
    action: "wordpress.publish",
  });

  if (reservation.status !== "RESERVED") {
    return services.reconciliation.inspect(reservation);
  }

  const freshContext = await services.context.refreshTrusted(context);

  const preEffect = await services.guard.verify({
    original: context,
    current: freshContext,
    reservation,
  });

  if (!preEffect.allowed) {
    await services.ledger.cancelIfNotDispatched(reservation);
    return services.fallback.handle(preEffect, freshContext);
  }

  await services.ledger.markDispatching(reservation);

  try {
    const result = await services.wordpress.publish({
      approvedArtifact: freshContext.approvedArtifact,
      correlationId: reservation.effectId,
    });

    await services.ledger.recordResponse(reservation, result);

    return await services.reconciliation.verifyWordPressEffect({
      reservation,
      expectedArtifact: freshContext.approvedArtifact,
      result,
    });
  } catch (error) {
    await services.ledger.markOutcomeUnknown(reservation);

    return {
      status: "EFFECT_UNKNOWN",
      effectId: reservation.effectId,
      nextAction: "RECONCILE_BEFORE_RETRY",
    };
  }
}

这段代码表达：

Agent 不直接提供可信审批状态。

Policy Decision 在外部 Effect 前。

Effect Reservation 要有真正原子性。

执行前刷新关键状态。

外部结果不确定不盲目重试。

它不是可直接部署的生产程序，仍需处理：

请求认证与防重放、Policy Version、Artifact Canonicalization、并发控制、持久化事务、外部关联、WordPress 回读和可靠审计。

即使执行前检查，也不能消除全部跨系统 TOCTOU 风险。对于需要原子资源版本检查的情况，应在 WordPress 服务端增加对应受控约束。

二十二、WordPress REST API 不是完整的幂等事务系统

WordPress 官方 Posts REST API 支持创建、读取、更新。

POST /wp-json/wp/v2/posts

GET /wp-json/wp/v2/posts/{id}

官方资料：

https://developer.wordpress.org/rest-api/reference/posts/

但不能据此认为，它对自定义 Agent Intent 原生提供完整幂等事务机制。

例如连续两次创建请求，不代表 WordPress 自动将其识别为同一个业务操作。

建议建立受控的 Effect Identity Mapping：

Effect ID
→
WordPress Post ID

再通过受保护服务端实现唯一性约束或受控创建流程。

通过 Slug 查询去重可以作为辅助措施，却不能视为并发和失败条件下严格的 Exactly-once 保证。

二十三、WordPress Readback 是 Runtime Assurance 必要组成

接口返回：

201 Created

只能说明请求被接受。

最终资源可能存在：

Status 与预期不一致。

正文被过滤或修改。

Meta 字段未正确保存。

插件改变了输出。

Canonical 或 Robots 状态不正确。

因此应区分：

Command Success：WordPress 接受请求。

Effect Verification：核验最终外部资源的相关状态。

检查可能包括：

Expected Post ID
Expected Slug
Expected Status
Expected Content Digest
Expected Resource Version
Expected SEO Metadata

真实核验要根据具体字段、权限及插件实现选择可信来源。

WordPress 的 content.raw 与 content.rendered 受上下文、权限和渲染影响。

不能简单认为：

WordPress Content Digest
=
Public HTML Digest

一定成立，因为主题、短代码和插件可能改变最终页面。

核验目标不同，需要比较的 Artifact 与字段也不同。

二十四、GSC 和 GA4 能否作为 Runtime Assurance 的核心证据？

GSC 与 GA4 重要，但主要反映搜索及用户行为。

例如页面是否被发现、索引、获得搜索曝光和点击；用户访问和关键事件如何变化。

它们通常不适合证明某次 WordPress 写入在秒级窗口内是否经过有效授权。

GSC 也不能替代当前 Robots、Canonical 和 HTTP 状态的实时核验。

需要分层：

Runtime Assurance
      ↓
Effect Correctness
      ↓
Technical SEO Monitoring
      ↓
Search Performance Monitoring
      ↓
Business Outcome Analysis

Runtime Assurance 核对写入是否被授权。

Technical SEO Monitoring 核对站点当前索引配置。

GSC Analysis 观察后续抓取与索引。

GA4 Analysis 观察访问与转化。

这些信号互为补充，不应相互冒充。

二十五、OpenTelemetry：Trace ID 能关联事件但不能证明权限

OpenTelemetry Context Propagation 可跨服务传播 Trace Context，帮助关联 Trace、Metrics 和 Logs。

官方资料：

https://opentelemetry.io/docs/concepts/context-propagation/

Research Agent
      ↓
Writer Agent
      ↓
Editorial Gate
      ↓
Policy Decision
      ↓
Publishing Gateway
      ↓
WordPress

上述事件可以共享关联的 Trace Context。

但：

Trace ID 是关联标识，不是授权凭证。

外部请求可能携带不可信追踪上下文。

跨越信任边界时，要注意不可信 Header 和敏感信息泄露。

治理系统应分别维护：

Trace ID
Intent ID
Authorization ID
Decision ID
Effect ID

这些标识可以相互关联，却不能互相替代。

二十六、Runtime Attestation：证明当前控制组件仍然可信

第（三十八）篇讨论 AI Supply Chain，第（四十四）篇讨论 Governance Root of Trust，第（四十五）篇引入 Formal Verification Manifest。

现在需要 Runtime Assurance Attestation。

至少核对：

当前运行的 Worker 版本。

当前 Policy Bundle。

Runtime Contract 版本。

状态机实现对应哪个经过审核的 Commit。

当前 Safety Epoch。

Formal Verification Evidence 是否适用。

runtime_attestation:
  attestation_id: RTA-046-001

  workload:
    service: seo-publisher
    environment: production

  deployment:
    artifact_digest: sha256:<verified-digest>
    source_commit: <approved-commit>

  governance:
    policy_bundle: POLICY-72
    runtime_contract: RTA-CONTRACT-046
    root_version: ROOT-7

  formal_assurance:
    model_id: SEO-PUBLISH-MODEL
    verification_ref: FV-045-001

  runtime:
    safety_epoch: 19
    monitor_status: HEALTHY

  result:
    status: PENDING_VERIFICATION

这是项目 Schema，不是 OPA、GitHub 或 NASA 的统一格式。

不能只检查 Attestation 存在，还应验证签发主体、摘要、可信来源、适用范围、有效期以及实际部署匹配关系。

Attestation 的存在不等于其内容可信。

二十七、SLSA 与 GitHub Artifact Attestations 的作用

SLSA 提供软件供应链安全规范，包含构建来源及 Provenance 相关要求与验证指导。

官方资料：

https://slsa.dev/spec/v1.2/

GitHub Artifact Attestations 可帮助建立构建产物与来源、工作流之间的可验证关系。

官方资料：

https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds

它们可以辅助回答：

生产 Artifact 来自哪里？

由哪个构建流程产生？

是否匹配批准的 Repository / Workflow？

产物完整性是否得到验证？

但：

软件 Provenance 不能单独证明运行中的 Agent 行为安全。

来源可信的 Worker 仍可能有代码逻辑缺陷，导致重复发布。

所以：

Trusted Build Provenance
+
Runtime Contract
+
Policy Enforcement
+
Effect Verification

必须相互连接。

二十八、OPA Policy Bundle 版本一致性也是 Runtime Assurance

OPA 的 Bundle 机制用于分发和更新 Policy 与数据。

Decision Logs、Status 等管理能力可辅助观察决策与部署状态。

官方资料：

https://www.openpolicyagent.org/docs/management-bundles

https://www.openpolicyagent.org/docs/management-decision-logs

https://www.openpolicyagent.org/docs/management-introduction

在分布式部署中，Bundle 更新可能存在传播与激活的时间差。

不能假设：

Policy Repository Updated
=
Every PDP Immediately Runs New Policy

高风险操作应验证：

Required Policy Version
=
Effective Policy Version

或使用明确的兼容策略。

不兼容时：

HOLD / DENY

而非默认 ALLOW。

版本迁移时，还需要明确旧任务和旧审批是否仍然有效，以及新的证据要求如何应用。

二十九、Assurance Drift：何时原来的安全保证会失效？

系统可能逐渐偏离原验证基础：

形式化模型未更新。

Policy Bundle 升级。

Worker 增加发布路径。

WordPress 插件改变内容过滤。

Agent 增加新的 Tool。

Runtime Contract 未覆盖新动作。

Monitor 仍按旧事件格式解析日志。

本项目称之为 Assurance Drift。

它不只是配置不一致，而是：

支持原安全结论的证据、假设或模型，已经不再匹配当前生产实现。

可以定义：

Assurance Validity
=
Model Applicable
AND
Policy Compatible
AND
Runtime Contract Current
AND
Deployment Verified
AND
Monitoring Coverage Sufficient

任一项失效，就不能无条件声称当前版本仍拥有原安全保证。

三十、Assurance Drift 应该如何检测？

建立版本关联：

Model Version
      ↓
Verified Properties
      ↓
Runtime Contract
      ↓
Policy Bundle
      ↓
Worker Artifact
      ↓
Production Effect Gateway

当组件变化时，触发 Impact Analysis。

例如：

Worker Code Changed

就应检查：

是否影响已经验证的状态转换？

是否新增外部 Effect？

是否改变审批验证顺序？

是否增加绕过入口？

如果重大影响存在：

ASSURANCE_REVALIDATION_REQUIRED

而不能继续沿用旧的 FORMAL_VERIFICATION = PASS。

验证结果应具有适用范围，而不是永久有效、与版本无关的生产许可证。

三十一、Runtime Assurance 失败时应如何降级？

不能简单：

Monitor Failure → All Systems Stop

使低风险能力全部不可用。

也不能：

Monitor Failure → Continue Normally

使高风险操作失去保护。

应按照 Action Risk 定义处理。

RECONCILE 并非继续生产操作，而是核对可能已经产生的 Effect。

无法验证安全条件时，应阻断新的高风险写入，不能让故障成为默认放行理由。

三十二、Runtime Recovery：高级 Agent 不得自行解除 Fallback

Publisher 因 Digest 不匹配进入 HOLD。

Writer 后来修复内容，但不能直接得出：

Issue fixed
→
Original approval restored

因为文章 Digest 可能已变化。

正确流程：

Artifact Rebuilt
       ↓
New Digest
       ↓
Required Evidence Revalidation
       ↓
Editorial Approval
       ↓
New Authorization
       ↓
Runtime Assurance Check
       ↓
Re-admission

Containment 情况还须验证新 Safety Epoch 与 Capability。

Effect Unknown 需要先核对外部状态。

Policy Compromise 则需要 Governance Recovery。

Fallback 到正常模式的转换，也是一项需要证据的受保护操作。

三十三、建立 Runtime Assurance Decision Receipt

此前已建立 Policy Decision Receipt、Governance Decision Receipt 和 Formal Verification Manifest。

现在应将其连接。

runtime_assurance_decision:
  id: RAD-046-001

  workflow_id: WF-046-001
  intent_id: INTENT-046-001

  proposed_action:
    type: wordpress.publish
    site: SITE-A
    artifact_digest: sha256:<content-digest>

  policy:
    decision_id: DEC-046-001
    bundle_version: POLICY-72

  formal_assurance:
    model: SEO-PUBLISH-MODEL
    verification_ref: FV-045-001

  runtime:
    contract_version: RTA-CONTRACT-046
    safety_epoch: 19

  checks:
    approval_digest_match: true
    trusted_evidence: true
    resource_authorized: true
    effect_budget_available: true
    runtime_contract_compatible: true

  decision:
    result: ALLOW

  validity:
    one_effect_only: true

此为项目 Schema 示例，不是已上线的实际记录。

关键在于每次生产动作都能回答：

依据哪份模型、哪套 Policy、哪份审批、哪个 Runtime Contract 和哪些当前状态获得执行资格？

三十四、Runtime Assurance Dashboard：什么指标重要？

这些属于本项目建议指标，不是 NASA、OPA 或 Cloudflare 规定的统一 KPI。

特别应关注 Unattributed Production Effect。

它意味着真实世界出现了生产效果，却找不到有效的授权和治理证据。

三十五、Game Day：Runtime Assurance 必须接受故障测试

场景一：审核后文章改变

预期：

Digest Mismatch
→ Pre-effect HOLD

场景二：Policy 决策后进入 Containment

Stale Safety Epoch
→ DENY

场景三：WordPress 创建成功但响应丢失

EFFECT_UNKNOWN
→ RECONCILE

不得直接重复创建。

场景四：Cloudflare Queue 重复投递

Same Intent
→ No unauthorized duplicate effect

场景五：Policy Bundle 不匹配

Policy Version Mismatch
→ HOLD / DENY

场景六：Runtime Monitor 不可用

高风险新写入停止，低风险业务按事先定义的权限策略执行。

场景七：旧 Publisher 绕过 Gateway

发现 Unattributed Effect，并触发权限调查与治理。

场景八：Agent 自行解除 Containment

Unauthorized Re-admission
→ DENY

演练必须在测试环境或可控范围内进行，不能为了测试直接破坏公开生产网站。

三十六、现有 SEO Publisher 怎样分阶段实施？

对于 WordPress、Cloudflare Worker、GitHub Actions 架构，建议分五阶段。

Phase 1：建立最小 Safety Envelope

保护正式发布、已有文章修改和高风险 Technical SEO 配置，统一：

Intent
Artifact
Approval
Evidence
Action
Resource
Safety Epoch

Phase 2：建立不可绕过的 Effect Gateway

Agent 高权限请求统一经过受控入口，不允许普通 Agent 持有可绕过 Gateway 的高权限 WordPress 凭据。

Phase 3：增加 Runtime Contract 和 Fallback

首先实现：

Digest 不匹配拒绝。

旧授权拒绝。

无有效审批拒绝。

Policy 不可用时阻断高风险写入。

外部 Effect 不确定时进入 Reconciliation。

Phase 4：建设持久化 Effect Ledger

选用具备适当一致性与事务能力的存储，建立 Intent Reservation、Effect Identity 和核验机制。

不能依赖 Worker 进程内存或简单 Slug 检查宣称严格幂等。

Phase 5：连接 Formal Assurance 与 Runtime Monitoring

将第（四十五）篇的 Formal Verification Manifest 映射到 Runtime Contract，持续检测模型、Policy、部署和运行偏移。

目标：

Formal Model
      ↓
Approved Runtime Contract
      ↓
Trusted Context
      ↓
Policy Decision
      ↓
Safety Envelope
      ↓
Protected Effect
      ↓
External Verification
      ↓
Assurance Evidence

这是建议实施目标，不表示当前生产仓库已部署全部组件。

三十七、十二条 Runtime Assurance Invariants

Invariant 1

Model Verified
≠
Production Implementation Verified

Invariant 2

Every High-risk Effect
must pass a trusted runtime boundary.

Invariant 3

Agent Assertion
≠
Trusted Runtime Context

Invariant 4

Unsafe Proposed Action
must not become an authorized Effect.

Invariant 5

Approved Artifact
must match Executed Artifact.

Invariant 6

Stale Safety Epoch
→ No New Protected Effect

Invariant 7

Unknown External Effect
→ Reconcile Before Retry

Invariant 8

Runtime Monitor Failure
must not silently authorize high-risk effects.

Invariant 9

Fallback Authority
must remain independently constrained.

Invariant 10

Recovery
requires fresh assurance evidence.

Invariant 11

Formal Assurance
must bind to an applicable
production implementation version.

Invariant 12

Unattributed Production Effect
→ Governance Incident

这些约束共同表达：

运行时安全不能只靠 Agent 的意愿，也不能只靠模型检查报告；必须落实到真实效果的前置控制、过程监测和事后核验。

---

结语：可信的自治系统必须知道何时不能继续自治

过去我们不断提高 Agent 能力，让它研究更多信息、调用更多工具、处理更长工作流、独立完成更多任务。

但自动化能力越强，越需要回答：

执行环境已经偏离安全假设时，Agent 是否还有继续操作的权力？

第（四十五）篇建立了 Formal Methods，提前寻找规则组合和状态转换中的危险路径。

第（四十六）篇进一步指出，即使模型通过验证，真实生产仍可能偏移。

Policy 更新。

代码改变。

外部 API 超时。

旧授权重放。

真实 Effect 与内部记录不一致。

因此系统需要持续运行的约束机制。

不应只问：

AI Agent 想做什么？

还要问：

是否有足够可信的当前证据，证明它仍有资格执行该动作？

如果有，可以在明确范围内继续自治。

如果没有，就拒绝、受限执行、核验外部状态或启动恢复。

自治能力不再是永久授予的权力，而是在持续满足安全条件时才允许使用的生产能力。

完整架构：

Verified Formal Specification
            ↓
Executable Runtime Contract
            ↓
Trusted Runtime Context
            ↓
Safety Envelope
            ↓
Shielded Execution
            ↓
Protected Effect Gateway
            ↓
External Effect Verification
            ↓
Continuous Attestation
            ↓
Assurance Drift Detection
            ↓
Controlled Runtime Recovery

这就是本篇提出的 Runtime Assurance Architecture for SEO/GEO Autonomous Workflows。

它不只是给 Agent 增加 SOP，而是让规则、模型、授权、运行状态与生产效果处于可验证、可强制执行的控制链中。

真正成熟的自治系统，不应以“永远继续执行”为成熟标志。

相反：

它必须能识别何时失去继续自治的充分条件，并在造成新的危险效果之前进入可信的受限状态。

Runtime assurance is not merely observing whether an autonomous system behaves correctly. It is ensuring that unsafe behavior cannot freely cross the production effect boundary.

运行时保证不只是观察自治系统是否正确运行，更重要的是确保危险行为不能不受约束地进入真实生产世界。

从 Formally Specified and Runtime-Assured Autonomous System 进一步进入：

Continuously Monitored and Runtime-Enforced Autonomous System。

---

官方依据与研究边界

1. NASA — Runtime Assurance of Autonomous UAS

NASA 相关研究讨论 Runtime Assurance 和 Simplex Architecture，包括 Advanced Controller、Reversionary Controller、Runtime Monitor 以及监测及时性和可信回退等条件。

https://ntrs.nasa.gov/citations/20240007986

本文借鉴其架构思想，不代表 SEO 自动化获得航空认证。

2. Open Policy Agent

OPA 提供策略决策、Bundles、Decision Logs 等能力。

https://www.openpolicyagent.org/docs/integration

https://www.openpolicyagent.org/docs/management-bundles

https://www.openpolicyagent.org/docs/management-decision-logs

3. Cloudflare Queues — Delivery Guarantees

Queues 默认至少一次投递，消息可能重复；非幂等操作需有独立去重机制。

https://developers.cloudflare.com/queues/reference/delivery-guarantees/

4. Cloudflare Durable Objects — Storage

Durable Objects 提供实例级事务性和强一致存储，不能自动将 WordPress 外部写入纳入同一事务。

https://developers.cloudflare.com/durable-objects/best-practices/access-durable-objects-storage/

5. WordPress REST API

Posts REST API 支持创建、读取、更新和状态管理。

https://developer.wordpress.org/rest-api/reference/posts/

6. OpenTelemetry — Context Propagation

Trace Context 可关联分布式调用，但不等于身份或授权证据。

https://opentelemetry.io/docs/concepts/context-propagation/

7. SLSA — Software Supply Chain Security

软件供应链规范及构建 Provenance 相关要求。

https://slsa.dev/spec/v1.2/

8. GitHub Artifact Attestations

可帮助建立构建产物与来源的可验证关联，使用条件需按产品和权限核对。

https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds

本项目原创工程设计

以下为本项目组合性设计：

• SEO/GEO Runtime Assurance Architecture
• Multi-dimensional Safety Envelope
• Executable Runtime Contract
• Shielded Publishing Gateway
• Runtime Conformance Registry
• Agent Fallback State Machine
• Effect-aware Fallback Controller
• Runtime Assurance Decision Receipt
• Runtime Assurance Attestation
• Assurance Drift Detection
• Formal-to-Runtime Governance Mapping
• Counterexample-driven Runtime Game Day
• Continuously Monitored and Runtime-Enforced Autonomous System

不应表述为 NASA、Google、WordPress、Cloudflare 或 OpenTelemetry 联合发布的 Agent 治理标准。

---

第（四十七）篇预告：Assurance Evidence Plane——怎样验证安全证据本身可信？

本篇将形式化规范推进为运行时控制。

但下一个问题是：

Policy Engine 输出 ALLOW。

Runtime Monitor 输出 SAFE。

Publisher 输出 SUCCESS。

WordPress 返回 201 Created。

这些数据分别存在不同系统时：

如何确认它们对应同一次 Intent？

如何确认批准记录绑定实际发布的 Artifact？

如何发现遗漏、延迟、篡改或重复记录？

如何证明 Effect Ledger 与 WordPress 真实状态一致？

如果治理控制面自身失陷，哪些证据仍能独立验证？

第（四十七）篇建议进入：

Assurance Evidence Plane / Event-Sourced Governance Ledger / Causal Event Graph / Tamper-evident Logging / Evidence Freshness / Evidence Completeness / Cross-System Reconciliation / Audit Integrity / Forensic Replay / Continuous Evidence Verification

架构：

Policy Decision
       ↓
Authorization Evidence
       ↓
Runtime Assurance Decision
       ↓
Effect Command
       ↓
External Effect
       ↓
Observed State
       ↓
Causal Evidence Graph
       ↓
Independent Verification

从 运行时如何阻止危险行为 继续推进到：

凭什么相信系统提供的每一条安全证据？

目标：Evidence-verifiable Autonomous Governance System。