Opus 5.5 设计的库让下游智能体少写代码、得分超过人类生产库 2.3 分，但 15 个任务中 11 个只是复刻了人类抽象

论文提出 LibraryDesignBench，把库的质量定义为下游智能体使用它时的正确性与简洁度，而不是库本身的测试通过率或接口是否符合规格。 此前评测要么用测试检查库是否正确、要么用签名或构造比对规格，都会预先规定待测的设计；该工作改为观察智能体真实使用库写出的程序，并用真实生产库写成的参考解做简洁度基准。 基准含 15 个库设计任务、4 种语言、242 道经专家校验的下游题目；每个设计者配置在每任务生成 3 个库、由 3 个实现者智能体解题，共 2178 次评测；另设无库与生产库两个基线，各跑同样 2178 次。

智能体确实能设计出帮助其他智能体的库：Opus 5.5 得分 48.9，比生产库基线 46.6 高 2.3 分（相对 4.9%），实现者通过同样多的测试但写出更简单的代码。 这是首次把设计者作为变量来测量库设计质量，并给出一个可复用的设计基线；此前工作多固定库、只评模型是否会调用。 表 1 给出 11 个设计者配置的得分与 95% 置信区间；各配置通过率集中在 84.1%–86.6%，无库条件为 86.4%，说明排名主要由简洁度而非正确性区分。

智能体设计的库在 15 个任务中的 11 个复刻了人类生产库的抽象，但下游智能体仍然少用库、重复实现库已提供的能力。 论文把“库写得对”与“库被用起来”分开：即使使用生产库，实现者的简洁度也只有 61.5，说明差距一部分来自使用者而非设计者。 对 6 个设计者配置抽样 810 个部分通过且代码超长的解做审计，82% 的首要归因属于库的限制，其中僵化与冗长占 64%、能力缺失仅占 14%；另一项作者分析中，180 个解里 13562 行手工标注的重写代码有 41% 在重做库已发布但被隐藏或损坏的功能。

面向智能体的处方式指导能改变设计结果：让设计者先画消费者程序草图、附可运行用法示例并用子智能体测试，导出名与生产库的重合度从 19.4% 降到 13.4%，得分从 44.1 升到 46.4，主要来自简洁度提升。 这提供了一个可操作的干预方向，并显示“为智能体设计库”与“为人类设计库”并不相同；但该结果仍略低于生产库 46.6 与标准提示下的 Opus 5.5 48.9。 干预在 GPT-6 Astra（Codex，高推理）上做配对比较，三个实现者与四种语言中的三种均有改善；指导使设计成本从 4.51 美元升至 8.24 美元，而每题成本不变。

该基准面向需要设计供其他智能体使用的库的研究者与工程团队，适用于论文设定的任务集、实现者配置与执行预算；它测量的是被测正确性与消费者程序的静态规模与复杂度，可用于比较不同设计者、不同提示与不同推理强度下的库设计实践，也可作为后续研究智能体接口、抽象与文档的测试床。论文给出的指导式干预（消费者优先的 API 草图、可运行用法示例、用子智能体测试）在 GPT-6 Astra 上把得分从 44.1 提到 46.4，为希望提升下游复用的人提供了一个起点。

论文自身指出，分数刻画的是特定任务、消费者配置与预算下的效用，而非与消费者无关的库排序；置信区间覆盖的是固定任务集的重跑，不保证推广到所有库领域。审计样本只覆盖部分通过且代码超长的解，且由单一模型完成、无人工标注与一致性检查，因此 64% 与 14% 这类比例描述的是该样本而非全部下游单元。指导式干预是作为整体评估的，未拆分各组件贡献；设计成本近乎翻倍而每题成本不变，这一权衡在不同预算下的表现仍待观察。此外，本次加载的是论文全文与外部报道，未包含基准网站上的完整排行榜与任务仓库内容。