AFTER：评估 LLM Agent 程序性记忆的 382 个企业任务基准

关联论文：2606.23127
作者：spark
更新：2026-07-22

一句话结论

AFTER 是评估「程序性记忆（procedural memory）」在 LLM Agent 中的可迁移性基准：382 个真实企业任务 × 6 个专业角色 × 22 项程序性技能；关键发现是——程序性记忆确实在工业流程中稳定提升 3.7–6.7 分，但部分技能会退化为角色专属，迁移后失效；且多模型执行轨迹混合演化出的技能比任何单模型源都更可迁移（73.1% 跨模型精度）。

解决什么真问题

LLM Agent 在企业场景里越来越多地通过「程序性记忆 / Skills」机制提升效果——把过往成功执行的工作流沉淀成可复用的 skill（可调用的提示词模板 + 工具调用序列），下次遇到类似任务直接调用。

但「程序性记忆」这个机制在生产里问题很多：

能不能提升？ 短期看 skill 调用比裸 prompt 更好，但长期累积的 skill 池反而可能拖慢 Agent、稀释上下文。
能不能跨任务复用？ 一个 skill 在它「学出来」的那个任务上效果好，但放到相邻任务、跨角色场景、换模型后还管用吗？
如何演化？ skill 池要持续更新，应该用哪个模型生成的执行轨迹作为「教材」？是统一用一个模型，还是混合多模型？
怎么评估？ 没有公认基准，今天各家 benchmark 跑出来都是自吹自擂。

论文对四个问题都给了定量答案，并配套发布 AFTER benchmark（382 个任务 × 22 个 skill）。

更实际一点说，企业 Agent 平台最常见的一个困境是「上线第一周看效果很好，三个月后效果不知不觉掉了」——而根本原因之一就是 skill 池在持续增长，但没有任何机制保证新加的 skill 不会冲掉旧 skill 的价值，甚至引发「skill 间的互相冲突」（两个 skill 给出互相矛盾的工作流）。AFTER 的「跨任务 / 跨角色 / 跨模型」三维评估，正是为这类隐性退化提供了一个可量化的体检方法。

核心方法

AFTER benchmark 设计

任务量：382 个真实企业任务。
角色维度：6 个专业角色（⚠️ abstract 未明确列出具体名称，推测覆盖 HR、财务、IT、客服、销售、运营等典型企业职能，需查正文 §2 确认）。
技能维度：22 个 procedural skill（程序性技能，例如「起草离职沟通邮件」「生成差旅报销记录」「对比两份合同的差异」；⚠️ abstract 未明确 skill 选取标准，需查正文 §2.2）。
评估设置：4 套受控实验，分别衡量：
Local improvement（本地改进）：同一任务反复执行是否持续提升？
Cross-task transfer（跨任务迁移）：同一 skill 用于不同任务表现如何？
Cross-role transfer（跨角色迁移）：把为 HR 角色写的 skill 用到财务角色，是否仍有效？
Cross-model generalization（跨模型泛化）：用 GPT 类模型生成的 skill 放到 Claude / 开源模型上，是否仍有效？

程序性记忆的运作机制

+--------------------------------------------------+
|             Procedural Memory Bank              |
|  skill_1  skill_2  ...  skill_22                 |
+--------------------------------------------------+
            ^                ^
            |                |
   distill from execution traces
            |                |
+-----------+----------------+-----------------+
|            Agent execution trace pool          |
|   trace_A (gpt-4o)    trace_B (claude)        |
|   trace_C (qwen)      trace_D (llama)        |
+--------------------------------------------------+

执行：Agent 在解决任务时检索相关 skill 注入上下文，按 skill 流程执行。
学习：把成功完成的执行轨迹蒸馏、抽象、合并成新 skill 入库。
演化：不断用新轨迹更新已有 skill（精炼或重写）。

关键实验结果

本地改进稳定：一轮精炼让聚合性能提升 3.7–6.7 分（⚠️ 具体是哪个聚合指标【平均/中位数/P95】abstract 未说明，需查正文 §4.1）。
多模型混合优于单模型： - 从「多模型（GPT-4o + Claude + Qwen + Llama 等）执行轨迹混合演化出的 skill」拿到 73.1% 跨模型测试精度（⚠️ 测试模型族、测试任务子集 abstract 未明确，需查正文 §4.3）。 - 超过任何单模型源生成的 skill（具体对比数字 abstract 未明确给出）。
技能可迁移性两极分化： - 一类 skill：广泛跨任务、跨模型泛化。 - 另一类 skill：退化为「角色专属」，换任务/角色/模型后效果骤降。

原文 abstract 未对每类 skill 的具体名称与精度数值逐一列出，需查正文表格。

伪代码视角（procedural memory loop）

