基于 Tool Call 的记忆检索—— Agent 记忆架构的构想

unted_pooh

• 13 min read
Share

1. 问题的核心

LLM Agent 需要一个记忆系统。在 2026 年的技术背景下,这个问题的性质已经发生了变化。

两年前,主要矛盾是 context window 装不下——模型只能容纳几千 token,超出就截断。今天不同了。Gemini 2.5 Pro 有 1M context,GPT-4 Turbo 有 128K,容量不再是最紧的瓶颈。

但新的问题出现了。Liu et al.(2023)在 "Lost in the Middle" 中证明了一个反直觉的事实:把更多信息塞进 context,不等于模型能有效利用它——长 context 中段的信息召回率会骤降。这本质上是注意力稀释:当 context 中有太多内容竞争模型的注意力时,关键信息容易被淹没。同时,全量 context 的每个 token 都要参与 attention 计算,推理成本线性增长。

Tool-based memory retrieval 的真正价值在此时显露出来:用少量、高信噪比的精准检索结果,替代全量长文本在注意力机制中的竞争。既是成本优化,也是精度优化。

在这个前提下,回顾一下当前主流记忆方案的结构性问题:memory access 的控制权在系统侧而非模型侧。RAG 在推理前由外部 retriever 取回 top-K 文档注入 context,模型只能接收、不能拒绝。循环总结是系统定期压缩历史再塞回去。这些方案共有的假设是"系统知道模型需要什么"——但这个假设从未被充分检验。

更自然的做法是:把记忆访问建模为一个 tool call。模型在需要时自己决定查什么,查多少。

2. 已有工作

2.1 Memory-as-a-Tool——最接近的实现

Gallego(2026)的 Memory-as-a-Tool 让模型通过 tool call 主动访问持久化的 guideline 记忆——不是原始日志,而是模型从 rubrics 反馈中提炼的抽象写作原则。

实验数据:Rubric Feedback Bench,42 个场景分布于 5 个任务类别(写作风格/行为准则/伦理推理/格式控制/创意文本)。每个 rubric 含 3-7 个评估维度,4-5 个评分等级,加权计分。H=12 混合任务长序列实验:记忆组 0.78±0.10 vs 无记忆 baseline 0.52±0.25——不仅平均分高了约 50%,方差也从 0.25 降到 0.10。12 个 episode 后 agent 自动积累了 8 个记忆文件,跨任务类别完成了知识整合。

成本分析:Self-critique 方法每次 query 要做 generation + critique + revision 三轮推理,2-3x token 开销。Memory-as-a-Tool 将 critique 成本摊还到学习阶段——只付一次,后续仅需检索已有 guideline。Pareto frontier 显示它在几乎同分的位置但成本显著更低。

但这套方案与本文构想的差异需明确:它处理的是 guideline retrieval——从 rubrics 反馈中学习写作原则——而非通用对话记忆。存储层是平面文件,检索依赖模型推理文件名,作者承认这带来了 scalability 问题。

2.2 MemGPT——工具化记忆管理的先驱

MemGPT(Packer et al.,2023)是更早的应用了 tool-based memory management 的系统。它本身通过 function call 实现 self-directed memory management——模型自主决定何时检索、检索什么、写入什么。

MemGPT 原文明确写道:"MemGPT autonomously updates and searches through its own memory based on the current context."具体实现上,模型使用 core_memory_append、core_memory_replace、archival_memory_insert、archival_memory_search、conversation_search 等 function 管理记忆。系统提供两个辅助信号:heartbeat(允许多步链式 tool call)和内存压力警告(提示 FIFO queue 即将驱逐)。

架构上定义了三段 prompt:system instructions(函数 schema + 控制流描述),working context(可读写的关键事实区),FIFO queue(滚动消息历史,头部保留被驱逐内容的递归摘要)。外存分两路:archival storage(pgvector + HNSW 索引)和 recall storage(完整对话历史数据库)。Queue Manager 是系统级的驱逐调度器——当 context 使用达到 70% 时发出警告,100% 时强制 flush。

