Cross-Agent Accountability：为什么每个 Agent 都通过审核，整个 AI 工作流仍然可能出错？｜SEO / GEO 自动化治理（四十二）

核心主题： Cross-Agent Accountability / End-to-End Verification / Distributed Evaluation / Global Invariants / Causal Responsibility / Evidence Aggregation / Workflow-level Assurance / System-wide Safety Case

研究日期：2026 年 10 月 15 日

系列定位： SEO / GEO / AI Agent 生产工程、数据治理、分布式智能系统与自治安全

研究性质： 官方技术依据 + 多 Agent 系统工程实践 + 本项目原创治理模型

---

假设一家中国工业设备出口企业，已经建立了较为成熟的 AI 内容生产系统。

Research Agent 负责查找产品资料和行业信息。Writer Agent 根据研究结果撰写英文产品文章。Fact Check Agent 检查事实、引用和技术参数。Editorial Agent 审核结构、语言和业务价值。Publisher Agent 将通过审核的内容发布到 WordPress 网站。最后，Monitoring Agent 负责监测 Google Search Console、GA4 和公开页面的运行状态。

整个工作流看起来非常完整。每一个 Agent 都有自己的任务范围、运行日志、评价指标和批准条件。

某次执行结束以后，系统给出的结果是：

Research Agent       PASS
Writer Agent         PASS
Fact Check Agent     PASS
Editorial Agent      PASS
Publisher Agent      PASS
Monitoring Agent     PASS

六个 Agent，六个 PASS。

但客户却发现，新发布的产品文章使用了错误的设备功率参数。

错误参数来自一份过期资料。Research Agent 没有识别资料版本，Writer Agent 正确引用了研究输出，Fact Check Agent 验证了文章与研究资料的一致性，Editorial Agent 认为内容符合写作规范，Publisher Agent 也严格按照批准流程完成了发布。

没有任何一个 Agent 明显违反自己的局部任务要求，整个工作流却产生了错误的业务结果。

更严重的是，如果同一个错误参数被后续 Agent 用于生成采购指南、产品对比表和解决方案页面，错误还可能沿着内容生产链继续传播。

这时，系统究竟应该把事故归因于谁？

Research Agent，因为它没有识别过期资料？Fact Check Agent，因为它没有独立查证？Editorial Agent，因为它批准了文章？Publisher Agent，因为它让错误内容进入了生产环境？还是整个工作流的设计者，因为系统从未规定“产品关键参数必须经过权威数据源验证”这一跨 Agent 约束？

如果最终只能回答“所有 Agent 都执行成功”，那么我们建立的实际上只是一个自动化任务平台，而不是一个真正可验证的自治系统。

第（四十二）篇要解决的核心问题是：局部正确，为什么不能自动推出全局正确？

这也是整个 SEO / GEO Agent 治理系列从单 Agent 可信运行，正式进入多 Agent 系统级验证的关键转折点。

一、第（四十一）篇解决了恢复证明，但恢复对象仍然不够大

前几篇已经建立了一条逐步扩展的治理体系。

第（三十四）篇通过 Resource Ownership、Lease、Lock 和 Authority Graph，讨论多 Agent 如何避免资源争用和执行冲突。

第（三十五）篇通过 Workload Identity、Attestation 与短期凭证，使生产操作能够绑定可验证的工作负载身份。

第（三十六）篇建立了 End-to-End Context Propagation、Causality 和 Intent Binding，要求工具调用与原始任务意图保持关联。

第（三十八）篇进一步验证 Model、Prompt、Tool、Dataset、RAG Corpus 与 AI Supply Chain 的来源和完整性。

第（三十九）篇建立 Continuous Assurance，持续判断 Agent 是否仍然有资格拥有当前自治权限。

第（四十）篇增加 Runtime Containment、Kill Switch、Safety Epoch 与 Recovery，保证系统异常时能够止损。

第（四十一）篇提出 Recovery Proof，要求系统在重新获得生产权限之前，拿出状态核对、安全重放和恢复证明。

这些机制已经相当完整。

但是，它们仍可能遇到一个共同的边界：

每个 Agent 的身份、权限、配置、行为和恢复状态都可以被单独验证，并不代表这些 Agent 组合以后形成的最终业务结果就是正确的。

可以用一个简化表达说明：

Agent A: Locally Valid
Agent B: Locally Valid
Agent C: Locally Valid
Agent D: Locally Valid

But:

End-to-End Workflow: Invalid

为什么？因为多个组件组合以后，可能产生单个组件内部无法观察的错误。

比如数据源之间存在冲突，任务交接丢失了关键限制条件，两个 Agent 使用不同版本的同一产品参数，或者多个评估 Agent 实际上共享同一份错误知识。

这些问题不一定违反某个单独 Agent 的局部规则。它们违反的是整个系统的业务约束。

因此：

Local Assurance does not automatically compose into System-wide Assurance.

局部可信不会自动组合成系统级可信。

这句话，是本篇全部技术架构的起点。

二、首先区分三种不同的“成功”

要理解多 Agent 事故，必须把 Success 拆开。

第一种是 Execution Success。

Agent 是否完成了被分配的步骤？例如 Research Agent 成功返回资料，Writer Agent 成功生成文章，Publisher Agent 成功调用 WordPress REST API。这是执行层成功。

第二种是 Contract Success。

Agent 的输入与输出是否满足既定任务接口、权限和质量标准？例如输出符合 Schema，引用字段齐全，写入目标属于批准的资源范围。这是组件契约层成功。

第三种是 Outcome Success。

所有 Agent 共同产生的最终结果，是否真正满足用户原始目标、业务事实约束和安全要求？例如公开文章使用了正确参数，没有编造认证信息，没有修改无关页面，也没有把未经批准的内容发布出去。这是业务结果层成功。

三者之间存在重要区别：

Execution Success
≠
Contract Success

Contract Success
≠
Outcome Success

举个例子。

Fact Check Agent 收到一篇文章，以及 Research Agent 附带的三条来源记录。

它发现文章中的每个数字都与 Research Agent 的输出一致，于是返回 PASS。

这个检查也许完全符合当前契约。

但是，如果 Research Agent 本身引用的是错误版本的产品说明书，那么所谓 PASS 只是证明：

文章与上游资料一致。

它并没有证明：

上游资料与现实产品事实一致。

这就是典型的局部正确、全局错误。

真正的系统级治理必须明确：每一个 PASS 究竟证明了什么，又没有证明什么。

三、Cross-Agent Accountability：责任不能随着任务交接消失

多个 Agent 协同工作时，经常发生一种现象：

上游 Agent 认为自己只是提供数据。

下游 Agent 认为自己只是使用经过批准的数据。

发布 Agent 认为自己只负责执行发布命令。

于是，所有组件都在完成自己的任务，却没有组件对最终业务结果负责。

本项目将这类问题定义为：

Accountability Gap。

