当 LLM Agent 的记忆被"用死"——一篇把记忆访问变成在线学习的论文

你有没有这种感觉：自己部署的 AI 智能体一开始还挺能打，跑了几百个任务之后，记忆库已经堆得很大了，但表现不升反降？明明"经验"更多了，为什么反而更不灵了？

又或者反过来：智能体卡在某个任务上，连续做了 5 步一样的动作。记忆里有现成的相似任务经验，但 agent 不会回头"换一种方式"再检索一次。

这些现象背后其实指向同一个根因——绝大多数 LLM 智能体的记忆系统，是在用一套写死的策略去访问一个会不断长大的记忆库。固定的 top-k、固定的 hop 深度、固定的查询模板。早期任务用这套参数会过度检索，把垃圾塞进 prompt；重复出现的目标类型用这套参数又会去最近邻搜索原始轨迹，而不是复用已经蒸馏好的计划模板；长任务流结束时更没人去清理记忆库。

arXiv:2607.13591 这篇论文，就是冲着这个根因去的。作者给了一个让人眼前一亮的解法：把记忆访问本身建模为一个在线学习的序列决策问题——不是用 LLM 当 controller（MemGPT 那条路），而是用一个毫秒级的查表 Q-learning 控制器。这套机制他们叫 MemCon（Memory as a Controlled Process），是个能套在任何现有记忆后端上的薄包装层。

跨 6 个 benchmark、3 个 agent 框架、3 个 LLM 底座，MemCon 是唯一一个在全部 54 个 (framework × benchmark) 单元中都排在 top-1 或 top-2 的系统——注意，是"唯一一个"。同时还把 token 消耗砍掉了 5–20%。具体在 ALFWorld 上，用 GPT-4.1-mini + Lobster 框架，MemCon 拿到 67.9% 的成功率，比最强的 baseline G-Memory（59.7%）高出 8.2 个点。换成更强的 Claude Sonnet-4，差距能拉到 12.7% → 60.6% 这种量级。

我的第一反应是：这不像底层突破，更像是工程整合的极致形态——论文自己定位也准，明确说"我们不是新的记忆存储，我们是访问控制器"。但这个整合做得相当干净，把 memory 中"存什么"（backend）和"怎么访问"（controller）解耦得彻底，而且零额外 LLM 调用这一点对生产环境太友好了。值得花时间细读。

论文信息

  • 论文：Memory as a Controlled Process: Learned Adaptive Memory Management for LLM Agents
  • 作者：Eric Hanchen Jiang, Zhi Zhang, Yuchen Wu, Levina Li, Dong Liu, Xiao Liang, Rui Sun, Yubei Li, Edward Sun, Haozheng Luo, Zhaolu Kang, Aylin Caliskan, Kai-Wei Chang, Ying Nian Wu
  • 链接：https://arxiv.org/abs/2607.13591
  • 发表日期：2026/07/15

问题动机：静态访问是核心瓶颈

作者在引言里抛出了一个非常扎心的观察——几乎所有现有 LLM 智能体记忆系统，无论底层是向量库、技能库、图结构还是潜在 token，都共享同一个访问范式：

"most existing memory systems treat memory access as a static pipeline: a single global retriever is called once per step with a hard-coded top-k, a hard-coded graph hop depth, and a hard-coded query template, and uses the same configuration whether memory is empty or contains thousands of trajectories, whether the task is familiar or novel, and whether the agent is progressing or has been executing the same action for five steps."

——不管记忆库是空的还是已经装了几千条轨迹，不管任务是新颖的还是熟悉的，不管 agent 是在推进还是已经卡了 5 步在重复同一个动作，访问参数都一视同仁。

这套设计为什么一定会出问题？作者列了四种需要不同记忆策略的场景，并强调"没有单一固定启发式能同时满足全部四种"：

场景 最优策略 静态管道的失败模式
早期任务（记忆库稀疏） 少检索甚至不检索 不加区分地检索只会被垃圾稀释 prompt
重复目标类型 复用蒸馏好的计划模板 仍然走最近邻原始轨迹检索，错过高质量模板
卡住的 agent（连续重复动作） 用替代查询重新检索 重读同样的 top-k，结果还是失败
长任务流结束 整合 + 遗忘 记忆库只增不减，噪声越来越多

我的第一反应是——这不就是我们做 agent 项目时踩过的坑吗？我们之前用 MemGPT 风格的方案，结果是 LLM 调用量爆炸；用传统 RAG，结果卡在某些任务上始终跳不出去。MemCon 的判断是"任何单一固定参数都对至少一种场景失配"，这点我是认同的。

