Can Agents Design Libraries for Agents?
Gabriel Orlanski, Alex L. Zhang, Avi Trost, Vincent Sunn Chen, Frederic Sala, Aws Albarghouthi, Ludwig Schmidt
cs.AI, cs.CL, cs.SE
2026-09-29
用下游三个模型的正确率与简洁度给库打分。Opus 5.5得48.9,比生产库高2.3分,64%多余代码因接口僵硬难用。
写代码的 Agent 越来越多地接手别的 Agent 写过的仓库。它们爱重写、少复用,后面的 Agent 要在更大的代码堆里干活。软件工程靠有人把领域压成库。现在要问的是:Agent 能不能给别的 Agent 设计库?
单测只看库对不对,看不出好不好用;按规格核对接口,规格会把设计写死;人来评审,测到的是人喜欢什么。这篇只看下游三个较弱的 coding agent(能改仓库、跑命令的编程代理)拿着库写程序,对不对、短不短。
LibraryDesignBench 分两阶段。
15 个库设计任务、242 道专家审过的题,覆盖 Python、TypeScript、Rust、Haskell。参考答案用成熟生产库写成,如 clirs 对 clap。每道题没有库也必须能做。
库分是测试通过比例的平方乘以相对参考的简洁度,对题目和三个实现者取平均后再乘 100。平方更看重正确:过 80% 且和参考一样长,低于全对但代码是参考的 1.5 倍。简洁度平均四个封顶比值:圈复杂度(分支数)、认知复杂度、Halstead Volume(运算符和操作数的体积)、格式化后有效行数。装不上的库得 0。
短但错、对但不短,分数都上不去。
正确率分不出设计者。各设置测试通过率在 84.1% 到 86.6%,无库是 86.4%。拉开分数的是代码短多少。
| 设置 | 分数 | 通过率 | 简洁度 |
| Opus 5.5 | 48.9 | 86.6% | 64.5 |
| Fable 5.1 | 47.5 | 86.1% | 62.7 |
| 人类生产库 | 46.6 | 85.4% | 61.5 |
| GPT-6 Astra | 45.1 | 85.7% | 58.7 |
| 无库 | 34.4 | 86.4% | 46.3 |
| DeepSeek V4 Pro | 31.2 | 84.9% | 42.0 |
Opus 5.5 比生产库高 2.3 分(相对 4.9%)。生产库相对无库高 12.3±0.4 分,每题大约多花 $0.14。DeepSeek V4 Pro 比无库低 9.2%,库是负资产。Haskell 上约 70% 的(设计者,任务)配对不如不给库。三个无库已胜过生产库的任务上,Opus 5.5 仍比无库低 3.2 分。
运行框架差一截:Fable 5.1 在 mini-SWE-agent 上 47.5,换 Claude Code 掉到 39.9。三个实现者对前三和垫底的排序一致,不偏袒自家模型。
15 个任务里 11 个,设计者复刻了人类生产库的抽象。clirs 上 Astra 和 Fable 抄 clap 的 builder 链,没用更短的 derive 宏。
下游会调库,但用不足。810 个「部分通过且长于参考」的样本里,82% 的多余代码主因算在库的局限,僵硬加啰嗦占 64%,能力缺失只占 14%。180 个解里 13562 行重写代码中,41% 是库已提供但藏着或坏掉的功能。clirs 的 33 个库里 24 个不好做长选项前缀推断,缺它的库在需要该能力的题上低 16.7 分。
即便给生产库,三个实现者简洁度也只有 61.5。LibraryUseBench 把库钉成生产库、换 8 个模型当用户,Opus 5.5 最高 66.9。GPT-5.6 Luna 把推理从 low 拉到 high,通过率从 51.4% 升到 84.5%,读库文件从约 2 个到 15 个;更指令化的 prompt 把简洁度从 48.7 拉到 60.4。最小 prompt 下 24% 的试验不打开库,参考里 36% 的库符号从未被看见(默认 prompt 下是 5%)。它 grep 自己记得的 API 名,想不起来的能力就废了。
给 GPT-6 Astra(Codex)加面向 Agent 的硬指导:先写下游草稿,做成可运行例子,再用 subagent 试库。与生产库导出同名从 19.4% 降到 13.4%,分数从 44.1 升到 46.4,仍低于生产库 46.6,简洁度相对高 6.8%。设计成本几乎翻倍($8.24 对 $4.51),下游每题成本不变。三个部件没拆开测。
这是第一份只用「别的 Agent 用得怎么样」来评库设计的基准。要让 Agent 互相接代码,测量应落在下游正确率和代码量上,不落在接口像不像人类库。
眼下的结论偏冷。最强设计者能小幅超过生产库,靠的是把人类抽象再实现一遍。下游拿到 clap、pydantic 这种熟库,仍会少用、重写。改成「只给 Agent 用」再加 subagent 试错,能缩短下游程序,相对生产库只追到附近。
能搬的是评测方式和设计循环:消费者程序先写、例子先行、用没见过设计的 subagent 验收。适合评估内部工具链和给 coding agent 的 SDK。不适合当「谁最会写库」的总榜,分数绑死了这 15 个任务、3 个用户模型和这套预算。
论文自己划了界:分数只描述这套任务、用户和预算下的效用,不是与用户无关的库排名;测的是测试通过率和静态规模,不管完整正确性、安全、运行时、可维护性;参考答案不是唯一最优;任务偏「库能省很多代码」;置信区间只覆盖固定题集重跑。
失败分类由同一家族的 GPT-5.6 Luna 做,无人工标签、无一致性检验,64% 带着审计器偏差。规格里两三个可见用例仍在计分集,设计者见过部分考题。Agent 向指导是打包实验,没拆「草稿 / 例子 / subagent」。通过率全员 84% 到 87%,无库有时更高,榜基本是简洁度榜。Haskell 上库常变成负资产,四语言等权会把「会设计」和「某语言很差」混在一起。