Meta 的经验图：怎么让 AI Agent 积累“可复用代码“？

qcx23

97人浏览 · 2026-07-15 00:28:26

qcx23 · 2026-07-15 00:28:26 发布

来源：arXiv · 2026年6月29日 · Meta Platforms & University of Maryland
论文：Experience Graphs: The Data Foundation for Self-Improving Agents (arXiv:2606.29823)
作者：Gang Liao, Gaoxiang Liu (Meta) 等 20 余位作者
标签：#经验图 #自进化Agent #MCTS #内核优化 #训练数据

你的 Agent 跑了 100 次任务，存了 100 条轨迹——但没有一条是"可复用知识"

你的 AI Agent 跑了 100 次代码生成任务，失败了 60 次。你把所有轨迹存进经验回放池，下次随机采样几条来"学习"。但问题是——你存的是 100 条原始轨迹，不是 100 条可复用的知识。就像程序员把所有 commit 记录存下来，但没有提炼成可复用的函数库。

更糟糕的是，传统经验回放存的是"状态-动作-奖励-下一状态"元组——这是给 RL 用的，不是给 LLM Agent 用的。LLM Agent 的"状态"不是数值向量，是代码、配置、测试用例；它的"动作"不是离散选择，是生成一段可执行的程序。用 RL 的记忆框架存 LLM Agent 的经验，就像用 Excel 存视频文件——格式不对。

Meta 和马里兰大学的研究者认为，Agent 的经验应该是一棵树，不是一堆扁平记录。他们叫它"经验图"（Experience Graph）。在 KernelEvolve 项目中——为 NVIDIA、AMD、MTIA、CPU 四个硬件平台生成优化内核——经验图把"达到 1.2× 加速所需步数"从 51 步降到 5 步，有 bug 的节点从 55% 降到 21%（论文 Section 4.1）。

这个改进不是来自更大的模型或更好的 prompt，而是来自怎么组织经验。下面拆解经验图的数据结构、为什么"查询"比"收集"更适合生成训练数据、以及 Meta 在生产环境中学到的教训。

经验图长什么样

经验图采用四层关系型层次结构（论文 Section 2.1）：

层级	含义	存什么
Tasks	定义问题	规格说明、目标环境、成功指标
Sessions	记录搜索过程	谁在搜索、用哪种算法、进度如何
Nodes	每次独立尝试	父节点链接、可执行工件、执行输出、适应度分数、UCB分数/世代ID等元数据
Prompt Histories	LLM消息历史	模型看到的精确消息序列

节点之间的边是虚拟父子关系，通过外键实现，用 Cypher 查询语言的 [:HAS_CHILD*1..k] 变长遍历操作暴露。图可以是树（MCTS/贪心搜索）或 DAG（进化搜索的交叉操作产生）（论文 Section 2.1）。

这里有一个关键设计决策值得深思：边不是预存的，是查询时计算的。传统图数据库存边表，经验图用外键 + Cypher 变长遍历动态生成边。这意味着同一个节点集可以从不同维度建立不同的"图视图"——按父子和谱系看是一棵树，按适应度排序看是一个排行榜，按工具使用看是一个工具调用图。

但更重要的是节点存了什么。传统经验回放存的是数值向量（状态）和离散动作。经验图的节点存的是可执行工件——代码、配置、测试用例。这意味着记忆本身可以被重放、diff 和重用（论文 Section 2.3）。你不仅能知道"这个尝试失败了"，还能知道"它生成的代码哪里错了"，甚至能直接复用失败代码中正确的部分。

训练数据不是"收集"的，是"查询"的

这是经验图最巧妙的设计，也是和传统 RL 经验回放最大的区别。

传统 RL 从回放缓冲区随机采样训练数据。经验图用图模式匹配查询生成训练数据（论文 Section 3.3）。三种训练数据对应三种查询：

SFT 轨迹：从根到叶的路径

