经验资产化：工件锚点记忆与 Skill 市场效用实证 两论文精读

论文一链接：ExperienceIndex: Artifact-Grounded Memory 论文一机构：MIT（一作 Peter Baile Chen 及 4 位作者）+ McKinsey & Company（咨询视角的企业场景）+ Oracle AI & UPenn（Dan Roth）+ AI2（Doug Downey）。典型的"高校主导 + 咨询/数据库/研究机构多边合作"：MIT 负责方法与系统，McKinsey 带来法律/咨询等知识密集行业需求，Oracle/Penn 与 AI2 提供信息检索与科学文献方向的资深合作者。 论文二链接：An Empirical Study of Agent Skills’ Downstream Utility 论文二材料仓库：anonymous.4open.science/r/skill_utility-D2C6（数据/脚本/执行记录，匿名评审仓库） 发表时间：均为 2026 年 10 月 论文二机构：浙江大学（一作 Yu Cheng 及 3 位作者，通讯 Xiaoxue Ren）+ 江西师范大学（1 位）+ CSIRO’s Data61（澳大利亚国立科研机构，Zhenchang Xing）。浙大主导实证设计与分析，Data61 提供软件工程方向的合作者。 领域标签：cs.CL / cs.AI，Agent 记忆、经验复用、Skill 工程

一、论文背景

1.1 Agent 的"经验"从哪里来，又存在哪里

LLM Agent 正在从"一次性助手"变成"长期驻任的数字员工"：它们反复处理同一批客户文档、同一个代码库、同一批数据表。人在这种岗位上会自然沉淀两类资产：一类是对具体物件的经验——“这张表只覆盖 2018-2019 年的价格”、“那份税单里根本没提 Delaware”；另一类是对做事方法的经验——“处理这类请求先用整数规划建模”。前者是关于工件（artifact）的知识，后者是程序性知识。

一个直观的类比：律所的新律师第一年做尽调要翻遍资料室，第五年则直接走到那几个档案柜前——因为他记得"并购条款的先例都在 B 区 3 柜"、“2020 年前的税务函件不用看”。资深律师的价值不在"更会搜索"，而在"知道东西在哪、哪些不用看"。Agent 记忆系统想复制的就是这种资产。

今天的 Agent 记忆系统几乎都在存后者。以 ReasoningBank（Google，ICLR 2026）为代表的"抽象记忆"路线，从过往推理轨迹中蒸馏可泛化的推理策略，新任务到来时检索相似任务的经验注入提示。以 Mem0、OpenAI Memory 为代表的"画像记忆"路线，则存用户偏好与事实属性（生日、座位偏好）。这两条路线有一个共同的盲区：它们都不存"这个工件覆盖什么、和那个工件怎么连"这类工件级知识。结果是 Agent 每遇到一个新任务，仍要对语料做多轮试错搜索——它可能记得"怎么搜"，却不记得"上次搜到过什么"。

1.2 另一边：Skill 市场繁荣但效用存疑

与记忆路线并行的是 Agent Skill 生态。一个 Skill 是打包好的程序性指导：一个 SKILL.md 文件（YAML 元数据 + Markdown 正文）加上可选的脚本、参考资料。Claude Code、OpenClaw 等平台都有公开市场，claude-plugins.dev 与 ClawHub 两家加起来超过 12 万条记录。开发者可以像装 npm 包一样给 Agent 装第三方"岗位操作手册"。

但"装了相关的手册"不等于"活干得更好"。此前 SkillsBench 的评估就发现 Skill 有时提升通过率、有时无效、有时反而降低。SWE-Skills-Bench 在真实软件仓库里报告了有限的增益和与项目上下文冲突引起的回退；Skill-Use 则发现同一模型在不同 harness 里使用 Skill 的行为本身就不一样。缺的是一个解释框架：Skill 的效用到底取决于什么——是内容写得好不好？是模型/harness 组合能不能执行？还是多个 Skill 之间怎么组织？这就是第二篇论文要回答的问题。

值得注意的是"配置（model–harness configuration）“这个概念：模型生成动作决策，harness（如 Codex、OpenCode、OpenClaw）管理上下文、工具调用与执行控制。同一份 Skill 交给"GPT+Codex"和"Qwen+OpenCode”，实际是两个不同的执行者。此前的研究要么只换模型、要么只换 harness，把两者当作独立因素；而这篇论文的核心实验单位就是"模型×harness"的组合，这直接决定了它能看到前人看不到的现象。

1.3 两篇论文的共同问题

把两篇放在一起读会发现它们在问同一件事：经验/技能作为一种可复用资产，它的价值锚点应该放在哪里？ ExperienceIndex 的答案是"锚在工件上"；Skill 效用实证的答案是"锚在原子操作与工件依赖上，而不是主题相关性上"。两者合起来，构成了对"经验资产化"这个方向的一次完整检查：一篇从供给端（怎么存经验）动手，一篇从消费端（怎么选与组织技能）动手。

时间线上这两篇也恰好互补：ExperienceIndex 于 2026 年 10 月 7 日提交（cs.CL），Skill 实证于 10 月 6 日提交（cs.AI），同周出现、互不知晓对方，却分别从记忆与 Skill 两个社区收敛到"工件/操作粒度"这个答案——这种独立收敛本身就是一个强信号，说明行业正在越过"要不要给 Agent 加经验"的阶段，进入"经验以什么粒度表示才可复用"的深水区。