现有方案的两种设计点

作者把现有工作归到两个设计点上：

设计点 A：固定管道（Fixed Pipeline）。绝大多数工作都属于此类——Generative Agents、MemoryBank、Mem0、MemLLM、Think-in-Memory、Voyager、MemP、Agent Workflow Memory、ProcMEM、MemSkill、HiAgent、LatentMem、Reflexion、ExpeL、CLIN、OAgents，以及作者自承"我们最强的 baseline" G-Memory，全都是固定 top-k / 固定 hop / 固定 query / 固定 consolidation 调度。

设计点 B：LLM 当 controller。MemGPT（Berkeley, 2023）是这条路最典型的代表：把 LLM 提升为记忆"操作系统"控制器，让它自己决定什么时候分页、什么时候检索、用什么查询。代价是每次记忆操作都要额外一次完整的 LLM 调用——一个长任务流跑下来，这笔开销累积得相当吓人。

MemCon 自居第三种设计点：learned-but-lightweight 的控制器。自适应但零额外 LLM 调用，毫秒级查表完成。

这三种设计点对比一下：

范式 代表方法 自适应 代价 论文定位
固定管道 Generative Agents / G-Memory 等 ❌ 无额外开销 在某些场景必然失配
LLM-as-controller MemGPT ✅ 每次操作 1 次额外 LLM 调用 自适应但成本爆炸
Learned-but-lightweight MemCon ✅ 零额外 LLM 调用 本文

MemCon 方法核心：把记忆访问变成在线学习

MemCon 的整体框架我直接上一张官方图（Figure 1），然后拆开讲：

图1：MemCon 整体框架

图 1：MemCon 五步流程图。任务流来自 ALFWorld / PDDL / ScienceWorld，在三种 agent 框架（Lobster / LangGraph / Microsoft Agent-FW）上执行，共享一个 LLM 底座。控制器在每一步的状态提取后用 UCB 选动作（PlanInject / Retrieve / Re-Retrieve / Consolidate / Forget / NoOp），并用 episode 末的 (success, efficiency) 反馈做反向折扣 Q 更新。

看完图你就明白，整套机制其实可以拆成 5 步走：状态提取 → 决策（UCB）→ 后端调用 → 推理生成 → Episode 反馈与 Q 更新。最关键的设计在第 2 步和第 5 步。

1) Memory MDP 的形式化

作者把记忆操作选择建模为一个标准的 MDP：

\[\mathcal{M}_{\text{mem}} = (\mathcal{S}, \mathcal{A}, \mathcal{T}, \mathcal{R}, \gamma)\]

但这里有一个很微妙的处理：环境转移 \(\mathcal{T}\) 实际上是由 LLM 智能体驱动的，对控制器而言是不透明的。所以作者做了一个降级——把 \(\mathcal{M}_{\text{mem}}\) 当成"带 episode 级（Monte-Carlo）反馈的上下文赌博机"：

"the controller never bootstraps a within-episode value estimate and instead receives one terminal-reward signal per task, which makes the formal regret analysis straightforward and bounds sample complexity to tens of tasks."

控制器不做 episode 内部的 bootstrapping 价值估计（这点和完整 RL 的最大区别），只等任务结束接收一个终端奖励。这使得遗憾分析（regret analysis）很直接，样本复杂度可以压到几十个任务以内。

2) 状态：把任务进度和记忆状态融合在一起

\[s = (s^{\text{task}}, s^{\text{mem}})\]

Task State（任务进度信号）：

\[s^{\text{task}} = (\texttt{goal\_type},\; \texttt{step\_phase},\; \texttt{is\_stuck},\; \texttt{objects\_held},\; \texttt{locations})\]

注意 is_stuck 这个维度——当 agent 连续两次发出相同的物理动作时设为 True。这正是论文案例研究里体现的"卡住检测"机制。

Memory State（记忆状态信号）：

\[s^{\text{mem}} = (\texttt{mem\_size},\; \texttt{plan\_available},\; \texttt{learning\_phase})\]

plan_available 是关键——是否已经存在当前目标类型对应的蒸馏成功计划。如果有，控制器就会倾向走 PlanInject 而不是普通 Retrieve。

状态被离散化为紧凑的可哈希键 \(\phi(s)\)，用于表格学习。每个 benchmark 大约只有几百个不同状态——这正是它能用纯查表实现的根本原因。

