Agent Memory实战：从hindsight到记忆提炼与检索的落地指南

1. 从“hindsight”说起：为什么记忆是Agent落地的最后一公里

“hindsight”这个词本身很有意思，字面意思是“事后的洞察力”，也就是我们常说的“后见之明”。把这个词放到AI Agent和LLM的语境里，它指向的东西非常具体：Agent在完成任务之后，能不能把经历过的事情沉淀下来，下次遇到类似场景时直接调用，而不是从零开始推理。这就是Agent Memory要解决的核心问题。

我接触过不少Agent项目，从早期的简单工具调用，到后来带编排的复杂工作流，再到最近半年大量涌现的MCP生态集成，一个感受越来越强烈：模型能力本身已经不是瓶颈了，真正卡住落地效果的是记忆机制。你用一个很强的LLM，给它配上完善的工具链，它单次任务的表现可以很惊艳。但如果你让它连续处理十个相关任务，每个任务之间有关联，你会发现它每次都在重新理解上下文，重新试错，重新踩坑。这就是没有记忆的代价。

“hindsight”这个项目标题，我理解它要做的不是简单的对话历史存储，而是一套面向Agent的事后记忆提炼与复用机制。它要回答的问题是：Agent执行完一个任务后，哪些信息值得留下来？以什么结构留下来？下次怎么检索出来？检索出来之后怎么注入到新的推理过程中？这四个问题，每一个都有坑。

这篇文章适合谁看？如果你正在做Agent开发，不管是基于LangChain、AutoGPT还是自己手搓的框架，只要你遇到了“Agent记不住事”“重复任务效率低”“多轮交互后上下文爆炸”这些问题，那这篇内容就是写给你的。如果你刚接触Agent概念，想了解Memory模块到底怎么设计，我也会从最基础的地方讲起，用生活化的类比把原理说清楚。

提示：本文涉及的代码示例和配置方案，均基于我在实际项目中的实践总结，不同框架的API可能有差异，但核心思路是通用的。

2. Agent Memory的核心设计思路拆解

2.1 为什么不能直接把对话历史塞进上下文

很多人做Agent Memory的第一反应是：把历史对话全部存下来，每次请求的时候拼接到prompt里不就行了？这个方案在Demo阶段能用，但一到生产环境就崩。原因有三个。

第一是Token成本。LLM的上下文窗口是有限的，就算现在有些模型支持很长的上下文，你把几百轮对话全塞进去，每次请求的Token消耗是线性增长的。假设每轮对话平均500个Token，100轮就是5万Token，按现在的API定价，一次请求的成本可能就上去了。而且大部分历史信息对当前任务是无关的，花这个钱不值得。

第二是注意力稀释。LLM在处理长上下文时，并不是每个Token都同等重要。你把大量无关的历史信息塞进去，反而会干扰模型对当前任务的判断。这就像你问一个人“今天午饭吃什么”，他先把过去一个月每天吃了什么全回忆一遍，然后再回答你，效率低而且容易跑偏。

第三是结构缺失。原始对话历史是非结构化的，里面混杂了成功的经验、失败的尝试、无关的闲聊、临时的中间结果。Agent下次遇到类似任务时，需要的是提炼后的知识，而不是原始流水账。

所以“hindsight”要做的第一件事，就是在任务结束后进行记忆提炼，把原始执行轨迹压缩成结构化的、可复用的知识单元。

2.2 记忆的分层模型：Working Memory与Long-term Memory

我在设计Agent Memory时，习惯把它分成两层：工作记忆（Working Memory）和长期记忆（Long-term Memory）。这个分法借鉴了认知科学的模型，但在工程上非常实用。

工作记忆是Agent在当前任务执行过程中临时维护的状态。比如它正在处理一个多步任务，第一步的输出是第二步的输入，这个中间结果就放在工作记忆里。工作记忆的特点是生命周期短，任务结束就可以丢弃，存储介质通常是内存或Redis这类高速缓存。

长期记忆是跨任务持久化的知识。它又可以分为几种类型：

