第 14 章 AI 依赖、韧性与运营准备度
稳定运行不等于从不出错。模型、工具、网络、知识、权限、数据、配置、人员和业务规则都会变化；真正可靠的组织不是假设 AI 永远可用，而是知道什么时候应暂停、谁来决策、怎样转人工、如何恢复，以及怎样把事故教训变成下一次更强的控制。
本章将韧性从抽象的“多模型备份”扩展为一套可运行的准备度体系：关键业务的人工底座、依赖可见性、事件分级、运行手册、恢复演练、复盘与持续改进。它适用于固定工作流、Skill、Agent 及其所依赖的模型、上下文包、知识、检索、记忆、工具与连接器。
韧性的目标不是承诺零中断或任意时限恢复。 目标是在组织已定义的业务优先级、数据与风险边界内，能安全地停止错误动作、保持必要服务、恢复到已验证状态，并留下可学习的证据。
一、先定义什么必须在 AI 不可用时继续
AI 用例不是都具有相同关键性。应先由业务 Owner 识别关键业务结果、允许的降级方式和人工备用流程，而不是事后才问“AI 停了怎么办”。
| 业务关键性 | 典型特征 | 人工备用要求 | 建议准备度证据 |
|---|---|---|---|
| 低 | 个人效率辅助；不采用输出不会阻断服务 | 使用者可自行暂停或回到原有方式 | 用例立项卡中的原流程说明与使用边界。 |
| 中 | 高频团队流程；中断会造成延迟、返工或内部协作问题 | 有可定位的手工模板、队列或替代流程；指定负责人 | 工作流合约、人工备用卡、最近一次演练/检查记录。 |
| 高 | 面向客户、关键运营、重要决策支持或具有较高外部影响 | 有明确停用权、优先级、人工接管队列、沟通和恢复条件 | 运行手册、事件分级、演练记录、健康卡、风险/AIA 与发布限制。 |
人工备用不是要求员工永远重复做所有工作，也不是以惩罚性“禁用 AI 时长”替代能力建设。它要求关键角色在必要时能理解任务、核验结果、使用基础工具或模板完成最低服务，并知道何时应升级求助。具体能力基线应由业务风险和岗位责任决定，并纳入附录 A 第 47 节的人工备用与能力基线卡。
二、依赖可见性与可切换设计
AI 工作流的关键依赖不仅包括模型供应商，还包括模型/端点与项目配置、网关、编排平台、上下文包、知识库与索引、检索策略、持久记忆、外部工具/连接器、身份权限、网络、关键人员和业务规则。任何一项不可用、过期、错误写入或配置变化，都可能让“模型仍在线”的工作流实际失效。
1. 为每个关键用例画出最小依赖图
至少记录：业务用例和优先级、模型/工具事实卡、上下文包与数据/知识来源、检索与记忆策略、读写或发送动作、身份与密钥、运行环境、人工备用路径、责任人和恢复证据。模型与工具事实卡可帮助识别版本、端点、数据处理和退出限制，但不替代本用例的内部配置和运行测试。
| 依赖类别 | 需要回答的问题 | 可能的降级或切换方式 |
|---|---|---|
| 模型/API | 哪个端点、版本、项目或区域失效会影响用例？ | 切换到经验证的候选方案；缩小功能；转人工。 |
| 工具与集成 | 哪个检索、文件、浏览器、数据库、消息或写入工具不可用？ | 关闭可选步骤；使用只读/人工流程；暂停写入。 |
| 上下文、知识与检索 | 权威来源、上下文包、索引、过滤、权限或更新链路失效时怎么办？ | 回到已验证版本；只处理可确认范围；转知识/上下文 Owner。 |
| 记忆与状态 | 任务状态丢失、摘要错误、记忆污染或跨用户混用时怎么办？ | 停止读取/写入受影响记忆；隔离、纠错或清理；回到任务记录和人工流程。 |
| 身份与配置 | 密钥、权限、路由、预算、策略或日志失效时怎么办？ | 停止自动动作；按批准流程恢复最小权限；启用人工处理。 |
| 人员与决策 | Owner、审核者或关键操作人员不在时怎么办？ | 指定替补人、值守角色和升级路径；不能满足时暂停扩大范围。 |
2. 切换前先验证，不在事件中“临时换模型”
备用模型、工具或人工流程只有在以下条件满足时才是有效备份：已经在批准环境中完成适用范围和数据条件核验；使用同一 Golden Set 或受影响样本完成比较；已写入工作流/Agent 合约；人工审核、成本、格式和回退条件明确；切换过程已通过演练。未验证的候选方案应视为研究选项，而不是事件中的直接替代品。
三、分级事件管理：先止损，再恢复，再学习
日常问题、计划变更和运行事件应区分处理。计划变更走回归与发布流程；事件是已经或可能已经造成实际错误、越权、数据/安全风险、严重服务中断、异常成本或人工接管失败的情形。
1. 事件分级参考
| 级别 | 典型情形 | 首要动作 | 决策与沟通 |
|---|---|---|---|
| E0 观察/近失 | 被验证或监控拦截，未造成实际采用/影响；重复趋势值得关注 | 记录信号、保留样本、排查是否需要小修复 | Skill/流程 Owner 在日常运营中处理；必要时更新健康卡。 |
| E1 用例异常 | 质量显著下降、知识/上下文失效、记忆异常、工具/连接器失败、成本异常或人工接管增加，但影响范围受控 | 暂停扩大范围；必要时隔离受影响资产、回退稳定版本或转人工 | 业务/技术 Owner 处理，记录事件与恢复条件。 |
| E2 严重事件 | 错误内容被对外采用、越权尝试/动作、关键业务流程受阻、敏感数据或控制风险需要立即评估 | 停止受影响动作，启动人工备用，保全证据并按组织路径升级 | 业务 Owner 与适用技术/安全/风险角色共同决定恢复、通知与复盘。 |
| E3 重大事件 | 影响范围广、可能造成重大权益/安全/合规/业务后果，或无法在已批准控制下安全运行 | 紧急停用或隔离，按组织事件响应/合规流程处置 | 由授权管理层和适用专项团队指挥；本手册的常规流程不足以单独处理。 |
不确定时按更高等级处理。事件等级不是为了追责个人，而是为了让停止、升级、沟通和恢复与影响相匹配。
2. 最小事件响应循环
发现/报警
↓
确认范围、级别与是否立即停止动作
↓
保全事实：上下文/知识/记忆/工具版本、输入/输出、来源、日志、配置、时间线与已采取措施
↓
转人工、回退稳定版本或隔离受影响依赖
↓
按等级通知业务/技术/风险等角色并进行恢复判断
↓
验证恢复：受影响样本、权限、知识、功能与人工备用
↓
完成复盘，更新资产、演练、风险/发布与证据索引细化的事件运行手册、事件记录和复盘模板见附录 A 第 44–45 节。任何涉及敏感数据、外部影响、重大越权或疑似合规问题的事件，应优先遵循组织既有的安全、隐私、法务或行业事件流程。
四、运行手册与人工备用流程
运行手册（Runbook）是让接棒人员能在压力下采取正确动作的操作资产。它不应堆砌长篇技术说明，而应为每个关键用例回答：系统健康如何观察、哪些信号会触发暂停、谁有停用/恢复权、如何转人工、怎样回退、应保留什么证据、恢复前要验证什么。
| Runbook 部分 | 最小内容 | 对应资产 |
|---|---|---|
| 用例与业务影响 | 用例编号、服务对象、关键性、不可接受后果、人工备用流程 | 用例立项卡、风险初筛/AIA。 |
| 依赖与健康信号 | 模型、上下文/知识/记忆、工具/连接器、权限依赖、健康阈值、预算/熔断与异常信号 | 事实卡、上下文包、记忆合约、工具控制卡、健康卡、Agent 或工作流合约。 |
| 暂停与升级 | 何时停止生成、发送、写入或自动动作；通知谁；谁决定恢复 | 风险等级、RACI、事件分级。 |
| 回退与恢复 | 上一稳定版本、人工模板、切换前提、恢复验证样本 | 发布登记、回归报告、人工备用卡。 |
| 记录与复盘 | 应保存的版本、样本、日志、时间线和改进项 | 事件记录、证据索引、Failure Casebook。 |
对低影响用例，Runbook 可以是一张短卡；对 R2/R3、外部沟通、Agent、写入或高关键性用例，应成为完整、可演练且可移交的运行资产。
五、恢复演练：验证“能切换”而不是假设“有备份”
演练应覆盖真实的故障模式和业务动作，而不是只做文档走读。优先场景包括：模型/API 不可用或明显退化、工具/连接器或知识源失败、上下文包或检索配置错误、记忆污染/丢失/隔离失败、权限/密钥失效、异常成本或循环、知识规则紧急变更、人工审核/接管不足，以及需要暂停对外或写入动作的情形。
每次演练至少验证四件事：能否发现异常并正确分级；有权人员能否停止动作并通知正确角色；人工或备用路径能否维持约定的最低服务；恢复后能否用受影响样本验证质量、权限和数据边界。演练不要求追求某个通用分钟数，而应记录本组织的实际发现、决策、切换、恢复和人工接管耗时，作为后续改进基线。
附录 A 第 46 节提供演练计划与记录模板。高关键性、R3 或依赖频繁变化的用例应在阶段提升、重大变更、移交前或健康信号恶化时优先演练；其他活跃用例可纳入月度或季度运营节奏。
六、复盘与持续改进
复盘的目标是改进系统，不是寻找替罪羊。应优先分析：任务/边界是否不清、上下文是否过量/过期/冲突/越权、知识是否过期或冲突、记忆是否错误写入或未隔离、Prompt/Skill/工作流是否存在缺口、模型或工具/连接器事实与配置是否变化、权限或预算是否过宽、人工审核是否被绕过、报警是否失效、以及备用路径是否真正可用。
复盘完成后，应明确每一项改进要更新哪些资产：风险初筛/AIA、事实卡、工作流或 Agent 合约、Golden Set、回归报告、发布登记、健康卡、Runbook、培训/接棒清单、组合台账或 Failure Casebook。没有 Owner、到期日和验证方式的“改进建议”不应被视为复盘闭环。
附录 G 用于沉淀去标识化、可复用的失败模式；附录 A 第 45 节用于保存具体事件的受控复盘记录。两者共同避免同类事故在不同团队中反复发生。
七、韧性与运营准备度复核
不建议用单一“总分”宣布组织安全。更有效的做法是每个关键用例定期回答以下问题，并将结论记录在健康卡、组合评审和证据索引中：
- 是否有经过验证的人工备用流程，并由能接棒的人员掌握？
- 关键模型、上下文/知识/记忆、工具/连接器、权限和人员依赖是否可见，是否有失效或变更信号？
- 上下文包、记忆和工具控制记录能否定位上一稳定版本，并支持隔离、回退、清理或恢复？
- 是否能在不扩大风险的前提下暂停、回退、切换或降级？
- 最近一次事件或演练暴露了什么问题，是否已按期关闭？
- 发布、移交或阶段提升后，Runbook、事实卡、评测和责任人是否仍与实际运行一致？
当关键问题无法回答、人工备用不可用、停止权不清、证据缺失或演练失败未关闭时，应暂停扩大范围，优先恢复控制能力。
八、本章行动清单
本周内完成：
- [ ] 为一个活跃用例指定业务关键性、人工备用流程、停用/恢复权和替补人。
- [ ] 为该用例填写附录 A 第44节运行手册，至少覆盖一个模型、上下文/知识/记忆或工具/连接器失效情形。
- [ ] 把最新依赖、事实卡、上下文包、记忆/工具控制记录、发布版本、健康信号和证据位置关联起来。
下一个运营周期内完成：
- [ ] 选择一个现实场景完成一次恢复演练，并记录实际发现、转人工、恢复与待改进项。
- [ ] 对一次真实事件或近失完成附录 A 第 45 节复盘；匿名化后沉淀到附录 G。
- [ ] 在 FDE/AI COE 移交或用例阶段提升前，验证接棒 Owner 能执行 Runbook、转人工和基础回退。
九、本章小结
成熟的 AI 运营不是追求最大自动化率，而是维持对关键业务、数据、决策和依赖的控制权。组织需要把人工能力、模型/工具替代、知识与权限、事件响应、恢复演练和复盘当成产品的一部分，而不是在故障发生后临时补救。
当团队能够安全停止、清楚升级、维持最低服务、验证恢复并把经验转化为更好的资产时，AI 才能从脆弱的效率工具变成可靠的企业能力。