3) 动作空间：6 个操作 × 参数

每个动作 \(a = (\texttt{op}, \theta)\) 由一个操作类型和参数组成。操作包括：

操作 说明
Retrieve 从后端返回 top-k 条目 + 最多 insight-k 条派生规则
Re-Retrieve 用替代查询后缀重新检索，用于逃离重复动作循环
PlanInject 当存在可用计划时，将泛化的成功计划前置注入
Consolidate 调用后端的合并/修剪钩子，不支持时静默 no-op
Forget 调用后端的遗忘/删除钩子，同样在不支持时 no-op
NoOp 跳过当前步的记忆访问

参数 \(\theta = (\texttt{top\_k},\; \texttt{insight\_k},\; \texttt{hop})\) 决定了检索的深度和广度。

4) UCB 策略：选动作

\[a_t = \arg\max_{a \in \mathcal{A}} \left[ Q(\phi(s_t), a) + c \sqrt{\frac{\ln N(\phi(s_t))}{N_a(\phi(s_t))}} \right]\]

标准的 UCB 形式，没什么花活儿。值得注意的几点：

  • 未访问动作获得 +∞ bonus，强制每个状态的前 \(|\mathcal{A}|\) 次访问遍历所有动作
  • Warm-start 先验在 +∞ 之间打破平局：Retrieve 和 PlanInject 偏正向，Re-Retrieve 偏较小正，Forget 和 NoOp 偏轻微负。这给出一个合理的初始排序
  • 探索系数 \(c\) 是个超参数，论文里说在 1.4 附近最优（看下面的敏感性分析）

5) Reward：把 token 效率塞进奖励里

\[r(\tau_i) = r_{\text{succ}} \cdot \mathbb{1}[\text{success}] + \lambda \cdot \max\left(0,\; 1 - T_i / T_{\max}\right) - r_{\text{fail}} \cdot \mathbb{1}[\text{failure}]\]

这个奖励设计挺有意思——除了成功/失败这种二值反馈，还把效率奖励 \(\lambda \cdot \max(0, 1 - T_i/T_{\max})\) 塞进去。任务完成得越快，奖励越大。这正是 MemCon 能"在提升准确率的同时减少 token 消耗"的关键——它学会了"该用计划模板时别去最近邻原始轨迹"、"记忆稀疏时直接 NoOp 跳过"。

6) Q-Update：反向折扣 Monte-Carlo

\[Q(\phi_j, a_j) \leftarrow Q(\phi_j, a_j) + \alpha \left[ \gamma^{|\text{ep}|-j-1} \cdot r_i - Q(\phi_j, a_j) \right]\]

每个 episode 结束后，对该 episode 中所有访问过的 \((s, a)\) 对做反向折扣 Monte-Carlo 更新。最后一个决策接收未折扣的 \(r_i\)，更早的决策按 \(\gamma^{|ep|-j-1}\) 几何衰减信用。这是个标准的 MC 信用分配。

Q 表每隔几次更新就持久化到磁盘，学习跨运行和任务流保持。

7) Backend-Agnostic Wrapper：薄包装层

MemCon 的包装层接口极其简单——后端只需暴露两个方法：

接口 功能
retrieve(query, θ) 返回 K 个与查询相关的条目
store(trace, label) 写入完成任务的轨迹
maintain(op)（可选） 解锁 consolidation 和 eviction 动作；不支持时静默 no-op

任何已有记忆后端都能即插即用——vector stores、skill libraries、summarisation-based memories、latent-token memories、graph-structured memories，全都可以套上 MemCon。论文里 MemCon 的内层后端默认用的是 G-Memory。

8) 两个增强操作

PlanInject（可学习的 MDP 动作）：提取成功任务的动作序列 → 通过 regex 重写器替换实例特定标识符（如 "shelf 3" → [shelf]） → 将模板以 JSON 索引存储 → 未来同类任务时把模板前置到检索结果。

Goal Decomposition（确定性启发式，不是 MDP 动作）：针对"把两个手机放到桌上"这种复合任务，注入"先完成对象 1 的所有步骤，再为对象 2 重复"的指令。

一个具体的案例：UCB 怎么选动作

光说公式太抽象了，论文在 Figure 2 里给了一个具体的 case study，对比了 WebWalkerQA 和 GAIA 两个不同 query 下控制器的行为：

图2：UCB 在两个 query 上的 step-by-step 案例