它不一定意味着某个 Agent 主观上“推卸责任”，而是系统在架构层面没有明确规定跨组件的验收责任。

因此，Cross-Agent Accountability 需要回答四个不同的问题。

谁提供了事实？

识别事实或数据第一次进入工作流的来源，以及引入它的 Agent、Tool 和数据版本。

谁改变了事实的表达？

识别是否发生单位换算、摘要、推断、分类、重写或内容扩展。

谁批准了关键判断？

识别哪些检查或人工审批声称支持了最终结果，以及这些审批的实际覆盖范围。

谁产生了外部影响？

识别哪个 Agent 或工具真正执行了发布、更新、删除、部署等生产操作。

但是，这四个问题还不够。系统还必须有一项独立职责：

谁负责验证整个工作流的最终结果符合原始业务目标？

在生产架构中，这个职责不能简单地交给最后一个 Publisher Agent。

Publisher 可以验证写入结果，却未必有能力重新调查所有事实来源。

因此需要建立独立于单一 Agent 的系统级验收机制。

我们可以称它为 Workflow Assurance Authority。

它不是一个拥有无限权限的超级 Agent，而是由确定性策略、证据核验机制、评估服务及必要的人工审批共同组成的治理职责。

四、官方技术依据：分布式追踪已经成熟，但追踪不等于证明

多 Agent 系统首先要解决的是可观察性。

如果一个 Research Agent 的输出经过 Writer、Fact Check 和 Publisher 三次交接，最终变成 WordPress 页面，那么系统必须有办法把这些事件关联起来。

W3C Trace Context 标准定义了 traceparent 和 tracestate 等机制，用于在分布式系统中传播追踪上下文。

OpenTelemetry 则通过 Trace、Span、SpanContext、Parent Span 与 Span Link 等概念描述跨服务操作关系。

这些技术为跨 Agent 执行链提供了重要基础。

参考：

• W3C Trace Context
• OpenTelemetry Specification

OpenAI Agents SDK 的官方文档也已经支持记录 Agent 运行中的模型生成、工具调用、Handoff、Guardrail 与相关事件，并通过 Trace 分析工作流行为。

相关评估资料进一步介绍了如何结合 Trace、数据集和评估机制识别工作流级失败模式。

参考：

• OpenAI Agents SDK — Tracing
• OpenAI — Evaluate Agent Workflows

但这里必须明确一个重要边界：

Trace ID 解决的是执行关联与可观察性问题，不会自动证明业务因果关系，更不会自动证明责任归属。

假设两个 Agent 出现在同一条 Trace 中。这只能说明它们与某次执行有关联，不能仅凭同一 Trace 就认定 Agent A 的输出必然导致了 Agent B 的错误。

还需要证明具体数据依赖、转换关系、版本状态和实际执行路径。

同样，Trace 也不能替代权限验证。攻击者不能因为携带了正确格式的 traceparent，就获得生产写权限。

所以本项目需要继续在分布式追踪之外建立：Cross-Agent Evidence Graph。

五、从 Trace Graph 进入 Evidence Graph

传统 Trace 主要用于回答：

一次请求经过了哪些服务，执行了什么操作，在哪里发生了延迟或错误？

而本项目需要进一步回答：

最终业务结果依赖了哪些事实、判断、授权和外部效果？这些依赖分别有什么证据？

考虑以下工作流：

Original Business Intent
          ↓
Research Agent
          ↓
Research Findings
          ↓
Writer Agent
          ↓
Article Draft
          ↓
Fact Check Agent
          ↓
Verification Result
          ↓
Editorial Agent
          ↓
Approval
          ↓
Publisher Agent
          ↓
WordPress Article

这样的流程图能描述执行顺序，却没有表达出：

Research Findings 使用了哪一个产品文档版本。

Writer 对某个数字是否进行了单位换算。

Fact Check 核验的是文章与研究摘要的一致性，还是与制造商原始参数的一致性。

Editorial 是否知道某个技术结论仍处于 UNKNOWN。

Publisher 接收的文章是否与最后批准的内容完全相同。

因此，Evidence Graph 需要把工作流中的不同实体连接起来：

Business Intent
      ↓
Source Evidence
      ↓
Claim
      ↓
Transformation
      ↓
Verification
      ↓
Approval
      ↓
Authorized Action
      ↓
Production Effect
      ↓
Observed Business State

其中每条连接都应该具有清晰的关系含义。

例如：

• DERIVED_FROM：某个结论来源于某份材料。
• TRANSFORMED_BY：内容经过了某个 Agent 的处理。
• VERIFIED_AGAINST：某个事实与某份证据进行了核验。
• APPROVED_UNDER：某项结果在特定审批范围内通过。
• AUTHORIZED_BY：某次写操作获得了具体授权。
• PRODUCED_EFFECT：某次工具调用产生了外部状态变化。

这些关系名称属于本项目建议的数据模型，并不是 W3C、OpenTelemetry 或 ISO 已经统一规定的 Agent Evidence Graph Schema。

它们的核心价值是：

把“谁参与了任务”推进到“每个关键结果究竟依赖什么”。

六、建立 Claim-level Provenance：错误不能在摘要过程中洗白

对 SEO / GEO 内容工作流来说，最容易传播的错误，往往不是整篇文章，而是其中一个事实主张。

例如：“某设备额定功率为 12 kW。”

这句话可以进入产品页、参数表、采购指南、FAQ、产品对比文章，甚至被后续 RAG 系统重新检索。

如果只追踪文档版本，就可能知道文章来自 Research Agent，却无法识别是哪一条具体事实发生了问题。

因此建议引入：

Claim-level Provenance。

每一个关键事实主张拥有独立身份。

例如：

claim_id: CLM-042-001

subject:
  entity_id: PRODUCT-001
  attribute: rated_power

claim:
  value: 12
  unit: kW

source:
  document_id: SPEC-V3
  document_version: 3
  authority_level: unverified_copy

verification:
  status: UNKNOWN
  verified_against: null

usage:
  - product_article_draft
  - comparison_table

decision:
  production_eligible: false

这是一份说明性的项目 Schema。它不代表某个真实设备的技术参数。

假设系统随后从经过确认的权威产品主数据中发现：

Approved Rated Power:
18 kW

那么系统不应该仅仅把 12 改成 18。

它还需要识别：

哪些文章、表格、内容块或后续生成任务使用了原来的 Claim。

哪些核验曾错误地批准了这个 Claim。

哪些资源可能已经公开发布。

这时，Claim-level Provenance 就和第（三十六）篇的 Causality、第（四十）篇的 Blast Radius、第（四十一）篇的 State Reconciliation 联系起来了。

事实错误不是只存在于某句话里，它还存在于所有继承了这句话的下游结果中。

七、Handoff Contract：任务交接不能只传结果，还要传限制

多 Agent 系统里的 Handoff 经常被设计成：

Agent A Output
        ↓
Agent B Input