从根节点到叶节点的路径就是一条完整的"解题过程"。但这里有个精妙的设计——AS-OF 时间旅行查询。每个节点在决策时只能看到它之前的信息，不能看到之后的信息。查询时重建每个节点决策时的精确状态，避免未来信息泄漏（论文 Section 3.3）。

从数据分析的角度，这是"因果一致性"的保证。如果你在训练数据里让第 3 步的 Agent "看到"第 5 步的结果，它学到的是"作弊"策略而非真实推理。AS-OF 查询确保训练数据和真实推理时的信息边界一致。

DPO 偏好对：同父兄弟的适应度差异

这是最优雅的设计。同一个父节点下的多个子节点（兄弟），如果适应度差异大，就天然构成偏好对——适应度高的"chosen"，适应度低的"rejected"（论文 Section 3.3）。用 Cypher 查询：

MATCH (p)-[:HAS_CHILD]->(a), (p)-[:HAS_CHILD]->(b)
WHERE a.fitness_score > b.fitness_score + $m
  AND a.is_buggy = false
RETURN a AS chosen, b AS rejected

传统 DPO 需要人工标注偏好对。经验图用树搜索的副产品自动生成偏好对——同一个父节点下的兄弟尝试，成功的就是正例，失败的就是负例。搜索过程本身就是在产出训练数据。

从 AI 工程的角度，这解决了一个实际痛点：DPO 训练数据标注成本高。如果 Agent 的搜索过程天然产生偏好对，你不需要额外标注，搜索即标注。

GRPO 组：把多小时展开坍缩为单步

GRPO（Group Relative Policy Optimization）从持久化缓冲区采样状态，生成 N 个子候选（GRPO 组），评估后计算组归一化优势，通过 SQL 窗口函数实现（论文 Section 3.3）。最后追加一个规范节点——将"多小时的多轮展开"成本坍缩为"单步扩展"。

这个设计解决的是 RL 的信用分配问题。传统 RL 在长链路任务中无法可靠追溯成功/失败到具体步骤，GRPO 通过"在同一状态生成多个候选"来隔离单步贡献。

传统经验回放回答不了的问题

论文 Section 2.3 有一个对比表，最能说明经验图的价值：

维度	传统经验回放	经验图
记录内容	状态-动作-奖励-下一状态元组	可执行工件 + 目标奖励 + 工具输出 + 因果谱系
结构	扁平的转换序列	树/DAG：节点带父链接、奖励和兄弟关系
检索方式	按时间或优先度均匀采样	图遍历 + 向量相似度 + 结构化过滤
可执行性	无——状态是数值向量	有——记忆是程序、配置、测试用例
因果性	缺失	核心属性——失败的动作在父计划和兄弟上下文中才有价值

最后一行是关键。传统经验回放无法回答"哪个兄弟方法在当前方法失败的地方成功了"这类查询。而在树搜索中，这恰恰是核心操作——你不仅要知道"这个尝试失败了"，还要知道"和它同父的兄弟哪个成功了、成功在哪"。

从知识管理的角度，经验图存的不只是"发生了什么"，还有"为什么发生"——父子关系记录了决策谱系，兄弟关系记录了对比基准。这让经验从"数据"升级为"知识"。

实战验证：KernelEvolve 加速器内核优化

经验图在 Meta 的 KernelEvolve 项目中做了主要实验——为 NVIDIA、AMD、MTIA、CPU 四个硬件平台生成优化内核，将 ML 模型操作转换为芯片特定指令（论文 Section 4.1）。

实验对比"无跨会话记忆"（冷启动）vs 启用经验图记忆（注入率 p=0.1 和 p=0.5），固定模型、步数预算（100步）、工作线程数和搜索策略（论文 Section 4.1）：

指标	无记忆	p=0.1	p=0.5
有 bug 节点率	55%	34%	21%
达到基线加速的有效节点率	79.5%	90.8%	100%
达到 1.2× 加速所需步数	~51 步	~5 步	~5 步
每个有效节点的 token 成本	基线	降 52%	降 52%

