Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase
Daegyu Sung, Yukyeong Lee, Geon Park, Yumin Choi, Sung Ju Hwang
EMNLP 2026
cs.SE, cs.AI, cs.CL
2026-08-29
KAIST的Super Library Agent一边写一组相关应用一边维护共享库，WebGen上代码行数降9%、啰嗦度降38%，跨应用策略补丁从936行降到256行且功能基本持平。
LLM 编码 Agent 已经能端到端写出一个网站、复现一篇论文。组织里更常见的是一批相关应用：同一套 UI、状态管理、表单校验，被每个 Agent 各写一遍。代码能跑，DRY 被打破，修一个 bug 要在 N 个仓库里同步。长时间的 Agent 维护还会堆出 SlopCodeBench 里那种功能正确但越写越啰嗦的 slop。
KAIST 和 DeepAuto.ai 把这件事写成 Super Library Agent 问题：应用请求按序列到达，Agent 每写一个新应用，都要维护一份跨应用共享的 Super Library，并把旧应用迁过去。单仓 Librarian 明确把多仓库建库留作开放问题，这篇接的就是那一块。
最小脚手架分两步：先按请求写新代码，再让一个库 Agent 同时抽公共组件并迁移依赖。实验里这个 SLA-NAIVE 抽不全，迁移也脆。完整版 SLA-FULL 把库 Agent 拆成抽取和迁移两个角色。
共享库的理想内容是至少被两个应用用到的组件。应用专属逻辑留在本地。
WebGen-Bench 三个 8 任务套件、PaperBench Code-Dev 五个 4 任务套件，各跑三轮。功能几乎不动，可维护性拉开。
| 方法 | WebGen Acc | LOC | 啰嗦度 | PaperBench Code-Dev | 补丁行数 |
| Zero-Shot | 76.04 | 9393 | 0.1603 | 0.4687 | 936 |
| Librarian (K=8) | 75.78 | 8973 | 0.1472 | 0.4591 | 522 |
| SLA-NAIVE-Implicit | 76.95 | 9133 | 0.1408 | 0.4802 | 632 |
| SLA-FULL | 77.21 | 8552 | 0.0994 | 0.4809 | 256 |
相对 Zero-Shot，SLA-FULL 在 WebGen 上 LOC 降 9.0%、token 降 6.7%、啰嗦度降 38.0%；PaperBench 上 LOC 降 5.0%、token 降 7.4%、结构侵蚀降 10.4%。跨应用策略补丁从 936 行降到 256 行，应用侧从 936 降到 232。功能差异统计上不显著。
Librarian 用 MDL 挑最好的重构，WebGen 上 MDL 最低，结构侵蚀却比 Zero-Shot 更高。Naive 脚手架也会把复杂度堆进共享组件。SLA-FULL 平均导出 13.3 个符号，被 6 到 8 个应用复用的有 4.8 个；Naive 大约 2.0 到 2.7 个。抽到的不只是 Header、Footer，还有 useFilteredList、FeatureCardGrid 这类行为和页面级抽象。成熟库当先验再写 8 个展示类应用，准确率从 80.95 提到 84.35，应用本地代码还少了。
给「Agent 写一整个产品线」的团队一个能落地的结构：共享逻辑抽一次、修一次。补丁缩小约 73% 是最接近真实维护价值的数字。这是渐进工程改进，不是新的代码生成范式。适合 UI 组件、训练循环、数据管线这种天然可复用的组合。现有单任务编码榜不能直接当 SLA 榜用，要自己切成序列套件。
作者写得很清楚。现有榜不是为长程建库设计的，维护实验只做了一轮，应用没有真实用户和提交历史，补丁缩小能不能活到生产未知。可维护性指标是规模、重复、啰嗦度的代理，不等于更好懂、更好改。自动迁移一次改错会顺着共享符号扩散到全部应用。骨干只用了 DeepSeek-v4-flash，换模型数字会不会跟着走，论文没测。