跳转到内容

研究、基准测试与行业动态

观察日期:2026-07-23。

适用来源:当前公开的基准测试论文、基准测试项目文档,以及关于软件工程智能体、浏览智能体、工具-智能体-用户交互和通用助手任务的评估文章。

维护状态:持续维护的领域笔记。当某个基准测试改变任务集、运行框架、污染控制、评分方法,或新的证据类别改变 Fieldbook 的持久主张时,应重新审阅。

智能体基准测试越来越关注系统,而不是孤立的补全。代表性任务已经包括解决真实软件问题、浏览寻找难以发现的信息、与工具和模拟用户交互,以及解决多步骤助手任务。这是一种进步:它迫使模型和运行框架处理状态、工具、不确定性和长周期工作。

这也让结果更难解释。一个基准测试分数可能取决于基础模型、工具接口、提示词、脚手架、重试预算、时间限制、浏览器环境、软件包安装、评估器、答案格式和泄漏控制。即使模型不变,运行框架变化也可能改变结果。分数提高可能反映的是更好的编排,而不是更可靠的通用智能体。

对 Fieldbook 来说,有用的问题不是“今天哪个模型赢了?”而是“这个基准测试为任务类型、失效模式、运行框架设计和评估限制增加了什么证据?”

把公共基准测试当作外部参照,而不是发布门槛。

基准测试可以提示某类任务正在变得可行。SWE-bench 和 SWE-bench Verified 与编码智能体相关,因为它们使用真实软件问题和基于测试的结果。τ-bench 与工具使用型智能体相关,因为它包含模拟用户交互和领域工具。GAIA 和 BrowseComp 与研究和浏览智能体相关,因为它们强调多步骤信息查找、工具使用和证据收集。

这些基准测试都不能证明你的产品可用。你的本地系统可能有不同的代码库、权限、API、文档、延迟目标、成本上限、隐私规则、升级处理路径和用户期望。一个在 benchmark issue 上表现良好的编码智能体,仍然可能错误处理你的 monorepo 构建系统、密钥策略、迁移流程或评审文化。一个能回答 benchmark question 的浏览智能体,仍然可能在你的受监管领域引用过期来源。

当某个基准测试结果很重要时,先读运行框架,再读排行榜。要问清楚:智能体能看见什么、能使用哪些工具、有多少次尝试、成功如何评分、任务是否经过筛选、答案或测试是否可能泄漏,以及失败是否经过分析。然后再决定这些证据是否应该改变本地评估套件、设计假设或 Fieldbook 章节。

不要把基准测试变化转化为通用产品承诺。“智能体可以解决软件问题”过于宽泛。更负责的说法应该有边界:在这个基准测试的问题分布、环境、运行框架、预算和评分规则下,这类系统达到了这个测量结果。

不要把公共基准测试当作领域专家的替代品。基准测试任务往往简化了验收、数据访问、策略解释、用户偏好和组织问责。

不要忽视负面证据。失败追踪记录、拒答、工具错误、预算耗尽、虚构证据和基准污染担忧,通常比标题分数更有设计价值。

  • 引用结果前,记录基准测试版本、任务划分、运行框架、工具、模型配置、重试预算、时间预算、评估器和评分规则。
  • 区分模型改进和脚手架、检索、浏览器、工具或评估器改进。
  • 检查基准测试任务是否类似于你的工作负载的数据、权限、后果、延迟和成功标准。
  • 检查污染、记忆化、答案泄漏、隐藏筛选和评估器漂移风险。
  • 当相关基准测试失败与产品风险匹配时,将其转化为本地评估任务。
  • 永远不要把公共排行榜作为生产发布的唯一证据。
  • 对易变的基准测试或行业动态,优先使用带日期的 Field Notes;只有当它改变持久指导时,才把材料移入核心章节。