7249 字
36 分钟

Agent Memory 与 Context Engineering:从任务状态到长期记忆治理

本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 5 的配套学习笔记。 核心结论:Memory 不是“把聊天记录放进向量库”。生产级记忆必须有写入策略、来源、作用域、时间、冲突、权限、删除和效果证据;Context Engineering 则负责在每一步选择最小、可信、及时且足够的信息。


0. 学习目标与边界#

学完本文后,你应该能够:

  1. 区分 Conversation History、AgentState、Checkpoint、Memory、RAG 与 Context;
  2. 解释 working、episodic、semantic、procedural、profile、summary 与 graph memory;
  3. 设计 Memory Record 的来源、双时间、置信度、敏感级别和作用域;
  4. 建立 observe -> propose -> policy -> commit -> index -> retrieve -> use -> feedback -> delete 生命周期;
  5. 决定什么该写、什么时候写、写到哪里、何时过期和如何撤回;
  6. 处理同一事实的新增、更新、冲突、失效、重复和来源分歧;
  7. 设计带 ACL、时间、新鲜度、相关性和多样性的记忆检索;
  8. 在 token 预算内组合指令、状态、事实、证据、历史与记忆;
  9. 用任务成功、反事实消融、检索和安全指标评估记忆;
  10. 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 Path
Events/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 Feedback

3.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 datetime
from typing import Literal
from 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: int

4.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_preference
profile.language
profile.timezone

Episodic 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 Sample

6.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_seen
last_event_committed
last_index_updated

三个 Watermark 分离,才能区分事件已读、Canonical Record 已提交、索引已可查询。


7. 去重、更新与冲突#

7.1 五种关系#

NEW 没有相关旧记录
DUPLICATE 语义相同,无需新增
REFINEMENT 新记录更精确,更新/合并
SUPERSEDES 新事实替代旧事实
CONFLICTS 来源或时间无法自动判定

7.2 冲突示例#

M1: 用户偏好 Email,来源=user assertion,valid_from=07-01
M2: 用户偏好 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_records
SET 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_seconds
memory_projection_version_lag
memory_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 + Provenance

8.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 | None

8.4 负向与缺失证据#

检索系统还要表达:

没有找到已确认偏好
找到两条相互冲突的当前偏好
只有低置信推断,不应自动使用
记忆已过期,需要重新确认

“没召回”不等于“不存在”;“召回第一名”不等于“事实为真”。


9. Context Engineering:分配注意力预算#

9.1 Context 组成#

System / Policy Instructions
Current Goal
Typed AgentState
Verified Tool Facts
Retrieved Business Evidence
Relevant Conversation Slice
Selected Memory
Available Tool Schemas
Output Contract
Reserved Generation Budget

9.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 node
completed steps
pending action
tool operation IDs
budget
pinned versions

它不等同于未来任务的“有用经验”。

10.3 Long-term Memory#

跨 Thread 使用,必须显式 namespace 与读取策略。一个常见错误是用 user_id 作为唯一 namespace,导致:

不同租户同名用户冲突
团队/项目作用域丢失
删除无法定位派生记录
测试环境污染生产画像

10.4 Profile 与 Collection#

Profile
当前值紧凑、读取简单、更新有冲突
Collection
多条记忆保留历史、检索灵活、需要聚合

稳定偏好适合 Profile;事件、案例和经验适合 Collection。混合方案通常更实用。


11. 安全、隐私与删除证明#

11.1 威胁#

Memory Poisoning
Persistent Prompt Injection
Cross-tenant Retrieval
Sensitive Inference
Secret Memorization
Unauthorized Promotion to Shared Scope
Deletion Failure
Stale Policy/Preference

11.2 写入前#

PII/Secret classification
consent and purpose check
namespace authorization
source trust
injection markers
retention policy
minimum necessary content

11.3 读取前#

authenticated identity
tenant + resource ACL
purpose limitation
sensitivity ceiling
valid time + expiry
untrusted-content labeling

11.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 record

11.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 link

13.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 receipt

14. 大厂与开源方案对照#

方案公开抽象适合借鉴需要重点核对
OpenAI Agents SDK SessionsSession 自动取回/追加历史thread history adapter存储、并发、保留
OpenAI Cookbook compaction/memory当前 Run 压缩 vs 未来 Run 经验两种生命周期分离摘要损失与评估
Anthropic context engineeringcompaction、tool clearing、note-taking、sub-agent注意力预算与长任务策略应用自行实现治理
Google ADK Sessionssession、state、events、artifacts状态与事件边界持久化实现/作用域
AWS AgentCore Memoryshort/long-term memory 服务抽象托管写读流程数据驻留、可迁移、删除
Microsoft AutoGen Memorymemory protocol/context update可插拔 memory component并发与业务事实边界
LangGraphcheckpointer + cross-thread storeState/Memory 分离Schema 与策略自行建模
Mem0提取、更新/追加、检索与图扩展快速实验与 Memory API算法版本、作用域、删除
Letta/MemGPTcontext hierarchy、memory blocks、archival分层上下文管理常驻块成本与编辑权限
Zep/Graphitiepisode/entity/fact、temporal graph时间事实与关系检索一致性、索引和运维成本

官方入口见 [S1][S6],以及 [S8]。表格只对照公开行为,不推断内部系统。


15. 前沿论文思想与工程落点#

