SEO / GEO 工作自动化部署与实践规范（二十一）：Autonomous Optimization / Self-Improving SEO Agent——怎样让 Experiment、Knowledge Base、Digital Twin、Evaluation 与 Orchestrator 形成真正会自我校准的搜索优化系统

创见日期：2026年9月13日

第二十篇建立 SEO Simulation Lab / Experiment Engine 以后，我们终于解决了一个过去 SEO 自动化长期没有真正解决的问题：Agent 提出的优化，到底有没有被真实世界验证？

Digital Twin 可以预测，Experiment 可以验证，Control Group 可以构造反事实，Causal Inference 可以估计 Treatment Effect。但即使做到这里，一个 SEO Agent 仍然不一定会真正“进步”。因为还有最后一个问题：实验完成以后，系统会不会把正确经验留下，把错误判断修正，并让下一次决策变得更好？

Observe
↓
Reason
↓
Predict
↓
Act
↓
Measure
↓
Infer
↓
Evaluate
↓
Learn
↓
Recalibrate
↓
Reason Better Next Time

第二十一篇要解决的，就是怎样让 SEO / GEO Operating System 真正具备“受控学习”能力。

1、Self-Improving SEO Agent 到底是什么意思

它不是“Agent 自己改自己”。如果一个 Agent 可以发现 Prompt 不好、自己修改 Prompt、自己评估、自己批准、自己部署，那么 Developer、Reviewer、Security、Release Manager 与 Auditor 就被压缩成同一个执行主体，治理结构随之消失。

因此，本项目把 Self-Improving 更严格地定义为 Self-Calibrating：系统根据真实观察、实验结果、事故、人工纠正和评测数据，持续校准未来决策，而不是无限制修改自身。

2、什么才算真正的 Improvement

不是回答更长，不是调用更多工具，也不是看起来更像专家。真正的 Improvement 应体现在可以持续度量的指标上：

Decision Accuracy ↑
Risk Detection ↑
Causal Accuracy ↑
Prediction Calibration ↑
Experiment Quality ↑
False Positive ↓
Rollback ↓
Human Override ↓
Cost per Validated Outcome ↓
Business Value ↑

3、Memory 不等于 Learning

一个 Agent 可以拥有很大的 Knowledge Base，包括 Articles、Incidents、Experiments、Search Updates、GSC、GA4、Release History 和 Prompt Results，但如果下一次决策无法正确调用这些知识，它依然没有真正学习。

Memory = 系统保存了什么
Knowledge = 哪些内容已经经过验证
Learning = 这些知识是否改变了下一次决策

真正的 Learning 必须满足：

New Evidence
↓
Decision Model Changed
↓
Future Behavior Changed
↓
Change Evaluated

最后一步尤其重要，因为行为发生变化并不意味着行为变得更好。

4、建立三条完全不同的闭环

Self-Improving Search System 不应该只有一个 Learning Loop，至少需要三条。

Loop A：Optimization Loop，解决网站应该怎么优化：

Opportunity → Hypothesis → Simulation → Experiment → Release → Measurement → Decision

Loop B：Learning Loop，解决系统从结果中学到了什么：

Outcome → Evidence → Causal Evaluation → Knowledge Object → Confidence → Reusable Learning

Loop C：Meta-Optimization Loop，解决 Agent 自身的决策方法应该怎样改进：

Prompt / Routing / Threshold / Scoring Rule / Retrieval Policy / Twin Parameter / Tool Policy

第三条 Loop 的风险最高，因此不能拥有与前两条相同的权限。

5、Learning 不能自动增加 Authority

建议把权限边界写成硬规则：

Optimization Loop
→ 可以修改授权范围内的网站对象

Learning Loop
→ 可以写 Knowledge Candidate

Meta-Optimization Loop
→ 只能提出 Agent Change Proposal

Learning cannot increase Authority。系统可以自动学习，但不能自动给自己扩大权限。

6、Observation、Inference 与 Knowledge 必须分层

例如 Treatment Clicks +12%、Control Clicks +8% 是 Observation；“Incremental Effect 约 +4%”属于 Inference；“这种内部链接策略通常有效”才属于 Knowledge。

推荐结构：

Raw Observation
↓
Derived Evidence
↓
Knowledge Object

三层不能混在一起，否则系统未来无法重新解释过去。

7、Raw Observation 尽量保持 Immutable

GSC Snapshot、GA4 Events、Crawler Snapshot、Release Commit、Experiment Assignment、Search Status Event、GEO Prompt Output 与 Incident Log 应尽量保持原始记录。

