Agent记忆及实现

核心概念

记忆的类型

https://arxiv.org/pdf/2504.01990

Agent的记忆类型

 

记忆内容

记忆窗口

适用场景

可能的实现方案(个人理解)

short-term working memory

    • 单次run
    • 长程+信息密集型的推理任务
    • reason & observation

单次运行内

mins

deepResearch

单次运行涉及多步推理的场景

存:主动存

取:指定取,或agentic tool call

short-term working memory

    • 单次会话thread
    • 多次run
    • 多轮交互历史
    • 可能不包括历史轮的中间过程

 

单次thread内

mins~hours

通用

存:后台存或异步存,列式,相对非结构化的信息压缩

取:retrieval with context window

User-specific long-term memory:

    • 单一用户
    • 跨thread
    • semantic & episodic为主
    • 用户偏静态用户画像
    • 用户行为习惯及偏好
    • 用户重要事件和经历
    • 用户信息三元组

中长期

week ~ month ~years

“千人千面”电商场景

家居规划Plus

存:后台存,相对结构化的Profile + 列式集合Collection

先验取:retrieval with context relevance (semantic & structured)

后验取:agentic tool call

Domain-specific long-term memory:

    • 多用户+ 专家
    • 独立于单个用户经验的
    • procedural
    • 领域相关的知识性或事实性记忆
    • 千人不千面的领域经验(example)
    • 智能体的核心个性
    • 智能体的响应模式(SOP)
      • 知道如何控制设备
      • 知道作为客服专家服务用户的SOP

长期,相对变化较少

~infinite

通用

不同场景的形式和内容具有一定的差异性

存:离线存,定期数据分析&回流领域知识库

先验取:retrieval with rag,作为提示词in-context

一般作为先验背景知识指导决策

sensory memory

    • 环境相关,客观存在或发生
    • 即时响应 vs 非即时响应

•外部环境感知

•家居环境感知

•环境事件(水洒,冒烟,...)

长短不一,动态变化

min ~ infinite

具身智能

家居规划

存:即时响应类事件直接件触发,非即时响应离线结构化存(应用无关)

先验取:retrieval with context relevance

后验取:agentic tool call

何时记

形成类型

延迟影响

更新速度

处理负载

用例

 

主动

更高

即时

响应期间

关键上下文更新

后台

延迟

调用之间/之后

模式分析,总结

 

关键技术

Short-term Run Memory

  • 目标:单次运行内的工作记忆(包括多步任务,状态和中间结果)有条理有计划的记住和使用
  • 适用场景:单轮多步,信息密集型推理任务
  • 要点:
    • 交互过程直接、显式的触发记忆的增删改查(例如任务列表等列式记忆)
    • 记忆的结构:Task-oriented schema
      • 以规划任务管理为例,需要支持的基本操作
        • 创建任务create
        • 更新任务(状态,结果)update
        • 删除任务delete
        • 查询任务 list retrieve
      • 记忆的结构: 通常单条任务需要一些基础的信息元素
        • id: 任务唯一标识符
        • title: 任务标题
        • 不同场景会有不同的其他信息的记录需求,例如
        • 条件和依赖:在什么条件下才需要执行该任务,依赖什么信息
        • 状态和结果:任务的完成的状态、步骤、结果
    • 实现:由于不需要持久化存储,
      • 可以考虑使用langmem.create_memory_manager进行列式或过程记忆的管理
      • 或者采用类似manus todo.md和claude Code的文件化记忆

Short-term Thread Memory

  • 目标:保留着单个thread对话中的消息列表,以及其他关键信息。支持上下文对话的连贯和一致性
  • 适用场景:绝大部分需要多轮对话的场景
  • 要点:
    • 记忆的结构:messages,
      • 一般以人机交互界面的消息为主,较少涉及单/多智能体内部的交互消息
    • langGraph提供的存取能力
 

主要类

主要能力

Basic

langgraph.checkpoint

方便的将对话过程中的状态信息进行记忆, 特别是对话交互的messages

    • 可以通过schema定义额外的状态
    • 和langGraph耦合较深

Plus

langmem.short_term. SummarizationNode

    • 当thread messages超过max_tokens_before_summary时,会对消息进行总结,形成对话状态的summarized_messages"
    • 需要根据需求结合到主流程每次run之后异步或后台总结
      • 和langgraph本身的耦合性能较好,单独使用可能需要输出输入的适配

Long term User memory

  • 用户记忆的重点是围绕每位用户建立详细档案,从而记住他们的偏好、个性化需求和关键事件。
  • 适用场景: 通常是需要个人性化体验的应用,特别是2C的应用 (客服,智能家居人机交互)
  • 要点:
    • 记忆的结构:
 

