FlexA-Mem：面向 LLM 智能体的预算自适应智能体记忆

1. 问题与价值

论文要解决的问题是：LLM agent 在不同场景下对记忆的需求是冲突的。一类场景是「事实回忆」，例如回答关于过去对话的问题，需要精确的日期、名字、数字等原文片段；另一类是「多步任务执行」，例如 AppWorld 里让 agent 转账，需要的是「我已经做过什么」的轨迹概览，以及下一步恰好需要但当前查询无法命名的细节。

为什么重要：agent 的历史很快超过单次调用的上下文窗口，而模型对长上下文中间部分的利用不可靠，所以每次调用必须在固定 token 预算内决定放什么进上下文。放错内容会导致 agent 反复登录、反复读 API 文档，或者回答事实问题时丢失精确字符串。

谁受益、怎么受益：任何需要在长历史上反复调用 LLM 的 agent 系统。多步任务 agent 受益于不再重复 setup 步骤，节省步数和 token；事实问答 reader 受益于保留原文精确片段而不是 LLM 改写后的摘要。论文声称一个存储设计同时服务两类场景，避免为每类场景单独部署记忆系统。

2. 已有工作的不足

在 FlexA-Mem 之前，最好的做法分几条线，每条只服务一类需求：

• A-Mem（Xu et al., 2025a）：检索式记忆，返回与查询最接近的笔记。适合事实回忆，但 agent 被要求「发送转账」时，没有理由去搜索它之前的登录步骤，导致任务轨迹断裂。论文数据显示 A-Mem 在 AppWorld Test-Normal 4k 只有 25.0% 完成率。
• Summary / compaction（Wang et al., 2025c；Lindenbauer et al., 2025）：把旧观察替换成占位符或 LLM 摘要。保留长轨迹概览，但丢失事实问题需要的精确字符串。Observation masking 在 AppWorld 4k 只有 35.7%。
• Summary+A-Mem：把两者拼起来，但预算分割在写入时固定。论文指出这种固定分割在写入历史时无法知道场景、步骤和预算，因此本质上被调到一个场景。
• MemGPT、Sculptor：把隐藏细节留给工具调用，但 agent 很少主动调用这些工具（Fan et al., 2026；Li et al., 2026b）。
• ReadAgent、AFM：最接近的设计。ReadAgent 让 LLM 选择用原文替换 gist；AFM 在预算内按最旧优先把单元降级为 full、compressed、placeholder。但 AFM 按年龄而不是相关性访问单元，且会丢弃最新单元——论文报告 AFM 在 4k 时每次调用平均丢掉 2.3 个最新单元。

核心不足可以概括为：写入时提交。无论是摘要、演化笔记还是固定预算分割，都在写入时决定了信息以后如何呈现，而那时场景、查询和预算都未知。

3. 重建作者的思考路径

从旧方法出发推演。面对第 2 项的不足，最直接的念头是：既然 A-Mem 丢轨迹、summary 丢精确串，那能不能把两者都存下来，读的时候再决定展示什么？这似乎就是 Summary+A-Mem 的思路。但 Summary+A-Mem 的问题是预算分割固定。于是自然会想：能不能让分割随查询和预算变化？

撞上的第一个矛盾：如果读的时候用 LLM 决定展示什么，每次调用都多一次 LLM 决策，agent 本来就每步调用模型，成本翻倍，而且 LLM 决策本身不可控。所以读时选择必须便宜，最好不用 LLM。

第二个念头：那用检索分数决定展示什么。A-Mem 已经这么做了，用 embedding 相似度检索笔记。但这里撞上第二个矛盾：agent 的下一步需要的细节，往往和当前查询文本不相似。论文后面给了数据：AppWorld 中 agent 下一步需要的细节落在 task+newest unit 的 BM25 top-5 里的比例是 22.4%，和随机顺序的 22.2% 几乎一样。也就是说，纯关键词匹配在多步任务里不比随机好。这说明不能只靠查询相似度选单元。

怎么改：既然查询不可靠，那就不要只依赖查询。可以保留一个不依赖查询的「轨迹」，保证 agent 总能看到自己做过什么的压缩记录。这解决了多步任务的轨迹需求。但轨迹是压缩的，精确细节还是丢。于是需要「恢复」机制，把某些单元的原文或片段放回轨迹中。

