Super Library Agent：连写八个应用，共享代码只留一份

应用从不孤立：为什么"每个应用各写各的"本身就是问题？

一个团队要一口气交付一组网站：一个博客、一个商城、一个后台管理面板。三个网站都要登录、都要分页、都要暗色主题。让 AI 编码智能体分别写这三个应用，它会在每个项目里各放一份登录组件、各写一遍分页逻辑。这看起来再正常不过，直到产品经理说"登录页的文案改一下"。你要同时改三个地方，改漏一处，三个应用的用户体验就开始悄悄分岔。要是这三份登录组件合并成一份、被三个应用共同引用，改动就只落一个文件。这句话听起来像常识，可惜市面上主流编码智能体的默认设定几乎都是"一个任务一个仓库"、各写各的。这就是可维护性的真面目：不是代码好不好看，而是改得动、改得净、改一处不会牵连另外八处。

分叉还会越滚越大，因为应用总是一个接一个到达的，不是一批到齐。真实需求就是这样：需求边来边做，你不可能等全部想清楚再开工。KAIST 团队的这篇 Super Library Agent（SLA）把场景就设在这条时间线上：一个编码智能体按顺序接到一组相关应用的请求 x₁ 到 x_N，每个新应用到达时，智能体不只写新代码，还要回头改写之前的代码库，把旧应用里已经存在的重复实现同步替换掉。这不是批量作业，是一条持续运行的流水线：每接一个新应用，就多一批散落在各处的副本、多几个分叉源头。改动的工作量跟着副本数线性涨，这正是"各写各的"真正贵的地方。

副本多了，改动就要追着副本跑，这个结怎么解？既然分叉的根是复制，那就把复制拆掉，SLA 想换掉的正是这条默认路径。药方很干净：凡是被至少两个应用用到的组件，就只留一份，放进一个跨应用共享的代码库，论文叫它 Super Library。新增应用从库里拿，旧应用里已有的重复实现被换成对库的引用。目标同时压两条线：功能满足，应用真的按需求工作；可维护性，共享代码被正确提取、去重、复用、更新。这不是先保功能、再顺手整理的先后关系，而是两个都要顶格的帕累托式双目标，任何一边打折都算失败。两条线是同一个承诺的两半：重复只剩一份，改动只落一处。SLA

图注：论文 Figure 1 的两幅概念对照，画的是同一个承诺的两种结局。左图每个应用框各自内嵌一份共享组件副本，右图同一组应用连到容纳去重后组件的共享库框。基本主张就藏在这张图里：独立生成等于复制粘贴，共享代码只留一份，改动才只落一处。SLA

分叉的代价为什么现在才付不起？过去两年，AI 编码智能体从"补全一个函数"进化到"自主写整个仓库"，单仓库基准上的成绩已经相当能看，但默认设定始终是"一个任务一个仓库"，独立生成因此几乎没有被真正当作问题来质疑。真实软件组织里应用几乎从不孤立：一家公司的小工具、内部系统、面向客户的产品，共享同一套登录、权限、支付和组件库。当 agent 从"被叫去修一个 bug"升级成"被要求一口气交付一组应用"，各写各的欠下的债就到了偿还的时候。而且"写"这件事本身越来越便宜，"改"的相对成本越来越高，谁在管共享代码、改一处要牵连几个地方，正在成为决定 AI 写出的软件能不能长期活下去的关键。

那这个承诺兑现起来，难点在哪？两笔账。Challenge 1 是认不出来：功能等价的代码块，表面形式经常毫无相似，登录组件一个用函数式写法、一个用类写法，按文本或 embedding 相似度检索，自然漏掉对方。漏掉的候选随应用数量增长而堆积，库越建越残。Challenge 2 是换不干净：把一份本地实现抽进库，等于动了所有依赖它的东西，import 声明、调用点、旁边搭着的小工具函数，一步漏改就留下坏引用、重复实现或死代码。这两个挑战的本质都是全局问题：单次调用里的 agent 看不到整个应用库的布局，所以靠提示词提醒"注意共享"解决不了，候选与迁移都必须被结构化。第一笔关乎"认出该共享的代码"，第二笔关乎"安全地换掉旧实现"，这两件事恰好是全文的骨架。

