SEO / GEO 工作自动化部署与实践规范（二十六）：Evidence Plane / Risk Engine / Decision Trace——让 Governance Engine 从“按规则判断”升级为“基于证据、风险与可解释轨迹做决策”

创见日期：2026年9月21日

第（二十五）篇解决了一个重要问题：当 SEO Agent、GEO Agent、Content Agent、Technical Agent、Publishing Agent 和其他自动化组件准备采取行动时，不应该继续由各个 Agent 自己决定“能不能做”。系统应该统一经过 Policy-as-Code + Control API + Governance Engine，并得到 ALLOW、DENY、REQUIRE_APPROVAL、DEFER、ESCALATE 这样的机器可执行决策。

但这只完成了治理系统的第一半。因为一旦真正开始建设 Governance Engine，马上会遇到第二个更困难的问题：Governance Engine 凭什么做出这个决定？

如果请求里只是随手传入 risk_score = 78，然后 Policy 写成 IF risk_score >= 70 THEN REQUIRE_APPROVAL，表面上看已经完成风险治理，实际上只是把“这个操作看起来风险挺高”换成了一个看似精确的数字。

真正成熟的治理系统不能只有：

Policy
→ Decision

而必须进一步建立：

Evidence
↓
Signals
↓
Risk Factors
↓
Risk Assessment
↓
Policy Evaluation
↓
Governance Decision
↓
Decision Trace

这就是第（二十六）篇要解决的核心：Evidence Plane / Risk Engine / Decision Trace。它们共同回答三个问题：我们知道什么？这些事实意味着什么风险？为什么最终做出这个治理决策？

1、真正危险的不是没有 Risk Score，而是 Risk Score 看起来太精确

自动化系统非常喜欢 Score，因为 Score 很容易进入代码。比如把风险映射为 0–100，再映射成 LOW / MEDIUM / HIGH / CRITICAL，最后进一步映射成 ALLOW、ALLOW + OBLIGATIONS、REQUIRE_APPROVAL 或 DENY。

这套设计非常直观，但问题也非常严重。假设 SEO Agent 准备修改 800 个页面 Title，Risk Engine 返回 Risk Score = 76，我们仍然不知道：76 到底意味着什么？是 Change Volume 高？Business Impact 高？Evidence Confidence 低？数据不新鲜？还是 Risk Model Version 刚刚改变？

最危险的不是评分错误，而是一个带有小数、区间、颜色和等级的数字，容易制造一种“系统已经准确测量风险”的错觉。

Risk Score 不是 Evidence。它只是对 Evidence 的某种计算结果。

2、把 risk_score 拆开

未来 Control API 不应该主要接收一个 risk_score，而应该接收或者能够解析出：

Evidence
Signals
Risk Factors
Impact
Likelihood
Exposure
Reversibility
Detectability
Control Coverage
Uncertainty
Confidence
Freshness

最终形成 Risk Assessment，然后 Governance Engine 再根据 Risk Assessment + Policy + System Context 形成 Decision。

Evidence ≠ Risk；Risk ≠ Decision。这是三个完全不同的层次。

3、Evidence Plane 是整个治理系统的事实层

Evidence Plane 可以理解为：Governance Engine 可以使用的、具有来源、时间、上下文和可信度的事实层。

它回答的是：What do we actually know？而不是 What does the Agent think？

例如 SEO Agent 想修改一个核心产品页。Agent 的理由可能是“这个 Title 可能影响 CTR”，这只是 Claim。Evidence Plane 则应该提供：

Page:
/products/ferris-wheel/

GSC clicks_28d:
1842

GSC impressions_28d:
49321

CTR:
3.73%

Previous CTR:
4.91%

Average Position:
4.2

Query Mix:
Stable

Page Type:
Core Commercial

Revenue Attribution:
High

Last Title Change:
93 days ago

Rollback Snapshot:
Available

Google Update:
Inactive

Data Freshness:
26 hours

然后系统才开始解释这些 Evidence。

4、Evidence 必须成为一等数据对象

不能继续把 Evidence 当成 Workflow 中的临时变量。建议建立正式 Evidence Object：

{
  "evidence_id": "ev_01K6...",
  "evidence_type": "metric_observation",

  "subject": {
    "type": "webpage",
    "id": "/products/ferris-wheel/"
  },

  "claim": {
    "metric": "organic_ctr",
    "value": 0.0373,
    "window": "28d"
  },

  "source": {
    "system": "google_search_console",
    "property": "https://example.com/"
  },

  "observed_at": "2026-09-21T04:00:00Z",
  "ingested_at": "2026-09-21T05:14:23Z",

  "freshness": {
    "age_hours": 25.2,
    "state": "ACCEPTABLE"
  },

  "provenance": {
    "collector": "gsc-ingestion-v4",
    "query_hash": "sha256:...",
    "transform_version": "3.8.2"
  },

  "quality": {
    "completeness": 0.99,
    "consistency": 0.96
  }
}