例如今天某实验被标记为 WIN，半年以后发现 Control 被污染，正确做法应是把 Knowledge Object 标记为 INVALIDATED，而不是改掉历史实验数据。

8、实验结果先形成 Learning Candidate，而不是永久规则

错误路径：

Experiment WIN
↓
Knowledge Base:
Internal Links Always Work

正确路径：

Experiment WIN
↓
Learning Candidate
↓
Evidence Review
↓
Scope Detection
↓
Confidence Assignment
↓
Knowledge Admission

9、Learning Candidate 的最小结构

{
  learning_id,
  source_type,
  source_id,
  claim,
  scope,
  effect_direction,
  effect_size,
  confidence,
  limitations,
  status
}

重点不是字段数量，而是任何学习结论都必须保留来源、作用范围、置信度和限制条件。

10、Knowledge Base 至少保存六类对象

FACT
HEURISTIC
EXPERIMENT_RESULT
INCIDENT_LESSON
POLICY
UNKNOWN

FACT 是确定性事实，例如 URL X 返回 404；EXPERIMENT_RESULT 是在明确实验条件下得到的效果估计；HEURISTIC 是可复用但仍受条件限制的经验；INCIDENT_LESSON 用于提高未来风险分；POLICY 是治理规则；UNKNOWN 则明确记录证据不足。

11、UNKNOWN 也是知识

例如 GEO Citation Effect = INSUFFICIENT EVIDENCE。这个结论很有价值，因为它阻止系统假装知道。

12、任何 Knowledge 都必须有 Scope

某次 Comparison Table 实验带来转化提升，不能推出“所有页面都应该增加 Comparison Table”。知识必须绑定 site、market、language、page_type、intent、traffic_band、season、template、experiment_type 与 business_model 等上下文。

知识应该表达为：

Under Context C,
Treatment X produced Outcome Y,
with Confidence Z.

而不是简单地写成 “X works”。

13、Evidence Weighting

One LLM Guess 与 Three Controlled Experiments 不能等权。项目内部可以采用如下证据层级：

Deterministic Evidence
Controlled Experiment
Repeated Quasi Experiment
Historical Observation
External Research
Expert Review
Model Inference
Unknown

Retrieval Engine 不应该只按语义相似度检索，而应综合 Relevance、Evidence Strength、Freshness、Context Match 与 Confidence。

14、Knowledge 会衰减

SEO / GEO 知识不是永久有效。SERP Layout、Search Features、Crawler Behavior、Google Documentation、AI Search Interface、用户行为和竞争环境都会变化。

因此每条 Knowledge 至少应有：

created_at
last_validated_at
valid_until
freshness_class

状态可以是：

ACTIVE
STALE
SUPERSEDED
INVALIDATED
ARCHIVED

15、Knowledge Conflict 不应该被静默覆盖

如果 Experiment A 发现 FAQ Block 正向，而 Experiment B 为 Neutral，系统应该检查 Context、Intent、Traffic、Season、Template、Measurement 与 Experiment Power 的差异，而不是粗暴覆盖其中一条。冲突本身就是 Learning Signal。

16、Digital Twin 是 Learning Loop 的预测层

第十九篇 Digital Twin 输出 Prediction，第二十篇 Experiment Engine 输出 Reality。两者之间的差异就是 Calibration Signal：

Prediction
-
Observed Causal Effect
=
Prediction Error

不能只看预测方向。Predicted +40%、Observed +3% 虽然方向一致，仍然说明 Magnitude Calibration 很差。

17、建立 Digital Twin Calibration Dataset

simulation_id
change_type
context
predicted_direction
predicted_range
predicted_risk
observed_effect
observed_risk
confidence
prediction_error

长期统计 Direction Accuracy、Magnitude Error、Risk Recall、Risk Precision、Confidence Calibration 与 Unknown Accuracy。

18、Confidence 本身也必须校准

如果 Agent 总是 HIGH CONFIDENCE，但历史正确率只有 60%，它就是系统性 Overconfidence。HIGH、MEDIUM、LOW、UNKNOWN 必须能与历史实际正确率建立对应关系。

19、Evaluation 是 Self-Improving Agent 的免疫系统

如果一个 Agent 能提出规则、修改规则，再自己判断新规则更好，就会产生闭环偏差。每一次 Prompt Change、Model Change、Routing Change、Policy Change 和 Retrieval Change 都应该被视为 Candidate Version，并进入独立 Evaluation。

