Agent Memory 认知地图

一句话地图

Agent memory 的核心任务是：在不能把全部历史交给模型的情况下，保留足以支持未来正确决策的信息结构。

flowchart LR
    O["观察与轨迹"] --> W["写入判断"]
    W --> R["原始证据层"]
    W --> S["语义与主题层"]
    W --> P["程序与技能层"]
    R --> X["当前执行状态"]
    S --> X
    P --> X
    X --> A["行动与回答"]
    A --> F["结果与反馈"]
    F --> C["价值归因与巩固"]
    C --> W
    G["来源、时效与权限"] --> W
    G --> X

这张图里，存储只是中间环节。真正困难的是写入、选择、更新、归因和治理。

两条最重要的区分轴

EvoMemBench 把问题拆成两条轴，这比“短期/长期 memory”更能指导设计。

	知识导向	执行导向
当前任务内	当前问题需要的事实、约束、证据	当前计划、子目标、工具结果、失败分支
跨任务	用户偏好、领域规则、稳定事实	可复用流程、技能、失败教训、策略价值

由此得到四个问题：

当前任务中，我需要保留哪些事实？
当前任务中，我需要维持怎样的执行状态？
跨任务后，哪些知识仍然有效？
哪些经验应该变成可以复用的行为规则？

四种核心产物

产物	保存什么	最适合的任务	主要风险
原始证据	完整对话、工具结果、轨迹	审计、细节恢复、重新解释	太长、噪声多、检索困难
语义文档	事实、主题、关系、时间线	多 session 问答、偏好与知识更新	过期、冲突、schema 不匹配
执行状态	当前路径、子目标、分支和约束	长程工具任务、GUI、编码与规划	错误状态持续传播
程序知识	规则、技能、指令和策略	重复任务、自我改进	过拟合、错误经验被固化

一个完整系统通常需要它们共存，而不是选一个数据库解决全部问题。

方法演化

flowchart TD
    A["把历史塞进上下文"] --> B["按相似度检索记录"]
    B --> C["结构化主题、图和层级"]
    C --> D["Agent 主动导航与验证证据"]
    D --> E["把轨迹维护成执行状态"]
    E --> F["把经验编译为规则和技能"]
    F --> H["从结果学习写入、检索和遗忘策略"]
    H --> I["增加 transition 验证、来源和权限治理"]

这不是严格时间线，而是问题不断暴露后的能力叠加：

上下文解决可见性，但产生成本和注意力稀释。
检索解决容量，但相似不等于对决策有用。
结构解决关系和聚合，但 schema 可能提前丢失未来问题需要的信息。
Agentic retrieval 延迟结构承诺，让模型按问题寻找证据，但增加推理成本。
执行状态解决长任务中的因果连续性和错误隔离。
编译记忆把反复出现的经验变成行为改变，而不只是再次展示历史。
学习控制策略解决“哪些记忆长期有价值”，同时引入 credit assignment 问题。
治理层防止错误或不可信内容变成永久系统状态。

五个设计环节

Write

决定候选信息是否值得越过持久化边界。需要处理信息增量、重复、置信度、来源和未来用途。

Manage

执行合并、拆分、更新、遗忘、冲突处理和版本维护。这里决定 memory 会不会随时间腐烂。

Read

根据当前问题选择最小但充分的上下文。读取既可以是一次检索，也可以是 Agent 多步搜索、检查和补证据。

Learn

根据任务结果更新哪些记忆有用、哪些结构有效、哪些经验应晋升为规则。关键难题是把结果正确归因到先前记忆。

Govern

记录来源、时间、主体、权限和派生链；敏感行动不能只因为某条记忆“看起来合理”就执行。

一眼判断方法

面对一个新任务，按顺序问：

历史是否真的超过有效上下文，或者会跨 session？如果否，先用长上下文 baseline。
任务失败来自忘记事实，还是丢失执行状态？两者需要不同结构。
是否存在可重复利用的稳定模式？如果有，考虑程序记忆或编译指令。
未来查询类型能否提前定义？如果不能，保留原始证据并支持主动导航。
memory 模块消耗的 token 和延迟，是否比把预算给基础 Agent 更值得？
写错、写旧或写入恶意内容后，系统能否追踪、撤销并阻止敏感行动？

4.5 KiB Raw Blame History