Sierra 开源 Hyper-𝜏-bench：评测能构建智能体的智能体

新闻与博客
Hyper-𝜏-bench：评估构建智能体的智能体

我们在 2024 年构建了 𝜏-bench，以回答当时看来很新颖的一个问题：模型能否充当可靠的客户服务智能体？如今这已是基本要求。更难的问题是，究竟是谁在构建这个智能体？越来越多的答案是模型本身。

我们与一些全球领先的公司紧密合作，推出他们的智能体。在实践中，这项工作不太像实现一份规格说明，而更像是做研究。需求散落在手册、支持文档、电子表格以及你最优秀的一线客服人员的头脑中——因此你要提出假设、挖掘证据，并通过构建和测试来确定哪些杠杆真正能提升表现。

今天我们开源了 hyper-𝜏-bench（以 𝜏^𝜏-bench 发布），这是一项新的长时程智能体评估，衡量模型不仅能充当智能体，还能构建智能体的能力。

沙盒内部

Hyper-𝜏-bench 将一个开发者智能体放入一个沙盒工作区，其中包含一家模拟企业的记录，以及一个可随时向其发消息的模拟客户。随后，开发者智能体端到端地完成工作——它从证据中还原规格说明，设计架构，并将企业的操作转化为工具——直到它拥有一个可用的客户服务智能体。客户的 REST API 可能存在细微缺陷，因此工作的一部分就是判断 bug 出在规格说明中还是代码中。完成的智能体必须在固定的模型菜单中提供服务，并遵守每次对话的成本预算。一旦交付，我们会使用开发者构建时从未见过的、完全可验证的 𝜏-bench 风格测试，将其部署到模拟的生产流量中。

当前前沿水平

在独立工作的情况下，我们最好的配置——在 Claude Code 中运行的 Claude Opus 5（最大推理）——仅通过了 23.9% 的留出评估任务。与一位拥有深厚背景的工程师配合时，同一类模型在相同任务上达到 82.2%。

我们通读了开发者的轨迹，以了解他们的构建在哪里失分。五种模式尤为突出：

他们没有完成规格说明的还原。在银行业务中，开发者只打开了约 1,700 个文件中的不到 80 个，只接入了关键词搜索恰好浮现的内容。
他们没有询问客户。在客户独自掌握 20-25 项需求背景的任务中，开发者最多只问了四个问题。提问能直接带来回报。在参考智能体（由工程师构建）得分 95–100% 的任务中——提问零次的构建得分为 5%，提问一次为 15%，两次为 25%，以此类推。
他们在两个方向上把经济账算错了。两个构建分别超出预算 3.0 倍和 1.3 倍，并在扣分后得分为零。其余的则把算力留在了桌上——存活的智能体平均只花费了预算的 0.45 倍。
他们没有探索设计空间。92% 的构建是单一的 LLM 工具循环，且大多数默认使用自己已经熟悉的模型——96% 的 Codex 构建服务于 OpenAI 模型，而 Kimi 仅为 13%。这代价高昂：一句架构建议就让一位开发者的电信得分翻倍，从 31% 提升到 67%。
他们会试图作弊。在 17-42% 的运行中，开发者至少尝试过一次作弊——探查沙盒以获取留出数据，或探查评分机制本身。没有人成功，但这提醒我们，加固沙盒与编写任务同样重要。

更大的图景

Hyper-𝜏-bench 与 MLE-bench 和 RE-Bench 等基准并列，这些基准衡量研究能力：设计实验、权衡取舍，并迭代改进系统。构建一个智能体需要所有这些能力——并且还带来了一些自身的问题。规范必须从文档和人员中还原出来。而且由于所构建的系统本身就是 AI，判断一个设计是否有效的唯一方法就是运行它，并阅读它对真实用户的反馈，而开发者在构建过程中从未见过这些用户。

𝜏-bench 问的是模型能否成为优秀的智能体。Hyper-𝜏-bench 问的是它们能否构建智能体。随着智能体自身承担越来越多这样的工作，我们将继续使用 hyper-𝜏-bench 来追踪它们做得如何。

论文 | 代码库 | 排行榜

订阅 Sierra 博客

获取新产品功能、客户更新等通知。

了解 Sierra 能为你做什么

了解 Sierra 如何帮助你借助 AI 交付更好的成果。