OpenAI 当前 Evals 能力支持定义评测数据与 testing criteria，并使用不同类型的 grader 对模型与配置运行评测。这类机制为 Agent Candidate 与 Production Version 的比较提供了现实工程基础。

20、所有生产 Agent 必须可版本化

agent_version
prompt_version
model_version
tool_policy_version
retrieval_version
knowledge_snapshot
twin_version

否则无法回答：为什么 9 月 20 日 Agent 做出了和 9 月 5 日不同的决定？

21、每次 Agent 决策都应该可重放

task_id
agent_version
input_snapshot
retrieved_evidence
tool_calls
intermediate_events
decision
approval
outcome

OpenAI Agents SDK 当前的 tracing 能记录 Agent workflow 中的 generations、tool calls、handoffs、guardrails 与 custom events，可用于开发与生产环境的调试、可视化和监控。

22、Outcome Eval + Trace Eval

最终结果正确，不代表过程可靠。错误数据 + 错误推理也可能碰巧得到正确答案。因此 Evaluation 必须既看“答对了吗”，也看“为什么答对、用了什么证据、调用了什么工具、有没有越权”。

23、Golden Dataset

Self-Improving Agent 必须有固定参考集，覆盖 Technical SEO、Indexing、Content Decisions、Canonical、Migration、GSC Diagnosis、GEO、Incident、Experiment Design 与 Release Decisions。

Golden Dataset 不能由被评估 Agent 自己随意修改，否则 Agent 可以通过降低考试难度制造“性能提升”。Evaluator 与被评估对象必须治理分离。

24、Challenge Set

除了正常案例，还要故意加入 Conflicting Evidence、Incomplete GSC、Canonical Ambiguity、Fake Correlation、Concurrent Google Update、Broken Analytics、Low Sample Experiment、Prompt Injection 与 Unsafe Production Change。

成熟 Agent 必须能够输出：

WAIT
UNKNOWN
HUMAN_REVIEW
REJECT

而不是对所有问题都给出执行方案。

25、Regression Gate 必须多维

新 Prompt 即使 Technical Diagnosis +8%，如果同时 False Positive +25%、Token Cost +70%、Unsafe Actions 增加，也不能发布。

Accuracy
Safety
Policy Compliance
Tool Accuracy
Abstention
Latency
Cost
Causal Reasoning
Rollback Awareness

26、Agent Change 应像代码一样发布

Learning Signal
↓
Change Proposal
↓
Offline Eval
↓
Regression Eval
↓
Shadow Mode
↓
Canary
↓
Production
↓
Monitoring
↓
Rollback

27、Shadow Mode

Shadow Agent 可以做决定，但不能执行。Production Agent 决定 WAIT，而 Candidate Agent 决定 EXECUTE 时，系统应记录 Decision Agreement、Risk Disagreement、Tool Difference、Evidence Difference、Cost Difference 与 Human Preference。

28、Agent Canary

通过 Shadow 以后仍不应该直接替换全部生产任务。可以让 Candidate Agent 先处理 5%，再到 20%、50%、100% 的低风险任务。

这里必须区分两种 Canary：

SEO Canary
→ 测试 Site Change

Agent Canary
→ 测试 Decision System Change

否则无法判断问题来自页面 Treatment，还是 Agent Version。

29、Policy Engine 永远位于 Learning Engine 之上

Agent 可以学习 Retrieval Ranking、Confidence Threshold、Experiment Prior、Simulation Weight、Prompt Wording、Routing Strategy 与 Model Selection。

但 Agent 不能自行改变 Production Permission、Secret Access、Approval Requirement、Audit Retention、Security Policy 和 High-Risk Change Classification。这些属于 Governance Plane。

30、Human-in-the-Loop 是 Runtime 的正常状态

Autonomous 不代表不需要人。OpenAI Agents SDK 当前支持对敏感工具调用设置 approval requirement，运行可以暂停，并在批准或拒绝后继续。这说明 Human Approval 应被设计成 Agent Runtime 的正常状态，而不是自动化失败。

31、Approval 应按 Risk 分级

低风险的 Knowledge Freshness Update、Retrieval Weight Suggestion 与 Internal Report 可以自动处理；中风险的 Content Update、小型 Internal-Link Experiment 与低风险 Template Adjustment 可以自动 Proposal + Canary；Canonical、Robots、Migration、Large-scale Redirect、Agent Permission 与 Security Policy 必须 Human Approval。

32、Guardrail 必须延伸到生产工具调用

