长程智能体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_factorylambda: 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(contentcontent, importanceimportance) self.items.append(item) self._evict() return item def _evict(self): if len(self.items) self.limit: return # 先按重要性升序再按时间升序移除最旧最不重要的记录 self.items.sort(keylambda 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, encodingutf-8) as f: self.experiences json.load(f) def _save(self): os.makedirs(os.path.dirname(self.store_path), exist_okTrue) with open(self.store_path, w, encodingutf-8) as f: json.dump(self.experiences, f, ensure_asciiFalse, indent2) 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(daysself.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(keylambda x: x[0], reverseTrue) 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(limitself.working_limit) self.ltm LongTermMemory( store_pathmemory_config[long_term_path], top_kmemory_config[top_k], retention_daysmemory_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}, importance5) 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}, importance2) # 完成任务后提炼经验写入长期记忆 if action finish and 完成 in observation: print(f\n任务在第 {step} 步完成提炼经验写入长期记忆) self.ltm.add( titlef任务经验: {task[:20]}, content按双记忆流程执行可稳定完成任务最终步骤应主动判断是否完成目标, tags[task.split()[0]] if task.split() else [通用], ) break else: print(达到最大步数限制任务未完成) if __name__ __main__: with open(config.yml, r, encodingutf-8) as f: config yaml.safe_load(f) agent DualMemoryAgent(config) agent.run(整理项目周报并发送给团队)这段代码的核心是run方法里的执行循环。它演示了双记忆机制的关键节点任务开始前检索长期记忆、任务目标写入工作记忆、每步结果写入工作记忆、达到刷新阈值时重新检索长期记忆、任务完成后把经验写入长期记忆。实际项目中只需要把_decide替换为大模型调用把_execute替换为工具调用整个架构就可以跑起来。7. 运行结果与效果验证写完代码后先跑一遍最小示例确认记忆流转逻辑符合预期。7.1 运行命令cd memory-demo python main.py7.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. 常见问题与排查思路双记忆机制在工程落地时会遇到一些典型问题。下面整理成表格方便排查。问题现象可能原因排查方式解决方案工作记忆一直增长没有触发淘汰working_limit配置过大或_evict逻辑未被调用检查配置项在add方法中增加打印日志调小容量确认每条新增记录都会触发淘汰检查长期记忆检索结果总是为空任务描述与经验标题、标签的关键词匹配不到打印检索 query 和评分过程丰富经验标签改用向量相似度检索检索出了大量无关经验关键词评分方法过于粗糙人工检查经验库内容质量和重复情况降低top_k增加评分权重或引入语义向量任务切换后上一条任务的经验干扰当前任务长期记忆检索条件过于宽泛检查检索时是否带上任务领域标签按任务类型过滤经验增加领域强约束模型陷入重复循环长期不结束决策信息中缺少“已完成”信号检查工作记忆摘要是否包含最近结果将上一步的观测结果放在工作记忆的最前面经验写入过多长期记忆库膨胀写入长期记忆的触发条件过宽审计add方法调用日志增加重要度阈值只有高价值经验才能写入token 消耗仍然偏高工作记忆摘要过长或检索结果太多检查组装后的 prompt 实际长度对工作记忆条目做摘要压缩减少top_k这里面最容易踩的坑是长期记忆污染。一旦把某个错误经验写入长期记忆之后每次同类任务都可能被这个错误经验误导。所以要谨慎控制写入条件宁可少写不要乱写。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 之间安全流动。这些方向都是双记忆机制的自然延伸理解了这篇文章的框架再去看这些进阶设计思路会清晰很多。