AI-Agent 长期记忆、记忆机制与上下文工程详解

code_pgf

639人浏览 · 2026-06-30 15:41:04

code_pgf · 2026-06-30 15:41:04 发布

请添加图片描述

摘要

AI-Agent 的长期记忆能力并不是模型参数被实时更新，也不是简单把全部历史聊天记录塞进 prompt，而是通过外部持久化存储、记忆抽取、语义索引、检索排序、上下文注入、反思整合与遗忘治理构成的一套系统工程。长期记忆解决的是“跨会话持续保存与召回”的问题；记忆机制解决的是“什么值得记、如何存、如何取、如何用、如何更新”；上下文工程解决的是“在有限上下文窗口内，每一步到底给模型放入哪些信息”。

LangChain 文档将短期记忆定义为单个线程或会话范围内的 state，将长期记忆定义为跨会话、跨线程持久保存并可召回的数据；OpenAI Agents SDK Cookbook 也给出了把用户画像与全局记忆 notes 注入系统提示词的实践样例。[1][2][3] LangChain 对 context engineering 的概括是：为 Agent 轨迹中的每一步填充“刚好合适”的上下文，并将策略归纳为 write、select、compress、isolate 四类。[4]

1. 基本概念界定

1.1 什么是 AI-Agent 的“长期记忆能力”？

AI-Agent 的长期记忆能力，是指 Agent 可以在多个会话、多个任务甚至较长时间跨度内保存并调用历史信息，例如：

用户偏好：喜欢中文、喜欢 Markdown、希望报告偏技术化；
项目背景：用户正在研究 AI-Agent、Function-Calling、记忆机制；
任务状态：某个报告已完成到第几版，哪些内容已确认；
过往经验：上次工具调用失败的原因、某个 API 的参数要求；
领域知识：团队规范、产品规则、业务流程、论文资料。

长期记忆不是“大模型自己脑子里永久记住了”，而是：

长期记忆能力 = 外部记忆库 + 记忆管理策略 + 检索与上下文注入 + 更新与遗忘机制

1.2 什么是 AI-Agent 的记忆机制？

记忆机制是 Agent 对信息进行写入、存储、检索、使用、更新、遗忘的完整闭环。

观察输入 → 抽取重要信息 → 写入记忆库 → 建立索引
       → 后续任务检索相关记忆 → 注入上下文 → 辅助推理与行动
       → 根据新反馈更新、合并、删除或降权旧记忆

1.3 什么是上下文工程？

上下文工程不是简单的“写提示词”，而是围绕上下文窗口进行系统设计：

上下文工程 = 在每一次模型调用前，选择、组织、压缩、隔离并注入最有价值的信息

它处理的问题包括：

哪些系统规则必须放进上下文？
哪些历史对话需要保留？
哪些长期记忆与当前任务相关？
检索文档、工具结果、用户偏好、任务状态如何排序？
上下文太长时，哪些内容要压缩或删除？
多 Agent 协作时，是否要为不同子 Agent 隔离不同上下文？

2. AI-Agent 如何具备长期记忆能力？

2.1 长期记忆能力的核心问题

大模型有固定上下文窗口。上下文窗口再大，也不等于真正的长期记忆，因为：

长会话会带来成本和延迟增加；
全量历史信息会稀释注意力；
旧信息可能过时或与当前任务冲突；
错误历史如果反复注入，会造成记忆污染；
用户希望某些信息可查看、可修改、可删除。

因此，长期记忆能力的核心不是“无限上下文”，而是“可控的外部状态管理”。MemGPT 也提出用类似操作系统分层内存的虚拟上下文管理方法，在有限上下文窗口和外部存储之间移动信息，以支持多会话聊天和长文档分析。[8]

2.2 长期记忆系统的基本架构

一个典型长期记忆 Agent 可以拆成七个模块：

模块	作用	常见实现
观察层	接收用户输入、工具结果、环境状态	chat logs、events、tool outputs
记忆抽取器	判断什么值得保存	LLM extractor、规则、分类器
规范化层	去重、结构化、加标签	JSON、schema、metadata
存储层	持久化保存记忆	KV store、SQL、vector DB、KG
检索层	找到相关记忆	embedding、BM25、hybrid search
上下文工程层	把记忆转成可用上下文	prompt assembly、compression
更新治理层	合并、覆盖、删除、降权	versioning、TTL、user controls