二、论文定位和关联工作

2.1 ExperienceIndex 所在的谱系

画像记忆（profile-based memory）：Mem0、OpenAI Memory 等以用户为锚点，存偏好与事实属性，主要服务对话历史类任务。ExperienceIndex 明确把自己与之区分：锚点是工件而非用户，因此适用于法律案例库、代码库、科学文献等非对话语料。

抽象记忆（abstracted memory）：ReasoningBank、Dynamic Cheatsheet、Log-augmented Generation 等从轨迹蒸馏推理模式或可复用计算。论文对它的定位是"互补而非竞争"：抽象策略解决"怎么推理"，工件经验解决"去哪找料"。

离线语料增强（offline enrichment）：EnrichIndex、GraphRAG、doc2query 等在离线阶段用 LLM 给语料中每个工件生成摘要/QA 对/图结构再增强检索。三个固有缺陷：(i) 标注时看不到下游任务，收益受限；(ii) 每个工件都要预处理的巨额前置成本；(iii) 假设能拿到全语料——对 Semantic Scholar 这种 2.38 亿论文的在线库不可行。ExperienceIndex 反其道行之：只从实际执行过的任务轨迹增量提取，成本随已解任务数而非语料规模增长。

2.2 Skill 效用实证所在的谱系

内容分析类：Hong 等对 SKILL.md 做语义组件分解并定义"Skill 坏味道"；Wu 等研究下游适配中的修改模式。它们说清了 Skill 里"有什么"，但没验证这些内容是否真能提升任务完成。

基准评估类：SkillsBench（87 任务 + 确定性验证器 + 配对评估）、SWE-Skills-Bench、Skill-Use。它们测出了"有没有效"，但止步于结果差异，不解释为什么。本文直接在 SkillsBench 上做深挖。

结构化表示类：SkVM 把 Skill 分解为原语能力并评估配置支持度、SkillDAG 用类型化边表示依赖、GraSP 建前后件图、AgentSkillOS 用能力树 + DAG 组织。这些工作提供了"操作分解"的思想，本文借用其表示方法做重排，但执行时保持 Skill 原文，避免混淆"表示"与"内容"的贡献。

本文的定位：填补"内容分析"与"性能评估"之间的解释缺口——通过同任务同配置下的受控对比 + 轨迹证据，把效用差异归因到内容、配置匹配、组织方式三个因素上。这是 ICSE 风格的实证软件工程研究进入 Agent Skill 领域的代表作。

2.3 合读视角下的定位

两篇互为镜像：第一篇说"存的时候要锚在工件上"，第二篇说"用的时候要按操作匹配、按工件依赖组织"。它们共同把"经验资产"从模糊概念拆解成了可工程化的两个接口。

三、问题定义

3.1 ExperienceIndex：把"找齐工件"抽象为经验检索问题

具体场景：Agent 在共享语料（法律案例、代码库、表格）上反复解题，每个新任务都要重新摸索哪些工件相关。这个摸索过程错误率高（漏掉邻居工件导致答案不完整）且昂贵（多轮搜索大量 token）。

核心洞察：任务成败取决于搜到的工件集是否相关且完整。这两个性质恰好可以由两类以工件为锚的经验分别保障——单工件经验管"相关性"（这个工件对新任务有没有用），工件对经验管"完整性"（这个工件的邻居还有谁需要一起看）。

形式化：给定工件语料 C（<artifact_id, artifact_content> 对）、任务流 T、求解模型 M 与搜索框架 R，在求解过程的关键节点（系统提示注入、搜索结果返回）检索并注入以 artifact_id 索引的经验，目标是在一次检索内最大化相关工件集的召回与精度，同时最小化在线成本；经验库本身只从已执行任务的推理轨迹增量构建。

这个抽象的精妙之处在于把记忆的键从"任务相似度"换成了"工件标识"：任务千变万化，但同一语料上反复出现的工件是稳定的实体。键稳定，检索才可增量、可积累。另一个精妙之处是它对"经验"的切分方式：不是按任务切（一个任务一条经验），而是按工件切（一个工件积累多条经验）。按任务切的经验只在同类任务重现时有用；按工件切的经验在任何触及该工件的新任务中都有用——这就是后面"Spider 的 SQL 经验能服务 MMQA 问答"这种跨任务泛化的结构基础。

3.2 Skill 效用：把"选 Skill"抽象为操作覆盖匹配问题

具体场景：开发者面对一个任务，从市场检索出几个主题相关的 Skill，不知道装哪个、怎么组织。

核心洞察：任务需求与 Skill 流程都可分解为原子操作——作用于具体对象、有可识别输出的基本单元。Skill 的效用不取决于主题匹配，而取决于它覆盖了任务所需的哪些原子操作、还缺哪些要 Agent 自己补。

形式化：下游效用定义为同任务同配置下相对 No-Skill 的通过率差 Δ_c(x;T) = P_c(x;T) − P_c(No-Skill;T)。对候选 Skill s 与任务 t 的原子操作集 O_t，逐操作判定支持等级（Full=1 / Partial=0.5 / Absent=0 / Conflicting=−1），得分 Match(t,s) = (N_F + 0.5·N_P − N_C) / |O_t|，按得分重排候选。多 Skill 场景则在固定 Skill 集上比较 Flat / Sequence / Stage Plan / Dependency DAG 四种组织。