• 事实性记忆：比如“用户偏好用Python而不是Java”“这个项目的API地址是xxx”。这类记忆相对稳定，变更频率低。
• 经验性记忆：比如“上次处理这类CSV文件时，用pandas的read_csv指定encoding='utf-8-sig'解决了乱码问题”。这类记忆是任务执行过程中积累的，是“hindsight”的核心产出。
• 实体性记忆：比如“用户提到的‘老王’指的是王建国，技术总监”。这类记忆用于消歧和关联。

“hindsight”这个项目，我判断它的重点应该放在经验性记忆的自动提炼上。因为事实性记忆和实体性记忆通常需要显式配置或人工标注，而经验性记忆是Agent在执行过程中自然产生的，量大且价值高，但如果不做提炼，就是一堆噪音。

2.3 记忆的写入时机：任务结束不是唯一选择

什么时候把信息写入长期记忆？最直觉的答案是任务结束后。但实际操作中，我发现有几个时机都值得考虑。

任务成功结束时，把整个执行路径中验证有效的步骤提炼成经验。这是最主要的写入时机。但要注意，不是所有成功的路径都值得记录。比如一个任务只有一种解法，那记录下来的价值就不大；如果一个任务有多种解法，Agent试了几种才找到对的，那“哪种解法有效”就是有价值的信息。

任务失败时，把失败的尝试和失败原因记录下来。这个很多人会忽略，但我觉得价值极高。因为Agent下次遇到类似任务时，如果知道“上次用A方法失败了，原因是B”，它就可以直接跳过A方法，节省大量试错成本。这其实就是“hindsight”的字面意思——从后见之明中学习。

用户显式反馈时，比如用户说“不对，应该这样做”，这是一个强信号，必须立即写入记忆。这种反馈的置信度比Agent自己推断的要高得多。

定期回顾时，可以设置一个定时任务，让Agent回顾最近一段时间的执行记录，从中提炼出跨任务的模式。比如“最近处理的五个数据清洗任务，都涉及处理缺失值”，这可能意味着用户当前的项目阶段对数据质量要求提高了。

2.4 记忆的检索策略：相似度不是唯一维度

写入记忆之后，怎么在需要的时候检索出来？最常见的做法是用向量数据库做相似度检索。但只用相似度是不够的。

我踩过的一个坑：Agent在处理一个“生成周报”的任务时，检索到了之前“生成月报”的记忆，因为两者在语义上很相似。但周报和月报的格式要求、数据范围、汇报对象都不一样，直接套用月报的经验反而导致了错误。

所以检索策略需要多维度结合：

• 语义相似度：基础的向量检索，保证召回相关的内容。
• 任务类型匹配：给记忆打上任务类型的标签，检索时优先匹配相同类型的任务。
• 时间衰减：越近期的记忆权重越高，因为项目环境和用户偏好可能已经变化。
• 置信度加权：经过多次验证的记忆权重更高，只出现过一次的记忆权重降低。
• 来源区分：用户显式反馈的记忆权重高于Agent自己推断的记忆。

这些维度可以通过一个加权评分函数来综合，最终返回Top-K条记忆注入到当前上下文中。

3. 核心细节解析与实操要点

3.1 记忆单元的数据结构设计

一条记忆应该包含哪些字段？我经过多次迭代，目前用的结构是这样的：

{ "memory_id": "mem_20250115_001", "task_type": "data_cleaning", "task_description": "清洗包含中文和英文的CSV文件", "content": "使用pandas读取CSV时，如果文件包含中文，需要指定encoding='utf-8-sig'，否则会出现乱码。如果文件同时包含中英文，这个编码也能正确处理。", "context": { "tools_used": ["pandas.read_csv"], "parameters": {"encoding": "utf-8-sig"}, "input_sample": "姓名,年龄,城市\n张三,25,北京", "output_sample": "姓名,年龄,城市\n张三,25,北京" }, "confidence": 0.85, "source": "agent_inference", "created_at": "2025-01-15T10:30:00Z", "last_accessed_at": "2025-01-20T14:20:00Z", "access_count": 3, "tags": ["csv", "encoding", "chinese", "pandas"] }