改完发现新问题：恢复哪些单元？如果只用 embedding 相似度，还是撞上「查询无法命名细节」的问题。一个自然的修补是：不仅恢复查询相似的单元，还恢复它们的时间邻居和链接邻居。因为 agent 的下一步往往紧接在最近几步之后，或者和某个相似单元有语义关联。论文的链接机制 Li 和时间邻居 Ni 就是这个修补。

再撞上预算问题：恢复的单元如果都放原文，预算一下就满了。于是需要降级机制：原文放不下就放摘录，摘录放不下就只保留记录。这就是 fit-or-degrade 的雏形。这里有一个关键设计选择：按什么顺序给单元分配分辨率？如果按年龄最旧优先，就会像 AFM 一样丢掉最新单元；如果按相关性排序，更相关的单元不会被更不相关的挤掉。论文选择了后者。

还有一个分叉：事实回忆场景里，问题通常直接命名证据，关键词匹配有效，而且证据可能分散在很多单元里，每个单元只需要一小片。这时恢复整单元浪费预算。于是分出一个「片段恢复」模式，按 BM25 对全历史所有片段排序，只取最匹配的片段。这个分叉不是一开始就显然的，而是在观察到「agent 场景查询不可靠、reader 场景查询可靠」之后才分开的。

与论文实际路径的差异：我猜的路径是先有「轨迹+恢复」的统一框架，再根据场景分模式。论文实际呈现的顺序更强调「写入一次、每次调用重新渲染」这个总设计，然后从 AFM 借预算内降级、从 ReadAgent 借 gist 原位替换原文，再引入按相关性访问和两种恢复模式。论文明确说恢复模式是「按任务类型设置」而不是运行时选择，且承认没有可部署的逐查询选择规则。我猜的路径里没有提前意识到「模式选择」本身会成为一个未解决的问题，而论文把它列为 limitation 和下一步工作。

4. 核心 intuition

把记忆想象成一本带索引的档案册。档案册里每一页原文都永久保存，不撕不涂改。每次开会前，秘书根据这次会议的主题和预算，临时做一份简报：先放一页时间线，上面每件事只有一行摘要，保证老板知道「已经办过哪些事」；剩下的篇幅，秘书挑几页和当前议题最相关的档案，能放全文放全文，放不下就摘录关键段落，再放不下就只保留那一行摘要。秘书不做任何不可逆的删改，下次会议预算不同、议题不同，简报就不同。

这个类比对应的机制是：不可变存储保证精确原文永不丢失；时间线记录保证轨迹始终在上下文中；fit-or-degrade 保证在剩余预算内给最相关的单元最高分辨率；摘录用 BM25 从原文里挑最匹配的片段，保留精确字符串而不是 LLM 改写。类比中的「秘书不做不可逆删改」对应论文的 write-once 设计，这是它和 summary、A-Mem 笔记演化的根本区别。

5. 方法 pipeline 举例

编一个具体输入：AppWorld 任务「Reset friends on venmo to be the same as my friends in my phone」，预算 4k token，当前是第 16 步。

1. 写入阶段：前 15 步中，离开 recent window 的单元被写成 note。每个 note 包含原文 ri、记录 si（最多 80 词，LLM 写）、检索字段 fi、embedding ei、链接 Li（余弦相似度最高的 3 个早期 note）、片段集合 Πi（按行切，每片最多 150 token）。例如单元 7 覆盖 steps 12-14，记录写「Loaded API docs for phone.login and venmo.login, then successfully logged in, both returning Bearer access_token dicts」，原文保留打印 token 的代码。

1. 计算 allowance：At = 0.95 × 4096 − ∣Pt∣ − ∣Wt∣。论文案例中 newest unit 占 1,571 token，留给记忆 1,712 token。

1. 构建时间线：所有过去单元的记录按时间排成 Tt。如果时间线太长，合并最旧的最多 4 条连续记录为一条 merged record，由一次 LLM 调用写，缓存复用。合并条件涉及 ∥Tt∥ > max(ρAt, At − Dt)，其中 Dt 是所有恢复候选按原文展示的总成本。

1. 单元恢复候选排序：查询 embedding 是 task 和 newest unit 的归一化和。取余弦相似度 top-10 作为 seeds，每个 seed 加上它的 3 个链接邻居和 2 个时间邻居，按公式 gt(j) 打分，折扣 λ=0.9 惩罚通过链接或时间到达的单元。候选按 gt 降序访问。

