摘要

本文介绍了腾讯 WorkBuddy Bench——一个面向编码智能体的多领域评测套件；本报告记录了其构建方法、评分协议以及跨模型排行榜。其核心是一个统一的评测框架，用于在四个工作领域——代码（Code）、网页（Web）、办公（Office）和安全（Security）——构建并运行基于真实分布信息的编码智能体任务。与改编公开 issue 文本的做法不同，每个任务都是从真实的 commit、pull request 或业务场景中逆向工程而来，并被改写为一段简短、口语化、角色扮演式的请求，因此任务提示词无法通过联网搜索底层 issue、pull request 或 commit 讨论串来获取。由于数据集是公开发布的——包括任务目录、环境镜像、评测框架、测试用例和参考解决方案——其抗污染能力依赖于这种构建方式以及数据集版本管理，而非保密性。四个子集——仓库级工程、前端开发、办公与业务工作流、红队/蓝队安全——分别考察真实工作中互补的侧面，每个子集都有各自的验证方式。所有子集都采用统一的任务目录格式打包，并在统一且可复现的协议下，于两个智能体框架（CodeBuddy Code 和 Claude Code）上运行；完整的开放发布使该基准测试端到端可复现且可直接审计，因为任何第三方都可以重新运行每个任务并检查其内容。由于每个子集使用不同的评分工具，各子集之间的分数不可比较，因此该评测套件不报告套件级平均值。我们报告了跨多个模型家族的跨模型排行榜。

1 引言

如今，编码智能体正面临两种截然不同的基准测试的检验，每种基准各有其利弊权衡。静态公开测试集，如 SWE-bench 和 SWE-bench Verified [1, 2]，在发布时便固定了任务集：它们的问题描述，以及通常的解决方案，都公开流传于网络上，因此不断攀升的分数可能反映的是对特定 issue 线程或 pull request 的记忆，而非真正的仓库级推理能力；并且它们的范围很窄——绝大多数是单一问题的缺陷修复。这种可爬取性问题在代码领域之外同样存在：用于前端生成 [3] 和网页智能体 [4] 的基准测试，其数据来源是本身就可被爬取的公共仓库、截图和网站。厂商的生产环境基准测试，如 CursorBench [5]，则采取了相反的做法，从真实的生产会话中提取任务，使得任务分布能够追踪智能体的实际使用方式——但这类基准本身是封闭的：外部方无法检查其任务分布，无法排除偏向于该厂商自身智能体的选择偏差，也无法确认其任务组合能否推广到该厂商用户群之外。因此，要评估那些旨在真实组织内部运行的智能体，就需要一套这样的测试集：其任务分布来源于真实工作，能够从构造上（而非仅仅依靠发布时的新颖性）抵御最关键的污染路径——即可通过网络搜索到的提示词，并且其发布足够开放，使外部方能够重新运行每个任务并直接审查其内容。

我们推出腾讯 WorkBuddy Bench，这是一个面向编码智能体的多领域评测套件；本报告记录了其构建方法、评分协议以及跨模型排行榜。其核心是一个统一的评测框架，用于在四个工作领域——代码（Code）、网页（Web）、办公（Office）和安全（Security）（图 1）——构建并运行基于分布信息的编码智能体任务，并在两个智能体运行框架（CodeBuddy Code 和 Claude Code）上以共享、可复现的协议进行评估。代码领域针对仓库级软件工程：在真实开源代码库中，根据角色扮演式的口语化需求，定位、修改并验证代码变更。网页领域针对前端产物，涵盖生成、修改、分析和质量保障，从页面实现和数据可视化，到有状态交互、测试、报告和文档转换。办公领域针对涉及多文件和交付物的业务流程。智能体必须读取混合格式的本地文件，跨交付物传递信息，更新工作区状态，并留下可供他人使用的结果。其评估目标是最终可验证的工作区状态：交付物、文件结构、状态变更、证据以及任务特定的执行边界。安全领域涵盖安全团队的完整范畴——漏洞发现与安全复现、恶意软件分析、安全运营和智能体安全评估——而非修复代码的编写。所有四个子集共享相同的任务目录格式、相同的准入协议和相同的执行基础设施。它们不共享的是评分工具：代码领域使用隐藏测试——“隐藏”意味着在智能体解题时对其保密，而非对公众保密，因为完整测试套件随开放版本一并发布；网页领域使用带规则检查的评分细则来验证确定性约束，用 LLM/VLM 评判器评估文本、结构和视觉语义，并用智能体评判器检查交互状态和工作流；办公领域使用任务特定的确定性规则检查与基于证据的 LLM 评判器评估的语义评分细则相结合的方案；安全领域使用确定性评分器。因此，各子集之间的分数不可比较，该套件也不报告套件级平均分——这是一个有意的设计事实，而非有待填补的缺口。统一之处在于构建方式和运行框架，该基准以开放形式发布，且可直接审计：协议、任务格式、任务目录、环境镜像、评测框架、测试和参考解决方案全部公开，任何第三方都可以重新运行每个任务并检查其内容。

这四类为何归入同一套基准。一个被置于真实组织工作中的编码智能体，不再仅仅编辑代码：同一个智能体还会被要求构建 Web 前端、生成或核对办公文档，以及针对安全产物进行推理。代码、Web、办公和安全，正是这类工作所跨越的四类产物与工作流边界，而该套基准之所以将它们视为一体，是因为在每个边界上任务形态都完全相同——智能体被放入一个工作区，根据自然语言请求产出一个产物，并由一个它从未见过的验证器进行评分。让四个子集构成一套基准的，是这种共同的形态，而非共同的评分规则。

对最关键的污染路径——可通过网络搜索到的提示词——的抵御，是一等设计约束，而非事后补救。任务并非公开议题标题或教程练习的复刻：每个任务都是从真实提交、拉取请求或业务场景中逆向工程而来，并被改写为一段简短、口语化、角色扮演式的请求，其指令隐去了根本原因、参考差异以及任何会让智能体直接拿到答案的框架性信息，因此某个任务的提示词无法通过在网上搜索底层议题或拉取请求讨论串来还原。由于数据集是公开发布的，这种构造层面的抵御依靠的是数据集版本管理，而非保密；第 2 节详细说明了该机制，并如实界定了它能抵御什么、不能抵御什么。

任务分布基于对真实使用情况的分析，而非对真实使用数据的复用。每个子集的类别、任务模式和难度配比，都与内部使用分类法——查询意图类别和请求结构模式——进行匹配，因此，例如，Code 的 80 个任务横跨五种请求者角色，且任务类型远不止修 bug（第 3 节）。被分析和匹配的是真实请求的分布，而非请求本身：没有任何原始用户提示词、会话或用户数据被复用到或暴露在已发布的任务中。也正是这一点，让该套基准能够完整发布并接受公开审计，而基于原始会话的基准则面临隐私约束，限制了其披露程度。

贡献。本报告做出四项贡献。1) 我们推出了腾讯 WorkBuddy Bench，这是一套包含四个并行子集——代码（Code）、网页（Web）、办公（Office）和安全（Security）——的基准测试套件，在统一的可复现测试框架下，评估编码智能体在仓库级软件工程、前端网页开发、办公与业务流程以及安全团队工作流中的表现。2) 我们采用一种基于分布信息的方法来构建任务，以抵御提示词污染：每个任务都是从真实的提交（commit）、拉取请求（pull request）或业务场景中逆向工程而来，与内部使用分类体系进行匹配，并改写为口语化、角色扮演式的自然语言需求，而非从公开的 issue 文本中复制或取自用户会话。3) 我们开发了一套超越通过/失败单元测试的评估方法。每个被接纳的任务都需通过基线/基准（oracle）准入门槛（基线奖励、基准奖励），确认未修改的工作区本身无法通过测试，且至少有一个参考解决方案能达到完整的验证器奖励；前端工件通过规则检查（针对确定性约束）、LLM/VLM 评判器（针对文本、结构和视觉语义）以及一个驱动运行中工件以检查交互流程和状态的智能体评判器进行评分。对于办公（Office）子集，确定性规则检查验证文件、结构、数值、状态和执行边界，而 LLM 评判器则利用任务结束后提取的固定证据，对二元语义评分标准进行评估。两个分数分别报告，并使用每个任务预先配置的权重进行合并。4) 我们报告了一个跨模型排行榜，涵盖多个模型家族，并在两套评估框架（CodeBuddy Code 和 Claude Code）下进行评测。$\le 0.3$$\ge 1.0$

简而言之，本报告提供了三方面内容：该套件的设计、当前每个子集的任务集构成，以及跨模型排行榜。表 1 总结了这四个子集。

媒体内容 · 前往原文查看

子集	领域	规模	指标
代码（Code）	仓库级软件工程（SWE）	80 个任务	每次运行的隐藏测试得分
网页（Web）	前端 / 图形界面（GUI）	70 个任务	评分标准评分（规则 / LLM-VLM / 智能体）
办公（Office）	办公数据与文件工作流	50 项任务	任务专属规则/评判器混合机制
安全	红队与蓝队安全测试	60 项任务	程序化评分（scoring.py，不使用 LLM 评判器）

报告其余部分结构如下。第 6 节首先将该评测套件与代码和网页领域现有的公开及厂商生产环境智能体基准进行定位对比。第 2 节随后描述该套件的共享设计原则、任务格式和执行模型，接着是详细说明四个子集、评测框架与评分方法、结果及局限性的各节。

2 任务构建

本节阐述腾讯 WorkBuddy Bench 的套件级构建协议。在全部四个子集——代码、网页、办公和安全——中，任务遵循相同的大致阶段：来源采集、改写为真实请求、组装智能体可见的工作空间、在任务回合结束前隔离评测资产，以及将每个任务打包为自包含目录。用户数据在整个构建过程中不参与其中。评分工具和各子集特定的准入检查并不统一：代码使用隐藏测试，网页使用规则、LLM/VLM 和智能体评判器评分项，办公使用确定性规则检查与基于证据的 LLM 评判器评分细则的任务专属混合机制，安全则使用确定性的 scoring.py。由于这些工具各不相同，各子集之间的分数不可比较，套件也不报告整体平均值；这是一个刻意的设计决策，而非需要修正的局限。本节涵盖构建和打包；执行和各项评分的具体规定在第 4 节中统一说明。