这个结构里，content字段是核心，它是一段自然语言描述的经验。为什么用自然语言而不是结构化数据？因为LLM对自然语言的理解能力最强，注入到prompt里也最自然。结构化数据放在context字段里作为补充。

confidence字段很关键。Agent自己推断出来的经验，初始置信度不应该设太高，我一般设0.6到0.7。如果这条记忆被成功复用了一次，置信度加0.1；如果被复用后用户反馈不对，置信度直接砍半。这样经过几轮验证，真正有用的记忆会浮上来，噪音会被压下去。

access_count和last_accessed_at用于实现时间衰减和热度加权。一条很久没被访问的记忆，即使语义相似度高，权重也应该降低，因为可能已经过时了。

3.2 记忆提炼的Prompt设计

从原始执行轨迹中提炼记忆，本质上是让LLM做一次总结。但这个总结不是随便总结，需要引导它关注可复用的经验，而不是复述过程。

我用的提炼Prompt大致是这样的：

你是一个Agent经验提炼助手。下面是一个Agent执行任务的完整轨迹，包括任务描述、执行的步骤、使用的工具、中间结果和最终结果。 请从中提炼出对未来类似任务有价值的经验。注意： 1. 只提炼可复用的经验，不要复述任务过程。 2. 如果某个步骤失败了但揭示了重要信息，也要记录。 3. 经验描述要具体，包含关键参数和条件。 4. 如果没有任何值得记录的经验，返回空。 任务轨迹： {trajectory} 请以JSON格式返回，包含以下字段： - task_type: 任务类型标签 - content: 经验描述（自然语言） - context: 相关的工具、参数、输入输出示例 - confidence: 你对这条经验的置信度（0-1） - tags: 标签列表

这个Prompt有几个细节值得说。“如果没有任何值得记录的经验，返回空”这一句很重要，否则LLM会强行编造一些废话出来。“如果某个步骤失败了但揭示了重要信息，也要记录”这一句引导它关注失败经验。要求JSON格式是为了后续程序化处理。

实测下来，这个Prompt的提炼质量还不错，但偶尔会漏掉一些隐含的经验。比如Agent在某个步骤重试了三次才成功，这个“重试三次”本身可能就是一个信号——说明这个操作不稳定，需要加异常处理。这种隐含信息需要在Prompt里额外提示，或者在后处理阶段用规则补充。

3.3 记忆注入的位置与格式

检索到相关记忆后，怎么注入到当前任务的上下文中？位置和格式都有讲究。

位置方面，我试过三种方案：

• 放在System Prompt里：优点是稳定，每次请求都带着。缺点是如果记忆很多，System Prompt会很长，而且不是所有记忆对当前任务都相关。
• 放在User Message前面：作为上下文的一部分。优点是灵活，可以针对当前任务动态检索。缺点是可能被User Message的内容覆盖或忽略。
• 放在单独的Memory Section里：在Prompt中明确标注“以下是相关经验”，与任务描述分开。这是我目前最推荐的方案，因为LLM对结构化标注的响应更好。

格式方面，我建议用简洁的列表形式，每条记忆一行，包含核心内容和关键参数：

[相关经验] 1. 处理中文CSV时，pandas.read_csv需指定encoding='utf-8-sig'（置信度：0.85） 2. 如果CSV分隔符不是逗号，先用csv.Sniffer检测（置信度：0.72） 3. 上次类似任务中，直接指定dtype={'年龄': int}避免了类型推断错误（置信度：0.68）

这种格式的好处是信息密度高，LLM一眼就能扫完。不要注入完整的JSON，那样太占Token而且LLM解析起来也费劲。

注意：注入的记忆条数不要太多，我一般控制在5到8条。太多会稀释注意力，而且增加Token成本。如果检索出来很多条，按加权评分排序取Top-K。