1. fit-or-degrade 分配分辨率：对每个候选单元，先试原文，放不下试摘录，再放不下只保留记录。记录成本为 0。摘录是记录 si 后面跟 BM25 对 newest unit 排名最高的片段，总长不超过 E=300 token。论文案例中，单元 7 的摘录保留了打印 phone_token 和 venmo_token 的代码片段，因为这段代码和当前任务最匹配。

1. 原位替换：恢复的单元替换时间线中自己的记录位置。如果记录已被合并，恢复内容插在 merged record 之后并付全文长度。最终 Mt 包含 5 条记录和 2 个摘录，总长不超过 1,712 token。

1. agent 看到的结果：时间线告诉它已经登录过两个服务，摘录告诉它 token 存在哪个变量里。agent 检查 token 仍存在，不再重新登录，第 22 步提交。对比之下，truncation、A-Mem、piece retrieval 在同一任务上反复读 API 文档 74 到 109 次后撞上 60 步上限。

6. 核心数学推导

先解释符号。At 是记忆 allowance，即总预算减去 prompt 和 recent window 后剩下的 token 数。Tt 是时间线，∥Tt∥ 是它的 token 长度。R0 = At − ∥Tt∥ 是恢复可用的剩余空间。ui 是第 i 个历史单元。xvi 是单元 ui 在分辨率 v 下的文本，v 可取 rec（记录）、exc（摘录）、raw（原文）。si 是 ui 的记录文本。τi 是指示器：如果 ui 的记录在时间线中仍然独立存在则为 1，如果已被合并则为 0。

第一个核心量是展示成本，公式（3）：

costi(v) = 0 当 v = rec；否则 costi(v) = ∣xvi∣ − τi∣si∣

推导逻辑：展示记录不额外花钱，因为记录本来就在时间线里。展示摘录或原文时，摘录和原文里都包含记录 si 作为前缀，而如果记录还独立存在于时间线中，这部分已经被计过一次，所以要减去 τi∣si∣ 避免重复计数。如果记录已被合并，τi = 0，恢复内容要付全文长度，因为合并记录里没有这个单元的独立记录可替换。

第二个核心量是 fit-or-degrade 的递推，公式（4）。设候选按分数降序排列为 u(1), u(2), ...。对第 ℓ 个候选：

v(ℓ) = max { v : cost(ℓ)(v) ≤ R(ℓ−1) }，其中 v 按 rec ≺ exc ≺ raw 排序

Rℓ = R(ℓ−1) − cost(ℓ)(v(ℓ))

推导逻辑：R(ℓ−1) 是处理完前 ℓ−1 个候选后剩下的空间。第 ℓ 个候选取能在剩余空间内放下的最高分辨率。因为 rec 成本为 0，所以记录总是能放下，这个 max 集合非空。Rℓ 是扣掉第 ℓ 个候选实际成本后的新剩余空间。这个递推保证更相关的单元先拿预算，不会被更不相关的单元挤掉。

这个公式在算的是：给定一个按相关性排好序的候选序列和一个固定剩余空间，如何贪心地给每个候选分配尽可能高的分辨率，同时总成本不超过空间。它不涉及任何 LLM 调用，是一个确定性的预算分配规则。

7. 实验设计

数据集：AppWorld（Test-Normal 168 任务、Test-Challenge 417 任务，4k 和 6k 预算，60 步上限）；SWE-bench Verified（480 issues，8k 预算，250 步上限，其中 95 个用于选设置）；LongMemEval（500 问题，约 48 会话、103k token 历史，4k 到 32k 预算，60 个 dev 问题选设置，440 个 held-out 报告）；LoCoMo（1,540 问题，10 个对话，2k 到 8k 预算）。另有 147 个 AppWorld Train/Dev 未用任务做冻结设计的确认实验。

基线：Full history、Truncation、Observation masking、Masking + rule log、Piece retrieval、Unit retrieval、A-Mem、Summary+A-Mem、MemGAS、Sculptor、ReadAgent、AFM。所有方法共享单元切分、embedding 模型、预算、token 计数器和 LLM（GPT-5.4 mini）。

指标：AppWorld 用任务完成率（所有单元测试通过）；SWE-bench 用 resolve rate；LongMemEval 和 LoCoMo 用准确率（LoCoMo 用 Mem0 的 judge prompt，指标记为 J）。成本用每任务 token 数，包含记忆构建。