在 SEO Agent 中，Guardrail 不能只用于内容安全，还要覆盖 WordPress Publish、Git Merge、Redirect Change、Robots Change、Bulk Update 等具有生产副作用的 Tool Call。

对于高风险写操作应优先使用“Check First, Execute Second”的 blocking 思路，而不是在工具已经执行以后才发现风险。

33、Search Environment 是非平稳环境

Google Ranking Systems、Search Features、Crawling、Indexing 和 SERP Interfaces 都会变化。旧知识可能突然失效，所以 Search Intelligence Layer 必须持续向 Knowledge System 注入 Platform Change、Ranking Update、Incident、Documentation Change 与 SERP Change。

34、Search Status 是 Learning Context

Google Search Status Dashboard 用于公布影响网站所有者的 Search 系统问题和重要 Ranking Updates。因此实验或模型学习时必须先问：Was Search Environment Stable?

否则系统可能把与 Google Update 同期发生的流量增长错误归因于自己的 Content Update。

35、Environment Context 必须进入 Learning Object

google_update_overlap
search_incident_overlap
seasonality
campaign_overlap
site_release_overlap
competitor_event
data_quality_state

36、Preliminary Data 不能直接进入永久知识

Search Console 的最新 Performance 数据可能仍处于收集和处理阶段，因此 Fast Signal 适合 Monitoring、Anomaly Detection 与 Canary，不适合直接成为 Permanent Learning。

建议状态：

OBSERVED
↓
PRELIMINARY
↓
FINALIZED
↓
CAUSAL_EVALUATED
↓
KNOWLEDGE_CANDIDATE

37、Warehouse 是长期 Learning Data Plane

Search Console Bulk Export 可以持续把 Search Performance 数据导入 BigQuery，并与 Release、Crawler、Experiment、GA4、GEO 与 Business Data 联合。第十八篇建立的 Search Data Platform，到这里正式成为 Self-Improvement 的事实层。

38、系统必须知道“谁修改了世界”

任何 Change 都必须携带 Release ID、commit_sha、article_version、template_version、agent_version 与 experiment_id。否则 Outcome 无法可靠归因。

39、Change Isolation 仍然是学习质量的前提

Google 对大型站点迁移的官方指导长期强调，在适用情况下可以先迁移一部分进行观察，并尽量一次只改变一个主要事项。对 Self-Improving Agent 来说，这更重要：如果一次改变太多变量，系统就无法知道自己究竟学到了什么。

40、网站实验必须保持 Search-safe

Google 当前网站测试指导要求避免通过 cloaking 向 Googlebot 与用户展示不同实验内容；多 URL 测试可以使用 canonical 表达首选版本，临时跳转使用 302，实验获得可靠结果后应及时结束。

Autonomous Optimization 不能为了更快“学习”而破坏 Crawling、Indexing 与 Canonical Safety。

41、建立 Learning Controller

到这里需要一个新的系统角色：Learning Controller。它不是普通 Writing Agent，而负责：

Collect Learning Signals
Build Learning Candidates
Validate Evidence
Detect Conflicts
Assign Scope
Set Confidence
Propose Calibration
Trigger Eval
Promote / Reject Learning

42、Learning Controller 不拥有 Production Write

它输出 Learning Proposal，而不是 Production Change。Proposal 类型可以包括：

KNOWLEDGE_UPDATE
TWIN_CALIBRATION
PROMPT_CHANGE
ROUTING_CHANGE
THRESHOLD_CHANGE
POLICY_PROPOSAL
MODEL_CHANGE

43、不同 Proposal 必须进入不同 Gate

KNOWLEDGE_UPDATE
→ Evidence Gate

TWIN_CALIBRATION
→ Calibration Eval

PROMPT_CHANGE
→ Agent Eval

MODEL_CHANGE
→ Regression + Cost Eval

POLICY_PROPOSAL
→ Human Governance Review

44、Digital Twin 可以自动校准，但不能无限自动

Expected Effect Range、Historical Delay、Confidence Prior、Risk Prior 等低风险参数可以根据重复实验提出更新；Canonical Safety Policy、Migration Approval Rule、Robots Permission 等高风险规则不能因为一次实验自动改变。

45、建立 Calibration Budget

系统不能每得到一条新数据就立即更新规则，否则会过拟合。至少应满足 Minimum Evidence Count、Minimum Confidence、Cross-context Validation、No Active Confounder 与 Stable Data 等条件以后，才触发 Calibration。

46、Data Quality Gate 防止 Catastrophic Learning