3.4 记忆的冲突处理与更新

同一个事实，不同时间写入的记忆可能冲突。比如一条旧记忆说“用户偏好用Java”，一条新记忆说“用户偏好用Python”。怎么处理？

我的策略是新记忆覆盖旧记忆，但保留旧记忆的变更历史。具体做法是给每条记忆加一个supersedes字段，指向被它取代的记忆ID。检索时只返回最新的有效记忆，但保留历史用于追溯。

如果是Agent自己推断的经验冲突，比如“用A方法处理”和“用B方法处理”都成功过，那就不是覆盖关系，而是并列关系。这种情况下，两条都保留，但在注入时标注各自的适用条件。比如“当数据量小于1万行时用A方法，大于1万行时用B方法”。

还有一种情况是记忆的置信度衰减。一条记忆如果长时间没有被访问，也没有被验证，置信度应该逐渐降低。我设置了一个简单的衰减规则：每30天没有访问，置信度乘以0.9。这样半年后，一条初始置信度0.8的记忆会降到0.8 * 0.9^6 ≈ 0.43，基本就不会被检索出来了。

4. 实操过程与核心环节实现

4.1 环境准备与依赖安装

假设你用Python做开发，核心依赖包括：

pip install openai chromadb sentence-transformers pandas numpy

• openai：调用LLM做记忆提炼和任务执行。
• chromadb：轻量级向量数据库，用于记忆的语义检索。选它是因为部署简单，单机就能跑，适合中小规模Agent项目。
• sentence-transformers：本地生成文本向量，不依赖外部API，省钱且响应快。
• pandas和numpy：数据处理和加权计算。

如果你用的是其他LLM提供商，把openai换成对应的SDK就行。向量数据库也可以用Milvus、Qdrant等替代，但Chroma的API最简单，适合快速验证。

4.2 记忆存储层的实现

先定义记忆的数据模型和存储接口：

import json import uuid from datetime import datetime from dataclasses import dataclass, field, asdict from typing import Optional @dataclass class MemoryUnit: memory_id: str = field(default_factory=lambda: f"mem_{uuid.uuid4().hex[:12]}") task_type: str = "" task_description: str = "" content: str = "" context: dict = field(default_factory=dict) confidence: float = 0.7 source: str = "agent_inference" created_at: str = field(default_factory=lambda: datetime.utcnow().isoformat()) last_accessed_at: str = field(default_factory=lambda: datetime.utcnow().isoformat()) access_count: int = 0 tags: list = field(default_factory=list) supersedes: Optional[str] = None def to_dict(self): return asdict(self) @classmethod def from_dict(cls, data): return cls(**data)

这个数据类定义了记忆单元的所有字段。supersedes字段用于处理冲突覆盖。to_dict和from_dict用于序列化。

存储层我用Chroma做向量存储，同时用一个JSON文件做元数据存储。Chroma的collection可以存向量和元数据，但元数据的查询能力有限，所以复杂的过滤和排序我在Python层做。

import chromadb from chromadb.config import Settings class MemoryStore: def __init__(self, persist_dir="./memory_db"): self.client = chromadb.PersistentClient(path=persist_dir) self.collection = self.client.get_or_create_collection( name="agent_memories", metadata={"hnsw:space": "cosine"} ) self.memories = {} # 内存中的元数据索引 def add_memory(self, memory: MemoryUnit, embedding: list): self.collection.add( ids=[memory.memory_id], embeddings=[embedding], metadatas=[{ "task_type": memory.task_type, "confidence": memory.confidence, "created_at": memory.created_at, "access_count": memory.access_count }], documents=[memory.content] ) self.memories[memory.memory_id] = memory def get_memory(self, memory_id: str) -> Optional[MemoryUnit]: return self.memories.get(memory_id) def update_memory(self, memory: MemoryUnit): self.memories[memory.memory_id] = memory # 更新Chroma中的元数据 self.collection.update( ids=[memory.memory_id], metadatas=[{ "task_type": memory.task_type, "confidence": memory.confidence, "created_at": memory.created_at, "access_count": memory.access_count }] )

