Table of Contents
背景
如今，越来越多的人开始让AI编码代理代替自己操作软件：只需描述一个任务，代理就会自己选择库、编写调用、运行代码，甚至调试自己的错误。当库的设计不便于使用时，代理甚至会主动绕过它，从头重写逻辑。这给库开发者引入了一个全新的概念：代码不仅要正确、高效，还应该设计得让代理能轻松驱动它。一个糟糕的API或过时的文档会让人类开发者头疼，但现在它还会让代理走更远、更昂贵的弯路。
Hugging Face团队发现，大多数基准测试只关注最终答案——代理是否做对了？但他们更关心整个过程：代理花了多少工作量才到达那里？答案是如何找到的？不同模型、不同库版本和不同任务之间的差异如何？
他们将transformers库作为案例，设计了一套专门针对代理使用场景的基准测试框架。该框架完全运行在以pi编码代理驱动的开源模型上，并通过Hugging Face Jobs将模型、库版本和任务的全排列分发到同一硬件上。
核心内容：为Agent优化的软件设计原则
博客提出了两条核心原则：
- 如果没测试，就是坏的：代理代码需要经过测试才能确保正常工作。
- 如果没文档，就是不存在的：代理通过文档来发现和了解工具，文档必须清晰、结构化，且包含快速入门的示例。
为了验证这些原则，团队对transformers库进行了一系列优化：添加了CLI接口、创建了Skill（一种可复用的能力模块）、并提供了自包含的任务特定示例。这与此前对hf CLI的优化类似——经过Agent优化后，代理使用hf CLI时消耗的token减少了1.3到1.8倍，最高达6倍。
基准测试的实现方法
研究者构建了一个轻量级的测试框架，包含三个关键组件：
- 任务集：从transformers支持的常见机器学习任务中选取，如文本分类、图像描述、语音转录等。
- 模型池：选择多个开源模型（如Llama、Mistral等），覆盖不同规模和能力。
- 库版本：包括优化前后的transformers版本，以及多个控制版本。
代理需要执行任务并使用transformers完成编码。框架记录比最终答案更多的信息：代理执行了多少步、调用了哪些函数、消耗了多少token、是否出现了错误以及如何恢复。这种细粒度的过程信息比简单的“对/错”更能反映工具的可用性。
初步发现：优化确实有效
尽管博客没有公布完整的实验数据，但团队透露，优化后的transformers版本确实让代理更高效。代理能更快地找到正确的API，更少地陷入死循环或依赖错误。重要的是，这种提升对较弱的模型尤为显著——文档清晰和API简洁对能力有限的代理来说至关重要。
行业影响与专业点评
这篇文章揭示了一个被忽视的软件工程维度：你是否在开发“Agent友好”的软件？随着AI编码代理的普及（如GitHub Copilot、Devin等），库开发者需要重新考虑API设计、文档组织甚至错误消息的表述。
对于AI从业者而言，这个基准测试提供了一个模板：你可以用它来测试任何库在代理驱动下的表现，而不仅仅是transformers。通过量化token消耗、执行步数和成功率，你可以客观地衡量一个工具对代理的友好程度。
未来，当AI代理成为开发的主力军时，“面向代理开发”可能成为软件开发的标准实践。就像我们今天会为移动端优化界面一样，明天我们会为代理优化API。这篇博客是这个方向的第一步，也为我们提供了一个实用的评估工具。