消融：去掉时间线、去掉恢复、去掉摘录、随机候选、相同候选随机顺序、时间线后展示相同选择、固定长度恢复、A-Mem 加 fit-or-degrade。关键结果：去掉时间线在 AppWorld 4k 掉 15.5%；去掉恢复在 LongMemEval 4k 掉 28.2%；随机候选在 LongMemEval 4k 掉 47.5%。

实验能否支撑结论：能支撑「一个存储服务两类场景」的核心主张，尤其是 147 个未用任务的冻结预测实验给出了较干净的证据。但有几个缺口：恢复模式是按任务类型手工设置的，没有逐查询选择规则；大多数配置只跑一次，AppWorld 两次运行间差异可达 4.8%；LongMemEval 的聚合结果在设计 piece recovery 时被检查过，论文自己承认只能算 comparative evidence；SWE-bench 上优势很小，480 issues 上只比 observation masking 高 2.3%。

8. take-aways

• 在 AppWorld Test-Challenge 4k 预算下，FlexA-Mem 完成率 40.3%，比第二名 ReadAgent 的 28.8% 高 11.5 个百分点，p 小于 0.001。
• 在 147 个未用于设计的 AppWorld 任务上，FlexA-Mem 4k 完成率 76.9%，比最强基线 Summary+A-Mem 的 64.6% 高 12.2 个百分点，Holm 校正后 p=0.006。
• 时间线是 agent 任务完成率的主要载体：去掉时间线在 AppWorld 4k 掉 15.5%，而时间线单独在未用任务上达到 76.2%，与完整方法只差 0.7 个百分点。
• 恢复机制是事实回忆准确率的主要载体：去掉恢复在 LongMemEval 4k 掉 28.2%，随机候选掉 47.5%；而去掉时间线在 LongMemEval 最多只改变 3.6%。
• 纯关键词检索在事实回忆上已经很强：piece retrieval 和 piece recovery 在 LongMemEval 每个预算下差距不超过 0.7%，但 piece retrieval 不写记忆，成本只有 8.0k token 对 176.6k token。
• 成本方面，SWE-bench Verified 上 FlexA-Mem 每 issue 用 306.2k token，Summary+A-Mem 用 1,577.1k token（306.2/1,577.1≈1/5），约为后者的五分之一。原文图 3 把 full history 与各方法画在同一 token 轴上对照，但正文没有给出 full history 的每任务 token 数，所以这里不做「比全历史更省」的断言。

9. 最脆弱的假设

最脆弱的假设是：恢复模式可以按任务类型预先设置，且同一类型内所有查询的最优模式一致。论文在 3.5 节明确说「we do not choose the mode at run time」，在 6.4 节承认「The runtime signals we tested do not reliably predict the better mode for a single query, and we offer no deployable rule for choosing it」。

这个假设一倒，结论就崩：如果实际部署中单个 agent 任务内部混合了「查询能命名证据」和「查询不能命名证据」的步骤，或者一个 reader 的问题集里同时有高可寻性和低可寻性问题，那么固定模式会在其中一半上显著劣于另一模式。论文自己的数据给出了这个脆弱性的量级：在 LongMemEval 4k，当 BM25 把证据排第一时 piece recovery 领先 unit recovery 17.6%，当证据排在 20 名以外时 unit recovery 领先 26.5%。也就是说，模式选错的代价最高可达 26.5 个百分点。

论文没有给出这个假设成立的证据。相反，它把「逐查询选择恢复模式」列为下一步工作，并承认运行时信号不可靠。这意味着当前方法在混合场景下的实际表现取决于任务类型划分的粒度是否足够细，而论文没有验证更细粒度的划分。

10. 一周最小复现

目标：复现「一个存储服务两类场景」的核心对比，不追求完整 benchmark 规模。

数据准备：用 LongMemEval 的 60 个 dev 问题选设置，440 个 held-out 问题报告；AppWorld 用 Test-Normal 的 168 任务，如果时间不够就随机抽 50 个。

实现步骤：

