【论文阅读】Agent 记忆机制（41）：Agentic Plan Caching——将历史执行轨迹转化为可复用的计划记忆

文章目录

• • [\> **怎样把历史执行经验变成可复用的 Plan Template，让 Agent 不必为相似任务反复支付昂贵的规划成本？**](#> 怎样把历史执行经验变成可复用的 Plan Template，让 Agent 不必为相似任务反复支付昂贵的规划成本？)
• 零、论文基本信息
• 一、背景与问题
• • [1. Plan-Act Agent 的成本主要花在哪里？](#1. Plan-Act Agent 的成本主要花在哪里？)
  • [2. 相似任务并不意味着答案可以复用](#2. 相似任务并不意味着答案可以复用)
• [二、为什么传统 Cache 不适合 Agent？](#二、为什么传统 Cache 不适合 Agent？)
• • [1. Context Caching：缓存模型内部状态](#1. Context Caching：缓存模型内部状态)
  • [2. Semantic Caching：缓存 Query → Output](#2. Semantic Caching：缓存 Query → Output)
  • [3. Query Similarity 还可能看错重点](#3. Query Similarity 还可能看错重点)
• [三、APC 的核心思想：不要缓存答案，缓存"做法"](#三、APC 的核心思想：不要缓存答案，缓存"做法")
• [四、APC 方法总览](#四、APC 方法总览)
• [五、Keyword Extraction：检索的不是相似句子，而是相似任务](#五、Keyword Extraction：检索的不是相似句子，而是相似任务)
• • [Figure 3：为什么不用 Query Similarity？](#Figure 3：为什么不用 Query Similarity？)
• [六、为什么采用 Exact Keyword Matching？](#六、为什么采用 Exact Keyword Matching？)
• [七、Cache Hit：用小模型适配历史 Plan](#七、Cache Hit：用小模型适配历史 Plan)
• [八、Cache Miss：让强模型重新思考](#八、Cache Miss：让强模型重新思考)
• [九、成功执行后如何生成 Plan Template？](#九、成功执行后如何生成 Plan Template？)
• • [1. Rule-Based Filter](#1. Rule-Based Filter)
  • [2. Lightweight LLM Filter](#2. Lightweight LLM Filter)
• [十、为什么不直接缓存完整 Execution History？](#十、为什么不直接缓存完整 Execution History？)
• [十一、APC 与 Semantic Cache 的本质区别](#十一、APC 与 Semantic Cache 的本质区别)
• • [APC Keyword → Plan Task Intent 小模型适配 Plan Template Keyword 后重新执行](#APC Keyword → Plan Task Intent 小模型适配 Plan Template Keyword 后重新执行)
• [十二、从 Agent Memory 角度怎么理解 APC？](#十二、从 Agent Memory 角度怎么理解 APC？)
• 十三、实验设置
• • [1. Agent 架构](#1. Agent 架构)
  • [2. 模型配置](#2. 模型配置)
  • [3. 数据集](#3. 数据集)
• 十四、对比方法
• • Accuracy-Optimal
  • Cost-Optimal
  • [Semantic Caching](#Semantic Caching)
  • [Full-History Caching](#Full-History Caching)
• 十五、主要实验结果
• • [1. 平均成本降低 50.31%](#1. 平均成本降低 50.31%)
  • [2. 保留 96.61% 的最优性能](#2. 保留 96.61% 的最优性能)
• [十六、GAIA：成本降低 76.42%，准确率只下降 0.61 个百分点](#十六、GAIA：成本降低 76.42%，准确率只下降 0.61 个百分点)
• [十七、QASPER 和 AIME 的结果](#十七、QASPER 和 AIME 的结果)
• [十八、Cache Hit 并不天然是一件好事](#十八、Cache Hit 并不天然是一件好事)
• 十九、成本到底花在哪里？
• 二十、延迟分析
• [二十一、Cache Generation 也不是免费的](#二十一、Cache Generation 也不是免费的)
• [二十二、Cache Size 越大越好吗？](#二十二、Cache Size 越大越好吗？)
• [二十三、Exact Match 与 Fuzzy Matching](#二十三、Exact Match 与 Fuzzy Matching)
• [二十四、Cold Start：Test-Time Memory 的天然问题](#二十四、Cold Start：Test-Time Memory 的天然问题)
• 二十五、这篇论文真正的核心增量是什么？
• [二十六、APC 与 HiAgent 的联系](#二十六、APC 与 HiAgent 的联系)
• [二十七、APC 与 A-MEM / MAGMA 的区别](#二十七、APC 与 A-MEM / MAGMA 的区别)
• 二十八、我的理解和启发
• • [1. Agent Memory 的价值不只是提高准确率](#1. Agent Memory 的价值不只是提高准确率)
  • [2. 真正值得保存的是"可迁移部分"](#2. 真正值得保存的是"可迁移部分")
  • [3. Memory Abstraction 可能比 Memory Retrieval 更重要](#3. Memory Abstraction 可能比 Memory Retrieval 更重要)
• [二十九、对 Tool Agent 的启发](#二十九、对 Tool Agent 的启发)
• [三十、对 Coding Agent 的启发](#三十、对 Coding Agent 的启发)
• [三十一、可以进一步扩展成 Experience Cache](#三十一、可以进一步扩展成 Experience Cache)
• [三十二、Memory 是否应该有"经济价值"评分？](#三十二、Memory 是否应该有"经济价值"评分？)
• [ V(m)](# V(m))
• [三十三、APC 的局限性](#三十三、APC 的局限性)
• • [1. 强依赖任务重复性](#1. 强依赖任务重复性)
  • [2. Keyword 可能过于粗粒度](#2. Keyword 可能过于粗粒度)
  • [3. Exact Match 提高 Precision，但降低 Recall](#3. Exact Match 提高 Precision，但降低 Recall)
  • [4. Plan Template 可能过时](#4. Plan Template 可能过时)
  • [5. 主要缓存成功经验](#5. 主要缓存成功经验)
  • [6. 成本结果依赖商业 API 定价](#6. 成本结果依赖商业 API 定价)
• [三十四、一个更完整的 Agent Memory 体系](#三十四、一个更完整的 Agent Memory 体系)
• 三十五、总结
• 参考资料

---

前言

前面已经阅读了 A-MEM、Mem0、MemoryOS、Nemori、MAGMA、HiAgent 等不同类型的 Agent

记忆方法。

这些方法虽然都在讨论"记忆"，但关注的问题已经逐渐从简单的历史信息保存扩展到了不同层面：

• Mem0 关注记忆如何新增、更新和删除； - A-MEM 关注记忆之间如何动态建立关联； - MemoryOS

关注不同生命周期的记忆如何分层管理； - Nemori

关注如何识别情节边界，将连续交互组织成稳定的 Episodic Memory； - MAGMA

关注如何根据问题意图，在语义、时间、因果和实体关系中寻找正确的证据路径； - HiAgent 关注

Long-Horizon Task 中不断增长的 Working Memory，利用 Subgoal 对历史执行轨迹进行分层压缩。

这些工作大多把记忆的价值理解为：

> 让 Agent 在未来能够"记得更多"，从而做得更好。

但今天这篇论文提出了一个不同的视角：

> 过去的 Agent 执行经验，除了可以提升能力，还能不能直接用来省钱？

考虑两个任务：

```text 任务 A： 计算 Costco 2019 财年的 Working Capital Ratio。

任务 B： 计算 Walmart 2022 财年的 Working Capital Ratio。 ```

两次任务需要读取的公司、年份和财务数据都不同，因此最终答案不能直接复用。

但它们背后的求解计划高度相似：

```text 找到 Current Assets ↓ 找到 Current Liabilities ↓ 计算：

Working Capital Ratio = Current Assets / Current Liabilities ```

传统 Semantic Cache 如果缓存：

text Query → Answer

就很难安全复用，因为答案依赖不同的外部数据。

真正可以复用的其实不是 Answer，而是 Plan。

也就是说，一次任务完成后，不只是得到答案，而是进一步从执行轨迹中提取：

```text Keyword： working capital ratio

Plan Template： 1. 获取 total current assets 2. 获取 total current liabilities 3.

用二者计算 working capital ratio ```

之后再遇到 Walmart 2022 的同类任务，就不必再次调用昂贵的大模型从头规划，而可以检索历史

Plan Template，再由轻量模型结合当前 Context 进行适配。

这就是论文提出的 Agentic Plan Caching（APC）。

因此，这篇论文虽然使用了"Caching"这个词，但从 Agent Memory 的角度看，它实际上提出了一种

Test-Time Memory：

> 把成功 Agent
轨迹中的可复用计划结构抽取出来作为记忆，在未来相似任务中复用，从而减少重复规划。

它想解决的核心问题不是：

> 怎样让 Agent 记住更多历史？

而是：

> **怎样把历史执行经验变成可复用的 Plan Template，让 Agent

不必为相似任务反复支付昂贵的规划成本？**

零、论文基本信息

• 论文名称：Agentic Plan Caching: Test-Time Memory for Fast and
  Cost-Efficient LLM
  Agents
• 发表平台：NeurIPS 2025 Main Conference
• 作者信息：Qizheng Zhang、Michael Wornow、Kunle Olukotun（Stanford
  University）

注：NeurIPS 2025 正式会议版本列出的作者为以上三位；后续 arXiv v2

版本增加了 Gerry Wan。本文以 NeurIPS 正式版本为准。

---

一、背景与问题

1. Plan-Act Agent 的成本主要花在哪里？

很多 Agent 并不是一次 LLM 调用就完成任务，而是不断重复：

Plan
 ↓
Act
 ↓
Observation
 ↓
Plan
 ↓
Act
 ↓
...

论文将这一类系统抽象为 Plan-Act Agent。

为了理解这种 Agent 与不同缓存方法之间的关系，可以先看论文 Figure 1.

图源：Zhang et al., 2025，Figure 1。

Figure 1(a) 展示典型的 Plan-Act Agent：Planner LM 根据 Query 生成

Plan，Actor LM 结合外部 Context 执行；Figure 1(b) 对比 Context

Caching、Semantic Caching 和 Plan Caching 分别缓存了什么。

Plan 阶段通常负责：

• 任务分解；
• 决定下一步需要什么信息；
• 设计工具调用流程；
• 判断 Actor 的结果是否足够；
• 必要时重新规划。

为了获得更好的规划能力，Planner 往往会使用更大的模型、Reasoning

Model、Chain-of-Thought 或更多 Test-Time Compute。

于是一个现实问题出现了：

规划本身可能非常贵。

尤其当很多请求实际上属于同一种任务时，Planner

可能一次又一次重新推导几乎相同的 Plan。

2. 相似任务并不意味着答案可以复用

例如：

Query A：
What is FY2019 working capital ratio for Costco?

Query B：
What is FY2022 working capital ratio for Walmart?

两个问题的高层意图相同，但答案依赖不同公司、年份和外部财务报表。

所以：

Answer A ≠ Answer B

但是：

Plan A ≈ Plan B

这正是 APC 的出发点。

对于 Agent，真正重复的往往不是最终输出，而是：

从任务意图到执行方案的规划结构。

---

二、为什么传统 Cache 不适合 Agent？

1. Context Caching：缓存模型内部状态

Context Caching 通常复用 Prompt Prefill 阶段产生的 KV Cache。

它能够减少重复 Prefill，但论文指出 KV Cache 与具体模型绑定。Agent

系统经常同时使用 Large Planner、Small Planner、Actor、Verifier

等多个模型，不同模型的 KV Cache 无法直接互换。

因此，Context Cache 更像：

模型级计算缓存。

而不是：

Agent 级经验复用。

2. Semantic Caching：缓存 Query → Output

Semantic Cache 通常保存：

历史 Query
   ↓
Embedding
   ↓
缓存 Output

新 Query 到来后，如果与历史 Query 足够相似，就直接复用旧 Output。

对于普通 Chatbot，这种方式可能有效。

但 Agent 的输出往往满足：

O u t p u t = f ( Q u e r y , C o n t e x t ) Output=f(Query,Context) Output=f(Query,Context)

而不是：

O u t p u t = f ( Q u e r y ) Output=f(Query) Output=f(Query)

这里的 Context 可以是：

• 外部文档；
• 数据表；
• 当前网页；
• GUI 状态；
• 用户信息；
• 环境变量；
• 工具返回结果。

所以：

Query 相似，不代表 Output 可以直接复用。

3. Query Similarity 还可能看错重点

假设：

A：Costco FY2019 working capital ratio
B：Costco FY2020 working capital ratio
C：Costco FY2019 debt-to-equity ratio

从 Plan 是否可复用的角度看，A 与 B 更接近。

但完整 Query Embedding 可能受到公司、年份等 Context-Specific Detail

的强烈影响。

因此：

Query Similarity

并不等于：

Plan Reusability

APC 不直接用完整 Query 作为 Cache Key，而是先抽取高层任务意图。

---

三、APC 的核心思想：不要缓存答案，缓存"做法"

传统 Semantic Cache：

Query
  ↓
Cache
  ↓
Answer

APC：

Query
  ↓
Intent / Keyword
  ↓
Plan Cache
  ↓
Plan Template
  ↓
结合当前 Context 适配
  ↓
Actor 执行
  ↓
Answer

两者最本质的区别是：

Semantic Cache：
复用结果

APC：
复用过程

更准确地说，是复用经过抽象后的规划结构。

一次真实执行可能是：

Plan 1：
从 Costco FY2019 财报中找到
Total Current Assets 和 Total Current Liabilities。

Response 1：
Current Assets = 23,485 million
Current Liabilities = 23,237 million

Plan 2：
计算 23,485 / 23,237。

APC 不会原样保存这些内容，而是抽象成：

Keyword：
working capital ratio

Plan Template：

Step 1：
获取 total current assets

Step 2：
获取 total current liabilities

Step 3：
计算 current assets / current liabilities

Costco、FY2019 和具体数值被删除，留下的是跨任务可迁移的求解结构。

---

四、APC 方法总览

为了理解 Cache Hit、Cache Miss 和 Plan Template

生成如何形成闭环，可以看论文 Figure 2。

图源：Zhang et al., 2025，Figure 2。

Figure 2 分成三部分：(a) Cache Hit 时使用 Small LM 适配历史 Plan

Template；(b) Cache Miss 时回退到 Large LM 正常规划；©

成功执行后，从 Plans、Responses 和 Output 中过滤出新的 Keyword 与 Plan

Template，并写回 Cache。

完整流程：

                   New Query
                       │
                       ↓
                Keyword Extraction
                       │
                       ↓
                Search Plan Cache
                  /            \
                Hit            Miss
                 │               │
                 ↓               ↓
         Retrieve Template   Large Planner LM
                 │               │
                 ↓               ↓
          Small Planner LM     New Plan
                 │               │
                 └───────┬───────┘
                         ↓
                  Context + Plan
                         ↓
                     Actor LM
                         ↓
                     Response
                         ↓
                Task Completed?
                    /       \
                  No         Yes
                  │           │
                  ↓           ↓
              Re-plan       Output
                              │
                       if cache miss
                              ↓
                   Extract Plan Template
                              ↓
                       Update Cache

APC 包含四个核心动作：

Extract
Store
Adapt
Reuse

即：

从成功执行中抽取计划 → 保存 → 新任务到来时检索 →
根据当前上下文适配后复用。

---

五、Keyword Extraction：检索的不是相似句子，而是相似任务

APC 收到 Query 后，先让轻量模型提取高层任务意图。

例如：

Compute the average of all numbers
listed in the external document.

转换为：

mean calculation

又如：

What is FY2019 working capital ratio for Costco?

提取：

working capital ratio

这里实际上做的是：

具体任务
   ↓
去掉实体、年份、数值等上下文细节
   ↓
抽象任务意图

APC 真正需要判断的不是：

两句话是不是很像？

而是：

两项任务是不是可以使用相似的 Plan？

因此 Keyword 比完整 Query 更接近 Plan Reusability。

Figure 3：为什么不用 Query Similarity？

图源：Zhang et al., 2025，Figure 3。

Keyword-Based Search 同时获得更低的 False Positive Rate 和 False

Negative Rate，说明完整 Query 的语义相似度并不等价于"是否应该复用同一

Plan"。

False Positive：

两个 Query 看起来很像
↓
Cache Hit
↓
实际上 Plan 不应该复用

False Negative：

两个 Query 表面不够像
↓
Cache Miss
↓
实际上完全可以复用 Plan

前者可能损害准确率，后者主要损害成本和延迟。

---

六、为什么采用 Exact Keyword Matching？

APC 主系统采用 Keyword Exact Match：

keyword ∈ Cache

就命中，否则 Cache Miss。

作者没有默认使用 Fuzzy Matching，因为如果重新引入：

Embedding Similarity
+
Similarity Threshold

就会重新遇到：

Threshold 太高
→ False Negative 增加

Threshold 太低
→ False Positive 增加

Exact Match 还可以直接使用哈希表，平均查询复杂度接近：

O ( 1 ) O(1) O(1)

使 Cache Lookup 本身非常便宜。

---

七、Cache Hit：用小模型适配历史 Plan

如果 Keyword 命中：

Query
 ↓
Keyword
 ↓
Cached Plan Template

APC 并不会原样执行 Template。

因为 Template 已经去掉了具体上下文。

系统调用 Small Planner LM，将：

Query
+
Context
+
Plan Template

重新实例化为当前任务的具体 Plan。

例如 Cache 保存：

1. obtain total current assets
2. obtain total current liabilities
3. calculate assets / liabilities

新任务是：

计算 Walmart FY2022 Working Capital Ratio

小模型将其适配为针对 Walmart FY2022 财报的具体步骤。

因此 APC 不是：

Retrieve → Copy

而是：

Retrieve → Adapt → Execute

它保存的是可以再次实例化的 Procedure Template。

---

八、Cache Miss：让强模型重新思考

如果：

keyword ∉ Cache

系统回退到 Large Planner LM：

Query
 ↓
Large Planner
 ↓
Plan
 ↓
Actor
 ↓
Response

这意味着：

见过类似任务：
历史经验 + 小模型

没见过：
强模型从头规划

Cache Miss

并不是纯粹浪费，因为任务成功以后，这次执行会进一步转化成未来可复用的

Memory。

---

九、成功执行后如何生成 Plan Template？

论文采用两级过滤。

1. Rule-Based Filter

先从 Execution Log 中保留关键内容，并去掉 Verbose Reasoning 等无关信息。

2. Lightweight LLM Filter

再使用轻量 LLM 删除：

• Entity Name；
• Numeric Value；
• 当前任务特有变量；
• Context-Specific Detail。

例如：

Provide the total current assets
and total current liabilities
for Costco for FY2019.

变成：

Provide:
1. total current assets
2. total current liabilities

Costco 和 FY2019 被删除。

最终形成：

(Keyword, Plan Template)

并写入 Cache。

这一步本质上是在做：

Raw Experience
      ↓
Filter
      ↓
De-contextualize
      ↓
Reusable Procedure

---

十、为什么不直接缓存完整 Execution History？

一个更简单的方案是：

成功执行一次
↓
保存整个历史轨迹
↓
以后作为 Few-Shot Example 给小模型

论文称为 Full-History Caching。

但在 FinanceBench 上：

Full-History Caching：

Accuracy = 72.00%
Cost = $1.99

APC：

Accuracy = 85.50%
Cost = $1.86

APC 不仅更便宜，而且准确率更高。

作者认为，小 Planner LM

不擅长从冗长、未经筛选的完整执行轨迹中自动找出真正可复用的规划结构。

因此：

更多历史 ≠ 更好的 Memory。

真正重要的是：

Raw Experience
      ↓
Filter
      ↓
Abstraction
      ↓
Reusable Experience

这与 HiAgent 中"不要把所有历史 Action-Observation

永久留在上下文"其实非常接近。

---

十一、APC 与 Semantic Cache 的本质区别

---

方法 缓存什么 命中依据 命中后做什么

---

Context Cache KV / Prefix State 精确或共享前缀 复用模型内部计算

Semantic Cache Query → Output Query Semantic 直接复用 Output

Similarity

APC Keyword → Plan Task Intent 小模型适配 Plan

Template Keyword 后重新执行

最关键的区别是：

Semantic Cache：
"这个问题以前是不是回答过？"

APC：
"这种任务以前是不是做过？"

因此 APC 将缓存粒度从 Query-Level 提升到了 Task-Level。

---

十二、从 Agent Memory 角度怎么理解 APC？

论文把 APC 放在 LLM Serving 和 Caching

背景下讨论，但作者明确将其描述为一种 Test-Time Memory。

从 Memory 角度看：

一次成功 Agent Execution
        ↓
      Experience
        ↓
提取可复用 Plan Structure
        ↓
      Memory
        ↓
未来相似 Task
        ↓
      Retrieve
        ↓
      Adapt
        ↓
      Reuse

因此 APC 保存的不是 Fact Memory，也不是 Conversation Memory，而更接近：

Procedural / Experience Memory。

它记住的不是：

"上次答案是什么？"

而是：

"上次这种事情是怎么做的？"

---

十三、实验设置

1. Agent 架构

主实验建立在 Minion 架构上，由 Large Planner LM 和较小的 Actor LM

协同执行，最大 Plan-Act 迭代次数为 10。

作者还将 APC 集成到 Open Deep Research Agent，以验证它并不只适用于

Minion。

2. 模型配置

主实验使用：

Large Planner：
GPT-4o

Small Planner：
Llama-3.1-8B

Actor：
Llama-3.1-8B

Keyword Extraction：
GPT-4o-mini

Cache Generation：
GPT-4o-mini

这体现了 APC 的目标：

昂贵模型
→
只在必要时使用

轻量模型
→
负责意图抽取、模板生成和模板适配

3. 数据集

论文覆盖：

• FinanceBench：长上下文金融推理；
• QASPER：科研论文长文档问答；
• TabMWP：表格数学文字题；
• AIME 2024 / 2025：数学推理；
• GAIA：复杂开放域、多步推理和工具调用。

---

十四、对比方法

Accuracy-Optimal

不使用 Cache，始终调用 Large Planner，代表性能优先。

Cost-Optimal

不使用 Cache，始终调用 Small Planner，代表成本优先。

Semantic Caching

缓存 Query → Response，通过 Query-Level Similarity 判断命中，测试

80%、85%、90% 三个阈值。

Full-History Caching

缓存完整 Agent Execution Log，命中后作为 In-Context Example 交给 Small

Planner。

这个 Baseline 直接检验：

APC 的效果是不是仅仅来自"给小模型看历史经验"？

---

十五、主要实验结果

论文最核心的四个数字是：

平均 Cost：
↓ 50.31%

平均 Latency：
↓ 27.28%

保留 Accuracy-Optimal 性能：
96.61%

Cache 额外成本：
1.04%

1. 平均成本降低 50.31%

APC 与 Accuracy-Optimal 相比，平均减少 50.31% 的 Agent Serving Cost。

真正节省的是：

Repeated Planning Compute。

2. 保留 96.61% 的最优性能

如果只是把 Large Planner 全部换成 Small

Planner，当然可以省钱，但准确率通常会下降。

APC 试图找到：

Accuracy-Optimal
     ↕
APC
     ↕
Cost-Optimal

之间更好的 Accuracy-Cost Trade-off。

---

十六、GAIA：成本降低 76.42%，准确率只下降 0.61 个百分点

GAIA 使用 Open Deep Research Agent：

方法 Cost Accuracy

---

Accuracy-Optimal $69.02 37.58%

Cost-Optimal $3.16 19.39%

APC $16.27 36.97%

相比 Accuracy-Optimal：

Cost：
$69.02 → $16.27

降低：

76.42 % 76.42\% 76.42%

Accuracy：

37.58% → 36.97%

只下降 0.61 个百分点。

因此 APC

不是追求最低成本，而是在基本保留强模型性能的前提下减少重复规划。

---

十七、QASPER 和 AIME 的结果

Benchmark Accuracy-Optimal Cost-Optimal APC

---

QASPER 2.14 / 58.00% 0.21 / 53.00% $0.78 / 57.00%

AIME 2024 1.14 / 64.52% 0.65 / 48.39% $0.85 / 61.29%

AIME 2025 1.34 / 61.29% 0.60 / 48.39% $0.81 / 58.06%

GAIA 69.02 / 37.58% 3.16 / 19.39% $16.27 / 36.97%

APC 的位置比较稳定：

Cost：
明显低于 Accuracy-Optimal

Accuracy：
明显高于 Cost-Optimal

因此它更像：

用历史经验换取 Planner Compute 的中间层。

---

十八、Cache Hit 并不天然是一件好事

论文 Figure 5 比较了 Cache Miss 和 Cache Hit 时的准确率。

图源：Zhang et al., 2025，Figure 5。

Semantic Caching 和 Full-History Caching 在 Cache Hit 后出现明显

Accuracy Drop，而 APC 的 Cache Hit 与 Cache Miss 表现更加稳定。

这说明：

Hit ↑

不一定意味着系统更好。

如果命中错误经验，反而可能：

Accuracy ↓

Semantic Cache 的问题在于：

Query Similar
↓
假设 Output Reusable

但 Agent 中 Query Similar 最多说明 Intent 可能相似，并不能说明 Output

相同。

APC 因此只复用 Plan Structure，仍让 Actor 根据当前 Context 重新执行。

---

十九、成本到底花在哪里？

FinanceBench 主结果的成本拆分：

Component Cost 占比

---

Large Planner LM $1.7544 94.17%

Small Planner LM $0.0168 0.90%

Actor LM $0.0705 3.78%

Cache Overhead $0.0213 1.15%

└ Keyword Extraction $0.0050 0.27%

└ Cache Generation $0.0163 0.88%

Total $1.8630 100%

真正昂贵的仍然是 Large Planner。

论文报告 Keyword Extraction 和 Cache Generation 的平均额外成本只有：

1.04 % 1.04\% 1.04%

即使 Cache Hit Rate = 0，平均额外成本也只有：

1.31 % 1.31\% 1.31%

因此：

命中：
节省 Large Planner

没命中：
多付少量 Cache 维护成本

---

二十、延迟分析

论文在 FinanceBench 随机抽取 100 个 Query，Cache Hit Rate 为 46%。

方法 Total Latency

---

Accuracy-Optimal 1959.24 s

Cost-Optimal 1004.79 s

APC 1424.82 s

相比 Accuracy-Optimal：

1959.24 − 1424.82 1959.24 ≈ 27.28 % \frac{1959.24-1424.82}{1959.24} \approx 27.28\% 1959.241959.24−1424.82≈27.28%

APC 将 End-to-End Latency 降低约 27.28%。

但 APC 并不是延迟最低的方法。Cost-Optimal 仍然更快，因为它始终使用 Small

Planner。

所以准确说法应该是：

APC 在尽量保留 Accuracy-Optimal
性能的同时减少成本和延迟，而不是追求绝对最低延迟。

---

二十一、Cache Generation 也不是免费的

APC 的主要额外延迟来自 Cache Generation。

论文报告平均每个 Cache Entry 的生成需要约：

3.99 秒

因此第一次遇到新任务时：

Cache Miss
↓
Large Planner
↓
执行任务
↓
生成 Template

会比完全不维护 Memory 多一个后处理阶段。

所以 APC 的收益依赖一个重要假设：

未来还会出现可以复用这条 Plan 的任务。

如果 Hit Rate 长期过低，论文建议自动关闭 Caching。

---

二十二、Cache Size 越大越好吗？

FinanceBench：

Cache Size   Hit Rate         Cost   Accuracy   Total Latency

---

         1         2%       \$3.97     92.00%       2232.76 s
        10        13%       \$3.51     88.00%       1911.95 s
        20        28%       \$2.95     85.00%       1772.61 s
        50        45%       \$1.88     86.00%       1459.92 s
       100        46%   **\$1.86**     85.50%   **1424.82 s**

随着 Cache 增大：

Hit Rate ↑
Cost ↓
Latency ↓

但从 50 增加到 100 时，Hit Rate 只从 45% 增至 46%，收益已经明显递减。

当 Cache 覆盖主要 Unique Task Keywords 后，继续扩大容量意义有限。

论文使用简单的 LRU Eviction Policy 管理 Cache。

---

二十三、Exact Match 与 Fuzzy Matching

当 Cache Size 达到 10 6 10^6 106 时：

Exact Match：

Hit = 56 μs
Miss = 37 μs

Fuzzy Matching：

Hit = 148449 μs
Miss = 148147 μs

也就是约 148 ms。

因此 Keyword Exact Match 不只是为了准确率，也为了让 Cache Lookup

足够便宜。

论文进一步测试：

Matching Threshold Hit Rate Cost Accuracy Total Latency

---

Exact 46% $1.86 85.50% 1424.82 s

> 80% 54% $1.15 83.00% 1219.73 s

> 60% 64% $0.93 77.00% 1044.50 s

随着 Fuzzy Threshold 降低：

Hit Rate ↑
Cost ↓
Latency ↓
Accuracy ↓

这说明：

Memory Retrieval 并不是召回越多越好。

False Negative 只是让系统重新思考一次；False Positive

却可能让系统沿着错误经验执行。

所以 APC 更偏向：

Precision 优先于 Recall。

---

二十四、Cold Start：Test-Time Memory 的天然问题

APC 的 Cache 一开始为空，因此早期会频繁 Cache Miss。

随着成功任务不断转化成 Plan Template，Hit Rate 逐渐提高。

论文在 FinanceBench 中观察到：

20% Query：
15 entries
Hit Rate = 14.29%

40% Query：
27 entries
Hit Rate = 24.39%

60% Query：
36 entries
Hit Rate = 36.07%

80% Query：
42 entries
Hit Rate = 40.75%

100% Query：
46 entries
Hit Rate = 48.00%

因此 APC 是一种：

越用越有价值的 Test-Time Memory。

如果已知目标 Workload，可以用 Offline Samples 预先生成 Plan Template，对

Cache 进行 Pre-Warm。

---

二十五、这篇论文真正的核心增量是什么？

如果只看表面，很容易把 APC 理解成：

给 Agent 加了一个 Cache。

但真正重要的是作者改变了：

Agent Experience 应该复用什么？

传统缓存：

复用 Model State
或
复用 Output

APC：

复用 Plan Structure

于是形成：

Past Execution
      ↓
Abstraction
      ↓
Plan Template
      ↓
Task-Level Memory
      ↓
Future Adaptation

换句话说：

它把一次性的规划过程变成了可以跨请求复用的程序性经验。

---

二十六、APC 与 HiAgent 的联系

HiAgent 关注：

当前任务内部

如何管理历史执行轨迹：

Subgoal 1
→ Summary

Subgoal 2
→ Summary

Current Subgoal
→ Detailed Trajectory

APC 关注：

不同任务之间

如何复用过去执行经验：

Completed Task
→ Plan Template
→ Cache

Future Similar Task
→ Retrieve
→ Adapt

因此可以放到两个时间尺度：

                 Agent Experience
                       │
          ┌────────────┴────────────┐
          ↓                         ↓
     Within-Task               Cross-Task
          │                         │
          ↓                         ↓
       HiAgent                      APC
          │                         │
          ↓                         ↓
 Working Memory             Test-Time Memory
          │                         │
          ↓                         ↓
Subgoal Summary             Plan Template

二者实际上非常互补。

---

二十七、APC 与 A-MEM / MAGMA 的区别

A-MEM、MAGMA 等方法更关注：

历史信息
↓
怎样组织？
↓
怎样找到正确证据？

APC 不是在问：

哪段历史事实可以帮助回答？

而是在问：

过去有没有做过同一种任务？如果做过，能不能直接复用当时的做法？

因此：

A-MEM / MAGMA：
Evidence-Oriented Memory

APC：
Procedure-Oriented Memory

---

二十八、我的理解和启发

1. Agent Memory 的价值不只是提高准确率

过去讨论 Memory 时，很容易想到：

Memory
↓
更多信息
↓
更准确

APC 提供了另一个视角：

Memory
↓
减少重复推理
↓
更便宜
+
更快

因此 Agent Memory 的评价指标还应该包括：

• Token Cost；
• Dollar Cost；
• Latency；
• Large Planner 调用次数；
• Cache Hit Rate。

Memory 不一定让 Agent"更聪明"。

有时它最大的价值是：

让 Agent 不必重复聪明。

2. 真正值得保存的是"可迁移部分"

一次 Agent Execution 包含：

Query
Reasoning
Plan
Tool Call
Observation
Response
Output

但并不是所有内容都适合作为长期经验。

Costco、FY2019、具体财务数字只对一次任务有意义；"计算 Working Capital

Ratio 需要哪些变量和步骤"才具有跨任务价值。

因此 Memory Construction 的核心问题可以进一步表述成：

如何从 Experience 中分离 Instance-Specific Information 与
Transferable Knowledge？

3. Memory Abstraction 可能比 Memory Retrieval 更重要

Full Execution History 信息最完整，但 FinanceBench 上只有 72.00%

Accuracy，而 APC 达到 85.50%。

说明：

Memory Quality 不等于 Information Quantity。

一个好的 Memory 应该主动完成：

过滤
+
抽象
+
去上下文化
+
结构化

而不是简单把历史全部存下来。

---

二十九、对 Tool Agent 的启发

例如：

用户：
帮我分析这个 CSV 中销售下降的原因。

第一次可能需要：

Inspect Schema
↓
Compute Monthly Revenue
↓
Locate Decline
↓
Segment by Region
↓
Inspect Product Categories
↓
Generate Explanation

成功后可以抽象成：

Keyword：
sales decline analysis

Plan Template：

1. inspect schema
2. aggregate target metric by time
3. locate decline interval
4. segment by major dimensions
5. identify largest contributors
6. synthesize explanation

以后分析另一份销售数据：

Retrieve
↓
Adapt
↓
Execute

这比保存上次具体 DataFrame 的所有中间结果更有价值。

---

三十、对 Coding Agent 的启发

Coding Agent 中也存在大量重复规划。

例如两个不同项目都出现 Python

ImportError，具体文件、包名和依赖版本不同，但 Plan 可能类似：

1. 读取报错堆栈
2. 定位失败 import
3. 检查依赖声明
4. 检查 module/package structure
5. 应用最小修改
6. 运行 targeted test
7. 运行 regression tests

可以保存：

{
  "keyword": "python import error",
  "plan_template": [
    "inspect traceback",
    "locate failing import",
    "inspect dependency and module structure",
    "apply minimal fix",
    "run targeted test",
    "run regression tests"
  ]
}

下一次：

Task
↓
Intent Extraction
↓
Plan Memory Hit
↓
Small Planner Adaptation
↓
Tool Execution

这能够减少 Coding Agent 中大量重复的"先让强模型想一遍应该怎么排查"。

---

三十一、可以进一步扩展成 Experience Cache

APC 当前主要缓存 Successful Plan。

进一步可以保存：

成功经验
+
失败经验
+
约束
+
修正策略

例如：

{
  "task_type": "python_import_error",
  "plan": [
    "inspect traceback",
    "inspect module structure",
    "check dependency"
  ],
  "failure_patterns": [
    "do not modify sys.path before checking package structure"
  ],
  "success_rate": 0.87,
  "usage_count": 42,
  "avg_cost_saved": 0.31
}

这样 Plan Cache 就会进一步变成：

Experience Memory。

---

三十二、Memory 是否应该有"经济价值"评分？

传统 Memory Importance 可能根据：

语义重要性
Recency
Frequency
用户偏好

评分。

APC 启发我们增加：

Reuse Frequency
Cost Saved
Latency Saved
Success Rate

可以进一步设想：

$$

V(m)

P(\text{reuse}\mid m)

\times

C_{\text{saved}}(m)

\times

Q(m)

$$

其中：

• P ( reuse ∣ m ) P(\text{reuse}\mid m) P(reuse∣m)：未来复用概率；
• C saved ( m ) C_{\text{saved}}(m) Csaved(m)：每次复用节省的成本；
• Q ( m ) Q(m) Q(m)：Memory 的可靠性。

这不是论文提出的公式，而是基于 APC 的进一步思考：

Agent Memory 可以按照未来能够减少多少计算来决定保留优先级。

---

三十三、APC 的局限性

1. 强依赖任务重复性

如果用户每次任务都完全不同：

Hit Rate → 0

APC 就几乎没有复用收益。

它更适合：

• 企业固定工作流；
• 数据分析；
• 财务问答；
• 重复工具任务；
• Coding Workflow。

2. Keyword 可能过于粗粒度

"分析销售下降原因"虽然 Keyword

相同，但不同数据结构、行业、工具可能需要完全不同的 Plan。

单一：

keyword → template

可能不足以表示复杂任务空间。

3. Exact Match 提高 Precision，但降低 Recall

mean calculation
average calculation
calculate arithmetic mean

可能对应同一 Plan，却被识别为不同 Keyword。

未来可以考虑：

Canonical Intent
+
Structured Task Signature

而不是简单字符串。

4. Plan Template 可能过时

API、网页 UI、代码仓库和工具都会变化。

旧 Plan Template 可能逐渐失效。

因此真实系统还需要：

• Version；
• Validity；
• Environment Signature；
• Success Statistics；
• Expiration。

5. 主要缓存成功经验

论文在正确完成任务后生成 Cache Entry。

这样可以保证 Memory Quality，但失败轨迹同样可能有价值：

这种做法以前失败过
↓
未来不要重复

6. 成本结果依赖商业 API 定价

论文的 Dollar Cost 根据实验时的商业 API Token Pricing

计算，因此价格变化后绝对金额也会变化。

更稳定的评价还应该同时报告：

• Planner 调用次数；
• Input / Output Token；
• Hit Rate；
• Planning Steps；
• Wall-Clock Latency。

---

三十四、一个更完整的 Agent Memory 体系

结合前面阅读的论文，可以把 Agent Memory 进一步理解为：

                        Agent Memory
                             │
          ┌──────────────────┼──────────────────┐
          ↓                  ↓                  ↓
      Fact Memory      Experience Memory   Working Memory
          │                  │                  │
          ↓                  ↓                  ↓
       "是什么"           "怎么做"           "现在在做什么"
          │                  │                  │
     Mem0/MAGMA             APC               HiAgent

继续细分：

Fact Memory
├── User Preference
├── Entity
├── Temporal
└── Causal

Experience Memory
├── Successful Plan
├── Failed Plan
├── Tool Workflow
├── Strategy
└── Skill

Working Memory
├── Current Goal
├── Current Subgoal
├── Recent Observation
├── Tool State
└── Current Constraints

APC 最有价值的地方，就是把 Agent Memory 的关注点从：

记住"内容"

扩展到了：

记住"做法"

---

三十五、总结

Agentic Plan Caching（APC）提出了一种面向 Plan-Act Agent 的 Test-Time

Memory。

它观察到：

Agent 的最终输出通常依赖动态 Context，不能像普通 Chatbot

一样直接复用历史 Answer；但不同任务之间的高层 Plan

往往具有很强的重复性。

因此 APC 不缓存：

Query → Answer

而是缓存：

Keyword → Plan Template

完整流程可以概括为：

历史成功任务
   ↓
提取执行轨迹
   ↓
删除具体实体、数字和上下文信息
   ↓
形成 Plan Template
   ↓
与高层 Keyword 一起写入 Cache
   ↓
新任务到来
   ↓
提取 Keyword
   ↓
Cache Hit?
   ↓
Small Planner 适配 Template
   ↓
Actor 根据当前 Context 重新执行

如果 Cache Miss：

Large Planner
↓
从头规划
↓
成功执行
↓
生成新的 Plan Template
↓
写回 Cache

实验表明，APC：

• 平均降低 Agent Serving Cost 50.31%；
• 平均降低 Latency 27.28%；
• 保留 Accuracy-Optimal Baseline 96.61% 的应用性能；
• Keyword Extraction 和 Cache Generation 的平均额外成本只有
  1.04%；
• 在 GAIA 上将成本从 69.02 降至 16.27 ，降低 76.42% ，而
  Accuracy 仅从 37.58% 降至 36.97%。

同时，论文也说明：

• 完整 Execution History 并不一定是好的 Memory；
• Query Semantic Similarity 并不等价于 Plan Reusability；
• Fuzzy Matching 虽然能提高 Hit Rate，却可能因为错误复用降低
  Accuracy；
• Test-Time Cache 存在 Cold Start；
• APC 的收益高度依赖任务是否具有可重复的规划结构。

如果用一句话概括 APC：

APC 将 Agent 的历史执行轨迹抽象成可复用的 Plan
Template，让相似任务从"每次重新规划"变成"检索过去的做法并按当前上下文适配"，从而把
Agent Memory 从能力增强工具进一步变成了推理成本优化工具。

---

参考资料

• Zhang Q, Wornow M, Olukotun K. Agentic Plan Caching: Test-Time
  Memory for Fast and Cost-Efficient LLM
  Agents.
  NeurIPS, 2025.