What Makes a Good Terminal-Agent Benchmark Task: A Guideline for Adversarial, Difficult, and Legible Evaluation Design
作者: Ivan Bercovich
分类: cs.AI
发布日期: 2026-04-30
💡 一句话要点
为终端代理基准测试任务设计提供指导,强调对抗性、难度和可读性
🎯 匹配领域: 支柱九:具身大模型 (Embodied Foundation Models)
关键词: 终端代理 基准测试 任务设计 对抗性评估 语言模型
📋 核心要点
- 现有终端代理基准测试任务设计缺乏对抗性审查,导致评估结果可能存在偏差。
- 论文提出对抗性、难度和可读性三个关键原则,指导高质量基准测试任务的设计。
- 研究揭示了常见的任务设计缺陷,并发现现有基准测试中存在可奖励利用的问题。
📝 摘要(中文)
终端代理基准测试已成为衡量大型语言模型编码和系统管理能力的主要指标。随着评估环境市场的增长,快速交付任务的压力也随之增加,通常缺乏对验证逻辑的全面对抗性审查。本文旨在为编写良好的基准测试任务提供指导,这些经验来自于一年多来为 Terminal Bench 贡献和审查任务的实践。大多数人编写基准测试任务的方式与编写提示词的方式相同,这是不应该的。提示词旨在帮助代理成功,而基准测试旨在找出它是否能够成功。我们认为,好的任务是对抗性的、困难的且可读的,并且一大类常见的失败模式——AI生成的指令、过度规范的规范、文书难度、假设隐藏知识的预言机解决方案、验证错误内容的测试以及可奖励利用的环境——都是将任务创作视为提示词创作的可预测后果。我们对这些失败模式进行了分类,认为真正的难度是概念性的而不是环境性的,并讨论了最近的经验证据,表明流行的终端代理基准测试中超过 15% 的任务是可奖励利用的。我们希望这能为基准测试维护者、任务贡献者以及使用基准测试分数作为证据的研究人员提供有用的参考。
🔬 方法详解
问题定义:现有终端代理基准测试任务的设计往往将任务创作视为提示词创作,缺乏对抗性审查,导致任务容易被利用或无法有效评估模型的真实能力。常见的痛点包括AI生成的指令模糊不清、过度规范的任务限制模型探索、文书工作难度过高、预言机解决方案假设了模型不应具备的隐藏知识等。
核心思路:论文的核心思路是将基准测试任务的设计视为一个对抗过程,旨在发现模型的弱点和局限性,而不是帮助模型成功。因此,任务设计应遵循对抗性、难度和可读性三个原则。对抗性是指任务应设计成能够挑战模型的边界,迫使模型犯错;难度是指任务应具有一定的挑战性,能够区分不同模型的性能;可读性是指任务的规范和验证逻辑应清晰易懂,方便研究人员理解和改进。
技术框架:论文没有提出一个具体的算法或模型框架,而是一个关于如何设计高质量终端代理基准测试任务的指导框架。该框架包括以下几个主要方面:1) 识别常见的任务设计缺陷,如AI生成的指令、过度规范的规范、文书难度等;2) 强调任务设计的对抗性,鼓励设计能够挑战模型边界的任务;3) 强调任务设计的难度,确保任务能够区分不同模型的性能;4) 强调任务设计的可读性,方便研究人员理解和改进。
关键创新:论文的关键创新在于它将基准测试任务的设计从一个提示词工程问题转变为一个对抗性评估问题。通过强调对抗性、难度和可读性三个原则,论文提供了一个系统性的方法来设计高质量的基准测试任务,从而更准确地评估终端代理模型的真实能力。与现有方法相比,该方法更加注重发现模型的弱点和局限性,而不是帮助模型成功。
关键设计:论文没有涉及具体的参数设置或网络结构,而是提供了一系列关于任务设计的建议。例如,论文建议避免使用AI生成的指令,因为这些指令往往模糊不清;建议避免过度规范的任务,因为这会限制模型的探索;建议避免文书工作难度过高的任务,因为这会分散模型的注意力;建议避免使用假设隐藏知识的预言机解决方案,因为这会使任务变得不公平。此外,论文还强调了奖励函数的设计,指出奖励函数应该能够准确地反映模型的性能,避免出现奖励利用的情况。
📊 实验亮点
论文通过实证研究发现,流行的终端代理基准测试中超过15%的任务存在可奖励利用的问题,这表明现有基准测试任务的设计存在缺陷。这一发现强调了遵循论文提出的指导原则设计高质量基准测试任务的重要性,以确保评估结果的准确性和可靠性。
🎯 应用场景
该研究成果可应用于各种需要评估大型语言模型在编码和系统管理方面能力的场景,例如招聘、模型选择和性能监控。通过使用遵循本文指导原则设计的基准测试任务,可以更准确地评估模型的真实能力,避免因任务设计缺陷而导致的评估偏差,从而做出更明智的决策。
📄 摘要(原文)
Terminal-agent benchmarks have become a primary signal for measuring the coding and system-administration capabilities of large language models. As the market for evaluation environments grows, so does the pressure to ship tasks quickly, often without thorough adversarial review of the verification logic. This paper is a guideline for writing good benchmark tasks, drawn from over a year of contributing to and reviewing tasks for Terminal Bench. Most people write benchmark tasks the way they write prompts. They shouldn't. A prompt is designed to help the agent succeed; a benchmark is designed to find out if it can. We argue that good tasks are adversarial, difficult, and legible, and that a large class of common failure modes -- AI-generated instructions, over-prescriptive specifications, clerical difficulty, oracle solutions that assume hidden knowledge, tests that validate the wrong things, and reward-hackable environments -- are predictable consequences of treating task authoring as prompt authoring. We catalog these failure modes, argue that real difficulty is conceptual rather than environmental, and discuss recent empirical evidence that over 15% of tasks in popular terminal-agent benchmarks are reward-hackable. We hope this serves as a useful reference for benchmark maintainers, task contributors, and researchers using benchmark scores as evidence.