def run_with_procedural_memory(query, role, memory_bank):
    # 1. 检索相关 skill
    skills = memory_bank.retrieve(query, top_k=3, role=role)

    # 2. 注入 skill 到 prompt
    prompt = inject_skills(query, skills)

    # 3. Agent 执行 + 工具调用
    trace = agent.execute(prompt, tools)

    # 4. 成功后蒸馏/更新 skill 池
    if trace.success:
        memory_bank.update(
            role=role,
            new_trace=trace,
            merge_strategy='multi_model_distill'
        )
    return trace.answer


def evolve_skills(memory_bank, traces_per_model):
    # 多模型轨迹混合 → 提炼出更通用的 skill
    merged_traces = pool(traces_per_model)         # 合并多模型轨迹
    new_skills = distill(merged_traces)           # 抽象为 skill
    # 注：distill() 具体是 prompt 抽象、LLM 摘要还是 SFT，
    #    abstract 未明确，需查正文 §3 实现细节
    memory_bank.merge(new_skills, strategy='union')

关键实验与数据

基准规模：382 tasks × 6 roles × 22 skills（⚠️ role 与 skill 的具体分布需查正文 §2）。
本地改进：single refinement round → +3.7 到 +6.7 points（聚合性能；⚠️ 指标类型需查正文）。
跨模型泛化：multi-model-evolved skills → 73.1% 跨模型测试精度，优于所有单模型源（⚠️ 测试集与模型族需查正文 §4.3）。
可迁移性分化：部分 skill 广泛泛化，部分 skill 退化为角色专属（⚠️ 量化阈值需查正文表格）。
应用域：明确点出「industrial workflows / production agent platforms」，验证目标是企业部署而非学术 toy。

亮点与局限

亮点

首个面向「程序性记忆迁移性」的受控基准：之前所有 RAG / Tool-use benchmark 都只评估「一次任务完成率」，AFTER 是首个覆盖「跨任务 / 跨角色 / 跨模型」三维迁移的基准。
量化「技能分化」现象：用数据证明「有些 skill 真的会过度特化」——这对业界一味往 skill 池里塞东西的做法是个重要提醒。
多模型混合蒸馏的硬证据：73.1% 跨模型精度强烈支持「不要把所有 skill 都基于一个模型」，给工程团队一个明确反直觉的最佳实践。
面向企业真实场景：382 个 enterprise task 不是合成的 toy benchmark，对真实部署有直接参考价值。
结果对 Agent 架构选型友好：给出了「本地」「跨任务」「跨角色」「跨模型」四个量级递进的评估场景，可以根据产品复杂度逐步引入。

局限

benchmark 静态：382 个任务一旦发布就有过期风险，特别是面向企业工作流时，制度、工具、行业规范变化会让部分 skill 失效。
skill 抽象 / 蒸馏的具体方法 abstract 未明确：是用 prompt 抽象、是用 LLM 摘要、还是某种 SFT？影响可复现性。
22 个 skill 的覆盖度未知：相对企业里成百上千的常规工作流，22 个 skill 是显著不足的样本；abstract 未明确 skill 是如何选取的。
角色与任务的分布偏差：6 个 role 是否覆盖足够均匀（IT 多 / HR 少会怎样）abstract 未明确。
没有给出 skill 池规模化的策略：当 skill 数从 22 涨到 200 / 2000 时，检索精度、上下文窗口、Agent 决策负担如何变化，本文未明确。
评测协议细节缺失：cross-model test 的具体测试模型族、测试任务数 abstract 未明确。
人工评估成本高：跨角色、跨模型评估本身需要多套环境与多个人类专家对结果进行 label，工业复现门槛不低。

工程落地与核查（Jay）

坑一：skill 蒸馏的实现路径不明确，工程选型风险高

abstract 没有说明 distill() 是用 prompt 抽象、LLM 摘要还是 SFT 训练三种路径，这直接影响工程实现：

Prompt 抽象路径：成本最低，但依赖 LLM 的 summarization 质量，且每次新任务都要重新抽象，累积多次后 skill 可能变得模糊。
SFT 微调路径：质量最高，但每次蒸馏都要准备训练数据、管理微调版本，且 skill 池一大，版本管理就是噩梦。
实际工程建议：先用 prompt 抽象做快速迭代，等 skill 验证有效后再 SFT 固化。避免在未验证的 skill 上过早投入微调资源。

坑二：skill 检索是规模化后的隐性瓶颈

22 个 skill 时尚可暴力检索，企业实际部署到 200+ skill 后：

检索延迟：top_k=3 的向量检索在 200 skill 上约 5–10ms，感知不强；但加上 skill 的 prompt 注入后，上下文膨胀导致的首次 token 延迟才是主要矛盾。
Skill 冲突检测：当两个 skill 描述相似但行为矛盾时（如「合同对比流程」vs「合同审查流程」），没有自动检测机制。需要为每个 skill 维护「互斥 skill 列表」，并在检索阶段做冲突过滤。
工程建议：在 memory_bank.update() 里加一个「相似度阈值检查」，超过阈值就触发 skill 合并或互斥标记，而不是直接入库。