任务来源。

每项任务都锚定于两类具体来源之一：要么是真实的上游产物——开源代码仓库中的历史提交或拉取请求（Code 类），要么是真实的历史 CVE（Security 类的白盒审计任务）——要么是具体的业务场景（Web、Office，以及 Code 和 Security 的合成任务族）。哪些场景值得构建、以何种比例构建，由内部使用分类法决定：每个子集的类别构成、任务模式、角色和难度都与真实请求的分布相匹配，而绝不针对请求本身。任何原始用户提示词、会话或其他用户数据都不会进入任何任务；构建过程仅依据聚合分布信息。在业务场景分支中，Office 采用两条构建路径：从任务规格和目标能力重建的任务，以及从抽象化办公流程扩展出的任务。两者都打包为自包含的工作区，仅包含可公开共享的输入，并通过相同的工作区完整性、评估资产、校准和发布就绪性检查。

重写协议。

任务并非以整洁的问题标题或教科书式习题的形式编写。当任务源自真实上游产物时，其原始上下文会被逆向工程并重写为简短、口语化、信息不充分的自然语言请求；当任务源自业务场景时，请求会直接以同样的语气编写。无论哪种方式，请求读起来都像同事或客户提出的合理诉求——Code 类还通过五种请求者角色（开发者、算法工程师、产品经理、QA、运维）为每项任务赋予声音，Security 类则为每个任务领域分配一个专业角色——并且指令会隐去根本原因、参考差异以及任何会让智能体直接获得解决方案的框架信息，因此智能体必须先自行定位工作区的相关表面，然后才能行动。这与提供详细、已诊断问题报告的基准测试形成鲜明对比。

刻意的不充分说明。

在全部四个子集中，请求的写法都像同事实际提问的方式——包含意图和约束条件，而非完整规格说明——并且刻意留有不明确之处：它们通常会省略目标文件或模块、确切的模式或接口、边界情况处理，以及变更的精确范围。弥合这些缺口本身就是任务的一部分：智能体必须从工作区中恢复缺失的上下文——包括代码仓库、数据夹具或现有代码和接口——并承诺一个合理的隐含假设，而不是被直接赋予一个。这是有意为之，而非疏忽：它既测试需求消歧和落地能力，也测试代码合成能力，这正是现实工作请求与整洁问题标题之间的区别。奖励根据任务特定的检查、评分细则或评估流程计算，而非通过匹配单一参考实现或措辞。这些工具编码了预期的契约，因此一个看似合理但违反契约的输出仍然可能失败。智能体的评判标准是是否满足该契约，而非是否恢复出某个被认可的特定实现。

回合后评估隔离。

在整个回合中，智能体能看到任务指令和声明的工作区，但看不到评分资产。只有在智能体完成行动后，任务特定的检查、评分细则或评估流程才会被引入沙箱，或由评估管线调用。“隐藏”或“保留”因此描述的是求解时的可见性，而非发布后的保密性：评估资产与数据集其余部分一起公开。它们的形式仍因子集而异——Code 使用隐藏测试、Web 使用评分器、Office 使用 Rule–Judge 评估、Security 使用确定性评分器——而共同属性是行动与评分之间的时间边界。Code 的诊断性金补丁和 oracle 门控准入在第三节的 Code 小节中描述。

任务目录格式。

任务使用 Harbor [6] 风格的任务目录约定打包，与标准 Harbor 布局相比有一个小差异，即将智能体可见的工作区与回合后评估资产分开：

instruction.md 承载上述自然语言请求。task.toml 在版本化 schema 下承载任务元数据——类别、难度、标签、资源限制以及各角色的超时时间。environment/ 定义沙箱：一个 Dockerfile，仅复制 workspace/ 而不复制其他内容，从而确保智能体可见的表面恰好是待测的代码仓库或业务工件。tests/ 存放回合后评估资源：test.sh 是入口点，grading/ 包含任务特定的检查或评估配置。可选的 gold.patch 是 Code 特定的诊断参考；其在 Code 的 oracle 门控准入中的作用在第 3 节中描述。由于 Dockerfile 仅构建可见的 workspace，且 tests/ 下的所有内容都保留在镜像之外，因此回合后评估边界是打包本身的性质，而非运行时配置的性质。

执行。

打包任务如何执行——沙箱化容器生命周期、模型连接、harness 后端以及每个轨道的评分规则——在第 4 节中一次性规定。

抗污染任务构建。

抗污染性首先源于任务构建方式。由于任务基于真实提交、CVE 和业务场景构建，并被改写为角色扮演式的自然语言请求，而非直接复制公开问题陈述，因此任何任务的指令文本都无法通过联网搜索底层 issue、pull request 或提交线程来还原：可搜索提示词路径在任务编写之时即被封闭，与任务发布时间无关。由于数据集是公开发布的——包括任务目录、评测测试和参考答案——这种抗污染性不能再依赖保密或隐藏评分答案。两个开放基准机制承担了剩余的重任：数据集版本管理，即该套件会定期刷新并重新版本化，使得已发布的快照在暴露累积到一定程度后可以被取代；以及可选的 canary 字符串，用于检测后续对已发布数据集的训练爬取。残余暴露也在同一句话中说明：模型可能已经见过原始的公开提交或 pull request 代码，或者——对于基于 CVE 的安全任务——针对底层漏洞的公开漏洞分析；而且，与 SWE-bench 等任何公开发布的基准一样，公开任务集在发布后也会面临训练暴露，版本管理可以缓解但无法消除这一问题。因此，这一主张是审慎而诚实的：抗污染的任务构建从构造上封闭了可搜索提示词路径，而开放发布的版本管理则随时间管理暴露风险——而非声称该套件完全无污染。

版本命名。

每个子集都带有内部版本标识符，由主索引和日期戳组合而成，但主索引的语义是各子集特有的，而非统一递增，因此不同子集之间的版本号不能直接比较。

2.1 发布内容

该套件以完全开放、SWE-bench 风格的数据集形式发布：运行、评分和审计任务所需的一切内容均为公开。上述构建协议、打包规范、任务目录、工作区/环境镜像、评测框架及其聚合代码、评分测试和参考答案全部发布，因此任何第三方都可以重新运行单个任务并直接检查其内容——该基准完全可复现、可公开审计，而不仅仅是在已发布协议的层面可审计。表 2 列出了发布内容。唯一不包含的是用户数据，这是出于“不存在”而非“刻意保留”：构建过程中任何环节都未使用原始用户提示词、会话或其他用户数据，因此没有可供发布的内容。

媒体内容 · 前往原文查看

组件	状态
任务目录骨架和打包规范（本节）	已发布
任务提示词和指令文本	已发布
用于离线第三方测试的工作区/环境镜像	已发布
评测框架和分数聚合代码	已发布
评分测试（求解时对智能体隐藏的验证器）	已发布
黄金补丁和参考答案	已发布
单任务和聚合分数，以及公开排行榜	已发布
任何类型的用户数据	完全未使用——不存在可供发布的内容

3 基准

腾讯 WorkBuddy Bench 分为四个互补子集——Code、Web、Office 和 Security——每个子集针对不同类别的真实智能体任务，同时共享统一的任务格式和评分理念。本节介绍 Code 子集；后续章节依次介绍 Web、Office 和 Security。

3.1 Code

Code 子集衡量的是智能体能否针对一个完整的开源代码仓库，执行一项真实的、角色扮演式的工程请求——而不是单文件的玩具问题，也不是预先诊断好再交给它的 bug 报告。智能体被放入一个在基线提交（baseline commit）处检出的项目中，必须跨模块定位相关代码、做出修改，并保持项目的隐藏测试全部通过。该子集的独特之处在于其角色和任务类型的多样性：每个任务都由五种请求者角色之一来表述——开发者（developer）、算法工程师（algo）、产品经理（pm）、质量保障（qa）和运维（ops）——并且涵盖的范围远不止修 bug 类工作（表 4、图 2(a)）。

任务来源。

每个任务都将其目标修改表述为一条自然语言的、角色扮演式的请求，因此解决它需要阅读并理解代码仓库本身。在 80 个任务中，有 34 个锚定在针对真实 OSS 快照的真实上游提交上（A 族）；其余 46 个没有上游代码，并按大致内部比例分为：洁净室（clean-room）重实现（B 族，24 个任务，其中包括 4 个将 JavaScript/TypeScript/Rust 目标移植到 Python 的任务）和完全合成的代码工作区（C 族，22 个任务），如表 3 所示。已发布的仓库数量会因是否包含洁净室和移植目标而有所不同，因此我们不报告汇总数量。

媒体内容 · 前往原文查看

族	定义	数量	示例
A	上游提交处的真实 OSS 快照；金标准补丁（gold patch）是真实的人工修复	34	Django、Flask、pytest、Black、Pydantic、httpx、Celery（18 个仓库）$\sim$
B	对目标库公共 API 的洁净室 *_like 重实现，不复制任何原始代码；包括 4 个跨语言移植（JS/TS/Rust 原版移植为 Python）	24	fastapi_like/openapi.py 桩文件，而非 FastAPI 本身
C	完全合成的代码工作区，带有 CSV/JSON 测试数据，旨在直接演练某个角色的工作流程	22	algo 工作区（12 个）和 pm 数据工作区（10 个）

规模与发布。

Code 包含 80 个任务。每个任务都以自包含的 Harbor 风格任务目录形式发布——包含 instruction.md、task.toml 元数据、目标仓库的 environment/ Docker 快照，以及一个存放隐藏测试和诊断性 gold.patch 的 tests/ 目录——遵循第 2 节所述的任务目录格式。

基于 Oracle 的准入机制。

每个候选 Code 任务在准入前需通过两轮验证。首先构建任务镜像，并针对未修改的基线工作区运行其验证器。随后，任务的 solution/solve.sh 应用诊断性 gold patch，之后再次运行验证器。准入要求满足基线奖励和 oracle 奖励。这一机制剔除了初始工作区已过度满足预期契约的任务，以及 gold patch 无法获得完整验证器奖励的任务。Gold patch 仅作为此验证过程的诊断参考，并非唯一正确解法；任何通过隐藏测试的补丁都能获得相应奖励。$\le 0.3$$=1.0$

