企业官网建设流程全解析

长程智能体（Long-horizon Agent）这几年热度一直没降，但真正把它推到生产环境的人都会遇到同一个问题：任务步骤一多，成功率断崖式下降。一开始大家以为是大模型推理能力不够，后来发现，推理模型在短任务上表现很好，一旦拉长到几十步、上百步，模型前后的目标一致性、关键信息保留、错误经验复用都会出问题。换句话说，长程任务的上限，不只是模型推理能力的上限，更是记忆系统的上限。

Recuris 的双记忆机制，恰好是冲着这个痛点来的。它的思路并不复杂：不要把所有上下文都塞给模型，而是区分“正在处理任务时的工作记忆”和“跨任务沉淀下来的长期记忆”，两者协同刷新、按需检索。这个机制真正改善的是长程任务中“记什么、怎么记、什么时候忘”的问题。本文会先讲清楚长程智能体的失败原因，再拆解 Recuris 双记忆机制的核心设计，然后给出一套可以落地的配置、代码和验证流程，最后补充工程落地中真正容易踩的坑。

1. 这篇文章真正要解决的问题

如果你做过 Agent 应用，大概率遇到过这样的场景：

• 让 Agent 完成一个需要调 5 个以上工具、中间还要根据结果做判断的任务，前几步还很正常，到后面突然忘了最初的目标。
• 对话一长，模型开始把之前的中间结果和用户需求混淆，生成的内容看着合理，实际已经偏离主题。
• Agent 在不同的任务之间切换时，上个任务的中间信息污染了下个任务的判断。
• 同样类型的错误反复出现，比如上一次任务已经发现某个工具参数格式不对，下一次任务又栽在同一个地方。

这些问题的共同点在于：模型不是不会做，而是“记不住该记的、忘了该忘的”。传统的做法是拼命把历史记录、工具返回结果、用户指令全部拼到 prompt 里，结果上下文窗口越撑越大，模型真正需要关注的信息反而被淹没，最后既费 token，效果又差。

Recuris 双记忆机制的核心价值，就是把“记忆”从模型上下文里剥离出来，变成一套独立的、有结构的、可管理的系统。短期工作记忆负责当前任务的过程信息，长期记忆负责沉淀可跨任务复用的经验和知识。模型在每个决策点只读取当前最需要的信息，而不是被迫消费整段历史。

这篇文章适合三类读者：

• 正在做多步骤 Agent 应用，但任务成功率始终上不去的开发者。
• 刚接触 Agent 架构，想理解 RAG、记忆、上下文管理之间关系的人。
• 想把长程任务从 Demo 推到生产环境，需要一套可评估、可排查方案的技术负责人。

2. 长程智能体的失败根源：目标漂移与上下文污染

在拆解 Recuris 之前，先花一点时间把长程智能体真正的痛点讲透。长程任务失败，表面原因千奇百怪，实际可以归结为三类。

第一类是目标漂移。Agent 在执行多步骤任务时，每一轮都需要根据当前状态决定下一步动作。如果模型每一轮都只看到最近几步的上下文，它很容易把局部的中间目标当成最终目标。比如任务是“整理项目文档并发送给团队”，Agent 可能在整理完目录之后，就认为自己已经完成了任务，因为它太专注于“整理目录”这个局部动作，忽略了“发送给团队”这个最终目标。这类问题不是模型不聪明，而是上下文缺乏对全局目标的持续锚定。双记忆机制把任务目标放在工作记忆的高优先级位置，每次决策前都会重新校准，从机制上缓解了目标漂移。

第二类是上下文污染。很多人以为上下文越长，模型理解越准确。实际上长上下文里包含大量噪音时，模型容易被无关信息带偏。例如一个数据分析 Agent 执行了 20 步操作，产生了 15 段中间结果，其中真正影响下一步决策的可能只有最近 2 步的汇总信息。如果把这 15 段全部塞进 prompt，模型需要从噪音中自行筛选，一旦筛选出错，后续动作就跟不上节奏。这就是为什么单纯扩充上下文窗口，并不能解决长程任务可靠性的原因。真正有效的办法，是像 Recuris 双记忆机制那样，由外部系统完成信息筛选和结构化，而不是把筛选压力全部交给模型。