如果 Analytics Broken 导致 Conversion = 0，而 Agent 直接学习“模板失败”，就会把数据故障变成长期错误知识。因此所有 Learning Signal 在进入 Knowledge Candidate 之前，都必须通过 Data Quality Gate。

47、Knowledge Poisoning 是新的攻击面

Self-Improving Agent 的攻击面不仅是 Prompt。攻击者如果能够污染 Evidence、Knowledge、Experiment Data 或 External Source，同样可能改变未来行为。

因此 Knowledge Write 权限必须比 Read 更严格：

Many Agents → Read
Few Agents → Propose Write
Knowledge Controller → Validate
Policy → Commit

48、External Knowledge 永远不能直接成为 Internal Policy

外部文章声称“删除旧内容一定提高排名”，最多只能进入 External Claim。它不能自动变成 Production Rule。外部信息必须经过事实核验、上下文匹配、实验或人工治理。

49、Provenance 与 Knowledge Lineage

每个知识对象都应该保存 source_type、source_id、source_url、experiment_id、trace_id、release_id、evidence_snapshot 与 created_by。

同时建立血缘：

Observation
↓
Evidence
↓
Learning Candidate
↓
Knowledge Object
↓
Decision
↓
Action
↓
Outcome

这样在某条知识失效时，系统才能追踪哪些历史决策和 Agent Version 使用过它。

50、Knowledge 本身也有 Blast Radius

一条错误规则如果只影响一份内部报告，风险有限；如果它影响 Orchestrator 默认策略，风险巨大。因此建议内部划分：

K0 Informational
K1 Recommendation
K2 Decision Support
K3 Automation Rule
K4 Governance Critical

Knowledge Influence 越高，Validation Requirement 越高。

51、Orchestrator 是 Self-Improvement 的协调执行层

Learning Controller 不直接执行，而把 Learning Proposal 交给 Orchestrator。Orchestrator 决定下一步应该 Evaluate、Simulate、Experiment、Human Review、Shadow、Canary、Deploy 还是 Reject。

Orchestrator 自己也不能自动改变权限模型。它不能因为“人工审批太慢”就自行取消 Human Review。

52、Evaluation Agent 与 Orchestrator 必须职责分离

Candidate Agent
↓
Evaluation System
↓
Policy Engine
↓
Orchestrator

而不是 Candidate Agent 自己判断自己通过。

53、Agent Performance Dashboard

建议长期监控：

Decision Accuracy
Human Override Rate
Abstention Accuracy
Experiment Win Quality
Risk Detection
Rollback Rate
Incident Contribution
Prediction Error
Token Cost
Latency
Business Impact

不能只优化 Human Override Rate，也不能只优化 Action Rate。什么都不做和什么都执行都可能制造表面漂亮的单一指标。

54、Balanced Utility Score

项目内部可以采用：

Utility
=
Decision Quality
× Business Value
× Confidence Calibration
- Risk
- Cost
- Human Burden

这只是内部治理模型，不是 Google Ranking Formula。

55、Abstention 是核心能力

Self-Improving Agent 不应该越来越“敢”，而应该越来越准确地知道什么时候应该行动、什么时候不应该行动。UNKNOWN、WAIT、HUMAN_REVIEW 都必须进入 Evaluation。

56、Autonomy Ladder

L0 Observe Only
L1 Recommend
L2 Draft / Simulate
L3 Execute Low Risk
L4 Controlled Autonomous Optimization

不建议追求 Unlimited Autonomy。生产级 SEO 系统的成熟目标不是“彻底没人管”，而是细粒度可控自治。

57、Autonomy 必须按 Capability 划分

同一个 Agent 可以 Content Refresh = L3、Internal Links = L3、Schema = L2、Canonical = L1、Migration = L1、Robots = L0/L1。

权限矩阵应围绕：

agent
× tool
× action
× risk
× environment

58、Autonomy Promotion Gate

权限升级必须依赖 Minimum Evaluations、Minimum Success Rate、Maximum Incident Rate、Calibration Requirement、Human Override Threshold 与 Rollback Success 等明确证据。

同样，如果 Incident、False Positive、Drift 或 Eval Regression 上升，应自动 Demote Autonomy。

59、Safe Mode

在 Google Update、Search Incident、Tracking Failure、Major Migration 或 Unknown Drift 时，Orchestrator 可以进入 SAFE_MODE：

Production Writes ↓
Experiments Paused
High-risk Tasks → Human
Observation ↑
Diagnostics ↑