这个抽象的精妙之处在于把"相关性"这个模糊的语义判断换成了可计算的覆盖函数：Conflicting 记负分尤其关键——一个与任务约束冲突的步骤比缺失更糟。另一个常被忽略的细节是"绑定即支持"的判定标准：只有"任务参数绑定后即可执行"的操作才算 Full 支持，需要 Agent 再补实质逻辑的只算 Partial——这个区分正是 lab-unit-harmonization 案例里 M1 与 M2 命运分岔的形式化表达。至于组织问题，DAG 方案的节点是"一次 Skill 使用"而非 Skill 本身（同一 Skill 可多次出现在图中），边上是"前置依赖 + 传递的工件"，这使它天然能表达"OCR 文本先落盘、字段抽取依赖落盘文本、工作簿生成依赖字段文件"这类流水线结构。

3.3 两个抽象的深层呼应

把两个形式化并排看，有一个漂亮的对应：ExpIdx 的工件对经验（“sales2 与 costs1.pdf 经 Delaware 关联”）与 RQ3 的 DAG（“xlsx 节点依赖 image-ocr 产出的文本文件”）都是以工件为节点的图结构。区别只在一个长在记忆库里供检索，一个写在组织指令里供执行。这暗示了一个统一视角：无论经验来自 Agent 自己的轨迹还是第三方的 Skill 包，让它可复用的关键表示都是"工件 + 工件间依赖"。第六部分会回到这个呼应。

四、问题解法

4.1 ExperienceIndex：三层架构的中间件

可以把 ExpIdx 理解为给任意 Agent 搜索栈外挂了一个"老员工笔记本"，它分三层工作：

（1）经验表示——两类笔记。单工件经验记录三元组：任务描述（这个工件曾被用于什么任务）+ 贡献摘要（它怎么帮上忙的，如"sales1 含 2018-2019 产品价格"）+ 片段（实际用到的部分，附行号定位）。工件对经验记录结构关系：文档与表可经重叠实体连接（“sales2 与 costs1.pdf 经 Delaware 关联”），两表之间则是可 join 列。类比数据库的"数据字典 + 外键图"：前者描述列含义，后者描述表间结构。

（2）经验检索——双通道。查询通道：把新任务描述用 Qwen3-8B-Embedding 嵌入，与历史经验的"任务描述+贡献摘要"组合相似度匹配取 top-k；工件通道：当搜索框架返回一批 artifact_id 时，针对每个 id 取其关联经验再选 top-k。两路并集形成候选工件集，再用一个轻量 LLM（默认 GPT-5-Mini）做相关性判定（relevant / irrelevant / inconclusive），剪掉无关的，对判为相关的工件继续查其工件对经验、把邻居工件主动引入并同样过一遍相关性判定。

这里有个容易被忽略的设计细节：为什么需要 artifact_id 条件通道？因为查询语义相似不等于工件相关——任务 2 问的是"营收与公司税"，单看查询你不知道该引入哪张表；但搜索框架先按查询返回了 sales15（覆盖 California），沿着这个 artifact_id 查经验才能发现"sales15 与哪些表有关联"。查询通道负责"从问题出发"，工件通道负责"从已发现的线索顺藤摸瓜"，两路缺一不可。

（3）经验注入——改两处上下文。一是拦截搜索框架输出：无关工件被移除、相关工件（含新引入的邻居）附带经验片段注入工具返回；二是注入系统提示：任务开始前就把相关经验放进 system prompt，让模型在大量推理之前就拿到先验。注入时附一个轻量反思步骤，要求模型（a）自行判断经验是否适用于当前任务，（b）以当前工件内容为准校验经验——防止幻觉或过时经验污染推理。

为什么两处都改？论文的论证是：模型运行时真正"可变且默认无经验感知"的非参数组件只有这两个——搜索框架的输出和模型提示上下文。系统提示注入提供"事前引导"（避免模型在拿到好经验之前就已走入次优推理路径），工具输出改写提供"事中纠偏"（每一轮搜索结果都被经验过滤与增强）。这种基于"运行时可变组件盘点"的注入点选择，是整个中间件设计里最值得学习的工程判断。

（4）经验提取与索引（离线增量）。任务完成后，把内部推理、思考轨迹与最终答案（含工件引用）拼接成完整轨迹，用 LLM 为每个出现的工件生成贡献摘要、抽取片段，再推断工件对之间的关系，连同嵌入存入 DuckDB。注意"批量任务结束后统一提取"的设计：经验写入是异步的、不阻塞在线求解，这保证了中间件的轻量性。

一个贯穿始终的运行示例值得记住：任务 1 让 Agent 算"2018 年以来 Delaware 来源产品价格与供应成本"，它在求解中读遍了 sales1（2018-2019 价格）、sales2（2020-2026 价格，Delaware）、costs1.pdf（与 sales2 经 Delaware 关联）。ExpIdx 从轨迹中沉淀出三条经验：A=sales1 的时间范围、B=sales2 的时间范围、C=sales2↔costs1.pdf 的关联。等任务 2 问"2020-2025 营收与公司税"时：从 A 判定 sales1 时间不符应剪除、从 B 引入 sales2、从 C 顺藤引入 costs1.pdf——一次检索即得完整工件集，而无记忆的 Agent 只搜到 sales1/sales15，答案漏掉 Delaware。