说明

示例

profile 用户画像

相对简洁、平面的用户画像

Schema-based 结构化特征或属性的用户描述

较少变化,已更新操作为主

不同场景关注的画像属性会有一定的差异

    • Personal context (name, language, timezone)
    • Communication preferences (formality, detail level, expertise)
    • Interaction highlights (last conversation, common topics, key relationships)

collections 用户事件

随时间变化的用户事件、信息,not just "what" but "why" and "how".

Schema-based

事件可以是文本化的形式

也可以是结构化的形式,例如subject-predicate-object三元组

可以用schema约束predicate的范围?

enable_inserts=False

  • langgraph提供的存取能力
 

主要类/方法

要点

主动存

langmem.create_memory_manager

langmem.create_memory_store_manager

langmem..create_manage_memory_tool

create_manage_memory_tool(("memory"), schema=Triple)

function = {
	'name': 'manage_memory',
	'description': 'Create, update, or delete a memory to persist across conversations.\nInclude the MEMORY ID when updating or deleting a MEMORY. Omit when creating a new MEMORY - it will be created for you.\nProactively call this tool when you:\n\n1. Identify a new USER preference.\n2. Receive an explicit USER request to remember something or otherwise alter your behavior.\n3. Are working and want to record important context.\n4. Identify that an existing MEMORY is incorrect or outdated.',
	'parameters': {
  		'type': 'object'
		'properties': {
			'content': {'anyOf':[
				{
					'title': 'Triple',
					'description': 'Store all new facts, preferences, and relationships as triples.',
					'type': 'object'
					'properties': {
						'subject': {'title': 'Subject', 'type': 'string'},
       					'predicate': {'title': 'Predicate', 'type': 'string'},
       					'object': {'title': 'Object', 'type': 'string'},
       					'context': {'anyOf': [{'type': 'string'}, {'type': 'null'}],'default': None}},
      				'required': ['subject', 'predicate', 'object'],
				},{
					'type': 'null'
				}],'default': None
			},
   			'action': {
				'default': 'create',
    			'enum': ['create', 'update', 'delete'],
    			'type': 'string'
			},
			'id': {
				'anyOf': [
					{'format': 'uuid', 'type': 'string'}, 	
					{'type': 'null'}
				],'default': None}
			},
  	'required': []
	}
}

 

    • 可以使用create_memory_manager(无持久化store), create_memory_store_manager(有store) 后进行显式的工具调用
    • 或者create_manage_memory_tool将记忆存储作为工具
      • 作为工具时action, id和content是上层参数
      • schema是content的下一层参数
      • 因此如果schema较为复杂,会涉及function参数的多层嵌套,对大模能力要求较高
    • 支持配置
      • instructions文本说明记忆的指令任务(记什么),
      • schema指定记忆的数据模式(记忆模式)
      • 支持的记忆操作("create", "update", "delete")
    • 可以通过共用store实现共享记忆

后台存

langmem.reflection.ReflectionExecutor

通过ReflectionExecutor(memory_store_manager)可以提交delay的记忆存储,减少频繁调用

指定搜索

langgraph.store.base.BaseStore

def search(
    self,
    namespace_prefix: tuple[str, ...],
    /,
    *,
    query: str | None = None,
    filter: dict[str, Any] | None = None,
    limit: int = 10,
    offset: int = 0,
    refresh_ttl: bool | None = None,
) -> list[SearchItem]:
	pass

 

nameSpace分区

query语义搜索

metadata filter 筛选

    • 目前原生支持的redis, sql ,sqlite作为持久化存储,有些似乎不支持语义化向量搜索,有些虽然支持,但是工程角度不够稳定和可靠(有可能还没找到)
    • 资源:这里可能需要一些工程化的资源,深度理解langGraph的store设计,设计稳定的工程结构和排坑

 

工具化搜索

create_search_memory_tool

{
	'name': 'search_memory',
	'description': 'Search your long-term memories for information relevant to your current context.',
	'parameters': {'properties': {'query': {'type': 'string'},
	'limit': {'default': 10, 'type': 'integer'},
	'offset': {'default': 0, 'type': 'integer'},
	'filter': {
		'anyOf': [{'additionalProperties': True, 'type': 'object'},{'type': 'null'}],
    	'default': None}
	},
  	'required': ['query'],
  	'type': 'object'}
}

 

支持工具化推理和搜索

    • 目前的create_search_memory_tool看起来并没有比较好的支持schema-based 结构化搜索
    • 更好的配合存储结构,需要一定程度的改造

业界产品的记忆实现

 