这种形式过于简单。

因为 Agent A 的输出可能同时包含：

已经验证的事实、尚未验证的推测、具有时间限制的材料、只允许用于草稿的内部信息、已经被批准的结论，以及不能用于公开发布的敏感内容。

如果在交接时只传递自然语言摘要，这些条件可能逐渐丢失。

例如 Research Agent 写道：“该参数来自第三方网页，尚未找到制造商正式文档，建议在发布前核验。”

Writer Agent 将其整理成：“该设备采用 12 kW 功率配置。”

Fact Check Agent 收到的文章已经不再包含上游的不确定性声明。

经过几次交接，一个 UNKNOWN 就可能变成事实。

因此，本项目建议建立：

Evidence-preserving Handoff Contract。

最小契约应包含：

例如：

handoff_id: HOF-042-001

from: research-agent
to: writer-agent

intent_id: INTENT-042-001

artifact:
  id: RESEARCH-042
  digest: sha256:<artifact-digest>

claims:
  - id: CLM-042-001
    verification: UNKNOWN
    critical: true

constraints:
  publishable: false
  may_be_used_in_draft: true
  independent_verification_required: true

这个契约的重点不是让每次交接变得繁琐，而是防止上游已经明确的限制，在下游自动化中被悄悄删除。

Handoff 传递的不应该只有答案，还应该有答案的适用范围。

同时，下游 Agent 不能把上游 Attestation 视为绝对事实。尤其涉及关键生产数据时，接收方仍须根据自己的职责完成独立验证。

八、Global Invariants：系统级约束不能由局部评分替代

到这里，我们已经能追踪 Agent、资料、Claim 和 Handoff。

但是，追踪并不会自动阻止错误。

必须进一步规定：

无论内部由多少个 Agent 协作，整个工作流都不得违反哪些条件？

这就是 Global Invariants。

Invariant 可以理解为系统必须持续满足的约束。

在多 Agent 场景中，它不能只存在于单个 Agent 的 Prompt 里。

例如：“发布的文章不得包含未经确认的关键产品参数。”

这项规则如果只写在 Fact Check Agent 的指令中，那么当 Fact Check Agent 没有收到足够的来源信息时，就可能无法正确执行。

真正的 Global Invariant 应当由系统级治理机制负责，在关键边界检查它是否成立。

对于 SEO / GEO 自动化，可以建立以下六类约束。

1. Factual Integrity

关键产品参数、价格、认证、交付能力与其他可核验事实，必须具有符合风险等级的权威证据。对于无法确认的事实，不能将其转换成确定性陈述。

2. Intent Integrity

Agent 的行为不得超出原始业务意图和批准的变更范围。例如“新增一篇产品文章”不能被自行扩展为“批量修改所有相关产品页面”。

3. Authority Integrity

每个生产写操作必须具有有效身份、当前授权、正确 Safety Epoch 和适用资源范围。

4. Evidence Integrity

关键结论必须能够追溯至其实际使用的来源、版本和核验结果。

5. Publishing Integrity

被发布的内容必须与批准版本一致，且实际 WordPress 资源、URL、状态和必要 SEO 元数据符合发布契约。

6. Search Infrastructure Integrity

普通文章发布不得擅自修改全站 Robots、Canonical 策略、Redirect 规则、Sitemap 生成机制或其他高影响技术 SEO 配置。

这些不是某个官方平台提供的统一六项 Agent Global Invariants。

它们是本项目根据 SEO/GEO 生产风险设计的系统级约束。

核心原则是：

只要最终结果违反关键 Global Invariant，即使所有 Agent 的局部评估都是 PASS，工作流也不能被判定为整体通过。

九、Global Invariant 应该怎样落实到真正的执行边界？

假设 Workflow Controller 只在发布前询问一个 LLM：

请判断这篇文章是否符合所有安全规则。

这种设计存在明显不足，因为模型本身也可能遗漏事实、忽略范围限制或错误理解业务规则。

因此需要区分两种验证。

Semantic Verification：语义核验。

用于分析文章是否符合主题，结论是否获得来源支持，是否存在不恰当的推断，是否具有原创价值。它可以由模型、规则、检索和人工共同完成。

Deterministic Enforcement：确定性强制执行。

用于检查 Post ID、授权范围、内容 Hash、审批状态、Safety Epoch、是否允许修改特定资源等客观规则。

这些规则应在实际 Tool Gateway 或 Effect Boundary 上强制验证。

例如：

def allow_publish(workflow, article, authority):
    if workflow.intent_status != "APPROVED":
        return "DENY_INTENT"

    if authority.safety_epoch != workflow.current_epoch:
        return "DENY_STALE_AUTHORITY"

    if article.approved_digest != article.current_digest:
        return "DENY_CONTENT_CHANGED"

    if article.critical_claims_unverified > 0:
        return "REQUIRE_FACT_REVIEW"

    if not authority.can_publish(article.site_id):
        return "DENY_RESOURCE_SCOPE"

    if workflow.global_invariant_state != "PASS":
        return "DENY_WORKFLOW_ASSURANCE"

    return "ALLOW"

这是用于解释架构的伪代码，并非可以不经修改直接部署的生产授权程序。

这里还要强调：critical_claims_unverified 与 global_invariant_state 不能由正在请求发布的 Agent 自行填写并被无条件信任。

它们必须来自受控评估、独立证据和具有适当权限的审批记录。

否则系统只是把 Prompt 中的自我声明，换成了 JSON 字段中的自我声明。

十、Distributed Evaluation：不能再把 Agent 的 PASS 简单相加

多 Agent 评估最常见的错误之一，就是把局部评分聚合成系统总分。

例如：

然后系统计算平均分：

Average Agent Score:
95.2

这里的数字只是一个假设性示例，并不代表实际评估结果。

问题在于，这五个评分可能测量的是完全不同的东西。

Research 得分高，可能代表检索任务完成率高。Writer 得分高，可能代表语言质量好。Fact Check 得分高，可能代表引用格式完整。Publisher 得分高，可能代表 API 发布成功率高。

这些评分没有共同的测量对象，因此不能简单平均以后当成全局事实准确率或生产安全概率。

更不能把几个未经校准的 Agent 置信度相乘，声称得出了系统整体可靠性。

因为多个 Agent 之间可能高度相关。

例如 Research 和 Fact Check 使用同一个搜索结果集、同一个模型版本、同一个 RAG Corpus。

当上游来源错误时，它们可能一起犯错。

这叫作 Common-mode Failure，或共同原因失效。

它是多 Agent 系统非常重要的风险来源。

多个 Agent 并不天然意味着多个独立判断。

十一、建立四层 Evaluation Architecture

为了避免局部高分掩盖全局错误，本项目建议建立四层评估结构。

L1：Component Evaluation。 检查单个 Agent 是否完成自己的规定任务。例如 Writer 是否生成完整文章，Publisher 是否正确使用 WordPress API。