4.2 Skill 效用实证：三问三答的受控实验设计

这篇论文的方法就是实证方法本身，分三步：

RQ1（配置依赖）：87 个 SkillsBench 任务 × 9 个配置（GPT-5.5 / DeepSeek-V4-Flash / Qwen3.5-27B 三模型 × Codex / OpenClaw / OpenCode 三 harness），Benchmark-Skill 与 No-Skill 两条件，每条件新鲜环境跑 3 次。这一问回答"同一份 Skill 在不同配置下效用是否稳定"。

RQ2（候选差异）：对 23 个单 Skill 任务，从 37,596 个市场 Skill（124,425 条记录经完整性/下载量/英文/去重四步过滤）中检索：BM25 取 200 → text-embedding-3-large 嵌入取 50 → Claude-opus-4.6 结合全文重排取 Top-5（M1–M5）。每个候选按原文原文资源执行；再用原子操作匹配分数 Match(t,s) 重排出 MR1–MR5，复用已有执行记录聚合。这一问回答"相关性排名是否选得出最好用的 Skill"。

RQ3（组织效应）：对 41 个 ≥3 Skill 的任务，固定 Skill 集与资源不变，只改组织指令：Flat（无组织）/ Sequence（用序）/ Stage Plan（阶段目标）/ Dependency DAG（工件依赖 + 传递物）。作者手工构建组织指令并由另一作者核查是否有源材料支撑。这一问回答"同样的料，怎么摆收益最大"。四方案的差异可以拿厨房类比：Flat 是把所有菜谱摊在台上随缘翻；Sequence 是"先做 A 再做 B"的步骤单；Stage Plan 是"备菜阶段把料切好、烹炒阶段出锅"的目标分解；DAG 则进一步写明"酱汁碗的产出要接到摆盘环节，摆盘必须等酱汁就位"。

证据分析：对 69 个比较组（含 210 条轨迹的初始样本）做 LLM 归纳 + 两作者人工复核，区分"内容缺失"、“写了但没被执行”、“Agent 执行中自己补的步骤”，产出五阶段 17 条作者实践。五阶段分别是 Preparation（适用边界、参考引用、环境与权限前提，P1–P4）、Adaptation（方法选择依据、数据语义、可替换示例参数，A1–A3）、Implementation（资源可得、调用文档、操作依赖、方法替换时的结果保留，I1–I4）、Verification（验收标准、交付物检查、重验证触发器，V1–V3）、Correction（诊断恢复、重试边界、修复中保留经验证的验收标准，C1–C3）。这 17 条实践本身也是论文的交付物之一——它们把"Skill 怎么写才有用"从经验直觉变成了可核查的条目。

五、评估指标与实验证据

5.1 ExperienceIndex 的证据体系

指标：在线阶段看平均答案分与平均在线成本（美元/千任务）；索引阶段看索引成本与存储足迹。答案分按数据集分别用执行准确率（Spider）、issue 解决率（SWE-bench）、LLM-judge（Locomo/MMQA/Musique）、rubric 评分（SQA/Freshstack）。

数据集矩阵：7 个数据集覆盖文件（Locomo 对话日志、SWE-bench 代码库）、文档（SQA 科学文献、Freshstack 技术文档、Musique 多跳 QA）、表格（Spider text-to-SQL、MMQA 事实 QA），搜索框架横跨文件系统搜索、定制 retrieve-and-rerank、向量检索工具——验证"中间件"的通用性。

†EnrichIndex 需离线访问全语料，SQA 的 Semantic Scholar 有 2.38 亿论文，不可行。

总体结论：双模型平均答案分相对最强 baseline EnrichIndex 提升 3.9%、相对 ReasoningBank 提升 5.01%；平均在线成本降 20.8%（对 baseline）/ 19.8%（对 RB），单项最大降幅 50.5%。Locomo 上 GPT-5-Mini 从 82.2 提到 88.8 的同时成本从 $14.2 降到 $7.03——分数升、成本降同时发生，这是"经验替代搜索"的直接证据。

索引经济学（Table 3，Gemini）：EnrichIndex 索引成本 $93.4、存储 1108.7MB；ExpIdx $0.628、15.5MB——索引成本降 115.0×、存储降 73.0×。这个数字的来源是结构性差异：EnrichIndex 必须扫全语料，ExpIdx 只处理轨迹中出现过的工件。

两个额外发现：（i）跨任务泛化——用 Spider 的 text-to-SQL 轨迹建记忆直接服务 MMQA 事实 QA（同表库），89.0 vs Base 84.0，说明经验锚定在工件上时天然跨任务类型；（ii）师生学习——强经验模型（Gemini）+ 弱评估模型（GPT-5-Mini）达 92.5 分、成本 $7.50，逼近强模型自身的 92.5/$93.4——弱模型"抄强模型笔记"就能追平强模型。师生学习四格表（Locomo）完整数据：Base GPT-5-Mini 82.2/$14.2、Base Gemini 88.8/$155.2；同模型 ExpIdx：GPT 88.8/$7.03、Gemini 92.5/$93.4；交叉配置 Gemini 经验 + GPT 评估 92.5/$7.50——分数追平 Gemini 的同时成本只有其 8%。这对团队的启示很直接：让贵模型跑一遍积累经验库，之后便宜模型搭载该经验库即可长期低成本运行。

