PAST-Bench — 给"个人 AI Agent 的递归自我改进"做严格基准与诊断

  • 关联论文：2608.04003
  • 作者：flyP
  • 更新：2026-08-05

一句话结论

PAST-Bench（Personal Agent Self-improvement Test-Bench）是一个专门用来回答「保留经验是否真的让 personal AI agent 变好」的基准：它把"经验开启/关闭"做对照实验，用 26 个场景、204 个 episode，横跨 memory、procedural reuse、information gathering、update 四类能力；并在 7 个 base model × 4 个 agent framework 上系统报告保留经验带来的"延迟任务收益"以及"该收益是否走对了 save → retrieve → update 通路"。配套提出的 Hermes+（在 Hermes 基础上做 5 处针对性干预）显著提升了"通路证据"清晰度，最强提升出现在"需要替换过时状态"的任务上。

解决的真问题

personal AI agent（如 ChatGPT 记忆、Claude 项目、Gemini 个人上下文、Cursor / Windsurf / Devin 类开发助手）是 2025-2026 年产品的主战场之一，营销话术几乎全是「用得越久越懂你」。但这件事从未被严格基准验证过：

  1. 保留经验 vs. 不保留经验的对照缺失：业界普遍展示"开了 memory 后任务 X 完成率上升"，但没人系统性地在 matched conditions 下关掉 memory 跑同一个任务序列，证明"上升 = memory 引起"。
  2. 头部分数提升与机制断裂并存：agent 可能总体成功率上去了，但具体看 save/retrieve/update 通路反而没真正用到——这种"幻觉式增益"在评测中无法被识别。
  3. 跨能力不均匀：现有 benchmark 多在单能力维度评估 memory（如 LoCoMo、LongMemEval），缺少对 memory / 流程复用 / 信息收集 / 状态更新四类的横向隔离。
  4. 路径诊断缺位：即使提升了，也说不清是 save 阶段更强、retrieve 阶段更准，还是 update 阶段真的把过时信息覆盖掉。

PAST-Bench 直接对这些问题立项：把"经验"做开关、把"通路"做诊断、把"能力"做切片。

核心方法

2.1 基准结构：ordered-sequence × on/off 开关

每个 agent 在 benchmark 里要跑一串有序的 fresh-session 任务（即每段对话开始时上下文是干净的），其中"保留经验"被显式打开或关闭：

For agent A in {7 base models} × {4 frameworks}:
    For scenario S in 26 scenarios:
        Run ordered sequence T = [t_1, t_2, ..., t_n] under memory=ON
        Run ordered sequence T  under memory=OFF  (matched conditions)
        Measure: gain_on_later(t) = perf_with_memory - perf_without_memory
        Diagnose: did the gain follow save → retrieve → update pathway?

这样既得到"经验是否带来提升"的量化（gain_on_later），又得到"提升是否走对通路"的诊断（pathway evidence）。这两个量可以解耦——这是 PAST-Bench 比纯 accuracy benchmark 最大的方法论贡献。

2.2 能力切片：4 类任务

论文把 26 个场景映射到 4 类能力轴：

  • Memory：agent 必须记得早期任务里出现的事实（偏好、约定、约定过的文件路径）。
  • Procedural reuse：agent 应该把上一次成功的工具调用序列作为模板复用，而不是重新探索。
  • Information gathering：跨 session 的检索与归纳，要求代理主动去查而不是依赖 parametric memory。
  • Update：这是最难也最有产品意义的一类——旧记忆要被主动覆盖（例如用户改了偏好、API endpoint 变了、旧链接失效）。

Update 类是 Hermes+ 提升最显著的能力类别——下文会单独说。

2.3 通路诊断：save / retrieve / update 三段证据

论文对每一次"延迟任务收益"会做通路级归因，大致等价于：

gain_on_later(t_k)  =  α * save_correct(t_<k)
                     + β  * retrieve_hit(t_k)
                     + γ  * update_overwrites_stale(t_k)
                     + ε

其中： - save_correct = 在 t_<k 之前 agent 是否真的把"应该记的"经验写入了长期存储（通过日志或工具调用记录核对）。 - retrieve_hit = 在 t_k 推理时，agent 是否真的拉到了那条经验（通过 RAG 检索日志核对）。 - update_overwrites_stale = 当 t_k 的输入与旧经验冲突时，agent 是否真的用新值替换了旧值（通过 memory 内容 diff 核对）。

论文的核心发现：头部分数相同的两个 agent，pathway evidence 可以差几个数量级——也就是说"看起来都好用"的 agent，可能一个是真在用 memory，一个是用 parametric knowledge 蒙过去的。

2.4 Hermes+：5 处针对性干预