这时候 Evidence 不再只是“CTR = 3.73%”，而是这个数字来自哪里、什么时候产生、什么时候被系统看到、经过什么转换、现在还有没有资格被使用。

5、Provenance：证据必须知道自己从哪里来

Evidence Plane 最重要的字段之一就是 Provenance。W3C PROV 系列规范长期以来围绕同一问题设计：描述一个数据对象由哪些 Entity、Activity 和 Agent 产生，以及对象之间如何派生，从而支持对来源、质量、可靠性、信任和可复现性的判断。

我们的系统没有必要完整实现 W3C PROV，但应该继承其最重要的思想：

Data without provenance
=
Weak evidence

例如“Organic Traffic = -32%”完全不够。至少还应该知道 Source、Property、Date Window、Comparison、Timezone、Filter、Transformation、Tracking State 与 Generated At。否则 Governance Engine 无法判断这个 -32% 到底能不能用来触发行动。

6、Observed At 与 Ingested At 必须分开

Evidence 至少存在两个时间：observed_at 与 ingested_at。

例如 Search Console 数据对应 2026-09-19，但系统直到 2026-09-21 才读取到。那么 observed_at ≠ ingested_at。

如果不区分，系统可能误以为“刚刚获取的数据就是刚刚发生的数据”。这对于 SEO Anomaly、Google Update、Experiment、Incident 与 GEO Monitoring 都会造成严重误判。

7、Freshness 不是附加字段，而是 Evidence Eligibility

过去我们可能只把 Freshness 显示在 Dashboard。Governance Engine 中，Freshness 应进一步进入 Evidence Eligibility。

GSC < 36h
→ ELIGIBLE

GSC 36–72h
→ DEGRADED

GSC > 72h
→ STALE

同一条“CTR dropped 28%”证据，今天可能支持 REQUIRE_APPROVAL，三天后如果没有更新就可能只支持 DEFER。Evidence 实际上应该有自己的 Time-to-Live。

8、Freshness 应该允许衰减，而不只是 Fresh / Stale

现实中的 Evidence 并不会在某个时刻突然从 100% 可信变成 0%。更合理的是 Freshness Decay，例如：

0–24h
Freshness Confidence = 1.0

24–48h
= 0.9

48–72h
= 0.7

72h+
= 0.4

当然，不同 Evidence 类型必须使用不同规则。Company Legal Name 可以数月不变，而 Deployment Health 可能五分钟后就失去意义。因此 Freshness Policy 必须是 Evidence-Type Specific。

9、Evidence 与 Signal 必须分开

假设系统观察到 CTR 从 4.8% 下降到 3.2%，这是 Evidence；进一步计算 CTR Change = -33%，仍然可以视为 Derived Evidence；但当系统输出 CTR_ANOMALY = TRUE 时，已经进入 Signal。

Evidence
=
What happened

Signal
=
Something noteworthy may be happening

Signal 是对 Evidence 的机器解释。

10、Signal 应该有自己的生成规则

{
  "signal_id": "sig_10293",
  "type": "CTR_ANOMALY",
  "subject": "/products/ferris-wheel/",
  "derived_from": [
    "ev_201",
    "ev_202",
    "ev_203"
  ],
  "rule": {
    "id": "ctr-anomaly-v3",
    "version": "3.1"
  },
  "value": true,
  "severity": "medium",
  "confidence": 0.87
}

这样系统才能解释为什么 CTR_ANOMALY 会变成 TRUE。

11、Risk Factor 是 Signal 的进一步治理解释

Signal 并不自动等于 Risk。CTR_ANOMALY 只是异常信号；但如果页面是 Core Commercial Page，并且 Revenue Contribution = High，那么它才进一步形成 Business Impact Risk。

又例如 Change Count = 1,200 本身只是事实，经过 Risk Engine 后变成 High Blast Radius。

Evidence:
1200 URLs

↓

Signal:
BULK_CHANGE

↓

Risk Factor:
LARGE_BLAST_RADIUS

12、Risk Factor 必须可枚举，而不是只留一个数字

建议至少逐步建立这些风险维度：

Impact
Likelihood
Exposure
Blast Radius
Reversibility
Detectability
Time Sensitivity
Control Coverage
Dependency Health
Data Quality
Evidence Confidence
Uncertainty

最终系统才知道风险高在哪里，而不是只知道 Risk = 78。

13、Impact：如果出错，会有多严重？

Impact 回答：What happens if this goes wrong?

修改 Blog Draft 和修改 robots.txt 都可能只是 UPDATE，但 Impact 完全不同。可以定义 I1 Negligible、I2 Limited、I3 Material、I4 Major、I5 Critical。

注意，Impact 不是发生概率，只回答“一旦发生，后果有多大”。

14、Likelihood：错误有多可能发生？

Likelihood 回答 How likely is failure?

经过稳定模板执行 Update Meta Description，失败概率可能比较低；但让 Agent 自动 Rewrite Product Specification，而来源数据又存在冲突，Likelihood 会明显提高。

