企业官网建设流程全解析

做原生AI应用最容易被低估的坑，恰恰是短期记忆。前阵子有个朋友找我复盘，他做的AI助手用的是一线大模型，功能做得挺全，可用户一聊超过十轮就开始"犯迷糊"：用户上半段刚说过"我对坚果过敏"，下半段它就能推荐含花生的零食；聊到第十分钟，用户早已确认过三次的使用场景，它还在反复追问。这种"金鱼记忆"问题，我自己的项目里也踩过不少次——不引入外部向量数据库、不做复杂长期记忆系统的前提下，怎样靠工程手段把一个原生应用在单次会话里该记住的东西守住，其实是有很实用的套路可循的。这篇文章就把我验证过的7种提升原生应用短期记忆性能的实战技巧梳理出来，原理、代码、踩坑写在一起，希望能帮各位少走弯路。

1. 先说清楚：短期记忆和长期记忆到底分界在哪里

1.1 一个容易被忽略的前提：短期记忆不等于"会话历史"

很多人一聊短期记忆就默认是在说"把聊天记录都拼进Prompt"。但严格来说，短期记忆指的是应用在不依赖外部持久化存储的情况下，在进程内维护的那部分"当前任务所需的上下文信息"。

它有三个典型特点：

• 生命周期短：一次会话结束，或者一个Agent任务完成，这块记忆就可以被清理。
• 容量受限：模型的上下文窗口就那么大，系统提示词、用户输入、工具返回结果都要挤在这块"考场记忆"里。
• 数据变化快：用户每说一句话、工具每次返回结果，记忆都可能要更新。

我见过不少团队上线了完整的向量库+长期记忆系统，结果短期对话还是频繁出错。原因就是他们把"记忆"这件事都外包给了检索链路，反而忽略了本地这一层基础的上下文管理。长期记忆解决的是"跨会话身份与偏好"的问题，短期记忆解决的是"本会话内任务连贯性"的问题，两者是叠加关系，不能互相替代。

1.2 短期记忆失效的四种典型症状

要判断自己的应用是否存在短期记忆问题，可以对照下面这几种现象。

我之前做过一个数据看板的对话式BI应用，用户在第2轮说"只看华东大区的增速"，第8轮问"那华北呢"，模型直接连着华东一起算了。查了日志才发现，系统每次把最近20轮原始文本全部堆进Prompt，重要约束被一长串中间对话给冲掉了。这就是典型的"信息稀释"加"错误坚持"同时发作。后面我把记忆结构改成下面要讲的第3、第4种技巧组合之后，这个问题才彻底解决。

2. 技巧一：给上下文窗口做"预算管理"

2.1 为什么上下文预算是一切记忆优化的地基

提升短期记忆性能，很多人的第一反应是"怎么往Prompt里塞更多东西"，但正确的方向恰恰相反——是怎么在有限的窗口里做减法。

大模型读Prompt时，注意力机制不是均匀分配的。给一个5000 Token的上下文，前面的系统指令和中间大段历史文本，实际在生成时对输出质量的贡献差异非常大。研究上有个共识：放在Prompt头部和尾部的内容更容易被模型"记住"，中段信息容易被忽略（这就是所谓的"Lost in the Middle"现象）。所以上下文预算管理做得好，不仅省Token，更是直接提升记忆的"感知效果"。

我一般把上下文窗口切成四块来做预算管理：

• 系统提示词与记忆锚点：固定不变的行为设定、记忆格式说明，控制在1500 Token以内。
• 结构化工作记忆：当前用户核心诉求、关键约束、待办事项等，500到800 Token。
• 最近对话历史：最近几轮原始对话，按1:1的Token预算保留。
• 当前轮输入+工具返回：实时数据，预留至少40%的空间。

2.2 一个可落地的Token预算分配逻辑

下面这个Python函数是我在一个客服机器人项目里用过的简化版预算分配器。它的思路很直接：先把当前输入和工具返回额定住，再扣掉系统提示词和结构化记忆的固定开销，剩下的空间才分配给历史轮次。