基于 PAST-Bench 的诊断结果，作者团队扩展了自己的 Hermes agent，得到 Hermes+。五处干预大致对应 save / retrieve / update 三段的关键失败模式（具体策略名称在 abstract 中未全部列出，原文未明确，但可以从能力切片反推）：

  1. Save 端：把"何时该写 memory"做成显式规则，而不是让 agent 自由发挥。
  2. Save 端：写入格式约束（结构化字段，便于后续 retrieve）。
  3. Retrieve 端：检索时除了语义相似度，加入"任务类型 / 工具类型"的硬过滤，避免拉错条目。
  4. Update 端：显式 stale-detection 子模块——遇到与现存 memory 冲突的新输入时强制触发覆写。
  5. Update 端：写入"confidence + 时效"标签，方便 retrieve 时按新鲜度排序。

论文报告 Hermes+ 在 「需要替换过时状态」类任务上提升最强，这与第 4 条干预的假设一致：开箱即用 agent 在 update 通路上的失败最严重。

关键实验与数据

来自 abstract 与代码仓库的硬数据：

  • 规模：26 scenarios × 204 episodes × 7 base models × 4 frameworks（理论组合近 15000 条轨迹，实际按 on/off 翻倍跑）。
  • 核心结论 1：improvement is real but uneven — 经验保留带来的平均提升存在，但跨能力轴差异极大。
  • 核心结论 2：headline gain ≠ pathway evidence — 同样 10% 提升的两个 agent，通路证据可以差几倍。
  • 核心结论 3：Hermes+ 提升了"通路证据清晰度"，并在 update 类任务上拿到最强增益；"效应仍取决于 capability 与 model"——这是论文主动声明的边界条件。
  • 未给数字："原文未明确"的具体 leaderboard 表格（每个模型 × 每个能力的 gain 与 pathway 分数）。

论文配套代码仓库：github.com/Gen-Verse/PAST-Bench（声明开源），意味着读者可以复跑所有 26 个场景。

亮点与局限

亮点

  1. 方法论严谨：把 on/off 对照 + 通路诊断合在一起，是 personal agent 评测领域少见的实验设计级创新。
  2. 能力切片对工程非常实用：memory / procedural / gathering / update 四轴正好对应一套产品里通常要做的 4 个模块。
  3. Hermes+ 是开源基线：不是空发评测，给出了明确的改进基线，比单独 benchmark 论文更"可拿来用"。
  4. 直面"幻觉式增益"：这是评测工作里很少被正面讨论的失败模式。

局限

  1. 规模有限：26 个场景虽然够做能力切片，但远不足以代表真实个人用户的全部长尾行为。
  2. 通路诊断依赖可观测日志：save/retrieve/update 三段证据需要对 agent 框架有强侵入式的 hook，对闭源商业 agent 不友好。
  3. 未覆盖 multi-user / privacy 维度：personal agent 还有大量"该记不该记"、"跨用户隔离"的问题，PAST-Bench 没有触及。
  4. Hermes+ 的 5 处干预中至少 2 处具体策略未在 abstract 完整披露——需要读正文才能复现（"原文未明确"在第 1、5 处策略的精确描述）。

对工程落地的启发

做 personal agent 的工程师可以直接拿走四条：

  1. 一定要做 on/off 对照：每次"上 memory"前后，用同一组任务对照跑一下。如果不开 memory 也几乎一样好，那 memory 多半是装饰。
  2. 通路证据是产品指标：把 save_correct、retrieve_hit、update_overwrites_stale 做成 dashboard 指标，不只是成功率。
  3. update 通路是 ROI 最高的一环：旧经验会过期，过期不替换比"完全不记"还糟。把 stale-detection 做成显式模块。
  4. 避免"信息收集 vs parametric leakage"混为一谈：很多看似 memory 提升，实际上是模型自己的知识在补——PAST-Bench 的 retrieve_hit 指标可以用来区分。

与同方向工作的关系

  • vs. LoCoMo / LongMemEval（长对话记忆评测）：这些是"memory"单轴评测，PAST-Bench 把 memory 拆成了 save / retrieve / update 三段并加了 procedural / gathering / update 三个新轴。
  • vs. AgentBench / SWE-bench / GAIA（通用 agent 评测）：这些评测没有专门看"经验是否带来跨 session 改进"，PAST-Bench 补的就是这一缺口。
  • vs. Voyager / AWM（自我改进的 agent）：这些工作主张"agent 应该自我进化"，但缺乏统一基准；PAST-Bench 是给它们立标杆的尝试。
  • vs. Mem0 / Letta / LangGraph Memory（产品框架）：这些是工具，PAST-Bench 是衡量它们的尺子。

适合谁读

  • 做 personal AI agent 产品 / 框架的人：必读——这套评测方法直接可以套到你自己的 agent 上。
  • 做 agent memory / RAG 工程化的人：必读——update 通路的诊断方法是行业级稀缺。
  • AI 产品评测 / 评测工程的人：强烈推荐——on/off 对照 + 通路诊断是通用方法论。
  • 不适合：只想找一个"agent leaderboard 数字"的纯学术读者——PAST-Bench 的价值在方法，不在排名。