可以建立 L1 Rare、L2 Unlikely、L3 Possible、L4 Likely、L5 Highly Likely。但如果没有足够数据，系统应该返回 UNKNOWN，而不是强迫模型猜一个 L3。

15、Unknown 必须成为一等状态

企业风险系统一个常见错误是每个字段都必须有数字。现实中很多时候我们根本不知道。成熟系统应该允许 KNOWN、ESTIMATED、UNKNOWN，甚至 NOT_APPLICABLE。

Unknown 不应该被悄悄换算成 0，否则 Unknown Risk 会被错误地理解成 No Risk。

16、Exposure：这个动作影响多少资产？

Exposure 与 Impact 不一样。修改一个高价值 Homepage，Exposure 可能 Small 但 Impact Critical；一次修改 10,000 个低价值 Archive 页面，Exposure Massive 但单页 Impact Low。两者都可能高风险，但原因完全不同。

Exposure 可以参考 URL Count、Traffic Share、Revenue Share、Country Coverage、Language Coverage、Entity Coverage、Tool Scope 与 Credential Scope。

17、Blast Radius 应该比 Change Count 更重要

1000 URLs 不一定比 1 个 robots.txt 风险更大。真正要计算的是 Blast Radius，包括 Affected Resources、Dependencies、Traffic Coverage、Index Coverage、Revenue Coverage、Downstream Systems 与 Rollback Scope。

18、Reversibility：犯错之后能不能回来？

Risk Engine 中必须加入 Reversibility。Meta Description Change 通常容易回滚；Delete Database Records 可能不可逆；大量 URL 301 Redirect 技术上可回滚，但搜索系统重新处理后影响可能不是瞬间恢复。

因此可以进一步区分 Technical Reversibility、Operational Reversibility、Search Reversibility 与 Business Reversibility。

19、Detectability：如果出错，我们能多快知道？

风险不仅取决于是否会失败，还取决于失败以后多久才能发现。

WordPress API 返回 500，Detectability 是 Immediate；错误 Canonical，Detectability 可能 Delayed；AI Search Citation 下降，Detectability 可能 Potentially Slow。

因此 Low Detectability 本身就应该提高治理等级。

20、Control Coverage：现有控制能不能把风险兜住？

两个完全相同的生产动作，如果一个拥有 Snapshot、Rollback、Canary、Monitoring、Post-release Validation，另一个完全没有，最终风险不应该相同。

所以 Risk Engine 必须考虑 Control Coverage。现有 Control 越强，Residual Risk 才可能越低。

Inherent Risk
↓
Controls
↓
Residual Risk

21、Inherent Risk 与 Residual Risk 必须分开

例如 Bulk Title Change 本身 Inherent Risk = HIGH，但系统具备 10% Canary、Snapshot、Auto Rollback、SEO Monitoring、Human Approval，那么 Residual Risk 可能降到 MEDIUM。

Governance Engine 真正应该依据的通常是 Residual Risk，同时保留 Inherent Risk。这样才能知道当前之所以允许执行，是因为风险本身不高，还是因为控制措施足够强。

22、Risk 与 Confidence 必须彻底分离

这是整篇最重要的原则之一。不要只返回 Risk Score = 78，而应该至少返回：

Risk:
HIGH

Confidence:
0.91

HIGH RISK + HIGH CONFIDENCE 意味着系统相当确定这是高风险动作，可能进入 DENY 或 REQUIRE_APPROVAL。

HIGH RISK + LOW CONFIDENCE 意味着当前证据提示风险可能很高，但系统并不确定，更合理的动作可能是 ESCALATE 或 DEFER。

23、低风险 + 低 Confidence 也不能直接 ALLOW

假设 Risk = LOW，但 Confidence = 0.32，真正含义并不是“风险很低”，而是“根据当前非常不足的 Evidence，看起来风险可能较低”。

因此 LOW RISK + LOW CONFIDENCE 也可能应该 DEFER，甚至 REQUIRE_APPROVAL。

Confidence 不能被 Risk Score 吸收掉。

24、Confidence 到底衡量什么？

Confidence 不能只是 LLM 返回 0.87。更合理的 Confidence 应至少参考 Source Reliability、Evidence Completeness、Evidence Consistency、Freshness、Sample Size、Measurement Quality、Model Certainty 与 Historical Stability。

可以把它拆成三层：

Evidence Confidence
Model Confidence
Decision Confidence

25、Evidence Confidence

Evidence Confidence 回答：我们对底层事实有多确定？

Search Console API + 数据完整 + 时间窗口足够 + 没有 Tracking 异常，可以形成较高 Evidence Confidence；而单次 AI Prompt 或第三方截图不应该拥有同样等级。

26、Model Confidence 不能冒充 Evidence Confidence

LLM 可能返回 Confidence = 0.94，这最多表示模型对自己的解释比较确定，并不意味着 Evidence Quality = 0.94。

否则 Very confident hallucination 可能被系统错误升级成 High-quality evidence。

27、Decision Confidence 是最终层