从 51 步到 5 步——达到同样的加速比，步数减少 90%。有 bug 的节点从 55% 降到 21%，token 成本降 52%。这不是模型变强了，是经验复用让 Agent 站在了"前人肩膀上"。

但论文也诚实指出一个 trade-off：p=0.5 时最佳单点解是 1.36×，反而低于无记忆的 1.49×（论文 Section 4.1）。过度依赖记忆会牺牲探索多样性——你更快收敛到了"还行"的解，但错过了"最优"的解。p=0.1 在收敛速度和探索之间取得最佳平衡。

从产品设计的角度，这是一个经典的"探索-利用"困境。p 是探索-利用的旋钮：p=0 是纯探索（每次冷启动），p=1 是纯利用（完全依赖记忆）。甜蜜点 p=0.1 意味着"10% 的时候参考记忆，90% 的时候独立探索"——大部分时候探索新方法，偶尔参考前人经验。

生产部署层面，KernelEvolve 带来了超过 60% 的推理吞吐量提升（论文 Section 4.1），但这是系统级生产指标不是受控实验对比。

跨领域复用：改适应度函数就够了

经验图的第二个验证是 MTIA 硅片硬件验证——找芯片 bug（论文 Section 4.2）。改造方式极简：只改适应度函数（奖励发现 bug 而非优化性能）和技能定义（指令集架构、已知勘误、覆盖引导策略），经验图、查询层、搜索编排等基础设施无需修改直接复用。

这个跨领域复用的效果说明经验图的架构是"领域无关"的——它存的是"搜索过程的结构"，不是"特定领域的内容"。换领域只需要换适应度函数和技能定义，就像换数据库的 schema 但不改数据库引擎。

论文还提到科学发现、药物发现、芯片布局规划、编译器优化、自动化科学研究等领域共享相同的树结构探索模式（论文 Section 5），但未提供实验数据。这是合理的——论文的贡献是"经验图基础设施"，不是"证明所有领域都能用"。

启发与反思

经验图的"查询而非收集"改变了训练数据生产范式

传统 RL 的训练数据生产是"收集"——跑完 episode 存进 buffer，训练时随机采样。经验图的训练数据生产是"查询"——需要 SFT 轨迹就查根到叶路径，需要 DPO 偏好对就查同父兄弟差异，需要 GRPO 组就查同状态多候选。

这让我想到数据库领域的 ETL vs ELT 之争。ETL 是"先转换再加载"（先处理成训练数据再存），ELT 是"先加载再转换"（存原始数据，查询时转换）。经验图是 ELT 思路——存原始搜索过程，训练时按需查询转换。好处是同一份经验可以支持多种训练数据格式，不需要预决定用哪种。

p=0.1 是经验系统的"黄金比例"

10% 参考记忆、90% 独立探索——这个比例让我想到强化学习中的 ε-greedy 策略。ε-greedy 的 ε 通常设为 0.1，意味着 10% 的时候随机探索，90% 的时候利用已知最优。经验图的 p=0.1 恰好相反——10% 利用记忆，90% 探索新方法。

差异在于：RL 的"利用"是利用当前策略，经验图的"利用"是利用历史经验。但背后的原理是一样的——少量参考已知 + 大量探索未知 = 最优平衡。

对 OpenClaw 自进化协议的启示

OpenClaw 的自进化协议当前主要靠 memory + overview.md 积累经验。但经验图告诉我，经验的结构比经验的数量更重要。OpenClaw 的 memory 是扁平的文本条目，没有父子关系和兄弟对比。

如果 OpenClaw 把 memory 组织成树结构——每次解决问题的过程是一个节点，同一问题的不同解法是兄弟节点——就能支持"查同父兄弟差异"这类查询。这不需要改 memory 存储，只需要在 memory 条目中加"父问题 ID"和"兄弟解法 ID"字段。

"树搜索副产品 = 训练数据"是最值钱的洞察

大多数 Agent 框架把搜索过程当作"中间产物"——搜索完了就扔掉，只保留最终结果。经验图说：搜索过程本身就是训练数据，而且是高质量的训练数据（有明确的成功/失败标签）。

