大数跨境
首页
>
SEO2026第266期 |SEO / GEO 工作自动化部署与实践规范（三十)
>

SEO2026第266期 |SEO / GEO 工作自动化部署与实践规范（三十)

SEO2026第266期 |SEO / GEO 工作自动化部署与实践规范（三十) 索未
2026-09-25
7

SEO / GEO 工作自动化部署与实践规范
第（三十）篇：SLO / Incident Detection / Circuit Breaker / Kill Switch / Break Glass / Incident Command

把体系从“单笔异常能够修复”进一步推进到“系统性故障爆发时能够自动止血、降级、冻结和安全恢复”。

这篇文章解决什么？
Execution Journal → Reconciliation Engine → DLQ → Repair Queue → Operator Console

操作路径

  • 01 一、从“事务失败”到“系统事故”，关键变化是什么？
  • 02 二、为什么 SLO 必须放在事故控制面的最前面？
  • 03 三、SEO / GEO Automation 的 SLO 到底测什么？
  • 04 四、本项目建议建立四层 SLO
  • 05 五、Error Budget 的真正价值：告诉系统“什么时候不该继续创新”
  • 06 六、从 Error Budget 进一步进入 Burn Rate

这套体系解决的是：

一笔事务出了问题之后，系统能不能发现它、定位它、修复它，并最终验证真实世界重新收敛。

但生产系统还存在更危险的一类事故。问题不再是：

1 个 WordPress Command 失败

而可能变成：

50 个 Command 同时失败
200 个任务开始重试
3 个 Agent 持续生成新的副作用
WordPress API 错误率持续上升
Cloudflare 请求不断超时
Database 写入开始排队
DLQ 快速增加
Repair Queue 同时膨胀

如果系统仍然按照第（二十九）篇的逻辑，一笔一笔 Repair，它可能根本来不及，甚至会出现：

恢复机制本身开始扩大事故。

例如：

Dependency Failure ↓ Retry ↓ More Load ↓ More Failure ↓ More Retry ↓ Systemic Failure

这时系统面对的已经不是单个异常，而是系统性故障。因此，第（三十）篇要解决的问题是：

当局部异常开始转化为系统性故障时，AI Agent 平台怎样知道应该停止正常运行？

进一步说：

  • 什么时候只是一次普通 Retry？
  • 什么时候应该打开 Circuit Breaker？
  • 什么时候应该暂停某类 Command？
  • 什么时候应该进入 Read-Only？
  • 什么时候应该冻结全部发布？
  • 什么时候应该触发 Kill Switch？
  • 正常治理系统本身失效时，谁可以 Break Glass？
  • 谁来指挥事故？
  • 如何防止五个 Agent 同时“各自救火”？
  • 什么时候可以恢复？
  • 恢复以后能不能直接全部打开？

这意味着整个系统必须继续增加一层，完整链路开始变成：

SLO ↓ Incident Detection ↓ Severity Classification ↓ Circuit Breaker ↓ Degradation ↓ Kill Switch ↓ Incident Command ↓ Break Glass（仅必要时） ↓ Containment ↓ Recovery ↓ Safe Re-entry ↓ Postmortem

这一篇解决的核心问题，可以浓缩成一句话：

生产系统真正成熟的标志，不是它会自动执行，而是当自动执行本身开始变得危险时，它知道什么时候停止。

01 一、从“事务失败”到“系统事故”，关键变化是什么？

第（二十九）篇主要处理：

Command A failed

或者：

Saga B drifted

但 Incident 往往表现为：

Failure Pattern

也就是：异常不再是独立事件，而开始呈现相关性、持续性和扩散性。

例如过去十分钟：

WordPress publish error rate: 1% 2% 8% 21% 47%

同时：

Retry Queue ↑ DLQ ↑ API latency ↑ Worker backlog ↑

如果继续把每次失败当成独立事件（Independent Failure），系统会不断 retry，而没有意识到 WordPress 本身可能正在故障。这就是 Incident Control Plane 的第一个职责不是“修复”，而是“识别”。

