一句话总结

韩国科学技术院（KAIST）和 DeepAuto.ai 的研究人员提出了 Super Library Agent 问题，涉及在维护共享的 Super Library 的同时，顺序生成包含 $N$N 个相关应用的产品组合，并通过基于代码块摘要的候选引导提取、提取前合并以及上下文感知迁移来解决提取失败问题，在 WebGen-Bench 和 PaperBench 上保留了功能，同时减少了冗余和 token 占用。

核心贡献

• Super Library Agent 问题被形式化为一个在线设定：一个编码 agent 顺序构建一系列相关应用，同时维护一个包含可复用跨应用组件的共享 Super Library。
• 为克服提取召回率低和依赖迁移脆弱的问题，使用基于摘要的代码块索引和基于 LLM 的候选选择的候选引导提取，上下文感知迁移则将提取轨迹和调用图信息提供给依赖迁移 agent。
• 在 WebGen-Bench 和 PaperBench 上的评估表明，该方法能够保留应用功能，减少冗余和 token 占用，并在可维护性指标、库利用率和抽象质量方面优于零样本和朴素库基线。

引言

作者致力于解决使用 LLM 编码 agent 构建和维护相关应用产品组合时面临的挑战：独立生成会重复共享逻辑，违反 DRY 原则。这种重复被 LLM 产生的代码冗余进一步放大，使得跨多个应用的维护变得日益脆弱。先前的库学习技术或者将抽象视为对现有代码库的事后处理步骤，或者假设只有一个项目，从而未探索多仓库、在线的设定。核心贡献在于 Super Library Agent 问题的形式化，以及一个解决两个核心障碍的框架：在识别不同实现中的可复用组件时提取召回率低，以及在将这些组件移入共享库时依赖迁移脆弱。作者引入了基于摘要代码索引和 LLM 选择器的候选引导提取，并配合利用提取轨迹和调用图信息的上下文感知迁移，以安全地更新导入语句和调用点。

方法

作者将 Super Library Agent 问题形式化为一个顺序多应用构建任务。给定一系列应用请求 $x_1, \ldots, x_N$x1​,…,xN​，一个 agent 必须构建每个代码库，同时逐步维护一个共享的 Super Library $\mathcal{L}_t$Lt​。在第 $t$t 步，根据之前的代码库 $\mathbf{C}_{<t}$C<t​ 和库 $\mathcal{L}_{t-1}$Lt−1​，agent 生成新的代码库 $c_t$ct​、更新后的库 $\mathcal{L}_t$Lt​ 以及修补后的先前代码库 $\mathbf{C}_{<t}'$C<t′​：