问题抛出后，先别急着看解法。独立生成这条路烂到什么程度，值得先量化一下。

单仓库路线为何不够：AI 会把代码越改越脏吗？

当前最强的编码智能体路线，以 SWE-agent 一系为代表，把任务钉在一个仓库内解决：一个 bug 报告进来，agent 在自己的仓库里搜索、修改、跑测试、反复迭代。这个设定成就了 SWE-bench 上的一系列记录，但也埋了一个隐患：修改是累积的，而每一次小改动都在给下一次改动挖坑。SWE-agent

SlopCodeBench 专门量化了这件事。在 36 个问题、196 个检查点组成的长程迭代里，77% 的轨迹结构性侵蚀在上升。侵蚀的意思是，复杂度往少数高复杂度函数里集中，代码块越改越大、越改越绕。论文记录过一个极端样本：某个模型在单个任务上，把 main() 一个函数从圈复杂度 13 改到 92，行数从 38 涨到 240。同时 75.5% 的轨迹冗余度在上升，冗余指重复代码和规则标记的冗余模式占总代码的比例。对照 473 个开源 Python 仓库的历史，agent 生成的代码平均冗余 2.3 倍、侵蚀 2.0 倍。SlopCodeBench

图注：SlopCodeBench Figure 2 的归一化轨迹对比。erosion 与 verbosity 两个面板中，agent 检查点曲线全程压在按 GitHub star 分箱的 473 个人类仓库曲线之上、终点更高，阴影为 95% 置信区间。SlopCodeBench

为什么会越改越脏？不全是 agent 的错，机制上就偏向脏。改一个功能时，最省事的动作是在现有函数上打补丁，重构需要更多步骤、承担更大风险；而函数一旦变复杂，下一次改动就更倾向继续堆在里面，侵蚀于是成了自增强的循环。冗余那边还有个反直觉的细节：agent 的重复粘贴暴涨 96%，而新引入的规则违规几乎没增加，只有 0.3%。它不是在发明新错误，而是在反复改写和复制已有代码。放到跨应用场景就是放大版：八个应用各复制一份、各自打补丁，同一段逻辑慢慢长出八份渐行渐远的实现。还要注意，这些结果是在各家模型自己的原生 harness 里测出来的，不是被某个笨重框架拖累的结果，这至少表明现象并非某个外加框架独有，不能只靠更换 harness 消除。反过来看人类那侧：473 个仓库跨越 13667 次提交的历史里，退化温和得多——冗余上升的占 68%、侵蚀上升的占 53%，且斜率中位数只有 agent 的约 1/5 到 1/6。

更麻烦的发现是，给 agent 加上专门的 anti-slop 提示词，只能把曲线起点压低，改不了斜率。而且提示词干预不是免费的：加了 anti-slop 和 plan-first 提示之后，每个检查点的成本平均上升 12.1%，严格通过率还掉了 1 到 3 个百分点。脏是结构性倾向，不是劝两句就能劝回来的。这条证据的推论值得停下来想：一个 agent 连在自家一个仓库里维护自己写过的代码都会越改越脏，那让它跨应用复制粘贴共享代码、再各自独立演进，只会更糟。提示词拦不住斜率，就只能靠结构来防，把共享代码显式抽出来，放在一个被统一维护的地方，而不是让每个应用各持一份、各自腐烂。剩下来的问题是，把共享代码抽出来管理，这件事前人做过吗？

库学习补得上这个洞吗：为什么"事后重构"救不了在线维护？