from typing import List, Dict import tiktoken class ContextBudget: def __init__(self, max_tokens: int = 8000): self.max_tokens = max_tokens self.enc = tiktoken.get_encoding("cl100k_base") def count(self, text: str) -> int: return len(self.enc.encode(text)) def build_prompt( self, system: str, working_memory: str, current_input: str, history: List[Dict[str, str]], reserved_ratio: float = 0.4 ) -> dict: # 1. 先固定当前输入和系统提示词 current_tokens = self.count(current_input) system_tokens = self.count(system) memory_tokens = self.count(working_memory) # 2. 计算剩余可分配给历史的预算 reserved = int(self.max_tokens * reserved_ratio) available = self.max_tokens - reserved - current_tokens - system_tokens - memory_tokens # 3. 从最新一轮向前分配，超过预算就停止 selected_history = [] used = 0 for turn in reversed(history): turn_text = f"{turn['role']}: {turn['content']}\n" turn_tokens = self.count(turn_text) if used + turn_tokens > available: break selected_history.insert(0, turn) used += turn_tokens messages = [{"role": "system", "content": system}] if working_memory: messages.append({"role": "system", "content": f"[工作记忆]\n{working_memory}"}) messages.extend(selected_history) messages.append({"role": "user", "content": current_input}) return { "messages": messages, "stats": { "total_tokens": system_tokens + memory_tokens + used + current_tokens, "history_tokens": used, "history_turns": len(selected_history), } }

这套逻辑的核心就是不把历史当"无限缓存"，而是当"有限带宽"。实测下来，把预留比例调到0.3到0.4最稳——太少了当前任务发挥受限，太多了历史又挤占注意力。

2.3 预算管理中最容易翻车的地方

预算管理看着简单，实际有坑。最常见的坑是把工具返回的结果整段塞进当前轮。一个查询接口可能返回几千行JSON，模型根本消化不了，还占掉大量预算。正确做法是在工具侧就做摘要或截断，只保留字段名、关键数值、总行数这些"元信息"。

另一个坑是系统提示词里塞了容易变长的例子。有人喜欢在系统Prompt里放Few-shot示例，示例一多，几千Token就被固定开销吃掉了。我的建议是：示例不要超过两个，能放进结构化记忆字段就别写死在系统提示词里，方便动态调整。

3. 技巧二：三层记忆架构——原始缓冲、工作记忆与滚动摘要

3.1 为什么只保留"最近N轮对话"不够用

预算管理解决的是空间分配问题，但"保留最近N轮"本身并不是一个好的记忆策略。原因有两点。

第一，最近的不一定最重要。用户在第5轮提过一个关键需求，第6到10轮都在闲聊，如果只保留最近5轮，那个关键需求就丢了。

第二，原始对话的冗余度太高。10轮里可能只有3轮包含关键信息，剩下7轮是寒暄、修正口误、语气词。把原始文本全部保留，是在用Token买噪声。

所以我更推荐把短期记忆设计成三层结构：原始缓冲层、工作记忆层、滚动摘要层。

• 原始缓冲层：保存最近1到3轮完整原始对话，主要用于兜底，防止工作记忆提炼时漏掉细节。
• 工作记忆层：从原始对话中抽取的结构化信息，包括用户目标、偏好、约束条件、临时实体等。这是每轮都要刷新并参与Prompt拼接的核心记忆。
• 滚动摘要层：对更早但仍有价值的对话做摘要压缩，按需参与拼接。它介于短期记忆和长期记忆之间，本质是"压缩后的历史"。

3.2 三层的迁移时机与触发条件

这三层之间不是静态的，而是随对话推进不断迁移。我总结了一套触发规则。

