先给结论：记忆增强压缩的核心工作，是把一批反复使用的推理步骤从生成阶段拿出来，提前整理好放进提示词里，用一套稳定的“可复用推理记忆”去替代模型每次从零推导的思维链过程。它针对的是思维链成本问题，更准确地说，是“重复出现的思维链”带来的 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 应用、智能体或者大规模提示词工程，不妨先挑一个出现频率最高的业务场景，用一套有版本号的记忆卡替换它原本的动态推理输出。这个小改动通常会带来两个直观变化：同类请求的输出稳定性上升，单位请求成本更容易预测。至于要不要把所有经验都压进提示词，我的看法是：能压的压，该留在生成阶段的就让它留在那里，刻意压缩反而会牺牲掉模型在复杂问题上的真实推理能力。