第三类是经验无法复用。传统 Agent 的每次任务都是“从零开始”，上一次任务中已经排查过的坑，这次还会再踩一遍。例如某个 Agent 接的数据库查询工具，返回结果带了多余的分页信息，需要先清洗再使用。第一次任务遇到这个问题后，模型虽然学会了处理方式，但任务结束后这个知识就消失了。下次任务遇到同样的返回格式，模型又要重新摸索。长期记忆机制要解决的，正是这种跨任务的知识沉淀。

理解这三类问题，就能理解 Recuris 双记忆机制的设计初衷：它不是做一个普通的向量检索库，而是用一套结构化的方式，把 Agent 的“过程状态”和“经验知识”分开管理，让模型在合适的时机只读取合适的信息。

3. 双记忆机制的核心概念：工作记忆与长期记忆

Recuris 双记忆机制，核心是两类记忆的划分和协同。

3.1 工作记忆：当前任务的“草稿纸”

工作记忆（Working Memory）对应的是“正在做的事”。它的特点是：写入频繁、时效性强、容量有限、任务结束即清空或归档。

可以把工作记忆理解成人类做菜时灶台边上的案板与调料盒。你正在做的这道菜，需要用到切好的葱姜蒜、已经调好的料汁、正在锅里炖的肉的状态。这些信息必须在触手可及的地方，不能放在储物间里。但是案板上的东西是临时的，这道菜做完，案板要清理，下一道菜需要新的备料。

在长程 Agent 中，工作记忆通常包含这些内容：

• 任务的初始目标和最终验收标准。
• 当前执行到第几步，前一步的工具返回结果。
• 已经在本次任务中做出的关键决策和理由。
• 临时需要记住的约束条件。

工作记忆有两个关键设计点。第一是容量限制。它不会无限增长，而是设置上限，超出的部分要么压缩成摘要，要么转移到长期记忆，要么直接丢弃。第二是刷新策略。每次新的观测进来，旧信息会被评估是否仍然重要，不重要的会被移除。这样才能保证模型每次看到的都是当前最相关的状态。

3.2 长期记忆：跨任务的“经验库”

长期记忆（Long-Term Memory）对应的是“以前学会的、以后还能用的事”。它的特点是：写入频率低、结构相对稳定、容量可以很大、需要按需检索。

继续用厨房做类比，长期记忆就是那本写满了菜谱、食材处理技巧、上次数菜翻车教训的笔记本。做糖醋排骨之前，你先翻开笔记本看一下上次做的比例是多少，这次直接复用。不需要每次做菜都重新摸索一遍。

在长程 Agent 中，长期记忆通常包含这些内容：

• 同类任务的标准操作流程。
• 特定工具的使用注意点和返回格式特征。
• 曾经出现的错误和对应的解决方案。
• 用户对不同事项的偏好。

长期记忆的写入需要谨慎，不是所有过程信息都值得沉淀。只有经过评估、被验证有效的经验，才应该写入长期记忆。否则会把经验库变成垃圾场，检索时命中大量无效信息，反而降低效果。

3.3 双记忆机制与 RAG 的区别

rIf you 熟悉 RAG，可能会觉得长期记忆有点像向量数据库。确实有相似之处，但两者的定位不同。RAG 通常服务于“知识问答”，检索的是外部知识文档，内容相对静态，面向的是“我不知道这个知识，查一下”。而双记忆机制中的长期记忆服务于“任务执行经验”，内容来自 Agent 自身的运行过程，动态增长，面向的是“我遇到过类似情况，上次怎么解决的”。