消融：去掉轻量反思步骤，Gemini 92.5→91.6、GPT-5-Mini 88.8→85.0——反思对防止过时/幻觉经验污染是必要的。另一个维度是记忆库规模：把建库数据占比从 80% 降到 20%–60%，所有规模都优于无记忆，且分数与成本效率随规模单调改善——经验越多越好用，没有饱和回退，这为"持续积累"的工程预期提供了曲线。相关性判定模型换成 Nemotron-3-Ultra 或 Mimo-V2.5，Gemini 下分别得 92.5 与 91.6，与 GPT-5-Mini 的 92.5 持平——判定环节不挑模型，增益来自经验表示本身。

5.2 Skill 效用实证的证据体系

RQ1 证据：9 配置全部正增益（+4.60 ~ +19.54pp），但 36.78%（32/87）的任务在不同配置下既有增益也有损失——效用不是 Skill 的固有属性，而是 Skill×配置的联合属性。九配置明细：GPT+Codex 42.15→54.02、GPT+OpenClaw 30.65→47.89、GPT+OpenCode 24.14→43.68（最大增益 +19.54）、DeepSeek+Codex 34.10→44.44、DeepSeek+OpenClaw 35.63→50.19、DeepSeek+OpenCode 36.40→48.28、Qwen+Codex 2.30→6.90（最小 +4.60）、Qwen+OpenClaw 3.45→17.24、Qwen+OpenCode 13.41→24.52（均为 No-Skill→Benchmark-Skill 的通过率百分比）。另一个反直觉发现：Skill 会放大模型间差距——OpenCode 下 GPT 与 Qwen 的差距从无 Skill 的 10.73pp 拉大到 19.16pp，“强者愈强"的马太效应在经验资产上同样成立。

RQ2 证据：69 个比较组中 23.19%（16/69）出现低排名候选胜过 M1；Qwen+OpenCode 下 M1（14.49%）甚至低于 No-Skill（17.39%）。原子操作重排后三配置首选项通过率 +4.35 / +4.35 / +5.80pp，其中 Qwen+OpenCode 从 14.49% 升到 20.29%，由负转正——同样的候选集、同样的执行记录，只换选择顺序就能翻正。

RQ3 证据：固定 Skill 集下 DAG 较 Flat 提升 +6.50 / +11.38 / +6.50pp（三配置）；5-6 Skill 任务上 DAG 较 Stage Plan 再 +12.12 / +3.03 / +9.09pp——Skill 数量越多、中间交接点越多，显式依赖的价值越大。

方法学效度控制：每条件 3 次重复、任务内平均后再跨任务等权平均；RQ2 重排复用执行记录排除执行随机性；RQ3 组织指令经第二作者核查源材料支撑；威胁效度一节明确承认 3 次重复的分辨率限制与 5-6 Skill 组仅 11 个任务的组成混淆——这是扎实的实证规范。还需要点出一个容易误读的数字：RQ1 的分组统计是 32 个"有增益也有损失”、32 个"只有增益"、8 个"只有损失"、15 个"不变"——也就是说 Skill 整体上大概率有益（64/87 至少有增益），但"有益"不等于"处处有益"，任何单配置评估都会高估或低估其效用。

实验为什么能证明论点：三个 RQ 的设计各堵死一条"绕路解释"。RQ1 用同一 Skill 集跨 9 配置，排除了"内容差异"解释——内容固定，效用仍变，变量只能是配置；RQ2 的重排实验用同一候选集、同一批执行记录，只换选择顺序，排除了"执行运气"解释；RQ3 固定 Skill 集与资源只改组织指令，排除了"Skill 质量差异"解释。每条 Finding 背后都有"只动一个旋钮"的对照，这在 Skill 研究里是罕见的严谨度。

六、效果优势的根源解释

6.1 ExperienceIndex：为什么锚在工件上就赢了

因果链一：对无记忆 baseline。ReAct 循环对每个新任务从零搜索 → 漏掉邻居工件（如答案需要 sales2 + costs1.pdf 但搜索只按查询语义命中前者）→ 答案不完整；或者反复试错 → token 成本高。ExpIdx 的工件对经验把"哪些工件总是一起出现"显式存了下来 → 检索到 sales2 时主动经 Delaware 关系引入 costs1.pdf → 一次检索得完整集合 → 分数升 + 轮数与成本降。（论文实验已支持：Locomo 分数 +6.6 同时成本减半）

因果链二：对抽象记忆 ReasoningBank。抽象策略的形式是"先明确问题要求，再列适用定理"这类通用步骤 → 不含任何工件知识 → 无法补全被搜索漏掉的表、也无法排除时间段不符的表。MMQA 案例中 RB 的策略记忆无法引入 Products_eafb 表，ExpIdx 经 join 关系（Order_Items_d9a3.product_id = Products_eafb.product_id）主动引入 → 模型改用 SQL 同时搜两张产品表 → 答对。（论文实验已支持：MMQA 上 EXP 92.0 vs RB 92.0 持平但 Musique/Spider 等拉开差距；机制层面 RB 缺少工件通道是其表示形式的必然）