$$(c_t, \mathbf{C}_{<t}', \mathcal{L}_t) = \mathcal{A}(x_t, \mathbf{C}_{<t}, \mathcal{L}_{t-1}).$$(ct​,C<t′​,Lt​)=A(xt​,C<t​,Lt−1​).

理想的库 $\mathcal{L}_t^\star$Lt⋆​ 包含所有被至少两个应用使用的组件，而特定于应用的代码则保留在本地。agent 针对功能（请求满足度）和可维护性（整个联合代码库中正确的提取、去重、复用和一致性）之间的帕累托权衡进行优化。

用作朴素基线的最小化 agentic 框架，通过每一步的两个粗糙阶段来处理这种映射。一个编码 agent 根据请求 $x_t$xt​ 生成初始代码库 $c_t^0$ct0​，并在可能时复用现有库组件。然后，一个单一的库 agent 联合提取共享组件到 Super Library 中，并迁移所有先前的代码库以使用更新后的库，从而生成 $\mathcal{L}_t$Lt​、$c_t$ct​ 和 $\mathbf{C}_{<t}'$C<t′​。这种未区分步骤的交接导致了在识别可复用代码块时召回率低，以及在迁移过程中破坏现有应用的风险。

为克服这些限制，增强后的框架将单一的库阶段分解为两个专门的 agent：库提取 agent 和依赖迁移 agent。提取 agent 负责更新 $\mathcal{L}_t$Lt​；迁移 agent 修补先前的代码库。它们由两个互补的策略支持。

首先，基于索引的候选提取从表面形式匹配转向语义层面的推理。每个代码库和库中的代码块通过 AST 边界（函数、类、模块）识别，并由 LLM 用自然语言进行总结，生成一个紧凑的代码摘要索引。然后，一个专门的基于 LLM 的候选选择器比较这些摘要以完成两项任务：提取候选（跨多个应用使用的代码块）和迁移候选（与它们可以替换的本地代码块配对的库符号）。在跨应用提取之前，一次性的合并步骤会重构每个新应用内部重复的本地代码，从而进一步完善索引。

其次，上下文感知的依赖迁移连接了提取 agent 和迁移 agent，并协调本地编辑。提取 agent 为每个新的或更新的库符号生成一个结构化的提取轨迹，记录其来源、泛化模式和替换指南。该轨迹被转发给迁移 agent，从而无需重新发现对应关系。此外，调用图条件化步骤为每个迁移候选附加一个“also-refactor”列表，包含相关的导入声明和调用者/被调用者关系。这提示 agent 更新依赖关系、移除死代码并消除过时的本地实现，从而减少损坏的引用和重复。这些策略共同使系统能够迭代地将代码库产品组合重构为可维护的、库驱动的结构。

实验

评估使用来自 WebGen-Bench 和 PaperBench 的顺序编码任务套件，将逐步构建共享库的 Super Library Agent 与零样本生成和事后库构建进行比较。SLA-Full 始终获得最佳的可维护性指标——更低的代码大小、结构侵蚀和冗长度——同时保留了应用功能，并且它通过将变更集中在库中，在共享策略更新期间显著减少了补丁大小。消融研究表明，摘要引导的候选选择、提取前合并和调用图条件化迁移各自提高了库质量，使库能够捕获超越简单 UI 原语的多样化行为和领域级抽象。此外，一个成熟的 Super Library 可以充当复用先验，以提高未来应用生成的准确性和紧凑性。

所有方法在 WebGen-Bench 上实现了相当的功能，表明库的使用不会损害任务性能。SLA-FULL 获得了最佳的可维护性分数（LOC、token 长度、侵蚀、冗长度），与零样本相比有统计学上显著的减少，而 LIBRARIAN 的 best-of-K 选择降低了 MDL，但增加了侵蚀。在 PaperBench 上，SLA-FULL 在所有五项可维护性指标上均达到最低值，同时保持了相当的代码开发分数，而朴素的未引导提取变体减少了一些大小指标，但将复杂性集中到了共享组件中。零样本、LIBRARIAN 和朴素变体在 WebGen-Bench 上都达到了相似的准确率（75-77）和外观（≈3.9）。SLA-FULL 实现了最佳的可维护性结果，相对于零样本，显著减少了 LOC、token 长度和冗长度。LIBRARIAN（K=8）获得了最低的 MDL，但侵蚀反而高于零样本。Naive-Implicit 和 Naive-Ward 减少了 LOC 和 token，但受到更高的侵蚀，这表明未引导的库提取将复杂性集中了起来。在 PaperBench 上，SLA-FULL 在所有五项可维护性指标上得分最低，同时保持与其他方法相当的代码开发分数。LIBRARIAN 在 PaperBench 上的事后 MDL 选择在 MDL 或功能方面没有比零样本有改进。

SLA-FULL 通过将共享更新集中在 Super Library 中，所需的总补丁大小最小，大幅减少了应用级的编辑。其他方法直接对应用应用较大的补丁，而补丁后通过率和外观质量在所有方法中保持相当。这表明以库为中心的维护可以在不损害功能的情况下简化更改。SLA-FULL 产生了最小的总补丁大小，大部分更改应用于共享库而非单个应用。原始和请求行为的通过率在不同方法之间相似，表明较小的补丁并未降低功能。

基于自然语言摘要的候选选择在朴素策略中提供了最佳的可维护性分数，而 SLA-FULL 通过添加调用图条件化和提取前代码库合并进一步提高了准确性。由此产生的 Super Library 更大、复用更广，并捕获了超越原始 UI 组件的更丰富的抽象层，从而减少了冗余，改善了后续应用生成。自然语言摘要方法识别出最多的共享组件，并在五项可维护性指标中的四项上获得最高分。放弃提取前合并会增加冗长度、结构侵蚀和总代码行数，表明它有助于库 agent 在单个代码库内抽象组件。移除调用图条件化会损害迁移准确性，留下死代码，并提高冗长度和侵蚀，表明结构化的调用者-被调用者上下文对于干净的依赖替换至关重要。SLA-FULL 导出更多被许多应用复用的库组件，并提取行为钩子和页面级模式，而朴素方法则局限于浅层的 UI 组件和薄弱的实用工具。在顺序轮次中，SLA-FULL 稳步减少了每个应用的本地代码，而朴素的共享库则显示出更平坦的轨迹，没有可靠的候选发现和迁移。

SLA-FULL 生成的 Super Library 比朴素变体大得多，平均导出组件多约 60%。它还实现了更广泛的复用，跨 3-5 个和 6-8 个应用共享的组件更多。这种扩展反映了超越原始 UI 元素的更高层次抽象的提取，这有助于稍后生成更准确且总代码量更少的应用。SLA-FULL 平均导出约 13 个组件，而朴素方法为 7-8 个。被 6-8 个应用复用的导出组件数量翻倍以上，从朴素变体中的约 2-3 个增加到 SLA-FULL 中的近 5 个。

当一个普通的编码 agent 使用成熟的 Super Library 来生成内容呈现应用时，UI 准确率显著上升，并且应用本地代码减少。即使算上增加的库代码，总代码行数也减少了约 11%，可维护性仅有轻微变化。在有库访问的情况下，UI 准确率从 80.95% 提高到 84.35%。总代码行数（应用加库）下降了约 11%，尽管库本身有代码贡献。

在 WebGen-Bench 和 PaperBench 上的实验评估了 Super Library 方法用于多应用代码生成和维护。SLA‑FULL 始终获得最佳的可维护性分数，与零样本基线相比，代码大小、token 长度、侵蚀和冗长度显著降低，而所有方法都达到了相当的功能准确性和外观，这证实了面向库的结构化不会损害任务性能。消融实验表明，调用图条件化和提取前合并对于提取超越浅层 UI 组件的更丰富、更可复用的抽象至关重要，从而产生了一个显著更大的 Super Library，被更多应用共享，并推动了各轮次中应用本地代码的稳定减少。维护评估进一步表明，将编辑集中在库中可产生最小的总补丁大小，而不会降低通过率，且配备此成熟库的下游编码 agent 获得了更高的 UI 准确率，并使总代码行数整体减少了 11%。