可靠性与降级
把 AI 部署进组织的关键流程，真正的考验不是平时跑得多快，而是出事时业务停不停、记录丢不丢。AIDC 平台的稳定性不依赖任何单点的“永不宕机”，而是来自多层冗余：每一层都假设相邻层可能失败，并预先定义了失败发生时的降级行为与恢复路径。
就像一家管理良好的公司不会因为某位员工请假就全面停摆——平台的每个环节都备好了“代班、补记、回退”的预案：单点故障发生时，业务照常运转，记录一条不丢，恢复后系统自动补齐，不需要人工事后对账。
设计立场：为失败而设计
在 六层架构 中，执行发生在分布式的 Agent Cell（L4，每个部门独立的 AI 运行环境），语义与策略集中在 Ontology 层与 Policy & Identity Plane（L1–L2）。这种“中央管语义、部门管执行”的分工本身就是可靠性设计的第一步：中央 Ontology 服务只做语义、策略和路由，不承载全部任务执行，因此中央故障不会让全公司的 Agent 同时停摆——就像总部办公室断电，不会让各地分公司同时关门。
在此基础上，可靠性模型回答三个管理者最关心的问题：
- 故障如何被限制 — 任何组件失败时，影响半径必须是可预先说明的（一个 worker、一个部门、一类动作），而不是“整个系统不可用”。
- 降级时还能做什么 — 降级不等于停机。系统在部分失效时仍能处理低风险任务，只暂停高风险动作。
- 恢复后如何补齐 — 事件补发、审计补写、版本回滚，恢复路径必须是机制化的，而不是靠人工事后对账。
多层冗余：五条机制
平台的冗余不是一条“主备切换”，而是五条相互独立、分别覆盖不同失效面的机制——任何一条失效，其余四条仍然各自成立：
Cell 水平复制Horizontal ReplicationAgent Cell 可水平复制，同一个部门可以运行多个 runtime worker（执行任务的工作单元），共享同一个部门文件系统与上下文索引。任务通过队列分发，worker 之间无状态依赖；单个 worker 崩溃时，队列中的任务自动由同 Cell 的其他 worker 接管，部门服务不中断——相当于一个岗位配了多名可互相顶班的员工。复制发生在 Cell 内部，不跨越部门边界，因此扩容不会稀释权限隔离。
事件总线韧性Resilient Event BusCell 之间的协作走事件总线（EventBridge / SQS / SNS），可以把它理解为公司内部的“挂号收发室”，它保证三件事：重试——投递失败的事件按退避策略自动重发；死信队列——多次重试仍失败的事件进入 DLQ（Dead Letter Queue，退件登记簿），留待人工或修复后的消费者处理，不会被悄悄丢弃；幂等消费——消费端按事件 ID 去重，同一份“信件”重复送达也只会被办理一次。三者组合保证“事件最终被处理且只生效一次”。
本地审计缓冲Local Audit Buffer每个 Cell 内置本地审计缓冲：所有动作先写入本地缓冲，再异步汇入中央 Action Log——部门先记台账，再汇总账。即使中央日志服务短暂不可用，本地审计链依然完整，恢复后按序补发。审计因此不依赖中央日志的可用性——这是平台“100% Action 审计覆盖”承诺的工程基础，详见下文专节。
版本化与备份Versioning & Backup部门文件系统和对象存储启用版本化与备份：EFS 定期备份，S3 开启 versioning 与 lifecycle policy，主机磁盘使用 EBS snapshot。文件是 Cell 的工作记忆，版本化让“误删、误改、坏写入”都可以回退到任意历史版本，而不是只剩最后一次每日备份——就像合同的每一稿都有存档，而不是只留最终签署版。
轻量中央平面Thin Central Plane中央 Ontology 服务只做语义、策略和路由，不承载全部任务执行。执行、文件、索引、审计缓冲全部分布在部门 Cell 里，中央平面的失效面被刻意压缩：它宕机时，已经拿到上下文包的任务可以继续执行，Cell 可以处理低风险本地任务，只有“需要新上下文或高风险授权”的动作会暂停。
故障降级策略
降级策略预先回答“某个组件失败时，系统的行为是什么”——这张表应当出现在每一次部署交付的验收材料里。五种典型故障与对应的降级行为如下：
| Failure | Degraded Behavior |
|---|---|
| 单个 Agent worker 崩溃 | 同 Cell 其他 worker 接管队列任务 |
| 单个部门 Cell 不可用 | 只影响该部门，不拖垮全局系统 |
| 中央 Context Gateway 短暂不可用 | Cell 可处理低风险本地任务，高风险动作暂停 |
| Event Bus 延迟 | 本地 action buffer 保留状态，恢复后补发 |
| Ontology schema 更新失败 | 回滚到上一稳定版本 |
单个 Agent worker 崩溃
最常见、影响最小的故障。worker 是无状态的执行体，任务来自队列、上下文来自 Context Gateway 的上下文包、产物落在部门文件系统。worker 崩溃时，未确认的任务回到队列，由同 Cell 的其他 worker 按幂等语义重新消费；执行到一半的文件写入由版本化兜底。对部门用户而言，可感知的影响通常只是单个任务延迟。
单个部门 Cell 不可用
整个 Cell（运行时、索引、事件消费）失效时，故障被锁定在部门边界内：其他部门的 Cell 不共享它的运行时与存储，照常工作；发给该部门的事件在总线上保留并重试，等 Cell 恢复后继续消费。这是“以 Cell 为部署单元”的直接收益——故障隔离边界与组织边界重合，不存在“一个部门的故障拖垮全公司”的路径。
中央 Context Gateway 短暂不可用
Gateway 是 Cell 获取跨部门上下文与高风险动作授权的唯一入口（见 Context Gateway）。它短暂不可用时，Cell 进入受限模式：依赖本地文件系统与本部门上下文索引即可完成的低风险任务继续执行；需要新上下文包、跨部门读取或受控 Action Type 授权的高风险动作一律暂停排队，等 Gateway 恢复后继续。降级的原则是“宁可慢，不可越权”——绝不因为中央不可用就放宽权限检查，正如审批人不在时合同只能等签，而不是免签。
Event Bus 延迟
事件总线延迟或短暂不可达时，Cell 不会丢失已完成的工作：执行结果与待发布事件先写入本地 action buffer（事件侧对应 outbox 目录，相当于“待寄出”文件筐），状态保留在 Cell 内部；总线恢复后按序补发，消费端的幂等机制保证补发不会造成重复生效。跨部门流程因此表现为“延迟交付”而不是“丢失交付”。
Ontology schema 更新失败
语义层是全平台共享的依赖，schema 更新是高风险变更。每次更新都带版本号，更新失败或灰度验证不通过时，回滚到上一稳定版本；正在执行的任务继续使用其上下文包中绑定的旧版本语义，不受切换影响。schema 的演化、灰度与回滚流程由 演化闭环 治理。
本地审计缓冲为什么重要
在传统集中式日志架构里，“日志服务不可用”有两种处理方式，都不可接受：要么阻塞业务（日志写不进去就不许执行），要么放过审计（先执行，日志丢了再说）。对一个以“所有 Action 可审计”为合约的平台，第二种意味着审计链出现缺口——你将无法向审计方回答“中央日志宕机的那二十分钟里，Agent 做了什么”。
本地审计缓冲用“部门台账先记账、总账事后汇总”的方式消解了这个两难：
- 先写本地，再汇中央 — 每个动作在执行所在的 Cell 内先写入本地缓冲，本地写入成功即视为审计成立；汇入中央 Action Log 是异步过程，中央短暂故障不阻塞执行、不产生缺口。
- 审计记录与动作同源 — 缓冲记录绑定发起者、Agent 版本、上下文包版本和工具调用摘要，与 Action Log 的字段合约一致。补发只是搬运，不需要事后重建现场。
- 恢复后按序补发 — 中央恢复后，缓冲按时间序补发，Action Log 的全局时间线保持完整；幂等写入保证重复补发不产生重复记录。
- 缓冲本身可审计 — 缓冲落在 Cell 文件系统的独立目录（如
audit/buffer/），受版本化与备份保护；即使 Cell 主机故障，缓冲也能从快照恢复。
审计链完整性优先于中央日志可用性。任何 Agent 动作都必须先落本地审计缓冲再执行副作用；禁止任何“日志服务不可用时跳过审计”的代码路径，也禁止 Agent 关闭或清空自己的审计缓冲。
备份与版本化策略
备份回答“灾难后能不能恢复”，版本化回答“坏变更能不能回退”。两者覆盖的对象不同，必须同时存在：
| 对象 | 机制 | 恢复语义 |
|---|---|---|
| 部门文件系统（EFS） | EFS backup（AWS Backup 定期计划） | 整目录恢复到备份时点，用于主机或存储级灾难 |
| 对象存储（S3） | S3 versioning + lifecycle policy | 单对象回退到任意历史版本；旧版本按生命周期归档降本 |
| 主机磁盘（EBS） | EBS snapshot | 整机回滚，用于运行环境损坏或升级失败 |
| Agent 运行环境（sandbox） | 变更前 snapshot（snapshot → 变更 → 验证 → 失败则 restore） | 策略、模型、工具变更失败时整环境回退 |
| Ontology schema | 语义版本化，保留历史稳定版本 | 更新失败回滚到上一稳定版本 |
| 策略与配置（policy YAML、IaC） | 进入 Git，走 PR review | 任何策略变更可追溯、可 revert、可审计 |
三条执行纪律让这张表真正生效：
- 变更前先快照 — 每次策略、模型、工具或 plugin 变更前，先对 Agent 运行环境做 snapshot；这把“变更失败”从事故降级为一次 restore。
- 配置即代码 — 基础设施与安全策略（Terraform / OpenTofu、policy YAML）全部进入 Git，版本历史本身就是一层备份，PR review 是变更前的最后一道人工闸门。
- 恢复必须演练 — 备份只有在恢复被验证过之后才算存在。交付验收要求关键服务有备份与恢复说明，并实际演练过 restore、rebuild 与权限撤销。
上线前可靠性验收清单
可靠性不是上线之后才去验证的属性。以下检查清单建议在每次部署交付或重大变更前过一遍，每一条都直接对应本页的五条冗余机制与三条执行纪律：
- 影响半径已书面化 — 每类组件失败时的影响范围（一个 worker、一个部门、一类动作）已写进交付文档，并与上文降级策略表一致。
- 恢复已实际演练 — 关键服务的 restore、rebuild 与权限撤销至少完整演练过一次，“有备份”不等于“能恢复”。
- 变更前快照成为习惯 — 策略、模型、工具变更前对 Agent 运行环境做 snapshot 的步骤已写入变更流程，失败可一步回退。
- 死信队列有明确负责人 — DLQ 不是垃圾桶：有指定角色定期处理积压事件，保证“事件最终被处理”不是一句空话。
- 审计链无缺口 — 抽查中央日志不可用时段的动作记录，确认本地缓冲补发后 Action Log 的全局时间线完整、无重复。
- 降级模式验证过 — 在测试环境人为隔离 Context Gateway，确认 Cell 只放行低风险本地任务、高风险动作排队等待，而不是放宽权限检查。
可靠性与成本的平衡
多层冗余不等于多倍成本。冗余机制的选型刻意偏向“按用量付费”的形态：worker 复制按队列深度扩缩容，低频任务走短生命周期 worker（Lambda），不为偶发任务长期占用计算资源；事件总线与死信队列按消息量计费；S3 旧版本按 lifecycle policy 自动转入低成本存储层。固定成本只留给必须长驻的部分——部门文件系统与轻量中央平面。资源选型与扩缩容策略详见 AWS 部署映射。
相关阅读
- Agent Cell — 冗余机制的物理载体：worker、缓冲、outbox 都在 Cell 内
- Context Gateway — 降级模式下“低风险放行、高风险暂停”的判定入口
- 演化闭环 — schema 与策略变更的灰度发布与回滚治理
- AWS 部署映射 — 备份、快照、日志与网络隔离的具体 AWS 落点
- Action Log — 本地审计缓冲最终汇入的中央审计对象