因果链三：对离线增强 EnrichIndex。离线增强的标注"看不到下游任务"→ 生成的 QA 对与真实检索需求错位，收益封顶；更要命的是成本结构：成本随语料规模线性增长，对 2.38 亿论文的 Semantic Scholar 根本不可行。ExpIdx 成本随已解任务数增长 → 已解任务远少于语料工件数时（现实常态），索引成本差 115×、存储差 73×。（论文实验已支持：Table 3 + SQA 上的不可行性论证）

跨任务泛化的机制补证：Spider 的经验库为何能直接服务 MMQA？因为两类任务虽然形式不同（生成 SQL vs 问答），但所需的事实相同——“Order_Items_d9a3 与 Products_eafb 经 product_id 可连接"这种工件对经验对两类任务都管用。反观任务锚定的记忆（ReasoningBank），跨任务类型时"相似任务检索"直接失灵——没有相似任务可检索。这解释了为什么 ExpIdx 的跨任务迁移是"免费搭车"而抽象记忆做不到。（论文实验已支持：MMQA 89.0 vs Base 84.0，且记忆库完全来自 Spider 轨迹）

反事实验证：去掉反思步骤 GPT-5-Mini 掉 3.8 分 → 说明经验注入并非多多益善，无校验的注入会被过时/幻觉经验污染；换相关性判定模型（Nemotron-3-Ultra、Mimo-V2.5）分数几乎不变 → 说明增益来自经验表示本身而非判定模型的特异能力；把建库数据从 80% 降到 20% 仍然全面优于无记忆 → 说明经验收益从少量积累就启动、且随积累单调增长（论文实验已支持）。

与外部工作的机制对照（阅读者综合）：ReasoningBank 的自进化范式证明了"轨迹→记忆→复用"闭环本身成立（Google 在 web browsing 与 SWE 基准上的独立证据），但它的记忆项挂在"任务"下；ExpIdx 相当于把同一闭环的记忆项重新挂到"工件"下，MMQA 案例所示的邻居补全能力是"挂在任务下"的结构性盲区——这是一条有论文证据支撑（对照实验 + 案例）但尚待独立复现的机制推断（标注：阅读者推断）。另一个旁证是第一篇同组前作 Log-augmented Generation 的"可复用计算"思想：同一批作者一直在探索"轨迹中什么值得留下来”，从可复用计算到工件经验是一脉相承的深化。

6.2 Skill 效用：三个 Finding 各自的机制闭环

F1（配置匹配）：exam-block-sequencing 案例中，Skill 主推整数规划方法，但允许启发式。DeepSeek+Codex 无 Skill 时 3/3 通过（自己选了模拟退火），带 Skill 时 0/3——公式漏掉 count 系数后反复调试超时；GPT 用同一 Skill 却能在求解器被杀后切换到允许的启发式保住可行解。机制：推荐流程超出配置的执行/适应能力时，指导就变成执行负担——不是 Skill 内容差，是"内容 × 执行方"错配。这个案例的戏剧性在于：同一个 Skill，对 DeepSeek 是毒药、对 GPT 是解药，把"效用是联合属性"这个论点钉死了。

F2a/b（相关性失效）：lab-unit-harmonization 的 M1（medical-unit-converter）主题高度相关，但接口要求已知源/目标单位，而任务还要求删不完整行、规范科学计数法、用生理范围判别异常值——这些操作缺口不被总体相关性分数反映。原子操作重排把 M2（clinical-data-cleaner）提到首位：它恰好提供单位标准化 + 删行策略 + 阈值检查 → 首选项效用 +4.35~5.80pp。机制：主题匹配是任务级信号，效用是操作级现象，粒度错位导致排名失效。执行轨迹进一步闭环了这个归因：GPT+Codex 使用 M2 的成功 run 里，agent 确实读取了 Skill 自带的阈值参考文件、按策略删行、转数值格式、逐特征处理单位并检查输出——重排选中的操作支持在轨迹中被真实使用了，而非纸面推断。

F3（DAG 传播修正）：jpg-ocr-stat（从收据抽日期与金额、生成工作簿）中 GPT+Codex 在 Flat/Sequence/Stage Plan 下均 0/3，DAG 下 3/3。DAG 要求保存 OCR 文本（字段之源）与结构化字段文件（连接抽取与工作簿生成）→ agent 检查抽取字段时发现问题 → 回读 OCR 源 → 重跑抽取 → 更新字段文件 → 重建工作簿。机制：显式工件依赖使中间工件可回溯核查、修正可沿 DAG 传播；且增益集中在 5-6 Skill 任务——交接点多、无显式依赖即断链。为什么 Stage Plan 不够？阶段计划说"这一阶段要达成 X 目标"，但阶段产出物落在哪里、下一阶段从哪里读，都是隐式的——出错时 agent 无从"回到源头"核对；DAG 把"产出什么文件、谁依赖它"写死，回溯路径才存在。0/3→3/3 的翻转不是巧合，是"中间工件可见性"从无到有的相变。

