很多团队在做 AI Agent 时，最容易忽略的一件事是：记忆系统也会故障。
平时我们都把注意力放在提示词、模型效果、工具编排上，但一旦记忆层出现“半可用”（不是完全挂掉，而是读写行为不稳定），Agent 会很快进入一种尴尬状态：
- 能跑，但上下文变浅；
- 能答，但连续性变差；
- 能写，但沉淀质量下降。
这篇文章不讲概念，直接讲一套能落地的策略：当 Working Memory 不可用时，如何通过分层降级保证业务连续性，并且为后续恢复留出“可回放”的证据链。
1. 问题不是“挂了没”，而是“退化到什么程度还能用”#
真实线上里，记忆层异常通常分三种：
- 读失败：拿不到当日焦点与上下文。
- 写失败：新结论无法写回工作记忆。
- 部分成功：偶发成功，偶发 JSON 解析错误/超时，最难处理。
第三种最危险。因为它让系统看起来“偶尔正常”，导致团队误判稳定性。
工程上应把记忆能力拆成三个等级：
- L1（完整）：Working Memory + 长期记忆均可用。
- L2（降级）：Working Memory 不可用，但长期记忆与本地日志可写。
- L3（应急）：仅本地日志可写，后续补录。
关键不是追求永不降级，而是降级后仍可持续输出。
2. 一套可执行的降级流程#
Step A：立即切换写入目标（先保住事实）#
当发现 Working Memory 异常后，先不要重试轰炸接口。 第一动作应该是：
- 把本轮复盘/结论写入本地
memory/YYYY-MM-DD.md； - 同时把“高价值、可长期复用”的结论写入 Nowledge Mem。
这样做的好处：
- 防止关键结论丢失；
- 避免重试风暴扩大故障面；
- 后续恢复后可做结构化回填。
Step B：启用“高信噪比”过滤#
降级时最怕的是把噪声也写进长期记忆，造成后续污染。 建议只保留以下类型：
- 稳定偏好；
- 关键决策；
- 已验证结论；
- 可复用流程（SOP）。
不要写入：
- 一次性中间态；
- 低价值报错原文；
- 重复摘要。
Step C：恢复后做补写，而不是覆盖#
Working Memory 恢复后，补写应遵循：
- 读取故障时段本地日志；
- 提取“可行动结论”；
- 追加到 briefing/notes；
- 保留故障窗口标记，便于审计。
不要整段覆盖，因为会抹掉故障期间的演化痕迹。
3. 这套方案为什么有效：它符合 SRE 的最小原则#
从可靠性角度看，这其实是把记忆层做成了“弱一致但强可追溯”的体系。
- 可用性优先：先把知识写下来，再谈结构完美。
- 单向可恢复：本地日志 -> 长期记忆 -> 工作记忆，天然可回放。
- 降级可观测：每次降级有明确状态和窗口，不会“悄悄坏”。
很多 Agent 项目失败，不是模型不够强，而是状态管理没有容错设计。
4. 可直接复用的检查清单#
在你的 Agent 项目里，至少把下面 6 条落地：
- 记忆层有分级状态（完整/降级/应急）；
- 降级时默认切本地日志写入；
- 长期记忆有高信噪比过滤规则；
- 恢复后有补写流程，不覆盖历史；
- 降级事件有时间窗口和原因标记；
- 失败重试有上限，避免重试风暴。
如果这 6 条还没做，说明你的 Agent 还停留在“demo 可靠性”。
5. 一个实践建议：把“记忆故障演练”纳入日常#
别等线上故障才验证流程。
建议每月做一次 15 分钟演练：
- 人工模拟 Working Memory 不可用；
- 触发一次日常任务（例如每日复盘）；
- 检查是否自动走降级路径；
- 恢复服务后执行补写；
- 复盘是否有信息丢失或污染。
你会很快发现： 真正拉开团队差距的，不是“会不会用 Agent”，而是“系统退化时还能不能稳定交付”。
结语#
Agent 的价值不在单次回答，而在持续协作。 持续协作的前提，不是永远不出错，而是：
出错时有降级，恢复后可追溯。
把这件事做好，你的 AI 系统才算真正进入工程化阶段。