class MemoryManager: def __init__(self, max_raw_turns: int = 3, max_working_tokens: int = 800): self.raw_buffer: List[dict] = [] self.working_memory: dict = {} self.summary: str = "" self.max_raw_turns = max_raw_turns self.max_working_tokens = max_working_tokens def add_turn(self, user_text: str, assistant_text: str, extractor_fn) -> str: # 1. 新对话先进入原始缓冲层 self.raw_buffer.append({"user": user_text, "assistant": assistant_text}) # 2. 将本轮关键信息更新到工作记忆 extracted = extractor_fn(user_text, assistant_text) self._merge_working_memory(extracted) # 3. 如果原始缓冲超长，触发摘要压缩 if len(self.raw_buffer) > self.max_raw_turns: stale = self.raw_buffer.pop(0) new_summary = self._compress_with_model(stale, self.summary) self.summary = self._truncate_summary(new_summary, self.max_working_tokens) return self._format_for_prompt() def _merge_working_memory(self, extracted: dict): # 只更新变化的字段，不整体替换 for key, value in extracted.items(): if value is not None and value != "": self.working_memory[key] = value def _format_for_prompt(self) -> str: parts = [] if self.summary: parts.append(f"[历史摘要]{self.summary}") if self.working_memory: parts.append(f"[工作记忆]{self.working_memory}") if self.raw_buffer: parts.append("[最近对话]") parts.extend(self.raw_buffer) return "\n".join([str(p) for p in parts])

触发压缩的准则我调过好几轮，最终固定成三个条件，满足任意一个就压缩：

• 原始缓冲超过3轮；
• 工作记忆的Token估算超过800；
• 滚动摘要本身超过500 Token。

3.3 滚动摘要别用"一次性重写"，要用增量更新

这里特别想强调一个容易踩的坑：滚动摘要的生成方式。很多初版实现是每次压缩时把"旧摘要+新对话"一起丢给模型重新生成一个长摘要，这种方式有两个问题：一是每次都触发全量重写，Token开销大；二是模型可能把前面已经压缩过的内容再次改写，关键实体出现漂移。

我用的增量更新策略是：把旧摘要当作上一轮的压缩结果，只把新剥离出来的这一轮对话交给模型，让它输出"把这轮内容合并进旧摘要后的更新结果"。这样每次压缩只增加少量Token，关键是摘要的稳定性会好很多。

4. 技巧三：用结构化记忆格式替代"整段自然语言历史"

4.1 自然语言历史 vs 结构化记忆的差距

同样一段用户信息，"张三想在下周五之前上线活动页，主色调用深蓝，不能出现品牌名，需要支持移动端"——按自然语言存进历史，和按结构化JSON存进工作记忆，模型的使用效率完全不同。

原因在于：模型从自然语言历史里提取信息时，是一个"重新检索+推断"的过程，容易漏；而从结构化字段里读取信息，本质上更像是"查表"，准确率高得多。所以虽然工作记忆也需要写成自然语言句子拼进Prompt，但在内部存储和更新层面，必须先结构化成字段。

我常用的是下面这套JSON Schema，包含用户意图、偏好、约束、实体和状态机五类信息。

{ "goal": { "description": "用户当前目标", "status": "in_progress", "last_updated_round": 5 }, "preferences": { "style": "deep_blue", "platform": "mobile", "tone": "professional" }, "constraints": [ { "type": "deadline", "value": "2025-04-18", "source_round": 3 }, { "type": "negative_rule", "value": "禁止出现品牌名", "source_round": 4 } ], "entities": { "user_name": "张三", "project": "活动页上线" }, "state": { "current_step": "design_review", "completed_steps": ["requirement_confirmation", "copywriting"] } }

这套结构的好处是方便做字段级更新。当用户在第8轮说"主色调还是用浅蓝吧"，只需要更新preferences.style这一个字段，同时把source_round改成8，不需要重建整段记忆。而且在Prompt里呈现给模型时，还可以按活跃度排序，把最新更新的字段放在最前面。

4.2 如何从对话里稳定抽取结构化记忆

抽取这一步，我建议不要搞"自由发挥"式抽取，而是给模型一个固定的抽取模板，让它只输出JSON。下面是我在项目里用的抽取提示词骨架：