这里有个细节：Chroma的update方法只能更新元数据和文档，不能直接更新向量。如果需要更新向量，得先删再加。不过记忆的向量通常不需要更新，因为content变了就是一条新记忆了。

4.3 记忆提炼的完整流程

记忆提炼的触发时机是任务结束后。整个流程分四步：

第一步，收集任务轨迹。在Agent执行过程中，每一步的工具调用、输入输出、中间结果都要记录下来。我一般用一个列表来存：

trajectory = [] def record_step(step_type, content, metadata=None): trajectory.append({ "step": len(trajectory) + 1, "type": step_type, # "thought", "tool_call", "tool_result", "final_answer" "content": content, "metadata": metadata or {}, "timestamp": datetime.utcnow().isoformat() })

第二步，调用LLM提炼经验。把轨迹格式化成文本，塞进前面提到的提炼Prompt里：

def extract_memory(trajectory, task_description): trajectory_text = format_trajectory(trajectory) prompt = EXTRACT_PROMPT_TEMPLATE.format( trajectory=trajectory_text ) response = llm_client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], response_format={"type": "json_object"} ) result = json.loads(response.choices[0].message.content) if not result.get("content"): return None return MemoryUnit( task_type=result.get("task_type", "unknown"), task_description=task_description, content=result["content"], context=result.get("context", {}), confidence=result.get("confidence", 0.7), tags=result.get("tags", []) )

第三步，生成向量并存储。用sentence-transformers生成content的向量：

from sentence_transformers import SentenceTransformer embedder = SentenceTransformer("all-MiniLM-L6-v2") def store_memory(memory: MemoryUnit): embedding = embedder.encode(memory.content).tolist() memory_store.add_memory(memory, embedding)

选all-MiniLM-L6-v2是因为它体积小、速度快，在英文和中文混合场景下表现也还行。如果你对中文语义相似度要求更高，可以换成BAAI/bge-small-zh-v1.5。

第四步，冲突检测与处理。新记忆写入前，先检索是否有相似记忆：

def check_conflict(new_memory: MemoryUnit, threshold=0.85): embedding = embedder.encode(new_memory.content).tolist() results = memory_store.collection.query( query_embeddings=[embedding], n_results=3 ) for i, distance in enumerate(results["distances"][0]): similarity = 1 - distance # cosine距离转相似度 if similarity > threshold: existing_id = results["ids"][0][i] existing = memory_store.get_memory(existing_id) if existing and existing.content != new_memory.content: # 冲突，新记忆覆盖旧记忆 new_memory.supersedes = existing_id existing.confidence *= 0.5 # 旧记忆置信度降低 memory_store.update_memory(existing) return new_memory

这个冲突检测的逻辑是：如果新记忆和已有记忆的语义相似度超过0.85，但内容不同，就认为是冲突。新记忆覆盖旧记忆，旧记忆置信度砍半。这样旧记忆不会立即消失，但检索时权重会降低。

4.4 记忆检索与注入的实现

检索发生在任务开始时。给定当前任务描述，检索最相关的记忆：