媒体内容 · 前往原文查看

维度	分布
角色	developer 30，algo 19，pm 15，ops 10，qa 6$\cdot$$\cdot$$\cdot$$\cdot$
难度（编辑标注）	easy 7，medium 31，hard 42$\cdot$$\cdot$
难度（L 阶梯）	L2 4，L3 27，L4 40，L5 9（以 L4 为中心）$\cdot$$\cdot$$\cdot$
准入门槛	基线 0.3，oracle（gold patch）1.0（针对隐藏测试）$\le$$=$

领域与难度。

任务涵盖 18 个细粒度类别，为便于阅读合并为六个使用领域（图 2(a)）。Bug 修复仅占 80 个任务中的 10 个；其余五个领域——功能与接口开发、代码工程、测试、算法工程以及产品/数据分析——承担了剩余 70 个任务，这是对早期基准“修一个 bug、加一个功能”框架的有意扩展。难度主要来自跨模块探索——即找到在哪里修改而非如何修改——并随着任务在 L 阶梯上攀升而随仓库规模和结构增长。L 阶梯是一个仓库复杂度标尺，从 L2（小型、模块少）延伸到 L5（大型多模块代码库）。表 4 给出了角色和难度分布。

构建过程中的早期评估运行展示了失败在仓库规模下是什么样子的：最主要的零分模式是智能体在测试文件编辑上循环直到超时，以及智能体在大型代码库中迷失方向并编辑了完全错误的文件——这证明困难来自导航和定位，而非代码生成。

一个具有代表性的角色扮演请求（产品经理、产品分析、注册漏斗、困难）：

“结账文案实验已经结束；我想先知道新版本是否更好。数据包含展示和购买事件——请计算每组的转化率、收入并给出一个简单结论，不要统计很久之后才发生的购买。”

该请求陈述了意图和约束，而非实现方案：它既没有指明相关文件，也没有说明预期的数据模式，更没有规定排除延迟购买的归因窗口应如何划定，留给智能体自己去从仓库中恢复这些上下文。

评分。

每个任务由在其 Docker 镜像内运行的逐任务验证器在应用智能体的补丁后进行评分；首要的代码指标是运行级得分，即逐任务隐藏测试得分的每次运行平均值。第 4 节完整给出了三种验证器形式、黄金补丁处理方式以及参考读数。图 3 总结了这一任务与评估流程。

3.2 Web

Web 子集测试的是模型能否交付一个可运行、可校验的前端产物——而不仅仅是在对话回合中输出一段看起来像样的 HTML。每项任务都带有“产物而非对话”的契约：智能体必须在声明的输出路径（例如 HTML 入口文件）生成一个可运行的产物；即便回答写得再好，只要该路径下没有产物，无论内容如何都算失败。在全部 70 项任务中，覆盖范围在同一个任务空间内横跨前端产物生成、修改、分析和质量保障：页面实现、页面交互、数据可视化、视觉设计、分析报告、代码测试和文档转换。

任务被划分为七个类别（图 2(b)）：页面交互（21 项任务）和数据可视化（15 项）占主导地位，合计占 70 项任务中的 36 项，其余任务覆盖视觉设计、前端项目分析、代码测试、页面实现和文档转换——这些是传统前端生成基准很少涉及的领域。

从另一个维度看，每项任务都被设计为针对 Web 开发生命周期中的一个环节（图 2(c)）。“从零开始”这一类别只能检验生成能力，因此整个套件中有一半任务要求修复前端状态、运行时或视觉缺陷，扩展现有页面或应用，审查 Web 项目证据，生成回归测试，或将源材料转换为面向前端的交付物——这样，那些只会创建而不会维护的模型就不会获得不成比例的优势。在图 (c) 中，“从零开始”恰好占整个套件的一半（70 项任务中的 35 项），另一半则分布在缺陷修复（8 项）、功能扩展（8 项）、审查与分析（7 项）、测试生成（7 项）和格式转换（5 项）中。

第三个维度追踪交互与状态复杂度。25 个任务是无需交互的前端项目产物，而 45 个任务需要交互或状态管理：单流程状态变更（15 个）、持久化/离线/跨状态行为（13 个）、多步骤工作流（9 个）以及轻度交互（8 个）。这一维度确保子集不会退化为静态页面生成：许多任务要求产物在用户操作下发生状态变更、恢复或保持一致。

页面交互类别中的一个代表性请求（移动端门店预约）：

“我想要一个移动端门店预约页面：用户选择服务和时段，填写联系方式，然后确认。已满的时段不可选择，提交前应有确认步骤。”

该请求明确了意图和若干约束——时段容量、提交前的确认步骤——而非完整规格说明，留给智能体去生成一个可运行的产物，让评分标准能够对照所请求的行为进行核验。

图 4 总结了这一以产物为中心的工作流，从查询理解与智能体执行，到证据提取、互补评判器与清单评分。

评分使用由规则检查、LLM/VLM 评判器和智能体评判器共同评判的评分标准条目。规则检查覆盖确定性交付约束，如文件、格式、预检查和可执行测试；LLM/VLM 评判器审查文本、结构化、DOM、截图和视觉证据；智能体评判器驱动运行中的产物来检查工作流、状态变更和持久化。一次运行仍必须在声明的输出路径交付声明的产物，且任务在无法访问实时互联网、外部账号、密钥或实时数据的环境下运行。第 4 节完整给出条目数量、聚合规则和模型评判器风险。

3.3 办公

Office 子集测试智能体能否在包含混合格式文件的本地工作区中完成一项自然语言工作任务。输入包括电子表格、文档、PDF、JSON 导出文件、Markdown 笔记和文件树；输出包括更新后的工作簿、报告、结构化记录、状态文件和交接材料。智能体必须生成所要求的交付物，保持各文件间信息一致，更新相关状态，保留可供审查的证据，并遵守任务特定的执行约束。评估检查最终工作区，这能捕获纯文本答案评分所遗漏的失败情况，例如写出了看似合理的摘要却没有更新其所描述的工作簿，或创建了文件却使依赖状态不一致。

规模与覆盖范围。

图 5 和图 6 总结了 Office 发布集。第一张图区分了构建路径和校准难度；第二张图将任务类型、场景、输出类别和评估机制排列在同一行中。开放发布集包含 50 个任务，通过两条路径构建：30 个任务根据任务规格和目标能力重建，20 个任务从抽象化的办公工作流扩展而来。两条路径产生相同的发布包，并遵循相同的验证协议。在此覆盖视图所用的宽泛任务族层面，发布集包含 24 个数据、电子表格或结构化处理任务；17 个文档、报告或演示文稿任务；以及 9 个工作区自动化或有状态工作流任务。该图还将任务归入六个办公场景：数据与财务分析（16 个任务）、文档与演示材料（11 个）、对账与后台运营（8 个）、工程与工具工作流（5 个）、有状态工作流（5 个），以及合规与证据整理（5 个）。这些分组描述的是基准覆盖范围，而非对生产请求流量的估算。

难度分为三个校准等级：13 个简单任务、24 个中等任务和 13 个困难任务。输出类型采用多标签计数：24 个任务生成电子表格，20 个生成 Markdown，15 个生成 JSON，6 个生成纯文本，5 个生成工作区或状态输出，另有少量涉及演示文稿、CSV、清单、文件系统和审计日志交付物。该版本以文本优先：其核心任务和评估不需要 OCR、视觉语言模型或像素级布局判断。

构建与难度。

每个任务都从目标能力或工作流出发。随后我们构建智能体可见的工作区并分离评估资产，在保存的提交上测试评估器，校准难度，并执行发布检查。在执行过程中，智能体只能看到请求和声明的输入；参考答案、预期状态、规则检查、语义评分标准和评估支持文件仅在智能体完成后使用。发布前，保存提交的回放会检查评估器是否覆盖了客观要求、是否为语义评分标准提供了充分证据，并且不会对有效的高质量输出进行惩罚。

难度来自解决路径而非单纯的文件数量。常见要求包括跨文件键匹配和别名解析、时间或状态依赖、规则优先级、冲突或缺失的证据，以及多个交付物之间的一致性。困难任务可能要求智能体协调多个来源、保留未解决的冲突、同时更新主要交付物和状态记录，并避免被禁止的副作用。这些要求有助于区分模型能力，而不依赖实时服务或未公开的账户。

一个代表性任务“医院床位利用率”提供了一张病房配置表、一份入院日志和一张床位状态策略表。智能体必须按病房和床位类型计算月度利用率，并生成一个包含利用率明细和病房级汇总的两工作表工作簿。仅给出一个看起来合理的百分比是不够的：提交结果必须跨数据源解析键值、规范化日期、应用正确的报告周期和策略分母、保留要求的表结构，并保持明细表与汇总表相互一致。因此，该任务测试的是完整文件工作流的可靠性，而非单一计算能力。

评分。

每个 Office 任务都使用两个评分组件：确定性规则检查和基于证据的 LLM 评审。规则检查是对可精确评估的客观要求（如必需文件、表结构、数值、数据源关系、状态转换、副作用和执行约束）进行的二元测试。每条语义评分标准定义一个二元质量条件，由评审基于任务结束后生成的固定证据（包括提交的交付物以及任务特定的状态或数据源摘要）进行评估。评审不会检查实时工作区，也不会更改已记录的规则检查结果。全部 50 个任务均使用这两个组件。对于选定的任务，状态差异（10 个任务）、受控环境（6 个）、执行轨迹（5 个）或运行时边界（3 个）为规则检查或语义评分标准提供证据；它们不是额外的评分通道。第 4 节定义了每个任务如何组合规则得分与评审得分、试验如何聚合，以及评审结果不可用时如何处理。图 7 总结了评估流程。

3.4 安全性