L2：Handoff Evaluation。 检查跨 Agent 交接是否保留了必要事实、来源、版本、限制与未解决问题。例如 Research 输出的 UNKNOWN 是否被传递到 Fact Check。

L3：Workflow Evaluation。 检查一次完整执行是否满足原始业务意图和 Global Invariants。例如最终文章是否具有足够的事实证据、是否发布到批准 URL、是否发生越权修改。

L4：Production Outcome Evaluation。 检查实际外部结果及后续影响。例如 WordPress 是否真正保存了批准版本、前台页面是否可访问、是否产生重复页面、监测数据是否出现需要调查的变化。

四层之间的关系是：

L1 Component
       ↓
L2 Handoff
       ↓
L3 Workflow
       ↓
L4 Production Outcome

但这不是一个只要逐层 PASS 就自动保证无风险的数学证明体系。不同层的证据仍可能缺失、过期或存在相关性。

因此应该建立明确的跨层验收逻辑。

OpenAI 官方关于 Agent Workflow Evaluation 的资料，已经介绍了利用 Trace、Grader、Dataset 与评估运行识别工作流问题，包括工具选择、Handoff 和安全策略违反等情况。

本项目在此基础上进一步提出四层系统级评估结构。这是工程扩展，不是 OpenAI 官方定义的 L1–L4 标准。

十二、独立评估不等于换一个 Agent 再问一遍

许多团队为了提高可靠性，会让第二个 Agent 审核第一个 Agent。

这可能有帮助，但不能直接等同于独立核验。

假设 Research Agent 根据某个错误的第三方产品页面，得出一项技术结论。

Fact Check Agent 又使用同一个页面核验。

两个 Agent 得出一致结论。

系统可能认为：“已有双重验证。”

但实际上：它们只是对同一份资料进行了两次处理。

这种重复并没有增加来源层面的独立性。

因此，Distributed Evaluation 必须至少评估三个维度。

第一，Evaluator Independence。评估 Agent 是否与被评估 Agent 共享可能导致同类错误的模型、Prompt、资料或推断路径？

第二，Evidence Independence。评估所使用的证据，是否真正独立于被审核内容的来源？

第三，Authority Independence。评估主体是否能够独立拒绝执行，而不是受到被审核 Agent 的控制？

对于关键产品参数，最理想的核验路径可能不是“第二个模型再搜索一次”，而是将内容与经过确认的产品 Source of Truth 进行结构化对照。

对于事实不完整的情形，则应保留 UNKNOWN 或交由具备业务知识的人确认。

这也回应了此前数据治理系列的一个核心原则：

Source of Truth 不应该因为 Agent 数量增加而变成多个相互冲突的版本。

十三、Causal Responsibility：能追溯执行路径，不等于已经证明因果责任

现在进入本篇最容易产生误解的概念：

Causal Responsibility。

它至少需要区分三个层次。

第一层：Execution Attribution

谁执行了什么？

例如 Research Agent 调用了哪个检索工具，Writer Agent 引用了哪些 Claim，Publisher Agent 发出了哪个 WordPress API 请求。

这些事实可以通过 Trace、日志、工具回执和资源版本进行核验。

第二层：Causal Contribution

某个上游事实或行为，如何参与形成最终结果？

例如错误参数进入研究摘要，研究摘要进入文章草稿，错误参数被保留并最终发布。

这条数据依赖链可以说明某个错误的传播路径。

但如果还要证明：“如果 Research Agent 当时使用了正确数据，最终错误就一定不会发生”，则需要更加谨慎。

因为 Writer 可能还有其他错误来源；Fact Check 可能存在独立缺陷；Publisher 也可能发布了错误版本。

仅凭事件先后和同一 Trace，无法完整回答所有反事实问题。

第三层：Organizational Accountability

谁对系统设计、验证要求和生产批准承担实际责任？

例如，如果 Fact Check Agent 的契约从来没有规定“必须与权威产品主数据核对”，那么事故不能简单归咎于模型没有执行一项不存在的任务要求。

系统设计者、业务数据负责人、内容审核责任人和发布权限批准人，都可能承担不同层面的治理职责。

因此：

Execution Attribution
≠
Causal Proof

Causal Contribution
≠
Organizational Accountability

本项目建议将三者分别记录。

不要把“谁的 Span 最接近错误发生时间”误当成责任结论。

十四、建立 Causal Evidence Record，而不是自动生成“责任排行榜”

假设前面提到的错误功率参数已经进入网站。

系统可以生成如下调查记录：

incident_id: INC-042-001

observed_failure:
  type: incorrect_product_specification
  affected_claim: CLM-042-001
  production_status: confirmed

execution_evidence:
  research_source: SPEC-V3
  writer_claim_ref: CLM-042-001
  factcheck_result: PASS
  publisher_receipt: POST-128

identified_control_gaps:
  - no_authoritative_version_check
  - no_independent_critical_claim_verification
  - uncertainty_not_propagated

causal_assessment:
  status: PARTIALLY_SUPPORTED
  requires_human_review: true

accountability:
  owner: workflow-governance-owner
  action: corrective_action_required

这是一份假设性示例，不代表发生过真实事故。

它区分了：已经观察到的错误、能够证明的执行路径、存在证据支持的控制缺陷、尚需进一步分析的因果关系，以及负责推动整改的治理责任人。

这种结构比“AI 自动判断 Research Agent 承担 70% 责任”更加可靠。

因为如果缺少清晰的因果识别方法和可验证依据，任何百分比责任分配都可能制造新的误导。

Causal Responsibility 首先是一套有证据边界的事故分析机制，而不是一套自动追责评分算法。

十五、System-wide Safety Case：整个工作流应该怎样证明自己可信？

前面我们已经分别建立：AI Decision Receipt、Evaluation Attestation、Containment Receipt、Recovery Attestation。

但这些证明通常绑定某一个决策、某个配置或某次事故。

现在需要更高层的结构：

System-wide Safety Case。

ISO/IEC/IEEE 15026-2:2022 为 Assurance Case 的结构和术语提供了正式标准依据。

该标准规范的是 Assurance Case 的结构与含义，并不自动保证其中的证据质量，也不指定某种 Agent 安全架构。

因此，我们可以借鉴 Assurance Case 的主张、论证与证据组织思想，形成多 Agent 系统级安全论证。

参考：ISO/IEC/IEEE 15026-2:2022 — Assurance Case

对于 SEO / GEO 自动发布系统，顶层 Claim 可以设为：

在当前批准的配置、权限与业务范围内，系统能够将经过充分核验的内容发布到指定网站，同时将未验证事实、越权写入和异常生产效果控制在已批准的风险边界内。

这项主张不能只由 Publisher Agent 的 PASS 支持。

它需要被进一步拆解：