Recuris 双记忆机制更进一步的地方，在于它把工作记忆和长期记忆做了联动。当任务进行到某个阶段，系统会先从长期记忆中检索相关经验，结合工作记忆中的当前状态，一起传给模型做决策。任务结束后，工作记忆中被验证有效的经验会被提炼并写入长期记忆。这样两类记忆就形成了一个持续运转的闭环，而不是两个独立模块。

这个设计背后的原因是：长程任务的成功率，既要靠当前任务中的上下文连贯性，也要靠跨任务的经验迁移能力。只有工作记忆，Agent 能跑完单次长任务，但每次都是新手；只有长期记忆，Agent 能调取经验，但缺少当前任务的实时状态。两者结合起来，才是一个完整的 Agent 记忆系统。

4. Recuris 工作流程拆解：从感知到记忆再决策

Recuris 双记忆机制在运行时的执行流程，大致分为五个阶段。理解这个流程，后面做配置和代码实现时就不会觉得抽象。

第一个阶段是感知与观测。Agent 执行一步动作后，会拿到一个观测结果，可能是工具返回值、模型输出、或者用户新消息。这一步的关键是记录原始观测，但不着急写入记忆，先做一次结构化解析。

第二个阶段是记忆更新。解析后的观测被用来更新工作记忆。系统要判断：这条新信息应该替换工作记忆中的哪条旧信息？是否触发摘要压缩？是否有值得提炼到长期记忆的经验？这一步是整个机制的核心，直接决定记忆系统的质量。

第三个阶段是长期记忆检索。在做出下一步决策之前，Agent 会根据当前任务描述和工作记忆中的关键要素，从长期记忆中检索最相关的经验。检索的触发时机很有讲究。如果每步都检索，成本高且容易引入无关信息；如果整个任务一次都不检索，长期记忆就失去了意义。更合理的策略是：在任务开始、遇到异常、进入新阶段时触发检索。

第四个阶段是上下文组装。把工作记忆摘要、长期记忆检索结果、任务目标、可执行工具列表组装成模型的实际输入 prompt。此时模型的输入不再是完整历史记录，而是经过筛选和重构的“有效信息包”。这一步是双记忆机制能减少 token 消耗的关键。

第五个阶段是模型决策与执行。模型基于组装好的上下文输出下一步动作，Agent 执行这个动作，产生新的观测，回到第一阶段。整个流程循环，直到任务完成或达到最大步数限制。

从 Recuris 双记忆机制的流程可以看出，它的关键不在于模型本身，而在于记忆系统如何管理信息的写入、更新、检索和淘汰。模型只是决策器，记忆系统决定了决策器看到什么信息。这也是为什么长程任务成功率能通过改进记忆系统来提升的根本原因。

5. 环境准备与基础配置

理解了核心流程之后，下面进入实操环节。我会用一套通用的实现思路演示双记忆机制，代码以教学演示为目的，不绑定 Recuris 官方特定版本。你在实际项目中，可以按照同样的接口思路适配自己的业务代码。

5.1 运行环境

Python 3.10+

建议使用虚拟环境隔离依赖。虽然本示例不依赖重型框架，只使用 Python 标准库和少量第三方库，但后续如果要接向量检索或大模型 API，仍然建议保持环境干净。

5.2 依赖安装

pip install pyyaml

配置文件采用 YAML 格式，所以需要 PyYAML 库。如果后续需要做向量相似度检索，可以自行增加sentence-transformers或faiss-cpu，本文演示阶段先使用基于关键词和简单评分的检索方式，方便看清整体流程。

5.3 目录结构建议

memory-demo/ ├── config.yml ├── main.py ├── memory/ │ ├── __init__.py │ ├── long_term.py │ └── short_term.py └── memory_store/ └── experiences.json

目录结构清晰的目的是让记忆模块独立成包，方便以后替换成更复杂的实现。

5.4 基础配置