"让系统自己从一堆程序里归纳可复用抽象"，是程序合成领域的一条老传统。DreamCoder 在 2021 年登上 Science：它用 wake-sleep 式的循环，清醒阶段解题，睡眠阶段从解出的程序里提炼公共片段、加入程序库，再用扩充后的库生成"梦境"任务反哺识别网络。库越长越深，新任务越容易解，这是库学习最早的完整闭环。在一道 list 处理这类任务上，它能自动归纳出大约 20 个可复用的操作原语。后来的 Stitch 把压缩步骤做快了 3 到 4 个数量级，LILO 第一次把 LLM 放进库归纳的闭环，让抽象对人类可读。这条谱系的核心模式始终是"学到的抽象跨任务复用"，但共同边界也很清楚：任务停在 λ-演算级别的小程序、规模在每域 100 到 200 个任务、设置是离线批量。所谓 λ-演算级别，就是几十行以内的玩具程序，抽象长在列表操作、算术这类通用原语上；而 SLA 要面对的，是动辄几百行、带 import 网络和业务语义的多文件应用，抽象的形态完全不同。尺度错位，正是整条谱系一直没有跨过真实软件门槛的原因之一。DreamCoder

把这条传统推到真实 Python 仓库的是 Librarian。它拿到一组已经写完的文件，先采样多份候选新库，再按最小描述长度选优，最后把旧文件逐个改写为依赖这个库。MDL 的直觉很简单：把代码压到最短、同时压完还自然，就用这条长度衡量代码好不好。一段能用语言模型高效压缩的代码，说明它规律性强、好理解。在 HuggingFace Transformers 的真实文件上，Librarian 把 MDL 压到了原始值的 67.2%（本簇内的压缩比），把学到的库迁移到未见过的簇还能压到 73%，且都通过全部集成测试。它甚至做过人因实验：14 个人、129 次两两比较，MDL 选出的库明显比 token 数、维护性指数选出的更讨人喜欢。不过 Librarian 自己在局限里也承认，压缩和复用不一定相关，压得短不代表别人愿意用、用得上。Librarian

图注：Librarian Figure 1 的整体骨架。左侧一组原始 Python 文件，中间抽出一个含共享函数与共享类的新库，右侧每个原始文件被改写为依赖该库。这是"完稿后重构"路线的标准形状。Librarian

但注意 Librarian 的工作方式：完稿之后才动手。库不参与生成过程，新应用到达时也没有人回头改旧库。这是 post-hoc，事后重构。"不参与生成"意味着什么？第一个应用本来有机会用上抽象的机会被白白浪费，第二个应用来的时候，旧库既没更新也不能直接引用。维护成本没有消失，只是从"生成时"推迟到"重构时"一次性爆发。把这条路线和 SLA 想要的放在一起看，缺口立刻露出来。SLA 要的是在线：应用一个接一个到达，每来一个，共享库实时更新，旧应用里的重复实现被同步替换。从 DreamCoder 到 Librarian，每一站都解决了上一步的某个瓶颈，却没有任何一站碰过"在线维护"这个维度。

图注：库学习谱系图。共同模式是"学到的抽象跨任务复用"，每一跳解决上一站的瓶颈：DreamCoder 立范式、Stitch 提速、LILO 引入 LLM、Librarian 走向真实仓库，而在线维护是 SLA 新开的一环。DreamCoder

把"事后重构"搬进生成流程本身，就是 SLA 的位置。问题只剩一个：具体怎么搬？

两把刀：怎么"认出"该共享的代码，再"换"掉旧实现？

SLA 先立了一个最简骨架当靶子，叫 SLA-Naive：一个 coding agent 写新应用，一个 library agent 同时做提取和迁移，没有候选选择，也没有结构化的交接。两个挑战全靠 agent 临场发挥。论文把 SLA-Naive 的两种候选策略都跑了一遍当对照：Naive-Implicit 完全不做选择，Naive-Ward 用 Ward 聚类选候选。为什么这个骨架注定翻车？因为提取和迁移是两种失败模式完全不同的事：判断"哪些代码值得共享"考的是全局视野，保证"换掉后整个项目还能跑"考的是局部精确，混在一个 agent 手里一把抓，就只能两头碰运气。这相当于先证明裸奔的代价，再展示 SLA-Full 的两把刀怎么补上。