TOP-LEVEL CLAIM
The workflow is acceptable for
approved autonomous publishing.
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
   Content     Authority   Production
   Assurance   Assurance   Assurance
        │         │         │
        ▼         ▼         ▼
   Fact/Source  Identity    Effect
   Evidence     Evidence    Evidence
        │         │         │
        └─────────┼─────────┘
                  ▼
          Global Invariants
                  │
                  ▼
        System-wide Decision

其中至少应包括：

Content Assurance Claim。 关键事实与内容质量符合发布条件。

Authority Assurance Claim。 所有生产操作都具有匹配的身份、授权和原始业务意图。

Handoff Assurance Claim。 跨 Agent 传递的限制和关键证据没有被无意丢失。

Effect Assurance Claim。 最终外部效果与批准的业务目标一致。

Recovery Assurance Claim。 系统发生故障以后，可以限制影响，并在证据支持下恢复。

这些 Claim 不是简单的勾选项目。每一个都必须关联实际证据。

十六、Evidence Aggregation：证据聚合不是把所有 PASS 收集到一张表

现在我们已经拥有多个 Agent 的 Evaluation Receipt。

但系统级证据聚合仍然需要解决三个问题。

首先，证据是否覆盖正确的对象？

例如一份针对旧 Prompt 的 Evaluation，不应该被用于证明新的 Prompt 已经安全。

针对 Article A 的核验，也不能自动用于 Article B。

其次，证据是否仍然有效？

如果工具定义、数据源、模型版本、发布策略或授权环境发生关键变更，过去的证据可能需要重新评估。

最后，证据之间是否互相依赖或冲突？

Research 和 Fact Check 如果依赖同一个错误来源，两份 PASS 不应该被算作两份独立事实证明。

因此，Evidence Aggregation 不应采取：

5 PASS
+
5 PASS
=
10 Units of Trust

而应该采取：

Evidence
  ↓
Scope Matching
  ↓
Freshness Check
  ↓
Provenance Check
  ↓
Dependency Analysis
  ↓
Conflict Detection
  ↓
Claim Coverage
  ↓
Assurance Decision

本项目建议对每一项关键证据保留以下状态：

SUPPORTED
PARTIALLY_SUPPORTED
CONTRADICTED
UNKNOWN
STALE
NOT_APPLICABLE

这里尤其需要避免将 UNKNOWN 转换成 PASS。

但同时也要避免所有未知事项一律阻断全部业务。

例如，某篇草稿的非关键背景资料尚待确认，可以继续内部编辑。某个公开产品页的核心额定参数没有得到核实，则不应该进入自动发布。

Evidence Aggregation 的目标不是追求证据数量，而是判断证据是否真正支持对应的业务主张。

十七、Global Assurance Decision：全局放行应该有明确规则

最终，Workflow Assurance Authority 需要输出一个有明确含义的决策。

建议采用：

PASS

PASS_WITH_CONDITIONS

REQUIRE_REVIEW

FAIL

INSUFFICIENT_EVIDENCE

五种状态可以分别对应不同操作范围。

这里需要建立一条硬性规则：

关键 Global Invariant 的 FAIL，不允许被其他 Agent 的高分抵消。

例如：

文章事实准确性评分很高，但缺少发布权限。不能因为内容质量好，就绕过授权。

发布权限完全有效，但文章包含已确认错误的关键产品参数。不能因为权限合规，就批准文章上线。

所有局部模型的语言质量评分都是优秀，但最终执行打算修改未经批准的 robots.txt。也必须拒绝。

安全关键约束应该具有否决能力，而不是成为可被平均分稀释的普通评分项。

十八、完整 SEO / GEO 案例：六个 Agent 全部 PASS，系统级 Gate 为什么仍然拒绝？

我们把前面的概念组合成一个完整案例。

假设某工业设备出口企业准备发布英文文章：

*How to Choose Industrial Equipment for Overseas Projects*

原始 Intent 是：为海外采购人员提供一篇专业指南，解释设备选型、运行条件、技术参数、运输与售后等关键事项。

同时要求：关键产品参数必须来自最新批准的产品主数据。涉及认证、功率、承载能力与技术限制时，不允许推测。文章正式发布前必须经过人工终审。

第一阶段：Research Agent

Research Agent 查找到一份旧的 PDF 说明书，并提取出：

Rated Power:
12 kW

它成功生成研究摘要。

局部状态：

Research:
PASS

但 Evidence Graph 记录：

Claim:
CLM-042-001

Source:
SPEC-V3

Verification:
UNKNOWN

注意，这里存在一个关键差别。

研究摘要生成成功，并不意味着产品参数已经得到权威确认。

第二阶段：Writer Agent

Writer Agent 根据研究摘要生成完整文章。

语言专业，结构清晰，并且符合采购人员的阅读需求。

它把 12 kW 写入了技术参数说明。

局部状态：

Writing:
PASS

但是在 Handoff 中，文章继续保留了：

CLM-042-001:
UNKNOWN

第三阶段：Fact Check Agent

Fact Check Agent 检查发现：文章中的数字与 Research 摘要一致。引用链接可打开。语言没有明显逻辑矛盾。

如果它只执行局部一致性检查，可能返回：

Local Fact Check:
PASS

但此时 System-wide Evaluation 发现：核心产品参数仍没有与权威产品主数据核对。

于是，全局事实完整性检查输出：

Global Factual Integrity:
INSUFFICIENT_EVIDENCE

第四阶段：Editorial Agent

Editorial Agent 判断文章结构、信息密度与读者价值达到要求。

输出：

Editorial Quality:
PASS

但它的 PASS 只适用于编辑质量，不能覆盖事实完整性方面的缺口。

第五阶段：Publisher Agent

Publisher Agent 准备将文章发送到 WordPress。

它检查自身身份、Capability、目标站点和 WordPress 操作范围。

局部发布权限：

Publishing Authority:
PASS

但是在最后的 Global Assurance Gate：

Critical Claim:
UNVERIFIED

Global Invariant:
FAILED

Decision:
DENY_AUTONOMOUS_PUBLISH

整个工作流最终返回：

Workflow Status:
REQUIRE_REVIEW

Allowed:
SAVE_DRAFT

Denied:
PUBLISH

这不是系统故障。

恰恰相反：这说明系统级治理正在正确发挥作用。

它没有因为 Writer 写得好、Editor 认为可读、Publisher 具备权限，就让一个仍然缺少关键证据的产品参数进入公开网站。

第六阶段：引入权威 Source of Truth

人工产品负责人核对最新版技术资料，发现批准参数为 18 kW。

注意，这里的 12 kW 和 18 kW 只是本案例假设数字，并非真实设备数据。

系统随后更新 Claim，并识别所有引用旧 Claim 的下游 Artifact。

Writer 修改正文。Fact Check 独立验证新参数。Editorial 审查修改后的文章。系统重新计算 Global Assurance。

最终，在完整内容获得正式批准后，Publisher 才允许执行生产写入。

第七阶段：发布后验证

