文章目录
- 零、论文基本信息
- 一、背景与问题
- 二、为什么传统 Cache 不适合 Agent?
- 三、APC 的核心思想:不要缓存答案,缓存"做法"
- 四、APC 方法总览
- 五、Keyword Extraction:检索的不是相似句子,而是相似任务
- 六、为什么采用 Exact Keyword Matching?
- 七、Cache Hit:用小模型适配历史 Plan
- 八、Cache Miss:让强模型重新思考
- 九、成功执行后如何生成 Plan Template?
- 十、为什么不直接缓存完整 Execution History?
- 十一、APC 与 Semantic Cache 的本质区别
- 十二、从 Agent Memory 角度怎么理解 APC?
- 十三、实验设置
- 十四、对比方法
- 十五、主要实验结果
- 十六、GAIA:成本降低 76.42%,准确率只下降 0.61 个百分点
- 十七、QASPER 和 AIME 的结果
- 十八、Cache Hit 并不天然是一件好事
- 十九、成本到底花在哪里?
- 二十、延迟分析
- 二十一、Cache Generation 也不是免费的
- 二十二、Cache Size 越大越好吗?
- 二十三、Exact Match 与 Fuzzy Matching
- 二十四、Cold Start:Test-Time Memory 的天然问题
- 二十五、这篇论文真正的核心增量是什么?
- 二十六、APC 与 HiAgent 的联系
- 二十七、APC 与 A-MEM / MAGMA 的区别
- 二十八、我的理解和启发
- 二十九、对 Tool Agent 的启发
- 三十、对 Coding Agent 的启发
- 三十一、可以进一步扩展成 Experience Cache
- 三十二、Memory 是否应该有"经济价值"评分?
- $$ V(m)
- 三十三、APC 的局限性
- 三十四、一个更完整的 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.
转载自 CSDN-专业IT技术社区
原文链接:https://blog.csdn.net/weixin_45642847/article/details/163804263