从用户输入和助手回复中抽取如下信息，以JSON返回： 1. goal：本轮是否表达了新目标，或对旧目标的修改 2. preference：用户明确表达的好恶 3. constraint：任何限制性条件（时间、范围、禁止项） 4. entity：重要人名、项目名、编号、地点 5. state_change：明确的状态推进 规则： - 没有变化的信息不要重复输出 - goal如果没变化，用no_change - 约束条件只保留用户的显式表达，不要推测 - 输出必须是合法JSON，不要额外文本

抽取结果再走一个JSON解析器合并进工作记忆。这里有个小建议：解析失败时不要直接抛错，而是整轮重试一次。因为大模型偶尔会输出多余文本，重试时在Prompt里追加一句"上次输出包含非JSON文本，请只输出JSON"，基本就能修好。

4.3 结构化记忆参与Prompt拼接的注意事项

结构化记忆不是越多越好。字段一多，反而会稀释模型的注意力。我建议工作记忆层控制在5到8个字段，超过这个数就做层级裁剪。比如，不活跃的旧约束可以先移到滚动摘要里，只保留"当前仍有效"的活跃约束。

另外还要注意，JSON本身也是Token，打印格式越紧凑越好。不要把结构化成漂亮的缩进排版存进记忆区，那是在白白烧Token。

5. 技巧四：基于重要度评分的记忆裁剪，不要只按时间窗口

5.1 时间窗口裁剪的痛点

最简单的记忆裁剪是"保留最近N轮"，这也是很多AI Agent框架的默认行为。但实际业务里，这种策略经常导致"关键需求被闲聊挤掉"。

举个例子：用户先说要分析"华东Q2销售数据"，然后连着聊了5轮人员调动安排，第7轮又问"我刚才说的销售口径是含税还是不含税"。如果只看最近5轮，那个"销售口径"问题对应的上下文早就被挤出去了，模型只能靠猜。

所以要给每条记忆打分，分低的才淘汰。打分不能只看"新旧"，还要看"引用频率"和"任务相关性"。

5.2 一个简单可用的重要度评分模型

我实际在用的评分逻辑是综合三个维度：

• 时效性：距当前轮次的衰减，衰减系数按业务线的对话节奏调整。客服场景衰减快一点，分析协作场景衰减慢一点。
• 引用频率：如果后面几轮对话里多次出现同一个实体或同一个约束，说明它仍然活跃，加分。
• 任务相关性：与当前goal描述里的关键词做语义相似度匹配，向量算相似度也行，字符重叠度也行。

整体算一个加权分，低于阈值就移出工作记忆，扔进压缩层等待摘要。

class ImportanceScorer: def __init__(self, decay_rate: float = 0.85): self.decay_rate = decay_rate self.reference_counter = {} def score(self, memory_item: dict, current_round: int, current_goal_terms: list) -> float: # 时效得分 age = current_round - memory_item["source_round"] recency = self.decay_rate ** age # 引用频率得分 key = memory_item["key"] frequency = min(self.reference_counter.get(key, 0) / 5.0, 1.0) # 任务相关性得分 item_terms = str(memory_item.get("value", "")).lower() relevance = sum(1 for term in current_goal_terms if term in item_terms) relevance = min(relevance / 3.0, 1.0) return 0.4 * recency + 0.35 * frequency + 0.25 * relevance

如果你不想自己写这套逻辑，直接复用一些开源Agent框架里的Message Window隔离策略也可以，但在项目里需要做二次验证，因为老外的默认参数往往不适合国内真实业务场景的对话密度。

5.3 记忆更新时最怕"频繁改写，越改越偏"

裁剪之外还有另一个坑：记忆更新得太激进，导致关键信息被"覆盖"。比如用户说"这个方案差不多了"，模型就把constraints里的条件删掉了一半，结果第12轮用户又说"删除的第三条约束还是要保留的"，这时候已经找不回来了。

我的处理经验是做带来源轮次的版本式存储。每次更新不直接覆盖旧值，而是记录当前生效值和来源轮次；只有新指令确实与旧值冲突时，才把旧值挪到"待确认"区。这样可以避免因为一句模棱两可的话，丢掉用户前面反复确认过的信息。

6. 技巧五：区分"指令型记忆"与"事实型记忆"，分别对待