02 二、为什么 SLO 必须放在事故控制面的最前面？

很多系统的告警来自：

CPU > 80%
Queue > 100
Error Count > 20

这些指标有价值，但并不能直接回答：用户真正受到影响了吗？

Google SRE 长期使用 SLI、SLO 与 Error Budget 作为可靠性管理基础，强调 SLO 应成为组织做可靠性决策的工具，而不只是 Dashboard 上的 KPI。错误预算应该用于平衡可靠性与变更速度，并在预算耗尽时触发具体的稳定性行动。

因此 SLO 不能只是月报指标（Monthly Report Metric），而应该是：

SLO Healthy → Normal Operation
SLO Degrading → Elevated Monitoring
Error Budget Burning Fast → Restrict Risk
Error Budget Exhausted → Freeze High-Risk Change

03 三、SEO / GEO Automation 的 SLO 到底测什么？

传统 Web Service 常见 SLO 包括：

Availability
Latency
Error Rate

SEO / GEO 自动化除了基础设施 SLO，还需要增加业务层面的关注点。因为对我们的系统而言，API 返回 200，并不代表任务成功。例如：

WordPress API = 200

但：

wrong content version published

仍然是严重失败。因此建议把自动化 SLI 分为五类：

SLI 关注点 示例
Availability 服务能否执行 Command Bus 可用率
Timeliness 是否及时完成 发布事务完成时间
Correctness 状态是否正确 正确版本正式发布
Convergence 最终是否收敛 Repair 后 Desired=Observed
Safety 是否产生危险副作用 重复发布/越权操作率

这意味着未来系统不应该只有 API Availability SLO，还需要：

Execution Correctness SLO
Reconciliation SLO
Publishing Safety SLO

04 四、本项目建议建立四层 SLO

Level 1：Infrastructure SLO

例如：

Command Bus availability
Database availability
Worker processing latency
Queue delay

Level 2：Execution SLO

例如：

99% commands reach terminal state within X minutes

Level 3：Business Transaction SLO

例如：

99.9% approved website publishing transactions reach verified published state without duplicate side effects

Level 4：Safety SLO

例如：

Unauthorized production side effects = 0
Duplicate irreversible actions = 0
Unreviewed high-risk publishing = 0

其中 Safety SLO 与普通 availability SLO 不完全相同。因为 99.99% safe 对于某些控制目标甚至都不够，有些事故目标应该是 Zero Tolerance Event（零容忍事件），例如：

production secret leaked
unauthorized DNS change
mass deletion
unapproved mass publish

05 五、Error Budget 的真正价值：告诉系统“什么时候不该继续创新”

假设 Publishing SLO = 99.9%，则对应一定的 Error Budget。Error Budget 的价值不是允许系统“故意失败”，而是建立一个客观机制：

How much unreliability can we tolerate?

Google SRE 的示例 Error Budget Policy 明确提出：如果服务已经消耗完错误预算，可以停止常规变更与发布，把资源转向可靠性修复。这给 SEO / GEO 自动化一个非常重要的启发：发布速度本身不应该永远具有最高优先级。

当系统表现恶化时，“Publish More”可能是错误动作，真正正确的动作可能是“Freeze Publishing”。

06 六、从 Error Budget 进一步进入 Burn Rate

只看“本月用了多少 Error Budget”，反应可能太慢。因为真正危险的是：Error Budget 正在以多快速度被消耗？

假设一个月允许 100 个错误，现在总共只发生 20 个，乍看还有 80% 预算。但如果 20 个错误全部发生在最近 3 分钟，那就是完全不同的问题。Google SRE 强调，应让 SLO 与错误预算直接驱动可操作告警。因此事故检测应该关注：

Error Budget Remaining + Burn Rate + Blast Radius

07 七、Incident Detection 不等于“收到一个 Alert”

一个 Alert 只是 Signal，而 Incident 是 Correlated Operational Condition（相关的操作状况）。例如：

Alert 1: WordPress 5xx
Alert 2: Retry Queue ↑
Alert 3: Publish latency ↑
Alert 4: DLQ ↑