图 2：左侧是 WebWalkerQA 的多跳金融查询（对比两家公司在美联储最近一次加息日的股价），右侧是 GAIA 的复合计算查询（60W 灯泡 8 小时跨年总能耗）。两个 case 都完整展示了 State Observation → UCB Action Selection → Execution & Failure Detection → Policy Adaptation → Reward Calculation → Q-Update 六个环节。

Case 1（WebWalkerQA）特别能说明 Re-Retrieve 的价值。Agent 第一次选了 RETRIEVE（top-k=2, hop=1），但直接搜索具体股价失败，因为美联储最近一次加息的日期是未知的——is_stuck=True。控制器检测到卡住后，第二次选了 RE-RETRIEVE，把查询改成"先找最近一次 Fed 加息的日期"。这个查询被赋予了更高的信用权重 \(\gamma\) 来强化"卡住状态要优先恢复动作"。这就是"learned adaptive"的实际表现——固定的 top-k 永远不会这样自动重写查询。

Case 2（GAIA） 展示了 PlanInject 的适用场景。复合计算任务（跨年能耗）触发了 PLANINJECT（top-k=2, hop=1），因为这个动作在"composite reasoning tasks"上历史 Q 值高。生成的计划模板是结构化三步："Step 1: 识别所有数值常量。Step 2: 应用单位换算。Step 3: 提供对比替代方案。"

两个 case 的 reward 公式都展开计算了，参数都是 \(r_{succ}=1.0, \lambda=0.3, T_{max}=30\)。

实验结果

主实验：6 benchmarks × 3 frameworks × 3 backbones

论文的核心卖点是在 54 个 (framework × benchmark) 单元中的一致性。我先看 GPT-4.1-mini 主结果（论文 Table 1）的关键数字：

Lobster 框架（GPT-4.1-mini）：

Method ALFWorld PDDL SciWorld TriviaQA WebWalkerQA GAIA Avg.
Empty（无记忆） 43.3 33.3 28.0 69.5 17.9 20.6 35.4
G-Memory 59.7 31.7 34.0 66.5 19.0 21.2 38.7
MetaGPT 55.2 33.3 33.0 71.5 18.2 16.4 37.9
Voyager 53.0 31.7 31.0 71.5 18.4 16.4 37.0
ExpBank 59.0 33.3 30.0 69.0 17.8 20.0 38.2
MemCon 67.9 35.0 38.0 71.5 20.6 22.4 42.6

ALFWorld 上涨了 8.2 个点（67.9 vs 59.7）——这是相当能打的提升，交互决策类任务上 8 个点的差距在智能体基准上属于"显著"。

Agent-FW 框架（GPT-4.1-mini）：

Method ALFWorld PDDL SciWorld TriviaQA WebWalkerQA GAIA Avg.
G-Memory 70.2 33.3 28.0 66.0 19.4 20.0 39.5
Voyager 54.5 36.7 36.0 67.5 17.1 19.4 38.5
MemCon 71.0 40.0 38.0 69.0 20.9 23.0 43.6

关键观察：固定管道 baseline 在不同设置间极不稳定——G-Memory 在 LangGraph-ALFWorld 上是 68.7% 的强 baseline，但在 Agent-FW-PDDL 上只有 33.3%，被 MetaGPT 38.3% 反超。没有任何一个固定的 baseline 能在所有 cell 上保持 top-1 或 top-2。MemCon 是唯一在全部 54 个 cell 中都处于 top-1 或 top-2 的系统。

强 LLM 上的优势更显著

这是论文里最让我意外的一组数据。在更强的 Claude Sonnet-4 上，MemCon 在 18 个 cell 里有 15 个是 top-1：

"MemCon attains the top S/A on 15 of 18 framework×benchmark cells (and the highest Avg. in every framework)"

"Sonnet-4 上分化最强 (15/18 top-1)：因为强 LLM 的瓶颈从推理能力转移到'是否在正确时间呈现正确经验'，正是 MemCon 自适应控制器解决的问题"

这个判断我觉得相当有道理——GPT-4.1-mini 还能靠"推理能力强行补偿记忆系统的不足"，但 Claude Sonnet-4 这种已经能写好代码的 LLM，反而更吃"信息在正确时间出现在 prompt 里"这个亏。具体差距：

  • Agent-FW ALFWorld：12.7% → 60.6%
  • Agent-FW PDDL：21.0% → 70.7%
  • Agent-FW ScienceWorld：17.0% → 67.1%

这几个数很能打。

Token 成本：不是更多检索，而是更聪明