实验数据——Deep Memory Retrieval(DMR)任务,Multi-Session Chat 数据集,5 个 session 各约 12 条消息:

LLM 裸跑 accuracy +MemGPT accuracy ROUGE-L
GPT-3.5 Turbo 38.7% 66.9% 0.394→0.629
GPT-4 32.1% 92.5% 0.296→0.814
GPT-4 Turbo 35.3% 93.4% 0.359→0.827

GPT-4 配合 MemGPT 达到 92.5%,不带记忆时仅有 32.1%——逼近随机猜测。在 Conversation Opener 任务中,MemGPT(GPT-4)的开场白在 persona 相似度上超过了人类手写的 opener。

本文构想与 MemGPT 的差异:两者都用了 tool-based memory access。区别在于:(1)MemGPT 针对文档 QA 和多 session 对话场景,用 OS 分层架构(archival+recall);TBMR 针对通用对话记忆,用结构化多后端(heap/queue/SQL);(2)MemGPT 的写入是事件驱动的——内存压力信号触发保存,而 TBMR 的写入策略需要单独设计;(3)TBMR 的多 store 路由是 MemGPT 未涉及的新问题(MemGPT 只有 archival 和 recall 两个 store,路由规则是显式的——全文本搜索用 archival,时间序搜索用 recall)。

3. 来自其他工作的关键约束

3.1 模型能力的硬天花板

MemTool(Lumer et al.,2025)在 ScaleMCP benchmark(5,000 个 MCP server)上的 100+ 轮交互实验给出了一个冰冷的数据:reasoning models(Gemini 2.5 Pro/Flash、GPT-o3、Claude Opus 4)达到 87.8-100% 的 3-window 平均 tool 剔除率,同时保持 80-90% task completion。而 GPT-4o Mini、GPT-4.1 Mini、Claude 3.5 Sonnet、LLaMA 3 70B 的剔除率在 0-60% 之间。Claude 3.5 Sonnet 和 LLaMA 3 70B 在 20 轮以内就撞到了 128 tool 的 API 上限——它们只会加,不会删。

这个发现的含义是:任何依赖模型自主 tool calling 的记忆管理方案,都存在一条模型能力的硬门槛。推理模型能做到,中型模型可能完全做不到。

3.2 过程记忆的质量管理

MACLA(Forouzandeh et al.,2025)在 ALFWorld 上的逐项 ablation 显示:去掉 Bayesian Selection 时 seen 降 7.8 分,unseen 降 9.1 分,reuse rate 从 78% 跌到 62%。没有不确定性感知,系统只按语义相似度检索,频繁选到"看起来匹配但实际不可靠"的 procedure。Memory capacity 实验表明 200 个 slot 最优,300 个反而微降(-0.2%)——溢出 slot 引入了检索噪声。

MACLA 的核心启示:如果记忆质量不可控,外部化记忆的价值会被错误传播抵消。

3.3 经验追随与错误传播

Xiong et al.(2025)发现的 experience-following property 是所有记忆系统设计中最致命的风险之一:当 task input 与记忆库中某条记录在语义上高度相似时,agent 的输出会趋同于该记录的 output。这不是"有效利用经验"——如果那条记忆是错的,错误会传播并恶化后续所有类似任务。

他们还观察到 misaligned experience replay:形式上成功了,作为经验模板却是误导性的。

3.4 Store Routing 与 Externalization 框架

Store Routing(Gaikwad,2026)的形式化结论:选择性检索(oracle router)在 accuracy 和 token efficiency 上都优于全量检索所有 store。

Externalization Survey(Zhou et al.,2026)的分类学:agent 能力演进沿 weights → context → harness 路径。Memory externalizes state across time,Skills 外部化过程性知识,Protocols 外部化交互结构,Harness 统一调度。