如果四个系统分别告警，Operator 会收到 4 个问题，实际上可能只有 1 个事故。因此需要把 Signals、Events、Symptoms、Dependencies 聚合成 Incident Candidate。

08 八、事故检测应该优先看“症状”，而不是猜根因

Google SRE 建议告警优先基于用户可感知的症状。例如：

CPU 91% → SEV1

并不一定成立，因为 CPU 91% 时所有发布可能仍然正常。反之：

CPU 40%
50% WordPress publishes wrong version

这反而是严重事故。因此 SEO / GEO 自动化应该关注 Publishing Success、Correctness、Duplicate Rate、Approval Bypass、Convergence、Monitoring Coverage，而不是只关注 CPU、RAM、HTTP requests。

09 九、建议建立 Automation Incident Severity

本文建议采用项目内部四级事故模型：

级别 定义 示例
SEV0 极端安全/控制事故 Secret 泄露、失控删除、控制面失效
SEV1 大范围生产影响 批量错误发布、关键系统不可用
SEV2 局部严重影响 单渠道大面积失败、DLQ 快速增长
SEV3 有限影响 小范围降级，可正常 Repair

注意：这些等级是项目内部定义。核心目的不是名称，而是：每个 Severity 必须绑定明确动作。

10 十、Severity 不能只由“错误数量”决定

建议至少考虑：Impact、Scope、Velocity、Reversibility、Safety、Visibility、Duration。

例如 Incident A：100 个 Monitoring Record 创建失败，但文章本身全部正确发布，可能是 SEV2。

Incident B：只有 3 个 Command，但它们做的是 Cloudflare DNS destructive change，则可能是 SEV0 / SEV1。

因此：Incident Severity 是风险函数，不是计数函数。

11 十一、Retry 什么时候必须停止？

当系统确认 Transient Failure（瞬态故障）时，Retry + Backoff 是合理的。但如果持续失败，不断重试可能开始扩大故障。AWS 指出 Circuit Breaker 的目的之一就是阻止这类无意义的重复调用。于是必须建立升级路径：

Failure ↓ Retry ↓ Retry Budget ↓ Circuit Breaker

而不是：

Failure ↓ Infinite Retry

12 十二、Circuit Breaker：第一层自动止血机制

Circuit Breaker 的控制范围应该是具体的依赖调用，例如：

wordpress.publish
github.create_pr
cloudflare.purge
database.write
wechat.create_draft

当 failure threshold exceeded（超过失败阈值）时，就停止继续向该依赖发请求。它的本质不是 Fix dependency，而是 Stop making dependency worse。

13 十三、Circuit Breaker 推荐采用三态模型

本文建议统一成：CLOSED ↓ OPEN ↓ HALF_OPEN ↓ CLOSED

CLOSED

正常执行。Command → Dependency

OPEN

依赖被认为异常。Command × Dependency。请求直接 fail fast、queue defer 或 fallback，而不是继续施压。

HALF_OPEN

只允许少量 Probe Request 验证恢复。如果成功转为 CLOSED，如果失败回到 OPEN。

14 十四、Circuit Breaker 必须按能力拆分，不能“一坏全坏”

例如 WordPress Media Upload 失败，不代表 WordPress Read 也失败，更不意味着 GitHub Archive 必须停止。因此应该建立 Circuit Scope：

wordpress.read
wordpress.create_draft
wordpress.publish
wordpress.media_upload
github.read
github.write
cloudflare.purge
cloudflare.dns_write

这样可以做到 wordpress.publish = OPEN 但 wordpress.read = CLOSED。系统仍然能读取状态做 Reconciliation，但停止危险写操作。

15 十五、Circuit Breaker 与 Permission System 是两件事

Capability 回答：May this Agent do this?（这个 Agent 可以做这件事吗？）
Circuit Breaker 回答：Should the platform currently allow anyone to do this?（平台当前应该允许任何人做这件事吗？）

因此，即使 Capability = VALID，也不能绕过 Circuit = OPEN。完整判断应该是：

Decision = APPROVED AND Capability = VALID AND Circuit = CLOSED AND Incident Policy = ALLOW