WordPress 返回创建成功，并不意味着所有环节已经完成。

系统仍需要验证：目标文章是否发布成功，正文是否匹配批准版本，关键参数是否仍然正确，公开页面是否正常访问，相关 Canonical、Indexability 和其他适用技术 SEO 设置是否符合预期。

只有这些关键的生产效果得到验证，Workflow 才能进入最终完成状态。

这个案例展示了第（四十二）篇最重要的变化：

Agent 的局部 PASS 是证据，而不是最终结论。

十九、为什么这套机制直接关系到 SEO 与 GEO？

对于 SEO/GEO 自动化，多 Agent 失误可能带来的问题并不只是文章质量下降。

它还可能形成规模化传播。

例如同一个错误产品参数，被自动复用到 20 篇采购指南和 30 个产品比较页面。

每一次 Writer 执行都符合自己的 Prompt。每一次 Publisher 执行都拥有有效权限。但是网站最终形成了一组具有共同事实缺陷的内容资产。

这可能影响用户理解、采购判断以及网站内容可信度。

Google Search Central 官方内容指导强调，网站应当提供有帮助、可靠、面向用户的信息，并关注原创价值、事实准确性与内容的实际用途。

其 Spam Policies 同时明确指出，主要为了操纵搜索排名而大规模生成、缺乏用户价值的内容，可能构成 Scaled Content Abuse；这一判断并不只取决于内容是否由 AI 创建。

参考：

• Google Search Central — Creating Helpful, Reliable, People-First Content
• Google Search Central — Spam Policies

需要明确：

Google 并没有因此发布一套专门用于 SEO 内容 Agent 的 Cross-Agent Accountability 标准。

本文提出的 Global Invariants 与 System-wide Safety Case，也不是 Google 排名算法的一部分。

它们属于企业为提高事实质量、降低生产风险、确保内容具有真实业务价值而建立的工程控制。

对于 GEO，也不能把它们描述成一种可以直接提高 AI 引用次数的秘密技术。

但它们能够帮助企业更可靠地维护：产品实体一致性、事实来源、知识库质量、内容版本和公开资料的可核验性。

这些能力可能为后续 AI Search 的检索、理解与引用提供更好的信息基础。

至于具体平台是否引用、如何排序和最终产生多少流量，仍然需要独立监测，不能预先保证。

二十、系统恢复也必须升级：单个 Agent 恢复成功，不代表整个工作流恢复成功

第（四十一）篇已经建立 Recovery Proof。

现在需要将其扩展到多 Agent 工作流。

考虑前面错误参数的案例。

Research Agent 已经修复。Writer Agent 已经重新生成文章。Fact Check Agent 已经更新验证逻辑。Publisher Agent 已经恢复生产访问。

是不是意味着系统恢复成功？

仍然不一定。

因为旧队列中可能还存在未处理的文章生成任务。

RAG Corpus 可能仍然保存旧参数。

已经发布的其他内容可能还在使用旧 Claim。

某个下游 Agent 的缓存可能仍然保留旧研究摘要。

因此，本项目需要进一步建立：

Multi-Agent Recovery Verification。

Agent-level Recovery Proof
          ↓
Handoff State Reconciliation
          ↓
Shared Data Reconciliation
          ↓
Cross-Agent Replay Validation
          ↓
Global Invariant Evaluation
          ↓
Production Effect Verification
          ↓
Workflow-level Re-admission

它要求恢复验证不仅覆盖各 Agent 本身，还覆盖 Agent 之间传递的共享状态。

尤其需要核对：旧的 Claim 是否仍然可被检索，旧的任务是否会重新消费，旧的授权是否可能继续生效，旧的内容是否仍然保留在公开页面。

如果这些问题没有处理，系统可能在恢复以后重新制造原来的事故。

单个 Agent 的 Recovery Attestation，不能自动代替整个系统的 Recovery Proof。

二十一、建立 System-wide Assurance Manifest

为了让架构能够落地，本项目建议为每次高风险工作流执行生成一份 System-wide Assurance Manifest。

示例如下：

schema_version: project-assurance-v1

workflow:
  id: WF-042-001
  type: seo-content-publishing
  intent_id: INTENT-042-001

scope:
  tenant_id: TENANT-001
  site_id: SITE-001
  action: publish_post

agents:
  - research-agent
  - writer-agent
  - factcheck-agent
  - editorial-agent
  - publisher-agent

global_invariants:
  factual_integrity: PASS
  intent_integrity: PASS
  authority_integrity: PASS
  evidence_integrity: PASS
  publishing_integrity: PASS
  seo_infrastructure_integrity: PASS

evidence:
  claim_coverage: COMPLETE
  critical_conflicts: 0
  unresolved_critical_claims: 0
  handoff_receipts: VERIFIED
  approval_record: PRESENT

production:
  approved_artifact_digest: sha256:<digest>
  publish_capability: VALID
  current_safety_epoch: 42

decision:
  state: APPROVED_FOR_SCOPED_PUBLISH
  effect_scope: SINGLE_POST

post_publish:
  required: true
  verification_state: PENDING

需要注意，这个例子中的 APPROVED_FOR_SCOPED_PUBLISH 只代表可以执行指定发布动作，并不代表发布后的业务效果已经验证完成。

只有完成后续回读与生产效果核验，系统才能把 Workflow 标记为最终完成。

这种分离非常重要。

因为：

Approved to Publish
≠
Successfully Published

Successfully Published
≠
Verified Business Outcome

因此，建议整个工作流至少具有以下状态：

CREATED
    ↓
IN_PROGRESS
    ↓
READY_FOR_ASSURANCE
    ↓
ASSURANCE_APPROVED
    ↓
EFFECT_EXECUTING
    ↓
EFFECT_RECONCILIATION
    ↓
VERIFIED_COMPLETED

同时允许转入：

REQUIRE_REVIEW
FAILED
QUARANTINED
RECOVERY_REQUIRED

不应该只有 running / success / failed 三种过于粗糙的结果。

二十二、让事故治理进入 Game Day：必须测试跨 Agent 的真实失败模式

一个多 Agent 系统即使在正常样本上表现优秀，也不能证明它能处理异常交接与共同原因失效。

因此，需要把第（四十）篇的 Game Day 扩展到系统级。

建议优先测试六类场景。

场景一：错误来源被多个 Agent 一致接受。

让 Research 与 Fact Check 接收到同一个过期资料，检查系统是否还能通过独立 Source of Truth 发现冲突。

场景二：Handoff 丢失 UNKNOWN。

在 Research 到 Writer 的交接中模拟不确定性字段缺失，检查下游是否拒绝将未经确认的 Claim 当作正式事实。

场景三：局部 PASS 与全局 FAIL 冲突。

所有组件质量评分均通过，但存在一项关键 Global Invariant 违规，检查最终 Gate 是否拒绝生产写入。

场景四：审批以后 Artifact 被修改。

