创见日期：2026年9月6日
前十三篇完成以后，我们已经拥有一套越来越接近生产系统的 SEO / GEO Automation Architecture：SEO Intelligence → Research → Fact Check → Technical SEO → Indexing Diagnosis → Measurement → Content Operations → GEO Research → Release Engineering → Monitoring → Incident Response → Knowledge Base → Learning Loop → Orchestrator。
到了这里，一个新的问题会变得越来越重要：我们怎么证明这些 Agent 真的可靠？
不是“这次回答看起来不错”，也不是“最新模型更聪明，所以应该没问题”。真正生产级系统必须能够回答：事实准确率是多少？会不会把行业观点写成 Google 官方结论？遇到信息不足时会不会正确停止？工具是否选对、参数是否正确？模型或 Prompt 升级以后有没有 Regression？
这就是第十四篇要建立的 Evaluation / Benchmark / Governance Layer。
一、最大的错误：把“模型能力”当成“系统可靠性”
Model Intelligence
≠
Agent ReliabilityAgent Reliability 更接近 Model + Prompt + Context + Knowledge + Tools + Routing + State + Policy + Infrastructure。任何一层变化都可能改变系统行为。
二、真正要评测的是整个 Agent System
OpenAI 当前 Agent Evaluation 文档已经把 Traces、Graders、Datasets、Eval Runs 作为评估 Agent 一致性与准确性的主要工具。Trace Grade 可以检查工具选择、Handoff、Workflow Policy Compliance，以及 Prompt / Routing 修改后的端到端行为变化。
三、SEO Agent Evaluation 至少分成九层
1. Task Understanding
2. Factuality
3. Evidence
4. Tool Use
5. Orchestration
6. Policy Compliance
7. Operational Reliability
8. Cost / Latency
9. Business Outcome四、Task Understanding
Agent 首先必须正确理解任务类型、范围和意图。例如“为什么这批 URL 没索引”应进入 Indexing Diagnosis，而不是直接给出“提交 Sitemap”的固定答案。
task_classification_accuracy
intent_accuracy
scope_understanding五、Factuality
Research / Content Agent 必须把 Claim 拆成 Supported、Unsupported、Contradicted、Unverifiable，并重点监控 Unsupported Claim Rate。
六、不要使用模糊的 Hallucination Rate
Fabricated Fact Rate
Unsupported Claim Rate
Wrong Attribution Rate
Stale Knowledge Use Rate
Inference Presented as Fact Rate这些比一个模糊的“幻觉率”更容易转化成工程改进。
七、Evidence Quality
结论正确并不代表证据质量正确。优先官方来源、判断来源新鲜度，并检查 Claim 与 Citation 是否真正匹配。
Source Authority
Source Relevance
Source Freshness
Claim-Source Alignment
Citation Completeness八、Source Attribution 本身也要评测
真实来源存在，不代表 Agent 可以扩大来源支持范围。例如官方只说明“eligible”，Agent 却写成“ranks higher”，属于 Citation Entailment Failure。
九、Tool Selection
Agent 动态选择工具增加了新的不确定性，因此必须独立评估 Tool Selection 和 Tool Argument Precision。
十、Tool Argument Accuracy 更危险
选择 update_post() 没错，但如果 post_id 从 128 变成 182，就是生产事故。因此 Tool Selection Accuracy 与 Tool Argument Accuracy 必须分开。
十一、Tool Eval 尽量使用确定性判断
expected_tool 与 actual_tool、expected_slug 与 actual_slug 可以直接代码比较。可以确定性验证的事情，不应优先交给 Model Grader。
十二、Orchestration Eval
评测路由、State Transition、Handoff、Dependency 是否正确。例如 FACT_CHECK = FAIL 时必须进入 RELEASE_BLOCKED。
十三、Trace Eval 比只看 Final Answer 更适合 Agent 系统
OpenAI Trace Grading 能对整个 Trace——模型调用、Tool Call、Handoff、Guardrail——进行结构化评分，从而判断 Agent 最终答对时是否走了错误路径。
十四、SEO Agent 尤其需要 Trace Eval
“页面存在 Canonical 冲突”可能来自猜测，也可能来自 Fetch HTML → Rendered HTML → Canonical → GSC → Diagnosis。最终文字相似，可靠性完全不同。
十五、Policy Compliance
对于生产 Agent，这一层甚至高于语言质量。CRITICAL → BLOCK，如果 Agent 仍执行 robots update，则必须判 FAIL。
十六、Policy Eval 必须设置 Hard Gate
secret_exposure
high_risk_without_approval
publish_without_fact_check
bulk_change_over_scope
incident_freeze_violation任何一个发生，都不能被平均分掩盖。
十七、Agent Eval 不能只用 Average Score
Writing、Research、Tool Use 很高，但 Policy 很低，仍然不能上线生产写权限。必须设计 Hard Gates + Weighted Scores。
十八、项目内部 Reliability Score
Reliability Score =
0.20 Factuality
+ 0.15 Evidence
+ 0.15 Tool Accuracy
+ 0.15 Orchestration
+ 0.20 Policy Compliance
+ 0.10 Operational Reliability
+ 0.05 Cost / Latency这是项目内部质量模型，不是行业标准；Critical Failure 出现时，即使总分 99 仍然 FAIL。
十九、哪些算 Critical Failure
虚构 Google 官方结论
未核验却标记 FACT
未经批准执行 HIGH/CRITICAL 变更
错误修改生产目标
意外扩大批量 Scope
暴露 Secret
Incident Freeze 期间继续生产变更
WordPress 未验证却宣称发布成功
Rollback 失败却标记 RESOLVED二十、Operational Reliability
Timeout Rate
Tool Error Rate
Retry Success
Duplicate Execution
Idempotency
State Recovery
Queue Recovery二十一、WordPress 443/522 事故应进入 Golden Dataset
刚刚真实发生的案例是：GitHub Runner → WordPress 出现 Connect Timeout :443；Cloudflare Worker → WordPress 返回 522。正确 Agent 行为不是继续无限重试，更不能宣称已上线，而是：
Detect External Dependency Failure
↓
Do Not Claim Published
↓
Do Not Alter Content
↓
Bound Retry
↓
Cross-check Alternate Network Path
↓
Confirm Origin Incident
↓
Stop Repeating
↓
Preserve Release Candidate
↓
Retry After Recovery
↓
Verify WordPress JSON二十二、这个 Case 比 100 个简单 SEO 问答更有价值
因为它同时测试 Tool Use、Failure Classification、Retry Policy、Truthfulness、Release State、Incident Reasoning、Idempotency 与 Verification。
二十三、Golden Dataset 到底是什么
Golden Dataset 不是“100 个问题 + 100 个漂亮答案”，而是一组经过人工确认的 Representative Cases + Expected Behavior + Expected Boundaries。
二十四、统一 Eval Case Schema
eval_case_id
task_type
scenario
input
context
risk_level
expected_state
expected_agent
expected_tools
allowed_actions
forbidden_actions
expected_evidence
expected_output
expected_decision
hard_fail_conditions
grader_type
created_at
verified_at二十五、SEO Golden Dataset 至少覆盖八类 Case
NORMAL_CASE
EDGE_CASE
AMBIGUOUS_CASE
ADVERSARIAL_CASE
INCIDENT_CASE
NO_ACTION_CASE
ESCALATION_CASE
REGRESSION_CASE二十六、Typical、Edge、Adversarial 都必须有
OpenAI 当前 Evaluation Best Practices 建议 Eval Dataset 覆盖典型、边缘和对抗性案例，并让领域专家参与标注，同时尽量反映真实生产分布。
二十七、Production Logs 是 Eval Dataset 的重要来源
生产日志会暴露真正值得加入 Eval 的新 Case，因此 Trace、Incident、Human Override 都应该进入 Case Mining。
二十八、自动 Case Mining 流程
Production Trace
↓
Failure / Override / Incident
↓
Human Review
↓
Root Cause
↓
Create Eval Case
↓
Add to Regression Suite二十九、Eval Dataset 应持续增长，但重点不是数量
真正重要的是是否覆盖高风险、高频、容易误判的生产场景。
三十、数据来源应多样化
Expert-curated Cases
Historical Incidents
Production Traces
Synthetic Edge Cases
Adversarial Cases
Known SEO Failure Patterns三十一、必须保留 Holdout Set
DEV SET
REGRESSION SET
HOLDOUT SET三者分开，避免 Prompt 对 Eval Set 过拟合。
三十二、监控 Eval Leakage
如果 Prompt、Knowledge Base 或 Agent 可以通过 Case ID 找到 Golden Label，那么 Eval Score 已经失效。
三十三、Ground Truth 不总是 Exact String
SEO 很多任务存在多个合理结论，因此更适合定义 Required Elements、Allowed Decisions、Forbidden Decisions、Required Evidence。
三十四、Canonical Diagnosis 的 Behavioral Ground Truth
Must Inspect:
Declared Canonical
Must Distinguish:
Google-selected Canonical
Must Not:
Claim root cause without evidence
Acceptable Final States:
CANONICAL_CONFLICT
DUPLICATE_CLUSTER
INSUFFICIENT_EVIDENCE三十五、Grader 应有层级
1. Deterministic Grader
2. Reference Grader
3. Model Grader
4. Human Expert三十六、Model Grader 的适用范围
清晰度、是否把推测写成事实、推荐合理性等很难简单字符串判断的问题适合 Model Grader，但 Model Grader 本身必须用高质量 Human Labels 校准。
三十七、Model Grader 也会犯错
Agent
↓
Model Grader
↓
Calibration
↓
Human Benchmark三十八、防止 Grader Hacking
自动评分可能被模型“投机”，因此必须周期性与 Expert Human Evaluation 对齐。
三十九、Human-Grader Agreement
可以内部监控 grader_human_agreement。若长期显著下降，说明 Grader 自身需要重构。
四十、评价输出时优先 Classification / Pairwise / Criteria Scoring
不要问“你觉得这篇 SEO 文章怎么样”，而要问：是否存在 Unsupported Google Claim？A/B 哪个更 Evidence-grounded？Evidence Discipline 0–4。
四十一、Model Upgrade 绝不能只跑 Smoke Test
Model A → Model B 必须跑 Full Regression Suite，因为新模型可能 Research 提高，但 Tool Calling 或 Escalation 下降。
四十二、Prompt Change 也应该算 Release
Prompt、Tool Definition、Knowledge Retrieval、Routing、Policy、Model 任一变化都可能改变行为。
四十三、Agent Version 由多个组件组成
agent_version
model
prompt
tools
knowledge_policy
routing
policy四十四、Agent Change Manifest
change_id
agent
before_version
after_version
changed_model
changed_prompt
changed_tools
changed_policy
reason
owner
eval_run
result
approved_by
deployed_at四十五、真正上线流程
CHANGE
↓
Eval Dataset
↓
Regression
↓
Hard Gates
↓
Benchmark Compare
↓
Approval
↓
Shadow
↓
Canary
↓
Production
↓
Continuous Eval四十六、Benchmark 一定要有 Baseline
Candidate 总分只提高 0.7 并不够，还应拆解 Factuality、Tool Accuracy、Policy、Cost、Latency 等变化。
四十七、Benchmark 应比较 Capability Vector
Factuality
Evidence
Tool Selection
Tool Arguments
Routing
Policy
Escalation
Latency
Cost四十八、不同 Agent 使用不同 Eval
Research 看 Source Quality、Claim Support、Freshness；Technical 看 Diagnosis Precision、False Positive、Evidence Completeness；Content 看 Intent Alignment、Original Value、Factuality；Monitoring 看 Alert Precision、Incident Recall；Publisher 看 Target Accuracy、Idempotency、Verification、Scope Compliance。
四十九、Orchestrator Eval 更关注 Routing
routing_accuracy
handoff_accuracy
state_transition_accuracy
dependency_compliance
stop_decision_accuracy五十、优秀 Agent 还要会“不做”
没有足够数据时返回 INSUFFICIENT_EVIDENCE，比硬生成 Root Cause 更优秀。
五十一、No-Action Accuracy
Healthy System → NO_ACTION 必须被正式测试，避免系统为了证明自己“主动”而不断过度优化。
五十二、Offline Eval 不等于 Production Reliability
真实生产环境还包含 API 变化、缓存、网络、权限、WordPress、GSC 等不确定性。
五十三、因此需要 Shadow Evaluation
Candidate Agent 接收真实生产任务副本，但 NO PRODUCTION WRITE；可以研究、诊断、提出 Action，再与 Production Agent 比较。
五十四、Shadow 特别适合高风险 Agent
Technical Agent 新版本可以连续两周分析真实问题但不修改网站，比较 Production Decision 与 Shadow Decision。
五十五、接下来才进入 Canary
New Agent
↓
5% LOW_RISK Tasks
↓
Observe
↓
20%
↓
Observe
↓
100%Google SRE 的 Canary 思维同样适用于 Agent 权限逐步放量。
五十六、Canary 不只看有没有报错
还应观察 Task Success、Fact Check、Human Override、Cost、Latency、Content Acceptance 等。
五十七、生产环境必须 Continuous Evaluation
Eval 不是上线前的一次考试，而是每次变更后持续运行，并不断把新的 Production Failure 扩充进 Eval Set。
五十八、Production Eval 可以抽样
100% deterministic checks
10% model grading
2% human review比例按风险调整。
五十九、高风险 Action 应 100% Audit
Canonical、robots、Bulk URL Action、Production Publish 应保存完整 Trace。
六十、需要检测 Agent Drift
即使 Model / Prompt / Tools 不变，Knowledge Base、输入分布和外部 API 变化仍可能造成行为漂移。
六十一、Task Distribution 也会造成 Drift
过去 70% 是 Content，后来 70% 变成 GEO Research，旧总体成功率就不再代表当前能力。
六十二、不能只用最新数据
Stable Core Regression Set
+
Current Production Distribution
+
Recent Incidents六十三、Evaluation Pyramid
Deterministic Unit Eval
↓
Workflow / Trace Eval
↓
End-to-End Production Eval
↓
Human Expert Evaluation六十四、生成式 AI 评测不能完全照搬传统软件测试
因为相同输入可能得到不同输出，所以需要 Software Tests + AI Evals 两套体系。
六十五、确定性代码仍用 Unit Test
Risk Mapping、State Transition、Slug Matching、Scope Limit 不需要 LLM Eval。
六十六、不确定性行为才使用 Eval
Diagnosis Quality、Source Selection、Research Judgment、Escalation 才属于 Agent Eval。
六十七、Governance 从这里开始
Evaluation 回答“Agent 表现怎么样”；Governance 回答“谁决定这个表现是否足够好到可以拥有某种权限”。
六十八、NIST AI RMF 可作为治理参考
GOVERN
MAP
MEASURE
MANAGE它适合作为风险治理思想参考，而不是 SEO Agent 的强制行业标准。
六十九、映射到 SEO Agent
GOVERN → 谁有权做什么？
MAP → 这个 Agent 会带来哪些风险？
MEASURE → 风险如何测试？
MANAGE → 不达标怎么办？七十、每一个 Agent 应有 Owner
Agent
Owner
Production Approver
Risk Tier
Autonomy七十一、需要 Agent Registry
agent_id
purpose
owner
version
model
tools
data_access
write_access
risk_class
autonomy_level
eval_suite
latest_eval_score
hard_gate_status
production_status七十二、Agent 上线必须有 Minimum Acceptance Criteria
不同 Agent 不能统一“80分及格”。Research Agent 可以要求 Unsupported Claim < 2%；Publisher 则可能要求 Target Accuracy = 100%、Scope Compliance = 100%、False Publish Success = 0。
七十三、风险越高，Threshold 越严格
CRITICAL Action 不能只看总体百分比，而应要求 0 Critical Failures。
七十四、Governance 必须控制 Autonomy Upgrade
L2 → L3 requires:
Regression PASS
Production Shadow PASS
100 Canary Actions
0 Critical Failures
Human Override < threshold
Owner Approval七十五、Autonomy 也必须可以降级
如果出现多次 Policy Violation，应允许 L3 → L2，甚至 READ_ONLY。
七十六、每一次 Incident 都应该影响 Eval 和 Governance
Incident
↓
New Golden Case
↓
New Regression Test
↓
New Policy七十七、如果 Eval 覆盖不到真实事故，说明 Dataset 不够好
WordPress 522 事故之前，如果 Dataset 只有 Happy Path Publishing，Publisher 可能“100% PASS”。因此必须新增 WP_ORIGIN_UNREACHABLE。
七十八、每个事故都问一个固定问题
Which missing eval allowed this incident?
七十九、Agent 发布本身也应该有 Eval Gate
Agent Change
↓
Static Tests
↓
Golden Dataset
↓
Regression
↓
Trace Eval
↓
Policy Gate
↓
Shadow
↓
Canary
↓
Production八十、不要把 Eval 绑定死在某个平台产品上
长期架构应围绕 Eval Concepts、Dataset Schema、Graders、Regression、Trace 建设，而不是依赖单一产品界面或会变化的旧接口。
八十一、Evaluation Infrastructure 本身也必须版本化
eval_suite_version
dataset_version
grader_version
threshold_version八十二、不同 Eval 版本的分数不能直接比较
今天新增 20 个困难 Incident Cases 后总分下降，并不一定说明 Agent 变差。因此每个 Score 必须带 eval_suite_version。
八十三、Benchmark 保存完整 Run Manifest
eval_run_id
agent_version
model_version
dataset_version
grader_version
started_at
total_cases
passed
failed
critical_failures
metrics
cost
latency
decision八十四、Evaluation 结果也应该进入 Knowledge Base
这样 Orchestrator 能知道某 Agent 在哪些任务上风险较高。
八十五、Orchestrator 可以根据 Eval 动态 Routing
Technical SEO 表现高的 Agent 不一定适合 Content。应该按被验证的能力路由。
八十六、这就是 Capability-Based Routing
Which agent is validated for this task?
而不是“哪个模型最新”。
八十七、Cost 也必须进入 Eval
质量 +1%，成本 +500%，是否值得是 Business Decision。建议关注 cost_per_validated_task。
八十八、Latency 同样重要
Daily Monitoring 与 Incident Agent 应有不同 Latency Budget。
八十九、Quality / Cost / Latency 一起比较
| Version | Quality | Cost | Latency |
|---|---|---|---|
| A | 94 | 1.0x | 1.0x |
| B | 96 | 2.8x | 2.2x |
| C | 93 | 0.3x | 0.5x |
九十、Production Agent 不一定永远用最强模型
Classifier 可使用成本更低的模型，复杂 Root Cause Research 再调用更强模型，只要 Eval 证明可靠。
九十一、Evaluation 是 Cost Routing 的基础
有了 Eval 才能找到“最低成本满足质量阈值的模型”。
九十二、SEO Agent Quality Dashboard
Eval Pass Rate
Critical Failures
Fact Support
Tool Accuracy
Routing Accuracy
Policy Compliance
Human Override
Regression
Production Incident
Cost per Valid Task九十三、Weekly Agent Quality Review
关注新 Failure、Regression、哪些 Agent 需要降级、哪些 Case 应加入 Golden Dataset，以及 Grader / Human Agreement 是否下降。
九十四、Monthly Governance Review
决定哪些 Agent 可以提高 Autonomy、哪些 Tool 权限应缩减、哪些 Policy 不够严格、哪些 Agent 可以合并或删除。
九十五、删除 Agent 也是成熟度
Multi-Agent 会增加新的不确定性，复杂架构必须通过 Eval 证明自己值得存在。
九十六、Evaluation 应该决定 Architecture
如果 Multi-Agent 只比 Single Agent 提升 0.5%，但 Cost ×3、Latency ×2、Failure Surface ×2，可能根本不值得。
九十七、复杂架构必须通过 Eval 证明价值
新增 Agent、Tool、Workflow、Memory、Routing，都应该回答：它是否带来可测量的改进？
九十八、Evaluation 最终是对自治权的证据
Agent 能不能自动发布、自动修复、自动修改 Technical SEO，不应取决于“团队觉得它很强”，而应取决于 Eval Evidence。
九十九、真正的 Agent Governance
Capability
↓
Evaluation
↓
Evidence
↓
Risk
↓
Permission
↓
Autonomy一百、完整 Agent Quality Loop
PRODUCTION
↓
TRACE
↓
EVAL
↓
FAILURE DISCOVERY
↓
ROOT CAUSE
↓
NEW GOLDEN CASE
↓
IMPROVEMENT
↓
REGRESSION
↓
SHADOW
↓
CANARY
↓
RELEASE
↓
PRODUCTION一百零一、整个体系形成完整工程闭环
SEO Intelligence
↓
Research
↓
Fact Check
↓
Technical SEO
↓
Indexing
↓
Measurement
↓
Content
↓
GEO
↓
Release
↓
Monitoring
↓
Incident
↓
Knowledge
↓
Learning
↓
Orchestrator
↓
Evaluation
↓
Governance系统不只会执行，也开始会证明自己是否值得继续执行。
结语：Agent Reliability 不是一种感觉
真正可靠的 SEO Agent，不是那个答对一次问题的 Agent，而是经过大量已知、未知、边缘、失败和真实生产场景以后，仍然能够保持正确边界的系统。
Agent Reliability 不是一种感觉，而是一组可以重复运行、持续比较、被生产事故不断修正的证据。
只有当 Capability 通过 Evaluation 形成 Evidence，并通过 Governance 转换成 Production Permission，我们才能说它不再只是一个聪明 Demo，而是一个可以被信任的生产系统。