4. 设计构想及已知约束

4.1 系统形态(未验证)

模型在正常运行时 context window 保持纯净,不含历史记忆注入。当需要查过往信息时,通过 read_memory(query, limit, store) 主动拉取。记忆由 write_memory(content, tags, priority) 写入。存储层支持多后端——堆(优先级)、队列(时间)、SQL(精确条件查询)。

4.2 写入策略设计(Hypothesis,未验证)

Xiong et al. 的错误传播发现意味着 naive 写入是一个已知会失败的选择。以下三个策略作为设计假设:

假设 A——异步反思写入(灵感来自 MACLA 的 contrastive refinement)。不在每轮对话后立即写入,而是在 session 结束时由独立 LLM 调用做一次反思(fast model 即可),从中提取关键事实写入。将写入视为一次独立的推理行为而非对话的副产品。代价:需要一个独立的反思 pass。

假设 B——验证门控写入(轻量级)。每次 write 调用触发验证流程:将待写入内容交给模型,追加一条 prompt——"这条记忆在什么情况下可能被未来的输入误解?"。验证不通过的条目标记为 low_confidence,降低 retrieval priority 或等待二次验证。代价:每次写入增加一次验证 token 开销。

假设 C——频率+时间双维护(无额外 LLM 开销)。每条记忆附带 confidence_score,由两个因素动态计算:被成功 read 的次数(正向)+ 距离上次写入的时间(负向,指数衰减)。低于阈值的自动降权或标记为 stale。代价:无额外 API 调用,但不能检测语义错误。

推荐 MVP 方案:组合 B + C,即验证门控保证基础质量 + 频率/时间维护防止过期。A 作为定期整理机制(如每 50 轮跑一次反思)。

4.3 Tool Call 引入的延迟(Hypothesis,未验证)

Tool-based memory 的工程代价:RAG 是系统提前组装好 context、模型一次性生成(TTFT 低);Tool-based 需要模型先生成查询 token → 等待数据库检索 → 再次触发模型生成 token。这引入了 1-2 轮 round-trip 延迟,在对话场景中对用户体验有明显影响。

缓解策略假设:

假设 A——流式判断(低开销)。模型在生成首个 response token 之前,先快速生成一个内部判断 token(如是否包含 <SEARCH> 标记),决定是否需要查记忆。不需要时零额外延迟,需要时多一轮查询。

假设 B——推测性并发检索(中等开销)。用户输入到达时同时启动两个并行路径:(a)模型直接生成回答,(b)基于用户 query 的 keyword 做数据库搜索。如果(a)的结果足够好,丢弃(b)的结果;如果(a)表明需要查记忆,使用已就绪的(b)结果。

假设 C——检索缓存(低开销,仅对重复查询有效)。最近 N 次检索结果保留在 context 或短期缓存中,避免重复查询同一话题。

4.4 冷启动与路由——设计假设

Q1:冷启动。假设:在 System Prompt 中注入一张 "记忆标签地图"(~200 tokens),包含记忆库中 top-K 高频标签和对应的话题摘要。模型可以从中推断记忆库的大致范围,形成初步检索意图。Memory-as-a-Tool 的文件名映射机制可以迁移——将标签地图建模为虚拟文件名列表。

Q2:可靠性量化。假设:每条记忆的 reliability 由三个因子决定:

$$reliability={timeDecay},\ {readCount},\ {verificationScore}$$

其中:

$${timeDecay}=\alpha^{t_{now}-t_{lastAccess}}$$

($\alpha\in(0,1)$ 为衰减因子)

${readCount}$ 来自实际使用频率, ${verificationScore}$ 来自策略 B 的验证结果. 融合 MACLA 的 Bayesian posterior 思路:

$$reliability\sim Beta(\alpha=n_{successReads}+1,\beta=n_{unusedSinceWrite}+1)$$