编辑批准了版本 A，Publisher 实际收到版本 B，检查批准 Hash 与最终内容 Hash 不一致时，系统能否拒绝发布。

场景五：局部恢复，但共享知识库尚未恢复。

多个 Agent 已经恢复运行，RAG Corpus 却仍然包含旧事实，检查 Workflow-level Re-admission 是否识别残余风险。

场景六：错误责任被错误归因。

模拟某个 Agent 只是传递了错误输入，但上游验证契约本身缺失，检查事故调查是否能够把执行事实、数据传播路径和治理责任分开处理。

每一项测试都应保留：实际输入、配置版本、期望行为、观察结果、相关证据和失败原因。

Game Day 的价值不只是验证系统能否拒绝错误操作。

还在于验证：发生错误以后，我们能否知道控制链究竟在哪里失效。

二十三、如何分阶段在真实 SEO/GEO 项目中实施？

完整的 System-wide Assurance 平台并不适合一开始就构建成一个庞大的治理产品。

对于正在使用 WordPress、GitHub、Cloudflare Worker 和 GSC/GA4 的 SEO 自动化项目，可以采用逐步实施路径。

第一阶段：先建立单一内容 ID 与全链路 Trace

为每个内容任务生成稳定的 Content ID、Intent ID 和 Workflow ID。

把研究、草稿、审核、发布和效果核验关联到同一业务任务。

最基本的目标是：不能出现文章已经发布，却无法判断它属于哪次任务、使用了哪份研究资料、经过了哪个审批版本的情况。

第二阶段：建立关键 Claim Registry

优先管理高风险事实，而不是给每句话都建立复杂数据模型。

例如产品功率、尺寸、容量、材料、价格、交货周期、认证声明和重要商务条件。

每个关键 Claim 关联权威来源、版本、核验状态和使用位置。

第三阶段：建立 Handoff Contract

要求 Research、Writer 和 Fact Check 传递关键事实引用与未解决问题。

不允许在没有新证据的情况下，将 UNKNOWN 自动升级为 VERIFIED。

第四阶段：建立 Global Publishing Gate

在 WordPress 正式发布前，检查：

内容是否经过批准。Artifact 是否匹配批准版本。关键事实是否通过核验。发布操作是否属于原始 Intent。生产写权限是否仍然有效。是否存在未解决的关键风险。

第五阶段：引入 Workflow-level Evaluation

逐步把局部质量评估扩展到完整的研究—写作—审核—发布链路。

针对共同来源错误、交接字段丢失、版本冲突和生产效果不一致建立专门测试。

第六阶段：建立 System-wide Safety Case

将关键业务主张、控制机制、评估证据和剩余风险统一组织起来。

高风险权限或重大变更时，重新核对证据是否仍然适用。

这样做的最终目标不是让每篇文章都产生一份繁琐的合规报告。

而是让生产系统在需要时能够回答：

为什么这篇文章有资格被自动发布？

以及：

一旦发生错误，我们能否准确识别来源、控制影响并完成可靠恢复？

二十四、系统级治理应该监测什么？

传统 Agent Dashboard 经常展示：任务完成数、Token 消耗、平均延迟、Agent Success Rate。

这些指标对于成本和运行管理有用，但不足以证明系统级安全。

本项目建议增加以下指标。

这些都是项目建议指标，不是已经统一发布的行业标准。

实施时必须明确分母、采样范围、数据质量、统计周期与例外条件。

其中最值得重视的两个指标是：

Local-pass / Global-fail Rate。 它能够暴露局部评估体系与最终业务要求之间的缺口。

以及：

Critical Claim Evidence Coverage。 它能够帮助企业判断关键事实是否真正获得了足够的来源支持。

但是，也不能把这两个指标简单当成越高或越低越好的排名分数。

例如，系统刚刚引入严格 Global Gate 时，可能发现大量过去未被识别的局部通过、全局失败案例。

短期内 Local-pass / Global-fail Rate 上升，未必意味着系统突然变差，也可能代表检测能力提高。

因此必须结合覆盖范围与评估制度变化解释趋势。

二十五、System-wide Assurance 的边界：更多控制，不等于绝对正确

到这里，还需要避免三个过度承诺。

第一，不能声称建立 Evidence Graph 以后，就能自动证明所有复杂业务结果的因果关系。

Trace、Data Lineage 和 Artifact Provenance 能够提供重要证据，但复杂因果问题仍可能需要进一步调查、对照测试及人工判断。

第二，不能声称 Global Invariants 可以覆盖所有可能出现的错误。

很多业务风险来自尚未识别的失败模式。因此 Global Invariants 需要与 Continuous Evaluation、Incident Review 和 Red Team Testing 持续迭代。

第三，不能认为拥有 System-wide Safety Case 就等于获得外部监管认证。

Assurance Case 的结构可以组织主张、论证和证据，但它本身不自动证明系统满足某项法律、法规或行业认证要求。

NIST AI RMF Playbook 明确属于自愿性的风险管理指导，其 Govern、Map、Measure 和 Manage 机制需要按照使用场景选择与实施。

OWASP Top 10 for Agentic Applications 2026 也为自治 Agent 的安全风险提供了参考，但并没有直接定义本文提出的全部工程模型。

因此，本篇的定位必须明确：

这是面向 SEO/GEO 多 Agent 生产系统的可验证治理架构，而不是某个官方机构已经发布的完整行业标准。

---

结语：真正的可信，不是所有 Agent 都说自己正确

回到文章开头的故事。

六个 Agent。六个 PASS。一篇错误的产品文章。

问题不在于 Agent 数量不够多，也不一定在于我们需要再增加第七个审核 Agent。

真正的问题是：

我们把每一个局部任务的完成，误当成整个业务目标的实现。

一个 Agent 可以正确执行错误的任务。

一个 Writer 可以准确表达错误的资料。

一个 Fact Checker 可以正确验证不完整的证据。

一个 Publisher 可以合法发布不合格的内容。

一个 Monitoring Agent 可以准确记录错误页面的访问数据。

如果系统没有全局业务约束，所有局部成功都无法自动阻止最终失败。

因此，第（四十二）篇的核心原则是：

Every agent may be locally correct while the system remains globally wrong.

要解决这个问题，必须把治理对象从单个 Agent 扩展到整个工作流。

Verified Agent Identity
          ↓
Verified Source Evidence
          ↓
Evidence-preserving Handoff
          ↓
Distributed Evaluation
          ↓
Global Invariant Enforcement
          ↓
Workflow-level Assurance
          ↓
Authorized Production Effect
          ↓
End-to-End Verification
          ↓
System-wide Safety Case

这条链路最终要求系统能够回答：

谁提供了事实？谁使用了事实？谁验证了事实？哪些限制在交接中仍然有效？什么规则约束了整个工作流？谁批准了最终生产操作？真实业务结果是否符合原始目标？如果发生事故，哪些事实可以确定，哪些因果关系仍然需要调查？