6.1 两类记忆的处理方式完全不同

做记忆优化之后，我越来越觉得有一个分类特别有价值：把短期记忆分成指令型和事实型。

• 指令型记忆：用户说"接下来每一轮输出前都要先检查约束""每次报价都给我列出含税价"。这类记忆有强制性，而且要一直生效，直到用户明确取消。
• 事实型记忆：用户说"我是华东区的""项目代号是Astra""目前预算还剩2万"。这类记忆是数据，可被新事实覆盖修正。

两类记忆的差异在于更新规则。指令型记忆默认不被新对话覆盖，除非用户明确表达"取消那条规则"；事实型记忆则默认接受新事实覆盖，因为新信息更接近真实情况。

如果混为一谈，就会出问题。比如用户先说了"以后报告都用PDF格式发我"（指令型），后面又提到"那个PDF格式的报告我收到了"（事实型），如果按事实型逻辑处理，模型可能把"用PDF格式发送"这条指令当作普通事实，不做强约束，结果后续就忘了格式要求。

6.2 在结构化记忆里给两种类型打标签

我的做法是在结构化记忆里显式增加一个type字段，并围绕它设置读写规则：指令型读取时放在Prompt更靠前的位置，以"强制规则"的形式出现；事实型读取时放在普通上下文里，以"状态记录"的形式出现。这样模型对两类信息的处理权重完全不同。

一段实际的记忆序列长这样：

{ "type": "directive", "content": "每周五下午5点前发送周报", "source_round": 2, "status": "active" } { "type": "fact", "content": "团队共12人，其中后端5人", "source_round": 7, "status": "active" }

6.3 指令型记忆的撤销机制

指令型记忆必须能撤销，否则它会变成"幽灵指令"，一直在后续对话里捣乱。我建议每次对话开始时做一个快速检查，把所有直接指令列给用户确认，或者在发现新指令与旧指令明显矛盾时，先输出一句"听起来你想修改之前的规则，是否确认？"再更新。这在金融、客服这类强合规场景里尤其重要。

7. 技巧六：用"记忆回放"对抗长对话的信息稀释

7.1 为什么长对话里，中段信息容易被遗忘

长对话进行到二三十轮时，就算有了预算管理和结构化记忆，还是会出现"中段信息被遗忘"的问题。原因在于Transformer的注意力机制天然偏向开头和结尾，中间部分的记忆痕迹会随长度增加而衰减。

很多框架选择的方案是"把摘要放回上下文"，这在某种程度上能缓解，但摘要本身是二次压缩，还是会丢失细节。这时候可以引入一个思路——记忆回放：在关键节点，把重要记忆以"重新播报"的形式强调一遍。

7.2 记忆回放的三种落地姿势

第一种是主动回放。每隔N轮，或者在某段长任务的中间节点，把工作记忆中的关键字段整理成一小段"当前进展回顾"注入上下文。这就像写代码时在长方法中间打日志，提醒模型现在进行到哪里了。

第二种是被动回放。当用户的话语中出现了与工作记忆里某个字段相关的关键词，就自动把那一条记忆以更强的权重附加到当前输入附近，而不是放在很远的历史位置。这个适合用来解决"用户随口提到两轮前的一个编号，模型想不起来"的情况。

第三种是冲突回放。当模型准备执行一个与现有约束可能有冲突的操作时，先把冲突的约束条件重新展示一遍。这点在工具调用类Agent里特别有用，能在模型调API之前，就拦住不符合约束的调用。

下面是一个很简化的回放触发逻辑：

def replay_if_needed(working_memory: dict, current_input: str): triggered = [] for item in working_memory.get("constraints", []): # 关键词重叠检测，达到阈值就触发回放 overlap = len(set(item["value"]) & set(current_input)) if overlap >= 2: triggered.append(item) if triggered: return { "role": "system", "content": "[关键约束回放] " + json.dumps(triggered, ensure_ascii=False) } return None

7.3 回放机制不要过度使用，否则反而稀释注意力