工作思想工程落点局限提醒
Generative Agents [P2]memory stream、reflection、planningEpisode + 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/Recall
Write Decision Accuracy
Sensitive Write Block Rate
Duplicate Rate
Conflict Detection Recall
Mutation Accuracy
Provenance Completeness
Write Latency / Cost

16.2 检索评估#

Memory Recall@K
Memory Precision@K
Required Memory Recall
Stale Memory Rate
Conflict Surfacing Rate
Unauthorized Retrieval Rate
Source Citation Accuracy
Tokens per Useful Memory

16.3 端到端评估#

Task Success with Memory
Task Success without Memory
Wrong Personalization Rate
Clarification Reduction
Repeated Work Reduction
Latency / Cost Delta
User Correction Rate
Delete Compliance

16.4 反事实消融#

同一测试 Case 至少跑:

A: no memory
B: oracle memory
C: production retrieval
D: stale/conflicting memory injected
E: 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 Rate
Canonical Commit Latency
Index Freshness Lag
Retrieval p50/p95
Context Memory Token Share
Stale/Conflict/Unauthorized Retrieval Rate
Memory-caused Task Failure Rate
Correction and Deletion Completion Time
Cost 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#

编号失败示例首要修复层
M01Wrong Candidate把当前订单状态当长期偏好Extractor
M02Unsafe Write保存 token/敏感推断Policy
M03Scope Leak写入全局而非用户 namespaceIdentity/Policy
M04Duplicate同义记忆无限增长Dedup
M05Wrong Update新信息错误覆盖旧事实Conflict Resolver
M06Temporal Error使用已失效偏好Time Filter
M07Provenance Loss不知记忆来源Record Schema
M08Index DriftCanonical 与向量索引不一致Index Pipeline
M09Retrieval Miss需要的记忆未召回Query/Retriever
M10Context Pollution无关记忆占满预算Context Builder
M11Instruction Confusion恶意记忆成为指令Trust Isolation
M12Wrong Use模型误用正确记忆Prompt/Verifier
M13Delete Failure派生摘要仍含被删内容Governance
M14No 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.py
tests/
memory/
write_policy/
conflicts/
temporal/
retrieval/
security/
deletion/
scenarios/
data/
memory_eval.jsonl
docs/
memory_architecture.md
memory_write_policy.md
retention_and_deletion.md

实践顺序:

1. 先实现 Typed AgentState,不接长期记忆
2. 建 MemoryRecord + Namespace + Provenance
3. 用规则实现明确偏好写入
4. 增加候选提取,但 Policy 仍确定性
5. 建 Profile CAS 更新与 Episode append-only
6. 接 Vector/Search Index,Canonical Store 为真相源
7. 建 Context Budget 与 trust label
8. 做冲突、过期和删除
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. 面试与架构评审问题#

  1. AgentState 与 Long-term Memory 为什么必须分开?
  2. Vector DB 为什么不等于 Memory System?
  3. 怎样判断一条用户陈述可以写长期记忆?
  4. 为什么要同时记录 valid time 和 recorded time?
  5. Profile 与 Collection 如何选择?
  6. 相似度为什么不能解决事实冲突?
  7. Hot-path Write 与 Background Write 各有什么一致性问题?
  8. 如何证明删除真的覆盖派生索引和摘要?
  9. 如何防止跨租户向量召回?
  10. Compaction 与长期记忆有什么区别?
  11. 如何评估“记忆提升”不是因为多给了 token?
  12. 什么情况下应该关闭 Memory?

23. 参考资料与延伸阅读#

以下资料用于核对公开行为和原始论文思想。产品文档会演进,真实接入需固定版本并验证数据治理;预印本结果需标明作者报告与实验条件。

厂商、框架与开源实现#

[S1] OpenAI Session 与 Compaction#

[S2] Anthropic Context Engineering#

[S3] 云厂商与框架 Memory#

[S4] Graphiti#

[S5] LangGraph Memory#

[S6] Mem0#

[S7] 安全与风险治理#

[S8] Letta 与 MemGPT#

论文与 Benchmark#

[P1] Lost in the Middle#

[P2] Generative Agents#

[P3] MemGPT#

[P4] Zep / Graphiti#

[P5] MemoryBank#

[P6] Reflexion#

[P7] Mem0#

[P8] A-MEM#

[P9] LoCoMo#

[P10] LongMemEval#

[P11] LongMemEval-V2#


24. 阶段总结#

生产级 Agent Memory 的核心不是“记得更多”,而是“只在正确的边界内记住值得复用的内容”:

State 负责恢复当前任务;
RAG 提供外部证据;
Memory 保存未来值得复用的信息;
Context Builder 决定这一次让模型看到什么。

每条长期记忆都应回答:

谁的?
从哪里来?
何时有效?
可信到什么程度?
为什么允许保存?
谁能读取?
与旧信息是什么关系?
何时过期?
怎样更正和删除?
是否真的提升任务结果?

只有这些问题有结构化答案,Memory 才是可治理的系统能力,而不是把上下文污染延长到未来会话。

Agent Memory 与 Context Engineering:从任务状态到长期记忆治理
https://jupiter-ws.cn/posts/agent/agent-memory-context-engineering/
作者
Jupiter
发布于
2026-04-11
许可协议
CC BY-NC-SA 4.0