2.3 长期记忆的写入流程

长期记忆写入不是“把全部聊天记录保存下来”这么简单，而是需要筛选和结构化。

推荐流程如下：

原始输入
  ↓
判断是否值得长期保存
  ↓
抽取事实 / 偏好 / 任务状态 / 经验
  ↓
转换为结构化 MemoryItem
  ↓
加上来源、时间、置信度、权限、主题标签
  ↓
写入数据库并生成向量索引

示例：

用户：以后帮我写 AI 技术报告时，尽量用中文，结构清楚一点。

可写成：

{
  "id": "mem_20260630_001",
  "type": "user_preference",
  "content": "用户希望 AI 技术报告使用中文，并保持结构清晰。",
  "topic": "AI技术报告",
  "scope": "user_global",
  "confidence": 0.95,
  "source": "user_explicit",
  "created_at": "2026-06-30",
  "last_used_at": null
}

2.4 长期记忆的检索流程

检索不是只看“语义相似度”，还要综合多个因素：

相关性：这条记忆和当前任务是否相关？
重要性：它是否影响输出质量或任务决策？
新近性：是否近期产生或近期使用过？
可信度：来源是否可靠？是否用户明确表达？
作用域：是否只属于某项目、某会话、某角色？
风险：是否包含敏感、过时、冲突或恶意内容？

一个可解释的排序公式可以写成：

MemoryScore = α × Relevance + β × Importance + γ × Recency + δ × Trust - λ × Risk

其中 α、β、γ、δ、λ 可以根据场景调整。例如医疗、法律、金融场景应提高 Trust 与 Risk 权重；个人助理场景可提高用户偏好记忆的 Importance。

2.5 长期记忆的注入流程

检索出的记忆不能原样无限塞进上下文。通常要经过上下文工程处理：

候选记忆 → 去重 → 冲突检查 → 风险过滤 → 摘要压缩 → 按优先级排序 → 注入 prompt

示例注入片段：

相关长期记忆：
- 用户正在系统学习 AI-Agent 技术。
- 用户偏好中文 Markdown 技术报告。
- 用户之前已讨论 Function-Calling、Agent 局限性与评价指标。

当前任务：
详解 AI-Agent 的长期记忆、记忆机制与上下文工程，并输出 .md 报告和动态 GIF。

2.6 长期记忆的更新与遗忘

长期记忆必须支持更新和遗忘，否则会变成污染源。

操作	说明	示例
新增	保存新偏好、新事实、新经验	用户明确说“记住以后用中文”
合并	多条相似记忆合成一条	多次提到报告要结构化
覆盖	新偏好替换旧偏好	“以后回答简洁一点”覆盖“回答详细”
降权	长期不用或不确定的记忆降低优先级	旧项目偏好过期
删除	用户要求忘记或合规删除	删除个人信息
过期	临时信息到期自动失效	“明天会议”过期后不再使用

2.7 长期记忆能力的工程模式

模式一：结构化用户画像

适合个人助理、教育助理、客服系统。

{
  "user_profile": {
    "language": "zh-CN",
    "preferred_format": "Markdown",
    "technical_depth": "intermediate_to_advanced",
    "current_projects": ["AI-Agent 技术报告"]
  }
}

优点是稳定、可解释、易治理；缺点是表达能力有限，不适合复杂经历。

模式二：向量化语义记忆

适合大量自由文本记忆，例如历史对话、笔记、文档摘要。

Memory text → Embedding → Vector DB → 相似检索 → 重排序 → 注入上下文

优点是召回灵活；缺点是容易出现“语义相似但任务不该使用”的问题。2026 年关于个人 Agent 记忆搜索安全的研究也指出，仅靠语义相似度可能导致跨域泄露、工具调用漂移、记忆诱导越狱等风险，需要任务条件化的记忆准入控制。[12]

模式三：事件流 + 反思总结

Generative Agents 采用 memory stream 保存观察、计划和反思，并通过动态检索支持行为规划；其架构表明 observation、planning、reflection 对智能体可信行为都有重要作用。[7]

原始事件流：
- 用户询问 Function-Calling
- 用户要求生成 Markdown 报告
- 用户继续询问记忆机制

反思总结：
- 用户正在系统学习 AI-Agent，偏好结构化技术报告。

模式四：分层记忆 / Memory OS