安全子集覆盖了安全团队的完整光谱——红队发现与安全利用、恶意软件分析、安全运营以及智能体安全评估——它提出的问题比代码部分中的漏洞修复任务更为尖锐：智能体能否像安全研究员那样定位真实漏洞并在沙箱环境中安全复现，能否像恶意软件分析师或SOC操作员那样分析恶意软件样本或对告警流进行分类，能否像AI红队成员那样探测使用工具的智能体。给定一个任务，智能体必须依次完成每一步，事先不会获得任何缺陷位置或预期行为信息，且每个任务都在沙箱化的评估环境中运行。该子集与套件其余部分的区别在于，它完全不使用LLM评判器：每个任务都附带一个确定性评分程序，将智能体输出直接转化为数值奖励，并由五层防作弊基础设施支撑，以封堵硬编码和枚举攻击。

安全子集包含60个任务，涵盖六个细粒度领域，归并为四个模块，横跨红队和蓝队两大方向（表5、图8）。按方向分组，该套件以红队为主——38个任务对22个蓝队任务——但仍完整覆盖了防御/检测闭环，且难度按设计刻意偏向困难，反映了真实安全工作的分布，其中困难案例多于简单案例。

媒体内容 · 前往原文查看

模块	角色	任务数	方向
漏洞发现与利用	安全研究员	32	红队
恶意软件分析	反病毒工程师	14	蓝队
安全运营	SOC分析师/检测工程师	8	蓝队
智能体安全	AI红队	6	红队

难度按设计刻意偏向困难。

每个任务的确定性评分器都在隔离的 Docker 容器内执行，并直接写入数值奖励，因此同一输出被重新评分两次会返回相同数值（图 8，右）。第 4 节给出了各评分器的定义——PoC 和 flag 验证、IOC 匹配、零误报约束下的 YARA 匹配率，以及宏 F1/Kendall-tau 报告评分。

发现与利用环节涵盖白盒源码审计、黑盒二进制利用和 Web 利用三类任务。白盒审计在广泛部署的上游项目中复现真实的历史 CVE——包括 binutils、curl、nginx、vim、jq 和 fluent-bit——采用“发现漏洞-编写 PoC-验证”的两步结构，其中第二步以通过第一步为前提。在这类代表性任务中（例如针对 binutils 的任务），第一步只给智能体源码树，要求它阅读解析器、追踪数据流并定位漏洞代码路径，按阈值评分通过后才解锁第二步环境；只有此时智能体才能提交概念验证输入，且该输入只有在沙箱容器内可复现地触发 ASAN 崩溃才算通过——这种节奏设计旨在模拟真实的“先审计后利用”实战流程，而不是一开始就把缺陷位置直接交给智能体。Web 利用案例围绕具体、具名的技术构建（例如 House of Apple2 和 ECDSA nonce 重用），而非泛化的漏洞类别。六项智能体安全任务针对使用工具的 AI 智能体特有的攻击面——智能体间提示词注入、ReAct 链劫持、多模态提示词链注入、工具模式混淆、通过摘要工具进行数据外泄，以及延迟触发攻击——每项任务都要求智能体返回一份带有 CVSS 严重性评级的结构化发现报告，模拟安全团队在发布前智能体安全审查中期望收到的交付物。$\to$

反作弊机制。

为了在完全自动化、无人工评判的验证方式下保持分数的有效性，每项任务都置于五层反作弊基础设施之后，从输入、代码和输出三个维度封堵硬编码和枚举攻击：

• 针对硬编码答案的禁用字面量扫描。

• 重命名输入测试，检查提取器是否真正解析结构而非依赖文件名。

• 针对尾部数据篡改的覆盖/篡改测试。

• 编码依赖测试，要求检测规则锚定字节而非明文。

• 低权重诱饵字段，抑制盲目枚举带来的奖励。

与其他子集一样，Security 在 CodeBuddy Code 和 Claude Code 两种 harness 下、以思考模式进行评分，取三次运行的平均值；结果见第 5 节。

4 评测 Harness 与评分

一个基准测试的数字，其可信度取决于生成这些数字的机制。腾讯 WorkBuddy Bench 将这一机制视为头等贡献，而非实现细节：每个任务，无论属于哪个赛道，都以自包含的任务目录形式交付，并在一个共享 harness 下、于沙箱容器内执行；该基准测试完全开源发布——任务目录、环境镜像、评测代码、评分测试以及参考/标准答案全部公开。外部方无需对该基准测试的内部基础设施拥有特殊访问权限，也无需为每个子集定制专属评测路径：仅凭公开发布的内容，即可复现分数，并可直接对任意单个任务进行重跑和审计。本节描述该 harness、智能体如何连接被测模型，以及各赛道适用的评分规则；上文各子集章节将评分细节统一归入此处说明。

沙箱执行与模型连接。

每次试验都会在隔离容器内运行任务环境；智能体只能看到任务声明的工作区，而任务特定的评估资源会在智能体完成操作之后才被引入沙箱或由评估流水线调用，因此评分过程绝不会泄漏到智能体的上下文中。模型与沙箱的关切被刻意分离：测试框架既可以直接访问模型后端，也可以通过一个本地代理访问——该代理负责协议转换、模型名称重写和请求日志记录；同时，它既可以在本地机器上执行沙箱，也可以在远程隔离的沙箱后端上执行。当沙箱在远程运行时，基准测试一侧的代理绝不会被放入其中——任何原本应由代理承担的协议处理都留给模型服务自身完成——而无法满足这种分离要求的沙箱后端与连接模式组合会被直接禁用，而不是静默回退到其他路径。为完整起见，这里披露一种访问不对称性：本次评估中使用的 HY（Hunyuan）端点由其提供商第一方提供服务，而所有其他模型均通过第三方服务端点访问；第三方的参数配置和请求处理可能会影响指标。

测试框架后端。

默认执行框架是 CodeBuddy Code；Claude Code 直接使用 Anthropic 协议，只要模型自身的协议支持该路径，就可作为替代方案使用。四条赛道均在两种框架下并行运行并分别报告结果（双框架报告），因为相对排名在两种框架之间可能发生变化——在一种框架下领先的模型，在另一种框架下未必领先（第 5 节）。推理模式（思考 vs. 不思考）是框架按模型记录的另一个配置维度，与下文所述的采样超参数并列；第 5 节的排行榜全程报告思考模式配置。在两种框架下，协议都将推理强度固定为高，将上下文窗口统一为 200k token 并设置统一的自动压缩阈值，同时禁用 WebSearch 和 AskUserQuestion 工具；除此之外，每个模型均以其供应商默认推理超参数运行，具体记录如下。报告结果与本次评估所用两个框架的特定构建版本绑定，指标可能随框架版本演进而变化。

评分形式。

赛道任务集中的每个任务都会产生一个验证器奖励，模型的赛道得分是未加权平均值$t$$𝒯$$r_t\in [0,1]$

$S=\frac{1}{\left|𝒯\right|}\sum _{t\in 𝒯}{r}_t,$

（1）

在赛道有多个独立运行的情况下，对多次独立运行取平均。每个任务的奖励因赛道而异。对于代码赛道，奖励是智能体补丁的隐藏测试通过率。对于网页赛道，奖励根据任务特定的一组评分细则项计算：每个细则项返回通过/不通过；设 为失败的非致命项集合，每项带有惩罚 ；任何致命失败都将任务奖励设为零：$r_t$$F_t$$p_{t,i}$