图注：论文 Figure 2 的宽幅流程对照。左半是最简骨架 SLA-Naive，coding agent 之后单个 library agent 一把抓提取与迁移；右半是 SLA-Full，增加代码块索引、候选选择器、带 extraction trace 的库提取和 call-graph 条件迁移四段结构。SLA

先看左半的失败模式，再看右半怎么补。刀一对位 Challenge 1，叫基于索引的候选提取（Index-based candidate extraction）。每个代码库和 Super Library 都维护一份代码块索引：代码块按函数、类、模块的 AST 边界切开，每一块配一段由 LLM 写的一句话摘要。注意索引是双向的，库自己也在索引里，因为库会随每轮提取长大，检索库侧时也要能按摘要找。为什么按 AST 边界切而不是按行切？函数、类、模块是代码的天然单位，切错边界会把半拉子功能当成候选。为什么配一句话摘要而不是只看 embedding？因为两个行为等价的代码块在向量空间里可能离得很远，摘要把比较拉回到语义层：目录里写的是"这个模块做什么"，而不是"这个模块长什么样"。候选选择器不看表面相似度，而是同时产出两类清单：哪些代码块该抽进库，论文叫提取候选；哪些库组件能替换应用里的旧实现，论文叫迁移候选。提取之前还有一步应用内 consolidation：先把单个应用内部自己重复的代码去重成共享模块，再跨应用提取。这一刀的本质，是给共享代码建一张带一句话摘要的目录。搬家时不再靠肉眼看箱子长得像不像，而是查目录里装的是什么，长得不像但装同样东西的箱子也能被找出来。顺着这个比方把整条流水线对一遍：目录是索引，查目录的图书管理员是候选选择器，搬家公司是迁移 agent，而刀二要讲的 extraction trace，就是搬家时交给搬家公司的那张"哪个箱子进哪个房间"的交接单。

刀二对位 Challenge 2，叫上下文感知的依赖迁移（Context-aware dependency migration）。每抽出一个库符号，library agent 就写一份结构化的 extraction trace：这个符号从哪里来、为什么这套模式能泛化到多个应用、怎么把旧代码换成库 API。迁移 agent 拿到的是别人写过的旧代码，它没有"为什么当初这么写"的上下文，让它从头推断对应关系，推断错了就换错地方。extraction trace 相当于把写库时的决策过程存档交接，迁移 agent 照着做就行。在此基础上，Call Graph Conditioning 再把相关 import 和调用关系列表直接钉进 prompt：换掉一个实现时，所有引用它的地方一起改，过时的本地实现一并删掉。SLA

把这两刀放到一个具体画面里。假设 8 个应用里有 4 个各写了一个分页组件，实现长得不完全一样，但行为等价。索引先认出这四块功能重叠，列为提取候选。提取前，consolidation 先把每个应用内部自身的重复理清，再跨应用抽出一个统一的分页组件进库。Extraction trace 记下这个符号的来龙去脉和替换方法，迁移 agent 按 call graph 清单把四个应用的 import 和调用点一起改掉、删掉本地实现。整套动作没有一步靠 agent 猜。SLA-Full 的全部奥义，浓缩成一句话：用索引认出该共享的代码，用轨迹与调用图换掉旧实现，两步都结构化，都不靠临场发挥。

这套设计跑出来效果如何？

省下的不只是行数：这些数字证明了什么？

