附录 G AI Failure Casebook（故障与失败案例集）
本附录是一个可持续维护的故障模式库，用于沉淀跨团队可复用的学习，而不是替代事件响应、合规通知、证据保全或责任认定。
与第 16 章的完整方法情景不同，本案例库聚焦技术、知识、流程、权限与运行中的具体故障模式。每个条目以“适用条件—可观察信号—可能根因—受控处置—复验要点”组织，帮助团队在遇到类似问题时提出更准确的问题。
证据与隐私边界：事件的原始时间线、配置、日志、数据、人员与决策记录，应先使用附录 A 第 45 节的事件记录与无责复盘模板，在受控位置保存。只有在完成去标识化、必要审批和复用价值评估后，才应将抽象故障模式纳入本库。除非条目明确链接到受控证据或公开来源，以下情节、数值和技术组合均为教学性或抽象化示例，不代表特定组织的真实事件或通用发生率。
公开案例映射（非因果归因）
下表将本库的抽象故障模式与附录 D 已登记的公开案例建立阅读入口。映射只说明某案例可以帮助提出哪些控制问题；它不宣称该公开事件已经证实本库列出的全部根因，也不替代对本组织的事件调查。
| 抽象故障模式 | 可参阅的公开案例 | 可以追问的控制问题 |
|---|---|---|
| 条件约束在变更后失效 | CA-001、CA-002 | 权威知识、适用范围、知识版本、来源定位、升级和纠错是否已受控？ |
| 多步骤 Agent 的异常调用与成本失控 | CA-006 | 破坏性动作是否被最小权限、隔离、独立授权、可恢复备份和演练约束？ |
| 敏感信息进入未批准工具或通道 | CA-003 | 数据分类、批准路径、受控替代方案、员工培训和事件处置能否形成闭环？ |
CA-001 至 CA-006 的来源链接、事实状态、适用范围和不可外推事项，见附录 D“公开案例来源登记册”。
案例一：条件约束在变更后失效
- 诊断层面：任务定义、知识与配置管理。
- 适用情形：高频、多规则的文本生成，且规则、示例或知识会持续更新。
- 风险说明：关键禁止事项、适用条件或输出格式可能在多次变更后被遗漏、冲突或错误引用。
1. 可观察信号
- 人工审核发现输出包含不应出现的敏感信息、过期口径或禁止内容。
- 与上一稳定版本相比，Golden Set 中的关键样本出现新的失败类型。
- Prompt、知识或示例不断叠加，但团队无法说明每项规则的来源、优先级和适用范围。
2. 可能根因
- 上下文债务：例外规则、历史说明和临时补丁不断累积，造成规则冲突或难以维护。
- 知识治理不足：来源、Owner、版本、生效日期或冲突处理不清，导致旧内容仍被使用。
- 验证覆盖不足：变更后未使用受影响的正常、边界和历史失败样本回归。
3. 受控处置
- 按 Runbook 暂停受影响范围，必要时回退到上一稳定资产或人工流程。
- 保留版本、样本、审核结论和影响范围；不要在未记录证据的情况下直接覆盖旧规则。
- 由知识 Owner 和 Skill/流程 Owner 清理重复、冲突或无来源规则，明确优先级与适用范围。
- 对受影响 Golden Set 重新评测；通过回归、发布和观察流程后再恢复或扩大。
4. 复验要点
- 禁止事项和关键边界能否被独立验证，而不是仅靠模型自我声明？
- 每条关键规则是否有权威来源、Owner、版本与生效范围？
- 当规则冲突或知识失效时，是否会停止、转人工或升级？
案例二：微调后任务适配变窄
- 诊断层面：技术选型、数据与评测设计。
- 适用情形：团队希望通过微调改善特定风格、格式或领域模式，并计划扩展到更广泛的请求。
- 风险说明：训练数据、目标、评测范围或发布条件不足时，候选版本可能只在狭窄样本上表现良好，却在边界任务、非训练分布或安全场景中退化。
1. 可观察信号
- 在训练样本或近似样本上表现良好，但在边界、负例或新问法中出现质量下降。
- 输出过度套用固定话术，无法识别不适用请求或转人工条件。
- 新版本的格式、知识使用、拒答、转人工或基础任务表现，与上一稳定版本存在未解释差异。
2. 可能根因
- 数据分布过窄：训练或评测样本不能代表实际任务、边界与异常情况。
- 目标不匹配：用微调解决本应由知识检索、规则、工作流或人工审核处理的问题。
- 评测不足：缺少稳定版本对照、通用能力检查、风险样本和发布观察。
3. 受控处置
- 暂停扩大新版本的使用范围，保留稳定版本与人工备用路径。
- 对训练数据、数据来源、许可、覆盖范围、评测集和目标进行复核；必要时缩小任务边界。
- 比较基础模型、检索增强、规则/工作流改造与微调等候选方案，不预设某一种方案必然更优。
- 使用 Golden Set、风险样本和回归报告验证候选版本；通过受控发布后再评估扩大。
4. 复验要点
- 微调目标是否明确，且能用与业务相关的样本证明改进？
- 知识时效、事实依据和适用范围是否被错误地交给模型参数承担？
- 边界、转人工、拒答和上一稳定版本对照是否覆盖？
案例三：多步骤 Agent 的异常调用与成本失控
- 诊断层面：Agent 状态、工具权限、预算与运行控制。
- 适用情形：Agent 可调用多个工具、循环查询或执行状态转换，且任务量、外部依赖或输入质量会波动。
- 风险说明：空值、异常输入、工具故障、状态判断错误或权限配置不当，可能导致重复调用、超时、成本上升、错误写入或下游拥塞。
1. 可观察信号
- 单任务的调用次数、耗时、成本或重试次数偏离已定义的运行范围。
- 工具返回空值、错误、延迟或不一致数据后，系统仍继续执行同类动作。
- 熔断、接管、日志或审批证据缺失，导致团队无法定位当前状态和影响范围。
2. 可能根因
- 退出路径缺失：Agent 未明确处理“无结果”“不确定”“工具错误”或“权限不足”的状态。
- 限制不足：没有依据业务风险设置单任务步骤、时间、预算、并发、重试或写入约束。
- 观测不足：缺少任务级日志、状态记录、告警、审计和人工接管入口。
3. 受控处置
- 按事件等级暂停相关权限、任务或自动动作，保全必要日志并确认业务影响。
- 将异常状态显式化：例如标记为“信息不足”“待人工确认”或“工具不可用”，而不是无限重试。
- 根据用例风险设置并演练步骤、时间、预算、并发、重试和动作限制；具体数值应来自任务与恢复能力，而非复制固定示例。
- 在恢复前验证工具返回、权限、人工接管、回退和日志是否可用，并用受影响样本回归。
4. 复验要点
- 每个外部工具调用是否有明确成功、失败、超时和无结果的处理路径？
- 是否能在到达限制前发现异常、停止动作并转交给合适角色？
- 是否能够从日志与证据索引定位版本、输入类别、状态、权限和恢复结论？
案例四：不可信上下文改变任务边界
- 诊断层面：上下文来源、指令边界与工具调用控制。
- 适用情形：Agent 或工作流会读取文档、网页、邮件、工单、检索片段或工具返回，并据此继续回答、规划或调用下一步工具。
- 风险说明：外部或内部内容中可能包含过期、冲突、误导性或试图改变系统行为的文字。若系统把这些内容视为比任务规则、审批或状态机更高的指令，就可能扩大检索、泄露资料、绕过验证或提出不应执行的动作。
1. 可观察信号
- Agent 在处理与任务无关的文本后，突然改变目标、来源范围、工具选择或输出格式。
- 检索片段、附件、网页或工具返回包含“忽略前述规则”“导出全部资料”等指令性文字，系统未将其视为不可信数据。
- 输出或行动依据无法定位到经过批准的来源、任务边界或人工批准记录。
2. 可能根因
- 指令与数据混淆：没有清楚区分系统规则、任务输入、检索内容、工具返回和人工批准的优先级。
- 来源边界缺失：上下文包未定义允许/排除来源、返回量、适用范围和异常处理。
- 工具控制断裂：工具调用只依据模型自然语言计划，没有动作白名单、参数限制或独立审批。
3. 受控处置
- 立即停止受影响的自动动作、外发或写入；保全任务、来源、上下文、工具调用和审批记录。
- 将可疑内容隔离为数据，不把其中的操作性文字视为有效指令；必要时转人工判断来源和业务含义。
- 更新上下文包、工具控制卡和 Agent 运行合约，明确来源白名单、排除来源、数据/指令分离、返回量和停止条件。
- 用包含提示注入、无关内容、来源冲突、超长返回和异常工具结果的样本回归；通过发布观察后再恢复范围。
4. 复验要点
- 系统是否能展示每个关键结论或行动使用的来源、版本与范围？
- 不可信内容能否被当作数据处理，而不是覆盖任务规则、审批或状态机？
- 工具是否仍会在不符合动作白名单、权限和批准条件时被拒绝或转人工？
案例五：持久记忆污染、过期或越界复用
- 诊断层面：状态管理、数据隔离、知识时效与可恢复性。
- 适用情形：Agent 将跨轮次任务进度、摘要、客户偏好、确认结论或工作笔记保存在持久记忆、向量索引、数据库或会话外状态中。
- 风险说明：未经确认的推断、过期规则、敏感原文或跨客户信息一旦被写入并在后续任务中读取，可能反复影响输出、造成越权引用或让纠错成本持续扩大。
1. 可观察信号
- 用户或审核者已纠正的内容在后续任务中再次出现，且无法说明读取来源。
- 不同用户、客户、项目或地区的上下文被错误混用。
- 任务状态、摘要或长期记忆与权威来源、当前规则或原始记录不一致。
2. 可能根因
- 写入缺少约束：将模型推测、完整会话、全量工具返回或敏感原文默认写入长期记忆。
- 隔离与生命周期缺失：未按用户、客户、项目、区域或数据级别划分读取范围、保留期和删除规则。
- 纠错不可追溯：记忆缺少来源、版本、Owner、失效和人工纠错入口。
3. 受控处置
- 暂停受影响记忆的读取和写入，隔离可能污染的范围，保留必要的审计证据。
- 使用记忆合约确定哪些内容是已确认事实、任务状态、待核验假设或禁止保存的信息；清理、纠正或按政策删除不符合要求的内容。
- 恢复前验证隔离、来源定位、过期处理、人工纠错、删除和回退是否可用；必要时回到短期任务状态或人工记录。
- 对涉及高影响输出、对外沟通或跨系统动作的任务，使用受影响样本检查记忆变化是否导致质量、权限或行动退化。
4. 复验要点
- 每条可用于关键结论的记忆能否定位到来源、写入原因、版本、Owner 和失效条件？
- 事实、待核验假设和工作笔记是否被明确区分，并采用不同读取与保留规则？
- 是否能按用户、客户、项目或区域隔离、纠错、删除和恢复，而不影响无关任务？
案例提交与维护
Failure Casebook 应作为学习资产维护。建议提交者先完成事件记录、无责复盘、必要的审批与去标识化，再提交可公开或可跨团队复用的抽象条目。提交内容不应包含客户、个人、账号、密钥、内部地址、未公开配置、原始日志或其他敏感信息。
如需提交条目，可按以下结构发送至 jacejacejia@gmail.com：
text
- 场景边界：说明业务任务，并移除客户、人员和敏感数据。
- 事件等级与诊断层面：参考第 14 章和第 2 章。
- 可观察信号：记录确认过的异常，不写入推测性结论。
- 已采取的停止、转人工或回退动作：仅描述可公开的抽象方式。
- 根因假设与验证：区分已证实事实、待验证假设和证据位置。
- 改进与复验：说明修复、演练或回归方式，以及残余风险和后续 Owner。维护者应定期复核条目的适用性、敏感性和关联章节。若条目已被新的证据推翻、存在敏感风险或不再具有复用价值，应更新、归档或移除。