$r_t=\{\begin{array}{cc}0,& \text{if any fatal item fails},\\ \max (0,1-{\sum }_{i\in F_t}{p}_{t,i}),& \text{otherwise},\end{array}$

（2）

对于办公赛道，任务奖励是确定性规则得分与基于证据的裁判得分的任务特定混合，定义如下；对于安全赛道，每任务的确定性评分器结合三个程序化项（图 8），对三次运行取平均。$r_t=w_1\text{artifact}+w_2\text{correctness}+w_3\text{robustness}$

各赛道评分。

每个任务都以相同方式打包和执行，但从中计算的奖励因赛道而异：

• Code——由 Harbor 评测框架 [6] 计算的运行级分数：每个任务隐藏测试分数的逐次运行平均值，这是本报告全篇的 Code 核心指标。验证器采用三种形式之一——pytest 注入测试套件（80 个任务中的 22 个）、无需 pytest 或网络访问的功能性布尔断言（80 个任务中的 54 个）、或用于仓库理解任务的 JSON 报告评分器（80 个任务中的 4 个）；gold patch 仅用于诊断目的，任何满足要求的补丁均可获得满分。任务级聚合单元测试通过率和 LLM 评判分数仅作为参考值记录。

• Web——对 786 个评分项进行评分标准打分。规则检查覆盖 62 个确定性交付和预检项；LLM/VLM 评判器覆盖 676 个涉及文本、代码、结构化内容、DOM 摘要、截图和视觉证据的项；智能体评判器覆盖 48 个需要操作运行中产物的项，如工作流完成、状态变更、持久化和跨状态一致性。未通过的项会扣除配置的罚分（），而致命失败则将任务奖励设为零。每个任务仍必须在声明的输出路径交付可运行的产物，且不得访问实时互联网、外部账户或密钥。$0.1/0.2/0.3$

• Office——两个独立保留的评分通道，每个由二元检查组成。确定性规则检查验证文件中的客观事实、结构、数值、跨文件关系、状态变更、副作用和执行边界。每个语义评分标准指定一个由 LLM 评判器在任务结束后评估的、基于证据的二元质量条件。评判器接收公开的任务指令、完整的规则检查结果，以及仅限所评估评分标准指定的固定证据；它不检查实时工作区，也不修改已记录的规则检查结果。每个任务预先配置两个通道分数的组合方式。

• 安全——隐藏测试验证，无需 LLM 评判：每个任务附带一个 scoring.py，在隔离容器中运行，直接写入数值奖励——利用类任务验证 PoC 或捕获的 flag，恶意软件分析任务将 IOC 与基准真值比对，YARA 规则任务在零误报约束下检查匹配率，SOC 报告任务则通过宏 F1/Kendall-tau 与参考报告进行评分。每个分数取三次独立运行的平均值。五层反作弊基础设施（禁用字面量扫描、重命名输入测试、覆盖/篡改测试、编码依赖测试和低权重诱饵字段）可防止在输入、代码和输出三个维度上进行硬编码。

Office 规则–评判组合。

对于 Office 任务的受审模型，设 为任务中通过的确定性规则检查数量。规则分数为$m$$a$$i$$P_{m,i,a}$$N_i$

$R_{m,i,a}=\frac{P_{m,i,a}}{N_i}.$

(3)

如果任务具有语义评分标准且评分标准返回 ，则评判分数为$i$$K_i$$k$$b_{m,i,a,k}\in \{0,1\}$

$J_{m,i,a}=\frac{1}{K_i}\sum _{k=1}^{K_i}{b}_{m,i,a,k}.$

(4)

试验分数使用任务预配置的规则权重 ：$w_i$

$S_{m,i,a}=w_i{R}_{m,i,a}+\left(1-w_i\right)J_{m,i,a}.$

(5)

每个任务将 固定在 0.70 到 0.95 之间；Office 不使用单一的全局规则权重。设 为任务 的可用试验次数。这些试验先取平均，即 。如果任务至少有一次可用试验，则 Office 分数为其等权宏平均，$w_i$$A_i$$i$${\overline{S}}_{m,i}=A_i^{-1}{\sum }_a{S}_{m,i,a}$$T$

${\mathrm{Overall}}_m=\frac{1}{T}\sum _{i=1}^T{\overline{S}}_{m,i}.$

(6)

规则和评判子分数使用相同的两级聚合，并保留用于诊断。证据提取失败或评判调用失败仅将受影响的评分标准置零；其余评分标准继续执行。如果某次试验因评判输入超过支持长度或所有评判调用均失败而没有评判分数，评估器将保留规则分数和错误状态，将该组合试验分数标记为不可用，并将该试验从两个聚合级别中排除。

基于评判的组件与评分风险。

该套件中的三个组成部分采用模型评判而非程序化评判：Web 的 LLM/VLM 与智能体评判细则项（其惩罚按任务配置）、Office 的 LLM 评判层（用于语义质量检查），以及 Code 的 LLM 评判分数（仅作为参考值记录，绝不进入核心指标）。已知风险在于模型评判偏差——评判模型可能系统性地偏好特定输出风格或自身所属的模型家族。该风险敞口在构造上受到约束：核心指标依赖于 Code 的确定性验证（隐藏测试）和 Security 的逐任务确定性评分器（无 LLM 评判）；Office 通过将每项二元语义细则绑定到固定的任务后证据、保留确定性规则结果作为独立分数、并防止评判结论改变这些结果，从而降低（但未消除）LLM 评判风险；Web 则保留对交付和预检约束的确定性规则检查，同时将 LLM/VLM 与智能体评判锚定在最终产物中记录的证据上。

推理超参数。

模型的有效采样行为可在三个不同层面设置——厂商自身的服务端默认值、基准测试的路由/网关层，以及任务配置中的显式覆盖——因此该项目维护一份逐模型超参数记录（涵盖温度、top-p、最大 token 数以及推理/思考开关等字段），以避免混淆三者。该记录目前涵盖为七个评估模型填充的 schema。实践中，大多数模型在无显式采样覆盖的情况下运行，而基准测试刻意固定并逐模型报告的唯一下参数是推理模式。

披露政策。

腾讯 WorkBuddy Bench 作为一个完全开放的基准测试发布：任务目录、环境镜像、评估代码、评分测试以及参考/标准解决方案均与汇总排行榜一同公开，遵循 SWE-bench 风格惯例，即发布完整任务集而非仅发布汇总分数。“隐藏测试”（针对 Code）和“保留评估资源”（更普遍而言）这两个术语描述的是求解时的可见性，而非保密性：它们在运行期间对智能体自身的上下文不可见，并且仅在智能体完成操作后才被引入或调用（见上文），但它们在发布的数据集中与其他所有任务工件一样是公开的。抗污染能力反而依赖于任务在创作时的新鲜度——任务由发布日期之前被排除在模型预训练语料库之外的内容构建——而非在发布后扣留任务内容。

5 结果

本节报告腾讯 WorkBuddy Bench 排行榜，并结合该套件旨在回答的问题进行解读：智能体能力在四类不同的真实工作——Code、Web、Office 和 Security——中如何排名，以及当测试框架本身发生变化时，该排名的稳健性如何。每个分数都是思考模式下三次独立运行的平均值，并且所有四个子集都在 CodeBuddy Code (cbc) 和 Claude Code (cc) 两种测试框架下进行评分。每个模型都在每个轨道/框架组合上被评分；一个单元格——Claude Opus 4.8 在 Claude Code 框架下的 Code 分数——来自一次修改指令的运行，已在表 6 中标记并在其标题中说明。$‡$

媒体内容 · 前往原文查看

	Code		Web		Office		Security
模型	cbc	cc	cbc	cc	cbc	cc	cbc	cc
Claude Opus 4.8	74.43	77.90‡	68.14	69.86	82.37	83.23	64.37	65.87
GPT-5.5	72.90	76.63	61.14	64.86	81.96	86.05	64.39	77.91
GLM-5.2	71.54	77.06	67.43	60.71	79.60	79.57	76.32	80.86
HY-3	62.90	66.26	67.71	66.43	82.08	80.08	64.50	65.59
MiniMax-M3	60.14	66.42	58.00	52.57	78.28	76.30	74.14	59.30
DeepSeek-V4-Pro	58.92	64.59	54.57	51.57	79.11	78.71	70.04	58.73
DeepSeek-V4-Flash	55.73	61.89	47.29	50.29	77.47	77.54	67.11	53.90

各赛道领先者。没有任何单一模型在所有榜单上登顶。在表 6 的八个榜单中，领先地位由三方瓜分：Claude Opus 4.8 领先五个——两种框架下的 Code（cbc 下 74.43；cc 下 77.90，来自表注中提到的修改指令运行）、两种框架下的 Web（cbc 下 68.14，cc 下 69.86），以及 cbc 下的 Office（82.37），HY-3（82.08）紧随其后位列 Office 第二；GLM-5.2 领先两个——两种框架下的 Security（cbc 下 76.32，cc 下 80.86）；GPT-5.5 领先一个——cc 下的 Office（86.05）。一个开放权重模型 GLM-5.2 能在两个 Security 榜单上双双登顶，这本身就是一项发现：在这套测试集上，开放权重模型与闭源前沿模型之间的差距因赛道而异，而非整体一致。$‡$

测试框架敏感性。在两种测试框架下对全部四个赛道进行评分后，可以明显看出测试框架并非中立的测量工具——四个赛道受到的影响程度差异很大。代码赛道的变动最为一致：模型在代码赛道上的排名顺序在两个测试框架下有所不同——GPT-5.5 在 cbc 框架下领先于 GLM-5.2（72.90 对 71.54），但在 cc 框架下则落后于后者（76.63 对 77.06）——而 Claude Opus 4.8 在修改指令后的 cc 框架下的得分也高于其在 cbc 框架下的得分。111测试框架与模型的集成细节在单一框架内也很重要：对 HY-3 在代码子集上启用跨轮推理回传（即思考内容在轮次间回传给后端）进行的诊断性重跑，在相同的三轮测试协议下，CodeBuddy Code 框架得分为 66.72（高于排行榜配置），Claude Code 框架得分为 68.18。排行榜报告的是标准配置下的结果。网页赛道在 Claude Code 框架下的表现更为复杂：七个双框架评分模型中，有四个得分下降，降幅从（HY-3）到（GLM-5.2）不等，而三个模型得分上升——Claude Opus 4.8（）、DeepSeek-V4-Flash（）和 GPT-5.5（）；带符号的平均变动为，且 Claude Opus 4.8 在两个框架下均领跑网页赛道。办公赛道变动最小：七个双框架评分模型中有五个的变动幅度在 2 分以内（绝对变动中位数为 0.86），例外是 GPT-5.5（）和 HY-3（）。安全赛道在两个框架间的排名重排幅度最大：七个双框架评分模型的平均绝对变动为 8.6 分。GLM-5.2 在两个框架下均领跑安全赛道，但其下方的排名发生了显著变化：GPT-5.5 从 cbc 框架下的第六名升至 cc 框架下的第二名，而 MiniMax-M3 则从第二名跌至第五名。$+3.82$$+1.92$$-1.28$$-6.72$$+1.72$$+3.00$$+3.72$$-1.14$$+4.09$$-2.00$

安全赛道的拒答情况。少数安全赛道的运行在涉及安全类请求的任务层面以拒答告终。在三次运行中，Claude Opus 4.8 在 Claude Code 框架下记录了 13 次拒答（在 CodeBuddy Code 框架下为零次），GPT-5.5 在 CodeBuddy Code 框架下记录了 2 次拒答，其余所有模型均未记录拒答。这些计数仅供参考；排行榜得分是对所有实际执行的运行结果取平均值。

编码与数据及算法类任务之间的差距。代码子集自身的类别体系将纯编码工作与数据和算法类工作区分开来，而两者之间的差距是系统性的而非偶然的：按类别细分（表6中未显示，取自该子集内部的按类别结果）发现，模型/测试框架配置在数据与算法任务上的得分几乎普遍高于编码任务，平均约为74%对65%。该细分结果附带的解读是，数据和算法类任务很少像代码那样难——它们的难度在于业务或数据语义——而在既有契约下精确修复真实代码库才是更具区分度的技能。表6与此一致：在同时参与两项评测的每一个模型/测试框架配置中，编码得分都低于同一配置的办公类得分，通常低十分或更多；而编码得分在除一种情况外的所有情况下都高于同一配置的网络类得分——HY-3是唯一例外，它在两种测试框架下网络得分均高于编码得分，在cbc下明显如此（67.71对62.90），在cc下则勉强如此（66.43对66.26）。

哪些编码类别最难。对代码子集按类别细分（所有有效配置的平均奖励）在更细粒度上说明了同样的问题。最难的两个类别是bug_fix（均值0.47）和api_contract（均值0.47）——即真实代码库的回归修复和精确、遵循契约的接口工作——而最容易的是feature_pipeline（0.94）和testing（0.88），这些是定义明确的合成流水线和测试编写任务。几个产品/分析类别的模型间差异异常大（product_analytics在不同模型间从0.08到1.00不等），这类任务的特点是得分取决于模型是否正确理解业务意图，而非其代码能否运行。

为什么 bug_fix 是最难的类别。这些任务是真实的、以口语化方式描述的上游回归问题，且根因被刻意隐藏。解决一个问题意味着要从一句话的症状描述中定位一个间歇性、依赖上下文的故障——这纯粹是对代码仓库的理解，没有任何算法难度——然后以最小改动打补丁，同时不破坏周边契约。较低的平均分（0.47）表明，当前模型恰恰在 SWE-bench 这类技能上仍显吃力，即把模糊的报告定位到大型代码库中正确的代码行。另一个相关但不同的失败模式是语义正确但契约不匹配的代码：模型在错误的函数名、参数形状或输出格式下实现了正确的行为，因此功能验证器仍然判定其失败。这在 api_contract 上最为突出，因为任务必须在现有契约下保留一组精确的字段，而只要丢掉一个字段，依赖它的检查项就会全部归零。

两种代表性的失败模式。两个 Code 类别的失败案例说明了丢分的主要方式。在一个 OpenAPI 契约任务中，模型产出了行为上合理的结果，但丢掉了一两个必填字段（例如 deprecated 或 examples），或者将路径参数的 required 标志保留为默认值；由于验证器会运行十几个逐字段的布尔检查，每一次遗漏都会使依赖该字段的检查归零，从而大幅拉低总分——问题与其说是功能错误，不如说是测试所隐含的契约未被匹配。在一个产品分析任务中，口语化的要求是计算每组转化率和收入，同时“不统计很久之后才发生的购买”——这隐含了一个转化归因窗口。高分模型会按该窗口过滤掉延迟购买；低分模型则忽略这一约束，统计所有购买，从而高估转化率，尽管两种情况下代码都能正常运行。差距完全来自是否理解了业务规则，这正是该类别上模型得分分布几乎横跨全区间的原因。

Web 能力切片。Web 切片结果指向一个一致的规律：视觉设计与分析性报告是最强的类别，代码测试与页面实现次之，而页面交互与数据可视化语义暴露出的失败最多。交互/状态轴则讲述了一个互补的故事：非交互与轻度交互的产物得分远高于有状态产物——单流程状态变更、多步骤工作流，以及持久化、离线与跨状态行为，是该子集中最难的切片。

失败模式与其说在于渲染一个可见页面，不如说在于未能闭环前端工程链路。模型往往能产出看似合理的 UI，却在状态来源、展示、持久化与最终载荷之间失去一致性——交互与有状态切片恰恰是得分最低的地方——或者产出图表与数据可视化结果，却没有清晰的“来源到输出”的证据链。按评测信号来看，LLM/VLM 项目占据了大多数检查项和大多数失败项；规则类失败主要反映交付、预检、格式或可执行测试契约问题，而智能体评判类失败则对应运行产物中的工作流或状态断裂。

按难度与任务类型划分的 Office 表现。图 9 展示了 Office 表现如何随难度及七种诊断性任务类型而变化。在每个测试框架内，跨模型平均得分从简单到中等再到困难任务依次下降（cbc 下为 84.6/80.3/73.1，cc 下为 83.9/78.9/72.0）。模型优势也因任务类型而异：Claude Opus 4.8 在两个框架下均领先多源合并与对账任务，而 GPT-5.5 在 cc 框架下领先所展示的七种类型中的五种，包括聚合与指标推理、复杂规则执行，以及结构化抽取。这一视角还揭示了被聚合得分掩盖的差异：GLM-5.2 在两个框架下的总体表现几乎不变（79.60 对 79.57），但其多文件抽取得分从 87.7 降至 70.5，而复杂规则执行则几乎保持不变（83.1 对 83.3）。

已审阅 Office 提交中的常见失败模式。我们检查了部分低分任务的交付物及 Rule/Judge 证据。相同的问题反复出现：相关交付物之间不一致，记录未明确关联到其来源或当前状态，结构化文件无法解析，或者智能体在未经验证的情况下提交产物。由于 Office 验证器会检查文件、跨文件关系、状态、输出契约以及基于证据的语义要求，这些不完整的工作流程即使某一项交付物看起来合理，仍会失分。

5.1 Token 与轮次效率

表 7 报告了 Code 子集上每次运行的平均助手轮次、输出 token 和输入 token。轮次按唯一的助手消息计数，包括主智能体之外的子智能体活动。输出 token 在两个测试框架之间具有可比性；输入 token 按包含缓存的方式报告——即同时计入缓存上下文读取和新增输入——且在不同测试框架之间不可比，因为两个框架在上下文和缓存管理上采用不同约定，因此输入数据应仅在单个测试框架列内解读。输出 token 计数也不应被视为跨模型的效率指标：不同模型使用不同的分词器，因此一个 token 在不同模型之间并非恒定的工作量单位，以下比较仅为说明性参考，而非严格的跨模型效率排名。

媒体内容 · 前往原文查看

	CodeBuddy Code (cbc)			Claude Code (cc)
模型	平均轮次	输出（千）	输入（千）	平均轮次	输出（千）	输入（千）
Claude Opus 4.8	29.51	22.3	928.7	13.2‡	4.7‡	646.5‡
GPT-5.5	26.92	6.9	753.2	30.44	8.7	696.5
GLM-5.2	33.06	12.3	861.4	33.73	22.0	1243.3
HY-3	26.02	9.3	586.8	18.07	13.9	659.2
MiniMax-M3	28.89	8.5	1021.4	33.90	10.6	1308.3
DeepSeek-V4-Pro	44.01	10.2	800.0	24.20	23.7	642.3
DeepSeek-V4-Flash	40.30	9.8	700.5	23.12	28.6	771.4

三点观察。第一，GPT-5.5 以极小的输出预算取得了顶级分数：在 cbc 下每次运行仅消耗 6.9k token，是该测试框架下最低的输出预算；在 cc 下为 8.7k，是标准协议运行中的最低值——而其他模型大多消耗 8–29k；cc 下最小的整体输出属于 Claude Opus 4.8 的修改指令运行（4.7k）。第二，消耗与排名并不一致：DeepSeek-V4-Flash 在 cc 下的输出约为 GPT-5.5 的 3.3 倍（28.6k 对 8.7k），但得分却低了 14.74 分（61.89 对 76.63）；GLM-5.2 在 cc 下取得 77.06 分，消耗了 22.0k 输出 token，而 GPT-5.5 仅用 8.7k 就领先了 0.43 分——与此同时，Claude Opus 4.8 以最高的 cbc 输出（22.3k）搭配 cbc 领先成绩。第三，在标准协议运行中，轮次数量在不同配置间大约相差 2.4 倍（每次运行 18.07 到 44.01），且两个极端都与分数无关：最精简的标准配置是 cc 下的 HY-3，每次运行 18.07 轮，得分 66.26 处于中游；而轮次最多的两个配置（cbc 下的 DeepSeek-V4-Pro 为 44.01 轮，DeepSeek-V4-Flash 为 40.30 轮）恰好是 cbc 配置中得分最低的两个。Claude Opus 4.8 的修改指令 cc 运行低于标准范围，每次运行仅 13.2 轮、4.7k 输出 token。$\times$$\times$

跨子集。

代码预算画像并非普遍适用。办公场景最为精简——各模型和测试框架下每次运行仅需 16–42 轮交互和 10–30k 输出 token——而网页场景居中（13–39 轮），安全场景则远超其他赛道，每次运行需 30–89 轮。¹ 安全场景的轮次和 token 统计仍沿用早期的轮次计数约定，尚未按独立助手消息重新计算；因此其轮次数据与表 7 中的代码场景数据不具直接可比性。安全场景的极端情况十分突出：MiniMax-M3 在 cbc 条件下平均每次运行需 88.8 轮，包含缓存在内的输入 token 约 11.1M，对应得分 74.14。在所有四条赛道中，GPT-5.5 始终是输出最精简的高分模型：在 cbc 条件下，它在每条赛道上的输出预算均为所有模型中最小——代码场景每次运行 6.9k 输出 token，网页场景 13.5k，办公场景 10.2k，安全场景 7.5k。

6 相关工作

我们首先将腾讯 WorkBuddy Bench 与代码、网页、办公和安全领域的现有智能体基准进行定位对比；该套件自身的任务构建方法、子集设计和评估框架将在后续章节详述。这些是依据该基准对任务设计的定性分析得出的设计阶段对比，而非在这些套件之间对智能体进行面对面的实测评估。

代码。Code 子集与 SWE-bench 系列[1, 2]以及 Commit0[7] 这类“从零构建代码库”的基准测试所覆盖的问题空间相近，但在指令风格和角色多样性上有所不同。SWE-bench 和 SWE-bench Verified 提供的是详细的 GitHub issue，而 Commit0 提供的是测试驱动的规格说明供实现参考——Code 任务则以简短、口语化的请求形式编写，更接近队友提出需求的方式，而非正式提交的 issue，刻意让实现细节保持未明确说明的状态；并且 Code 覆盖了五种请求者角色（开发工程师、算法工程师、产品经理、QA、运维），涉及除缺陷修复之外的 18 个类别，而非单一的 issue 解决框架。该系列在抗污染策略上各有不同：LiveCodeBench[8] 依赖模型训练截止日期之后发布的问题，而 Code 则依赖全新编写的任务目录——包括真实的上游提交、洁净室重新实现以及合成工作区——这些内容在基准测试发布之前一直构建并保密，发布时提示词、隐藏测试和黄金补丁会随之一并完整公开。RepoBench[9] 和 Aider Polyglot[10] 则聚焦于同一空间内更窄的切片（仓库级补全和模板化多语言练习），而 Terminal-Bench[11] 评估的是通用终端智能体能力，而非仓库范围内的代码变更。

端到端与生产级编程智能体基准测试。Vibe Code Bench [12] 评估从文本规格说明到零基础 Web 应用开发的完整流程，并通过部署应用上的浏览器智能体工作流测试进行验证，使其成为可运行前端交付物的紧密参考基准。CursorBench [5] 则通过不同路径追求类似的真实感目标：它将已提交的代码追溯到真实生产会话中的原始智能体请求，因此其任务分布锚定于某一家供应商用户的实际工作方式，而非精心策划的 issue 文本。这些选择使两个基准测试都成为重要的参考点，但它们为我们的场景留下了不同的空白。Vibe Code Bench 专注于从零开始的应用构建，而 WorkBuddy Web 还涵盖修改、审查、前端项目测试、分析和转换。CursorBench 是闭源的，因此其任务集、类别分布以及任何对供应商自身智能体的选择偏差都无法被独立审计，其代表性也无法被确认能扩展到该供应商用户群体之外。腾讯 WorkBuddy Bench 通过基于分布信息的方法追求真实感，然后将结果完全开源发布：任务类别、形态和意图均对照真实使用情况进行校验（第 3 节），任务从真实工件中逆向工程而来，并经过整理或合成以匹配该分布，而非直接发布原始生产会话；最终的任务目录、环境镜像、评估代码、评分测试和参考解决方案全部公开，可独立审计。

Web。Design2Code [3] 和 Interaction2Code [13] 评估从参考设计进行静态和轻度交互式页面复现；FrontendBench [14] 将自动评判扩展到更广泛的前端生成任务；WebArena [4] 和 VisualWebArena [15] 则评估智能体在现有浏览器环境中进行操作，而非从头生成可运行的产物。每个基准在一两个维度上表现突出——静态复现、交互式生成、浏览器智能体操作或代码维护的真实性——但没有任何一个能在单一评估中同时涵盖页面/UI 工作、数据和图表产物、前端项目文档、测试和分析、非从零开始的完整生命周期覆盖、运行时交互/状态检查，以及规则、LLM/VLM 和智能体评判。表 8 将这些维度分开列出，而非报告任务数量，因为已发布的基准规模在网页、交互、问题和应用规格等不同单位之间无法直接比较。该比较是定性且基于各基准自身已发布描述的自述，而非实测评估。

媒体内容 · 前往原文查看

工作表面

生命周期

运行时证据

评判机制

基准

UI

应用

数据

文档/测试

从零开始

修复/扩展

审查/转换

操作

状态

规则

VLM

智能体

Vibe Code Bench v1.1

$\bullet$

$\bullet$

$\circ$

$\bullet$

$\bullet$

$\circ$

$\bullet$

$\circ$

CursorBench 3.1

$\circ$

$\circ$

$\circ$

$\bullet$

$\bullet$

$\circ$

$\bullet$

Design2Code

$\bullet$

$\bullet$

$\circ$

$\bullet$

Interaction2Code

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\circ$

$\bullet$

$\circ$

FrontendBench

$\bullet$

$\circ$

$\bullet$

$\bullet$

$\circ$

$\bullet$

WebArena

$\bullet$

$\bullet$

$\bullet$

$\bullet$

VisualWebArena

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\circ$

WorkBuddy Web

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

$\bullet$

Office。近期基准覆盖了办公智能体工作的互补部分。Workspace-Bench 1.0 [16] 使用细粒度评分标准，在多种智能体框架上评估具有大规模异构文件依赖关系的任务。ClawsBench [17] 评估 Gmail、Calendar、Docs、Drive 和 Slack 快照恢复模拟中的能力和安全性。OdysseyBench [18] 针对长周期、多应用工作流及扩展交互历史，而 SpreadsheetBench 2 [19] 则探究复杂多工作表工作簿中的端到端构建、修复和可视化。

ClawsBench 和 OdysseyBench 强调跨多个应用的交互，SpreadsheetBench 2 聚焦于工作簿工作流，而 Workspace-Bench 则处理异构文件依赖关系。WorkBuddyBench-Office 是该套件中的 Office 子集，专注于包含多种文件格式的本地工作空间中的完整交接。智能体必须将源信息带入交付物中，保持相关文件和状态的一致性，并在 CodeBuddy Code 或 Claude Code 下遵守执行约束。确定性规则检查用于验证文件、跨文件关系、状态变更、副作用和执行约束，同时一个基于证据的大语言模型评判器（LLM Judge）根据任务后固定证据对二元语义评分标准进行打分。每个任务自行设定其规则/评判器权重。这些比较涉及任务和验证设计；各基准测试使用不同的任务单元、环境和评分方案。

安全。现有的安全智能体基准测试各自覆盖红队侧的一个切片：Cybench [20] 和 NYU CTF Bench [21] 对专业级和竞赛级 CTF 挑战进行评分，InterCode-CTF [22] 将 CTF 解题视为带执行反馈的交互式编码，CVE-Bench [23] 衡量对真实世界 Web 应用 CVE 的自主利用能力，而 Meta 的 CyberSecEval 系列 [24, 25] 则评估模型自身的网络安全风险和能力，涵盖从不安全代码建议到进攻性操作辅助等各个方面。Security 子集在两个维度上有所不同：覆盖范围和评分方式。其 60 个任务在单一套件中涵盖红队和蓝队工作——漏洞发现与安全利用、恶意软件分析、安全运营以及智能体安全——而非仅限 CTF 或利用任务，并且每个任务都由一个确定性的逐任务 scoring.py 在五层反作弊机制之后进行评分，全程不涉及任何大语言模型评判器。其白盒发现任务锚定于广泛部署的上游项目中的真实历史 CVE，重建为经过改写、沙箱化的环境，并使其远离公开训练语料库以增强抗污染能力。

该套件新增的内容。其广度与框架定位使其区别于其他套件，而非引入新的任务类型。代码套件将仓库级任务与五种请求者角色及一个包含18个类别的分类体系相结合，针对的是口语化请求而非已提交的issue提示词，并通过在发布前保留新编写的任务目录，从构造上抵御可搜索提示词与答案泄露的污染。网络套件将上述任务类型、生命周期模式、交互/状态及评判维度统一于一个体系，结合规则检查、LLM/VLM评判，以及对运行中前端产物的智能体评判验证。办公套件将混合格式、多产物的工作流视为完整交接，通过分别保留的规则通道与评判通道，衡量机器可检查的工作区状态及语义层面的交付物质量。安全套件在完全确定性的逐任务评分下覆盖红队与蓝队全谱系，而该领域公开基准仍十分稀缺。对可搜索提示词及泄露测试或答案的抵御，依赖于发布前保留的新编写任务目录及构造性设计；基于分布信息的构造则依赖于分布匹配的任务，并以完全开放的形式发布——任务目录、环境镜像、评估代码、评分测试及参考答案全部公开——因此在封闭供应商无法做到的情况下，可被完整独立审计。这些仍是该基准自身设计阶段的定位声明，而非对所比较套件间智能体性能的实测对比。

7 局限性与结论

本节讨论本报告所述腾讯WorkBuddy Bench当前的局限性，以及为应对这些局限而规划的近期待办工作。

• 排行榜中有一个单元格使用了修改后的指令设置。全部七个模型均在两套测试框架下、于全部四个赛道中接受评分。唯一一个可比性注意事项是Claude Opus 4.8在Claude Code下的代码赛道得分：如表6所述，在禁用AskUserQuestion工具的基础上，该次运行额外添加了“不得提问、一次性完成”的显式指令，因此其设置与其他运行略有不同，其得分在报告时并列展示——但未并入第5节中的代码赛道框架切换汇总。

• 代码子集的单语言侧重。代码子集的开放发布以 Python 任务为主；跨语言覆盖仅限于少量将目标行为从 JavaScript、TypeScript 或 Rust 项目移植到 Python 的任务。本报告中关于编码难度、编码与数据/算法之间的差距以及测试框架差异的发现，在未经进一步评估的情况下，不应假定可推广到其他编程语言或生态系统。

• 开放发布带来发布后污染风险。腾讯 WorkBuddy Bench 完全开放发布——任务目录、环境镜像、评估代码、评分测试和参考答案全部公开，以便外部读者可以独立重新运行并审计单个任务的结果，而不仅仅是复现本报告前面描述的流程。这种开放性的代价是，已发布的任务内容从发布那一刻起就面临被爬取进未来模型训练数据的风险，这可能会随着时间推移削弱抗污染能力。数据集版本管理可以缓解但无法消除这一问题——未来的修订版可以淘汰或替换出现污染迹象的任务——而不是通过扣留任务内容来解决。

• 基于评判器的组件带有模型评判器偏差。Web 评分将基于规则的检查与 LLM/VLM 及智能体评判器的评分项相结合，依据是运行中的前端产物所生成的证据；Office 评分将确定性规则检查与基于固定任务后证据的 LLM 评判器相结合；Code 评分则额外计算一个跨多个维度的加权 LLM 评判器诊断分数，该分数不计入核心指标。Office 评分独立保留规则检查结果，因此评判器无法更改这些结果，但其语义评分项分数仍受模型评判器偏差影响。更广泛地说，模型评判器可能偏好它们熟悉或易于理解的回答风格，而不管任务正确性如何——这一风险本报告尚未单独量化。

• 分数与特定的服务端和测试框架条件相关。本次评估中使用的 HY（混元）端点是其提供商第一方提供的，而所有其他模型则通过第三方服务端点访问，后者的参数配置和请求处理方式可能会影响指标。同样，结果也与本次评估中使用的两个测试框架的特定版本相关，随着框架版本的演进，指标可能会发生变化（第 4 节）。

• Office 以文本优先。当前 Office 版本覆盖本地、混合格式的工作流，但不需要 OCR、视觉语言模型、像素级布局判断或原生桌面 GUI 交互。因此，Office 的结果适用于文件处理、状态更新和基于证据的工作流完成，而不适用于视觉感知或 GUI 操作。

近期工作聚焦于校准：继续 Web 评分标准校准，并在可行的情况下，将一种修改指令配置（Claude Code 下 Code 任务的 Claude Opus 4.8）纳入标准指令协议。

本报告描述了已发布的腾讯 WorkBuddy Bench：四个子集共享一种任务目录格式、一种准入协议和一种执行框架，以及其排行榜和上述限制。这些限制和范围边界是我们认为值得明确指出的内容，并非详尽无遗的列表。该套件完全开源发布——任务目录、环境镜像、评估代码、评分测试和参考解决方案均公开，可供第三方离线测试和审计——本版本之后的近期规划是推出一个公开排行榜，在两个框架上不断扩大模型覆盖范围。

贡献者

蔡思琪1*、陈少鹏4*、费翔1*、毛勇1*、徐子涵1*、吕志恒3*、邵志坚2*、石雨辰1、张淑文1、邱超凡1、车林杰3、赵晓曦3、吴峰3、张凯3、朱超凡3、齐玉斌3、梁晓云3、董培杰3、张云浩3、朱远杰、蒋玲2、张贤俊2、储哲航2、桑安远2、冯震2、聂森2、吴石2、徐远珍4、李鑫4、杨宁4、董志强4、董涵德3、林强3、刘毅3、吴云生1、李可1†、孙星1

1Youtu Lab 2Keen Security Lab 3Workbuddy 4Yunding Security Lab$\cdot$$\cdot$$\cdot$

*这些作者对本文贡献相同。作者顺序按字母顺序排列。†项目负责人。

参考文献

• Jimenez 等人 [2024] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, 和 Karthik Narasimhan. SWE-bench：语言模型能否解决真实的 GitHub 问题？发表于国际学习表征会议（ICLR），2024年。URL：https://arxiv.org/abs/2310.06770。
• OpenAI [2024] OpenAI. 推出 SWE-bench verified。OpenAI 博客，2024年。URL：https://openai.com/index/introducing-swe-bench-verified/。
• Si 等人 [2024] Chenglei Si, Yanzhe Zhang, Zhengyuan Yang, Ruibo Liu, 和 Diyi Yang. Design2code：我们距离自动化前端工程还有多远？发表于计算语言学协会会议（ACL），2024年。URL：https://arxiv.org/abs/2403.03163。
• Zhou 等人 [2024] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, 和 Graham Neubig. WebArena：用于构建自主智能体的真实网络环境。发表于国际学习表征会议（ICLR），2024年。URL：https://arxiv.org/abs/2307.13854。
• Cursor [2026] Cursor. 我们如何在 Cursor 中比较模型质量。Cursor 博客，2026年。URL：https://cursor.com/blog/cursorbench。
• Harbor 框架团队 [2026] Harbor 框架团队. Harbor：一个用于在容器环境中评估和优化智能体与模型的框架。GitHub 仓库，Laude Institute，2026年。URL：https://github.com/laude-institute/harbor。DOI：10.5281/zenodo.20953922。
• Zhao 等人 [2024] Wenting Zhao, Nan Jiang, Celine Lee, Justin T. Chiu, Claire Cardie, Matthias Gallé, 和 Alexander M. Rush. Commit0：从零开始生成库，2024年。URL：https://arxiv.org/abs/2412.01769。
• Jain 等人 [2024] Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, 和 Ion Stoica. LiveCodeBench：对代码大语言模型的全面且无污染评估，2024年。URL：https://arxiv.org/abs/2403.07974。
• Liu 等人 [2024] Tianyang Liu、Canwen Xu 和 Julian J. McAuley。RepoBench：对仓库级代码自动补全系统进行基准评测。发表于国际学习表征会议（ICLR），2024 年。URL：https://arxiv.org/abs/2306.03091。
• Gauthier [2024] Paul Gauthier。Aider polyglot 基准。Aider 文档，2024 年。URL：https://aider.chat/docs/leaderboards/。
• Terminal-Bench 团队 [2024] Terminal-Bench 团队。Terminal-bench：面向终端环境中 AI 智能体的基准评测。项目网站，2024 年。URL：https://www.tbench.ai/。
• Tran 等人 [2026] Hung Tran、Langston Nashold、Rayan Krishnan、Antoine Bigeard 和 Alex Gu。Vibe Code Bench：评估 AI 模型在端到端 Web 应用开发中的表现。发表于 ACM 人工智能与智能体系统会议（ACM CAIS），2026 年。doi：10.1145/3786335.3813180。URL：https://arxiv.org/abs/2603.04601。
• Xiao 等人 [2024] Jingyu Xiao、Yuxuan Wan、Yintong Huo、Zixin Wang、Xinyi Xu、Wenxuan Wang、Zhiyao Xu、Yuhang Wang 和 Michael R. Lyu。Interaction2Code：基于交互式原型对多模态大语言模型驱动的交互式网页代码生成进行基准评测，2024 年。URL：https://arxiv.org/abs/2411.03292。
• Zhu 等人 [2025a] Hongda Zhu、Yiwen Zhang、Bing Zhao、Jingzhe Ding、Siyao Liu、Tong Liu、Dandan Wang、Yanan Liu 和 Zhaojian Li。FrontendBench：通过自动评估对大语言模型在前端开发中的表现进行基准评测，2025a。URL：https://arxiv.org/abs/2506.13832。
• Koh 等人 [2024] Jing Yu Koh、Robert Lo、Lawrence Jang、Vikram Duvvur、Ming Chong Lim、Po-Yu Huang、Graham Neubig、Shuyan Zhou、Ruslan Salakhutdinov 和 Daniel Fried。VisualWebArena：在真实视觉网页任务上评估多模态智能体。发表于计算语言学协会会议（ACL），2024 年。URL：https://arxiv.org/abs/2401.13649。
• Tang 等人 [2026] Zirui Tang、Xuanhe Zhou、Yumou Liu、Linchun Li、Yukai Wu、Weizheng Wang、Hongzhang Huang、Wei Zhou、Jun Zhou、Jiachen Song、Shaoli Yu、Jinqi Wang、Zihang Zhou、Hongyi Zhou、Yuting Lv、Jinyang Li、Jiashuo Liu、Ruoyu Chen、Chunwei Liu、GuoLiang Li、Jihua Kang 和 Fan Wu。Workspace-Bench 1.0：在具有大规模文件依赖关系的工作区任务上对 AI 智能体进行基准评测，2026 年。URL：https://arxiv.org/abs/2605.03596。
• Li 等人 [2026] Xiangyi Li, Kyoung Whan Choe, Yimin Liu, Xiaokun Chen, Chujun Tao, Bingran You, Wenbo Chen, Zonglin Di, Jiankai Sun, Shenghan Zheng, Jiajun Bao, Yuanli Wang, Weixiang Yan, Yiyuan Li 和 Han-chung Lee。ClawsBench：在模拟工作空间中评估 LLM 生产力智能体的能力与安全性，2026 年。URL https://arxiv.org/abs/2604.05172。
• Wang 等人 [2025] Weixuan Wang, Dongge Han, Daniel Madrigal Diaz, Jin Xu, Victor Rühle 和 Saravan Rajmohan。OdysseyBench：在长周期复杂办公应用工作流上评估 LLM 智能体，2025 年。URL https://arxiv.org/abs/2508.09124。
• Zhu 等人 [2026] Jian Zhu, Yuzheng Zhang, Zeyao Ma, Bohan Zhang, Armin Schoepf, Daniel Woloch, Peter Yiliu Wang, Guangyu Robert Yang, Samuel Jacob, Siddharth Nagisetty, Abhiram Chundru, Jean Lin, Spencer Mateega 和 Jing Zhang。SpreadsheetBench 2：在端到端业务电子表格工作流上评估智能体，2026 年。URL https://arxiv.org/abs/2606.29955。
• Zhang 等人 [2025] Andy K. Zhang, Neil Perry, Riya Dulepet, Joey Ji, Celeste Menders, Justin W. Lin, Eliot Jones, Gashon Hussein, Samantha Liu, Donovan Jasper 等人。Cybench：评估语言模型网络安全能力与风险的框架。发表于国际学习表征会议（ICLR），2025 年。URL https://arxiv.org/abs/2408.08926。
• Shao 等人 [2024] Minghao Shao, Sofija Jancheska, Meet Udeshi, Brendan Dolan-Gavitt, Haoran Xi, Kimberly Milner, Boyuan Chen, Max Yin, Siddharth Garg, Prashanth Krishnamurthy, Farshad Khorrami, Ramesh Karri 和 Muhammad Shafique。NYU CTF Bench：用于评估 LLM 攻击性安全能力的可扩展开源基准数据集。发表于神经信息处理系统进展大会（NeurIPS），数据集与基准赛道，2024 年。URL https://arxiv.org/abs/2406.05590。
• Yang 等人 [2023] John Yang, Akshara Prabhakar, Karthik Narasimhan 和 Shunyu Yao。InterCode：利用执行反馈标准化并基准化交互式编码。发表于神经信息处理系统进展大会（NeurIPS），数据集与基准赛道，2023 年。URL https://arxiv.org/abs/2306.14898。
• Zhu 等人 [2025b] Yuxuan Zhu, Antony Kellermann, Dylan Bowman, Philip Li, Akul Gupta, Adarsh Danda, Richard Fang, Conner Jensen, Eric Ihli, Jason Benn, Jet Geronimo, Avi Dhir, Sudhit Rao, Kaicheng Yu, Twm Stone 和 Daniel Kang。CVE-Bench：用于评估 AI 智能体利用真实世界 Web 应用漏洞能力的基准测试。收录于《国际机器学习大会（ICML）》，2025b。URL https://arxiv.org/abs/2503.17332。
• Bhatt 等人 [2024] Manish Bhatt, Sahana Chennabasappa, Yue Li, Cyrus Nikolaidis, Daniel Song, Shengye Wan, Faizan Ahmad, Cornelius Aschermann, Yaohui Chen, Dhaval Kapil, David Molnar, Spencer Whitman 和 Joshua Saxe。CyberSecEval 2：面向大语言模型的广泛网络安全评估套件，2024。URL https://arxiv.org/abs/2404.13161。
• Wan 等人 [2024] Shengye Wan, Cyrus Nikolaidis, Daniel Song, David Molnar, James Crnkovich, Jayson Grace, Manish Bhatt, Sahana Chennabasappa, Spencer Whitman, Stephanie Ding, Vlad Ionescu, Yue Li 和 Joshua Saxe。CyberSecEval 3：推进大语言模型网络安全风险与能力的评估，2024。URL https://arxiv.org/abs/2408.01605。