1. 用 all-MiniLM-L6-v2 做 embedding，o200k tokenizer 计数，GPT-5.4 mini 或任何可用 LLM 做 agent 和 reader。
2. 实现单元切分：agent 场景按 1,000 token 打包连续 step；reader 场景按约 2,000 token 切会话。
3. 写 note：每个单元一次 LLM 调用生成最多 80 词记录和检索字段。这是主要的 LLM 成本。
4. 实现时间线：记录按时间排列，超限时合并最旧最多 4 条，合并用一次 LLM 调用。
5. 实现 fit-or-degrade：按论文公式（3）（4），候选来自 embedding top-10 seeds 加链接和时间邻居，摘录用 BM25 对 newest unit 或 question 排名片段，每片最多 150 token，摘录总长 300 token。
6. 基线只实现三个：Truncation、A-Mem（简化版，embedding 检索笔记）、Summary+A-Mem（固定分割）。

预期指标：在 LongMemEval 440 问题上，piece recovery 应在 4k 达到约 78% 准确率，比 A-Mem 高约 25 个百分点；在 AppWorld 50 任务子集上，unit recovery 应比 Truncation 高至少 30 个百分点完成率。如果时间只够一个场景，优先 LongMemEval，因为它不需要 agent 环境，且效果差异更大、更稳定。

硬件：24GB 显卡足够跑 embedding 和推理，瓶颈是 LLM API 调用次数而不是本地显存。

11. 反例设计

设计一个混合查询集，其中每个查询的「最优恢复模式」可以被预先标注，但查询本身不携带可识别的模式信号。

具体做法：从 LongMemEval 的 held-out 问题中，按 BM25 证据排名选出两组各 100 个问题——一组证据排名前 5，一组证据排名 20 以后。把这两组问题随机交错，交给同一个 reader，但强制使用单一恢复模式。判据：如果固定 piece recovery，在低可寻性组上的准确率应显著低于 unit recovery；如果固定 unit recovery，在高可寻性组上的准确率应显著低于 piece recovery。若 FlexA-Mem 的任一固定模式在两组上的平均准确率与「oracle 逐查询选择较优模式」的差距超过 10 个百分点，则说明「按任务类型固定模式」的核心设计在混合场景下失效。

更强的反例：构造一个 agent 任务，其中前 10 步需要轨迹概览（unit recovery 优势），后 10 步需要回答精确事实问题（piece recovery 优势），且两类步骤的查询文本在 embedding 空间不可分。如果 FlexA-Mem 用 unit recovery 跑完全程，在后 10 步的事实准确率掉到随机水平以下，则证明模式必须逐查询选择，论文当前设计不可部署。

判据要预先注册：准确率差距超过 10 个百分点且 McNemar 检验 p 小于 0.05 即判定反例成立。

12. 落地判断

用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：可以落地，但需要改造。

怎么用：FlexA-Mem 的 write-once 存储和 fit-or-degrade 渲染器可以直接嵌入多智能体脚手架的上下文管理模块。每个 agent 的历史单元写入不可变存储，每次调用前由渲染器生成时间线加恢复内容。27B 模型本地推理，embedding 用 all-MiniLM-L6-v2 在 CPU 上跑即可，BM25 用纯 Python 实现，不占 GPU。

成本量级：主要成本是写 note 和合并时间线的 LLM 调用。论文数据是每任务 150.7k 到 344.2k token（含记忆构建），但这是 GPT-5.4 mini 的 agent 轨迹。27B 模型的轨迹可能更短或更长，取决于任务复杂度。按论文的单元大小 1,000 token 估算，每写一个单元一次 note 调用，每合并最多 4 条记录一次调用。如果历史有 100 个单元，note 写入约 100 次 LLM 调用，每次约 1,000 token 输入加 80 词输出。在单张 24GB 卡上，27B 模型 4-bit 量化推理速度约 20-40 token/s，100 次 note 写入的延迟在分钟级，可接受。

最大的坑：恢复模式选择。多智能体脚手架里，不同 agent 或同一 agent 的不同阶段可能混合事实回忆和轨迹追踪需求。论文没有给出逐查询选择规则，固定模式会在混合场景下损失最高约 26.5 个百分点准确率。实际部署前需要先做一个小规模标注集，测试运行时信号能否预测较优模式。如果不行，保守做法是默认用 unit recovery，因为它在 agent 任务上全面领先，且事实回忆场景下 unit recovery 的损失小于 agent 场景下 piece recovery 的损失。第二个坑是合并时间线的 LLM 调用在 read time 发生，会增加每次调用的延迟，需要缓存合并结果并接受首次调用的额外延迟。