def retrieve_memories(task_description, task_type=None, top_k=5): query_embedding = embedder.encode(task_description).tolist() results = memory_store.collection.query( query_embeddings=[query_embedding], n_results=top_k * 3 # 多召回一些，后面再过滤 ) candidates = [] for i, memory_id in enumerate(results["ids"][0]): memory = memory_store.get_memory(memory_id) if not memory: continue similarity = 1 - results["distances"][0][i] # 多维度加权评分 score = similarity * 0.5 if task_type and memory.task_type == task_type: score += 0.2 score += memory.confidence * 0.2 score += min(memory.access_count / 10, 0.1) # 访问次数加权，上限0.1 # 时间衰减 days_since_created = (datetime.utcnow() - datetime.fromisoformat(memory.created_at)).days time_decay = max(0.5, 1 - days_since_created / 365) score *= time_decay candidates.append((score, memory)) candidates.sort(key=lambda x: x[0], reverse=True) return [mem for _, mem in candidates[:top_k]]

这个评分函数综合了语义相似度、任务类型匹配、置信度、访问热度和时间衰减。权重是我根据经验调的，你可以根据自己的场景调整。比如如果你的任务类型很固定，可以把任务类型匹配的权重调高。

检索到记忆后，格式化成文本注入到Prompt中：

def format_memories_for_prompt(memories): if not memories: return "" lines = ["[相关经验]"] for i, mem in enumerate(memories, 1): lines.append(f"{i}. {mem.content}（置信度：{mem.confidence:.2f}）") return "\n".join(lines)

然后在构建任务Prompt时，把这个文本放在任务描述之前：

def build_task_prompt(task_description, memories): memory_text = format_memories_for_prompt(memories) prompt = f"""{memory_text} [当前任务] {task_description} 请根据以上经验执行当前任务。如果经验不适用，请忽略并说明原因。""" return prompt

最后一句“如果经验不适用，请忽略并说明原因”很重要。它给了LLM一个出口，避免它被不相关的记忆误导。同时“说明原因”这个要求，也为我们后续优化检索策略提供了反馈信号。

4.5 记忆的更新与反馈闭环

记忆不是写完就完了，需要根据使用效果持续更新。我设计了一个简单的反馈机制：

每次记忆被检索并注入后，记录它的使用情况。如果任务成功完成，且用户没有提出异议，就给这些记忆的access_count加1，confidence加0.05（上限0.95）。如果任务失败，或者用户明确说“不对”，就给这些记忆的confidence减0.1。

def update_memory_feedback(memory_ids, success: bool): for mid in memory_ids: memory = memory_store.get_memory(mid) if not memory: continue memory.access_count += 1 memory.last_accessed_at = datetime.utcnow().isoformat() if success: memory.confidence = min(0.95, memory.confidence + 0.05) else: memory.confidence = max(0.1, memory.confidence - 0.1) memory_store.update_memory(memory)

这个反馈闭环让记忆系统有了自我进化的能力。经过几轮迭代，真正有用的记忆置信度会越来越高，噪音会被逐渐淘汰。

5. 常见问题与排查技巧实录

5.1 记忆检索不相关怎么办

这是最常见的问题。Agent检索出来的记忆和当前任务八竿子打不着，注入进去反而干扰了推理。

排查思路：先看检索出来的记忆的相似度分数。如果分数普遍低于0.6，说明向量模型可能不适合你的领域。比如你用all-MiniLM-L6-v2处理大量中文技术文档，它的中文语义理解能力可能不够。换成BAAI/bge-large-zh-v1.5试试。

如果相似度分数高但内容不相关，那可能是任务描述太短或太泛。比如任务描述是“处理数据”，那检索出任何和数据相关的记忆都不奇怪。解决办法是在任务描述里补充更多上下文，比如“处理用户上传的CSV文件，包含中文姓名和地址，需要清洗后入库”。

还有一个可能是记忆本身的content写得太泛。比如“使用pandas处理数据时要小心”这种记忆，看起来相关但没有任何指导意义。这需要在提炼Prompt里强调“具体、包含关键参数和条件”。

5.2 记忆冲突导致Agent行为不一致

同一个任务，两次执行结果不一样，因为检索到了不同的记忆。这种不一致性在调试时很让人头疼。

排查思路：检查是否有冲突的记忆没有被正确处理。用supersedes字段追踪记忆的覆盖关系，确保旧记忆的置信度已经降低。如果两条记忆置信度接近且内容冲突，考虑在注入时都带上，但标注“存在不同经验，请根据当前情况判断”。

另一个原因是检索的随机性。Chroma的查询默认是近似最近邻，可能有细微的随机性。如果对一致性要求高，可以把n_results设大一些，然后在Python层做精确排序。

5.3 记忆库膨胀导致检索变慢

跑了一段时间后，记忆库越来越大，检索速度明显下降。

排查思路：首先，定期清理低置信度的记忆。我设置了一个规则：置信度低于0.3且超过60天未访问的记忆，直接归档（从活跃库移到冷库）。其次，给Chroma的collection建索引。Chroma默认用HNSW索引，对于万级以下的记忆量，检索速度应该在毫秒级。如果到了十万级，考虑分片或换更专业的向量数据库。

还有一个技巧是记忆的合并。如果多条记忆在语义上高度相似（相似度>0.95），可以把它们合并成一条，取最高的置信度，合并访问次数。这样既能减少记忆数量，又能保留信息。

5.4 常见问题速查表

5.5 几个踩过的坑和实操心得

坑一：不要用LLM生成记忆的向量。我一开始图省事，直接用LLM的embedding API生成向量。后来发现成本高不说，而且LLM的embedding对短文本的区分度不如专门的sentence-transformers模型。换成本地模型后，效果更好，成本为零。

坑二：记忆的content不要用Markdown格式。我试过用Markdown的列表和加粗来组织记忆内容，结果注入到Prompt后，LLM有时候会把Markdown符号也当成内容的一部分来理解。后来改成纯文本，用分号或句号分隔要点，效果好很多。

坑三：任务类型标签要统一。一开始我让LLM自由生成task_type，结果出现了“data_cleaning”“data-clean”“清洗数据”等多种写法，导致任务类型匹配失效。后来我维护了一个预定义的任务类型列表，让LLM从中选择，问题就解决了。

坑四：记忆的注入位置影响很大。我试过把记忆放在System Prompt里，结果LLM把它当成了系统指令的一部分，过于严格地遵守。后来改成放在User Message里，用[相关经验]标注，LLM的响应就自然多了。

坑五：不要忽略失败记忆的价值。我一开始只记录成功的经验，后来发现失败的经验同样重要。Agent知道“上次这样做失败了”，比知道“上次那样做成功了”有时候更有价值，因为它能避免重复踩坑。

6. 记忆系统的扩展方向与个人体会

“hindsight”这个项目做下来，我最大的体会是：Agent Memory不是一个纯技术问题，而是一个产品问题。技术上的实现方案有很多种，向量数据库、图数据库、关系数据库都能用。但真正决定记忆系统好不好用的，是你对Agent使用场景的理解。

比如，如果你的Agent是面向个人用户的助手，那记忆的个性化就很重要，需要区分不同用户的记忆。如果你的Agent是面向企业内部的自动化工具，那记忆的共享和权限管理就是重点。如果你的Agent是处理一次性任务的，那记忆系统可能根本不需要，每次从零开始反而更干净。

后续的扩展方向，我觉得有几个值得探索：

记忆的主动遗忘。现在我的方案是被动衰减，置信度低了自然就不检索了。但更优雅的做法是主动识别哪些记忆已经过时，主动删除或归档。这需要结合任务的成功率和用户反馈来做判断。

跨Agent的记忆共享。如果多个Agent处理相关任务，它们之间的记忆能不能共享？比如一个Agent负责数据清洗，一个Agent负责数据分析，数据清洗的经验对数据分析Agent也有价值。这需要设计一套记忆的共享协议和权限模型。

记忆的可解释性。当Agent做出一个决策时，能不能追溯到它是基于哪条记忆做出的？这在调试和审计场景下很重要。我目前的方案是在日志里记录检索到的记忆ID，但还没有做到端到端的可解释。

与MCP生态的集成。现在MCP协议越来越普及，如果能把记忆系统做成一个MCP Server，那任何支持MCP的Agent都能直接调用，不需要每个项目都重新实现一遍。这可能是“hindsight”最有价值的扩展方向。

最后分享一个小技巧：在调试记忆系统时，我习惯把每次检索到的记忆和最终的任务结果都记录下来，定期人工review。你会发现有些记忆被频繁检索但从未导致成功，这些就是“看起来相关但实际没用”的记忆，应该降低权重或直接删除。这个人工review的过程，比任何自动化的评估指标都更能发现问题。