Decision Confidence 回答的是：给定这些 Evidence、Signals、Risk Factors 和 Policies，我们对最终 Governance Decision 有多大把握？

{
  "decision": "REQUIRE_APPROVAL",
  "risk": "HIGH",
  "evidence_confidence": 0.94,
  "decision_confidence": 0.91
}

与：

{
  "decision": "ESCALATE",
  "risk": "HIGH",
  "evidence_confidence": 0.44,
  "decision_confidence": 0.62
}

表达的是完全不同的治理状态。

28、NIST AI RMF 给出的重要启示：风险必须被测量、记录和持续监控

NIST AI RMF 1.0 的 MEASURE 功能强调使用定量、定性或混合方法，对已经识别的 AI 风险进行分析、评估、基准测试和持续监控，并要求对无法测量的风险进行记录，而不是假装所有风险都能被精确量化。

这对 Risk Engine 的启发非常重要：

Measurable
→ Measure

Not Measurable
→ Document

Uncertain
→ Preserve Uncertainty

而不是 Everything → Convert to 0–100。

29、Risk Engine 不应该只有一个公式

最简单的风险矩阵是 Risk = Impact × Likelihood。它很有用，但对于 Agent 系统远远不够。我们还需要考虑 Exposure、Blast Radius、Reversibility、Detectability、Control Coverage、Evidence Confidence、Freshness 与 System State。

Risk Assessment
=
f(
  Impact,
  Likelihood,
  Exposure,
  Blast Radius,
  Reversibility,
  Detectability,
  Controls,
  Evidence,
  Context
)

但不要急着把它变成复杂数学公式。首先应该让每个维度可解释、可追溯、可测试。

30、不要过早引入“高级 AI 风险模型”

第一阶段完全可以先使用 Rules + Tables + Thresholds + Historical Metrics。

Protected Resource
→ Impact >= HIGH

Bulk Change > 500 URLs
→ Exposure >= HIGH

No Rollback
→ Reversibility = LOW

Data Freshness > Threshold
→ Evidence Quality = DEGRADED

只有当 Decision Logs 足够多以后，才值得进一步研究 Statistical Risk Model、Machine Learning、Bayesian Risk 与 Predictive Failure Model。否则系统只是用更复杂的模型掩盖更差的数据基础。

31、Evidence Conflict 必须成为正式状态

真实系统经常会遇到：

GSC:
Traffic Stable

GA4:
Traffic -35%

Server Logs:
Googlebot Stable

这不是普通 LOW CONFIDENCE，而是 EVIDENCE_CONFLICT。

{
  "conflict_id": "conf_921",
  "evidence": [
    "ev_gsc_21",
    "ev_ga4_31",
    "ev_logs_12"
  ],
  "state": "UNRESOLVED"
}

Policy 可以规定：如果 evidence_conflict == UNRESOLVED 且 action_risk >= HIGH，则 ESCALATE。

32、Source of Truth Conflict 是更高级别的 Conflict

例如 Website 写 Capacity = 100，CRM 写 80，Engineering Master Data 写 120。这不是简单数据误差，而是 Authority Conflict。

此时应该先判断哪个系统拥有 Authority。如果 Authority 本身没有定义，Governance Engine 不应该猜。正确答案可能就是 ESCALATE。

33、Evidence Plane 最终应该形成 Evidence Graph

随着系统复杂度增加，Evidence 不应该只是 SQL Table，而应该逐渐形成 Evidence Graph：

Decision
  │
  ├── Risk Assessment
  │      │
  │      ├── LARGE_BLAST_RADIUS
  │      │        │
  │      │        └── 1,200 URLs
  │      │
  │      ├── HIGH_BUSINESS_IMPACT
  │      │        │
  │      │        ├── Revenue Share
  │      │        └── Core Page
  │      │
  │      └── LOW_REVERSIBILITY
  │               │
  │               └── No validated rollback
  │
  └── Policies
         │
         ├── bulk-change-v4
         └── core-commercial-page-v3

这样用户才能真正 Drill-down：为什么 REQUIRE_APPROVAL？

34、Decision Trace 与普通 Agent Trace 不是一回事

第（二十四）篇已经引入 Agent Trace。OpenAI Agents SDK 当前的 tracing 可以记录 Agent 运行中的 LLM generations、tool calls、handoffs、guardrails 和 custom events，并使用 trace / span 表示端到端 workflow。

但 Execution Trace 和 Decision Trace 必须分开。

Execution Trace
回答：
Agent 做了什么？

Decision Trace
回答：
系统为什么允许或阻止它？

35、OpenTelemetry 可以提供 Trace 的基础语义

OpenTelemetry 的 Trace 模型中，一个 Trace 由多个 Span 组成；Span 包含 parent、timestamps、attributes、events、status 等信息，并可以组成完整调用树。Semantic Conventions 的目标之一也是让不同语言和系统使用统一字段进行关联分析。

因此可以借鉴 trace_id、span_id、parent_span_id、attributes、events，但 Governance Decision 还需要额外建立：