# 文件路径：memory-demo/config.yml agent: name: long_horizon_agent max_steps: 30 memory: working_limit: 8 long_term_path: ./memory_store/experiences.json top_k: 3 refresh_threshold: 5 compaction_threshold: 12 retention_days: 30

配置项解释一下：

• working_limit：工作记忆最多保留多少条信息。超出后按策略压缩或淘汰。
• long_term_path：长期记忆的存储路径，本文用 JSON 文件存储，生产环境可以替换为向量数据库。
• top_k：每次决策时从长期记忆中检索几条相关经验。
• refresh_threshold：触发长期记忆检索的步数间隔。比如设置为 5，表示每执行 5 步触发一次检索。
• compaction_threshold：工作记忆条数超过该值时触发摘要压缩。
• retention_days：长期记忆的保留天数，用于清理过期经验。

这些配置不是固定的，应该根据任务复杂度调整。任务越复杂，工作记忆容量可以适当调大，但不要超过模型单次处理能力。经验之谈是，工作记忆控制在 8 到 15 条之间，检索结果控制在 3 到 5 条之间，效果比较稳。

6. 双记忆机制的核心代码实现

下面直接给出一套可运行的完整代码。我会把短期记忆和长期记忆分成两个模块，最后在主程序中实现一个带双记忆的 Agent 循环。

6.1 短期记忆模块

# 文件路径：memory-demo/memory/short_term.py from dataclasses import dataclass, field from datetime import datetime from typing import List, Optional @dataclass class WorkingMemoryItem: content: str timestamp: str = field(default_factory=lambda: datetime.now().isoformat()) importance: int = 1 class ShortTermMemory: """ 工作记忆：保存当前任务的近期状态信息。 采用列表存储，超出容量后丢弃最旧且重要性最低的记录。 """ def __init__(self, limit: int = 8): self.limit = limit self.items: List[WorkingMemoryItem] = [] def add(self, content: str, importance: int = 1): item = WorkingMemoryItem(content=content, importance=importance) self.items.append(item) self._evict() return item def _evict(self): if len(self.items) <= self.limit: return # 先按重要性升序，再按时间升序，移除最旧最不重要的记录 self.items.sort(key=lambda x: (x.importance, x.timestamp)) self.items.pop(0) def snapshot(self) -> str: """返回当前工作记忆的完整摘要，用于拼装 prompt。""" if not self.items: return "（当前无工作记忆）" lines = [f"- {item.content}" for item in self.items] return "\n".join(lines) def clear(self): self.items.clear()

工作记忆的核心逻辑是add和_evict。_evict通过排序保证容量不会无限增长。importance字段用于标记关键信息，比如“任务最终目标”这种信息，重要性设为 5，就不会轻易被挤出工作记忆。

6.2 长期记忆模块

# 文件路径：memory-demo/memory/long_term.py import json import os from datetime import datetime, timedelta from typing import List, Dict, Any class LongTermMemory: """ 长期记忆：保存可跨任务复用的经验。 本演示使用 JSON 文件存储，生产环境建议替换为向量数据库。 """ def __init__(self, store_path: str, top_k: int = 3, retention_days: int = 30): self.store_path = store_path self.top_k = top_k self.retention_days = retention_days self.experiences: List[Dict[str, Any]] = [] self._load() def _load(self): if os.path.exists(self.store_path): with open(self.store_path, "r", encoding="utf-8") as f: self.experiences = json.load(f) def _save(self): os.makedirs(os.path.dirname(self.store_path), exist_ok=True) with open(self.store_path, "w", encoding="utf-8") as f: json.dump(self.experiences, f, ensure_ascii=False, indent=2) def _clean_expired(self): now = datetime.now() valid = [] for exp in self.experiences: created = datetime.fromisoformat(exp.get("created_at", now.isoformat())) if now - created < timedelta(days=self.retention_days): valid.append(exp) self.experiences = valid def add(self, title: str, content: str, tags: List[str]): self._clean_expired() self.experiences.append({ "title": title, "content": content, "tags": tags, "created_at": datetime.now().isoformat(), }) self._save() def _score(self, query: str, exp: Dict[str, Any]) -> float: """简单的关键词重叠评分，生产环境可替换为向量相似度。""" score = 0.0 query_keywords = set(query.lower().split()) title_words = set(exp.get("title", "").lower().split()) content_words = set(exp.get("content", "").lower().split()) tag_words = set(exp.get("tags", [])) score += len(query_keywords & title_words) * 2.0 score += len(query_keywords & content_words) * 1.0 score += len(query_keywords & tag_words) * 1.5 return score def retrieve(self, query: str) -> List[str]: scored = [] for exp in self.experiences: score = self._score(query, exp) if score > 0: scored.append((score, exp)) scored.sort(key=lambda x: x[0], reverse=True) results = [] for _, exp in scored[:self.top_k]: results.append(f"[经验] {exp['title']}: {exp['content']}") return results