回放不是越多越好。如果把所有历史信息每轮都回放一遍，那它实际上又变成了全量历史，和没裁剪没区别。我的经验是：一次回放不超过3条，回放的信息必须和当前轮有明确的相关性，且同一轮内不要多次触发回放。

8. 技巧七：善用Prompt前缀的"锚点区"，提高关键记忆的注意力权重

8.1 为什么信息在Prompt中的位置会影响记忆效果

前文提到过"Lost in the Middle"，这就是位置效应。模型对Prompt开头和结尾的内容编码得更充分，对中间内容相对容易忽略。所以与其纠结模型"记性不好"，不如把关键记忆主动放到容易被记住的位置。

具体来说，我会在系统提示词之后紧跟着放一个"记忆锚点区"，这个区域专门放"绝不能被遗忘"的核心信息，比如用户身份、当前最核心的任务目标、必须遵守的三条硬性规则。这样一来，每次请求这个区块都在最前面，模型每次解码时都会先聚焦到这些信息上。

8.2 锚点区如何与其他记忆区配合

我的实际Prompt排布顺序是这样的：

1. 系统提示词（行为设定与工具声明）；
2. 记忆锚点区（2到4条硬性记忆，必须每条都能在一句话里说清）；
3. 工作记忆区（结构化偏好、约束、实体）；
4. 滚动摘要区；
5. 最近N轮对话；
6. 当前输入与工具结果。

注意锚点区与工作记忆区是分离的。工作记忆区可以有很多字段，但锚点区只放那种"丢了就出事"的信息。我之前一个客服项目，把"客户编号"和"当前售后单号"放在锚点区之后，模型就再也没有在对话中段搞混过这两个编号。

8.3 一个反直觉的发现：锚点区信息也会过期

最后分享一个观察：即使是锚点区，也不能永远放同一批信息。锚点区中的硬性记忆要随任务阶段变化而更新。用户的目标从"选品调研"推进到"撰写文案"后，锚点区如果再持续放"选品调研"的目标描述，反而会和当前任务产生干扰。所以锚点区的内容要定期根据goal.status做刷新，和前面结构化记忆里的state字段联动。

9. 七种技巧合起来用，是一个渐进迭代的组合拳

9.1 一个多轮对话场景下的完整演示

上面七种技巧各有侧重，但它们不是孤立的。我把它们在同一个场景里走一遍，大家就能更直观地理解怎么组合。假设你在做一个AI数据分析助手，用户开始对话：

第1轮，用户说："帮我看一下华东区上个月的销售数据，重点看手机品类。"

此时发生了：

• 预算管理器初始化，划分好窗口各区块；
• 抽取器从语句中提取goal（分析华东区上月手机品类销售）、entity（华东区、手机品类）；
• 工作记忆更新，然后拼进锚点区。

第5轮，用户说："对了，手机品类里面剔除低端机，单价800以下的不要。"

发生了：

• 新增constraint（单价800以下剔除），写入工作记忆层；
• 重要性评分启动，把该约束标记为"强相关性"；
• 由于该约束与当前任务高度相关，被动回放触发器已就绪。

第10轮，用户开始闲聊："你们这个工具支持私有化部署吗？"

发生了：

• 目标字段没有变化，闲聊信息不进工作记忆；
• 原始缓冲层保留最近2轮，不影响核心任务；
• 预算管理发现历史预算充裕，不动滚动摘要。

第15轮，用户绕回去问："刚才有几个品类表现不行，你推荐一下主推哪个？"

发生了：

• 被动回放触发器检测到"推荐""品类"与工作记忆中的goal和constraint相关，触发了一次回放；
• 回放的内容包含"华东区""上月""手机品类""剔除单价800以下"，这些信息被放在当前输入附近；
• 模型基于回放的最新上下文，给出推荐，不再犯"忘记剔除条件"的问题。

这样一整套走下来，每一轮都在做"裁剪→抽取→分层→回放→锚定"的循环，而不是简单地把所有历史倒进Prompt。

9.2 从零开始落地时，建议按什么顺序实施