decision_id
evidence_set_id
risk_assessment_id
policy_evaluation_id

36、一个完整 Decision Trace 应该长什么样？

{
  "decision_id": "dec_002193",
  "trace_id": "trace_a81...",

  "request": {
    "principal": "seo-agent",
    "action": "UPDATE_SEO_METADATA",
    "resource": "/products/ferris-wheel/"
  },

  "evidence_set_id": "evset_301",

  "signals": [
    "sig_ctr_decline",
    "sig_high_business_value"
  ],

  "risk_assessment_id": "risk_811",

  "risk": {
    "inherent": "HIGH",
    "residual": "MEDIUM_HIGH",
    "confidence": 0.91
  },

  "policies": [
    "core-commercial-page-v3",
    "production-seo-change-v5"
  ],

  "decision": "REQUIRE_APPROVAL",

  "obligations": [
    "snapshot",
    "store_diff",
    "post_release_monitoring"
  ],

  "policy_version": "2026.09.21.7",
  "created_at": "2026-09-21T05:41:20Z"
}

这才是真正的 Explainable Governance。

37、Decision Trace 不应该只是最终结果

很多系统只记录 Decision = DENY，这不够。应该记录 Input、Evidence Used、Evidence Rejected、Signals Generated、Risk Factors、Control Adjustments、Policy Matches、Conflict Resolution、Final Decision、Obligations 与 Execution Outcome。

特别重要的是 Evidence Rejected。

38、为什么要记录 Evidence Rejected？

假设系统同时获得 GSC、GA4、Third-party SEO Tool、Cached Snapshot 与 Agent Observation，最后只采用 GSC + GA4，那么 Decision Trace 应该解释：

Third-party Tool:
rejected_due_to_staleness

Cached Snapshot:
rejected_due_to_age

Agent Observation:
context_only

否则未来复盘时，人类只知道系统“看过这些数据”，却不知道哪些数据真正参与了判断。

39、Policy Evaluation 本身也应该进入 Trace

policy_1
matched

policy_2
matched

policy_3
not_matched

policy_4
overridden

winning_policy:
core-commercial-page-v3

这与 OPA Decision Logs 的工程思想高度一致。但本文的 Decision Trace 会继续向上增加 Evidence、Risk、Confidence、Obligations 与 Outcome，这些属于本项目的 Governance Architecture。

40、Decision Trace 必须连到 Execution Outcome

真正成熟的系统不能在 ALLOW 之后就结束记录。我们还需要知道 ALLOW 以后发生了什么。

Decision:
ALLOW

Execution:
SUCCESS

Validation:
FAILED

Rollback:
TRIGGERED

最终才能判断这次 Policy Decision 好不好。

41、没有 Outcome，Risk Engine 永远不会进步

Decision Trace 最终应该进入 Feedback Loop：

Decision
↓
Execution
↓
Outcome
↓
Incident / Success
↓
Risk Model Evaluation
↓
Policy Improvement

例如过去 100 次 Risk = MEDIUM、Decision = ALLOW，其中 18 次发生 Rollback，那么这个 Risk Model 很可能低估风险。

42、Risk Calibration 要成为正式指标

随着数据积累，可以衡量 Predicted Risk vs Observed Outcome。

LOW Risk
Failure Rate = 1%

MEDIUM Risk
Failure Rate = 8%

HIGH Risk
Failure Rate = 26%

如果实际变成 LOW 18%、MEDIUM 7%、HIGH 9%，说明 Risk Classification 基本失去意义。这就是 Risk Calibration。

43、Confidence 也需要 Calibration

如果系统长期声称 Confidence > 0.9，但最后 30% 决策被人工 Override，说明 Decision Confidence 也没有校准好。

因此未来 Governance Console 中应该增加 Risk Calibration、Confidence Calibration、Human Override Rate 与 Policy Override Rate。

44、Human Override 不应该被视为失败

例如系统 REQUIRE_APPROVAL，人类最终 REJECT，这是非常有价值的数据。或者系统 DENY，经过 Break-glass OVERRIDE，也应该记录 override_reason、override_actor、override_evidence、override_outcome，然后用于未来 Policy Review。

45、Risk Engine 不应该直接依赖自然语言解释

错误架构：

LLM:
“我认为风险比较高，
因为这个页面似乎很重要。”

↓

Risk = HIGH

正确架构：

Structured Evidence
↓
Structured Signals
↓
Risk Rules / Model
↓
Risk Assessment
↓
LLM Explanation

LLM 可以负责 Explain、Summarize、Recommend，但不要让 Natural Language Narrative 成为唯一风险计算输入。

46、Explainability 也不能等于“让 LLM 解释一下”

很多系统所谓 Explainable AI 的实际实现是 Decision = DENY，然后再 Prompt：Please explain why this decision happened。

这不是真正的 Decision Trace。真正的 Explainability 应该来自 Actual Evidence、Actual Policy Match、Actual Risk Factors、Actual Rule Evaluation 与 Actual Decision。LLM 最多负责把这些结构化事实转换成人类容易阅读的语言。