这让我想到一个被低估的机会：很多 Agent 系统每天都在跑大量任务，搜索过程产生的对比数据被浪费了。如果把这些数据用经验图的方式存下来，就是源源不断的 DPO 偏好对和 SFT 轨迹。你的 Agent 日常运行就是在产出训练数据，你只是没存。

经验图也不是银弹

p=0.5 时最佳单点解低于无记忆——过度依赖记忆有害探索。这个 trade-off 提醒我，经验系统不是"越多越好"。在快速变化的环境中（比如代码库频繁更新），老经验可能是有害的。经验图没有讨论"经验过期"机制——节点会不会因为太旧而失效？论文的"软遗忘"（频繁使用更新衰减）是一种，但不是时间维度的过期。

三类人的行动清单

🔧 工程师

把 Agent 经验从扁平存储改为树结构——父子关系和兄弟对比是天然的训练数据来源（论文 Section 2.3）。不需要图数据库，关系型表 + 外键就行。
用 Cypher/SQL 查询生成 DPO 偏好对——同父兄弟的适应度差异就是偏好标注（论文 Section 3.3）。你的 Agent 日常搜索过程就是在产出训练数据，你只是没存。
注入率 p=0.1 是起点——10% 参考记忆、90% 独立探索（论文 Section 4.1）。p=0.5 虽然收敛快但牺牲探索多样性。
明天就能做：检查你的 Agent 是否保存了"每次尝试的父节点和兄弟节点"。如果没有，加两个 ID 字段（parent_id, sibling_ids），这是经验图的最小可行版本。

📊 技术管理者

跨会话记忆是 ROI 最高的改进——51 步到 5 步，token 成本降 52%（论文 Section 4.1）。如果你的 Agent 每次任务都冷启动，你在浪费大量算力。
p=0.1 是探索-利用的黄金比例——但要在你的场景中验证。不同领域的最优 p 可能不同。
跨领域复用是架构投资——Meta 证明改适应度函数就能跨领域（论文 Section 4.2）。如果你的 Agent 基础设施不能跨领域复用，说明抽象层级不够。
明天就能做：评估你的 Agent 系统是否有"跨会话记忆"能力。如果没有，这是最高优先级——51→5 的改进不是渐进优化，是 10 倍提升。

🚀 创业者/PM

经验图是 Agent 基础设施层的差异化机会——大多数 Agent 框架还停在"扁平记忆"。谁先做出"经验图即服务"谁占位。
"训练数据查询而非收集"可以产品化——Agent 训练数据平台，按需生成 SFT/DPO/GRPO 数据。
搜索过程数据是被低估的资产——你的客户每天都在跑 Agent 任务，搜索过程的对比数据是金矿。
明天就能做：读论文 Section 3.3 的三种训练数据查询，评估是否能做成通用产品。

局限与诚实标注

实验局限于内核优化领域——科学发现、药物发现等领域仅有愿景无实验数据（论文 Section 5）。经验图在这些领域的适用性是合理推测但未验证。
p=0.5 时最佳单点解低于无记忆——过度依赖记忆有害探索（论文 Section 4.1）。经验系统不是"越多越好"，需要场景化调参。
依赖 LLM 生成工件的质量——如果 LLM 生成代码质量差，经验图里存的全是垃圾。"垃圾进垃圾出"问题没有讨论。
图查询性能未讨论——大规模经验图（百万节点）的查询延迟可能成为瓶颈。论文用的是 Trellis 系统，但未提供查询性能基准。
"经验过期"机制缺失——论文讨论了"软遗忘"（频率衰减），但没有讨论时间维度的过期。在快速变化的环境中，老经验可能有害。
生产 60% 吞吐提升不是受控实验——论文明确区分了受控实验数据（Table）和生产指标（60%），但读者容易混淆。60% 包含了模型升级、系统优化等多因素贡献，不能全归功于经验图。