如果项目还在起步阶段，我建议不要一次性全部上，分四步渐进实施：

• 第一步先做预算管理：让上下文窗口的使用变得可控，这是其他所有技巧的前提。
• 第二步上三层记忆架构：把"最近N轮"改成"原始缓冲+工作记忆+滚动摘要"。
• 第三步做结构化抽取和重要度裁剪：让工作记忆真正"提炼"而不是"搬运"。
• 第四步再加回放和锚点区：针对长对话场景做精细化调优。

第四步是锦上添花，前三步是地基。地基打牢之后，很多记忆问题其实已经解决大半了。

9.3 关于"短期记忆再好也无法替代长期记忆系统"的一句话

近几年不少项目把短期记忆和长期记忆一块儿做，这没问题。但如果你只是想快速改善一个原生应用的多轮交互体验，先把短期记忆这层做扎实，收益远比你匆匆接一个向量数据库回来要高。短期记忆层面的问题不解决，外部存储做得再好，信息在进入模型之前就已经丢了，后面再检索也是白搭。

10. 实测数据与四种组合方案的收益对比

为了让大家对"做了这些到底有多大用"有一个体感，我拿一个内部Agent项目做了对照实验。场景是模拟一个20轮的多轮任务对话，用户会在第4、第9、第15轮分别补充三个约束条件，最后在第18轮要求汇总时看看约束保留率。

四种组合如下：

从这组数据能清楚看到几个结论：

• 全量历史的方案不仅贵，效果还差，Token消耗高了一倍多，约束保留率却垫底；
• 单纯做预算管理能省Token，但记忆质量只提升了一点点，原因是"裁剪"本身不等于"记住"；
• 三层记忆架构的提升最明显，说明信息整理结构比单纯的容量控制重要得多；
• 在C的基础上加上结构化抽取和主动回放，Token只多了一点点，用户体验却明显好了。

当然，约束保留率在小样本里能到100%，不代表任何场景下都能做到满分。如果约束本身在语义上容易混淆，或者用户中途改了三次需求，还是会出问题的。但这个趋势是稳定的——结构化、分层、回放这三板斧，是把短期记忆做扎实的通用路径。

这套实验我们跑过三次，结论基本一致。所以我不太相信"换个更强的大模型就能自动记住所有东西"这种说法，上下文管理上的工程投入，目前看是躲不掉的。

11. 几个我认为值得分享的实战心得

聊到最后，把我在实际项目中一次次撞出来的经验写在这儿。

第一，记忆系统的可观测性一定要早做。给每条记忆打上source_round，给每次截断记录日志，否则出了问题你根本不知道是模型没记好，还是记忆在进入Prompt之前就被错误的裁剪弄丢了。我见过太多团队花两周时间调Prompt，最后发现是历史缓冲被某个工具返回结果挤爆了。

第二，评测指标不要只看"是否提到"。做记忆优化时，我建议大家不只检查模型输出里有没有出现那个实体，还要检查它有没有用对。比如"是否提到了华东"算一个指标，"在对比里是否正确区分了华东和华北"才算真正有意义的记忆保持。我后来都是直接把评测集做成"状态更新题"和"约束保持题"，一轮轮自动跑，效果比肉眼看好得多。

第三，短期记忆优化的目标是降低不确定性，而不是塞满信息。最理想的短期记忆状态，是模型每一次读取上下文，都能快速找到当前任务需要的所有关键约束，不要让它从几百行历史里"大海捞针"。

第四，用户的明确纠偏，永远是最高优先级。不管重要性评分系统觉得某条记忆多不重要，只要用户主动表达了修正，就必须立刻更新工作记忆，并且同步刷新锚点区。这既是工程问题，也是产品体验的底线。

最后一句话总结我的态度：短期记忆能力不是某个大模型版本自带的天赋，而是一个需要认真设计、持续维护的工程模块。把预算管理、三层架构、结构化抽取、重要度评分、记忆回放和锚点区这几件事做扎实，原生应用的多轮交互水平会有质的提升。希望这些经验对正在打磨AI应用的你有帮助。