47、Evidence Plane 还必须处理 Sensitive Data

Decision Trace 往往会越来越详细，这也意味着 Credential、User Data、Business Data、Security State、Internal Risk 可能被写进 Trace。

不能为了 Explainability 把所有输入完整永久保存。Evidence Plane 必须支持 Redaction、Masking、Hashing、Retention、Access Control 与 Classification。

48、Evidence 本身也需要 Permission

不是所有 Agent 都应该看到 Revenue Data、Security Finding、Credential State、Employee Information。因此 Evidence Plane 本身必须进入第（二十五）篇建立的 Governance Engine。

Agent
↓
Request Evidence
↓
Governance
↓
Evidence Access

这意味着 Governance Engine 也治理 Governance Data。

49、SEO 场景：是否应该自动改 Title？

SEO Agent 提出：

Action:
UPDATE_TITLE

Resource:
/products/ferris-wheel/

Evidence Plane：

GSC CTR:
-28%

Average Position:
Stable

Traffic:
High

Revenue Share:
High

Title Age:
112 days

Google Update:
Inactive

Page Type:
Core Commercial

Rollback:
Available

Data Freshness:
28h

Signals：

CTR_DECLINE
HIGH_VALUE_PAGE
TITLE_STALE
ROLLBACK_READY

Risk Factors：

Business Impact:
HIGH

Likelihood:
MEDIUM

Blast Radius:
LOW

Reversibility:
HIGH

Detectability:
HIGH

Control Coverage:
HIGH

Risk Engine：

Inherent Risk:
HIGH

Residual Risk:
MEDIUM

Confidence:
0.93

Governance Engine：

REQUIRE_APPROVAL

Reason：

Core Commercial Page
+
High Business Impact
+
Production SEO Change

Obligations：

Create Snapshot
Store Diff
Monitor CTR
Rollback Window = 14d

这已经远比 risk_score = 72 有价值。

50、Technical SEO 场景：robots.txt 修改

Technical Agent 发现 Crawler 无法访问某资源，建议修改 robots.txt。

Evidence：

Crawler Test:
Blocked

Robots Rule:
Confirmed

Affected URLs:
47,000

Search Traffic:
High

Rollback:
Available

Canary:
Impossible

Risk Factors：

Impact:
CRITICAL

Blast Radius:
SITE_WIDE

Reversibility:
MEDIUM

Detectability:
MEDIUM

Control Coverage:
MEDIUM

即使 Likelihood of mistake = LOW，最终 Residual Risk 仍可能为 HIGH，Governance 返回 REQUIRE_APPROVAL，甚至根据 Policy 要求 Mandatory L2 Approval。

Low Failure Probability ≠ Low Risk。

51、GEO 场景：品牌 Leadership Claim

GEO Agent 想发布：“We are a leading global manufacturer…”

Evidence Plane 搜索 Company Site、CRM、Industry Sources、Awards、Market Research，最终得到：

Manufacturing Fact:
Supported

Global Customers:
Supported

Leading Claim:
No authoritative evidence

Signal：

UNSUPPORTED_SUPERLATIVE

Risk Factor：

Claim Risk:
HIGH

Evidence Confidence:
HIGH

Business Impact:
MEDIUM

Governance：

DENY

这个 DENY 并不是 LLM 觉得这句话夸张，而是 Claim → Evidence Missing → Policy Match → DENY。这才是可审计治理。

52、Analytics 场景：流量下降是否触发自动优化？

Monitoring Agent 发现 Organic Sessions -31%，但同时 GSC Stable、GA4 Tracking Health = DEGRADED、Tag Deployment = 6h ago。

Signals：

GA4_ANOMALY
TRACKING_CHANGE_RECENT
GSC_NOT_CORROBORATING

Risk Engine：

Evidence Consistency:
LOW

Root Cause Confidence:
LOW

Optimization Action Risk:
HIGH

Governance：

DEFER

而不是立即启动 Mass Content Optimization。这就是 Evidence Plane 的真正价值。

53、Decision Trace 应该进入 Command Center

第（二十四）篇中的 Command Center 未来应该新增 Decision Explorer。用户点击任何 ALLOW、DENY、REQUIRE_APPROVAL、DEFER、ESCALATE，都应该看到 Decision、Risk、Confidence、Evidence、Signals、Risk Factors、Policies、Obligations 与 Outcome。

54、Governance Console 最重要的页面可能不是 Policy，而是 Why

未来操作人员最常问的问题很可能不是“有哪些 Policy？”，而是“为什么这个任务被阻止？”

DECISION

REQUIRE_APPROVAL


WHY

Core Commercial Page
High Revenue Exposure
Production Metadata Change


EVIDENCE

GSC       Fresh
GA4       Fresh
CMS       Fresh
Rollback  Ready


RISK

Impact          High
Exposure        Medium
Reversibility   High
Detectability   High