先看评测怎么搭。SLA 拿两个现成的单任务基准来切 suite。WebGen-Bench 让 agent 从零写出可交互网站，用 WebVoyager 跑功能测试、LLM 打外观分，SLA 把它的任务切成 3 个互不重叠的 8 应用 suite。WebGen-Bench PaperBench Code-Dev 让 agent 复现论文代码、按 rubric 逐项判分，SLA 把 20 篇论文切成 5 个 4 应用 suite。PaperBench 为什么挑这两个？WebGen 测"从零写交互应用"的形态，共享逻辑长在 UI 组件和状态管理上；PaperBench 测"复现已有工程代码"的形态，共享逻辑长在训练与推理管线上。两种形态都覆盖，共享库的价值才不是某一类代码的特例。每个 suite 内应用按序到达，共享库一路携带，suite 之间独立。这里要强调一点：这些数字不是"8 个应用各跑一遍再汇总"，而是库在 8 个应用之间真实传递、旧库在每一轮被更新之后的端到端结果。功能侧，WebGen 让 WebVoyager 模拟真实用户操作网站并给出 YES / PARTIAL / NO，外观由 LLM 打 1 到 5 分；PaperBench 是 rubric 树的叶子节点逐条判分。两个基准的评测都依赖 LLM 判分，这也是论文在局限里承认"指标是代理"的伏笔。backbone 统一用 deepseek-v4-flash，执行 harness 是极简的 mini-SWE-agent：只留 bash、完全线性的历史，约 100 行 Python，把全部工程复杂度留给库这一层，而不是每步控制流。mini 版之所以敢这么极简，是因为它已经在 SWE-bench Verified 上用 100 行 Python 追平了原版 SWE-agent 的性能，控制流简单这件事本身是被验证过的。

先看维护性怎么度量。五个指标，覆盖"短不短、自不自然、脏不脏、冗余不冗余"：

Erosion 与 Verbosity 的定义沿用 SlopCodeBench，MDL 公式来自 Librarian 一系，SLA 把它改造成依赖感知的变体：每个文件的条件概率以它直接 import 的东西为条件，压缩得动依赖结构，才算真的规律。五个指标全在整份 portfolio（应用加共享库）上统计。

WebGen 上的核心结果（3 个 suite × 3 次试验平均）：

读表的重点不在 SLA-Full 拿下最低值，而在两个对照组。先看 Librarian K=8。它拿到了全场最低的 MDL（33919，表中未列），但 Erosion 反升到 0.1352，比 Zero-Shot 的 0.1032 还高。这个反超值得点破：压得最狠的库，结构上反而更糟。压缩不等于可维护，把代码压短可以，压完复杂度堆在一个地方，照样难改。再看两个 SLA-Naive 变体，它们同样把 Erosion 抬过了 Zero-Shot，说明没有引导的提取会把复杂度集中进共享库。而 SLA-Full 在准确率不降反升（76.04 → 77.21）的同时，LOC 降 9.0%、冗余（Verbosity）降 38%、侵蚀（Erosion）降 4.4%。SLA

功能不降反升这件事本身，就是论文最重要的发现。库学习历史上最大的风险是压缩伤功能，Librarian 的两个 K 值在 WebGen 上准确率都略低于 Zero-Shot，方向已经摆在那里。表里所有方法的功能分其实都挤在一个窄区间里（从 75.09 到 77.21），谈不上谁统治谁，但 SLA-Full 用共享库换来了更短的代码和更低的冗余，功能没有付出代价。WebGen 的外观分也说明同一件事：SLA-Full 拿到 3.86，和 Zero-Shot 的 3.84 持平，共享库没有牺牲观感。这一串结果回答了一个本该先问的问题：这不是拿功能换整洁。