才能真正执行。

16 十六、Degraded Mode：系统不一定只有“运行”和“停止”

Circuit Open 后，不应该所有业务都返回失败。更成熟的方法是定义降级模式：

NORMAL ↓ DEGRADED ↓ READ_ONLY ↓ FROZEN

NORMAL

全部功能允许。

DEGRADED

停止非关键能力（如暂停自动生成图片、批量内容刷新、低优先级实验），但保留 Monitoring、Reconciliation、Critical Repair。

READ_ONLY

允许 Research、Monitoring、Observation、Analytics、Reconciliation；禁止 Publish、Update、Delete、Deploy。

FROZEN

除了 Incident Recovery 以外，全部生产副作用停止。

17 十七、Kill Switch 与 Circuit Breaker 完全不同

Circuit Breaker 是：Automatic、Scoped、Dependency-Aware（自动的、局部的、依赖感知的）。
Kill Switch 是：Explicit、High Authority、System-Wide or Domain-Wide（显式的、高权限的、系统级或域级的）。

例如 wordpress.publish circuit = OPEN 只影响 WordPress Publishing。而 GLOBAL_PRODUCTION_WRITE_KILL_SWITCH = ON 则可能禁止 WordPress Publish、GitHub Write、Cloudflare Change、Database Mutation、Email Send、WeChat Publish 等所有高风险 Side Effect。

18 十八、Kill Switch 必须 Easy / Obvious / Fast

Google SRE 明确建议保留 Kill Switch 与 Manual Override，并要求其容易找到、明显、快速且有完善文档。对于 SEO / GEO Agent 平台，Kill Switch 绝不能设计成需要找工程师改代码再部署的漫长流程。真正的 Emergency Stop 应该通过 Operator Console 认证后直接触发策略存储并立即执行。

19 十九、Kill Switch 不应该直接 Kill Process

Kill Switch 的重点不是 kill -9 worker，因为直接杀进程可能制造 Outcome Unknown、Orphan Command、Partial Saga 等更加复杂的问题。更合理的是 Stop New Side Effects，然后 Allow In-Flight Transaction → Reach Safe Boundary 或者 Pause Before Pivot。因此 Kill Switch 应控制入口和策略，而不是简单粗暴地 Destroy Processes。

20 二十、需要设计多个 Kill Switch，而不是只有一个红色按钮

推荐至少包括：

GLOBAL_WRITE_STOP （全部生产写入停止）
PUBLISHING_STOP （停止 WordPress / WeChat 内容发布）
DEPLOYMENT_STOP （停止 GitHub Merge / Deploy / Cloudflare Config）
AUTONOMOUS_ACTION_STOP （停止 Agent 自动 Side Effect，但允许人工审批动作）
DELETE_STOP （禁止所有破坏性删除）

这样 Incident Commander 可以做到 Stop Minimum Necessary Scope（停止最小必要范围），而不是 Shutdown Everything。

21 二十一、Kill Switch 还必须有 Fail-Safe 默认值

假设 Kill Switch Policy Store 无法读取，系统是 ALLOW 还是 DENY？对于 production write、delete、publish、deploy、DNS，更合理的原则通常是：Control Plane Unknown → Reject High-Risk Side Effect（未知则拒绝高风险副作用）。而对于 Read、Monitoring、Observation、Health Check，则可以 Fail Open。具体策略需要按 Capability Class 设计。

22 二十二、Kill Switch 本身也是 Tier-0 系统

如果 Emergency Stop 依赖正在故障的 Command Bus，那就没有意义。因此 Emergency Control Plane 最好拥有 Separate Path（独立路径），至少在逻辑上避免完全依赖普通执行路径。确保 Stop 比 Start 拥有更少依赖。

23 二十三、Break Glass 是什么？

当 Normal IAM Policy Engine 和 Approval System 本身不可用时，正常治理流程可能阻止 Operator 修复生产系统。这时需要 Break Glass，即 Emergency Privileged Access（紧急特权访问）。但必须强调：Break Glass 不是“超级管理员方便入口”。

