做 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 原生应用的记忆从“堆数据”变成“管数据”效果提升的幅度远超换一个更强模型。 
长河君 · 2026/10/23 6:02:28 · 阅读 1.2k AI原生应用中的大模型记忆管理：工作记忆机制设计与实践
做 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 原生应用的记忆从“堆数据”变成“管数据”效果提升的幅度远超换一个更强模型。