PaperBench 上是同样的模式：Code-Dev 分数从 0.4687 微升到 0.4809，功能不受损，五个维持性指标全部最低（LOC −5.0%、Token −7.4%、MDL −2.8%、Erosion −10.4%、Verbosity −2.0%）。五个指标里降幅最大的是侵蚀（Erosion −10.4%）；冗余（Verbosity）最重的一刀落在 WebGen 上（−38%），这正好对应了故事的起点：独立生成产生的大部分脏东西就是重复，而共享库把重复连根拔掉。最能说明"改动集中"的是维护轮的数字：同一个跨应用修改需求发下去，Zero-Shot 要在 8 个应用里各改一遍，共 936 行；SLA-Full 把共享部分写进库、应用侧只做跟进调整，共 256 行（库里 24 行、应用侧 232 行），约为前者的 3.7 分之一。消融实验各自成立：去掉应用内 consolidation，准确率掉到 75.25；去掉 call graph 条件，准确率掉到 74.48。两把刀少一把都不行，连"选候选"也不是越宽越好，候选选得太多会把准确率拖到 72.95，靠 call graph 条件才兜得住。

省下来的不只有行数，还有"日后改得动"。论文还追踪了逐轮维护性的变化：随着应用一个接一个加入，SLA-Full 的应用侧本地代码持续下降，说明复用是在流水线行进中逐步积累起来的；而 naive 变体的曲线明显更平，光有一个共享库、没有可靠的候选发现和迁移，库就只是挂在那里的摆设。共享库的利用率也很能说明问题：SLA-Full 平均每轮向库暴露约 13.3 个共享组件，比两个 naive 变体多出 5 到 6 个，其中被 3 到 5 个应用复用的有 6.0 个，被 6 到 8 个应用复用的有 4.8 个。论文还把被 8 个应用中至少 4 个引用的库符号分类统计：纯 UI 控件、行为钩子、页面与领域模式。SLA-Full 不只是把按钮这类浅层控件收进库，还在行为钩子和组合式页面模式上明显更多。这说明库里的东西真的是可复用的设计，而不是把新代码改名塞进去充数。

图注：论文 Figure 4 的柱状图，按方法分组统计被至少 4 个应用 import 的库符号在纯 UI 控件、行为钩子、页面与领域模式三类中的平均数量。原文结论是 SLA-Full 在 primitive 之外的类别上捕获更多深层抽象。SLA

另一个数字很能说明成熟库的价值：让一个不带库的普通编码 agent 去写 8 个新应用，如果给它用 SLA-Full 攒下的最终库，平均准确率从 80.95 涨到 84.35，总行数再降约 11%。共享库不只在建设期省钱，还会让后续生成本身变强。

它走到了哪一步：值得用吗，还差什么？

先把判断收住。SLA 是库学习谱系里第一个把"维护"显式放进生成循环的工作：新应用到达、旧库实时更新、跨应用一致，这条在线维度它跑通了，在功能不降的前提下显著改善了代码质量与后续修改成本。什么场景值得用？一组相互关联的应用、存在大量共享逻辑、你愿意为"日后改得动"付出额外成本。反过来，如果这批应用彼此独立、共享逻辑很少，或者维护压力本来就靠人而不是靠代码结构撑着，这套架构就是杀鸡用牛刀。判断标准可以浓缩成一个评测内的自检：改一次共享逻辑，过去要动几个文件？这组结果提示，共享改动频繁时值得评估这套架构，但生产收益仍待多轮真实维护验证。成本不低：同一个 8 应用 suite，Zero-Shot 大约 10 分钟，SLA-Full 要约 1.5 小时，API 调用成本约为 Zero-Shot 的 8.3 倍（WebGen 上）。

论文自己把边界写得相当老实，四条值得逐条读。第一，没有 SLA 原生基准。两个评测都是借来切片的，当初都不是为测库增长和跨应用复用设计的，维护只测了一轮，长程漂移和累积错误观察不到。第二，维持性指标都是代理。MDL 在 LLM 评测下不稳定，LOC 不反映可读性；真正的可维护性要靠未来反复修改来检验，静态指标加一轮维护测不出这个。第三，集中风险。一个库符号被多个应用 import，一次错改就全域扩散。这恰恰是库有用的原因，也是它危险的原因，论文承认两者拆不开。第四，可复现性。项目 README 原话是 "Nothing reproduces exactly"：同样的模型铭牌会被 OpenRouter 路由到不同后端，两个判分器都是 LLM，单格数字差异要当噪声处理。项目页