24 二十四、Break Glass 应该与日常管理员身份完全分开

不能 normal-admin@example.com 既负责日常操作，又是 break glass。更合理的是 Normal Operator 与 Emergency Operator 分离。Break Glass 凭据应该：rarely used、strongly protected、independently monitored、regularly tested。任何此类账户使用都应触发高优先级告警。

25 二十五、Break Glass 不能绕过 Audit

紧急权限可以 bypass normal approval，但绝不能 bypass audit。相反，Break Glass 操作应该拥有最高级别的审计，至少记录 session_id、incident_id、operator、reason、scope 等。并且 Break Glass Activated 应直接创建 Incident Event，甚至自动升级 Severity。

26 二十六、Break Glass 权限必须短生命周期

错误的模型是 Emergency Admin Password 永远有效。更好的模型是：Emergency Identity ↓ Explicit Activation ↓ Short TTL ↓ Limited Scope ↓ Auto Expire。Break Glass 的目标是 restore control（恢复控制），而不是 replace governance（替代治理）。

27 二十七、谁决定“这是 Incident”？

不能让每个 Agent 自己宣布 SEV1，否则系统会产生 Incident Storm（事故风暴）。因此建议加入 Incident Detection Engine，接收 SLO signals、Burn Rate、Circuit states 等，生成 Incident Candidate。只有满足 Incident Policy 后才进入 OPEN INCIDENT。

28 二十八、Incident Command：事故必须只有一个协调中心

如果多个负责人同时自行操作，非常容易出现“A 在 rollback，B 在 deploy fix，C 在 retry...”最终谁也不知道到底哪一个动作改变了状态。Google 的事故管理强调 Coordinate、Communicate、Control，并采用明确角色结构。

29 二十九、本项目建议建立三类 Incident Role

Incident Commander

负责 Severity、Priorities、Scope、Kill Switch、Recovery decision。核心职责是 Control the incident（控制事故）。

Operations Lead

负责 Diagnosis、Mitigation、Rollback、Circuit control、Repair execution。核心职责是 Fix / Contain（修复/遏制）。

Communications / Record Lead

负责 Timeline、Status update、Decision record、Stakeholder update。核心职责是 Maintain shared truth（维护共同事实）。

30 三十、AI Agent 在事故期间应该做什么？

事故发生时，Agent 不应该继续 maximize automation throughput（最大化自动化吞吐量），而应该切换到 INCIDENT_AGENT_MODE。

允许：Observe、Read、Analyze、Correlate、Recommend、Reconcile、Generate rollback plan、Generate impact report。
限制：Publish、Deploy、Delete、Mass update、Policy change（除非获得 Incident Capability）。

31 三十一、Incident Capability 必须独立于普通 Capability

普通 Capability（如 wordpress.publish）在事故期间可能被冻结，而 Incident Capability 可能允许 wordpress.unpublish_known_bad_post 或 deploy.rollback_to_known_good_version。Incident Capability 应更窄、更短、风险更明确、审计更强，而不是简单给予 admin:*。

32 三十二、进入事故状态以后，优先目标不是 Root Cause

在用户影响仍然扩大的情况下，Root Cause 通常不是第一目标。更合理的顺序是：Detect ↓ Contain ↓ Mitigate ↓ Stabilize ↓ Recover ↓ Root Cause。所以：Mitigation First, Explanation Later.（先缓解，后解释。）

33 三十三、SEO / GEO 平台的 Containment 可以是什么？

例如发现自动发布内容版本错误，Containment 不一定是立刻删除全部文章，更可能是：

PUBLISHING_STOP = ON
Freeze pending publishes
Preserve existing pages
Reconcile affected versions

如果发现 Cloudflare write automation anomaly，则 cloudflare.write = DISABLED, cloudflare.read = ENABLED。如果发现 Agent planning anomaly，则 AUTONOMOUS_ACTION_STOP = ON，但继续允许 Monitoring 和 Operator-approved repair。

34 三十四、Incident Control 需要“Blast Radius”概念

