创见日期：2026年9月15日
第二十二篇完成 Multi-Agent Coordination / Organizational Architecture 以后，我们已经解决了一个非常重要的问题：当 Research、Technical、Content、GEO、Experiment、Evaluation、Security、Publisher 等 Agent 同时存在时，谁负责什么，谁能做什么，以及怎样避免相互冲突。
但组织关系清晰，并不意味着系统已经可以稳定运行。一个架构设计非常漂亮的 Multi-Agent System，仍然可能因为 OpenAI API latency 上升、Search API rate limit、GSC 数据延迟、Crawler 过载、WordPress timeout、GitHub workflow queue、数据库锁、Agent retry storm、Context explosion、Experiment backlog 或 Publisher congestion 突然进入半失效状态。
任务还在运行
↓
队列越来越长
↓
Agent 开始超时
↓
自动 Retry 增加
↓
API 调用更多
↓
Latency 继续上升
↓
更多任务超时
↓
更多 Retry最终形成的不是一个普通错误，而是 Agent Cascading Failure。
所以，当 SEO / GEO 自动化进入多 Agent 阶段以后，下一步不能只是继续增加能力，而必须建立 Agent Reliability Engineering。它要回答：系统有多可靠？怎样衡量可靠？允许失败多少？什么时候降级？什么时候停止接单？什么时候熔断？一个 Agent 坏掉会不会拖垮整个系统？外部 API 失效以后怎样继续工作？数据丢失以后多久恢复？
最终目标，是把 Multi-Agent Organization 升级为 Production-Grade Search Reliability System。
1、Agent Reliability 不是 API Uptime
传统系统中，我们很容易用 HTTP 200 Rate、Availability、Latency 衡量可靠性。但 Agent 系统不同。
假设 Research Agent 请求成功、模型正常返回，却引用了过期来源、遗漏 Google 官方文档，或者把推断写成事实。技术上属于 Request Success，业务上仍然属于 Task Failure。
Publisher Agent 更典型：WordPress 返回 HTTP 200，但文章仍然是 Draft、Slug 错误、发布内容和 Approved Artifact 不一致，都不能叫 Reliable Publish。
因此，本项目把 Agent Reliability 定义为：系统能否在规定的时间、权限和质量边界内完成用户真正要求完成的任务。
Correct
+
Complete
+
Timely
+
Safe
+
Verified
=
Reliable Agent Outcome2、SRE 为什么适用于 Agent System
Google SRE 将 SLI 定义为服务水平的定量指标，将 SLO 定义为这些指标的目标值或目标范围，并强调 SLO 应从用户真正关心什么开始，而不是从什么最容易测量开始。
这对 Agent 系统尤其重要。最容易测量的是 API latency、token usage、HTTP error，但用户真正关心的是：任务有没有正确完成？
所以第一个 Reliability 原则是：Measure User-Visible Outcome，而不是 Measure Model Availability Only。
3、建立 Agent Reliability Stack
建议把 Agent Reliability 分成七层：
L1 Infrastructure Reliability
L2 Dependency Reliability
L3 Agent Runtime Reliability
L4 Workflow Reliability
L5 Decision Reliability
L6 Side-Effect Reliability
L7 Business Outcome ReliabilityL1：Infrastructure Reliability
包括 Compute、Network、Queue、Database、Storage、Runner、Scheduler，回答“系统还能不能运行”。
L2：Dependency Reliability
包括 OpenAI API、Google Search、Search Console、GA4、Crawler、GitHub、WordPress、Cloudflare 以及其他第三方 API，回答“Agent 依赖的外部系统是否可用”。
L3：Agent Runtime Reliability
包括 Agent Timeout Rate、Tool Failure Rate、Model Error Rate、Retry Rate、Invalid Structured Output、Context Overflow。
L4：Workflow Reliability
包括 Task Completion、Handoff Success、State Transition、Deadlock、Duplicate Execution、Queue Delay。
L5：Decision Reliability
包括 Correct Diagnosis、Correct Routing、Correct Abstention、Policy Compliance、Evidence Completeness。
L6：Side-Effect Reliability
包括 Publish Correct Artifact、Git Merge Correct Commit、No Duplicate Publish、Rollback Works、Write Lock Honored。
L7：Business Outcome Reliability
最终回答任务是否真正产生预期的 SEO、GEO、Lead、Revenue 与 Risk outcome。
4、Agent SLI 不能只看一个指标
对于 SEO Agent Platform，建议至少建立八组 SLI。
SLI 1：Task Success Rate
Task Success Rate 可以写成 Successful Tasks / Eligible Tasks，但 Successful Task 必须严格定义。
Research Task 不能仅仅定义成“Agent returned output”，而应该满足 Required Sources Found、Evidence Schema Valid、Freshness Satisfied、Fact Check Passed、No Unresolved Critical Uncertainty。
Publisher Task 则应该满足：
Approved Artifact Received
↓
Publish Request Sent
↓
CMS Returned Valid Object
↓
status = publish
↓
Final URL Exists
↓
Published Artifact Verified所以不同 Agent 必须拥有不同 SLI：Research 看 Evidence Success，Technical 看 Diagnosis Accuracy，Experiment 看 Experiment Integrity，Publisher 看 Verified Publish Success，Orchestrator 看 Workflow Completion。
SLI 2：Good Outcome Rate
仅仅完成任务还不够。100 个 Content Task 都运行结束，其中 20 篇 Fact Check 失败，Task Completion 仍然不能代表可靠性。
更合理的是定义 Good Event：
Task Completed
AND
Quality Gate Passed
AND
Policy Passed
AND
No Critical IncidentSLI 3：End-to-End Latency
Agent latency 不应该只看 LLM Response Time，而应该看从 Task Created 到 Queued、Assigned、Executed、Reviewed、Approved、Verified 的总耗时。
一个模型可能只运行 30 秒，但 Task 在队列里等了 45 分钟。用户感受到的延迟是 45 分 30 秒，而不是 30 秒。
因此 Latency 应进一步拆解为 Queue Latency、Agent Runtime、Tool Latency、Dependency Latency、Approval Latency、Verification Latency。
SLI 4：Freshness
SEO Intelligence 的价值高度依赖时效。需要监控 Update Detection Delay、Evidence Freshness、GSC Data Age、Crawler Snapshot Age。
SLI 5：Correctness
Correctness 来自 Evaluation、Golden Dataset、Human Review、Production Outcome，例如 Diagnosis Precision、False Positive、False Negative、Routing Accuracy、Abstention Accuracy。
SLI 6：Safety
包括 Unauthorized Write Rate、Policy Violation、Experiment Contamination、Wrong Resource Modified、Duplicate Publish。这类目标通常应该非常接近 0。
SLI 7：Recoverability
不是问“会不会失败”，而是问“失败以后多久恢复”。可以跟踪 Mean Time to Detect、Mean Time to Mitigate、Mean Time to Recover、Rollback Success Rate。
SLI 8：Observability Completeness
如果任务失败后没有 trace、task_id、tool log、error class，本身就是 Reliability Failure。无法诊断的系统无法可靠运营。
OpenAI Agents SDK 的 tracing 可以记录 Agent runs、generations、tool calls、handoffs、guardrails 和 custom events，因此可以建立 Trace Coverage SLI：
Completed Production Tasks with Full Trace
÷
All Production Tasks5、定义 SLO：不是所有 Agent 都应该一样
Google SRE 强调，100% Reliability 通常既不现实，也不理想。过度追求 100% 会带来巨大成本，并压缩正常创新空间。
Agent 系统也不应该给所有角色同样 SLO。Daily Research 的 99.0% 也许足够，但生产 Redirect Deployment 的 99.0% 可能远远不够。
建议按 Risk Class 定义：
- R0 Informational：Research、Report、Internal Analysis。
- R1 Low-risk Automation：Monitoring、Classification、Content Draft。
- R2 Production Content：WordPress Publish、Content Update。
- R3 Search Infrastructure：Canonical、Redirect、Robots、Migration。
项目内部示例 SLO Matrix：
| Capability | Success SLO | Latency SLO | Safety |
|---|---|---|---|
| Research | 98% | 95% < 10 min | High |
| GSC Analysis | 99% | 95% < 15 min | High |
| Content Draft | 98% | 95% < 20 min | High |
| Publish | 99.9% | 99% < 10 min | Very High |
| Rollback | 99.99% | 99% < 5 min | Critical |
| Production Policy | 99.99% | N/A | Critical |
这些数字只是项目内部设计示例，不是行业标准。
6、Error Budget：让可靠性真正影响决策
如果 SLO 是 99.9%，Error Budget 就是 0.1%。Error Budget 的意义，是在 Reliability 与 Change Velocity 之间建立客观控制机制。
例如 Content Automation SLO = 99%，一个月处理 1000 个任务，则理论上允许 10 个 bad tasks。如果已经发生 9 次 Failure，系统不应该继续快速增加 Agent 自主权，而应该 Reduce Change、Increase Review、Investigate Reliability。
如果 Error Budget 被快速消耗，自动进入 RELIABILITY_MODE：
Autonomy ↓
Human Review ↑
New Feature Rollout ↓
High-risk Experiment PauseSLO 只有在违反时真的会改变发布、实验和自治策略，才不是一张装饰性报表。
7、Burn Rate：不要等月底才知道预算耗尽
系统需要监控 Error Budget Burn Rate。如果一个月允许 1% Failure，但 1 小时内已经消耗了 20% 的月度预算，说明系统已经出现严重异常。
此时 Reliability Incident 的优先级应该高于普通 Content Production。
8、Capacity Engineering：Agent 系统一样会排队和拥塞
定义两个基本变量：Arrival Rate，即每分钟进入多少任务；Service Rate，即每分钟能够完成多少任务。
If Arrival Rate > Service Rate for long enough
then Queue → ∞因此至少要监控 Queue Depth、Oldest Task Age、Arrival Rate、Completion Rate、Worker Utilization。
Queue Depth 单独并不够。Queue = 500，但每秒处理 100 个，不严重；Queue = 50，但每小时只处理 1 个，则已经严重失效。Oldest Task Age 还能直接反映是否发生 Starvation。
9、Workload Class 与 Priority Lane
建议至少把负载拆成：
INTERACTIVE
PRODUCTION_WRITE
MONITORING
EXPERIMENT
BATCH
BACKGROUND不同队列不能完全混用。10,000 个批量页面 Crawl Task 不应该阻塞 Critical Rollback。
可以设置 P0 Incident、P1 Production、P2 Monitoring、P3 Experiment、P4 Batch 等 Priority Lane。批量工作再大，也不能拖垮 Production Recovery。
10、容量不要设计到 100% Utilization
100% Utilization 意味着没有 Burst Capacity、Failure Capacity、Recovery Capacity。应保留 Headroom，例如正常利用率控制在 60%–70% 区间，把剩余能力留给 Burst、Failover、Retry 和 Incident。具体比例必须通过真实负载测试确定。
Google SRE 对容量管理的核心提醒是：Capacity Planning 必须和 Load Testing 结合，仅做容量规划仍不足以避免 Cascading Failure。系统必须真正知道 Breaking Point 在哪里，以及超过临界点后会以什么方式失败。
11、Test Until Failure：知道系统真正的临界点
可以逐级测试 10、50、100、200、500、1000 concurrent tasks，并观测 Latency、Queue、Error、Retry、Cost、Timeout、Memory、Tool Failure。
真正重要的是知道系统何时从“越来越慢”切换成“全面崩溃”。这才是 Capacity Engineering 的核心。
12、Backpressure：下游承受不了时，上游必须减速
当上游产生任务的速度超过下游处理能力时，系统必须反馈 Slow Down，而不是 Keep Sending。
Backpressure 可以通过 Throttle、Queue、Reject、Defer、Batch 实现。
例如 SEO Intelligence 一次发现 50,000 anomalies，不能立即生成 50,000 个 Research Task。应该先：
Deduplicate
↓
Cluster
↓
Severity
↓
Sample
↓
Priority最后可能只有 120 个 investigation 真正需要执行。
13、Admission Control
在任务进入系统前先问：系统现在还能承受这个任务吗？
如果 Queue Saturation > 90%，低优先级任务可以直接 DEFER，而不是无限增长。
14、Load Shedding：过载时主动舍弃低价值负载
与其让所有任务一起慢死，不如明确放弃低价值任务。SEO Agent 的 Load Shedding 可以暂停 Historical Refresh、Low-priority Crawl、Optional GEO Sampling、Batch Rewriting，保留 Incident Detection、Critical Monitoring、Rollback、Security、Production Verification。
15、Graceful Degradation：不是少做，而是降低执行成本
Research Agent 正常模式可能是 10 Sources + Web Search + Cross-check + Fact Check + Strong Model。降级模式可以变成 Official Sources Only、Reduced Search Depth、Smaller Model for Classification、No Optional Competitive Research。
Content Agent 正常模式是 Full Rewrite + GEO + Fact Check + Internal Link，降级模式则可以只产生 Draft，禁止自动 Publish。
但 Publisher、Canonical、Redirect、Robots 等生产动作不应该“降低质量继续执行”，而应该 Fail Closed。
因此每个 Capability 应明确标记：
DEGRADE_ALLOWED
FAIL_CLOSED
FAIL_OPEN16、Retry：最容易把局部错误放大成事故
失败后 Retry 看起来合理，但如果每个 Agent、每个 Tool、每一层都独立重试，就会形成 Retry Storm。
Small Error
↓
More Retries
↓
More Traffic
↓
System Overload
↓
More Failures
↓
More Retries所以 Retry 应由统一 Reliability Controller 管理，而不是让每个 Agent 自己无限决定。
17、Retry Policy
至少需要定义：
Retryable?
Max Attempts
Backoff
Jitter
Retry Budget
Timeout适合 Retry 的通常包括 429、502、503、504、Network Timeout、Temporary Overload。Authentication Failure、Permission Denied、Policy Block、Malformed Request、Invalid Schema、Human Rejection 通常不应该自动 Retry。
OpenAI Agents SDK 当前的模型重试需要显式配置，可以针对 timeout、network error、Retry-After，以及 408、409、429、500、502、503、504 等状态设置策略，并支持指数退避和 jitter。
18、Replay Safety：产生副作用以后不能盲目重放
如果请求已经产生 Publish、Delete、Merge 等 Side Effect，就不能简单 Retry。
例如 WordPress POST 超时，并不能说明 Publish Failed，可能只是 Publish succeeded but response lost。
正确流程应该是：
Timeout
↓
Check Existing Resource
↓
Verify Idempotency Key / Slug
↓
Decide Whether Retry而不是 Timeout 后直接 POST Again。
19、Retry Budget
可以同时限制 retry_budget_per_task、retry_budget_per_agent、retry_budget_global。
例如 Task max retry = 3，System retry ratio 不高于正常流量的某个阈值。超过以后应该停止重试并进入 Degraded / Incident 状态，而不是继续制造压力。
20、Circuit Breaker：Dependency 已经失败时，不要继续撞墙
经典状态：
CLOSED
↓
OPEN
↓
HALF_OPEN
↓
CLOSEDCLOSED 正常调用；当 Failure Rate 超过阈值后进入 OPEN，停止继续调用；等待一段时间以后进入 HALF_OPEN，只放少量 Probe；成功再 CLOSED，失败继续 OPEN。
SEO Agent 中至少 OpenAI API、Google API、Crawler、WordPress、GitHub 和外部 GEO API 都可以有独立 Circuit Breaker。
Retry 是单个 Task 重新尝试，Circuit Breaker 是整个系统暂时停止访问故障 Dependency，两者不能混淆。
21、Failure Domain：一个组件失败不应自动拖垮整个系统
建议至少建立五类 Failure Domain：
Agent Domain
Tool Domain
Dependency Domain
Workflow Domain
Production DomainGEO Agent 故障应该影响 GEO Monitoring，但不应该影响 WordPress Rollback；Crawler 故障应该影响 Technical Crawl，但不应该导致 Security Agent Offline；Publisher 故障应该阻止 New Publish，但仍然允许 Monitoring、Research、Diagnostics。
22、Bulkhead：Worker Pool 也要隔离
建议拆成 Research Worker Pool、Analytics Worker Pool、Content Worker Pool、Publisher Worker Pool、Incident Worker Pool。
不要让 500 个 Research Task 耗尽全部 worker，以至于 Emergency Rollback 无法运行。Critical Capacity 必须预留给 Incident、Rollback、Security。
23、External Dependency Failure
SEO Operating System 大量能力依赖第三方，因此必须接受外部系统一定会失败。
Google Search Status Dashboard 会公开 Search 系统信息、中断、故障和 Ranking Update。这意味着内部 Monitoring Agent 看到异常时，不应该立即得出“我们的网站失败”结论。
如果 Google Search 出现广泛 Incident，系统可以进入：
EXTERNAL_DEPENDENCY_INCIDENT
↓
Freeze Causal Learning
Pause Aggressive Optimization
Increase Observation24、Dependency Health Registry
建议维护：
dependency
status
latency
error_rate
last_success
circuit_state例如：
GSC: DEGRADED
WordPress: HEALTHY
OpenAI: HEALTHY
Crawler: SATURATEDOrchestrator 再根据 Registry 做 Routing 和 Scheduling。
25、Agent Reliability 的五个核心监控信号
经典 Reliability 监控可以映射为 Latency、Traffic、Errors、Saturation。Agent System 还需要增加 Quality。
- Latency：任务多久完成。
- Traffic：多少 task、tool call、request 进入。
- Errors：多少调用或任务失败。
- Saturation：Queue、Worker、Token Budget、API Quota 是否接近极限。
- Quality：即使技术完成，结果质量是否退化。
26、Semantic Reliability Incident
有时模型服务没有宕机，但 Tool accuracy、Evidence accuracy 持续下降，Structured output errors 上升。这属于 Semantic Reliability Incident。
因此 Alert 不应只看 HTTP Error，还要看 Evaluation Failure、Human Override、Unexpected Abstention、Fact Check Failure、Policy Failure。
27、Tracing 是故障定位的基础
OpenAI Agents SDK tracing 可以记录 Agent、Generation、Function Tool、Guardrail、Handoff、Custom Span。
建议统一 Trace Metadata：
job_id
task_id
agent_id
agent_version
capability
risk_class
release_id
experiment_id
dependency发生 Incident 时需要能回答：Failure 从哪个 Span 开始，而不是笼统说“Agent 失败了”。
28、Timeout 必须分层
不要用一个 global_timeout 覆盖全部系统，应分别定义 Model Attempt Timeout、Tool Timeout、Task Timeout、Workflow Timeout、Approval Timeout。
OpenAI Agents SDK 当前可以针对单次 Model Call 设置 timeout，而且该 timeout 限制的是单次模型调用尝试，不等于整个 Agent Run、工具执行或 Retry Backoff。这正说明 Reliability 必须分层定义 Deadline。
29、Deadline Propagation
假设整个 Task SLO 是 10 分钟，而 Research 已经用掉 8 分钟，Fact Check 不应该重新获得完整 10 分钟 timeout。
Total Deadline
-
Elapsed
=
Remaining Budget每个下游环节应该继承 Remaining Deadline，否则子任务会把整个 Task 无限延长。
30、Queue Reliability 与 Concurrency Group
GitHub Actions 提供 concurrency group 来限制相同资源或 workflow/job 的并发执行。这个设计思想可以直接映射到 Agent Scheduler。
例如 wordpress-production 一次只能允许一个 Publisher，而 Research 可以允许更高并发。Concurrency 应按 Resource 定义，而不是用一个全局并发数字覆盖所有任务。
Queue 满以后必须有 Overflow Policy：Reject、Drop、Defer、Replace，不能无限增长。
31、Dead Letter Queue
经过 Max Retry 仍然失败的 Task 应进入 DLQ，并保存 Task、Last State、Error、Attempts、Trace、Dependency。
DLQ 不是垃圾桶，还必须有 DLQ Review。否则失败任务只是被系统遗忘。
32、Poison Task
Malformed HTML、Huge Document、Broken Encoding、Invalid Schema 等任务可能每次都把 Agent 或 Tool 弄崩。如果不断 Retry，就会形成 Poison Message Loop。超过阈值必须 QUARANTINE。
33、Graceful Restart 与 Checkpoint
系统重启以后不能让所有任务从头再跑。必须保留阶段性 Checkpoint，例如：
Research Complete
Fact Check Complete
Content Pending重启后从 Content 继续，而不是重复已经验证过的 Research 和 Fact Check。对于 Published、Merged、Deleted 等 Side Effect，更不能重新执行，必须先通过状态记录和幂等校验确认。
34、Chaos Testing：在可控环境主动验证故障韧性
Chaos Engineering 的核心不是把系统搞坏，而是在可控制环境注入已知故障，验证系统是否真的具有预期韧性。
Agent Chaos Test 可以非常具体：
OpenAI latency +10s
GSC API 429
WordPress 503
GitHub unavailable
Crawler timeout
Queue worker killed
Database read-only
Malformed Tool Output
Agent returns invalid JSON测试的不是“Agent 会不会报错”，而是错误会不会被隔离、系统会不会自动降级、会不会产生不受控副作用、是否触发熔断、是否能够恢复。
35、六类 Chaos Test
Dependency Failure
例如 WordPress unavailable，预期 Publisher Circuit OPEN、Content Task 仍可完成 Draft、不会产生 duplicate publish、任务进入 WAITING。
Latency Injection
给 OpenAI 增加额外 latency，观察 Deadline、Queue、Retry、Backpressure 是否工作。
Rate Limit
注入 429，期望出现 Backoff、Jitter、Retry Budget，而不是 Retry Storm。
Agent Crash
运行一半时 kill worker，期望 Lease expires、Task reassigned、Checkpoint recovered、No duplicated side effect。
Data Corruption
注入 invalid Knowledge Object，期望 Schema Validation Fail、Quarantine、No Production Decision。
Observability Failure
关闭部分 tracing，系统自身应该能发现 Observability Gap。Monitoring 本身也必须被 Monitoring。
36、Chaos Test 必须控制 Blast Radius
不能直接在整个 Production 上 Kill Everything。建议采用 Local → Test → Staging → Shadow → Small Production Slice 的递进方式。
必须定义 Abort Condition，例如 Error > 5%、Incident Triggered、Data Integrity Risk 时立即 STOP CHAOS。
每次 Chaos Test 还应保存 experiment_id、fault、scope、start、stop、expected、observed、rollback。
37、Game Day
定期主动演练真实场景，例如“WordPress 全部不可用 30 分钟会发生什么”，验证 Detection、Escalation、Fallback、Recovery、Communication。
只有真正演练过的 Runbook，才有资格被认为是可靠 Runbook。
38、Disaster Recovery：局部故障之外，还要考虑核心系统丢失
Chaos Testing 解决局部失败，Disaster Recovery 则要回答：如果核心系统真的没了怎么办？
首先定义 RTO：灾难发生以后允许多久恢复正常运行；再定义 RPO：灾难发生时，可以接受丢失多少时间范围的数据。
39、为 Search Operations 定义 RTO / RPO
项目内部示例：
Knowledge Base
RPO = 1 hour
Task Registry
RPO = near zero
Article Draft
RPO = 24 hours
Production Release State
RPO = zeroRTO 也应该不同：
Research Agent: RTO 4 hours
Monitoring: RTO 30 minutes
Publisher: RTO 1 hour
Incident Control: RTO 5 minutes这些仍然只是内部设计示例。
40、不是所有系统都值得 Zero RTO
接近零 RTO 的高可用设计通常更加复杂、昂贵，只适合真正关键的少量能力。因此要按 Criticality 分层：
Tier 0
Policy / Secrets / Release State
Tier 1
Monitoring / Incident / Task Registry
Tier 2
Research / Analytics
Tier 3
Batch Content Jobs41、Backup 不等于 Recovery
拥有备份并不意味着真的能够恢复。必须定期执行：
Backup
↓
Restore
↓
Verify
↓
Measure RTO
↓
Measure RPO恢复测试至少要验证 Data Integrity、RTO、RPO。
42、哪些状态必须备份
至少包括 Task Registry、Knowledge Base、Experiment Registry、Release Registry、Policy Config、Agent Version、Prompt Version、Evaluation Dataset。
Secrets 不应该混入普通 Snapshot，而需要独立 Secret Management、Rotation 与 Recovery Procedure。
43、Configuration 本身就是 Critical State
很多灾难不是 Database Lost，而是 Bad Config，例如 Concurrency 被改错、Retry 从有限变成 unlimited、Approval 被关闭。
因此 SLO、Timeout、Retry、Circuit Breaker、Queue Limit、Concurrency、Degradation Policy 等 Reliability Config 都必须 Versioned、Reviewed、Rollbackable。
44、Reliability Change 也要 Canary
把 retry max 从 3 改成 10，如果一次推到全部 Agent，可能同时放大系统流量。所以 Reliability Config 也应该 5% workers → observe → 25% → 100%。
45、故障恢复必须有 Runbook
每个 Critical Dependency 至少需要 Detection、Impact、Immediate Mitigation、Circuit Breaker、Fallback、Recovery、Verification、Escalation。
WordPress Runbook
503 detected
↓
Open Circuit
↓
Stop Publish
↓
Keep Draft Queue
↓
Probe
↓
Recover
↓
Verify Existing Posts
↓
Resume QueueOpenAI Dependency Runbook
Latency / 429 ↑
↓
Reduce concurrency
↓
Enable backoff
↓
Route low-risk tasks to alternate model
↓
Defer batch
↓
Protect critical tasksGSC Dependency Runbook
Data unavailable
↓
Mark DATA_STALE
↓
Disable causal decision
↓
Continue crawler / GA4 observation
↓
Wait for data recovery46、Degraded Data 不能伪装成正常数据
系统必须保留 data_quality_state，例如 FINAL、PRELIMINARY、STALE、PARTIAL、UNAVAILABLE。数据处于 STALE 或 PARTIAL 时，很多 Causal Decision 和永久 Knowledge Write 都应该自动降级或暂停。
47、引入 Reliability Controller
到这里，需要在现有 Orchestrator 之外增加一个逻辑组件：Reliability Controller。
它负责：
SLI Collection
SLO Evaluation
Error Budget
Queue Health
Capacity
Circuit State
Backpressure
Degradation
Failure Isolation
Recovery它不能负责业务策略。Reliability Controller 不应该决定“要不要重写页面”，它只决定“现在系统是否适合执行”。
48、Orchestrator、Reliability、Policy、Evaluation 必须分开
Orchestrator:
What should we do?
Reliability Controller:
Can we safely do it now?
Policy Engine:
Are we allowed to do it?
Evaluation:
Is the result good enough?也就是：
WHAT
WHEN
MAY
GOOD四个问题分别由不同控制层回答，才能避免系统既做决策、又给自己放行、又评价自己成功。
49、全局 Reliability State
建议定义：
HEALTHY
DEGRADED
SATURATED
INCIDENT
RECOVERYHEALTHY 允许正常自动化；DEGRADED 降低 Batch、提高 Production Review；CRITICAL / INCIDENT 可以暂停 New Writes，只允许 Incident Task。
50、Recovery 不能立即恢复 100% 流量
严重过载或 Incident 后，系统应该先降低负载恢复稳定，再逐步增加流量，例如 10% → 25% → 50% → 100%，而不是问题一消失就瞬间打开全部队列。
51、Reliability Dashboard
最终需要一个真正的 Control Board，至少显示：
Task Success
Task Latency
Queue Depth
Oldest Task
Retry Rate
Circuit State
Dependency Health
Worker Saturation
Error Budget
Incident Status同时显示 Quality Reliability：Eval Pass、Fact Check Failure、Human Override、Policy Violation。
52、顶级 Reliability KPI
建议持续跟踪 Good Task Rate、SLO Compliance、Error Budget Remaining、P95 Task Latency、Queue Age、Recovery Time、Retry Amplification、Rollback Success、Dependency Availability、Quality Regression Rate。
53、Retry Amplification
可以定义：
Total Attempts
÷
Original Tasks如果从 1.05 突然变成 2.8，说明系统可能正在进入 Retry Storm。
54、Queue Amplification
定义：
Generated Subtasks
÷
Incoming Tasks突然大幅上升，可能意味着 Agent over-decomposition、Handoff loop 或 Duplicate work。
55、Failure Containment Rate
可以统计：
Local Failures that remained local
÷
All Local Failures它直接衡量 Failure Isolation 是否真正有效。
56、Reliability Testing Matrix
| Failure | Expected Behavior |
|---|---|
| LLM timeout | retry / backoff |
| 429 | throttle |
| API outage | circuit open |
| WordPress 503 | queue publish |
| Worker crash | reassignment |
| Invalid JSON | quarantine |
| Queue saturation | load shed |
| GSC unavailable | data stale |
| GitHub failure | stop release |
| Database loss | restore |
57、每个 Agent 与 Tool 都必须遵守 Reliability Contract
所有 Agent 都必须遵守 Deadline、Idempotency、Retry、Error Classification、Trace、Cancellation 协议。
每个 Tool 也应该拥有自己的 Reliability Contract，例如：
tool: wordpress_publish
timeout: 20s
retry: conditional
idempotent: false
circuit_breaker: true
fallback: queueResearch Tool 则可能是：
tool: web_search
timeout: 30s
retry: true
idempotent: true
degrade: official_sources_only58、统一 Failure Taxonomy
建议统一使用：
TRANSIENT
PERMANENT
CAPACITY
DEPENDENCY
POLICY
DATA
SEMANTIC
SIDE_EFFECT_UNKNOWNSIDE_EFFECT_UNKNOWN 尤其重要。例如 POST timed out 的状态不应该直接标成 FAILED，而应该标成 UNKNOWN，先 Verify，再决定 Retry、Rollback 或 Escalate。
59、Incident Severity
可以继续沿用 P0 / P1 / P2 / P3：
- P0：Unauthorized Production Change、Data Loss、Mass Wrong Publish。
- P1：Production Publisher Down、Critical Monitoring Blind。
- P2：Research Degraded、GEO Measurement Delayed。
- P3：Optional Batch Slow。
60、Reliability Incident 必须产生 Postmortem
尤其当 Error Budget 被大量消耗时，Postmortem 不能只回答“谁做错了”，而应该回答：为什么系统允许这个错误扩大？
除了 Root Cause，还要分析 Detection Gap、Isolation Gap、Recovery Gap、Control Gap。
例如真正的 Reliability Root Cause 可能是：
WordPress Timeout
+
Unlimited Retry
+
No Idempotency
+
Shared Worker Pool
=
Mass Duplicate Publish61、Reliability Learning 也要进入 Knowledge Base
每次 Incident 都应该产生 Reliability Learning Object，记录 failure_mode、trigger、blast_radius、detection、mitigation、root_cause、preventive_control。
Digital Twin 不应该只模拟 SEO Change，也可以模拟 Dependency Failure、Queue Surge、Agent Loss；Simulation Lab 可以测试“If GSC unavailable for 12h, what happens?”；Experiment Engine 可以验证 Kill 10% Workers 后是否仍满足 Task SLO。
62、Self-Improving System 需要两条 Learning Loop
Optimization Learning
→ 学习怎样优化 SEO / GEO
Reliability Learning
→ 学习怎样让系统稳定运行一个系统只有优化能力，没有可靠性学习能力，最终会不断重复相同的故障模式。
63、最终 Reliability Architecture
USER / EVENT
↓
ADMISSION CONTROL
↓
QUEUE
↓
SCHEDULER
↓
ORCHESTRATOR
↓
┌──────────────┼──────────────┐
│ │ │
AGENT POOL TOOL POOL DEPENDENCIES
│ │ │
└──────────────┼──────────────┘
↓
RELIABILITY LAYER
│
┌──────────────┼──────────────┐
│ │ │
TIMEOUT RETRY CIRCUIT
BUDGET BUDGET BREAKER
│ │ │
└──────────────┼──────────────┘
↓
POLICY / EVAL
↓
SIDE EFFECT
↓
VERIFY
↓
TRACE
↓
MONITORING
↓
SLI / SLO / BUDGET
↓
INCIDENT / DEGRADATION
↓
RECOVERY / DR
↓
KNOWLEDGE BASE64、完整可靠性状态机
ACCEPTED
↓
QUEUED
↓
RUNNING
↓
DEPENDENCY_WAIT
↓
DEGRADED
↓
RETRYING
↓
EXECUTING
↓
VERIFYING
↓
COMPLETED同时支持：
THROTTLED
CIRCUIT_OPEN
QUARANTINED
DLQ
FAILED
UNKNOWN
ROLLBACK65、真正成熟的 Agent System 必须能失败
一个可靠系统不是 Never Fails，而是 Fails Predictably。
它应该知道什么时候重试、什么时候不重试、什么时候降级、什么时候拒绝、什么时候等待、什么时候熔断、什么时候停止发布、什么时候恢复。
成熟度可以表示为：
Agent Works
↓
Agent Workflow Works
↓
Multi-Agent Organization Works
↓
System Works Under Failure最后一层才是真正的 Production Reliability。
结语：可靠性不是避免失败，而是控制失败
当 SEO / GEO Agent 系统规模越来越大以后，最危险的问题不是某个 Agent 偶尔失败，而是一个局部失败通过 Retry、Queue、Dependency 和 Shared Resource 扩散成整个系统失败。
所以 Agent Reliability Engineering 最重要的目标不是消灭所有 Error，而是：
Detect Failure
↓
Contain Failure
↓
Degrade Gracefully
↓
Recover Quickly
↓
Learn真正成熟的系统应该做到：
- 一个 Research Agent 崩溃，不影响 Publisher。
- 一个 Crawler 过载，不影响 Incident Response。
- Google API 延迟，不触发错误的 SEO 决策。
- WordPress 超时，不产生重复发布。
- OpenAI 429，不形成 Retry Storm。
- Queue 饱和，不拖死 Rollback。
- Worker Crash，不丢失 Task State。
- Database 恢复以后，知道从哪里继续。
- Backup 存在，而且真正验证过 Restore。
- 故障模式不是等事故发生才第一次看到，而是已经通过 Chaos Test 被演练过。
这时系统才真正从 AI Automation 进化为 Reliable Search Operations Platform。
第二十二篇解决的是：Agent 应该怎样组织。第二十三篇解决的是：这个组织在压力和故障下还能不能工作。
只有 Organizational Correctness + Operational Reliability 同时成立，多 Agent SEO / GEO Operating System 才真正具备进入长期生产环境的资格。
官方依据与工程边界说明
本文提出的 Agent Reliability Stack、Agent Good Event、Risk-based SLO Matrix、Reliability Controller、Retry Amplification、Queue Amplification、Failure Containment Rate、Agent Failure Domain、Reliability Learning Object 等，是本 SEO / GEO 自动化项目的工程设计，不是 Google、OpenAI、GitHub 或 Microsoft 的官方 Agent 标准。
Google SRE 对 SLI、SLO 和 Error Budget 提供了本文最主要的可靠性理论基础。Google 将 SLI 定义为服务水平的定量指标，将 SLO 定义为这些指标的目标值，并建议根据用户真正关心的结果选择指标；Google SRE 还强调 100% Reliability 通常并非合理目标，Error Budget 应实际参与发布和可靠性决策。官方资料：Service Level Objectives、Implementing SLOs、Error Budget Policy。
在 Overload 与 Cascading Failure 方面，Google SRE 建议结合 Capacity Planning、Load Testing、Load Shedding、Graceful Degradation、限制 Retry、Randomized Exponential Backoff 与 Retry Budget。官方资料：Addressing Cascading Failures。
OpenAI Agents SDK 当前提供 tracing，以及面向模型调用的 timeout / retry configuration，可作为本文 Task Trace、Failure Localization、Timeout 与 Retry 治理的实现参考。官方资料：Tracing、Models。
GitHub Actions 提供 concurrency 机制用于限制相同资源或 workflow/job 的并发执行，可映射到本文的 One Writer、Production Queue 与 Resource-specific Concurrency。官方资料：Using concurrency。
Google Search Status Dashboard 会公开 Search 系统相关事件与 Ranking Update，可作为 SEO 自动化系统的重要 External Dependency Context。官方资料：Google Search Status Dashboard。
Google Cloud Disaster Recovery 文档使用 RTO 与 RPO 描述灾难恢复目标，并建议通过实际恢复测试验证 Data Integrity、RTO 与 RPO。官方资料：Disaster recovery planning guide。
Chaos Engineering 部分参考 Azure Chaos Studio 对 Fault Injection 与 Resilience Testing 的官方说明。官方资料：Chaos engineering and resilience。