可靠性与降级

把 AI 部署进组织的关键流程，意味着系统必须为失败而设计。AIDC 平台的稳定性不依赖任何单点的高可用，而是来自多层冗余：每一层都假设相邻层可能失败，并定义了失败发生时的降级行为与恢复路径。

// 核心命题

稳定性来自多层冗余，而不是某个组件"永不宕机"。Cell 可复制、事件可重放、审计可缓冲、文件可回滚、中央保持轻量——五条机制叠加之后，任何单一故障都只产生局部、可恢复的影响。

设计立场：为失败而设计

在六层架构中，执行发生在分布式的 Agent Cell（L4），语义与策略集中在 Ontology 层与 Policy & Identity Plane（L1–L2）。这种"中央管语义、部门管执行"的分工本身就是可靠性设计的第一步：中央 Ontology 服务只做语义、策略和路由，不承载全部任务执行，因此中央故障不会让全公司的 Agent 同时停摆。

在此基础上，可靠性模型回答三个问题：

故障如何被限制 — 任何组件失败时，影响半径必须是可预先说明的（一个 worker、一个部门、一类动作），而不是"整个系统不可用"。
降级时还能做什么 — 降级不等于停机。系统在部分失效时仍能处理低风险任务，只暂停高风险动作。
恢复后如何补齐 — 事件补发、审计补写、版本回滚，恢复路径必须是机制化的，而不是靠人工事后对账。

多层冗余：五条机制

平台的冗余不是一条"主备切换"，而是五条相互独立、分别覆盖不同失效面的机制：

Cell 水平复制Horizontal Replication

Agent Cell 可水平复制，同一个部门可以运行多个 runtime worker，共享同一个部门文件系统与上下文索引。任务通过队列分发，worker 之间无状态依赖；单个 worker 崩溃时，队列中的任务自动由同 Cell 的其他 worker 接管，部门服务不中断。复制发生在 Cell 内部，不跨越部门边界，因此扩容不会稀释权限隔离。

事件总线韧性Resilient Event Bus

Cell 之间的协作走事件总线（EventBridge / SQS / SNS），总线支持三件事：重试——投递失败的事件按退避策略自动重发；死信队列——多次重试仍失败的事件进入 DLQ，留待人工或修复后的消费者处理，不会被悄悄丢弃；幂等消费——消费端按事件 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 复制按队列深度扩缩容，低频任务走短生命周期 worker（Lambda），不为偶发任务长期占用计算资源；事件总线与死信队列按消息量计费；S3 旧版本按 lifecycle policy 自动转入低成本存储层。固定成本只留给必须长驻的部分——部门文件系统与轻量中央平面。资源选型与扩缩容策略详见 AWS 部署映射。