超级库智能体：超越单一代码库的多应用联合生成与维护 Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase
让LLM智能体边顺序生成相关应用边维护共享组件库，在不损功能的前提下大幅削减代码冗余
前置知识
LLM 编码智能体（Coding Agent）
以大语言模型为核心、通过多轮工具调用（读写文件、执行命令、运行测试）自主完成软件任务的系统，代表有 SWE-agent / mini-SWE-agent、OpenHands、Claude Code。它们按“读任务说明→改代码→验证”的循环工作，能在无人干预下端到端生成一个完整应用。
本文研究的对象正是这类智能体的长期行为缺陷：单个智能体生成一个应用没问题，但让它连续生成 N 个相关应用时会积累冗余和“代码 slop”。所有对比方法都构建在 mini-SWE-agent 脚手架之上，不理解这一点就无法理解实验设定。
库学习（Library Learning）
从已有程序语料中自动挖掘可复用抽象（函数、组件、hook）并汇总成共享库的技术，源自程序合成领域（DreamCoder、Stitch、LILO），近年 Librarian 把它建模为“最小化 MDL 的代码库重构”。这些方法都假设代码已经存在，做事后压缩。
本文把库学习从“事后、单项目”推广到“在线、多代码库”设定：应用逐个到达，新应用生成时使用库，新发现的抽象再回迁到旧应用。论文的基线 LIBRARIAN 就是最强的库学习代表，理解这一脉络才能看出方法差异。
最小描述长度（MDL）
用参考语言模型对代码计算负对数概率作为“压缩代价”的代理指标。本文采用依赖感知变体 $\mathrm{MDL}(C) = -\log p_\theta(L) - \sum_{i=1}^{N} \sum_{f \in c_i} \log p_\theta(f \mid \mathrm{deps}(f))$，即库与各文件在给定其直接 import 条件下的负对数似然之和，用 Qwen-2.5-7B 计算，值越低代表代码越能被库“解释”。
MDL 是 Librarian 基线的核心选择准则（采样 K=8 个重构取 MDL 最低者），也是本文五项可维护性指标之一；论文还发现 MDL 有盲区——消融中结构更差的方案 MDL 反而更低，读懂 MDL 才能理解这一关键讨论。
结构侵蚀与冗长度（Erosion & Verbosity）
来自 SlopCodeBench 的两个“代码 slop”度量。结构侵蚀 Erosion 衡量圈复杂度大于 10 的函数所承载的复杂度质量占比（每函数按其圈复杂度与源代码行数的平方根加权，圈复杂度基于 McCabe 1976）；冗长度 Verbosity 衡量被重复代码或规则标记的冗余模式覆盖的逻辑行占比。两者都是越低越好。
它们是本文区别于朴素库构建的核心证据：SLA-FULL 把 WebGen-Bench 的 Verbosity 从 0.1603 降到 0.0994（−38%），而朴素抽取反而推高 Erosion。不懂这两个指标就无法理解论文“共享库不应集中复杂度”的核心论点。
调用图（Call Graph）
以文件/函数为节点、以 import 语句和调用关系为有向边的依赖图（Ryder 1979）。修改一个文件时，导入它的调用者文件和它依赖的被调用文件都可能需要同步更新，否则会留下断引用、重复实现或死代码。
本文的“调用图条件迁移”（call graph conditioning）是保证迁移正确性的关键机制之一：为每个迁移候选附加 also-refactor 清单（相关 import 与每侧至多 8 个 caller/callee 文件），消融显示去掉它后准确率从 77.21 掉到 74.48、Erosion 升至 0.1409。
DRY 原则与跨项目代码克隆
DRY（Don't Repeat Yourself）要求同一逻辑在代码库中只存在一份。功能等价但文本差异巨大的代码称为克隆（尤其是 Type-3/4 克隆），它们是维护负担的主要来源：每个 bug 修复、策略变更都要手工传播到所有副本，且极易遗漏。
论文挑战一（抽取召回率低）的根源正是 Type-4 克隆：功能等价的实现语法结构可能完全不同，基于表面相似度的检索或聚类会漏掉真正的复用候选。这是作者改用自然语言摘要索引而非代码相似度来发现候选的直接原因。
研究动机
现实组织的软件资产很少是孤立的单个应用，而是由可独立部署、共享领域逻辑、界面模式、数据处理例程和运维约定的相关应用组成的组合（portfolio），即经典的软件产品线场景。当用 LLM 编码智能体逐个生成这些应用时，每个智能体都会把共享关注点（如“搜索+分类过滤”“localStorage 持久化”“表单校验”）以微妙不同的形式重写一遍，违反 DRY 原则，形成一个不一致面：每个 bug 修复、设计变更或政策更新都必须手工传播到多个近似副本。这种重复在传统软件组合中已是公认的维护负担，而 LLM 让它在规模上更容易被制造出来。更糟的是 LLM 智能体自身的维护行为在火上浇油：已有研究表明 LLM 生成代码带有可度量的 code smells，SlopCodeBench 证明长期的智能体式编码会产生“slop”——功能仍然正确、但越来越冗长、结构越来越缠绕的代码。用 N 个相互隔离的智能体生成 N 个应用会把这一效应复合：每个智能体重新推导共享逻辑、积累自己的死代码、并随每个维护周期与兄弟应用漂移得越来越远。论文用数字量化了这一现状：在 WebGen-Bench 上，Zero-Shot 方法生成 8 个应用的组合需要 9393 行非空代码、70364 个 token，冗长度 Verbosity 高达 0.1603；而一次跨应用的共享策略更新要对这些孤立代码库打下 936 行的补丁、触碰约 29.8 个文件。
本文的目标是本文的目标是形式化并解决“超级库智能体（Super Library Agent, SLA）”问题：给定相关应用实现请求的序列 $X = (x_1, \ldots, x_N)$，智能体从空库 $L_0 = \emptyset$ 出发，在每个时刻 $t$ 给定新请求 $x_t$、已有代码库 $C_{<t} = \{c_1, \ldots, c_{t-1}\}$ 和当前库 $L_{t-1}$，产出 $(c_t, C'_{<t}, L_t) = A(x_t, C_{<t}, L_{t-1})$，其中 $c_t$ 是新代码库，$L_t$ 是更新后的共享超级库，$C'_{<t}$ 是被修补为使用新库的旧代码库。理想的超级库应包含每个被至少两个已实现应用使用的组件 $L_t^\star = \{u : \sum_i \mathbf{1}[\mathrm{use}(u, c_i)] \geq 2\}$——应用专属组件留在本地，共享组件被抽取并一致复用。最终目标是在功能性与联合代码库可维护性之间寻求有利的帕累托权衡：应用要满足各自请求，同时共享组件要被正确抽取、去重、复用和更新，使得修复一个共享 bug 只需改库中一处、即可惠及全部导入该符号的应用。
与已有工作不同的是，现有工作存在三个方向的盲区。其一是库学习与事后重构：DreamCoder、Stitch、LILO 从固定程序语料挖掘抽象，Librarian 把库构建建模为对已有代码片段的 MDL 最小化重构，但它们都是对“已经存在”的代码做事后压缩，且 Berlot-Attwell 等指出其收益可能被额外推理预算混淆、学到的工件很少被真正复用；Librarian 明确假设输入文件在单一逻辑项目内，并把“大规模多 repo 库构建”留作开放问题。其二是可维护代码生成：MaintCoder、SlopCodeBench、CodeTaste、Agentic Refactoring 等表明智能体能在保持行为的同时积累冗长、重复和架构债，但这些工作只研究单一演化中的代码库，不处理跨应用的联合可维护性。其三是共同逻辑抽取与迁移：RefAgent、EM-Assist 等系统通过语料级分组或结构化重构流程从已完成的代码库中抽取公共逻辑，证明发现和迁移需要比直接改写更多的结构，但不处理在线的跨应用抽象。本文的独特切入是把三者统一到在线设定：应用带着单一初始请求逐个到达、无后续补丁，智能体在生成新应用时使用共享库，并把新抽象回迁到旧应用；同时首次系统识别并命名了阻碍朴素库构建的两个失败模式——抽取召回率低（Challenge 1）与依赖迁移脆弱（Challenge 2），并针对性地设计候选引导抽取与上下文感知迁移两个机制。
核心方法
先讲直觉：与其让每个应用各自重复实现“搜索+分类过滤栏”“localStorage 读写循环”“联系表单校验”这类模式，不如让一个智能体在按顺序建设应用流的同时维护一个不断增长的共享超级库，并保证每次抽取都安全地传播到所有受影响的应用——这样修复一个共享 bug 只需改库中一处。技术路线上，SLA 被实例化为一个顺序脚手架：每轮把 $(x_t, C_{<t}, L_{t-1})$ 映射为 $(c_t, C'_{<t}, L_t)$，分两个阶段——编码智能体生成新代码库 $c'_t$（凡库 $L_{t-1}$ 中有适用组件就复用），随后库智能体从已实现的应用中抽取跨应用共享组件得到 $L_t$，并把含有重复实现或过期库依赖的旧代码库迁移过去得到 $c_t$ 与 $C'_{<t}$。最小版本（SLA-NAIVE，Algorithm 1）把库构建和跨代码库依赖迁移都交给单个通用库智能体一次调用完成；完整版（SLA-FULL，Algorithm 2）把它拆成库抽取智能体与依赖迁移智能体两个专职角色，并叠加三项增强：基于索引的候选抽取、抽取前的代码库整合、以及利用抽取轨迹与调用图信息的上下文感知迁移。实验配置为批大小 $m=2$，即每轮并行生成 2 个应用、共 4 轮生成 8 个应用，每轮结束执行一次抽取+迁移循环。
核心创新在于“用自然语言摘要索引选候选 + 用抽取轨迹和调用图引导迁移”这一对机制，它们与已有方法有本质区别。对于候选发现：传统库学习和克隆检测按代码文本或 embedding 相似度分组来发现重复，但功能等价的实现往往语法与结构差异巨大（Type-4 克隆），表面相似性检索会漏掉大量有效候选；SLA-FULL 改为用 gpt-5.4-nano 为每个 AST 边界的代码块生成一句不超过 160 字符的自然语言摘要（描述“做什么”而非“怎么写”），让 LLM 选择器（deepseek-v4-flash）在这些紧凑的代码摘要索引上做跨应用匹配——按块的功能而非写法分组。对于迁移正确性：已有工作把抽取当作一次局部改写，而迁移最难的恰是非局部依赖——替换本地实现需要同步更新 import 声明、调用点和依赖的辅助函数。SLA-FULL 让抽取智能体为每个新增或更新的库符号写一份结构化“抽取轨迹”（extraction trace），记录该符号从哪些代码块泛化而来（Sources 表）、为什么该模式能跨应用泛化（Why generalized）、以及如何用库 API 替换原代码（Apply guidance）；把轨迹传给迁移智能体就在两个分离的阶段之间架起桥梁，使其无需从零重新发现对应关系。再辅以纯程序化（无 LLM）构建的文件级调用图，为每个迁移候选附加 also-refactor 清单（相关 import 声明与每侧至多 8 个 caller/callee 文件），强制智能体更新依赖点、删除被替换的本地实现，从机制上压制断引用、重复实现和死代码。
方法步骤详情
SLA-FULL 每轮执行四步（Algorithm 2）。第一步编码：编码智能体按任务说明 $x_i$、给定库 $L_{r-1}$ 与代码索引 $N_{r-1}$，并行生成批内 $m=2$ 个新代码库 $c_i$，输出为可运行的代码库，能复用库组件处直接 import。第二步索引：用 cocoindex-code 按 AST 边界（函数、类、模块）把每个代码库切块，gpt-5.4-nano 逐块生成一句英文摘要；索引条目记录语言、文件路径、行区间、内容哈希与摘要——哈希未变的块复用旧摘要实现增量更新，短于 5 行的块跳过，索引渲染进提示时每块一行。第三步两级抽取：先用同一套索引选择流程做抽取前整合（consolidation），识别每个新代码库内部重复或重叠的本地实现并重构成库内共享模块（因为抽取智能体被设计为只看跨代码库模式，单库内的重复它发现不了）；然后库抽取智能体读取“现有库摘要 + 所有应用全部块摘要”，由选择器提出 Top-K 个出现在至少 2 个应用中的高价值跨应用候选（提示要求保守——假阳性比覆盖更致命，且不得与现有库符号重复），确认后把代码库特定值参数化为通用 API、合成库符号写入 $L_r$，并为每个新/更新符号写抽取轨迹 $T_r$（轨迹是累积文档，后续轮次追加并修订既有条目）。第四步迁移：每个应用一个迁移智能体，输入库符号摘要与该应用全部块摘要，选出该应用应采纳的库符号（Top-K，若无强匹配输出 NONE），配合抽取轨迹定位替换点，再附上调用图生成的 also-refactor 清单，把本地实现改写为库调用、更新 import 与调用点、清除死代码。全程施加三条硬约束：应用代码可导入库、库永不导入应用；库必须保持无应用特定状态；必须保持各基准的构建与入口约定，使重构后的组合仍能在评测框架下运行。
技术新颖性
本文的新颖性体现在四个层面。问题层面：SLA 把“生成新应用 + 维护共享库 + 跨代码库依赖迁移”统一为单一在线决策问题，此前没有基准或系统针对它，Librarian 明确把多 repo 库构建留作开放问题。抽取机制层面：候选选择基于跨代码库的自然语言块摘要索引（AST 切块 + LLM 摘要 + LLM 选择器），而不是代码克隆检测或嵌入聚类；消融显示 NL 摘要方式在 5 项可维护性指标中 4 项最优，且抽出的共享组件远多于其他方式（库 815 LOC vs 无候选的 447、Ward 聚类的 433），说明按语义而非表面形式匹配显著提高了抽取覆盖。迁移机制层面：“抽取轨迹 + 调用图条件”的组合是全新的——轨迹在抽取与迁移两个分离的智能体之间传递因果知识（来源、泛化理由、替换指南），调用图则提供确定性的依赖上下文；消融证明去掉调用图后准确率 77.21→74.48、Erosion 0.0987→0.1409（迁移后死代码残留），去掉抽取前整合后 Verbosity 0.0994→0.1264，两者缺一不可。评估层面：论文把单任务编码基准改造成顺序套件（WebGen-Bench 3 个 8 任务套件、PaperBench 5 个 4 任务套件，每个 3 次试验），并发明两类新评测——构造后的共享策略更新维护、以及“库作为先验”的任务知情消融——配合覆盖 LOC/token/MDL/Erosion/Verbosity/库利用率/抽象层级的多维指标体系，这套协议本身对后续研究有方法论价值。
实验结果
逐实验分析如下。（1）初始构建（Table 1）：WebGen-Bench 上所有方法功能相当（SLA-FULL 准确率 77.21 vs Zero-Shot 76.04，+1.5%，配对检验不显著），说明用库不伤任务性能；可维护性上 SLA-FULL 在 LOC、token、Erosion、Verbosity 四项最优：LOC 8552（−9.0%，p=0.001）、token 65633（−6.7%）、Erosion 0.0987（−4.4%）、Verbosity 0.0994（−38.0%）。LIBRARIAN(K=8) 靠 best-of-K 采样拿到最低 MDL 33919，但其 Erosion 反升至 0.1352（高于 Zero-Shot 的 0.1032）；两个 NAIVE 变体虽缩小体积却把 Erosion 推到 0.1567/0.1250——无引导的库抽取会把复杂度集中到共享组件。PaperBench 上 SLA-FULL 五项可维护性全部最优（LOC 6252 −5.0%、Tok 63514 −7.4%、MDL 29489 −2.8%、Erosion 0.2291 −10.4%、Verbosity 0.8490 −2.0%），Code-Dev Score 0.4809 也最高（+2.6%），而 LIBRARIAN 的事后 MDL 选择对 MDL 和功能都无改善。（2）配对显著性检验（Table 6，n=24/20）：vs Zero-Shot 在两基准上 Tok 和 Verbosity 显著降低（p≤0.01），vs 两个 NAIVE 基线 Erosion 显著降低（p=0.002–0.004），所有功能指标无显著差异——可维护性收益不以牺牲任务性能为代价。（3）构造后维护（Table 2）：对每个 WebGen 套件施加同一条跨应用策略更新（如“表单邮箱必须含 @ 和点”），SLA-FULL 补丁仅 256 行（应用 232 + 库 24）vs Zero-Shot 936 行（−73%）、NAIVE-WARD 380、LIBRARIAN 522，触碰文件 19.9 个 vs 29.8 个，且原始行为保持 77.4、新请求满足率 80.0、外观 3.86 与基线相当——共享库把共享变更集中到一处，正是 SLA 问题定义的动机所在。（4）消融（Table 3）：NL 摘要候选选择在 5 项可维护性指标中 4 项最优且抽取出最多组件（库 815 LOC），但准确率降到 72.95（额外的共享组件给智能体引入 bug 的机会），这一不准确性由调用图条件弥补；去掉抽取前整合后 Verbosity 0.1264、Erosion 0.1263、LOC 8733 均变差，而 MDL 反而更低（33880 < 34195），暴露 MDL 度量的盲区（作者归因于参考 LLM 的训练数据质量）；去掉调用图条件后准确率 74.48、Erosion 0.1409，原因是迁移智能体无法正确处理结构性依赖更新、替换后常留死代码。（5）库利用与抽象质量（Table 4、Figure 4）：SLA-FULL 平均暴露 13.3 个导出符号（NAIVE 8.2/7.2、LIBRARIAN 4.2），其中被 6–8 个应用复用的 4.8 个、被 3–5 个复用的 6.0 个；对被 ≥4 个应用导入的高复用符号分类，各方法原始 UI 组件数量相当，但 SLA-FULL 捕获的行为 hook/工具（如 useSearchFilter、useFormValidation、createAuthContext）和页面/领域级模式（如 FeatureCardGrid、MessageBanner）显著更多——摘要引导的抽取拓宽了库的语义覆盖而非只堆砌原始组件。（6）库作为先验（Table 5）：让普通编码智能体生成 8 个内容展示应用，有库访问时 UI 测试准确率 80.95%→84.35%（+3.40）、外观 3.83→3.92，即使算上库本身总 LOC 也降约 11%（应用侧 8256→6567，总量 −940 行），MDL 仅 +135。（7）LOC 动态（Figure 3）：SLA-FULL 随应用增多持续削减应用本地代码，朴素脚手架轨迹平坦——说明光有共享库不够，还需可靠的候选发现与迁移。（8）推理成本（Table 15/16/17）：SLA-FULL 总开销 8.3× Zero-Shot（WebGen）、3.1×（PaperBench）；迁移会话复用可省 11.7% 成本、27% 迁移轮次且六项质量指标统计不变，但依赖 97% 的缓存命中，无缓存折扣时仅省 1.9%；把每轮应用数 m 从 2 提到 8 成本降到 4.93×，但准确率 −3.6%、LOC +4.4%、Verbosity +11.1%。（9）鲁棒性与边界（Table 18/19/20）：换 minimax-m3 骨干核心结论保持（LOC/token/Verbosity 仍最优）；在跨 13 个主题组的 16 任务低复用压力套件上 SLA-FULL 仍产出最小组合（LOC 18557 vs Zero-Shot 23263）且 Verbosity 最低（0.121），但功能退化（Acc 77.45 < Zero-Shot 79.17、外观 3.29 vs 3.66）——应用几乎无共享结构时库收益有限；与 OpenHands、Claude Code 等单代码库脚手架对比，SLA-FULL 仍在 LOC（8552 vs 8712/8948）和 Verbosity（0.0994 vs 0.1349/0.1489）上领先，但 OpenHands 的 Erosion 0.0732 更低，说明 SLA 是脚手架之上的一层、两者正交可叠加。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Web 应用生成（WebGen-Bench，3 套件 × 8 任务） | Accuracy：可执行测试加权通过率（WebVoyager 执行，↑） | 77.21（SLA-FULL） | Zero-Shot 76.04；LIBRARIAN(K=8) 75.78；NAIVE-WARD 76.07 | +1.5%（配对检验不显著，功能不受损） |
| Web 应用生成 | LOC：组合总非空代码行（↓） | 8552 | Zero-Shot 9393 | −9.0%（p=0.001） |
| Web 应用生成 | Verbosity：冗余模式覆盖的逻辑行占比（↓） | 0.0994 | Zero-Shot 0.1603 | −38.0%（p=0.001），全部方法中最低 |
| Web 应用生成 | Erosion：高圈复杂度函数的复杂度质量占比（↓） | 0.0987 | NAIVE-IMPLICIT 0.1567；NAIVE-WARD 0.1250；Zero-Shot 0.1032 | vs 两个 NAIVE 基线显著降低（p=0.002/0.004） |
| AI 论文复现（PaperBench Code-Dev，5 套件 × 4 任务） | Code-Dev Score：rubric 型 LLM 评审归一化得分（↑） | 0.4809 | Zero-Shot 0.4687 | +2.6%（不显著） |
| AI 论文复现 | 五项可维护性 LOC / Tok / MDL / Erosion / Verbosity（↓） | 6252 / 63514 / 29489 / 0.2291 / 0.8490（全部最优） | Zero-Shot 6578 / 68603 / 30342 / 0.2558 / 0.8665 | −5.0% / −7.4% / −2.8% / −10.4% / −2.0% |
| 构造后维护：跨应用共享策略更新（3 个 WebGen 套件） | Patch Size：补丁新增源代码行数（↓） | 256（应用 232 + 库 24），触碰 19.9 个文件 | Zero-Shot 936 行 / 29.8 文件；LIBRARIAN 522；NAIVE-WARD 380 | −72.6%，且功能保持（原始行为 77.4、新请求满足 80.0） |
| 库作为先验：有/无库生成 8 个内容展示应用 | UI 测试准确率（↑） | 84.35%（有库） | 80.95%（无库） | +3.40 个百分点，同时总 LOC 约 −11% |
| 库利用率与抽象质量（3 个 WebGen 套件） | 平均导出符号数与广复用符号数（↑） | 13.3 个导出；被 6–8 应用复用 4.8 个、3–5 应用 6.0 个 | NAIVE-IMPLICIT 8.2 / NAIVE-WARD 7.2 / LIBRARIAN 4.2 | 复用密度与行为级/领域级抽象占比显著更高 |
局限与改进
作者明确承认的局限有四点。第一，缺乏 SLA 原生基准：现有套件是对单任务编码基准的改造，任务本就取自同一主题簇、共享结构多，天然利于复用；没有基准专门测试长周期的库增长、跨应用复用与代码库维护，第 4.4 节只测了一轮部署后维护，且被维护的应用本身是没有用户、没有提交历史、没有生产环境的基准产物，补丁规模的缩减能否迁移到真实应用未被验证，也没观察需求持续漂移时共享库的表现、错误如何跨轮复合。第二，可维护性度量依赖代理指标（代码量、重复、冗长、库利用率），它们捕捉抽象与复用的信号，但不能完全度量代码库是否更易理解、修改和扩展；可维护性最终要通过未来反复的变更来揭示，而本文评估混合了最终代码库的静态属性和单轮维护。第三，自动化代码修改无人在环：迁移能通过功能检查仍可能改变检查未覆盖的行为，且一个库符号被许多应用导入，一次错误编辑会同时传播到所有应用——集中化既是收益也是风险；发布的应用代码库和库未经安全、可访问性、数据处理审查，不可部署。第四，骨干模型都在公开代码上训练，生成组件可能与现有实现相似，复用前需核查许可。我自己的观察补充五点：其一，成本偏高——WebGen 上 8.3× Zero-Shot，且唯一有效的省钱手段（会话复用）依赖 prompt 缓存定价，无缓存折扣只省 1.9%，而减少迁移轮次（m=8）又牺牲质量，成本-质量前沿尚未被认真刻画；其二，功能指标全程无显著提升，当前价值完全在可维护性侧，对低复用场景（压力测试中准确率 77.45 反低于 Zero-Shot 的 79.17、外观 3.29 明显落后）收益为负，适用边界需要明确声明；其三，附录 I 的导出清单显示库中存在 0% 复用率的符号（如 loadSubmissions、removeFromStorage、DataTable），说明候选选择仍有假阳性，“保守抽取”的提示词并未完全解决问题；其四，消融中 MDL 与结构指标方向背离（去掉本地整合后 MDL 更低但结构更差），作者仅推测是参考模型训练数据所致，这动摇了 MDL 在本设定下的可信度，也削弱了以 MDL 为核心的 LIBRARIAN 基线的代表性；其五，所有实验的骨干与评审都是 2025–2026 代闭源 API 模型（deepseek-v4-flash、gpt-5-mini、gpt-5.4-nano、Claude Opus 4.7/4.8），仅 minimax-m3 一组鲁棒性验证，对开源小模型的结论外推性未知。
独立分析的弱点
第一，抽取的召回-精度权衡未解决：NL 摘要候选选择让组件抽取量最大化（库 815 LOC），但准确率从 76.95 掉到 72.95，靠调用图条件才补回到 77.21——即候选选择本身会引入 bug，而系统没有候选级别的验证。改进方向：为每个候选库符号做差异化测试（用原实现与库实现在相同输入上对比行为），或让选择器输出置信度、只在高于阈值时抽取，把“保守”从提示词变成硬门禁。第二，迁移正确性只靠提示词加调用图上下文，没有编译/测试反馈回路：一次错误迁移会沿共享符号传播到所有导入应用（作者在伦理节自认）。改进方向：迁移后自动运行各应用的原有测试与 WebVoyager 冒烟用例，失败即回滚该符号的迁移；或采用影子迁移模式，先生成 diff 供审查再落盘。第三，评估只有一轮策略更新，而库的真正考验是多轮需求漂移：库符号 API 变更会引发跨应用连锁改写，库本身也可能腐化（0% 复用符号已现端倪）。改进方向：构造多轮更新序列，度量补丁大小随轮次的趋势、库符号的版本存活率与 API 稳定性。第四，抽象粒度受限于 AST 块加文件级调用图：Figure 4 显示 SLA-FULL 的页面/领域级组合抽象（如 FeatureCardGrid）虽多于基线但绝对数量仍少，跨文件的页面/路由级模式难以被“逐块摘要+选择”捕获。改进方向：把调用图升级为组件树/路由图，或允许选择器把多个块组装成候选“组合抽象”再评估泛化性。第五，批内并行假设批内应用同时可见（m=2、共 4 轮），真实组织中应用由不同团队异步开发、流式到达且不可等待成批。改进方向：流式库更新加语义版本化的库 API（兼容层、弃用流程），让迁移可在任意时刻对任意应用触发。第六，成本结构不利于普及：8.3× 的开销对多数团队过贵，会话复用仅省 11.7% 且依赖缓存定价。改进方向：把摘要、选择等简单环节蒸馏到小模型；用“复用密度预测器”决定哪些轮次值得触发迁移，跳过低收益轮次。
未来方向
作者提出的方向：一是构建 SLA 原生基准——包含足够共享结构的相关应用流，同时测试共享库如何支撑演进的维护请求；二是把评估扩展到真实应用上的多轮维护、跨应用更新一致性、回归频率，以及人类对抽象质量的判断；三是在用于人们依赖的生产软件之前，加入生成 diff 的人工审查和比基准环境更强的回归测试。基于本文成果可自然延伸的研究：（1）库版本管理与 API 演化：给超级库引入语义版本与弃用机制，研究库符号 API 变更的自动传播与兼容层生成——这是“维护”从一轮走向持续的必经之路；（2）与持续集成融合：把 SLA 变成 CI 中的常驻重构机器人，以测试通过率和回归率为抽取/迁移门禁，把 Table 2 的单轮补丁扩展为补丁流；（3）“库课程”式生成：Table 5 已证明成熟库可使新应用生成准确率 +3.4 个百分点，可进一步研究先建库后生成的两阶段规划，或在新应用生成时主动检索库组件（RAG 式复用）；（4）跨框架库移植：把 React hooks 库映射为 Vue composables 或其他技术栈，测试抽象的语言无关性；（5）把 Erosion/Verbosity 等在线可计算的结构信号作为 RL 奖励，训练编码智能体自身的复用倾向，而非依赖外挂脚手架；（6）与 MDL 目标统一：本文显示 LIBRARIAN 的事后 best-of-K MDL 选择未带来结构收益，在线设定下的 MDL 最小化（把抽取决策建模为对 $\mathrm{MDL}(C_N, L_N)$ 的贪心下降）可能是更原则化的库构建目标，但需先修复 MDL 度量本身的盲区（消融中它已与结构指标背离）。
复现评估
开源情况良好：代码在 https://github.com/sbigstar0310/super-library-agent，MIT 许可，包含系统源码、所有报告数字背后的指标与结果文件、最终轮应用代码库及抽出的超级库。外部依赖全部开放：WebGen-Bench、PaperBench（MIT）、WebVoyager（Apache 2.0）、mini-SWE-agent（MIT）、cocoindex-code（Apache 2.0）、Qwen2.5-7B（Apache 2.0）。复现细节充分：Algorithm 1/2 给出完整流程，Appendix H 给出索引渲染格式、抽取/迁移候选选择提示全文、抽取轨迹实例与调用图注入示例，Appendix A–E 交代了套件构造（对 101 个 WebGen 任务用 Ward 聚类 k=14 选簇、每簇取离质心最近的 8 个任务）、容器环境（27 个预装包、--network=none 禁网）、布局描述的生成方式（Claude Opus 4.7 从原始指令渲染参考页并描述布局，所有方法共用以控制设计方差）、各 API 模型的角色分工与显著性检验协议。主要障碍在算力与成本：无本地训练，全部是 API 调用，但骨干是闭源模型（deepseek-v4-flash 主智能体、gpt-5.4-nano 摘要、gpt-5-mini 外观评审与解析、Claude Opus 4.7 布局描述、claude-opus-4.8 策略撰写）；Appendix C 显示单个 WebGen 组合的迁移部分约 $0.40–0.45，而主表需要 3+5 个套件 × 6 个方法 × 3 次试验，粗估总花费数百至上千美元。难度评估：中等。脚手架本质是提示词级工程加确定性工具（AST 索引与文件级调用图构建均无 LLM 参与），方法描述足以重实现；最大的不确定性是闭源模型的版本漂移（论文已用 minimax-m3 验证过一次骨干鲁棒性，可作为复现者参照），以及 WebGen 套件对 Claude 4.7 生成的布局描述的依赖——若不复现该步骤会引入设计方差，影响可维护性指标的可比性。
论文图表
左侧展示朴素逐个生成：三个请求 $x_1, x_2, x_3$ 各自生成独立代码库 $c_1, c_2, c_3$，每个都重复实现 UI、State、Chart、Form 等共享逻辑，标注 Low maintainability；右侧展示 SLA：同一请求流由共享的可复用组件（超级库 $L_t$）支撑，三个代码库复用库中的组件，标注 High Maintainability。
一图定义全文问题：直观对比“隔离生成导致逻辑重复”与“共享库带来高可维护性”，是理解 SLA 问题设定的起点。