Manus文本化记忆:

  • Context Engineering for AI Agents: Lessons from Building Manus
  • Manus是典型的押注于上下文工程,而非端到端智能体模型的公司
  • 使用文件系统作为上下文,通过“坐标“指向内容,例如url, 文件路径
    • 将长观测结果放在文件中,提供”坐标“而非内容本身作为上下文
    • 结合web_visit和file_read工具,可以回顾原始上下文
  • 处理复杂任务是,采用了他们称之为“复述 (Recitation)”的技巧。
    • 让 Agent 维护一个 todo.md 文件,并周期性地回顾和更新其内容(非结构化

 

claude code Agent: 三层记忆窗口,偏文件化的记忆

  • 短期记忆层 (Short-term Memory): 对应于当前对话轮次中的消息流 (Messages),这是最活跃、最详细的信息层。
  • 中期记忆层 (Mid-term Memory): 当短期记忆接近 LLM 上下文窗口的 92% 阈值 时,触发 wU2 消息压缩器,调用 AU2算法 进行压缩。
    • 该算法并非简单地截断历史,而是通过理解对话内容,将其压缩成一个语义密度更高的摘要。
    • 压缩后的内容已结构化的形式文本化结构储存,模拟了开发者回顾项目时的思维模式
      • Primary Request and Intent (主要请求和意图): 用户的核心目标是什么? Key Technical Concepts (关键技术概念): 对话中涉及的框架、算法、库等。 Files and Code Sections (文件和代码片段): 所有被提及或修改过的代码和文件路径。 Errors and fixes (错误和修复): 记录遇到的错误信息和最终的解决方案。 Problem Solving (问题解决过程): 解决问题的完整思路和决策路径。 All user messages (所有用户消息): 保留用户的关键指令和反馈。 Pending Tasks (待处理任务): 未完成的工作项,形成待办清单。 Current Work (当前工作状态): 明确记录当前对话中断时的进度。
    • wU2 压缩器在生成摘要后,还实施了一套严格的质量验证机制,确保压缩过程不会损害关键信息的完整性。

四重检查,加权平均

压缩质量验证失败时,启动降级决策,确保系统在任何情况下都能继续运行

    • 平均压缩率可达 78%,单次压缩可节省 4000-6000 Token
  • 长期记忆层 (Long-term Memory): 对应于持久化的项目信息、用户偏好等,通常存储在 CLAUDE.md 等文件中。
    • 用户可编辑
    • 可以本地化,对于隐私和权限问题的顾虑少?
    • 支持但非强制向量化搜索,当新的对话开始时,系统可以将用户的问题转换成向量,在长期记忆库中进行相似度检索,从而“回忆”起过去相关的经验,

共同点:文件系统作为记忆+结构化内容

Claude和Manus都不约而同的使用了文件化的记忆

  • 对于中短期记忆的内容,做了结构化形式的总结
  • 可能从可扩展性和可维护性角度,未使用大规模的结构化存储系统?
    • 可能也有场景化的考虑?
  • 对于文件操作工具有一定的要求
  • 文件化,也天然的给human in the loop, 对用户更容易透明和可控

 

 

主要挑战

  • rag 选择哪种记忆结构和存储
    • 非结构化记忆
      • 适合内容比较长尾的或不可枚举的文本化记忆
      • 总结和挖掘完全依赖LLM,精确性和提取效率较低
      • 容易存在关键信息遗漏,非关键信息冗余,以及幻觉问题
      • 中间态(非结构化文本+结构式内容)对于中短期记忆也是常用的一种方式
    • 结构化记忆,不同场景下,schema具有一定差距
      • 适合对精度要求比较高的记忆(例如 数值、时间、可枚举类)
      • 信息存储对于模型的嵌套结构化输出能力要求交过
      • 记忆检索时,对于模型结构化输出和也有一定的要求
    • 图记忆
      • mem0为例

add

search

  • 记忆专用模型
    • 以较小的参数量实现高效的记忆存取
    • 每个记忆schema一个模型 vs 每个场景一个模型 vs 每个领域一个模型 vs 通用记忆模型?
    • NLP任务能力角度:
      • 大模型:结构化信息输出
      • 大模型:嵌套结构的结构化信息输出(支持shema=obj)
      • 较大的上下文(支持中长程记忆的update, delete操作)
      • 向量模型:获取相关性的记忆是否需要定制向量模型?
  • 工程化: 对于langgraph和langMemo的深度理解
    • 需要对相关框架非常理解,能改的动
    • 稳定、可持续的工程化设计
  • MCP server: 服务化复用

Ref:

页面附件

附件

image2025-7-8_14-30-35.png

posted on 2026-08-01 21:49  limingqi  阅读(13)  评论(0)    收藏  举报

导航