一个异常不能只回答“有问题吗？”，还必须回答“影响了多少？”。1 Command 1 Article 与 2,400 URLs 3 websites Cloudflare account 完全不是一个量级。因此 Incident Record 至少需要记录 affected_systems, blast_radius 等。

35 三十五、系统需要自动生成 Incident Snapshot

Incident 创建时，应该立即冻结一份 Incident Snapshot，包括 detected_at, severity, slo state, circuit_states, kill_switch_states 等。因为事故处理过程中系统状态一直变化，如果没有 Snapshot，事后就很难回答事故刚开始时到底是什么样。

36 三十六、事故期间必须冻结哪些变化？

推荐引入 Change Freeze，但不能机械地 freeze everything。可以设计：

NORMAL_CHANGE = STOP
EXPERIMENTAL_CHANGE = STOP
RECOVERY_CHANGE = ALLOW
SECURITY_CHANGE = ALLOW

这样可以避免“为了恢复生产，却禁止所有恢复修改”的悖论。

37 三十七、恢复不能以“错误率下降”为唯一条件

事故最容易出现：看起来恢复了 ↓ 全部打开 ↓ 再次故障。因此必须定义 Exit Criteria：

SLO burn normalized
dependency health stable
no new safety violations
DLQ growth stopped
critical drift reconciled
rollback/fix verified

只有 Exit Criteria = PASS 才进入 RECOVERY。

38 三十八、Safe Recovery 必须分阶段

推荐恢复状态机：INCIDENT ↓ CONTAINED ↓ STABILIZING ↓ RECOVERY_PROBE ↓ PARTIAL_RESTORE ↓ OBSERVATION ↓ NORMAL。不能 FROZEN ↓ NORMAL 一步跳转。

39 三十九、先恢复 Read，再恢复 Write

一个很实用的顺序是：Monitoring ↓ Read APIs ↓ Reconciliation ↓ Low-Risk Writes ↓ Draft Creation ↓ Approved Publishing ↓ Autonomous Publishing ↓ High-Risk Mutation。如果你连现实状态都看不清，就不应该恢复自动写入。

40 四十、Circuit Recovery 应采用 Probe，而不是全流量恢复

Circuit Breaker 从 OPEN 恢复时，不应该直接 100% traffic。而应该 OPEN ↓ HALF_OPEN ↓ Limited Probe ↓ Stable ↓ CLOSED。对 Agent 系统而言，Probe 可以是 1 Draft、1 Read、1 Cache Purge，而不是直接恢复 500 queued commands。

41 四十一、积压任务恢复时尤其危险

系统停机 30 分钟后，Queue 里可能积累 1,000 Commands。如果 Circuit 关闭后 1000 commands immediately dispatch，可能造成二次雪崩。因此需要 Controlled Drain（受控排放），例如 5% ↓ 10% ↓ 25% ↓ 50% ↓ 100%，每个阶段检查 SLO、Latency、Error 等。

42 四十二、事故恢复以后不能立即关闭 Incident

技术恢复（Service Healthy）不等于 Incident Closed。还需要 Verify external state、Reconcile outstanding transactions、Resolve DLQ、Revoke break-glass access、Reset kill switch state、Archive timeline。因此 SERVICE_RECOVERED 和 INCIDENT_CLOSED 必须分开。

43 四十三、Break Glass 必须在恢复后立即撤销

Break Glass 最大的风险不是“打开”，而是“忘记关闭”。因此 Incident Exit Checklist 必须包括 Break Glass Revoked，并重新确认 Normal IAM restored 等。不能让 temporary emergency access 变成 permanent shadow admin。

44 四十四、Kill Switch 恢复也必须经过审批

Enable Kill Switch 可以是 fast path，但 Disable Kill Switch 应该 slower、higher confidence、approved。这是一个重要安全原则。

45 四十五、Incident Record 需要哪些字段？

建议扩展 incident record，包含：incident_id, severity, status, timeline (detected, contained, recovered, closed), trigger, symptoms, blast_radius, slo, error_budget, circuits_opened, kill_switches, roles, break_glass_sessions, actions, root_cause, postmortem 等。这样 Incident 才是结构化的工程资产，而不是 Slack 里的一段聊天。

