先给结论记忆增强压缩的核心工作是把一批反复使用的推理步骤从生成阶段拿出来提前整理好放进提示词里用一套稳定的“可复用推理记忆”去替代模型每次从零推导的思维链过程。它针对的是思维链成本问题更准确地说是“重复出现的思维链”带来的 token、延迟和输出漂移成本。这个思路特别适合正在做智能问答、问数 Agent、客服辅助、AI 编程提示词模板这类项目的团队因为你们每次请求的 prompt 结构相近但生成阶段仍让模型重新做大量判断。如果你以为这是把回答缓存下来那就理解偏了。缓存看到的是最终答案压缩的是推理路径。同一类问题模型每次都从“分析问题”开始一步步走到结论这个过程会占用大量生成 token。生成 token 往往比输入 token 更贵单价更高耗时也更长。可复用推理进入提示词后模型不需要每次都重新把这些推导过程摆一遍而是直接读取你已经整理好的规则继续执行。我这里会按实际落地顺序聊先讲原理再讲怎么盘点然后给做法和验证指标最后列几个非常容易被坑的地方。1. 记忆增强压缩到底压缩了什么1.1 它的对象是生成阶段的可复用推理不是最终答案模型处理一个问题时大致会经历两个阶段先把问题和上下文一起读进来再去生成回答。思维链通常发生在生成阶段模型一边列出中间判断一边产生最终结论。这类中间判断非常有用能提升复杂任务的准确率。可问题也随之而来如果一类任务每天被触发几十次、几百次模型每次都重新生成一套几乎一样的中间判断成本就会变得很扎眼。比如同样一个“是否为节假日”的判断在值班排班、考勤扣减、加班费计算里都可能被反复使用。你可以让每次请求都从“什么是节假日”开始推演也可以把节假日判断规则单独整理好直接装进提示词里。记忆增强压缩压缩的正是这种“反复推到同一结论”的过程。最终答案不是它关注的重点重点是那些已经被验证过、可以复用的推理链。把它从生成阶段移走之后模型的输出不再每次都从头分析一遍而是拿到规则后直接产出结果。这里有一个容易混淆的点提示词长度可能会变长。既然输入 token 变多为什么还能降低成本因为成本结构发生了变化。原来你要支付的是大量生成 token 的推理费用和时间现在你支付的是提示词里的静态 token 费用还往往能命中缓存或较低单价。生成阶段减少的输出部分通常比提示词里多出来的输入部分更有价值。而且如果服务端支持前缀缓存重复出现的记忆压缩内容还能进一步降低多次调用的成本。1.2 成本账不是“少花一点”而是从输出挪到输入从成本模型上看这个思路很像缓存和预计算。你不再等模型每次都烧输出 token而是调接口前先准备好一段“经验材料”让模型在回答时照着材料走。很多商业模型按输入输出分开计费输出单价普遍高于输入单价。哪怕两边价格一样生成阶段减少的那几百个 token 还会带来响应延迟的下降和输出不稳定性的下降这三点都比单纯省 token 更有意义。不过要提醒你不要为了压缩而压缩。如果一条思维链只在一个一次性难题里出现一次把它提前写进提示词就是多余动作。记忆增强压缩的收益必须来自“可复用”三个字。如果任务本身没有规律推理路径每次都不一样压缩反而会把 prompt 塞得很长模型还容易受干扰。后面我会专门说这种边界条件。2. 动工之前先做一次可复用推理盘点2.1 连续抽取同主题问题观察什么在重复我建议你先不要写任何 Prompt先去看历史日志。不管你是调用模型 API、让 Agent 跑任务还是在一套业务系统里接提示词日志里至少能找出两类信息用户问的是什么模型最终输出了什么。把过去一段时间里主题相似的请求拉出来按业务类型分组。比如考勤计算类请假、加班、调休合同审核类违约条款、赔偿上限、不可抗力数据分析类指标口径、同环比、日活统计代码改动类函数修改影响面、依赖升级风险分组之后同一个组里继续看中间环节。如果模型在回答里反复出现“先确认统计周期再去除周末和法定节假日再计算请假天数”这个步骤就是可复用推理。如果每次生成时它还要根据具体的问题动态决定要不要走赔付计算那这部分会随着输入变化就不能完全固定到提示词里。判断标准并不复杂同一个规则连续出现在很多次回答里证明模型每次都在重新产生它这个规则又可以被独立描述出来说明它具备被提前整理的条件。两者同时满足才值得搬移。2.2 怎样的推理值得搬进提示词不是所有中间推理都适合搬至少要满足三个条件。第一它在一定周期内保持稳定。你整理出一条规则放进提示词等于告诉模型以后都按这个规则处理。如果下个月业务规则突变提示词里的旧记忆会立刻变成过时信息甚至比不写还危险。所以那些政策和判断标准频繁变化的领域需要额外加版本失效机制不能在提示词里一劳永逸。第二它不太依赖某一次具体的上下文。有些推理过程看着很像但每次都要结合用户提供的表格、合同、代码片段来判断。比如“判断合同是否违约”规则本身可以复用但具体违约金额必须看原合同条款。这时候适合搬进提示词的是“判断违约时先看哪些条款项”的推理框架而不是把某一份合同的违约金数字写死。第三它会重复出现且出现频率够高。如果一周出现一次写提示词反而拖累其他任务。如果一天出现几十次几乎每次都要模型重新思考一遍那它对成本和延迟的影响就很大值得做压缩。2.3 不适合搬入的类型不要硬塞有些团队做优化时会把大量边界条件、极端案例全部堆进提示词希望一次解决所有情况。结果 prompt 越来越长模型越到后面越容易忽略前面的指令。以下几类不要硬塞需要查实时数据库的数值判断应该让 Agent 发接口查而不是靠提示词记忆。只出现一次的定制化分析写进全局提示词会污染其他任务。长文本里的结论性推理比如用户上传了 80 页合同要求分析整体风险这需要结合每页内容单独生成不能压缩成固定模板。你还拿不准正确性的规则宁可先让模型动态推导也不要提前放进记忆否则错误会通过固定提示词被稳定地复制。真正好的做法是先做减法。从一堆历史回答里找到那 5% 的规律把它们沉淀下来而不是把所有经验都写成一个巨型提示词。3. 把共性推理做成可维护的提示级记忆3.1 建立触发、步骤、边界、示例四个字段当你决定把某条推理移入提示词时我建议不要直接写一段大白话塞进系统里而是先定义一张“记忆推理卡”。它通常包含四个部分触发条件、执行步骤、边界限制、一个典型示例。触发条件解决的是“什么时候才使用这条推理”。没写触发条件模型会在无关问题上也强行套用。执行步骤告诉模型按什么顺序处理。边界限制划清“哪些情况不做”这一步最容易漏。典型示例则帮模型稳定格式也方便人做 review。我长期用下来比较顺的模板是 YAML 或 JSON。它比自然段落更容易做版本管理也方便在代码里渲染成字符串。改成 YAML 后每次调整规则都像改配置文件不需要反复改提示词模板里的长文本。3.2 一个实用的记忆推理卡示例下面这条示例卡片写的是考勤场景里的可复用推理你可以套到自己的业务里。memory_card: name: 考勤请假核算 version: 1.2 trigger: - 请假 - 工作日 - 应出勤天数 steps: - 确定统计周期例如自然月或指定日期区间 - 获取该周期内的日历工作日 - 排除周末和法定节假日 - 从工作日中扣减请假天数半天按 0.5 天计算 - 若存在加班或调休按公司规则增加对应天数 boundaries: - 请假天数以工作日为单位不包含休息日 - 跨周期的连续请假需要拆分到两个周期分别计算 - 法定节假日调休安排需要以当年通知为准 example: input: 4月请了3天假应出勤多少天 output: 先按日历工作日排除周末和法定节假日再扣减3天请假天数得到应出勤天数。 invalid_when: - 公司考勤制度变更 - 国家法定节假日日期调整后未更新你可以看到这里搬进提示词的不是某个具体的人请了几天假而是一套如何计算的推理路径。真正使用时再把它和某个用户的出勤明细结合起来。3.3 渲染进提示词之后如何避免模型重新推导把卡片存好不等于模型会照做。实际工程里我通常会在调用模型前动态渲染 prompt只把与当前问题相关的记忆卡放进去而不是把所有卡都塞进去。渲染完成后还要在提示词里加一层明确指令。不能只贴卡片然后指望模型自动理解“以后不要再重复推导规则”。在代码里大概是这样一种组装思路def build_prompt(user_query, user_context, rendered_cards): if not rendered_cards: return user_query system_part f 你具备以下可复用推理记忆 {rendered_cards} 当用户问题命中记忆中的 trigger 条件时 1. 直接按 steps 顺序执行 2. 最终回答中只输出各步骤结果和结论 3. 不要重新解释规则的前提也不要从零推导规则的来源。 当用户问题没有被任何规则命中时忽略以上记忆正常回答。 return f{system_part}\n用户问题{user_query}\n相关上下文{user_context}注意这里的关键点是先判断命中再执行。很多失败的案例是命中判断做得太松结果模型把一条考勤规则用到了合同计算场景里。触发条件要写业务关键词但也不能只靠关键词最好让用户上下文里同时出现对应主体比如“员工”、“合同”、“服务器”等实体范围。4. 设计一个能证明效果的对照实验4.1 同一批问题跑两套 Prompt搬完规则后不要直接去生产环境观察费用账单那太粗糙。我建议先做一轮小范围对照实验把问题和回答全部打上版本号。准备一批真实历史问题数量不用太多三十到五十条足够。同一批问题拆分到两个环境基准组用原来的动态生成逻辑优化组用带记忆推理卡的 prompt。如果不想破坏线上环境可以把两组请求都放到离线评估环境里跑只要模型版本一致就有可比性。测试时最好固定随机参数比如温度调成 0 或较低值。否则输出 token 会受随机性影响你很难判断减少的次数到底来自规则还是单纯因为这次回答抽到了短结果。4.2 重点看哪些指标指标基准组优化组怎么看输入 token 数通常较低可能变高记忆卡增加了固定输入输出 token 数通常较高希望明显下降这是主要收益来源首 token 延迟看服务商逻辑观察趋势部分平台要为长前缀计算可能不是立刻变快总耗时作为参考作为参考与网络、并发、缓存相关结果一致性波动大波动小多次重复同类型问题看回答是否稳定规则违反率无法评估越低越好用人工快速判断回答是否遵守了提示词中的步骤失败重跑率若常超时则较高希望降低长输出往往更容易超时这里不要只看“输出 token 减少”还要看“结果对不对”。如果优化后的模型因为规则提示词过强连用户真正想问的深度分析都不做了那省下 token 也没意义。输出质量得靠人工抽查兜底。4.3 前后对比怎么读才不容易被坑有几个典型的坑需要避开。第一个坑是把不同模型版本混着对比。模型本身的输出习惯差异很大必须先锁定同一个模型版本。第二个坑是不开缓存就急着看价格。有些平台会对重复前缀命中缓存打折只有命中缓存后“把推理从生成阶段移入提示词”的成本优势才最明显。对比时要记录缓存命中率而不是只看一次请求的单次调用价格。第三个坑是忽略输入的异常变化。如果同一批问题本来只有几百个输入 token你为了压缩推理往 prompt 里放了上万字规则哪怕输出 token 降了总成本也不一定会降。这时候要认真权衡到底压缩掉多少动态输出才值得放进多少静态输入。第四个坑是只测单条不测总量。单条请求可能只优化了一瞬间真正有影响的是同类型请求在一天内的调用次数。次数不高收效不大次数高才值得把规则做得更细致。5. 为什么你没省到钱反而把输出变长了5.1 先说最容易出现的三种现象方案是好的但落到实际环境中我经常见到几类“反效果”。第一类是输出变长。你越是在提示词里写复杂规则模型越容易在回答末尾重复这些规则像是表示“我严格按照提示词执行了”。结果每次回答都多出一大段复述。这本质上是提示词指令不够明确你没有告诉模型只要执行步骤不要解释步骤来自哪里也不要复述规则本身。第二类是规则被过度使用。你的触发条件写得太宽模型把很多本来不该套用规则的场景也套了一遍。比如你写了一条“关于合同违约”的规则本来只适合买卖合同结果用户问的是劳动合纠纷模型仍然走买卖合同逻辑回答方向全错。这说明可复用推理并没有被准确压缩它被错误地泛化了。第三类是成本确实降了但回答质量明显下降。模型为了减少输出 token把必要的过程省略了直接给你一个结论。用户拿到结果后无法验证体验反而更差。这时候你要考虑到底是省钱优先还是保留可解释性优先。不能为了省 token 把用户真正需要的推导过程也删掉。5.2 沿着现象往配置层排查遇到反效果不要先怀疑这个思路本身先按下面的顺序排查。第一步看触发条件。把每个命中样本拿出来检查规则的 trigger 是否覆盖了你想要的语义。如果无关问题频繁命中就收紧 trigger增加业务主体、问题类型等更多条件。第二步看提示词位置。记忆卡要放在系统提示或公共前缀区域而且越靠近顶部越容易被模型遵循。如果把它放到和用户消息混杂的中间部位模型会把规则当成普通聊天内容遵循度很低。第三步看是否缺少输出约束。在规则后面补一句“只输出该用户问题需要的内容不要逐条列出规则也不要复述记忆卡里的步骤原理”。这一句通常就能抑制模型在回答里复读规则。第四步看静态前缀是否稳定。如果你在每次请求时都动态往记忆卡里追加时间、随机变量、用户身份 ID平台的前缀缓存可能每次都失效计算成本会变高。应该把稳定不变的规则放前面把每次变化的上下文放后面让前面尽量成为可缓存的公共前缀。第五步看记忆卡的版本。规则更新后如果只是改了代码中的字符串而没有更新版本号你很难追踪哪一次调用用的是旧规则。长期维护时版本和生效日期必须保留。5.3 回归集才是这类方案最后的守门人每次新增、修改、删除记忆卡都要准备几十条回归用例。把之前出现过错误结论的问题全部放进回归集里跑一遍确认没有因为新规则而“开倒车”。有些问题表面上被新规则解决了实际它会波及其他任务。比如你为了压缩考勤计算的思维链放入了“如果周期冲突就按最早日期优先”这样的规则。它本意是解决跨周期问题却可能影响排班模块里“哪些日子需要加班”的判断。回归集存在的意义就是防止这类交叉影响。成本优化的项目最容易犯的错误是只看费用曲线不看错误率上升曲线。建议在监控面板上同时记录两个维度单次请求费用、规则违反率或人工抽检不通过率。两者同时下降才说明方案有效。6. 不要滥用适用边界和下一层优化6.1 当规则数量大、更新快时提示词不是唯一容器记忆增强压缩把可复用推理移进提示词这种做法的边界也很清楚提示词长度不能无限增长。当你沉淀出几十上百条规则时不能把全部记忆卡一次性塞进系统提示词。这时的选择不是放弃而是分层。比较确定、只涉及少量字段的判断可以直接写进代码或工作流。例如“节假日是否属于调休”这类强规则如果能从日历服务拿到结果就让 Agent 调用工具不要留在提示词里。需要自然语言判断、解释和边界场景处理的规则放提示词里更方便。比如“合同违约是否影响项目交付”这件事往往涉及很多模糊变量代码很难穷举这时候用提示词模板保留推理框架更合适。因此不要期待一条提示词把所有业务经验闭环。提示词、代码、外部检索、模型微调是几个不同层次的容器每条规则应该落到它最适合的层。6.2 它与 RAG、工作流编排不是一个层级的方案需要区分清楚记忆增强压缩不是 RAG 的替代品。RAG 解决的是“外部知识怎么被找到并放入上下文”记忆增强压缩解决的是“已经知道的可复用推理怎么被提前组织起来避免模型重复生成”。两者可以协同使用。比如在智能问数 Agent 里你可以先用 RAG 从资料库中检索出相关业务口径文档再把文档转化后的规则卡作为记忆压缩内容放进提示词。RAG 保证了知识足够新记忆压缩保证了模型不要每次回答前都把口径推导一遍。再比如 AI 编程助手场景项目级编码规范、发布前检查清单、代码改动的风险评估步骤都是天然的可复用推理。把它们抽成固定记忆后新请求只需要补充当前文件差异和用户诉求。这样可以减少生成阶段反复分析同一套工程上下文的问题。在工作流编排里不同的节点负责不同功能。记忆增强压缩适合放在最前面的指令构建节点而不是代替 Agent 的整个决策器。它会给你一条稳定的“规则基线”让后续的生成更可控。6.3 维护策略把记忆压缩当成团队资产来管理最后建议所有做这类优化的团队把记忆推理卡当作资产而不是临时字符串管理。具体动作包括给每张卡设置独立版本号在卡里写明生效日期和失效条件每次增量变更都要留下对比日志对应历史测试样本要归入回归集定期检查每张卡在真实请求中的命中率。命中率很低或已经几个月没有命中的推理卡可以考虑移出全局 prompt改成按需检索或删除避免一直占着上下文。这个思路真正落地时最该盯住的不是“能不能减少思维链输出”这个单点结果而是输入格式、缓存命中、规则触发准确度和回归稳定性。很多人一开始只觉得把固定推理写进提示词就好结果跑了两天发现成本没降反而因为重复规则导致各种乱套。先跑稳单条规则再扩展批量规则是比较稳妥的顺序。如果你正在做 API 应用、智能体或者大规模提示词工程不妨先挑一个出现频率最高的业务场景用一套有版本号的记忆卡替换它原本的动态推理输出。这个小改动通常会带来两个直观变化同类请求的输出稳定性上升单位请求成本更容易预测。至于要不要把所有经验都压进提示词我的看法是能压的压该留在生成阶段的就让它留在那里刻意压缩反而会牺牲掉模型在复杂问题上的真实推理能力。