MemoryOS 这类方法把记忆分成短期、中期、长期个人记忆，并设计存储、更新、检索和生成四个模块，试图像操作系统一样管理 Agent 记忆。[11]

短期记忆：当前会话最近内容
中期记忆：一段时间内的任务摘要
长期记忆：稳定偏好、长期项目、重要经验

模式五：记忆操作工具化

更高级的 Agent 会把记忆操作暴露为工具：

save_memory()
search_memory()
update_memory()
delete_memory()
compress_memory()

这样模型可以在任务过程中主动决定“什么时候存、什么时候取、什么时候更新”。这与 Agentic Memory 的研究方向一致：让 Agent 把短期与长期记忆管理纳入自身策略，而不是完全依赖外部固定规则。[13]

3. AI-Agent 中记忆机制的原理与作用

3.1 记忆机制的本质

记忆机制的本质是：

把过去的信息转化为未来可用的上下文资产。

它包括三个层面：

存储层：信息保存在哪里；
控制层：什么信息该保存、该检索、该删除；
使用层：如何把记忆变成当前推理的有效上下文。

3.2 记忆类型划分

记忆类型	含义	典型内容	生命周期
工作记忆 / 短期记忆	当前任务正在使用的信息	最近对话、当前计划、工具结果	当前会话或任务
语义记忆	稳定事实和概念	用户偏好、业务规则、领域知识	长期
情景记忆	过去发生过的具体事件	上次任务过程、失败原因、关键决策	中长期
程序性记忆	做事方法和流程	写报告格式、代码规范、运营 SOP	长期
实体记忆	关于人、项目、产品、组织的结构化资料	用户、客户、课程、项目	长期
反思记忆	从多个事件中总结出的高层洞察	“用户正在系统学习 AI-Agent”	中长期

LangChain 文档也使用 semantic、episodic、procedural 等分类来解释长期记忆的内容类型。[1]

3.3 记忆机制的运行闭环

3.4 记忆机制的主要作用

作用一：保持对话连续性

没有记忆的 Agent 每次都像第一次见用户；有记忆的 Agent 可以理解“上次那个报告”“刚才那两个问题”“按我之前的格式”等指代。

作用二：实现个性化

记忆可以保存用户的表达风格、专业背景、格式偏好、语言偏好，使输出越来越贴近用户需求。

作用三：支撑长期任务

论文写作、软件开发、运营策划、项目管理等任务都需要跨多轮保存目标、约束、版本和反馈。长期记忆使 Agent 能够持续推进任务，而不是每轮重启。

作用四：提高规划质量

Agent 做计划时需要知道历史状态：哪些步骤已完成、哪些方案被否定、哪些工具调用失败过、哪些约束不能违反。

作用五：降低上下文成本

通过摘要、压缩、检索，Agent 不需要每次塞入完整历史记录，而是只注入少量高价值记忆。

作用六：支持经验学习

记忆可以沉淀成功经验和失败教训，使 Agent 避免重复错误。例如代码 Agent 记住某项目不能升级某依赖版本；客服 Agent 记住某客户已提交过材料。

作用七：支持多 Agent 协作

在多 Agent 系统中，共享记忆可以让研究 Agent、写作 Agent、审校 Agent、工具 Agent 围绕同一任务状态协作。

3.5 记忆机制的风险

风险	表现	防护策略
记错	把临时表达当长期偏好	写入前分类和置信度判断
记太多	记忆库臃肿，召回噪声增加	去重、摘要、TTL、重要性评分
记忆过时	旧偏好覆盖新偏好	时间戳、版本、冲突检测
检索错误	召回语义相似但不该使用的记忆	重排序、任务条件化准入
记忆污染	恶意内容写入长期记忆	安全过滤、权限隔离
隐私风险	保存敏感信息	用户可查看、可删除、最小化保存
上下文漂移	过多历史让 Agent 偏离任务	context budget、压缩、隔离

4. AI-Agent 上下文工程的原理

4.1 上下文工程解决什么问题？

LLM 每次调用时只能基于当前上下文生成输出。Agent 的能力很大程度上取决于这次调用前是否给了它正确的信息。

上下文工程要解决的问题是：

在有限 token 预算下，如何让模型看到最相关、最可靠、最有行动价值的信息？