论文用 Figure 3 把 token 成本和任务成功率画在同一张图上：

图3：Token 成本 vs 任务成功率

图 3：三个子图分别对应 DeepSeek-V3.2+LangGraph 在 PDDL、GPT-4.1-mini+Lobster 在 ALFWorld、Claude Sonnet-4+Agent-FW 在 GAIA。每个气泡代表一个记忆 baseline，横向是 S/A (%)，纵向是每任务平均输入 token，面积为 token 成本。

数据点（GPT-4.1-mini + Lobster + ALFWorld）：

Method S/A (%) Tokens 备注
Empty 43.3 44K 无记忆但仍要展开历史
G-Memory 59.7 45K 准确率高但 token 不省
Voyager 53.0 48K —
OAgent 48.5 59K 最贵
MemoryBank 57.5 55K —
ExpBank 59.0 65K —
MetaGPT 55.2 48K —
MemCon 67.9 39K 又准又省

MemCon 在 ALFWorld 上同时拿到最高 S/A 和最低 token 消耗。论文汇总的 token 节省范围是 5–20%。这个反向结果（更多准确率 + 更少 token）只有在"智能选择何时不检索"的设计下才有可能。

消融实验：UCB 控制器是最大功臣

Table 2 的消融数据（GPT-4.1-mini, Lobster）：

变体 ALFWorld S/A GAIA S/A Δ ALFWorld
Static backend（仅 G-Memory 无控制器） 59.7 21.2 —
+ learned UCB 64.9 22.4 +5.2
+ plan injection 66.4 22.4 +1.5
+ goal decomposition 67.2 22.4 +0.8
+ all (= MemCon) 67.9 22.4 +0.7

关键发现：learned UCB 控制器是单一最大贡献者（+5.2 S/A），plan injection 额外 +1.5，goal decomposition 额外 +0.8。三个增强点是有用但可选的——即便只用 UCB 控制器 + G-Memory 后端，67.9% 里的 64.9% 已经到手了。

GAIA 上只有 learned UCB 有贡献（+1.2），两个增强操作在 GAIA 上无额外贡献——这和设计预期一致，GAIA 不包含复合目标。

超参数敏感性

图4：单参数扫描（连续策略超参数）

图 4：α、c、γ、r_fail 四个超参数的单变量扫描。实线是 GAIA S/A，虚线是 WebWalkerQA，★ 标记 GAIA 峰值，tan 色块是默认区域。

图5：效率权重和动作预设的扫描

图 5：左图是效率权重 λ 的扫描，λ=0.3 是默认也是峰值；右图是动作预设的扫描，9-action 默认预设显著优于 retrieval heavy、plan first、compact 三个手工替代。

关键发现：

  • GAIA S/A 在每个超参数的整个扫描范围内波动 ≤ ±2.5 个点
  • 默认值是 α、c、r_fail 的最优点；γ ∈ {0.7, 0.9} 差距在 0.1 点以内
  • 效率权重 λ=0.3 最优（去掉或过大均降约 2 个点）——这验证了"把 token 效率塞进奖励"是有意义的
  • 默认 9-action 预设显著优于手工替代（retrieval heavy、plan first、compact）

这是个很让人放心的鲁棒性表现——你不用反复调参也能拿到接近最优。

我的判断

亮点

  1. 正确定位了问题。把"记忆访问"从"记忆存储"里解耦出来，单独建模成决策问题——这本身是个干净的工程洞察。论文里"a thin wrapper that intercepts the abstract retrieve and store entry points of any existing memory backend"这句话定位非常准。

  2. 零额外 LLM 调用 是真卖点。MemGPT 那种 LLM-as-controller 的方案在 demo 上看着漂亮，但生产环境用起来 LLM 调用量爆炸。MemCon 用纯查表 Q-learning 跑出更强的结果，这个对比挺有说服力。

  3. 正交设计让落地成本极低。任何已有后端都能套上 MemCon，不用重写存储层。这对生产环境非常重要——你可以今天就在你已有的 RAG pipeline 上加一层 MemCon，明天再换后端。

  4. 强 LLM 上的差距反而更大 这一点我特别喜欢。强 LLM 的瓶颈在"信息呈现"而不是"推理能力"，这其实是个很普遍但少有人点破的判断。

  5. 理论保证。附录 D 提供了 UCB 策略的完整 regret bound，这对工程师来说是定心丸。