"指标都是代理"这句不是套话，仓库里记着几个具体的翻车点。评测只读每个任务自己的 lib/ 镜像，手工拼的备份会把所有库指标报成零；库太大加上应用太大，可能把 MDL 请求推出 7B 模型的 32k 上下文窗口，超窗文件直接从分数里消失；连评测的数值精度都不能乱动，fp16 会让 MDL 跑偏 6% 到 10%，比各方法之间的差距还宽。这些细节说明同一件事：SLA 现在的数字是"在特定评测装置下成立"，不是"在任何环境都成立"。

8.3 倍的成本换 3.7 倍小的维护 patch，这组对比本身就是论文的自我定位：它赌维护贵于生成。在 AI 编码智能体从"写一个应用"走向"维护一组应用"的当口，这个赌注在评测内站住了脚，生产侧则如四条局限所指，仍待多轮真实维护验证。值得一提的是，论文标注的 EMNLP 2026 Findings 来自代码仓库 README 的 bibtex 自陈，还没有在 ACL Anthology 交叉核验，引用时值得留意。另外这是库学习谱系里提交时间最近的一站（arXiv v1 在 2026 年 8 月底），而且它复用的是别人的现成基建：WebGen、PaperBench、mini-SWE-agent 都是借来的，没造新轮子，这套思路今天就能在公开的基准上复现。后续值得盯的三件事也很明确：一个为库增长而生的 SLA 原生基准；跨真实用户、真实 commit history 的多轮维护实验，现在只测了一轮；以及单一 backbone（deepseek-v4-flash）之外的泛化验证，跨模型稳健性还没测过。它离生产还差这几步，但方向已经摆在那里：连写八个应用，共享代码只留一份；日后改动，只落一处。

想深入可以读原文：Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase，arXiv:2608.29310；项目页 sbigstar0310.github.io/super-library-agent 有 TEASER 五步动画（Request → Coding → Consolidate → Extract → Migrate）；GitHub 仓库 MIT 许可，README 里记录了各方法 arm 对应的环境变量。想亲手跑一遍也不难：克隆仓库、装好 Docker 镜像、按 README 配好 cocoindex 的 embedding 设置，一行脚本就能在 WebGen 的某个 cluster 上重现。README 里有两个值得先读的警告：PaperBench 的 cluster 3 是前几个 suite 的并集而不是第六个 suite，跑错会静默得到另一个实验；WebGen 评测要一次跑一个，并行的 vite 实例会争端口，可能让你丢 30 个准确率点。

参考文献

• [SLA 论文] Super Library Agent: Joint Generation and Maintenance of Multiple Applications Beyond the Single Codebase，arXiv:2608.29310，https://arxiv.org/abs/2608.29310
• [Librarian] Refactoring Codebases through Library Design，arXiv:2506.11058，https://arxiv.org/abs/2506.11058
• [SlopCodeBench] SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks，arXiv:2603.24755，https://arxiv.org/abs/2603.24755
• [WebGen-Bench] WebGen-Bench: Evaluating LLMs on Generating Interactive and Functional Websites from Scratch，arXiv:2505.03733，https://arxiv.org/abs/2505.03733
• [PaperBench] PaperBench: Evaluating AI's Ability to Replicate AI Research，arXiv:2504.01848，https://arxiv.org/abs/2504.01848
• [SWE-agent] SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering，arXiv:2405.15793，https://arxiv.org/abs/2405.15793
• [DreamCoder] DreamCoder: Growing generalizable, interpretable knowledge with wake-sleep Bayesian program learning，arXiv:2006.08381，https://arxiv.org/abs/2006.08381
• [项目页] Super Library Agent 官方项目页与代码仓库，https://sbigstar0310.github.io/super-library-agent/，GitHub: https://github.com/sbigstar0310/super-library-agent