这些问题回答得越清楚，系统才越有资格承担更复杂的自主任务。

第（三十九）篇，我们提出：Continuously Assured Autonomous Agent。

第（四十）篇，我们推进到：Containable and Recoverable Autonomous System。

第（四十一）篇，我们进一步提出：Provably Recoverable and Safely Re-admitted Autonomous Agent。

到了第（四十二）篇，治理目标正式升级为：

End-to-End Verifiable Multi-Agent System。

最后，用一句话概括本篇：

An autonomous workflow should not be trusted merely because each agent passed its own checks. It should be trusted only to the extent that its end-to-end claims, evidence, authority, and effects have been verified.

翻译成生产工程原则：

系统级可信，必须由系统级证据支持。

对于 SEO/GEO 自动化，这意味着我们最终追求的不应该只是一个能够每天自动生成和发布内容的系统。

而应该是一个能够持续说明：

为什么这些事实可信、为什么这项任务被允许、为什么这篇文章能够发布、为什么最终结果符合业务目标，以及错误发生以后如何追溯和恢复的完整自治系统。

这才是多 Agent 自动化真正进入生产级治理的关键。

---

官方依据与研究边界

以下资料构成本文的主要外部技术依据。有关 Global Invariants、Cross-Agent Evidence Graph 和 System-wide Safety Case 的具体实现模型，均应与官方原始技术规范区分。

1. NIST AI Risk Management Framework / Playbook

NIST AI RMF 1.0 于 2023 年 1 月发布，其 Playbook 围绕 Govern、Map、Measure、Manage 四项功能提供自愿性的风险管理实践建议。本文借鉴其系统风险识别、评估、监测和管理思想。

官方来源：

https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook

https://airc.nist.gov/airmf-resources/playbook/

2. W3C Trace Context

W3C Recommendation 定义跨服务分布式追踪上下文传播所需的标准 HTTP Header 与数据格式。本文以此作为跨 Agent 执行关联的技术依据，不将 Trace Context 等同于授权或因果证明。

官方来源：

https://www.w3.org/TR/trace-context/

3. OpenTelemetry Specification

OpenTelemetry 规范提供 Trace、Span、SpanContext、Span Link 等机制，用于跨进程观察和关联执行行为。本文借鉴其分布式可观察性能力，但另行提出 Claim、Handoff 和 Effect 的业务证据图。

官方来源：

https://opentelemetry.io/docs/specs/otel/overview/

https://opentelemetry.io/docs/specs/otel/trace/api/

4. OpenAI Agents SDK — Tracing、Handoffs 与 Workflow Evaluation

OpenAI 官方资料介绍了 Agent Handoff、Tool Call、Guardrail、Trace 与工作流评估的实际技术能力。本文的四层评估体系为项目扩展，不是 OpenAI 官方定义的 L1–L4 标准。

官方来源：

https://openai.github.io/openai-agents-python/tracing/

https://openai.github.io/openai-agents-python/handoffs/

https://developers.openai.com/api/docs/guides/agent-evals

5. ISO/IEC/IEEE 15026-2:2022 — Assurance Case

该标准于 2022 年发布，规定 Assurance Case 的结构与术语要求。本文借鉴其主张、论证和证据组织方式，但不把本项目的 System-wide Safety Case Schema 描述为 ISO 官方模板。

官方来源：

https://www.iso.org/standard/80625.html

6. OWASP Top 10 for Agentic Applications 2026

OWASP 于 2025 年 12 月 9 日发布该项目资料，讨论自治 Agent 应用的关键安全风险。本文将其作为多 Agent 权限、工具、目标与风险传播治理的参考，而不是声称其已经规定本文全部控制结构。

官方来源：

https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

7. Google Search Central — Creating Helpful, Reliable, People-First Content

Google 官方强调内容的原创性、可靠性、准确性与用户价值。本文将这些原则转化为 SEO 内容生产的可验证业务约束，但不把该转换模型描述为 Google 排名规则。

官方来源：

https://developers.google.com/search/docs/fundamentals/creating-helpful-content

8. Google Search Central — Spam Policies

Google 明确描述了 Scaled Content Abuse，包括主要为了操纵搜索排名而大量生产缺乏用户价值内容的行为。本文据此强调规模化自动发布必须建立系统级质量保障，不能将“使用 AI”直接等同于违规。

官方来源：

https://developers.google.com/search/docs/essentials/spam-policies

本项目原创工程模型

本文建议的以下机制属于 SEO/GEO 工作自动化专项原创或组合性架构设计：

• Cross-Agent Accountability Framework
• Cross-Agent Evidence Graph
• Claim-level Provenance Registry
• Evidence-preserving Handoff Contract
• SEO/GEO Global Invariants
• Four-level Distributed Evaluation Architecture
• Causal Evidence Record
• Workflow Assurance Authority
• System-wide Safety Case
• Global Assurance Decision
• System-wide Assurance Manifest
• Multi-Agent Recovery Verification
• Local-pass / Global-fail Monitoring

这些模型可以用于系统设计、SOP 建设和实现验证，但不能未经核实地标注为 NIST、ISO、W3C、OpenTelemetry、OpenAI、OWASP 或 Google 已发布的统一工程标准。

第（四十三）篇预告：Policy-as-Code / Global Invariant Compiler / Proof-carrying Handoff / Runtime Verification

第（四十二）篇解决了一个系统级问题：

为什么 Agent 的局部正确，不能自动证明整个工作流正确？

我们建立了 Cross-Agent Evidence Graph、Distributed Evaluation、Global Invariants 和 System-wide Safety Case。

但接下来还有一个更加实际的工程问题：

这些规范如果只存在于文章、Prompt、审核清单和制度文件中，系统到底怎样自动执行？

例如：“未经验证的关键产品参数不得正式发布。”

这是一项正确的治理规则。

但如何把它转化为可以被机器执行的策略？

怎样防止 Agent 在 Handoff 时丢失限制？

怎样让 WordPress Publishing Gateway 在真正写入前检查全局约束？

怎样在 Model、Tool 或业务规则更新以后，证明原来的控制仍然有效？

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

Policy-as-Code / Global Invariant Compiler / Proof-carrying Handoff / Runtime Verification / Policy Decision Point / Policy Enforcement Point / Evidence-bound Authorization / Continuous Policy Compliance / Governance CI/CD / Policy Regression Testing

目标是把本篇的：

System-wide Assurance

推进到：

Machine-enforceable Governance

最终形成：

Human-approved Policy
        ↓
Machine-readable Invariant
        ↓
Policy Compilation
        ↓
Evidence-bound Handoff
        ↓
Runtime Verification
        ↓
Policy Decision
        ↓
Effect Enforcement
        ↓
Continuous Compliance Evidence

也就是从：

End-to-End Verifiable Multi-Agent System

继续走向：

Policy-enforced and Evidence-carrying Autonomous Workflow。