Q3:多 store 路由。假设:混合策略——用一个便宜的 fast model(如 GPT-4o Mini)作为独立 Router,根据 query 语义判断应查询哪个 store,或同时查询多个 store 但给每个 store 的结果分配不同的 priority。备选:给主模型一个 list_stores tool,让它先探查 store 的结构再决定检索策略(与 MemGPT 的 heartbeat 链式调用机制类似)。

4.5 已确认的约束(不重复前文)

  • 模型能力门槛(MemTool 数据——中型模型淘汰率 0-60%)
  • 记忆质量退化(Xiong et al. 的 experience-following——memory 中的错误会传播)
  • Cold start(MemGPT 用 system instruction 缓解,Memory-as-a-Tool 用文件名推断——都不完美)
  • Memory 膨胀(MACLA 的 capacity ablation——200 slots 最优,300 开始退化)

5. 验证路径

Level 1——功能验证

read_memory 和 write_memory 的基本语义正确性:写入后能否精确读回,多模态查询(关键词+标签+时间范围)是否正确解析,limit 参数是否生效。

Level 2——行为验证(关键层)

核心问题:Agent 是否会主动且正确地调用 memory tool?

方法修改:使用修改版的 Multi-Session Chat(MSC)数据集——构造 逻辑强依赖问题对。每对包含:

  • 源轮次:包含特定事实(如 "我叫小明,喜欢量子物理")
  • 目标轮次:提出一个只有知道源轮次事实才能回答的问题(排除通过常识推断能回答的问题)

计算 recall = 模型在目标轮次实际调用 read_memory 且查询命中源轮次的比例。同时记录 query 质量(查询词是否精准)。

Level 3——效果验证

对照实验:无记忆 vs TBMR。度量维度:长线 task completion rate + 事实追踪准确率。同步设计 Xiong et al. 风格的错误传播实验:注入 20% 错误条目,追踪表现退化曲线。

Level 4——对比验证

TBMR vs RAG vs Summarization,相同任务。标准:Memory-as-a-Tool 提出的 Pareto optimal——accuracy 与 cost 双维度比较。

Level 5——边界验证

  • 记忆膨胀(10,000 条→检索精度曲线,参考 MACLA 的 capacity ablation)
  • 多 store 路由(heap/queue/SQL 共存,参考 Store Routing 的 oracle router)
  • 模型能力阈值(至少测试 reasoning model 和 medium model 两组,参考 MemTool)
  • Latency vs Accuracy 权衡(新增):测量不同 write 策略和 retrieval 策略下的端到端延迟 p50/p95,与 SLM-based 方案对比 TTFT

References

  1. Packer et al. "MemGPT: Towards LLMs as Operating Systems." 2023. arXiv:2310.08560
  2. Gallego. "Distilling Feedback into Memory-as-a-Tool." 2026. arXiv:2601.05960
  3. Lumer et al. "MemTool: Optimizing Short-Term Memory Management for Dynamic Tool Calling." 2025. arXiv:2507.21428
  4. Forouzandeh et al. "MACLA: Learning Hierarchical Procedural Memory for LLM Agents." 2025. arXiv:2512.18950
  5. Xiong et al. "How Memory Management Impacts LLM Agents: An Empirical Study." 2025. arXiv:2505.16067
  6. Huang et al. "Memory Sandbox: Transparent and Interactive Memory Management." 2023. arXiv:2308.01542
  7. Gaikwad. "Cost-Sensitive Store Routing for Memory-Augmented Agents." 2026. arXiv:2603.15658
  8. Zhou et al. "Externalization in LLM Agents: A Unified Review." 2026. arXiv:2604.08224
  9. Yu et al. "MemAgent: Reshaping Long-Context LLM with RL-based Memory Agent." 2025. arXiv:2507.02259
  10. Liu et al. "Lost in the Middle: How Language Models Use Long Contexts." 2023. arXiv:2307.03172