长期记忆的检索比较粗糙，用的是关键词重叠评分。实际生产环境中可以替换为向量模型，把 query 和经验内容分别转成向量，再做相似度检索。替换方式很简单，只需要改retrieve方法内部的实现，外部接口保持不变。

6.3 带双记忆的 Agent 主循环

# 文件路径：memory-demo/main.py import yaml from memory.short_term import ShortTermMemory from memory.long_term import LongTermMemory class DualMemoryAgent: def __init__(self, config: dict): memory_config = config["memory"] self.working_limit = memory_config["working_limit"] self.stm = ShortTermMemory(limit=self.working_limit) self.ltm = LongTermMemory( store_path=memory_config["long_term_path"], top_k=memory_config["top_k"], retention_days=memory_config["retention_days"], ) self.step_count = 0 self.refresh_threshold = memory_config.get("refresh_threshold", 5) def _decide(self, task: str, observation: str): """ 模拟模型的决策过程。 实际项目中，这里应调用 LLM，根据任务目标、工作记忆、长期记忆生成下一步动作。 本演示使用规则逻辑替代，重点展示记忆的流转。 """ if "完成" in observation or "成功" in observation: return "finish" return "continue" def _execute(self, action: str, step: int): """模拟执行一步动作。实际项目中，这里会调用外部工具。""" if action == "finish": return "任务已完成" return f"第 {step} 步执行完毕，中间结果正常" def _compress(self): print("触发工作记忆压缩...") def run(self, task: str): print(f"开始执行任务: {task}") # 任务开始前检索长期记忆，复用历史经验 related_experiences = self.ltm.retrieve(task) if related_experiences: print("从长期记忆中检索到相关经验:") for exp in related_experiences: print(f" {exp}") else: print("长期记忆中没有相关经验") # 将任务目标写入工作记忆，重要性设为最高 self.stm.add(f"任务目标: {task}", importance=5) max_steps = 30 for step in range(1, max_steps + 1): self.step_count = step # 达到刷新阈值时，重新检索长期记忆 if step % self.refresh_threshold == 0: related_experiences = self.ltm.retrieve(task) if related_experiences: print(f"第 {step} 步触发长期记忆检索，命中 {len(related_experiences)} 条经验") # 查看当前工作记忆 current_memory = self.stm.snapshot() print(f"\n[step {step}] 当前工作记忆:") print(current_memory) action = self._decide(task, current_memory) observation = self._execute(action, step) print(f"[step {step}] 执行动作: {action}, 观测: {observation}") # 将本轮结果写入工作记忆 self.stm.add(f"第 {step} 步结果: {observation}", importance=2) # 完成任务后，提炼经验写入长期记忆 if action == "finish" and "完成" in observation: print(f"\n任务在第 {step} 步完成，提炼经验写入长期记忆") self.ltm.add( title=f"任务经验: {task[:20]}", content="按双记忆流程执行可稳定完成任务，最终步骤应主动判断是否完成目标", tags=[task.split()[0]] if task.split() else ["通用"], ) break else: print("达到最大步数限制，任务未完成") if __name__ == "__main__": with open("config.yml", "r", encoding="utf-8") as f: config = yaml.safe_load(f) agent = DualMemoryAgent(config) agent.run("整理项目周报并发送给团队")