OpenAI Agents SDK Cookbook 中的 session memory 示例强调通过 trimming 和 compression 管理上下文，使 Agent 更快、更可靠、更节省成本。[5] LangChain 的 context engineering 文章则把主要方法归纳为 write、select、compress、isolate 四类。[4]

4.2 上下文工程与提示词工程的区别

对比项	提示词工程	上下文工程
关注点	怎么写指令	每次模型调用前放入什么信息
范围	多为单次 prompt	覆盖状态、记忆、工具、检索、压缩、隔离
数据来源	人写的 instructions	用户输入、记忆库、工具结果、文档、系统状态
目标	提升回答质量	提升 Agent 长程任务稳定性
典型动作	改写 prompt	选择、排序、压缩、注入、隔离上下文

可以说：

提示词工程是“写好指令”；
上下文工程是“管理模型可见世界”。

4.3 上下文的组成

一个 Agent 调用模型时，上下文通常由以下部分组成：

System Instructions：角色、边界、规则
Developer / Policy Context：业务流程、合规要求、工具约束
User Input：当前用户请求
Conversation State：当前会话摘要、任务状态
Long-term Memory：用户偏好、历史任务、项目背景
Retrieved Knowledge：外部文档、数据库、网页检索结果
Tool Definitions：可用工具名称、描述、参数 schema
Tool Results：工具调用返回结果
Examples / Few-shot：示例任务轨迹
Scratchpad / Plan：中间计划、待办项、状态变量

4.4 上下文工程四类策略

4.4.1 Write：写入上下文或外部状态

Write 指把任务过程中产生的重要信息写入某个状态容器。

用户要求 → 写入任务状态
工具结果 → 写入观察日志
重要偏好 → 写入长期记忆
复杂历史 → 写入摘要

Write 的关键不是保存全部信息，而是保存未来会用的信息。

4.4.2 Select：选择相关上下文

Select 指从大量候选信息中挑选当前最有用的内容。

候选来源包括：

最近对话；
长期记忆；
RAG 文档；
工具结果；
当前任务状态；
用户画像；
业务规则。

选择过程通常使用：

关键词匹配 + 向量检索 + 元数据过滤 + 重排序 + 安全准入

4.4.3 Compress：压缩上下文

当上下文过长时，需要压缩：

压缩方式	适合内容
滑动窗口	最近对话
摘要	长对话、长文档
结构化提取	用户偏好、任务约束
层级摘要	长项目、长代码库
证据片段化	法律、科研、金融材料

压缩的风险是丢失细节，因此最好保留“摘要 + 原始引用指针”。

4.4.4 Isolate：隔离上下文

Isolate 指不同任务、不同子 Agent、不同工具调用使用不同上下文，避免互相污染。

例如：

研究 Agent：只看资料和引用规则
写作 Agent：只看大纲、材料和风格要求
审校 Agent：只看成稿和审校标准
工具 Agent：只看工具参数，不看无关隐私信息

隔离可以降低上下文噪声，也可以降低隐私泄露风险。

4.5 上下文组装流程

4.6 上下文工程的设计原则

原则一：最小充分上下文

不要把所有信息都放进去，而是放“足以完成当前步骤”的信息。

不是 more context，而是 right context。

原则二：高优先级信息显式化

关键约束、用户明确要求、合规规则、工具边界应放在稳定且显眼的位置，避免被长上下文淹没。

原则三：事实与偏好分离

事实记忆、偏好记忆、工具结果、推理中间状态应分区存放，避免模型把偏好当事实，或把历史猜测当证据。

原则四：保留来源与时间

记忆和检索结果最好带上来源、时间、置信度，方便模型判断是否可信。

原则五：压缩但不失真

摘要要保留关键实体、数值、时间、约束和用户否定过的方案。

原则六：上下文可观测

生产系统需要记录每次模型调用到底注入了哪些记忆、文档、工具定义和策略，方便调试与评估。

5. 长期记忆、记忆机制、上下文工程三者关系

三者不是并列孤立的，而是层层递进：

长期记忆：解决信息能否跨会话保存
记忆机制：解决信息如何写入、检索、更新、遗忘
上下文工程：解决当前这一步应该如何使用这些信息

关系图：

可以把它们理解为：

层级	关注问题	工程产物
长期记忆	过去信息保存在哪里	memory store、vector DB、profile
记忆机制	信息如何流动和治理	extractor、retriever、updater、deleter
上下文工程	本次调用放什么信息	prompt assembler、compressor、context router
模型推理	基于上下文如何行动	plan、tool call、answer

