Agent Memory 与 Context Engineering:从任务状态到长期记忆治理
本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 5 的配套学习笔记。 核心结论:Memory 不是“把聊天记录放进向量库”。生产级记忆必须有写入策略、来源、作用域、时间、冲突、权限、删除和效果证据;Context Engineering 则负责在每一步选择最小、可信、及时且足够的信息。
0. 学习目标与边界
学完本文后,你应该能够:
- 区分 Conversation History、AgentState、Checkpoint、Memory、RAG 与 Context;
- 解释 working、episodic、semantic、procedural、profile、summary 与 graph memory;
- 设计 Memory Record 的来源、双时间、置信度、敏感级别和作用域;
- 建立
observe -> propose -> policy -> commit -> index -> retrieve -> use -> feedback -> delete生命周期; - 决定什么该写、什么时候写、写到哪里、何时过期和如何撤回;
- 处理同一事实的新增、更新、冲突、失效、重复和来源分歧;
- 设计带 ACL、时间、新鲜度、相关性和多样性的记忆检索;
- 在 token 预算内组合指令、状态、事实、证据、历史与记忆;
- 用任务成功、反事实消融、检索和安全指标评估记忆;
- 为
OrderFlow-Agent实现短期、中期和长期三层记忆。
本文不把不同厂商名词强行视为同一实现。OpenAI Sessions/compaction、Anthropic context engineering、Google ADK sessions、AWS AgentCore Memory、Microsoft AutoGen Memory、LangGraph Store、Mem0、Letta 与 Graphiti 解决的问题部分重叠,但数据模型、控制权和一致性边界不同。[S1] [S2] [S3]
1. 先分清六个概念
| 概念 | 核心问题 | 生命周期 | 真相属性 |
|---|---|---|---|
| Conversation History | 用户和助手说过什么 | thread/session | 原始交互记录 |
| AgentState | 本次任务做到哪里 | run | 流程恢复真相 |
| Checkpoint | 如何从故障/暂停恢复 | run/version | 状态快照与进度 |
| Memory | 未来任务值得复用什么 | 跨 run | 经过治理的经验/偏好/事实 |
| RAG | 当前问题需要哪些外部证据 | query/request | 外部来源候选证据 |
| Context | 本次模型调用最终看到什么 | model call | 临时组装包 |
1.1 一条信息的不同归宿
用户说:
订单 ORD-A1B2C3D4 三天没发货,我以后都希望优先短信通知。拆分后:
Conversation History 保存原始话语与时间
AgentState order_id=ORD-A1B2C3D4, intent=refund_or_logistics
Business Fact 是否三天未发货必须查询订单/物流系统验证
Long-term Profile Memory notification_preference=sms(需确认、作用域和可删除)
Context 当前节点只加载必要字段,不一定加载整段原话1.2 三个常见错误
聊天记录 == 记忆 错:原始历史未经筛选、冲突与隐私治理向量库 == 记忆系统 错:它只是索引/召回的一种实现上下文窗口变大 == 不需记忆 错:成本、注意力、权限与新鲜度仍需管理“Lost in the Middle” 显示长上下文的信息位置会影响模型使用效果;Anthropic 也把 Context 视为有限注意力预算,强调选择最小高信号 token 集。[P1] [S2]
2. Memory 分类:按用途,不按存储产品
2.1 Working Memory
当前任务正在使用的结构化工作集:
目标槽位最新工具事实引用待验证假设已完成步骤待执行动作预算通常属于 AgentState,随 Run 结束而归档,不自动成为长期记忆。
2.2 Episodic Memory
过去发生过的具体事件:
2026-07-10 用户因订单 X 的物流延误联系过客服,最终转人工处理。需要事件时间、来源、参与者、结果和可见范围。Episodic Memory 适合从相似历史中学习,不适合直接当稳定业务规则。
2.3 Semantic Memory
相对稳定的事实或概念:
用户偏好短信通知商家 A 属于跨境业务“妥投”表示物流已签收必须标记来源、确认方式、有效时间和置信度。
2.4 Procedural Memory
“怎样做”的方法:
处理退款时先查订单和物流,再查生效规则,最后验证动作结果。它更接近 Prompt、Policy、Workflow 或 Skill。不要把未经审核的单次成功轨迹直接提升为全局流程。
2.5 Profile / Entity Memory
围绕用户、团队、项目或订单实体维护当前画像:
{ "entity": "user:123", "notification_preference": "sms", "language": "zh-CN", "preferred_contact_hours": "09:00-18:00 Asia/Shanghai"}Profile 便于读取当前状态,但字段更新需要冲突和并发控制。
2.6 Summary Memory
对长对话或长任务进行有损压缩。Summary 应保留:
已确认事实未决问题关键决定及证据引用承诺与截止时间不确定项源消息范围摘要版本摘要不是原始证据,应能回溯到消息/事件。
2.7 Vector / Graph Memory
它们描述索引和关系组织方式,不是独立认知类型:
Vector:语义近邻召回Graph:实体、事件、事实、时间与关系遍历同一 Episodic Memory 可以同时有关系表、向量索引和图投影。
Generative Agents 以 memory stream、reflection 与 planning 组织长期行为;MemGPT 把上下文管理类比为操作系统的分层内存。[P2] [P3] 这些是架构启发,不意味着业务系统应复制拟人化名词。
3. 生产架构:Write Path、Read Path 与 Governance Plane
Governance Plane Policy / Consent / Retention / ACL / Delete / Audit / Eval ↙ ↘Write Path Read PathEvents/Messages Current Task -> Extract Candidate -> Query Intent -> Normalize -> Namespace/ACL Filter -> Validate Source -> Hybrid Retrieve -> Memory Policy -> Rerank/Deduplicate -> Resolve Duplicate/Conflict -> Freshness/Trust -> Commit Canonical Record -> Context Budget -> Update Indexes -> Context Package -> Audit -> Usage Feedback3.1 Canonical Store 与索引分离
Canonical Memory Store 保存完整记录、版本、来源、时间、ACL、删除状态
Vector / Search / Graph Index 可重建的读取投影
Context Cache 短期加速结果,带 TTL 与版本向量库不应是唯一不可恢复的数据副本。索引删除成功也不证明备份、缓存和派生索引已经删除。
3.2 控制权
| 决策 | 推荐控制者 |
|---|---|
| 是否提出记忆候选 | 模型/规则均可 |
| 是否允许写入 | Memory Policy Engine |
| 写入哪个作用域 | 可信身份与业务配置 |
| 是否覆盖旧事实 | Conflict Resolver + CAS |
| 当前调用读哪些记忆 | Context Builder |
| 是否向用户展示/删除 | 产品与隐私控制面 |
模型可以提出 MemoryMutationProposal,不能直接写 Canonical Store。
4. Memory Record:来源和时间是一等字段
4.1 基础 Schema
from datetime import datetimefrom typing import Literalfrom pydantic import BaseModel, Field
class MemoryRecord(BaseModel): memory_id: str schema_version: Literal["2"] = "2" tenant_id: str namespace: str subject_ref: str kind: Literal[ "episodic", "semantic", "profile", "procedural", "summary", ] key: str | None content: str structured_value: dict | None source_refs: list[str] source_type: Literal[ "user_assertion", "verified_tool_fact", "human_review", "derived_summary", "system_policy", ] confidence: float = Field(ge=0, le=1) sensitivity: Literal["public", "internal", "confidential", "restricted"] valid_from: datetime | None valid_to: datetime | None recorded_at: datetime expires_at: datetime | None consent_ref: str | None status: Literal["active", "superseded", "invalidated", "deleted"] version: int4.2 双时间
Valid Time 这条事实在现实世界何时成立?
Transaction/Recorded Time 系统何时知道并记录它?示例:
2026-07-01 用户偏好 Email 生效2026-07-05 系统才收到并记录2026-07-10 用户改为 SMS只存 updated_at 会失去“当时我们知道什么”和“事实何时有效”的区别。
Zep/Graphiti 的公开论文与实现强调情节、实体、事实和时间关系,可作为双时间与事实失效设计的参考。[P4] [S4]
4.3 Provenance
来源至少能回答:
谁说的?来自哪个消息/工具/文档?是否经过验证?用哪个提取器/Prompt/模型生成?基于哪些源范围做摘要?后来被什么记录覆盖或撤回?没有 provenance 的记忆无法审计,也无法在源数据删除时做级联处理。
5. Scope 与 Namespace:先隔离,再检索
5.1 常见作用域
tenant/{tenant_id}tenant/{tenant_id}/user/{user_id}tenant/{tenant_id}/team/{team_id}tenant/{tenant_id}/project/{project_id}tenant/{tenant_id}/agent/{agent_id}tenant/{tenant_id}/thread/{thread_id}5.2 读取原则
Identity -> Allowed Namespaces -> Memory Type -> Time -> Retrieval权限过滤必须在候选内容进入模型上下文前执行。不能全局向量召回后再让模型“不要泄露”。
5.3 共享记忆
团队/多 Agent 共享记忆需明确:
谁可写谁可读谁可批准冲突如何处理哪些 Agent 产出只能是候选是否允许从私有作用域提升到共享作用域默认禁止自动把用户私有偏好或对话提升到团队共享空间。
5.4 Key 设计
Profile Memory 可用稳定 key:
profile.notification_preferenceprofile.languageprofile.timezoneEpisodic Memory 通常使用 append-only ID,不应以同一个 key 粗暴覆盖所有历史事件。
6. Write Path:记忆写入是一项高风险动作
6.1 完整写路径
Observe Event -> Candidate Extraction -> Normalize -> Sensitivity Detection -> Consent / Retention Check -> Source Validation -> Duplicate Retrieval -> Conflict Resolution -> Mutation Proposal -> Policy Decision -> Transactional Commit -> Index Update -> Audit / Eval Sample6.2 Mutation Proposal
class MemoryMutationProposal(BaseModel): operation: Literal["add", "update", "invalidate", "delete", "no_op"] namespace: str kind: str key: str | None candidate_content: str | None source_refs: list[str] matched_memory_ids: list[str] conflict_type: str | None confidence: float reason_code: str模型输出 Proposal 后,Policy Engine 决定是否提交。
6.3 Memory Write Policy
| 信息 | 默认决策 | 原因 |
|---|---|---|
| 用户明确稳定偏好 | 可写,需作用域/删除能力 | 未来任务可复用 |
| 当前订单状态 | 不写长期记忆 | 应从业务真相源读取 |
| 一次工具返回 | 写 Trace/引用 | 可能陈旧或敏感 |
| 未验证用户陈述 | 可存为 assertion,低置信 | 不能升级为事实 |
| 密码、token、支付凭据 | 拒绝 | 高风险 Secret |
| 医疗/金融敏感推断 | 默认拒绝或严格同意 | 高风险画像 |
| 已确认的人工决策 | 可写 Episode | 需来源和保留期 |
| 单次模型反思 | 不直接升为程序性记忆 | 可能错误/过拟合 |
6.4 Hot Path 与 Background Write
Hot Path 用户当前回复依赖立即写入 优点:一致性直观 缺点:增加延迟,失败影响主链路
Background 事件进入队列,异步提取/去重/提交 优点:可批处理、可用更强模型 缺点:最终一致、需要 watermark 与重放LangGraph 公开文档也区分在主路径或后台写入长期记忆,并区分 thread-scoped checkpointer 与 cross-thread store。[S5]
6.5 Background Watermark
last_event_seenlast_event_committedlast_index_updated三个 Watermark 分离,才能区分事件已读、Canonical Record 已提交、索引已可查询。
7. 去重、更新与冲突
7.1 五种关系
NEW 没有相关旧记录DUPLICATE 语义相同,无需新增REFINEMENT 新记录更精确,更新/合并SUPERSEDES 新事实替代旧事实CONFLICTS 来源或时间无法自动判定7.2 冲突示例
M1: 用户偏好 Email,来源=user assertion,valid_from=07-01M2: 用户偏好 SMS,来源=user assertion,valid_from=07-10如果时间明确,M2 可 supersede M1;如果两个来源同时声称当前偏好且时间不明,应保留冲突并追问,不能用 embedding 相似度决定真相。
7.3 来源优先级不是绝对真理
可配置:
human verified> authenticated user explicit statement> verified business tool> derived summary> model inference但工具事实与用户偏好属于不同字段域,不能用统一排行榜粗暴覆盖。
7.4 CAS 更新
UPDATE memory_recordsSET structured_value = :value, source_refs = :sources, version = version + 1, recorded_at = now()WHERE memory_id = :id AND version = :expected_version;并发写冲突需要重新读取并解析,不做 last-write-wins。
7.5 Add-only 与显式 Update/Delete
Add-only 便于保留历史和异步写入,但 Profile 当前值需要读取时聚合;显式 Update/Delete 读取简单,但更依赖正确冲突判断。Mem0 等公开实现与文档展示了不同版本的提取/更新策略,工程选型要看数据语义和删除要求,而不是只看 API 名称。[S6]
7.6 Canonical Commit 与 Index Saga
PostgreSQL、向量库、搜索引擎和图数据库通常不能参加同一个 ACID 事务。正确目标不是伪造“全局原子写”,而是让不一致可检测、可修复:
Canonical Transaction 1. insert/update memory_record 2. append memory_outbox event 3. commit
Index Worker 4. consume outbox idempotently 5. update vector/search/graph projections 6. record projection watermark 7. mark event processed最小表:
CREATE TABLE memory_records ( memory_id text NOT NULL, tenant_id text NOT NULL, namespace text NOT NULL, kind text NOT NULL, content text NOT NULL, source_refs jsonb NOT NULL, valid_from timestamptz, valid_to timestamptz, status text NOT NULL, version integer NOT NULL, recorded_at timestamptz NOT NULL, PRIMARY KEY (memory_id, version));
CREATE TABLE memory_outbox ( event_id text PRIMARY KEY, memory_id text NOT NULL, memory_version integer NOT NULL, operation text NOT NULL, payload jsonb NOT NULL, created_at timestamptz NOT NULL, processed_at timestamptz);Index Worker 使用 event_id 去重,投影记录携带 memory_id + version + content_hash。Read Path 发现索引版本落后时,可丢弃候选、回查 Canonical Store,或在严格任务中降级为不使用该记忆。
7.7 Repair Worker
扫描未处理 Outbox比较 Canonical 与 Index version/hash重建缺失向量或图边移除已 tombstone 的投影刷新失效 Cache记录 repair reason 与结果关键指标:
memory_outbox_lag_secondsmemory_projection_version_lagmemory_index_repair_total{reason,status}memory_canonical_index_mismatch_total只有 Canonical Commit 成功时,写 API 才能返回“记录已持久化”;只有目标 Projection 到达对应 Watermark,才能声明“已可被该检索路径读取”。
8. Read Path:相关不等于应该进入上下文
8.1 检索管线
Task + Current State -> Query Intent -> Namespace/ACL Filter -> Memory Type Filter -> Valid-time/Expiry Filter -> Candidate Retrieval -> Trust/Freshness Rerank -> Deduplicate/Conflict Group -> Diversity Selection -> Context Budget Allocation -> Context Items + Provenance8.2 Score 不是只有相似度
score = semantic_relevance + task_relevance + source_trust + freshness + explicit_user_priority - conflict_penalty - staleness_penalty - redundancy_penalty - privacy_risk权重必须通过任务数据集校准。
8.3 检索输出
class RetrievedMemory(BaseModel): memory_id: str version: int kind: str content: str source_refs: list[str] valid_from: datetime | None confidence: float retrieval_score: float retrieval_reasons: list[str] conflict_group: str | None8.4 负向与缺失证据
检索系统还要表达:
没有找到已确认偏好找到两条相互冲突的当前偏好只有低置信推断,不应自动使用记忆已过期,需要重新确认“没召回”不等于“不存在”;“召回第一名”不等于“事实为真”。
9. Context Engineering:分配注意力预算
9.1 Context 组成
System / Policy InstructionsCurrent GoalTyped AgentStateVerified Tool FactsRetrieved Business EvidenceRelevant Conversation SliceSelected MemoryAvailable Tool SchemasOutput ContractReserved Generation Budget9.2 Token Budget
class ContextBudget(BaseModel): total_tokens: int reserved_output_tokens: int instructions_tokens: int state_tokens: int tool_schema_tokens: int evidence_tokens: int conversation_tokens: int memory_tokens: int预算不是固定百分比。退款决策可能提高规则证据预算;闲聊可能不加载任何业务工具和 Memory。
9.3 Context Item
class ContextItem(BaseModel): item_id: str kind: str content: str trust: Literal["instruction", "verified", "untrusted"] source_refs: list[str] token_estimate: int priority: int expires_at: datetime | None明确 trust,避免文档、记忆与工具文本被模型误当高优先级指令。
9.4 Compaction
长 Run 中,compaction 用于保持当前任务连续性;跨 Run Memory 用于复用未来有价值的信息。OpenAI Cookbook 明确区分这两种角色。[S1]
Compaction 前后必须保留:
任务目标已验证事实及引用关键决策未完成步骤外部操作 ID用户确认范围预算与错误状态原消息范围引用9.5 Tool Result Clearing
工具全文进入上下文后,可以在事实抽取和受控存档后替换为:
结构化事实+ content hash+ source reference+ truncated/omitted indicator但不能在外部写操作结果尚未验证时清掉 operation ID。
9.6 Scratchpad
Scratchpad 是临时工作区,不自动持久化为长期记忆。尤其不要保存隐藏推理文本;保存可验证的中间结构、假设、证据引用和下一步即可。
10. Session、Checkpoint 与 Long-term Memory
10.1 Thread-scoped Session
OpenAI Agents SDK Sessions、Google ADK Sessions、AutoGen Memory 等公开 API 都提供一定程度的历史/状态注入。[S1] [S3]
需要核对:
数据持久化位置session/thread key 语义多租户隔离并发写入删除/保留消息裁剪/摘要是否自动注入可否导出与迁移10.2 Checkpoint
Checkpoint 保存 Runtime 恢复所需状态:
current nodecompleted stepspending actiontool operation IDsbudgetpinned versions它不等同于未来任务的“有用经验”。
10.3 Long-term Memory
跨 Thread 使用,必须显式 namespace 与读取策略。一个常见错误是用 user_id 作为唯一 namespace,导致:
不同租户同名用户冲突团队/项目作用域丢失删除无法定位派生记录测试环境污染生产画像10.4 Profile 与 Collection
Profile 当前值紧凑、读取简单、更新有冲突
Collection 多条记忆保留历史、检索灵活、需要聚合稳定偏好适合 Profile;事件、案例和经验适合 Collection。混合方案通常更实用。
11. 安全、隐私与删除证明
11.1 威胁
Memory PoisoningPersistent Prompt InjectionCross-tenant RetrievalSensitive InferenceSecret MemorizationUnauthorized Promotion to Shared ScopeDeletion FailureStale Policy/Preference11.2 写入前
PII/Secret classificationconsent and purpose checknamespace authorizationsource trustinjection markersretention policyminimum necessary content11.3 读取前
authenticated identitytenant + resource ACLpurpose limitationsensitivity ceilingvalid time + expiryuntrusted-content labeling11.4 删除生命周期
Delete Request -> Resolve subject/source scope -> Tombstone canonical records -> Remove vector/search/graph indexes -> Invalidate caches/context snapshots -> Propagate to derived summaries -> Schedule backup expiry where applicable -> Emit deletion evidence -> Verify no active read path returns record11.5 Delete Receipt
{ "deletion_id": "del_01J...", "subject_ref": "tenant/a/user/123", "requested_at": "2026-07-15T10:00:00Z", "canonical_records": 12, "indexes_removed": ["vector", "search", "graph"], "derived_records_invalidated": 3, "cache_namespaces_invalidated": 2, "verification_status": "passed", "backup_retention_deadline": "2026-08-14T10:00:00Z"}OWASP Agent Security 与 NIST AI RMF 提供了记忆投毒、数据治理、审计和生命周期风险的通用框架。[S7] 删除实现还需遵循具体法律、合同和组织政策。
12. OrderFlow-Agent 三层记忆
12.1 短期:Run State
{ "run_id": "run_01J...", "intent": "refund_request", "order_id": "ORD-A1B2C3D4", "verified_fact_refs": [ "order://ORD-A1B2C3D4?version=8", "logistics://ORD-A1B2C3D4?version=3" ], "policy_refs": ["policy://refund/v18#R001"], "pending_action": "refund:create", "status": "awaiting_confirmation"}随 Run 恢复和归档,不作为用户长期画像。
12.2 中期:订单/工单 Episode
{ "kind": "episodic", "subject_ref": "order:ORD-A1B2C3D4", "content": "用户因超过72小时未发货申请退款,规则R001命中,确认后退款完成", "source_refs": [ "run://run_01J...", "refund://RF-20260715-88" ], "valid_from": "2026-07-15T09:20:00Z", "expires_at": "2026-10-15T00:00:00Z"}用于后续同一订单/工单连续处理,保留期依据业务要求。
12.3 长期:明确偏好
{ "kind": "profile", "namespace": "tenant/shop-a/user/123", "key": "notification.preference", "structured_value": { "channel": "sms", "quiet_hours": "22:00-08:00 Asia/Shanghai" }, "source_type": "user_assertion", "consent_ref": "consent://memory/2026-07-15/7", "confidence": 1.0, "status": "active"}12.4 明确不写
- 订单最新状态:每次从订单服务查;
- 退款规则全文:属于版本化规则库/RAG;
- 支付账号与身份证明:默认不写;
- “用户容易投诉”这类敏感推断:不写;
- 模型对用户人格的猜测:不写;
- 未验证工具错误文本:只进安全日志/Trace。
13. 一次完整 Write/Read 闭环
13.1 写入偏好
User: 以后物流更新请优先短信通知-> Extract candidate: notification.preference=sms-> Verify explicit user statement-> Sensitivity: low, purpose: service personalization-> Consent policy: allowed + visible/editable-> Retrieve current profile value-> Conflict: email -> sms, explicit newer statement-> CAS update canonical profile-> Update indexes/cache-> Show confirmation and memory control link13.2 下次读取
New logistics task-> Identity -> tenant/user namespace-> Query relevant profile keys-> Check valid/expiry/consent-> Context Builder selects sms preference-> Tool policy verifies SMS channel is available-> Action still requires normal authorization记忆偏好不能绕过用户联系方式验证、消息权限和静默时段策略。
13.3 用户删除
User: 忘掉我的通知偏好-> Resolve profile key and derived summaries-> Tombstone canonical value-> Invalidate cache/index-> Verify retrieval returns no active preference-> Return delete receipt14. 大厂与开源方案对照
| 方案 | 公开抽象 | 适合借鉴 | 需要重点核对 |
|---|---|---|---|
| OpenAI Agents SDK Sessions | Session 自动取回/追加历史 | thread history adapter | 存储、并发、保留 |
| OpenAI Cookbook compaction/memory | 当前 Run 压缩 vs 未来 Run 经验 | 两种生命周期分离 | 摘要损失与评估 |
| Anthropic context engineering | compaction、tool clearing、note-taking、sub-agent | 注意力预算与长任务策略 | 应用自行实现治理 |
| Google ADK Sessions | session、state、events、artifacts | 状态与事件边界 | 持久化实现/作用域 |
| AWS AgentCore Memory | short/long-term memory 服务抽象 | 托管写读流程 | 数据驻留、可迁移、删除 |
| Microsoft AutoGen Memory | memory protocol/context update | 可插拔 memory component | 并发与业务事实边界 |
| LangGraph | checkpointer + cross-thread store | State/Memory 分离 | Schema 与策略自行建模 |
| Mem0 | 提取、更新/追加、检索与图扩展 | 快速实验与 Memory API | 算法版本、作用域、删除 |
| Letta/MemGPT | context hierarchy、memory blocks、archival | 分层上下文管理 | 常驻块成本与编辑权限 |
| Zep/Graphiti | episode/entity/fact、temporal graph | 时间事实与关系检索 | 一致性、索引和运维成本 |
官方入口见 [S1] 到 [S6],以及 [S8]。表格只对照公开行为,不推断内部系统。
15. 前沿论文思想与工程落点
| 工作 | 思想 | 工程落点 | 局限提醒 |
|---|---|---|---|
| Generative Agents [P2] | memory stream、reflection、planning | Episode + higher-level synthesis | 模拟社会不等于业务可靠性 |
| MemGPT [P3] | 类 OS 分层管理有限上下文 | working/archival hierarchy | 类比不是事务与权限实现 |
| MemoryBank [P5] | 长期对话记忆与遗忘/更新 | retention 与用户画像实验 | 情感对话结果不可直接外推 |
| Reflexion [P6] | verbal feedback 进入 episodic buffer | 失败经验候选 | 自我反馈可能固化错误 |
| Mem0 [P7] | 可扩展长期记忆提取与检索 | 写读管线和评估 | 论文指标需业务复验 |
| Zep [P4] | 双时间知识图 | valid/recorded time、失效边 | 图成本与一致性复杂 |
| A-MEM [P8] | agentic note linking/evolution | 动态关联与组织实验 | 自动改写需 provenance |
| LoCoMo [P9] | 超长多会话对话评测 | 长期一致性数据集 | 合成对话与真实业务差异 |
| LongMemEval [P10] | 信息提取、时间推理、知识更新、拒答 | 分能力 Memory Eval | 单一 QA 指标不够 |
| LongMemEval-V2 [P11] | 从记住事实到经验型协作 | 程序性经验与长期任务 | 2026 预印本需持续核对 |
论文中的“memory”常包含不同数据、任务和读取协议。引用实验数字时必须同时说明模型、数据集、baseline、指标与作者报告边界;本文不把某论文增益写成通用生产收益。
16. Memory Evaluation:证明它有用,而不是证明它存在
16.1 写入评估
Candidate Extraction Precision/RecallWrite Decision AccuracySensitive Write Block RateDuplicate RateConflict Detection RecallMutation AccuracyProvenance CompletenessWrite Latency / Cost16.2 检索评估
Memory Recall@KMemory Precision@KRequired Memory RecallStale Memory RateConflict Surfacing RateUnauthorized Retrieval RateSource Citation AccuracyTokens per Useful Memory16.3 端到端评估
Task Success with MemoryTask Success without MemoryWrong Personalization RateClarification ReductionRepeated Work ReductionLatency / Cost DeltaUser Correction RateDelete Compliance16.4 反事实消融
同一测试 Case 至少跑:
A: no memoryB: oracle memoryC: production retrievalD: stale/conflicting memory injectedE: unauthorized memory must be blocked这样才能分清:
系统是否需要记忆写入是否正确检索是否正确模型是否正确使用错误记忆是否会伤害任务16.5 Case Schema
{ "case_id": "M-PREF-013", "history_events": [ "event://user-preference-email", "event://user-preference-sms-later" ], "current_task": "通知物流异常", "expected_active_memory": { "key": "notification.preference", "value": "sms" }, "expected_invalidated_memory_ids": ["mem_email_v1"], "forbidden_namespaces": ["tenant/other/user/123"], "expected_action": "send_sms_after_policy_check"}LongMemEval 与 LoCoMo 为长期对话信息提取、时间推理和知识更新提供了公开评测思路。[P9] [P10]
16.6 线上反馈不能直接回写 Memory
线上信号可能包括:
用户更正用户删除模型忽略/采用某条记忆工具动作成功或失败人工审核投诉与满意度这些信号先成为带来源的 MemoryFeedbackEvent:
class MemoryFeedbackEvent(BaseModel): event_id: str memory_id: str memory_version: int run_id: str feedback_type: Literal[ "used", "ignored", "corrected", "confirmed", "harmful", "deleted", ] source: Literal["user", "human_reviewer", "verifier", "system_metric"] evidence_refs: list[str] occurred_at: datetime后续离线作业可用它调整 retention、rerank 或写入策略;不能因为模型采用过某条 Memory 就自动提高可信度,也不能因为一次任务失败就自动删除相关记忆。
16.7 运行指标与 SLO
Write Accepted / Rejected / Deferred RateCanonical Commit LatencyIndex Freshness LagRetrieval p50/p95Context Memory Token ShareStale/Conflict/Unauthorized Retrieval RateMemory-caused Task Failure RateCorrection and Deletion Completion TimeCost per Memory-assisted Successful Run所有指标按 tenant、memory_kind、write_policy_version、retriever_version 切分,但不能把高基数 user_id 直接作为公共 Metric Label。具体样本通过受控 run_id/memory_id 引用进入 Trace 和评估系统。
17. 测试与故障注入
17.1 Write Policy
明确偏好否定句临时偏好第三方信息敏感推断Secret间接 Prompt Injection用户撤回同一字段并发更新17.2 Conflict/Temporal
新事实晚记录但早生效两个来源同一时间冲突摘要遗漏否定词旧事实过期但索引仍命中Add 成功、Index 失败Index 成功、Canonical Transaction 回滚17.3 Retrieval/Security
跨租户近邻更相似namespace filter 缺失低置信记忆排名过高同义重复占满 top-k冲突只返回一侧恶意记忆试图改变系统指令17.4 Delete
Canonical tombstone 后 vector cache 仍返回Graph edge 未级联失效Derived summary 仍含被删事实并发 Run 持有旧 Context Package备份保留期未披露18. Failure Taxonomy
| 编号 | 失败 | 示例 | 首要修复层 |
|---|---|---|---|
| M01 | Wrong Candidate | 把当前订单状态当长期偏好 | Extractor |
| M02 | Unsafe Write | 保存 token/敏感推断 | Policy |
| M03 | Scope Leak | 写入全局而非用户 namespace | Identity/Policy |
| M04 | Duplicate | 同义记忆无限增长 | Dedup |
| M05 | Wrong Update | 新信息错误覆盖旧事实 | Conflict Resolver |
| M06 | Temporal Error | 使用已失效偏好 | Time Filter |
| M07 | Provenance Loss | 不知记忆来源 | Record Schema |
| M08 | Index Drift | Canonical 与向量索引不一致 | Index Pipeline |
| M09 | Retrieval Miss | 需要的记忆未召回 | Query/Retriever |
| M10 | Context Pollution | 无关记忆占满预算 | Context Builder |
| M11 | Instruction Confusion | 恶意记忆成为指令 | Trust Isolation |
| M12 | Wrong Use | 模型误用正确记忆 | Prompt/Verifier |
| M13 | Delete Failure | 派生摘要仍含被删内容 | Governance |
| M14 | No Benefit | 增加延迟但不提升任务 | Product/Eval |
19. 常见反模式
19.1 全量聊天记录向量化
问题:噪声、重复、隐私、注入、无来源与无删除语义。
19.2 每轮都总结并覆盖
问题:摘要漂移,否定、数字和未决事项逐轮丢失。
19.3 让模型自由调用 remember()
问题:模型同时成为候选生成、授权、冲突解决和提交者。
19.4 用相似度解决冲突
问题:相似度说明文本接近,不说明时间、来源或真值优先级。
19.5 把业务规则写进用户 Memory
问题:规则变化、权限与版本失控。业务规则应在版本化 Policy/RAG 中。
19.6 Context 越长越好
问题:成本、注意力、冲突和攻击面一起增大。
19.7 只测 Memory QA
问题:记住事实不等于安全地完成有工具和策略的任务。
19.8 删除就是向量库 delete
问题:Canonical Store、缓存、图、摘要、备份与在途 Context 仍可能存在。
20. 项目目录与实践任务
app/ memory/ records.py namespaces.py candidates.py write_policy.py conflict_resolver.py canonical_store.py indexer.py retriever.py reranker.py context_selector.py deletion.py audit.py context/ budget.py builder.py compaction.py trust.pytests/ memory/ write_policy/ conflicts/ temporal/ retrieval/ security/ deletion/ scenarios/data/ memory_eval.jsonldocs/ memory_architecture.md memory_write_policy.md retention_and_deletion.md实践顺序:
1. 先实现 Typed AgentState,不接长期记忆2. 建 MemoryRecord + Namespace + Provenance3. 用规则实现明确偏好写入4. 增加候选提取,但 Policy 仍确定性5. 建 Profile CAS 更新与 Episode append-only6. 接 Vector/Search Index,Canonical Store 为真相源7. 建 Context Budget 与 trust label8. 做冲突、过期和删除9. 跑 no-memory/oracle/production/stale 消融10. 再评估 Graph 或更复杂自动组织是否值得21. 达标检查清单
概念与架构
- 区分 History、State、Checkpoint、Memory、RAG、Context;
- Canonical Store 与可重建索引分离;
- Write/Read/Governance 三条路径独立;
- Profile、Episode、Procedure 的数据模型不同;
- 模型只能提出 Mutation Proposal。
数据与时间
- Memory 有 tenant、namespace、subject、version;
- 有 source refs、source type 与 confidence;
- valid time 与 recorded time 分离;
- 支持 duplicate/refinement/supersede/conflict;
- 并发更新使用 CAS。
安全与删除
- 写入前检查敏感性、同意、目的和保留期;
- 读取先做身份/namespace/ACL,再做语义检索;
- 不可信 Memory 不会变成系统指令;
- 用户可查看、更正和删除适用记忆;
- 删除覆盖 Canonical、Index、Cache、Graph 与 Derived Summary。
Context 与评估
- Context 有总预算与输出保留;
- Tool facts、Evidence、Memory 具有不同 trust label;
- Compaction 能回溯原始消息范围;
- 对比 no-memory/oracle/production/stale;
- 以任务收益、错误个性化、安全和成本共同验收。
22. 面试与架构评审问题
- AgentState 与 Long-term Memory 为什么必须分开?
- Vector DB 为什么不等于 Memory System?
- 怎样判断一条用户陈述可以写长期记忆?
- 为什么要同时记录 valid time 和 recorded time?
- Profile 与 Collection 如何选择?
- 相似度为什么不能解决事实冲突?
- Hot-path Write 与 Background Write 各有什么一致性问题?
- 如何证明删除真的覆盖派生索引和摘要?
- 如何防止跨租户向量召回?
- Compaction 与长期记忆有什么区别?
- 如何评估“记忆提升”不是因为多给了 token?
- 什么情况下应该关闭 Memory?
23. 参考资料与延伸阅读
以下资料用于核对公开行为和原始论文思想。产品文档会演进,真实接入需固定版本并验证数据治理;预印本结果需标明作者报告与实验条件。
厂商、框架与开源实现
[S1] OpenAI Session 与 Compaction
- OpenAI Agents SDK Sessions;
- OpenAI Cookbook Building Reliable Agents with Memory and Compaction。
[S2] Anthropic Context Engineering
- Effective context engineering for AI agents:compaction、structured note-taking、sub-agent 与 tool result clearing。
[S3] 云厂商与框架 Memory
[S4] Graphiti
[S5] LangGraph Memory
[S6] Mem0
[S7] 安全与风险治理
[S8] Letta 与 MemGPT
- Letta Context hierarchy;
- letta-ai/letta。
论文与 Benchmark
[P1] Lost in the Middle
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024。
[P2] Generative Agents
- Park et al., Generative Agents: Interactive Simulacra of Human Behavior, UIST 2023。
[P3] MemGPT
- Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023。
[P4] Zep / Graphiti
- Rasmussen et al., Zep: A Temporal Knowledge Graph Architecture for Agent Memory, 2025。
[P5] MemoryBank
- Zhong et al., MemoryBank: Enhancing Large Language Models with Long-Term Memory, AAAI 2024。
[P6] Reflexion
- Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023。
[P7] Mem0
- Chhikara et al., Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory, 2025。
[P8] A-MEM
- Xu et al., A-MEM: Agentic Memory for LLM Agents, 2025。
[P9] LoCoMo
- Maharana et al., Evaluating Very Long-Term Conversational Memory of LLM Agents, ACL 2024。
[P10] LongMemEval
- Wu et al., LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory, ICLR 2025。
[P11] LongMemEval-V2
24. 阶段总结
生产级 Agent Memory 的核心不是“记得更多”,而是“只在正确的边界内记住值得复用的内容”:
State 负责恢复当前任务;RAG 提供外部证据;Memory 保存未来值得复用的信息;Context Builder 决定这一次让模型看到什么。每条长期记忆都应回答:
谁的?从哪里来?何时有效?可信到什么程度?为什么允许保存?谁能读取?与旧信息是什么关系?何时过期?怎样更正和删除?是否真的提升任务结果?只有这些问题有结构化答案,Memory 才是可治理的系统能力,而不是把上下文污染延长到未来会话。