主题
第 22 章 典型场景实践
前面五章建立的是通用方法：责任域怎么划分、写入与检索怎么做、治理怎么落地、选型怎么判断。但方法要落到场景里才有意义，而场景之间的差异不在技术栈，在失效后果的严重程度与可接受的召回错误率。
一个个人助理记错用户口味，用户会纠正，成本是一句抱怨。一个医疗随访系统记错过敏史，成本是一次医疗事故。两者用的是同一套机制，但配置、验收标准与投入完全不同。把这些差异写清楚，比再给一套通用最佳实践更有用。
本章选五个场景，每个按四段展开：业务约束、记忆设计、失效点、验收方法。五个场景覆盖了从低风险高容忍到高风险低容忍的完整区间，也覆盖了中文场景的特殊问题。
22.1 个人助理：偏好漂移与过度概括
22.1.1 业务约束
个人助理的记忆需求有三个特征：写入频率低（一天几条）、读取频率高（每轮对话都要用）、错误容忍度高（用户会纠正）。
约束的关键在于用户是唯一的裁判。系统不需要向第三方证明什么，只需要让用户感觉"它懂我"。这意味着审计链、级联删除这些能力在这里的优先级远低于召回准确率与响应速度。
22.1.2 记忆设计
核心是分层画像。把记忆分成三层：稳定身份（职业、语言习惯、长期偏好）、偏好与约束（饮食禁忌、沟通风格）、当前情境（最近在做什么项目、这周的目标）。
分层的价值在于更新频率不同。稳定身份几乎不变，当前情境每周都变。如果混在一起，每次情境更新都会污染身份层。
第二个设计是来源标注。区分"用户明确说的"与"系统推断的"。用户说"我不吃香菜"是明确的；系统从三次点餐记录推断"偏好清淡"是推断的。两者在召回时的权重应当不同。
22.1.3 失效点：过度概括
最常见的失效不是记错，而是从具体推一般时推过头。
用户说过三次"少放辣"，系统推断出"不吃辣"并写入偏好层。下次用户点麻辣火锅时，助理推荐了清汤锅底，用户困惑。
这个失效的机制是：单次陈述被提升为稳定属性，而提升过程没有置信度衰减。正确做法是把推断结果标为低置信度、放在情境层而非偏好层、并在每次使用时允许被推翻。
第二个失效点是偏好漂移未及时反映。用户三个月前喜欢深色模式，现在改用浅色。如果旧记忆没有被新记忆压制，系统会持续推荐深色。这要求检索时必须考虑时间信号，而不只是语义相似度。
22.1.4 验收方法
三个可执行的检查。
分层可展示性：系统能否向用户展示"我记住了什么"并按层组织？如果只能给一个平铺列表，用户无法判断哪条是身份、哪条是临时情境。
推翻成本：用户说"不对，我现在喜欢浅色"之后，需要几次交互才能让系统改正？超过一次就说明写入路径缺少冲突消解。
过度概括率：抽样 50 条系统推断的记忆，人工判断有多少条是"从一次陈述推出的稳定属性"。超过 20% 说明推断过于激进。
22.2 企业客服与 CRM：旧事实压过新事实
22.2.1 业务约束
客服场景的记忆有三个特征：写入频率高（每次交互都产生记录）、读取必须实时（用户等待中）、错误后果中等（影响满意度但不直接违法）。
关键约束是多来源。同一个客户的信息来自工单系统、通话记录、邮件、订单库，四个来源的更新时间不同，且可能互相矛盾。
22.2.2 记忆设计
核心是双时间轴 + 来源优先级。
双时间轴区分"事实何时发生"与"系统何时获知"。一条"客户已升级到企业版"的记录，发生时间是上周，但系统可能是今天才知道。如果只记录写入时间，系统会误判这条信息的新鲜度。
来源优先级解决矛盾。订单库的状态优先于通话记录里的口头承诺；正式工单的结论优先于聊天中的猜测。这个优先级需要显式配置，不能靠模型判断。
第二个设计是冲突显式化。当两个来源给出矛盾信息时，不要静默选一个，而是把矛盾标记出来，让检索结果带上"存在冲突"的标记。人工客服看到标记后会主动确认，而静默选择会让错误持续。
22.2.3 失效点：旧事实持续生效
最典型的失效是：客户三个月前投诉过物流慢，系统把"对物流敏感"写进画像。客户后来换了收货地址，物流问题解决了，但画像没更新。每次交互系统都主动提"我们注意到您之前对物流有顾虑"，客户觉得系统在翻旧账。
机制上，这是派生结论没有随源事实失效。源事实（那次投诉）已经不再有预测价值，但派生结论（物流敏感）独立存在且没有过期机制。
第二个失效点是跨会话的上下文污染。上一个客服会话里客户表达了不满情绪，这个情绪被写入记忆，下一次会话开始时系统带着"这位客户可能不满"的先验，导致语气过度谨慎。
22.2.4 验收方法
时序正确率：构造 20 组"新旧事实冲突"的测试用例，看系统返回的是新事实还是旧事实。目标 90% 以上返回新事实。
冲突可见率：故意注入矛盾的来源，看检索结果是否带冲突标记。目标 100% 可见。
过期清理：统计超过 90 天未被引用且未被更新的记忆占比。超过 40% 说明缺少降级机制。
22.3 研发效能 Agent：经验负迁移
22.3.1 业务约束
研发场景的记忆需求特殊：写入的是方法而非事实，读取发生在任务开始时，错误后果可能是引入 bug。
关键约束是经验有适用条件。"这个项目里我们用 pnpm 而不是 npm"是一条有效经验，但它只在特定项目成立。如果被无差别套用到另一个项目，会造成构建失败。
22.3.2 记忆设计
核心是前置条件必填。保存一条可复用经验时，必须同时记录三件事：什么条件下适用（must）、什么条件下不适用（must_not）、典型环境是什么（typical_env）。
没有这三件事的"经验"实际上是"建议"，而建议的可靠性远低于经验。
第二个设计是召回时做前置条件校验。不是简单返回匹配的经验，而是判断当前环境是否满足 must、是否触发 must_not，只返回通过校验的条目，并给出未通过的原因。
Mnemosyne 的 playbook_save 把 preconditions 设为必填字段，playbook_recall 返回 applicable 与 blocked_by。这个设计的代价是写入时更麻烦——调用方必须想清楚适用条件，而这件事经常被跳过。
第三个设计是代码演进记忆。记录每次变更的意图、约束、影响面与被拒绝的方案。这类记忆的价值不在于"当时改了什么"，而在于"当时为什么不那样改"——后者在六个月后无人记得。
22.3.3 失效点：负迁移
最典型的失效是：某条经验在 A 项目有效，被套用到 B 项目造成事故。
具体形态：Agent 在 A 项目学到"遇到类型错误先检查 tsconfig 的 strict 设置"，这个经验被存入经验库且没有前置条件。在 B 项目里遇到类型错误时，Agent 直接去改 tsconfig，而 B 项目的真实问题是依赖版本冲突。改动 tsconfig 掩盖了症状，问题在两天后以更严重的形式爆发。
机制上，这是经验被当作通用规则。前置条件缺失让召回变成了关键词匹配，而关键词匹配无法区分"相似的问题"与"相同的问题"。
第二个失效点是经验库变成教条库。随着经验积累，Agent 越来越依赖历史做法，对新情况的探索减少。表现为：遇到新问题时，Agent 反复尝试历史方案而不是分析当前问题。
22.3.4 验收方法
前置条件覆盖率：统计经验库中有完整 must / must_not / typical_env 的条目占比。目标 100%，低于 80% 说明写入纪律未落实。
负迁移检出：构造 10 组"经验不适用"的场景，看 playbook_recall 是否正确返回 blocked_by。目标 100%。
探索率：统计 Agent 在遇到新问题时使用历史方案与现场分析的比例。探索率持续下降说明经验库在压制探索。
22.4 合规敏感行业：删了但派生结论还在
22.4.1 业务约束
医疗与金融场景的记忆有三个特征：写入需谨慎（每条都可能是证据）、读取需授权（越权读取是事故）、删除需可证（法定删除权）。
关键约束是没有任何一步可以"大概对"。审计方会追问细节，而细节层面的含糊会被认定为不合规。
22.4.2 记忆设计
核心是四层删除语义 + 派生关系记录。
派生关系必须在写入时建立，而不是删除时推断。一条"患者对布洛芬不过敏"的记忆，可能已经生成了"可用 NSAIDs"的派生结论、被引用进了两次会诊摘要、影响了三条用药建议。这些关系如果不在写入时记录，删除时只能靠全文扫描，准确率无法保证。
第二个设计是删除预览。执行删除前，必须能看到受影响的派生条目、摘要、缓存清单，而不只是一个数量。决策者需要判断"删掉这些是否可接受"。
第三个设计是审计链的完整性。每次删除都要入链，记录谁在什么时间删了什么、影响了什么。这不是为了追责，而是为了在审查时能证明"删除是按流程执行的"。
22.4.3 失效点：派生结论残留
最典型的失效就是 13 章开头那个案例：源记录删了，摘要还在引用，策略还在用旧参数。
具体形态：患者行使删除权，要求清除"收入水平"相关记忆。运维执行删除，接口返回成功，检索确认查不到。三个月后合规抽查发现，该患者的会话摘要里仍有一句"月收入约 2 万"，依赖该记忆生成的随访策略仍在使用旧参数。
机制上，这是删除只做了第一层。四层语义中，源记录删除是最简单的一层，派生失效、缓存清除、摘要标陈旧都需要额外机制。
第二个失效点是导出副本与删除权冲突。为了保留审计证据，系统做过防删除导出。用户要求删除时，这份导出是否也删？如果保留，是否构成对删除权的违反？
22.4.4 验收方法
级联完整性测试：删除一条有依赖的记忆，验证派生结论、缓存、摘要四个层次都被处理。目标 100%。
预览准确率：对比预览列出的影响项与实际受影响项，目标 100% 一致。不一致说明派生关系记录不全。
导出范围声明：每次删除处理记录中，必须明确列出"本次删除覆盖的范围"与"范围之外保留的副本及理由"。缺这一项，审查时会被追问。
22.5 中文为主的企业知识场景：专有名词召回失准
22.5.1 业务约束
中文场景的记忆需求有两个特殊点：分词没有空格边界，专有名词（产品型号、人名、项目代号）在嵌入空间中区分度低。
关键约束是关键词信号不能只做兜底。多数系统的设计是"语义为主，词法兜底"，但在中文专有名词场景，词法才是主力。
22.5.2 记忆设计
核心是词法信号作为一等公民。
Bigram 分词是零依赖条件下最稳定的 n-gram 策略：把"华为Mate60Pro"切成二元组，既保留了"Mate60"这样的关键片段，又不需要词典。配合 FTS5 全文索引，可以在没有嵌入模型的情况下完成基础召回。
第二个设计是同义词词典。中文的近义表达（"偏好"/"喜欢"/"习惯"）在语义上接近，但在词法上完全不同。内置词典让词法检索能覆盖这些变体。
第三个设计是相对时间解析。"上周三""去年底""这季度"必须被解析为绝对日期，否则双时间轴直接失效，而双时间轴是冲突裁决的基础。
22.5.3 失效点：纯嵌入召回在型号上失准
最典型的失效是：用户问"Mate60 的保修政策"，系统返回了"Mate50 的保修政策"。
机制上，两个型号在嵌入空间中的距离很近（都是手机型号、都是华为产品、句子结构相似），但在业务上完全不同。语义相似度在这里给出的是错误信号。
第二个失效点是中文摘要的过度压缩。中文的信息密度高，摘要压缩时容易丢掉关键限定词（"仅限"、"不包括"、"除…之外"），导致语义反转。
22.5.4 验收方法
专有名词召回率：构造 50 组"型号/人名/代号"查询，看 top-5 是否命中正确条目。目标 85% 以上，纯嵌入方案通常在 60% 左右。
词法-语义对照实验：同一批查询分别用纯嵌入、纯词法、融合三种方式跑，比较命中率。这个实验能直接说明在特定语料上哪种信号更有效。
时间解析正确率：抽样 50 条含相对时间表达的输入，看解析结果是否符合预期。
22.6 场景与能力的映射
| 场景 | 关键能力 | 主要风险 | 核心验收指标 |
|---|---|---|---|
| 个人助理 | 分层画像、来源标注、时间信号 | 过度概括、偏好漂移 | 过度概括率 < 20% |
| 客服与 CRM | 双时间轴、来源优先级、冲突显式化 | 旧事实压制新事实 | 时序正确率 > 90% |
| 研发效能 | 前置条件必填、召回校验、变更记忆 | 经验负迁移 | 前置条件覆盖率 100% |
| 合规敏感 | 四层删除、派生关系、删除预览 | 派生结论残留 | 级联完整性 100% |
| 中文知识 | Bigram + FTS5、同义词、时间解析 | 专有名词失准 | 专名召回率 > 85% |
表 22-1 五类场景的能力映射与验收指标
这张表最有用的地方是最后一列：每个场景都有一个可以用脚本验证的核心指标。没有这个指标的团队，实际上无法判断自己的记忆系统是否在工作。
22.7 本章小结
本章确立了三条判断。
第一，场景之间的差异不在技术栈，在失效后果与可接受错误率。 个人助理能容忍 20% 的过度概括，医疗场景不能容忍任何派生结论残留。同一套机制在不同场景下的配置与验收标准完全不同，套用通用最佳实践会导致资源配置错位。
第二，每个场景都有一个决定性的失效模式，而它通常不是"记错"。 个人助理的失效是过度概括，客服的失效是旧事实压制新事实，研发的失效是经验负迁移，合规的失效是派生结论残留，中文的失效是专有名词失准。五种失效对应五套不同机制，没有一个通用方案能同时防住。
第三，验收必须落到可脚本化的指标。 过度概括率、时序正确率、前置条件覆盖率、级联完整性、专名召回率——五个指标都能用固定数据集验证。没有这类指标的团队，只能靠用户投诉发现问题，而用户投诉的滞后性在合规场景里是不可接受的。
本章是实践篇的最后一章。接下来的展望篇要处理的是这些场景共同面对的、目前无解的问题。