Residual Risk:
Medium

Confidence:
92%

这比 Risk Score: 67 清楚得多。

55、Evidence Plane 与 Search Data Platform 的关系

前面的架构已经建立 Search Data Platform。Evidence Plane 并不是再建一个数据仓库。

Search Data Platform
=
Stores operational and analytical data

Evidence Plane
=
Transforms eligible data
into governance-ready evidence

也就是 Raw Data → Validated Data → Evidence Object → Governance。

56、Evidence Plane 是治理语义层，不是数据复制层

它可以只保存 Reference、Hash、Snapshot、Metadata、Provenance，而不必复制所有原始数据。

{
  "evidence_id": "ev_992",
  "source_ref": "bigquery://seo/gsc/page_daily/...",
  "snapshot_hash": "sha256:...",
  "observed_at": "...",
  "quality_state": "VALID"
}

这样可以避免 Evidence Warehouse 变成新的数据孤岛。

57、完整对象模型

Evidence
↓
Signal
↓
Risk Factor
↓
Risk Assessment
↓
Policy Evaluation
↓
Governance Decision
↓
Approval / Defer / Escalation / Execution
↓
Outcome
↓
Decision Trace

核心 ID 可以统一：

evidence_id
signal_id
risk_factor_id
risk_assessment_id
policy_id
decision_id
approval_id
command_id
trace_id
outcome_id

这样整个系统第一次真正拥有 End-to-End Decision Lineage。

58、第一阶段不需要一次做完所有风险模型

建议先建设最小闭环：

STEP 1：Evidence Schema。先统一 source、observed_at、freshness、quality、provenance。

STEP 2：Signal Registry。建立 DATA_STALE、BULK_CHANGE、PROTECTED_RESOURCE、TRACKING_DEGRADED、SOURCE_CONFLICT、HIGH_VALUE_PAGE。

STEP 3：Risk Factor Schema。先支持 Impact、Exposure、Reversibility、Evidence Confidence。

STEP 4：Risk Assessment。

STEP 5：Decision Trace。将 Governance Engine 的每一次决策完整串起来。

59、第一批最值得建设的 Evidence 类型

Search Performance Evidence
Analytics Evidence
Technical SEO Evidence
CMS / Release Evidence
Content Evidence
Brand / Entity Evidence
Source Authority Evidence
Security Evidence
Reliability Evidence
Business Impact Evidence

这样已经足以覆盖绝大多数 Production Decision。

60、第一批最重要的 Risk Factors

优先从 Impact、Exposure、Reversibility、Evidence Confidence、Freshness、Control Coverage 开始。

不要第一版就设计 37 个风险维度。系统最重要的是每个维度真的有 Evidence，而不是模型看起来很复杂。

61、Evidence Plane 自己也要有 SLO

既然 Governance Engine 依赖 Evidence Plane，那么 Evidence Plane 本身也成为 Critical Dependency，需要监测：

Evidence Freshness
Evidence Availability
Evidence Validation Success
Conflict Rate
Unknown Rate
Provenance Completeness
Evidence Retrieval Latency

例如：

Evidence Availability SLO:
99.9%

Freshness Compliance:
98%

Provenance Completeness:
99.5%

62、Risk Engine 也需要自己的质量指标

至少监控：

Risk Calibration
Human Override Rate
False Allow
False Deny
Approval Conversion
Escalation Accuracy
Unknown Rate
Confidence Calibration

尤其要关注 False Allow，因为它代表系统认为可以自动执行，但结果证明本来不应该执行。

63、Decision Trace 也应该有完整性指标

例如 Decision Trace Completeness = 99.9%。每个 Production Decision 都应该能够关联 Policy、Evidence、Risk Assessment、Decision 与 Outcome。

如果某次生产变更只能找到“Agent said so”，那么它实际上仍然没有进入治理系统。

64、完整架构

                DATA SOURCES
                     │
      ┌──────────────┼──────────────┐
      │              │              │
     GSC            GA4            CMS
      │              │              │
      └──────────────┼──────────────┘
                     │
                     ▼
            SEARCH DATA PLATFORM
                     │
                     ▼
            ┌─────────────────┐
            │ EVIDENCE PLANE  │
            │                 │
            │ Provenance      │
            │ Freshness       │
            │ Quality         │
            │ Confidence      │
            │ Conflict        │
            └────────┬────────┘
                     │
                     ▼
                SIGNAL ENGINE
                     │
                     ▼
              ┌─────────────┐
              │ RISK ENGINE │
              │             │
              │ Impact      │
              │ Likelihood  │
              │ Exposure    │
              │ Blast Radius│
              │ Reversibility│
              │ Detectability│
              │ Controls    │
              │ Uncertainty │
              └──────┬──────┘
                     │
                     ▼
              Risk Assessment
                     │
                     ▼
             ┌─────────────────┐
             │ GOVERNANCE      │
             │ ENGINE          │
             │                 │
             │ Policy-as-Code  │
             │ Conflict Rules  │
             │ Obligations     │
             └────────┬────────┘
                      │
                      ▼
       ┌───────────────────────────────┐
       │      GOVERNANCE DECISION      │
       │                               │
       │ ALLOW                         │
       │ DENY                          │
       │ REQUIRE_APPROVAL              │
       │ DEFER                         │
       │ ESCALATE                      │
       └──────────────┬────────────────┘
                      │
                      ▼
                   EXECUTION
                      │
                      ▼
                  VALIDATION
                      │
                      ▼
                    OUTCOME
                      │
                      ▼
             ┌─────────────────┐
             │ DECISION TRACE  │
             │                 │
             │ Evidence        │
             │ Risk            │
             │ Policies        │
             │ Decision        │
             │ Outcome         │
             └────────┬────────┘
                      │
                      ▼
                COMMAND CENTER
                      │
                      ▼
                   LEARNING