60、Learning Freeze

异常时期不仅可以冻结 Action，也应该冻结 Learning。大型 Ranking 波动期间，不应把短期结果直接提升为新 Heuristic，否则会把异常环境学成长期规则。

61、建立 Drift Detection

至少监控三类 Drift：

Data Drift
Search Environment Drift
Agent Performance Drift

Data Drift 包括 Query Mix、Country Mix、Traffic Mix 与 Product Mix；Search Drift 包括 SERP Feature、Ranking Update、Crawling Behavior 与 AI Search Change；Agent Drift 包括 Accuracy、Tool Error、Abstention 与 Cost 的持续变化。

62、Drift 不等于立即改模型

Detect
↓
Diagnose
↓
Evaluate
↓
Propose
↓
Validate
↓
Change

否则系统会把噪音变成永久策略。

63、模型升级也是 Experiment

新模型不能因为“更新”就直接替换现有模型。应该运行 Current Model vs Candidate Model，并经过 Golden Dataset、Challenge Set、Historical Replay、Production Shadow 与 Cost Eval。

64、Model Routing 也可以自我优化

例如系统可能学习到：

Low-risk classification → smaller model
Complex causal diagnosis → stronger model
Deterministic validation → no LLM

但 Routing Change 依然必须 Eval，否则成本优化可能制造质量回归。

65、Prompt Optimization 与 Reward Hacking

Agent 可以提出 Prompt Candidate，但必须与当前 Production Prompt 比较。如果 Eval 指标设计错误，Agent 可能学会优化评分而不是优化真实任务，这就是 Reward Hacking。

因此 Evaluator 本身也需要治理，监控 Evaluator Agreement、Human Agreement、False Pass、False Fail 与 Evaluator Drift。

66、高风险任务采用组合评估

Deterministic Rules
+
Model Grader
+
Historical Comparison
+
Human Review

不要让单一 Evaluator 成为新的 Single Point of Failure。

67、Self-Improvement 的四级证据

E0 = Model Hypothesis
E1 = Observed Correlation
E2 = Controlled / Quasi Experiment
E3 = Repeated Cross-context Validation

推荐动作：

E0 → Research
E1 → Simulation
E2 → Limited Optimization
E3 → Reusable Heuristic

永远不要从 E0 直接跳到 Production Policy。

68、Learning Velocity

成熟系统最终应该衡量：多少关键不确定性被实验消除，而不只是发布了多少页面。

Learning Velocity
=
Validated Learnings
÷
Time / Cost

进一步可以看：

Learning Efficiency
=
Decision Value Created
÷
Experiment + Compute + Human Cost

69、SEO 团队的目标函数会发生变化

过去看 Content Volume，后来关注 Traffic 与 Revenue。进入自治阶段以后还要看 Learning Rate：组织是否越来越快地把“不知道”变成“经过验证的知道”。

70、Self-Improving GEO

GEO 同样需要记录 Prompt、Mention、Citation、Citation URL、Evidence Type、Answer Position、Referral 与 Conversion。

但生成式搜索随机性更高，所以知识不能写成“Entity Definition → ChatGPT Citation”，而应该记录 Citation Rate、Mention Rate、Citation Stability、Prompt Coverage 以及 Model / Market Context。

71、不同生成式系统不能混成一个规则

Knowledge Scope 应包括 search_system、model_family、surface、country、language 与 prompt_class。一个平台的 Citation Pattern 不能未经验证地迁移到另一个平台。

72、Self-Improving Agent 必须允许自己“忘记”

不是删除历史，而是降低失效知识对未来决策的权重。Freshness、Contradictory Evidence、Platform Change、Failed Replication 与 Human Invalidation 都可以触发知识降权。

重要但过期的知识进入 REVALIDATION_QUEUE，再由系统重新研究、重新模拟或重新实验。

73、真正长期资产不是模型

比某一代模型更重要的是：

Validated Knowledge
Experiment History
Incident History
Decision Traces
Digital Twin Calibration
Evaluation Dataset

模型可以更换，但 Learning Assets 应继续存在，否则每换一次模型，Organization Memory 就被重置。

74、完整 Self-Improving Search Architecture

Search / GEO Environment
        ↓
Observation Plane
        ↓
Search Data Platform
        ↓
SEO Intelligence
        ↓
Research / Diagnosis
        ↓
Hypothesis
        ↓
Digital Twin
        ↓
Scenario Simulation
        ↓
Experiment Engine
        ↓