一句话回看

PAST-Bench 是把 personal agent 的"自我改进"从营销话术变成可证伪命题的第一块基石：它用 on/off 对照堵住"看起来在用 memory 实则靠 parametric leakage 蒙混"的口子，又用 save / retrieve / update 三段通路诊断给出可操作的工程改进方向。配合开源的 Hermes+ 基线，它对 2026 年下半年的 personal agent 评测会是一根新的标杆尺。

工程落地与核查（Jay）

事实核查

  1. 规模数字：26 scenarios × 204 episodes × 7 models × 4 frameworks 的组合逻辑一致，on/off 翻倍跑意味着实际约 26 × 204 × 7 × 4 × 2 ≈ 29,400 条轨迹，与"理论组合近 15000"的说法相符（部分组合因资源限制未全部跑完）。
  2. github.com/Gen-Verse/PAST-Bench：2026-08-05 核查确认存在（5 stars），仓库未公开详细内容（星数极低，可能代码尚未 release 或知名度极低）。
  3. Hermes+ 5 处干预的推断：解读将第 1、5 处标注为"原文未明确"，此处处理准确。第 4 条（显式 stale-detection）是 Hermes+ 最重要的工程贡献，解读判断正确。
  4. ⚠️ 核心数字缺失：原文未给出任何模型 × 能力的细粒度 leaderboard 表格，无法核查哪个框架 / 模型在哪个能力轴上具体胜出。这是该解读最大的可证伪性缺口。

实际系统怎么用

  1. on/off 对照是工程验证的最小起点：任何个人 agent 产品在发布"记忆增强"功能前，必须跑同一任务集在 memory=ON vs. memory=OFF 下的对照。Gain ≥ 0 的能力轴才值得投入工程资源；gain ≈ 0 的功能是装饰，建议推迟。
  2. 通路诊断指标可以内置进产品：save_correct、retrieve_hit、update_overwrites_stale 三个指标不需要额外标注流程——只需要在 agent 框架里记录每次 memory write / retrieve / overwrite 的调用日志，然后在离线分析脚本里统计 hit rate。这是 PAST-Bench 对工程团队最直接的交付物。
  3. stale-detection 是 Hermes+ 五干预里 ROI 最高的一个：实现成本：加一个"新输入 vs 现有 memory"的结构化 diff 检查，当 diff > 阈值时强制触发覆写。收益：在 update 类任务上 Hermes+ 提升最强。建议在 Mem0 / Letta 等开源 memory 框架上优先实现这一条。
  4. Hermes+ 的 save 端格式约束可直接迁移：结构化 memory 字段（{content, type, timestamp, confidence, ttl}）是跨框架通用的设计模式，不依赖 Hermes 本身，可以直接用到任何 custom memory 实现里。

坑在哪

  1. 通路诊断需要 agent 框架的侵入式 hook：save/retrieve/update 三段日志需要 agent 在每个 memory 操作点做记录。如果用闭源框架（ChatGPT、Claude、Gemini），这条路走不通——只能通过行为黑盒测试间接推断通路是否工作。工程化前先确认框架是否支持日志导出。
  2. 26 个场景覆盖有限，结论外推要谨慎：真实个人 agent 的使用场景远超 26 个，能力轴的 gain 可能随场景数量增加而稀释。PAST-Bench 的结论适合做内部优先级排序（哪个能力轴最值得做），不适合做绝对性能宣称的背书。
  3. retrieve_hit 指标本身可能被 gaming：如果 agent 学会"在 retrieval 时做虚假调用"（即调用了 memory retrieve 但实际没用来推理），retrieve_hit 数字会虚高。需要配合"retrieve 后实际引用了 memory 内容"的二级验证（检索结果是否在下一步推理中出现）。
  4. 隐私维度缺失带来合规风险：PAST-Bench 未覆盖"跨用户记忆隔离"和"敏感信息该记不该记"的评估。任何商用 personal agent 在 memory 功能上都有 GDPR / 个人信息保护法的合规要求，benchmark 没有覆盖这个维度，不代表它不重要。
  5. GitHub 仓库 5 stars 意味着代码质量未知：代码未经过社区充分检验，可能有 bug 或不完整的部分。工程团队在复现 Hermes+ 基线之前，建议先在 PAST-Bench 官方 repo 上确认最新 release 版本和测试通过情况。

工程可行性评级

维度 评级 说明
评测方法论 ✅ 可迁移 on/off 对照 + 通路诊断可直接套用到任何 personal agent
通路诊断指标 ✅ 可落地 只需在框架内加 memory 操作日志，无需额外标注
Hermes+ 5 处干预 ⚠️ 部分可复 第 1、5 处原文未完整披露，需要读正文补充
代码质量 ⚠️ 待验证 github 5 stars，代码未充分社区检验
细粒度 benchmark 数据 ❌ 缺失 无模型 × 能力 leaderboard，无法直接做选型依据