65、从 Policy-as-Code 到 Evidence-backed Governance

第（二十五）篇完成的是：

Rules
→ Machine Executable

第（二十六）篇进一步完成：

Decisions
→ Evidence Backed

两者组合以后，Governance Engine 才真正从 Rule Engine 升级成 Evidence-backed Governance System。

结语：成熟治理最重要的问题不是“系统做了什么决定”，而是“系统凭什么这么决定”

当 Agent Automation 进入 Production 后，我们不能满足于“Agent: I think this is risky”，也不能满足于“Risk Score: 78”，更不能满足于“Policy: risk_score > 70 → approval”。这些设计只是把人的模糊判断换成了机器里的模糊数字。

真正成熟的治理链应该是：

Evidence
↓
Provenance
↓
Freshness
↓
Signals
↓
Risk Factors
↓
Risk Assessment
↓
Confidence
↓
Policy
↓
Decision
↓
Execution
↓
Outcome
↓
Decision Trace

到这个阶段，每一次 Production Decision 都应该能够回答：

What evidence did we have?
Where did it come from?
How fresh was it?
What signals were generated?
What risks were identified?
What was uncertain?
What controls reduced the risk?
Which policies matched?
Why did one policy win?
Why was the final decision
ALLOW / DENY /
REQUIRE_APPROVAL /
DEFER / ESCALATE?
What happened after execution?

这才是真正意义上的 Explainable Governance。

Agent 可以生成建议，Risk Engine 可以计算风险，Policy 可以定义边界，Governance Engine 可以做出决定；但一个企业级自主系统最终必须能够做到：任何重要决定，都能沿着 Decision Trace，一路回到当时实际存在的 Evidence。

未来真正成熟的 Agent Control Plane，不应该只有 Policy-as-Code，还必须拥有：

Evidence-as-Data
Risk-as-Structure
Decision-as-Trace

只有当 Evidence + Risk + Policy + Trace 形成统一体系，Agent 自主权才真正从“系统愿意相信 Agent”升级为：系统能够证明，为什么在这个时间、基于这些证据、在这些风险和控制条件下，允许这个 Agent 获得这一次自主权。

这才是 Governance Engine 从“有规则”走向“有依据”的真正分水岭。

官方依据与工程边界说明

本文提出的 Evidence Plane / Signal Engine / Risk Engine / Decision Trace、Evidence Eligibility、Freshness Decay、Evidence Conflict、Risk / Confidence 分离、Inherent Risk / Residual Risk、Decision Trace Completeness 等，属于本 SEO / GEO 自动化项目的工程架构，并非 NIST、W3C、OpenTelemetry、OPA 或 OpenAI 官方定义的一套统一 Agent Governance 标准。

NIST AI RMF：AI RMF 1.0 的 MEASURE 功能强调使用定量、定性或混合方法分析、评估、基准测试和监控 AI 风险，并明确要求记录无法或不适合测量的风险。官方资料：https://www.nist.gov/itl/ai-risk-management-framework

W3C PROV：W3C PROV 提供描述 Entity、Activity、Agent 及其派生关系的数据模型，用于表达数字对象的来源，并支持对质量、可靠性、可信度和可复现性进行判断。官方资料：https://www.w3.org/TR/prov-primer/

Open Policy Agent Decision Logs：OPA 可记录 Policy Query、Input、Bundle Metadata 等决策事件，并在启用 Decision Logs 时向策略决策 API 返回 decision_id，用于审计和离线调试。官方资料：https://www.openpolicyagent.org/docs/management-decision-logs

OpenTelemetry Trace：OpenTelemetry 使用 Trace / Span 描述一次端到端操作及其子操作，Span 支持 parent、时间戳、attributes、events 与 status；Semantic Conventions 用于跨语言和平台建立统一遥测语义。官方资料：https://opentelemetry.io/docs/specs/otel/trace/api/

OpenAI Agents SDK Tracing：Agents SDK 内置 tracing，可记录 LLM generations、tool calls、handoffs、guardrails 与 custom events，并使用 trace / span 表示端到端 Agent workflow。官方资料：https://openai.github.io/openai-agents-python/tracing/