6. 典型技术实现方案

6.1 MemoryItem 数据结构

from dataclasses import dataclass
from typing import Literal, Optional, Dict

@dataclass
class MemoryItem:
    id: str
    user_id: str
    type: Literal["semantic", "episodic", "procedural", "profile", "task_state"]
    content: str
    topic: str
    source: str
    scope: str
    confidence: float
    importance: float
    created_at: str
    updated_at: str
    expires_at: Optional[str]
    embedding_id: Optional[str]
    metadata: Dict

6.2 写入伪代码

def maybe_write_memory(user_input, model_output, tool_results, user_id):
    candidates = extract_memory_candidates(
        user_input=user_input,
        model_output=model_output,
        tool_results=tool_results
    )

    for item in candidates:
        if not is_worth_saving(item):
            continue
        if violates_policy(item):
            continue

        normalized = normalize_memory(item)
        existing = search_similar_memory(normalized, user_id=user_id)

        if existing and should_merge(existing, normalized):
            update_memory(existing.id, merge(existing, normalized))
        else:
            save_memory(normalized)
            index_embedding(normalized)

6.3 检索伪代码

def retrieve_memories(query, user_id, task_scope, token_budget):
    candidates = hybrid_search(
        query=query,
        user_id=user_id,
        filters={"scope": task_scope}
    )

    scored = []
    for mem in candidates:
        score = (
            0.45 * relevance(query, mem)
            + 0.20 * mem.importance
            + 0.15 * recency(mem)
            + 0.15 * mem.confidence
            - 0.30 * risk_score(mem, query)
        )
        scored.append((score, mem))

    selected = select_under_token_budget(scored, token_budget)
    return compress_for_prompt(selected)

6.4 上下文组装伪代码

def build_agent_context(user_input, session_state, user_id):
    intent = classify_intent(user_input)

    short_context = summarize_recent_messages(session_state.messages)
    task_state = load_task_state(session_state.task_id)
    memories = retrieve_memories(
        query=user_input,
        user_id=user_id,
        task_scope=task_state.scope,
        token_budget=1200
    )
    docs = retrieve_external_docs(user_input, token_budget=1800)
    tools = select_tools(intent)

    context = assemble_prompt(
        system_rules=BASE_RULES,
        task_state=task_state,
        user_memories=memories,
        recent_context=short_context,
        retrieved_docs=docs,
        tools=tools,
        user_input=user_input
    )
    return context

7. 评价指标

长期记忆与上下文工程不能只看最终回答是否好，还应从过程质量评估。

指标类别	具体指标	说明
任务效果	Task Success Rate	任务是否完成
记忆召回	Memory Recall	该用的记忆是否被检索到
记忆精确率	Memory Precision	检索出的记忆是否真正相关
上下文效率	Token Efficiency	有效信息 / 总 token 比例
一致性	Longitudinal Consistency	跨会话回答是否一致
个性化	Personalization Accuracy	是否正确使用用户偏好
稳定性	Drift Rate	长任务中是否偏离目标
安全性	Memory Leakage / Poisoning Rate	是否泄露或误用记忆
可解释性	Traceability	能否追溯使用了哪条记忆
延迟成本	Latency / Cost	检索、压缩、调用成本

8. 常见错误做法与改进建议

错误一：把完整历史聊天全部塞入上下文

问题：成本高、噪声大、容易上下文漂移。
改进：使用摘要、检索、重要性评分和任务状态结构化。

错误二：只用向量相似度检索长期记忆

问题：相似不等于该用。
改进：加入任务作用域、时间、可信度、安全准入、用户权限。

错误三：只存事实，不存来源和时间

问题：无法判断新旧、可信度和冲突。
改进：MemoryItem 必须保存 source、created_at、confidence、scope。

错误四：没有删除和更新机制

问题：记忆会越来越过时。
改进：支持用户查看、编辑、删除；支持 TTL 与版本管理。

错误五：把工具结果直接当长期事实

问题：工具结果可能临时、错误或过期。
改进：工具结果先进入事件日志，经过验证后再沉淀为长期记忆。

9. 示例：一个具备长期记忆的学习型 AI-Agent

场景：用户持续学习 AI-Agent。