质疑与限制

  1. 状态离散化的人为因素。"几百个不同状态"的前提是离散化设计——bin 大小怎么选、is_stuck 阈值怎么定，这些超参数不敏感性的证据只有 GAIA 一个 benchmark 上的扫描。Lobster 和 LangGraph 上的同等鲁棒性证据我希望在正文里看到，没找到。

  2. episode 级 Monte-Carlo 反馈的代价。要等任务结束才能更新 Q 表，意味着短任务（5 步以内）的信用分配粒度其实很粗。论文里 "converges within tens of tasks" 这个说法在 ALFWorld（长任务流）上成立，但 TriviaQA 这种短答案任务上控制器能从中学到什么是个开放问题。

  3. Warm-start 先验里藏的人为设计。"Retrieve 正向、PlanInject 正向、Forget 轻微负向"——这些先验是论文作者拍脑袋的，还是有经验依据？论文没细说。

  4. 真正的"学习"深度有限。我看 Table 2 的消融发现一个微妙的事情——ALFWorld 从 59.7（静态 G-Memory）到 64.9（+UCB）涨了 5.2，但 goal decomposition 又涨了 0.7。这些数字加在一起和 67.9 完美对齐，没有任何"组合效应"溢出。这暗示这些组件是互不干扰的累加，而不是协同——这点论文没有展开讨论。

  5. 对比基线的公平性。G-Memory 用了 5.2 个点的提升空间，LatentMem 在 Sonnet-4 上某些 cell 还能压过 MemCon 一点点（18 cell 里 3 个失败），但论文没有进一步分析这些 case 上的失败模式。

  6. 离线评估的局限。所有结果都是 offline benchmark 跑出来的，没有真实部署场景下的用户反馈。"tens of tasks 内收敛"在生产环境的真实任务流上能否复现，未知。

跟同期工作的对比

MemGPT（Berkeley, 2023）：LLM 当 controller，每次记忆操作 1 次额外 LLM 调用。MemCon 的核心差异就是零额外调用。

G-Memory（2025, 作者自承最强 baseline）：图结构分层记忆。MemCon 默认就是把 G-Memory 当内层后端来用，所以这是个叠加关系而不是替代。

OLIVIA（2024, 同期 bandit 工作）：把 ReAct 风格 LLM agent 的最终动作选择建模为 contextual linear bandit，用 frozen hidden states 当 context。MemCon 是对记忆操作做 bandit，OLIVIA 是对agent 动作做 bandit，正交。

Cobalt（OSU NLP, 2025）：把多轮代码生成建模为 contextual bandit 用 GRPO 训练。MemCon 是 tabular Q-learning + UCB，Cobalt 是 GRPO 训练；一个针对记忆访问，一个针对 agent 主行为。

总的来说，MemCon 不是底层创新，而是工程整合的极致形态——把成熟的 tabular RL 工具（contextual bandit + UCB）用到 LLM agent 记忆管理这个具体问题上，定位精准、解耦干净、落地成本低。这种工作容易被忽视但实际价值很大。

工程启发

如果你的项目里已经有 RAG / 向量库 / 技能库，MemCon 的设计思路有几点可以直接借鉴：

  1. 加一层"访问控制器"。不需要训练一个复杂模型，先用规则化的策略：记忆空时 NoOp、有同类目标计划时 PlanInject、卡住时 Re-Retrieve。把这些规则做成可调参数。

  2. 奖励里塞效率信号。把 token 消耗或 step 数塞进 reward 是个简单但有效的杠杆。即使你不用 RL，规则化的访问策略也应该用效率做权重。

  3. 跨任务持续学习。MemCon 把 Q 表持久化到磁盘，让学习跨运行保留——这个"小本本记下来"的工程模式比 fine-tuning 模型便宜得多，适合工业界快速试错。

  4. 强 LLM 优先试 MemCon 类方案。如果你已经在用 Claude Sonnet-4 或 GPT-4 级别的 LLM，记忆控制器的边际收益最大——这从 MemCon 的 Sonnet-4 数据上看得很清楚。

收尾

MemCon 给我最大的启发不是某个具体公式，而是"把访问模式从固定管道改成在线学习"这个思路本身。在 LLM agent 越来越普及的今天，如何让智能体在长任务流中持续变聪明是一个被严重低估的问题。绝大多数项目还停留在"加一个向量库，调一下 top-k" 的层面，但任务流长了之后这远远不够。

MemCon 的解决方案是轻量、便宜、可插拔的——这正是工业界最需要的东西。如果你也在做 LLM agent 的记忆层，这篇论文的思路值得花一晚上读一下。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我。