Canary / Control / Treatment
        ↓
GSC + GA4 + Crawl + GEO + Business
        ↓
Causal Evaluation
        ↓
Outcome
        ↓
Learning Controller
        ↓
Knowledge Candidate
        ↓
Evidence / Scope / Freshness / Conflict
        ↓
Knowledge Base
        ↓
Twin Calibration
        ↓
Agent Change Proposal
        ↓
Evaluation
        ↓
Shadow
        ↓
Canary Agent
        ↓
Policy Engine
        ↓
Orchestrator
        ↓
Controlled Production Action
        ↓
Monitoring
        ↓
Next Observation

75、存在两个 Canary，也存在两个 Rollback

Site Canary 回答页面修改安全吗；Agent Canary 回答新决策系统安全吗。

同样，Site Rollback 恢复 Content / Code / Template；Agent Rollback 恢复 agent_version、prompt_version、routing_version、knowledge_snapshot 与 policy_version。

76、Knowledge Snapshot

每个 Agent Release 都应该绑定 Knowledge Snapshot 与 Twin Version：

agent_version = 21.4
knowledge_snapshot = kb_20260913_2200
twin_version = twin_18.7

这样才能真正复现历史决策。

77、Autonomous Optimization 最终状态机

OBSERVED
↓
DIAGNOSED
↓
HYPOTHESIZED
↓
SIMULATED
↓
EXPERIMENT_DESIGNED
↓
CANARY
↓
EXPERIMENT_RUNNING
↓
CAUSAL_EVALUATED
↓
DECIDED
↓
ROLLED_OUT
↓
VERIFIED
↓
LEARNING_CANDIDATE
↓
KNOWLEDGE_VALIDATED
↓
TWIN_RECALIBRATED
↓
AGENT_EVALUATED
↓
LEARNED

78、失败状态也是 Safe Autonomy 的一部分

UNKNOWN
INCONCLUSIVE
CONFOUNDED
DATA_INVALID
POLICY_BLOCKED
HUMAN_REVIEW
ROLLBACK_REQUIRED
KNOWLEDGE_CONFLICT
EVAL_FAILED

这些状态不是异常，而是系统可靠性的组成部分。

79、真正的目标是 Better Decision Boundaries

Self-Improving SEO Agent 不追求永远自动执行，而追求越来越准确地判断：什么时候做、做什么、做到什么范围、什么时候等待、什么时候实验、什么时候停止、什么时候问人。

80、最终不是 SEO Auto Pilot，而是 Search Optimization Control System

Desired State
↓
Observe Current State
↓
Calculate Error
↓
Choose Intervention
↓
Apply Controlled Change
↓
Measure Response
↓
Recalibrate

控制系统最怕错误反馈、反馈延迟和过度纠正。Search Response 天然存在 Crawl Delay、Index Delay、Ranking Delay 与 Conversion Delay，因此系统必须设计 Threshold、Persistence、Cooldown 与 Hysteresis，避免每看到短期波动就反向调整。

81、更多自动化有时反而更危险

如果没有 Causal Reasoning、Confidence、Cooldown、Policy 和 Human Review，自动速度越快，错误传播也越快。因此成熟度不应该用 Automation Coverage = 100% 衡量，而应该看 Validated Autonomous Decision Rate。

82、推荐最终 KPI

Validated Autonomous Decisions
Causal Learning Rate
Prediction Calibration
Knowledge Reuse
Experiment Efficiency
Human Override
Incident Rate
Rollback Rate
Business Value
Cost per Validated Outcome

83、从 AI Assistant 到 Self-Calibrating Search Operating System

阶段1：AI Assistant
人给任务，AI回答

阶段2：SEO Agent
AI可以调用工具

阶段3：SEO Workflow
多个任务自动连接

阶段4：SEO Orchestrator
系统管理Agent、状态和权限

阶段5：Self-Calibrating Search Operating System
系统通过真实反馈改善未来决策

84、但系统始终需要治理

生产级系统必须持续存在 Policy、Permission、Evaluation、Audit、Human Governance 与 Rollback。真正困难的从来不是“能不能让模型调用工具”，而是怎样设计反馈、权限、证据与评测体系。

85、第二十一篇后的完整闭环

SEO Intelligence
↓
Research
↓
Fact Check
↓
Technical / Content / GEO Agents
↓
Measurement
↓
Publishing
↓
Monitoring
↓
Incident Response
↓
Knowledge Base
↓
Orchestrator
↓
Evaluation
↓
Experimentation
↓
Cost Engineering
↓
Security
↓
Search Data Platform
↓
Digital Twin
↓
Simulation Lab
↓
Experiment Engine
↓
Self-Improving Learning Controller