坑三：cross-model 泛化 73.1% 是上界，不是日常保证

73.1% 是在「多模型轨迹混合演化」后的 skill 上测出来的，对应的是「精心混合多模型执行轨迹」这个最优路径。实际工程中：

如果团队只用 GPT-4o 生成所有轨迹，cross-model 精度会显著低于 73.1%。
不同模型版本（如 gpt-4o-2024-05 vs gpt-4o-2024-08）也属于「cross-model」，内部升级也要重测。
工程建议：把 cross-model 精度作为 skill 的元属性公开，每次模型升级时重新跑一遍 cross-model 评估，不达标的 skill 要降级为「单模型专属」并加标签。

坑四：角色专属 skill 的识别和隔离需要产品层支持

当一个 skill 被标记为「角色专属」后，工程上需要防止误调用：

跨角色调用时，Agent 层面应该有警告或阻断机制，而不是静默降级。
「角色专属」不等于「坏 skill」——同一个业务里 HR 和财务对「入职流程」的需求本来就不同，不能强制合并。
工程建议：skill 的 role 属性应该是「推荐」而非「强制」，通过置信度分数而非硬阻断来控制跨角色使用。

坑五：benchmark 的静态性与企业业务变化的矛盾

382 个任务在发布时代表「真实企业场景」，但企业工作流会随组织架构调整、工具升级（如 ERP 换代）而变化：

上线后 6–12 个月：部分 skill 对应的任务描述可能仍然正确，但预期输出格式已经过时（如「新员工入职 checklist」的任务在系统换代会后内容变了）。
工程建议：把 benchmark 任务集作为 skill 的「回归测试集」，每次业务大版本升级时跑一次 skill 池的全量回归，不通过的 skill 要么更新要么下架。

核查清单（工程团队引入 AFTER 时）

检查项	操作
Skill 蒸馏路径选型	确认是用 prompt 抽象、LLM 摘要还是 SFT，记录在 skill 元数据
冲突检测机制	每次 skill 入库前跑相似度检查，超阈值进入合并流程
cross-model 精度监控	作为 skill 元属性，每次模型升级时重新评估
角色专属标记	用标签而非硬阻断，留出跨角色调用的置信度路由空间
定期回归	业务大版本变更时，用 benchmark 任务集做 skill 池回归

与同方向工作的关系

Voyager / Generative Agents：早期把「技能库」概念引入 LLM Agent 的工作（游戏 / 社交模拟），AFTER 是把这一范式搬到企业场景的严肃基准。
DSPy / LangChain Memory / Mem0：工业 Agent 框架里的程序性 / 情节性记忆实现，AFTER 给这些实现提供评估标准。
ToolBench / API-Bank / Gorilla：评估 LLM 调用工具能力的 benchmark，主要测「一次性调用准确性」，AFTER 测「跨任务 / 跨角色 / 跨模型复用性」。
AgentBench / SWE-Bench：评估 Agent 综合能力的代表性 benchmark，与 AFTER 互补。
Self-RAG / Corrective RAG：评估 RAG 反思 / 修正能力，与 AFTER 的 skill 演化在「持续学习」思路上相近。
Multi-model ensemble / model merging：模型层面的多源融合工作，本文在 skill / prompt 层面给出与之平行的结论。

适合谁读

企业 Agent 平台架构师：必读。skill 池的设计、演化、淘汰策略直接关系到平台长期价值。
RAG / Tool-use / Agent 框架作者：AFTER 可作为新框架的评测基线之一。
AI 产品经理：把 +3.7 分、73.1% 跨模型精度等数字翻译给业务方，作为平台投入 ROI 的论据。
持续学习 / 终身学习研究者：AFTER 给「程序性记忆」这一长期被忽视的子领域提供了评测抓手。
多模型策略研究者：73.1% 的结论对「为什么要用多模型」给了一个非传统的实证支撑。

不确定处（标注）

6 个 professional role 与 22 个 procedural skill 的具体名称与分布 abstract 未明确。
skill 抽象 / 蒸馏的具体算法（prompt / SFT / embedding clustering）abstract 未明确。
73.1% 是哪一类测试集 / 哪一组测试模型上的精度 abstract 未明确。
benchmark 是否开源 / 是否提供 replay 工具 abstract 未明确。
在更大 skill 池（>100）下的检索与决策负担变化 abstract 未明确。
本地改进的 +3.7–6.7 points 具体对应哪个聚合指标 abstract 未说明。

一句话总结

程序性记忆是 Agent 平台的关键资产，但也是最容易「隐性退化」的部件；AFTER 用 382 个真实任务 + 多维迁移评估，把这个过去仅凭直觉管理的机制变成了可量化的工程对象。