6.3 两篇对照：外部证据与交叉验证

综合判断：（a）“结构化/显式组织优于语义平铺"得到 AgentSkillOS、SkillDAG、GraSP 与本文 RQ3 的多项共同支持，属稳健机制；（b）“工件锚点优于用户/策略锚点"在 ExpIdx 内部证据充分（消融 + 跨任务泛化 + 成本结构），但外部独立复现尚缺，属"单一论文强证据”；（c）适用边界：ExpIdx 要求任务流共享同一工件语料——对一次性语料无积累空间；Skill 重排结论依赖 Claude-opus 级别的操作抽取质量，且作者自己承认需在独立任务集上验证稳定性；（d）值得注意的反向条件：F1 表明当配置能力不足时，更多指导反而有害——经验资产不是无条件正资产。

检索范围说明：以上对照表基于两篇论文的 Related Work 全文、以及本次通过 arXiv 页面核实的 ReasoningBank（含 ICLR 2026 接收信息与代码库）和 SkillsBench（含 18 配置平均 +16.6pp 的 v4 更新数据）。对"artifact-grounded memory 是否有其他同期工作"的检索在本次范围内未发现直接同题研究；相关表述均标注了证据等级（论文实验已支持 / 阅读者推断）。

七、必要知识反推

假设让一个没有背景的人重做这两项工作，最少需要掌握什么？

领域知识层：（1）知识密集行业的实际工作形态——法律/咨询/科研人员如何在共享语料上反复解题、人的"便签式"工件记忆长什么样（ExpIdx 的类比直接来自此，McKinsey 合作者的价值所在）；（2）Agent Skill 生态的现状——SKILL.md 规范、渐进披露机制、两个主流市场的规模与质量分布；（3）ReAct 循环与搜索框架的三种形态（文件系统/流水线/向量工具），否则无法设计"中间件"注入点。第（1）条尤其值得强调：如果作者没有对"律师/顾问如何记便签"的真实观察，就提不出"工件对经验"这种与真实工作记忆同构的设计——很多系统设计的灵感源头其实在领域现场而非文献里。

方法论知识层：（4）记忆系统设计的两条既有路线（画像/抽象）及其表示形式——没有它们就没有对照对象，也无从发现"工件知识"这个空位；（5）实证软件工程方法——配对比较、任务内平均后跨任务等权、LLM 辅助归纳 + 作者复核 + 反例检查的质性分析流程（第二篇的脊梁骨）；（6）检索与嵌入——BM25 与稠密检索的组合、top-k 召回 + LLM 重排的流水线（第二篇候选检索与第一篇经验检索共用这套）。

工程知识层：（7）token 级成本核算——按输入/输出 token 与 API 定价折算美元，才能算出 115×/50.5% 这类经济学证据；（8）数据库增量索引——DuckDB 存储 + 嵌入预计算；（9）受控执行基础设施——新鲜环境、程序化验证器、3 次重复的实验管理。第（9）项的工作量常被低估：9 配置 × 2 条件 × 87 任务 × 3 次的 RQ1 加上 RQ2 的 7 条件 × 3 配置 × 23 任务 × 3 次，累计数千次容器化执行——没有可靠的实验编排与产物留存（轨迹、交付物、验证结果），后续的"LLM 归纳 + 作者复核"分析流程根本无从谈起。

知识融合的关键节点：最关键的化学反应是**“锚点"概念的迁移**——把数据库领域"以稳定实体为主键"的思想搬进 Agent 记忆（工件 id 就是经验的主键），同时把实证软件工程"控制变量 + 轨迹证据"的方法搬进 Skill 评估。两篇论文各自在自己的传统里完成了跨界嫁接。第二个融合节点在评估侧：两篇都必须回答"如何把不可见的东西变成可测的东西”——第一篇把"熟悉语料"变成"在线成本 + 索引成本"的经济计量，第二篇把"Skill 好不好用"变成"同任务同配置配对差分 + 轨迹取证”。方法论上的共通点是：当研究对象（经验、效用）无法直接观测时，就为它的可观测后果建立会计体系。

八、论文中可以提取的通用性灵感

灵感一：资产的价值锚定在其作用对象上，而非其主题上。 论文证据：ExperienceIndex 以 artifact_id 为记忆主键后索引成本降 115×、答案分反升；Skill 实证中主题相关的 M1 在 23.19% 场景输给操作覆盖更好的低排名候选。 推广场景：推荐系统（按"能完成用户当前操作链"而非品类相似推荐工具）；RAG 文档选择（按"能支撑查询所需的字段/推理步骤"选段）；企业知识管理（按"被哪些流程实际消费"而非目录分类组织文档）；代码依赖管理（按运行时实际调用而非声明依赖做裁剪）；招聘匹配（按岗位实际职责清单而非行业 title 相似度筛人）。

灵感二：单元资产之间的连接关系是更高阶的资产。 论文证据：单工件经验只保证"不选错"，工件对经验（Delaware 关联、join 列）才保证"不漏选"——完整性来自图结构；DAG 的增益集中在交接点多的 5-6 Skill 任务。 推广场景：数据治理（表间血缘图决定影响分析能力）；微服务架构（服务依赖图决定故障传播可追踪性）；供应链（二级供应商关系决定风险可见度）；团队知识库（文档间引用网络决定新人能否找齐上下文）。

