论文页面 - 智能体能为智能体设计库吗？

来源：https://huggingface.co/papers/2609.36730

我们正快速接近这样一个临界点：软件库的主要用户将是智能体，而不是人类工程师。如果智能体才是用户，那么衡量一个库的好坏，就应该看智能体用它编写正确的程序需要写多少代码，而不是它在人类读来是否优雅。正因如此，我很高兴发布 LibraryDesignBench（https://ldbench.com/）——一个两阶段基准，它衡量智能体编写的库时，唯一依据是该库对使用它的未来智能体有多大帮助。

让智能体为其他智能体编写库

LibraryDesignBench 让智能体编写有效的库，并且我们有意给予它们设计上的灵活性。我们从不规定它们的库必须暴露哪些函数签名，也从不引导它们采用特定的抽象或模式。我们有意提供欠规定、模糊且含糊不清的库规范，因为前沿智能体需要构想未来智能体将如何使用它们的库、未来智能体需要什么，以及什么样的设计效果最好。LibraryDesignBench 给予智能体极大的自由度，因为评测需要作为测试平台，用于理解智能体实际上偏好哪些模式，而不是我们认为它们会偏好哪些。

基于智能体如何使用来评估库

一个正确实现功能的库并不能立刻带来任何价值——它既要正确，又要让未来的代码更简单。因此，衡量一个库质量的唯一方式，就是观察未来的智能体能从其设计决策中获益多少。LibraryDesignBench 分两个阶段完成这一评估：

1. 设计阶段： 智能体根据一份有意不加规定的规范，实现一个完整的库。
2. 评估阶段： 我们通过观察多个不同的实现者智能体尝试使用该库来解决问题，从而评估这个库。

在设计阶段，我们唯一检查的是该库能否在它们受限网络的环境中安装，因为我们会为评测预先安装所有库——尝试安装库并不是我们关心的信号。随后，我们指派三个智能体（Codex 上的 5.6 Luna、mini-SWE-agent 上的 DeepSeek v4.1 Flash，以及 mini-SWE-agent 上的 GLM 5.3 Flash）用尽可能少的代码、借助该库来解决编程问题。每个「问题 × 智能体 × 库」的组合都在各自独立、无网络访问、高推理强度且已预装库的环境中运行。我们使用高度具体的提示词（https://github.com/SprocketLab/librarydesignbench/blob/dev/configs/prompts/library_use_inst.md），以确保智能体尽可能充分地利用该库。

然后我们根据以下公式为这些解决方案评分：

\text{score} = \text{pass rate}(y)^2 \cdot \text{simplicity}(y)

通过率是通过测试的百分比，我们对其取平方，以便对错误施加比简单性更严厉的惩罚。简单性定义为：

\text{simplicity}(y) = \frac{1}{\|\mathcal{M}\|} \sum_{m \in \mathcal{M}} \min\left\{\frac{m(y^*)}{m(y)}, 1\right\}

其中 \mathcal{M} 是我们用来比较「使用该库编写的解决方案」与「使用真实生产库编写的黄金参考解 y^*」之间差距的一组静态指标。每个比率上限为 1，因此一个优于参考解的解决方案不会获得额外加分。这四个指标是：

• 源代码行数（Source Lines of Code）： 智能体编写了多少代码。
• 圈复杂度（Cyclomatic Complexity）： 智能体用了多少分支和循环。
• 认知复杂度（Cognitive Complexity）： 代码有多难理解，对嵌套结构赋予额外权重。
• Halstead 体积（Halstead Volume）： 运算符和操作数的数量，密集的单行代码无法在此指标上取巧。

智能体在复制人类设计，但质量更差

我们评估了 11 种设计器配置，涵盖 9 个前沿模型，其中部分模型在多个运行框架中均有运行，全部采用高推理强度。每种配置尝试每项 15 个库设计任务三次，总共产生 45 个库。三个实现者智能体随后使用每个库来解决其任务中的每一道问题。在全部 242 道问题中，合计为 242 道问题 × 3 个库 × 3 个实现者 = 每种配置 2,178 次试验。

我们与使用同样 2,178 次试验的两个基线进行比较。第一个基线中，实现者没有库可用，使用另一套提示词；第二个基线中，实现者可以使用预先安装的人类编写的生产库。由于两个基线都没有三个已设计的库可供变化，我们改为对每一对「问题-实现者」组合运行三次。

Opus 5.5 设计的库对下游智能体的帮助超过了人类编写的生产库。使用这些库时，实现者通过同样多的测试，同时编写更简单的代码。Fable 5.1 大致与生产库持平。正确性几乎无法区分各个设计者，因为每种配置通过的测试比例都大致相当，因此排名取决于实现者还需要编写多少代码。而在另一端，DeepSeek V4 Pro 的库反而产生了负面影响：实现者使用它时的表现甚至不如完全没有库。运行框架同样有影响：Fable 的库在 mini-SWE-agent 中设计时比在 Claude Code 中设计时有用得多，而 Astra 的库在 mini-SWE-agent 中比在 Codex 中稍有用一些。

了解更多

完整的排行榜和任务见 ldbench.com（https://ldbench.com/）。你可以在这里查看完整代码仓库，在这里查看任务仓库，也可以在这里阅读完整技术报告。如果你有想看到的任务，可以在仓库中提一个 issue，或加入 Discord 参与讨论。

没有我出色的合作者，这一切是不可能实现的：Alex L. Zhang、Avi Trost、Vincent Sunn Chen、Frederic Sala、Aws Albarghouthi 和 Ludwig Schmidt。我也感谢 John Yang、Parth Asawa、Xavier Garcia、Ryan Carelli、Arun Kumar、Floriad Brand 和 Nick Roberts 给予的宝贵反馈与讨论。LDB 得到 DARPA、NSF、Prime Intellect 和 Snorkel AI 通过 Open Benchmarks Grant 的支持。