做 AI 原生应用的人，早晚都会撞上同一个问题：模型本地推理再强，面对跨很多轮的任务，它仍然会“选择性失忆”。我一开始以为这是模型能力问题，后来反复排查才发现，真正决定记忆效果的是应用层那套数据处理流程，尤其是被称作工作记忆的那一段。工作记忆负责把当前任务最需要的上下文信息装进每一次请求里，并且随着对话推进不断更新、淘汰。这篇文章我会把工作记忆从数据入口到压缩遗忘、再到与长期记忆交互的完整链路拆开，讲清楚每一步为什么这么做，以及我踩过的坑。
1. 要把工作记忆聊透，得先从“上下文窗口不够用”讲起
1.1 大模型不会“记住”，应用层必须替它记
很多刚接触 AI 原生应用的朋友会有一个误解：大模型既然能理解自然语言，那它应该也能“记得”用户之前说过什么。实际上模型每一次推理都只拿到当前请求里拼接好的文本，它没有真正意义上的内部状态，不会因为上一轮聊过就自动保留信息。所谓“记忆”，全部依赖应用层在每次请求时把过去的信息重新放回输入文本中。
这就带来了一个很现实的矛盾：上下文窗口不是无限的。即便用支持超长窗口的模型，把整段历史一股脑塞进去，也会遇到注意力被稀释的问题，模型对早期关键信息的敏感度会明显下降。更别提 token 成本和请求延迟会随长度快速上涨。所以工作记忆的定位非常像人的“手头工作台”：只放当前任务最需要的东西，放不下的要么压缩、要么归档、要么丢掉。这个工作台本身不存在于模型内部，它是由应用层的数据结构、调度逻辑和存储策略一起搭出来的。
我自己在做一个模拟项目X（一个多轮订单处理助手）的时候，最早就是简单地把全部对话历史拼进 prompt。前二十轮效果还行，到第四十轮以后模型开始频繁忽略用户最早提出的硬性要求，比如“必须周三前送达”“包装上不要出现品牌字样”。当时我第一反应是换更大的窗口，但换了之后问题只是推迟出现，并没有消失。后来才意识到，问题的本质不是窗口大小，而是我在数据处理流程上缺少“工作记忆管理”这一层。
1.2 工作记忆、短期记忆和长期记忆的边界到底划在哪
记忆体系里通常分成三层：工作记忆、短期记忆、长期记忆。工作记忆对应的是当前任务正在使用的信息，典型例子包括用户本轮输入的指令、上一步工具调用返回的结果、尚未完成的目标清单；短期记忆则是对近期对话内容的缓冲，比如最近几轮的原始消息；长期记忆则是对用户画像、历史偏好、领域知识、项目背景这类跨会话信息的持久化存储。
边界不是一成不变的，而是由数据的生命周期和访问频率决定的。工作记忆的特点是访问频率最高、生命周期最短，通常只在一个会话或一个任务阶段内有效，需要主动维护优先级和淘汰策略；短期记忆更像一个滚动缓存，按时间和轮次自然淘汰；长期记忆则进入外部存储，需要检索才能回到工作记忆。
我在架构设计时会把三者分开存储。工作记忆放在内存中的一个独立数据结构里，短期记忆放在会话级缓存，长期记忆放到持久化存储。这样可以避免一个常见误区：把长期记忆当成工作记忆的扩容区。长期记忆如果被无差别地塞回 prompt，会让模型分不清哪些是当前必须遵守的、哪些只是背景资料，最终反而降低指令遵循的稳定性。
1.3 一条用户消息进入工作记忆后的完整旅程
如果把一条用户消息从进入系统到影响模型输出看作一条完整的数据处理流水线，大致会经历这几个环节：接收原始输入，做基础解析和意图提取；结合当前工作记忆中的任务状态，判断这条输入属于新指令、补充信息还是状态变更；经过 token 预算分配，决定它要以原始形态还是压缩形态进入上下文；在上下文组装时，与历史轮次、检索结果、系统指令一起排队；随后触发工作记忆内部的状态更新，把不再适用的旧信息降级或丢弃；最后，如果这条消息包含值得长期保留的信息，还会异步写入长期记忆。
这个旅程里最容易出问题的，是“判断属于新指令、补充信息还是状态变更”这一步。它决定了新信息应该覆盖什么、保留什么。如果判断错，比如把用户的一次补充说明当成全新指令，原本的目标就被截断了；反过来，如果把新指令当成旧信息的补充，又会造成约束冲突。我后来固定的做法是给每条进入工作记忆的消息标注一个“操作类型”字段，取值为新增、更新、删除、确认、无关。这个字段不直接喂给模型，但会参与优先级评分和冲突消解逻辑，效果比纯靠模型自己理解要稳定得多。
2. 数据进工作记忆的第一道关卡：上下文组装与Token预算分配
2.1 先给上下文窗口做预算，别把Token全赌在历史上
大多数工作记忆失控的起点，是上下文组装阶段没有预算概念。很多人觉得“窗口够大，历史全塞就行”，结果窗口的一半被无关闲聊占据，真正重要的约束反而被稀释。正确的做法是先做 token 预算分配：根据模型的上下文窗口大小，把空间划分为系统指令区、用户当前输入区、历史消息区、检索结果区、工具返回区。
以常见的 32K 窗口为例，我在模拟项目X里是这样分配的：系统指令占 3K，用户当前输入预留 2K，检索结果预留 4K，工具返回结果预留 3K，剩下的 20K 左右全部交给历史消息和工作记忆摘要。这个分配不是拍脑袋，而是基于对实际请求的统计：多数正常交互里，系统指令和工具定义是固定的，用户输入通常不会超过 2K，检索结果如果超过 4K 说明召回质量有问题，需要先做重排序而不是硬塞。
预算分配的核心意义在于给了工作记忆一个硬边界。一旦边界定了，后续所有“该保留什么、该压缩什么”的决策都有了判断依据。我不再需要问“这段历史重不重要”，只需要问“它值不值得占这段预算”。这个思维转变非常关键，它让记忆管理从一个模糊的语义问题，变成了一个相对明确的资源分配问题。
2.2 历史轮次筛选：滑窗之外的保留规则
确定预算之后，下一步是决定哪些历史轮次能进入工作记忆。最简单的是滑窗法，只保留最近 N 轮。但这个策略有一个明显缺陷：用户可能在很早就提出了一个关键约束，到后面才要求执行，如果当时这一轮被滑出窗口，约束就丢了。模拟项目X里“周三前送达”被遗忘，就是因为裁剪时把最早几轮直接丢弃。
我的改进方案是在滑窗之外叠加一套保留规则。首先把所有包含明确约束的消息标记为“关键消息”，关键消息包括带有否定词、时间节点、价格、地址、ID、数值等槽位的内容；其次，凡是用户明确用“记住”“必须”“不要”“改成”这类指令词修饰的消息，一律提升为高优先级；最后，对于被标记为关键的消息，不参与轮次裁剪，只参与 token 压缩。这样一来，历史区域实际上由两部分组成：一部分是最近 N 轮的完整原始消息，另一部分是跨轮次的“关键消息保护区”。
保护区的大小也需要限制，否则所有历史都会被标记成关键消息。我设置了一个经验阈值：保护区最多占历史预算的 40%，超出部分按重要性评分排序，只保留分数最高的那些。这个比例来自多次测试，超过 40% 后模型端的效果提升变得非常有限，反而挤占了近期上下文的预算，导致对最近指令的响应变差。
2.3 工具返回结果和检索片段如何压缩后进场
AI 原生应用里有一个非常常见但总被忽视的场景：工具调用返回的数据量巨大。比如查数据库返回几十行订单记录，或者调一个接口拿回一大段日志。如果把完整结果塞进上下文，工作记忆瞬间就被占满了。我现在的做法是给工具返回结果接一个“提取-压缩”层：先用结构化提取逻辑把关键字段抽出来，比如订单号、状态、金额、时间、异常项，再用大模型做一次轻量摘要，只保留与当前任务直接相关的部分。
检索片段也是同样的逻辑。从长期记忆或知识库召回的 topK 条目，不能直接拼接进 prompt。我会先做一次相关性重排，只取前 3 到 5 条；然后对每条做摘要或截断，把每条的 token 控制在 300 以内；最后还要检查一条：如果检索结果与当前任务完全没有语义关联，宁可不要，也不要硬塞。这个“宁缺毋滥”的原则很难量化，但对模型输出的稳定性影响极大。
我在一次测试中发现，检索结果里塞入一条与用户需求高度相似但实际不同的旧订单信息后，模型出现了一次严重混淆，把旧订单的金额当成当前订单的金额输出。后来我固定了两道防线：一是检索片段必须附带来源标识和时间戳，二是上下文组装阶段对检索片段做“与当前用户输入的相关性复核”，相似度低于阈值的直接丢弃。这套机制上线后，类似混淆案例基本消失。
2.4 入口闸门的实测效果与一个小工具
整个入口闸门改造完成之后，我做过一次对比测试：同一套订单任务，20 轮对话，分别用“全量历史拼接”和“预算分配+关键消息保护区+检索片段过滤”两套流程跑。全量拼接方案在 40 轮时报错率明显上升，关键约束遵守率只有不到 60%；加了工作记忆管理之后，同样跑到 40 轮，关键约束遵守率稳定在 90% 以上，单次请求的 token 消耗还下降了将近三分之一。
为了提升排查效率，我顺手写了一个很小的调试工具：在每次请求发出前，把组装好的上下文结构打印出来，标注每条内容的来源类型、占用 token 数、优先级分数。这个工具不参与线上逻辑，但调试记忆问题时帮了大忙。很多记忆问题其实是在入口阶段就埋下的，不是模型推理阶段才出现的。看到“哪条信息被丢弃了、哪条信息被压缩了、哪条信息被检索回来了”，判断问题原因要比黑盒猜测快一个量级。
3. 工作记忆内部到底长什么样：状态结构、优先级和时效性
3.1 工作记忆的核心数据结构：多维记忆表
入口闸门决定了哪些数据能进入工作记忆，但进入之后，它们不能被当成一锅粥乱放。我在实现时采用了一个“多维记忆表”的结构，每条记忆记录包含若干个关键字段：记忆ID、内容摘要、原始内容、类型、来源、创建时间、最后访问时间、重要性分数、过期时间、状态。类型字段用来区分用户指令、系统状态、工具结果、检索片段、模型生成结论等不同来源，因为不同类型的记忆在后续处理中的权重和淘汰策略是不同的。
以模拟项目X里的订单任务为例，工作记忆表里会有这样几条记录：一条类型为“用户指令”的记录，内容是“周三前送达”，重要性分数很高；一条类型为“工具结果”的记录，内容是当前订单的配送状态，来源是物流接口；一条类型为“系统状态”的记录，内容是当前步骤处于“确认配送方式”阶段；一条类型为“模型生成结论”的记录，内容是模型根据前两步推断出的初步方案。
把工作记忆拆成多条独立记录，而不是一整段对话文本，最大的好处是每一轮都可以单独更新、降权或删除。比如用户说“不用周三前了，改成周五”，我只需要把那条“周三前送达”记录的状态改为“已失效”，再新增一条“周五前送达”，而不是去修改一整段历史文本。这比把工作记忆实现成“prompt 字符串拼接”要灵活得多，也为后面的优先级计算和遗忘策略提供了操作粒度。
3.2 优先级评分：重要性、时效性和任务相关性如何一起算
有了记录结构，接下来要回答的是：每条记忆该以什么顺序占用预算？我采用的评分公式大致是 baseScore = importance × recencyFactor + relevanceBonus - exposurePenalty。importance 是静态重要性，表示这条信息本身的关键程度，比如“不要放品牌字样”这种否定式约束的基础分就很高；recencyFactor 是时间衰减因子，距离当前时间越近权重越高；relevanceBonus 是动态相关分，根据这条记忆与当前用户输入和当前任务阶段的语义相似度实时计算；exposurePenalty 是一个惩罚项，用于防止同一信息反复出现在上下文中造成冗余。
静态重要性可以由规则引擎预先打标，比如匹配到“必须”“不要”“改成”“多少钱”“几点前”等模式就加分；动态相关性可以由一个轻量级的语义相似度模型来计算，不需要每次调用大模型。在模拟项目X里，我用了一个小的嵌入模型为每条工作记忆生成向量，然后与当前用户输入的向量做余弦相似度，超过阈值的部分作为 relevanceBonus。这种混合计算比纯规则灵活，也比每轮都让大模型评分的成本低很多。
优先级分数的直接用处，是在预算紧张的时候决定谁先被压缩。只要历史区域的 token 占用超过阈值，就从分数最低的记忆开始压缩或淘汰，分数高的保留原始形态。这个机制很朴素，但效果非常直观。我曾经测试过一个极端场景：用户在前三轮提出十个约束，之后连续二十轮都在闲聊，最后突然说“按照所有要求执行”。没有优先级评分时，模型几乎只记得最后几轮闲聊内容；加了评分之后，十个约束里九个都被保留了，任务完成率明显提升。
3.3 信息过期机制：标记、降级与归档候选
优先级评分解决的是“哪些信息值得留”，过期机制解决的是“哪些信息不该继续留”。我给每条工作记忆记录设置了一个 optional 的过期时间字段。对于时效性强的信息，比如“当前正在上传文件”“正在等待接口返回”“本轮临时指定的筛选条件”，过期时间通常设置得比较短，可能是几秒到几分钟；对于持续性较强的信息，比如用户画像中的长期偏好，则不太依赖过期字段，而是靠遗忘策略来处理。
当一条记录过期之后，它并不会直接消失，而是先被标记为“过期”状态，进入降级流程。降级的目标是把它从“活跃工作记忆”移到“归档候选区”。归档候选区在上文里提到的历史保护区之外，它没有独立预算，只是等待被写入长期记忆或被彻底清理。这样设计的考虑是：信息即使过期了，也可能对后续任务有参考价值，比如用户曾经要求“周三前送达”，虽然这次已经改成周五，但如果别的任务里又出现类似场景，这条历史经验是有用的。
我特别强调一个细节：过期不等于删除。直接删除太激进，因为一旦后续用户反悔说“还是按原来说的周三吧”，模型就需要重新获取信息；而如果信息已经降级到归档候选区，恢复起来就很容易。在模拟项目X里，我实际遇到过一次用户改回原约束的情况，当时我差点把“周三前送达”直接从库里删掉，后来发现它是“已失效”状态，只需要把状态改回“活跃”就能恢复。这种可逆设计给工作记忆换来了很大的容错空间。
4. 压缩和遗忘：工作记忆腾出空间的两种手段与我的踩坑记录
4.1 摘要压缩的触发时机、实现方式与质量陷阱
当工作记忆里的记录太多、token 预算不够的时候，压缩是比淘汰更温和的手段。最常用的方式是摘要压缩：把一段较长的对话历史交给模型，让它生成一段更短的摘要，用摘要替代原始文本进入后续请求。摘要压缩的触发时机我定成两个：一个是历史消息区的 token 占用达到预算的 60%；另一个是当前任务阶段发生了明显切换，比如从“收集信息”阶段进入“确认下单”阶段。这两者都意味着原有细节的重要性开始下降，可以用摘要承载上下文信息。
摘要压缩的实现方式有直接让大模型归纳一整段历史和分层摘要两条路。直接归纳简单，但一开始就压缩容易丢失关键细节；分层摘要的做法是先按小段落分别生成摘要，再把摘要继续向上合并，得到一棵摘要树。查询时可以从相应层级取摘要。我在模拟项目X里用的是折中方案：先按每 5 轮一组生成底层摘要，再在需要时把多条底层摘要合并成高层摘要。这样既能控制 token 消耗，又能在需要细节的时候回溯到原始消息。
摘要压缩有一个非常隐蔽的质量陷阱：模型在压缩时容易丢掉否定词和精确数字。比如原始对话里用户说“不要改价格”，摘要可能变成“用户提到价格”，含义就完全反了。我在测试中发现，包含“不要”“取消”“拒绝”“排除”这类否定表达的片段，被摘要污染的概率非常高。之后我定了一条硬规则：含有否定词、具体数字、日期、地址、ID 的消息不允许参与摘要压缩，必须保留原始形态。只有那些背景性、解释性、闲聊性的内容才允许进入摘要。
4.2 遗忘不是简单删除，而是分级降级
遗忘机制解决的是工作记忆里那些既不能压缩、又不需要保留的信息。我把它设计成四级降级通道：活跃态、可压缩态、可丢弃态、长期态。活跃态保留原始记录，参与每轮的优先级计算；可压缩态只保留摘要，原始内容进入归档区；可丢弃态只保留实体索引，比如“用户曾提到某个订单号”，但不再保留详细描述；长期态则是写入持久化存储之后的状态。
每一轮更新时，系统会扫描所有记录，按照优先级分数和状态自动降级。分数低于活跃阈值的先降到可压缩态；在可压缩态里停留超过一定轮次、且没有被访问过的，继续降到可丢弃态；可丢弃态的记录如果再次被检索命中，则重新升级回活跃态。这个机制的灵感来自缓存系统里的 LRU，但比 LRU 多了一个重要性维度。纯粹按“最近最少使用”淘汰对 AI 任务并不合适，因为某些关键约束可能很久没有出现在对话里，却仍然必须保留。
自动升级的路径同样重要。用户偶尔会重新提到一个老早之前的信息，比如“还记得我之前说过的那个地址吗”。如果没有升级机制，这条信息可能已经被降级到可丢弃态，模型即使检索到也拿不到完整内容。我的做法是：当用户当前输入与某条可丢弃态记录的实体索引匹配成功时，触发一次召回，把原始内容拉回工作记忆并标记为活跃态。这样既保证了遗忘曲线的平滑，也不会彻底切断旧信息的可访问性。
4.3 一次遗忘策略过激导致的订单任务事故复盘
这部分我想讲一个真实的踩坑过程。模拟项目X曾经有一版遗忘策略非常激进：只要对话轮次超过 30 轮，就直接从最早的消息开始裁剪，剪掉的内容不保留摘要，也不进长期记忆。上线没几天，就有测试反馈说模型在最后确认订单时漏掉了“打印赠言”这个要求。排查链路是这样的：我先把最后一次请求的上下文结构打印出来，看到的结果是“打印赠言”这条消息在第二轮被用户提出，但在第 28 轮时被简单裁剪掉，完全消失了。
然后我去查日志里 28 轮前后的内存状态，发现这条消息当时的重要性分数并不低，因为它是用户显式指定的附加服务。问题出在裁剪逻辑没有考虑重要性分数，它只按时间先后顺序裁剪。也就是说，这个 bug 不是模型判断错了，而是我自己的工作记忆数据结构在入口阶段就丢弃了关键信息。后来我把裁剪逻辑改成“优先淘汰分数最低的记录”，同时为所有显式指定类消息强制标记为不可裁剪，除非用户明确表示取消。
这次事故让我定下了两条固定规则：第一，任何遗忘策略都必须经过“关键约束恢复测试”，流程是构造一个包含若干显式要求的超长对话，跑到末尾时看模型是否还能复述所有要求；第二，生产环境里的记忆管理日志至少保留一周，一旦出现任务断裂，第一件事不是调模型 prompt，而是回放上下文结构，看信息是在哪个阶段被压缩或被淘汰的。这两条规则后来救了我很多次。
5. 工作记忆和长期记忆怎么倒腾：检索回填与异步固化
5.1 什么样的信息值得固化进长期记忆
工作记忆里的信息不能一直只活在内存里，否则会话一结束就全丢了。所以每次会话进行中或结束时，需要把一部分有价值的信息异步固化到长期记忆。我在工程上定义了几类“必固化”信息：用户显式表达的偏好和规则，比如“以后订酒店都选无烟房”；任务完成后产出的关键结论，比如“这个订单最终选择了顺丰加急”；多次反复出现的实体信息，比如用户在不同轮次里重复提到同一个收货地址；以及发生过冲突且已经消解的信息，比如“用户曾要求周三后又改为周五”。
固化动作应该在后台异步执行，不能阻塞主对话流程。因为长记忆写入涉及向量化、存储和索引更新，如果放在用户请求的关键路径上，会明显拉高响应延迟。我在模拟项目X里把固化和检索都放到了单独的执行队列里，会话主流程只负责读写工作记忆，长期记忆层通过事件队列接收更新请求。这样的解耦让长期记忆的后端即使短暂不可用，也不会影响当前对话的响应。
固化之前要做的最后一道检查是去重和合并。有些信息在多次会话中反复出现，直接插入会产生重复记录，导致日后检索时召回多条互相矛盾的版本。我给每条长期记忆记录加了“来源会话ID”和“首次创建时间”，固化时先按实体标识查一次历史库，如果已存在则执行合并而不是新增。合并策略是保留最新值，但把旧值作为历史版本挂在该实体下，方便溯源。
5.2 检索回填如何不污染当前任务
长期记忆不能只进不出，它需要在合适的时机把信息重新送回工作记忆，这个过程我习惯叫检索回填。回填的难点不是“找到相关的”，而是“不要污染当前任务”。如果每次请求都把与用户画像相关的所有长期记忆塞进上下文，模型很容易被背景信息带偏。比如用户当前在问“这个订单什么时候到”，系统如果回填了用户过去三个月所有购物偏好，模型反而可能开始推荐商品而不是回答问题。
我的做法是分三步：先用当前用户输入加上工作记忆摘要里的关键实体，构造一个检索查询；然后从长期记忆库召回 topK 候选；最后再用一个轻量级相关性模型对候选做重排，只保留与当前任务直接相关的条目进入工作记忆。回填的条目同样会带着来源标识和时间戳，并标注“背景信息”而不是“当前指令”。这非常重要，因为模型对“当前指令”和“背景信息”的权重判断完全不同。
还有一条很实用的经验：检索回填失败时，宁可少回填也不要强行凑数。如果相关性重排之后只有一条记录达标，那就只回填一条。如果一条都不达标，就不要回填。硬塞无关长期记忆造成的上下文污染，比缺失背景信息造成的理解偏差更难修复。因为前者会让模型“一本正经地跑题”，后者至少还能让模型诚实地承认自己不知道。
5.3 新旧信息冲突时的一致性处理
长期记忆回填之后，经常会出现新旧信息冲突的情况。比如长期记忆里存着用户“选择普通配送”的偏好，但当前对话里用户刚说了“这次用加急”。如果按照旧偏好执行，模型就会做错。解决这个问题的核心思路是给每条信息标“版本时间”，并且让“当前工作记忆里的显式指令”优先级永远高于“长期记忆里的历史偏好”。
我在工作记忆数据结构里加了一个“冲突消解”字段，当检索回填的信息与当前工作记忆中的某条指令发生语义冲突时，系统不会自动丢弃任何一条，而是把两条都放进上下文，但明确标注时间顺序。比如在 prompt 里呈现为“长期偏好：用户通常选择普通配送；但当前会话最新指令：本次使用加急”。模型看到这种显式的先后关系后，通常能正确理解当前指令覆盖旧偏好。
还有一种更隐蔽的冲突：模型自身在推理过程中产生了某个初步结论，被写进工作记忆，后来用户又给出了不同信息。这种情况我选择“模型结论永远低人一等”，凡是模型自己生成的内容，在记忆表里的状态标识是“推测”，不参与冲突消解，只能作为待确认信息。除非用户明确认可，否则模型推测内容不允许覆盖用户显式提供的信息。这套规则虽然简单，但让整个记忆体系的可靠性上了一个台阶。
6. 落地阶段的取舍、测试方法和个人固定动作
6.1 一套可以直接抄的初始配置参考
如果你打算做一个带记忆管理的 AI 原生应用，却没时间从零调参，可以参考我在模拟项目X里稳定运行的初始配置。这个配置不是最优解，但它是很好的起点：上下文窗口按 32K 来规划，系统指令区 3K，当前用户输入 2K，检索结果区 4K，工具返回区 3K，历史与工作记忆区 20K。历史区里，关键消息保护区占 40%，普通历史占 60%。压缩触发阈值设定为历史区 token 达到 60%。重要性评分里，显式指令类消息的基础分设为 0.9，工具结果类默认 0.5，闲聊内容默认 0.2；时间衰减因子按每 5 轮下降 0.1。
这些数字不是玄学，背后是对成本和效果的权衡。系统指令区、检索结果区、工具返回区的预算需要根据实际场景调整。如果你的应用工具调用很少，可以把工具返回区预算让给历史区；如果知识库检索非常核心，则应该保住检索结果区的空间。我建议在初期保持总预算等于窗口大小的 90% 左右，留出 10% 的余量，因为上下文组装过程中 token 数的计算会有小幅误差，实际模型 tokenizer 计算可能与预估不一致。
6.2 记忆压力的测试方法：构造长轮次任务
记忆管理这种模块，普通的功能测试很难发现问题，因为它出错的时候往往在几十轮之后。我建议专门设计一套“记忆压力测试”。核心思路是构造一个需要长上下文配合才能完成的任务，里面包含多个显式约束、多个状态变更、若干次信息修订。比如让助手处理一次行程规划：用户在第一轮给出五个约束，中间十轮不断追加和修改细节，最后二十轮穿插大量无关闲聊，然后在倒数第二轮突然要求“按照所有最终确认的信息生成一个汇总”。
测试完成后，检查模型输出是否完整复述所有“最终确认”的约束，以及是否被中途已经废弃的旧信息干扰。每次修改遗忘策略或压缩策略之后，都要把同一套任务重跑一遍，对比关键约束遵守率。我在模拟项目X里用 10 组不同的长轮次任务做回归，任何一组的关键约束复述率低于 85%，就不允许上线。
还有一个容易被忽略的测试点：并发会话和记忆隔离。多用户同时使用同一个应用时，工作记忆的数据结构必须是会话级别的隔离，不能在用户之间串用。实际操作中，我会给每条工作记忆记录加上会话ID，并在每次请求入口做一次强制过滤，确保只有当前会话ID的记录能进入上下文组装。这个过滤逻辑非常基础，但一旦漏了，会出现比工作记忆失效严重得多的数据安全问题。
6.3 我现在的固定动作与下一步想试的方向
经过这几个版本的迭代，我形成了一些固定动作：改记忆模块前先画清楚数据流图，标注每条信息从哪个环节进入、在哪个环节被压缩、在哪个环节被淘汰；每次上线前跑记忆压力测试；每次出问题先查上下文组装日志，而不是先调 prompt。这些动作听起来很基础，但确实是让我从“觉得模型不行”转变到“发现应用层没管好记忆”的关键。
下一步我想试的方向是让工作记忆具备更主动的自我反思能力。目前的优先级评分和遗忘策略都是偏静态的规则，虽然稳定，但不够智能。理想的情况是，在任务的关键节点，模型可以评估当前工作记忆里是否缺少必要信息，然后主动发起检索或询问用户。这相当于给工作记忆加一个“缺口检测器”，而不是被动地等数据进来。另外，我也想试试多智能体场景下共享工作记忆的方案，看看几个子任务如何在一个公共记忆表上协同更新，同时避免互相覆盖数据。这条路还有很多坑，但至少方向是清楚的：把 AI 原生应用的记忆从“堆数据”变成“管数据”，效果提升的幅度远超换一个更强模型。