这段代码的核心是run方法里的执行循环。它演示了双记忆机制的关键节点：任务开始前检索长期记忆、任务目标写入工作记忆、每步结果写入工作记忆、达到刷新阈值时重新检索长期记忆、任务完成后把经验写入长期记忆。实际项目中，只需要把_decide替换为大模型调用，把_execute替换为工具调用，整个架构就可以跑起来。

7. 运行结果与效果验证

写完代码后，先跑一遍最小示例，确认记忆流转逻辑符合预期。

7.1 运行命令

cd memory-demo python main.py

7.2 预期输出

下面是前几步的关键输出示例：

开始执行任务: 整理项目周报并发送给团队 长期记忆中没有相关经验 [step 1] 当前工作记忆: - 任务目标: 整理项目周报并发送给团队 [step 1] 执行动作: continue, 观测: 第 1 步执行完毕，中间结果正常 [step 1] 当前工作记忆: - 任务目标: 整理项目周报并发送给团队 - 第 1 步结果: 第 1 步执行完毕，中间结果正常 ...

如果第二次运行同一个任务，长期记忆中已经有了上一次沉淀的经验，输出中会出现：

开始执行任务: 整理项目周报并发送给团队 从长期记忆中检索到相关经验: [经验] 任务经验: 整理项目周报并发送: 按双记忆流程执行可稳定完成任务，最终步骤应主动判断是否完成目标

7.3 如何判断成功

验证双记忆机制是否生效，可以从三个维度观察。

第一是工作记忆容量是否稳定。运行一个长循环任务，观察current_memory的条数是否始终不超过working_limit。如果条数持续增长，说明淘汰策略有问题。

第二是长期记忆是否可以复用。运行完一次任务后，删除本地 JSON 文件之外的数据，再跑一次同类型任务，检查是否输出了“从长期记忆中检索到相关经验”。如果能够输出，说明沉淀和检索链路是通的。

第三是观察模型输入是否包含无关历史。在真实项目中，你可以在调用 LLM 之前打点记录传入的 prompt。如果 prompt 里除了工作记忆摘要、长期记忆经验、当前步骤信息之外，不再携带大量无关历史记录，说明双记忆机制已经起到了精简上下文的作用。

7.4 失败时先看哪里

如果运行报错，第一个要看的地方是配置文件路径。检查long_term_path指向的目录是否存在，程序会自动创建目录，但如果是相对路径，需要在main.py所在目录下运行。第二个要看 JSON 文件是否损坏，如果手动编辑过experiences.json，可能会导致json.load抛异常。第三个要看 PyYAML 是否安装成功，可以使用pip list | grep yaml确认。

8. 常见问题与排查思路

双记忆机制在工程落地时，会遇到一些典型问题。下面整理成表格，方便排查。

这里面最容易踩的坑是长期记忆污染。一旦把某个错误经验写入长期记忆，之后每次同类任务都可能被这个错误经验误导。所以要谨慎控制写入条件，宁可少写，不要乱写。

9. 最佳实践与工程建议

结合双记忆机制的特点，这里给出一些在真实项目中沉淀下来的建议，每一条都踩过对应的坑。

9.1 记忆写入要有门槛

不是每一步的结果都值得写入长期记忆。建议为长期记忆设置一个重要度阈值，只有满足以下条件之一时才写入：

• 该经验已经经过至少两次任务验证。
• 该经验涉及特定工具的异常处理方式。
• 该经验能明显缩短同类任务的完成步数。