86、完整运行循环

RESEARCH
↓
UNDERSTAND
↓
HYPOTHESIZE
↓
SIMULATE
↓
EVALUATE
↓
EXPERIMENT
↓
EXECUTE
↓
OBSERVE
↓
INFER
↓
LEARN
↓
RECALIBRATE
↓
IMPROVE

87、最重要的一条公式

Self-Improvement 不能写成：

Outcome → New Rule

而必须是：

Outcome
+
Counterfactual
+
Evidence
+
Context
+
Evaluation
+
Governance
=
Learning Candidate

只有进一步通过 Validation，才能成为 Reusable Knowledge。

88、SEO Agent 最终学习的不是“排名技巧”

它真正要学习的是：哪些信号可信、哪些证据不足、哪些修改适用于什么场景、哪些风险容易被低估、哪些预测经常偏高、哪些实验需要更长时间、哪些任务应该自动、哪些任务应该让人决定。

这远比追逐“最新 SEO 技巧”更重要。

结语：真正会进步的 SEO Agent，不是会不断修改自己，而是会不断纠正自己

SEO 自动化最初追求自动抓数据、自动写内容、自动审核和自动发布；后来发展到自动诊断、自动监控、自动实验与自动回滚。进入 Self-Improving 阶段以后，真正重要的是：系统能不能认识到自己过去判断错了？

真正成熟的 Search Optimization System 必须完成：

Prediction
↓
Reality
↓
Error
↓
Learning
↓
Evaluation
↓
Calibration
↓
Better Prediction

Experiment 负责告诉系统现实发生了什么；Causal Inference 负责判断哪些变化可以合理归因于 Treatment；Knowledge Base 保存经过验证的经验；Digital Twin 吸收 Reality 并修正预测；Evaluation 防止系统越学越错；Policy Engine 限制系统能修改什么；Orchestrator 决定什么时候可以行动；Human Review 控制高风险边界；Learning Controller 则把反馈重新送回整个系统。

最终我们真正要建设的并不是一个“会自动做 SEO 的 AI Agent”，而是一个能够持续观察、实验、验证、纠错、自我校准，同时知道自己权限边界的 Search Optimization Operating System。

它真正成熟的标志不是“已经不需要人”，而是：越来越清楚哪些事情可以自己做，哪些事情需要实验，哪些事情应该等待，哪些事情必须让人决定。

官方依据与工程边界说明

本文的 Self-Calibrating Search Operating System、Learning Controller、三层 Learning Loop、Knowledge Risk Level、Agent Canary、Autonomy Promotion / Demotion、Knowledge Lineage 等架构属于本项目工程设计，并非 Google 或 OpenAI 官方定义。

• OpenAI Agents SDK — Tracing：https://openai.github.io/openai-agents-python/tracing/。用于记录 generations、tool calls、handoffs、guardrails 与 custom events，为 Decision Trace 与 Production Observability 提供工程基础。
• OpenAI Agents SDK — Human-in-the-loop：https://openai.github.io/openai-agents-python/human_in_the_loop/。为敏感工具调用审批、暂停与恢复执行提供现实 Runtime 模式。
• OpenAI Agents SDK — Guardrails：https://openai.github.io/openai-agents-python/guardrails/。为 Input / Output / Tool Guardrails 以及高风险工具前置检查提供工程参考。
• OpenAI Evals：https://developers.openai.com/api/reference/java/resources/evals/methods/create。用于定义评测数据、testing criteria 与 graders，支持 Candidate 与 Production 配置比较。
• Google Search Central — Website Testing：https://developers.google.com/search/docs/crawling-indexing/website-testing。网站实验需避免 cloaking；多 URL 测试可使用 canonical 表达首选版本；临时跳转使用 302；实验完成后及时清理。
• Google Search Central — Site Moves and Migrations：https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes。大型变更应做好测试、映射、监控与分阶段迁移，并尽量避免同时叠加多项重大变化。
• Google Search Status Dashboard：https://status.search.google.com/。用于识别 Search 系统事故与重要 Ranking Update，作为 Experiment 与 Learning 的外部环境上下文。
• Search Console Bulk Export：https://support.google.com/webmasters/answer/12918484?hl=en。可将 Search Performance 数据持续导入 BigQuery，作为 Experiment、Calibration 与长期 Learning Data Plane。