46 四十六、Operator Console 必须升级成 Incident Console

除了展示 DLQ、Repair、Drift，还需要增加 Current Incident、Severity、SLO Status、Open Circuits、Kill Switch State、Blast Radius 等。最重要的视觉信息应该是：What is currently allowed?（当前允许做什么？），这样 Operator 不需要猜现在到底还能做什么。

47 四十七、Incident Mode 必须传播到所有 Agent

不能出现 Orchestrator knows incident 但 Publisher Agent still publishing 的情况。因此 Incident State 必须成为全局 Policy，所有 Action Gateway 都读取同一个 Incident Policy。

48 四十八、Incident State 本身也必须版本化

例如 Incident Policy v14 允许 wordpress.read，v15 允许 wordpress.draft。如果 Worker 使用旧缓存，可能造成 policy drift。因此需要 incident_policy_version，并在高风险 Side Effect 前重新验证 Current Incident Policy。

49 四十九、如何处理“监控系统自己坏了”？

如果 Monitoring unavailable，系统还能继续 Autonomous Publishing 吗？高风险自动化应考虑：如果已经无法证明 system is healthy，就应降低 allowed autonomy。例如：

Monitoring Healthy → autonomous publishing
Monitoring Partial → approved publishing only
Monitoring Blind → production write freeze

因为：无法观察的自动化，不应该保持最高自治等级。

50 五十、AI Agent 自己能不能触发 Kill Switch？

可以，但不是 LLM thinks something looks bad → global kill。应该经过 Deterministic Policy，例如 Safety Violation Confirmed AND Blast Radius > threshold，或者 SLO Fast Burn AND Multiple Independent Signals，才触发 AUTO_KILL。而模糊判断“可能有问题”更适合 Recommend Kill → Human Confirm。

51 五十一、推荐建立四级自动止血动作

Level 0 — Observe

No restriction

Level 1 — Throttle

Reduce concurrency, Reduce rate, Delay low priority

Level 2 — Circuit / Degrade

Open affected circuit, Disable optional capabilities

Level 3 — Freeze

Stop production writes, Keep observation + repair

Level 4 — Emergency Stop

Global Kill Switch, Incident Command, Break Glass if required

这样 Incident Response 就从 Binary Stop / Go 升级为梯度控制。

52 五十二、Automation Safety State Machine

建议形成状态机：NORMAL ↓ WATCH ↓ DEGRADED ↓ INCIDENT ↓ FROZEN ↓ EMERGENCY。恢复则不能直接反向跳跃，应该 EMERGENCY ↓ FROZEN ↓ RECOVERY ↓ LIMITED ↓ WATCH ↓ NORMAL。这使平台拥有真正意义上的安全状态机。

53 五十三、完整架构现在演进到哪里？

Agent
 │
 ▼
Evidence Plane
 │
 ▼
Risk Engine
 │
 ▼
Governance Decision
 │
 ▼
Decision Trace
 │
 ▼
Capability Issuer
 │
 ▼
Action Gateway / PEP
 │ ├── Circuit Breaker
 │ ├── Degraded Mode
 │ └── Kill Switch
 │
 ▼
Command Bus
 │
 ▼
Execution State Machine
 │
 ▼
Saga Orchestrator
 │ ├── Idempotency
 │ ├── Retry
 │ ├── Compensation
 │ └── Outbox
 │
 ▼
Execution Journal
 │
 ▼
Reconciliation Engine
 │ ├── Drift Detector
 │ ├── Orphan Detector
 │ ├── DLQ
 │ └── Repair Queue
 │
 ▼
Reliability Control Plane
 │ ├── SLI / SLO
 │ ├── Error Budget
 │ ├── Burn Rate
 │ ├── Incident Detection
 │ └── Severity Engine
 │
 ▼
Incident Control Plane
 │ ├── Incident Commander
 │ ├── Operations Lead
 │ ├── Communications Lead
 │ ├── Kill Switch
 │ ├── Break Glass
 │ └── Recovery Controller