工作记忆可以快速写入，长期记忆必须谨慎。工作记忆写错了，几分钟后就被淘汰；长期记忆写错了，会长期污染后续任务。

9.2 工作记忆要注意信息位置

模型对 prompt 不同位置的注意力不同。把“任务最终目标”放在工作记忆的最前面，把“上一步观测结果”放在工作记忆的最后面。这样模型在生成下一步动作时，既能看到全局目标，也能看到最近状态。这个顺序问题在长程任务中非常关键，很多 Agent 跑着跑着忘了目标，就是因为目标信息被埋在中间位置。

9.3 检索触发要分层次

不建议每个步骤都触发长期记忆检索，那会让任务时间变长，而且引入的噪音往往大于收益。更合理的触发策略是：

• 任务开始时必检，用于复用经验。
• 每 N 步触发一次，N 根据任务复杂度设置。
• 遇到异常或工具报错时触发，用于找到历史解决方案。
• 切换任务子阶段时触发。

9.4 记忆数据要考虑安全和权限

长期记忆沉淀的内容可能包含业务敏感信息。在把经验写入长期记忆之前，需要做一次脱敏处理，比如去掉用户名、邮箱、具体金额等字段。生产环境中，记忆库的访问权限应该独立管理，不能所有任务都共享同一个长期记忆库。不同业务线、不同保密等级的数据，应该使用不同的记忆存储空间。

9.5 评估效果要看长期趋势

双记忆机制的效果不是看单次任务的完成率，而是看长期趋势。建议持续记录以下几个指标：

• 任务成功率：每类任务的成功率变化。
• 平均完成步数：是否逐步变短。
• 长期记忆命中率：检索结果的采纳比例。
• 错误重复率：同类错误是否还在反复出现。

如果错误重复率在下降，说明长期记忆正在发挥作用。如果任务成功率没有变化，先检查检索命中质量，再检查工作记忆容量设置。

9.6 记忆系统可观测性要提前做

双记忆机制本质上是在模型外部增加了一个状态管理系统。既然是系统，就必须可观测。建议至少记录以下日志：

• 工作记忆每次 update 前后的差异。
• 长期记忆检索时的 query 和返回 top_k 列表。
• 每次写入长期记忆的触发原因。

有了这些日志，问题出现时才能快速定位是记忆写入问题、检索问题，还是模型决策问题。

10. 总结与后续学习方向

Recuris 双记忆机制解决的核心问题，是把长程智能体的“过程状态”和“经验知识”分开管理。相比把全部历史塞进上下文的做法，双记忆机制用工作记忆保证当前任务的连贯性，用长期记忆沉淀跨任务的可复用经验。两者协同之后，模型在每个决策点看到的都是经过筛选的有效信息，而不是堆积的原始历史，这既缓解了目标漂移，也降低了上下文噪音，同时为错误经验的复用作出了机制保障。

这篇文章没有停留在概念层面，而是给出了一套可以运行的代码实现。你可以基于ShortTermMemory和LongTermMemory两个模块，快速搭建一个带双记忆的 Agent 原型，然后逐步替换掉其中的模拟逻辑，接入真实的大模型和工具调用。建议实践路径是：先跑通最小示例，观察记忆的写入、淘汰和检索；然后接入一个真实的长程任务，比如多工具数据分析、多步骤工单处理；最后加入可观测指标，持续评估记忆系统对任务成功率的影响。

后续值得深入的方向有三个：一是长期记忆的向量化检索，把关键词匹配替换成语义相似度；二是记忆的自动摘要和压缩策略，让工作记忆在有限容量内保留更多关键信息；三是多智能体场景下的记忆共享机制，当多个 Agent 协作完成一个长程任务时，记忆如何在不同 Agent 之间安全流动。这些方向都是双记忆机制的自然延伸，理解了这篇文章的框架，再去看这些进阶设计，思路会清晰很多。