第 1 次交互

用户：Function-Calling 如何把外部工具变成模型可以理解的方式？
Agent：解释工具描述、JSON Schema、模型生成 tool call、后端执行。
写入记忆：用户正在学习 Function-Calling 基础。

第 2 次交互

用户：大模型如何学习 Function-Calling 能力？
Agent：检索上次记忆，继续解释预训练、SFT、强化学习、工具轨迹数据。
写入记忆：用户关注 Function-Calling 的训练机制。

第 3 次交互

用户：详解 AI-Agent 中的记忆机制。
Agent：检索前两次记忆，知道用户正在系统学习 AI-Agent，输出结构化技术说明。
写入记忆：用户偏好 Markdown 技术报告。

第 4 次交互

用户：详细整理长期记忆、记忆机制和上下文工程，并输出 .md 和 GIF。
Agent：读取长期偏好 + 当前会话状态 + 相关技术资料，生成完整报告和动态图。

这体现了长期记忆与上下文工程的协同：

长期记忆保存历史学习轨迹；
记忆机制决定哪些历史值得保存；
上下文工程决定当前报告生成时使用哪些历史信息。

10. 工程落地建议

10.1 最小可用架构

如果要快速实现一个具备长期记忆能力的 Agent，可以从以下架构开始：

1. 最近 10～20 轮对话作为短期记忆
2. 每轮结束后抽取用户偏好、任务状态、重要事实
3. 保存为 JSON + 向量索引
4. 每次新请求先检索相关记忆
5. 对候选记忆做过滤、排序、压缩
6. 注入系统 prompt 或上下文消息
7. 用户可查看、修改、删除记忆

10.2 生产级架构

生产级系统应增加：

多租户 memory namespace；
memory ACL 权限控制；
memory versioning；
安全过滤与 prompt injection 检测；
记忆召回日志；
记忆使用可解释性；
离线 memory consolidation；
自动评估集和回归测试；
敏感信息最小化存储。

10.3 推荐上下文模板

[System Rules]
你是一个可靠的 AI-Agent，必须遵守安全、隐私和任务边界。

[Task State]
当前任务：{task_goal}
已完成：{completed_steps}
待完成：{pending_steps}
关键约束：{constraints}

[Relevant Long-term Memories]
{selected_memories_with_source_time_confidence}

[Recent Conversation Summary]
{short_term_summary}

[Retrieved Evidence]
{retrieved_docs_or_tool_results}

[Available Tools]
{selected_tool_schemas}

[User Request]
{current_user_input}

11. 总结

AI-Agent 具备长期记忆能力，靠的不是模型永久记住一切，而是外部记忆系统与上下文工程的协同。

可以用一句话概括：

长期记忆负责“保存过去”；
记忆机制负责“管理过去”；
上下文工程负责“让当前模型调用正确使用过去”。

更完整地说：

AI-Agent = LLM 推理能力
         + 工具调用能力
         + 状态与长期记忆
         + 上下文工程
         + 安全治理与评估闭环

长期记忆让 Agent 具备连续性和个性化；记忆机制让 Agent 能筛选、检索和更新历史；上下文工程让 Agent 在每一步都获得最相关、最可靠、最少噪声的信息。三者共同决定了 Agent 能否从“一次性问答工具”升级为“可持续协作的智能体”。

参考资料

[1] LangChain Docs. Memory overview. https://docs.langchain.com/oss/python/concepts/memory
[2] LangChain Docs. Long-term memory. https://docs.langchain.com/oss/python/langchain/long-term-memory
[3] OpenAI Cookbook. Context Engineering for Personalization - State Management with Long-Term Memory Notes using OpenAI Agents SDK. https://developers.openai.com/cookbook/examples/agents_sdk/context_personalization
[4] LangChain Blog. Context Engineering. https://www.langchain.com/blog/context-engineering-for-agents
[5] OpenAI Cookbook. Short-Term Memory Management with Sessions. https://developers.openai.com/cookbook/examples/agents_sdk/session_memory
[6] OpenAI Developers. Building agents. https://developers.openai.com/tracks/building-agents
[7] Park et al. Generative Agents: Interactive Simulacra of Human Behavior. https://arxiv.org/abs/2304.03442
[8] Packer et al. MemGPT: Towards LLMs as Operating Systems. https://arxiv.org/abs/2310.08560
[9] Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. https://arxiv.org/abs/2210.03629
[10] Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools. https://arxiv.org/abs/2302.04761
[11] Kang et al. Memory OS of AI Agent. https://arxiv.org/abs/2506.06326
[12] Zhang et al. Beyond Similarity: Trustworthy Memory Search for Personal AI Agents. https://arxiv.org/abs/2606.06054
[13] Yu et al. Agentic Memory: Learning Unified Long-Term and Short-Term Memory Management for Large Language Model Agents. https://arxiv.org/abs/2601.01885
[14] Xu et al. A-MEM: Agentic Memory for LLM Agents. https://arxiv.org/abs/2502.12110

龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

大模型安全实战】智能体安全的攻防二元性：同一种能力，为什么既是防线也是攻击面？（第4期）

龙虾开发者社区

SparkSQL 之 Hive On Spark 原理分析

龙虾开发者社区

RL训练Agentic模型实现并行多轮上下文检索：匹配前沿模型且快10倍

基于RL的Agentic检索模型正在成为AI Agent效率革命的关键驱动力。并行化：从串行单次调用转向多轮高并行调用自编辑：模型在检索过程中主动裁剪不相关信息迭代优化：检索器与Agent在RL训练中双向迭代当Agentic检索的速度提升10倍以上、成本大幅下降，AI系统将能在数秒内完成以往需要数分钟的复杂信息收集——这是Agent从“对话助手”走向“行动执行者”的关键一步。参考文献：, ACL

龙虾开发者社区

所有评论(0)

查看更多评论

code_pgf

@m0_60827485

已为社区贡献14条内容

AI-Agent 长期记忆、记忆机制与上下文工程详解

code_pgf

摘要

1. 基本概念界定

1.1 什么是 AI-Agent 的“长期记忆能力”？

1.2 什么是 AI-Agent 的记忆机制？

1.3 什么是上下文工程？

2. AI-Agent 如何具备长期记忆能力？

2.1 长期记忆能力的核心问题

2.2 长期记忆系统的基本架构

2.3 长期记忆的写入流程

2.4 长期记忆的检索流程

2.5 长期记忆的注入流程

2.6 长期记忆的更新与遗忘

2.7 长期记忆能力的工程模式

模式一：结构化用户画像

模式二：向量化语义记忆

模式三：事件流 + 反思总结

模式四：分层记忆 / Memory OS

模式五：记忆操作工具化

3. AI-Agent 中记忆机制的原理与作用

3.1 记忆机制的本质

3.2 记忆类型划分

3.3 记忆机制的运行闭环

3.4 记忆机制的主要作用

作用一：保持对话连续性

作用二：实现个性化

作用三：支撑长期任务

作用四：提高规划质量

作用五：降低上下文成本

作用六：支持经验学习

作用七：支持多 Agent 协作

3.5 记忆机制的风险

4. AI-Agent 上下文工程的原理

4.1 上下文工程解决什么问题？

4.2 上下文工程与提示词工程的区别

4.3 上下文的组成

4.4 上下文工程四类策略

4.4.1 Write：写入上下文或外部状态

4.4.2 Select：选择相关上下文

4.4.3 Compress：压缩上下文

4.4.4 Isolate：隔离上下文

4.5 上下文组装流程

4.6 上下文工程的设计原则

原则一：最小充分上下文

原则二：高优先级信息显式化

原则三：事实与偏好分离

原则四：保留来源与时间

原则五：压缩但不失真

原则六：上下文可观测

5. 长期记忆、记忆机制、上下文工程三者关系

6. 典型技术实现方案

6.1 MemoryItem 数据结构

6.2 写入伪代码

6.3 检索伪代码

6.4 上下文组装伪代码

7. 评价指标

8. 常见错误做法与改进建议

错误一：把完整历史聊天全部塞入上下文

错误二：只用向量相似度检索长期记忆

错误三：只存事实，不存来源和时间

错误四：没有删除和更新机制

错误五：把工具结果直接当长期事实

9. 示例：一个具备长期记忆的学习型 AI-Agent

第 1 次交互

第 2 次交互

第 3 次交互

第 4 次交互

10. 工程落地建议

10.1 最小可用架构

10.2 生产级架构

10.3 推荐上下文模板

11. 总结

参考资料

所有评论(0)

温馨提示：您尚未绑定手机号

code_pgf