54 五十四、本项目的原创判断：自治的上限由“停止能力”决定

很多 Agent 系统都在追求更多权限、更多工具、更多自主执行。但生产环境真正的安全上限并不是 Agent 能做多少事，而是：当 Agent 做错、依赖出错、策略出错或系统进入未知状态时，我们能多快阻止它继续做事。

因此 Autonomy 必须与 Interruptibility 同步建设。更强的 Agent 如果没有 Circuit Breaker、Kill Switch、Incident Policy，只意味着错误可以传播得更快。

55 五十五、真正成熟的自动化必须满足“两种速度”

正常状态下：Move Fast
事故状态下：Stop Fast
恢复状态下：Resume Slowly

56 五十六、从 Reliability 到 Resilience

Reliability 关注系统是否稳定工作；Resilience 更进一步关注系统在已经发生严重故障以后，还能不能限制损失并恢复。演进路径是：Governance ↓ Reliable Execution ↓ Operational Recoverability ↓ Incident Control ↓ Resilience。

57 五十七、第（三十）篇最终结论

第（二十九）篇结束时，我们得到：可运营系统不是没有异常，而是任何异常都不能悄悄消失。

第（三十）篇再增加一句：韧性系统不是所有异常都继续修复，而是当修复速度赶不上故障扩散速度时，系统知道什么时候停止继续制造新的副作用。

因此真正成熟的生产自动化必须具备：SLO、Incident Detection、Circuit Breaker、Degraded Mode、Kill Switch、Incident Command、Break Glass、Safe Recovery、Postmortem。最终整个体系从 AI can act 升级为 AI can act safely，再升级为 AI can fail safely。

58 第（三十一）篇预告

当上述机制建立之后，下一个自然问题是：事故结束以后，系统怎样避免同一种事故再次发生？

如果 Postmortem 最终只是写一份报告，然后 Action Item 过期，那么系统实际上什么都没有学会。因此第（三十一）篇将进入 Postmortem 与 Chaos Engineering，重点解决如何从事故 Timeline 构建 Causal Graph、如何把修复转成 Regression Test、如何通过 Chaos / Game Day 验证 Kill Switch 和 Circuit Breaker 是否真的可用。把 Incident Response 继续升级为 Anti-Fragile System（反脆弱系统）。

59 来源与核验说明

  • Google Site Reliability Engineering — The Art of SLOs：Google 将 SLI、SLO 和 Error Budget 作为以用户为中心衡量和管理可靠性的基础。
  • Google SRE Workbook — Implementing SLOs / Error Budget Policy：讨论了错误预算耗尽后减少风险、暂停普通变更的政策机制。
  • Google SRE Workbook — Alerting on SLOs：SLO 与错误预算可以直接驱动可操作的告警。
  • Google SRE — Incident Management Guide：强调 coordinate / communicate / control，并设置 Incident Commander 等清晰职责。
  • AWS Prescriptive Guidance — Circuit Breaker Pattern：说明 Circuit Breaker 用于阻止对持续失败依赖的反复调用。
  • Google SRE Workbook — Managing Load：建议设置 Kill Switch 与 Manual Override，并要求其易用、明显、快速。
  • Microsoft Entra — Emergency Access / Break Glass：建议为紧急访问保留独立机制，并实施强监控和告警。

你进行到哪一步？
你所在的团队，最需要先补齐哪一项规则？

阅读、SEO、AI实践、小说与生活
在不同路径里，寻找同一件事：怎样成为更完整的自己。

推荐阅读:

  • SEO2026第265期 | SEO / GEO 工作自动化部署与实践规范（二十九）
  • SEO2026第264期 | SEO / GEO 工作自动化部署与实践规范（二十八）
  • SEO2026第263期 | SEO / GEO 工作自动化部署与实践规范（二十七）
【声明】内容源于网络
0
0
索未
各类跨境出海行业相关资讯
内容 906
粉丝 0
索未 各类跨境出海行业相关资讯
总阅读35.5k
粉丝0
内容906