灵感三：经验注入必须自带"校验与失效"机制。 论文证据：ExpIdx 去掉反思步骤 GPT-5-Mini 掉 3.8 分；Skill 实践 V3（重验证触发器）与 C3（修复中保留经验证的验收标准）同属一阶段。 推广场景：缓存系统（TTL + 主动失效校验）；人肉 SOP（FMEA 中的再验证节点）；金融模型（数据漂移检测触发重训）；法务合同（变更条款触发关联条款复核）。

灵感四：成本结构决定方案的可扩展性上限。 论文证据：EnrichIndex 与 ExpIdx 的效果差距不大，但"随语料规模增长"vs"随已解任务数增长"的成本结构差出 115×，直接决定谁能在 2.38 亿论文上活下来。 推广场景：ETL 设计（全量 vs 增量）；索引构建（预计算 vs 查询时计算）；安全扫描（全量代码 vs 变更触达路径）；大模型部署（预训练 vs 按需微调）。

灵感五：同一资产对不同消费者不等价，评估必须配对。 论文证据：同一 Skill 在 36.78% 任务上跨配置既有增益也有损失；DeepSeek+Codex 无 Skill 3/3、有 Skill 0/3。 推广场景：药品（适应症 × 个体基因）；教辅材料（学生水平 × 教学法）；API 库（框架版本 × 运行时）；培训内容（岗位 × 经验背景）。

灵感六：强者的经验是弱者的杠杆。 论文证据：Gemini 的经验库让 GPT-5-Mini 以 1/12 的成本追平 Gemini 自身的 92.5 分；Skill 侧的马太效应（GPT 与 Qwen 差距被 Skill 从 10.73pp 拉大到 19.16pp）则从反面说明经验放大能力差距。 推广场景：组织知识管理（专家离职前的经验萃取让新手接手）；模型蒸馏的轻量替代（经验库即数据自由主义蒸馏）；开源社区（核心贡献者的 issue 处理记录成为新维护者训练集）；体育竞技（冠军训练日志对青年队员的价值）；教育体系（名师教案让普通教师上出高质量课）。

灵感七：中间件位置是注入先验的最小侵入点。 论文证据：ExpIdx 不改模型、不改搜索框架，只在"工具输出"与"系统提示"两个运行时可变组件上做增强，即横跨 7 个数据集 × 多种搜索框架通用。 推广场景：数据库（查询改写中间件）；浏览器扩展（不改网站本身增强功能）；编译器 pass（不动前端后端插入优化）；DevOps（sidecar 容器注入可观测性）。

灵感八：把"评估过的条件"作为资产的一部分发布。 论文证据：论文讨论部分明确建议发布 Skill 时记录验证所用的任务与配置——因为 36.78% 的双向任务证明效用不能脱离配置谈论；类似地 ExpIdx 的师生学习表本质上是"经验 + 其来源模型"的元信息在发挥价值。 推广场景：npm 包的 engines 字段与 peerDependencies 声明；药品说明书的适应症与禁忌；机器学习模型卡（model card）的评测环境记录；菜谱标注的难度与厨具前提。发布方少写一行适用条件，消费方就多付一次试错成本。

两篇合读的元灵感：经验的供给与消费需要对齐在同一坐标系下。 ExperienceIndex 解决"经验以什么形式沉淀"（工件锚点），Skill 实证解决"经验以什么标准选用"（操作覆盖）。单独优化任何一端都会落空：只有记忆没有选用标准，会重演"相关性排名失效"；只有选用标准没有记忆积累，每次都从零开始。一个完整的"经验资产化"系统需要两者咬合——而咬合的公切线正是第三部分末尾指出的：以工件为节点、以依赖为边的图表示。这是本次合读最值得带走的设计判断。

附录：符号与术语速查

• ExpIdx：ExperienceIndex 的缩写。
• RB / EI / EXP：实验表中 ReasoningBank / EnrichIndex / ExperienceIndex 的对照条件。
• M1–M5 / MR1–MR5：相关性排名前五候选 / 原子操作重排后前五候选。
• Flat / Sequence / Stage Plan / DAG：无组织 / 用序 / 阶段目标 / 工件依赖图四种 Skill 组织方案。
• pp：percentage point，百分点。
• 相关性失效：指 23.19% 的比较组中低排名候选效用高于首选项 M1 的现象。
• model–harness configuration：模型 × 执行框架的组合（如 GPT+Codex），论文中效用分析的基本单位。
• 单工件经验 / 工件对经验：ExpIdx 的两类记忆，分别保障检索的相关性与完整性。
• 原子操作：作用于具体对象、有可识别输出的基本动作单元，任务需求与 Skill 流程的共同分解标准。
• 师生学习：强模型执行经验任务、弱模型搭载所得经验库完成评估任务的设置。
• 渐进披露（progressive disclosure）：Skill 的加载机制——先暴露名称描述供选择，激活时加载正文，按需访问配套资源。
• 反思步骤（lightweight reflection）：ExpIdx 注入经验时附带的指令，要求模型校验经验与当前工件的一致性，冲突时以当前工件为准。

附录：关键数字速查