摘要
本文介绍了腾讯 WorkBuddy Bench，一个面向编码智能体的多领域评估套件；本报告记录了其构建方法、评分协议以及跨模型排行榜。其核心是一个统一的评估框架，用于在四个工作领域——代码、网页、办公和安全——构建并运行基于分布信息的编码智能体任务。每个任务并非改编自公开的问题文本，而是从真实的代码提交、拉取请求或业务场景中逆向工程而来，并重写为简短、口语化、角色扮演式的请求，因此任务的提示词无法通过联网搜索底层的问题、拉取请求或提交线索来获取。由于数据集是公开发布的——包含任务目录、环境镜像、评估工具、测试用例和参考解决方案——其抗污染能力依赖于这种构建方式以及数据集版本管理，而非保密性。四个子集——仓库级工程、前端开发、办公与业务流程、红蓝队安全——分别探究实际工作中互补的方面，每个子集都有其独特的验证方式。所有子集都采用统一的任务目录格式打包，并在统一且可复现的协议下，在两个智能体框架（CodeBuddy Code 和 Claude Code）上运行；完整的开放发布使得该基准测试端到端可复现且可直接审计，因为任何第三方都可以重新运行每个任务并检查其内容。由于每个子集使用不同的评分工具，分数在子集之间不具有可比性，因此该套件不报告跨套件的平均分。我们报告了涵盖多个模型系列的跨模型排行榜。
1 引言
当前对编码智能体的评估主要依据两类截然不同的基准，每类基准各有其权衡取舍。静态公开套件（如 SWE-bench 和 SWE-bench Verified [1, 2]）在发布时便固定了任务集：其问题描述乃至解决方案通常会在网络上公开流传，因此不断攀升的分数可能反映的是对特定问题讨论串或拉取请求的记忆，而非真正的仓库级推理能力；此外，这类基准的覆盖范围十分狭窄——绝大多数仅针对单一问题的缺陷修复。同样的可爬取性问题也存在于代码领域之外：前端生成 [3] 和网页智能体 [4] 的基准均依赖于可被爬取的公共仓库、截图及网站。厂商生产环境基准（如 CursorBench [5]）则采取相反策略，从真实生产会话中抽取任务，使任务分布能够反映智能体的实际使用方式——但这类基准本身是封闭的：外部方无法审查其任务分布、排除对厂商自身智能体的选择偏差，也无法确认其任务组合能否推广至该厂商用户群体之外。因此，评估旨在实际组织内部运行的智能体，需要一套具备以下特征的套件：其任务分布源于真实工作场景；能够从根本上抵御最关键的污染路径——即可通过网络搜索获取的提示词——而非仅依赖发布时的新颖性；并且以足够开放的方式发布，使外部方能够重新运行每个任务并直接审查其内容。
我们推出腾讯工作伙伴基准（Tencent WorkBuddy Bench），这是一个面向编码智能体的多领域评估套件；本报告记录了其构建方法、评分协议以及跨模型排行榜。其核心是一个统一的评估框架，用于在四个工作领域——代码、网页、办公和安全（图1）——构建并运行基于分布信息的编码智能体任务，并在两个智能体框架（CodeBuddy Code 和 Claude Code）上，按照共享且可复现的协议进行评估。代码领域针对仓库级软件工程：在角色扮演的、口语化的需求下，在真实开源代码库中定位、修改并验证变更。网页领域针对前端制品，涵盖生成、修改、分析和质量保证，从页面实现和数据可视化到有状态交互、测试、报告和文档转换。办公领域针对涉及多个文件和交付物的业务流程。智能体必须读取混合格式的本地文件，跨交付物传递信息，更新工作区状态，并留下可供他人使用的结果。其评估目标是最终可验证的工作区状态：交付物、文件结构、状态变更、证据以及任务特定的执行边界。安全领域涵盖安全团队的各个范畴——漏洞发现与安全复现、恶意软件分析、安全运营以及智能体安全评估——而非编写修复方案。所有四个子集共享相同的任务目录格式、相同的准入协议以及相同的执行基础设施。它们不共享的是评分工具：代码领域使用隐藏测试——“隐藏”意味着在智能体解题时对其保密，而非对公众隐藏，因为完整的测试套件会随公开版本一同发布；网页领域使用带有规则检查的评分标准，用于确定性约束，使用大语言模型/视觉语言模型评判器评估文本、结构和视觉语义，并使用智能体评判器检查交互状态和工作流；办公领域使用任务特定的确定性规则检查与基于证据的大语言模型评判器评估的语义评分标准相结合的混合方式；安全领域则使用确定性评分器。因此，各子集之间的分数不可比较，该套件不报告全套件平均分——这是一个刻意的设计事实，而非需要填补的空白。统一之处在于构建和框架层面，该基准已公开发布且可直接审计：协议、任务格式、任务目录、环境镜像、评估框架、测试用例和参考解决方案均为公开，因此任何第三方都可以重新运行每个任务并检查其内容。
为何这四个领域应归入同一套件。一个被置于真实组织工作中的编程智能体不再仅仅编辑代码：同一个智能体还需构建网页前端、生成或核对办公文档，以及分析安全制品。代码、网页、办公和安全，正是这项工作所跨越的四种制品与工作流边界，而该套件将它们视为一体，因为在每一处边界上，任务形态完全相同——智能体被投入一个工作空间，根据自然语言请求生成制品，并由一个它从未见过的验证器进行评分。这种共同的形态，而非共同的评分规则，才是使这四个子集构成同一套件的原因。
对最关键的污染路径——可通过网络搜索获取的提示词——的抵御，是一项首要的设计约束，而非事后才考虑的问题。任务并非公开议题标题或教程练习的复制品：每个任务都是从真实的代码提交、拉取请求或业务场景中逆向工程而来，并被重写为一段简短、口语化、角色扮演式的请求，其指令隐去了根本原因、参考差异以及任何会让智能体直接获得解决方案的框架，因此，通过搜索底层议题或拉取请求线程无法在网络上找到该任务的提示词。由于数据集是公开发布的，这种构建层面的抵御能力依赖于数据集版本管理而非保密性；第2节详细阐述了该机制，并诚实地界定了其能抵御和不能抵御的范围。
任务分布基于对真实使用情况的分析，而非对真实使用数据的复用。每个子集的类别、任务模式与难度组合，均与内部使用分类法——查询意图类别与请求结构模式——进行匹配，因此，例如，代码子集的80个任务涵盖了五种请求者角色以及远超错误修复范畴的任务类型（第3节）。被分析和匹配的是真实请求的分布，而非请求本身：没有任何原始用户提示词、会话或用户数据被复用或暴露在已发布的任务中。这也使得该套件能够完整发布并接受公开审计，而基于原始会话的基准测试则面临隐私限制，从而限制了其披露范围。
贡献。本报告做出四项贡献。1) 我们推出了腾讯工作伙伴基准测试（Tencent WorkBuddy Bench），这是一套包含四个并行子集——代码、网页、办公和安全——的测试套件，用于在统一的可复现框架下评估编码智能体在仓库级软件工程、前端网页开发、办公与业务工作流以及安全团队工作流方面的表现。2) 我们采用一种基于分布信息的方法构建任务，该方法能够抵御提示词污染：每个任务都是从真实的代码提交、拉取请求或业务场景中逆向工程而来，与内部使用分类相匹配，并改写为口语化、角色扮演式的自然语言需求，而非从公开的问题文本中复制或从用户会话中提取。3) 我们开发了一种超越通过/失败单元测试的评估方法。每个被接纳的任务都需通过基线/基准准入关卡（基线奖励，基准奖励），确认未修改的工作空间本身无法通过，且至少有一个参考解决方案能达到完整的验证器奖励；前端产物通过规则检查（针对确定性约束）、大语言模型/视觉语言模型评判（针对文本、结构和视觉语义）以及一个驱动运行中产物以检查交互流程和状态的智能体评判来进行评分。对于办公子集，确定性规则检查会验证文件、结构、值、状态和执行边界，同时一个大语言模型评判会利用任务结束后提取的固定证据来评估二元语义评分标准。这两个分数分别报告，并使用每个任务预先配置的权重进行合并。4) 我们报告了一个跨模型排行榜，涵盖多个模型家族，并在两个评估框架（CodeBuddy Code 和 Claude Code）下进行。
简而言之，本报告提供了三方面内容：该套件的设计、每个子集当前的任务集构成，以及跨模型排行榜。表 1 总结了这四个子集。
| 子集 | 领域 | 规模 | 指标 |
|---|---|---|---|
| 代码 | 仓库级软件工程 | 80 个任务 | 每次运行的隐藏测试分数 |
| 网页 | 前端 / 图形用户界面 | 70 个任务 | 评分标准评分（规则 / 大语言模型-视觉语言模型 / 智能体） |
| 办公 | 办公数据与文件工作流 | 50 项任务 | 任务特定的规则/裁判混合机制 |
| 安全 | 红蓝队安全测试 | 60 项任务 | 程序化评分脚本（无大模型裁判） |
报告其余部分组织如下。第 6 节首先将该评测套件与现有公开及厂商自研的代码和网页领域智能体基准进行定位比较。第 2 节随后描述该套件的共享设计原则、任务格式和执行模型，接着是详细说明四个子集、评估框架与评分方法、结果及局限性的各个章节。
2 任务构建
本节阐述腾讯 WorkBuddy Bench 的套件级构建协议。在所有四个子集（代码、网页、办公和安全）中，任务遵循相同的总体阶段：来源收集、改写为真实请求、组装智能体可见的工作空间、在任务回合结束前隔离评估资产，以及将每个任务打包为独立的目录。用户数据在整个构建过程中均不涉及。评分工具及任何子集特定的准入检查并不统一：代码使用隐藏测试，网页使用规则、大语言模型/视觉语言模型和智能体裁判评分标准，办公使用确定性规则检查与基于证据的大语言模型裁判评分标准相结合的任务特定混合机制，安全则使用确定性的评分脚本。由于这些工具不同，各子集之间的分数不可比较，且该套件不报告套件级平均值；这是一个刻意的设计决策，而非需要纠正的局限。本节涵盖构建与打包；执行和每个轨道的评分将在第 4 节中统一说明。
任务来源。
每项任务都锚定于两类具体来源之一：真实的上游工件——即开源仓库中的历史提交或拉取请求（代码类），或真实的历史 CVE（安全类的白盒审计任务）——以及具体的业务场景（网页、办公，以及代码和安全类的合成任务族）。哪些场景值得构建、以何种比例构建，是根据内部使用分类法来决定的：每个子集的类别组合、任务模式、角色和难度，都与真实请求的分布相匹配，但绝不直接使用请求本身。没有任何原始用户提示词、会话或其他用户数据进入任何任务；构建过程仅依据聚合分布信息。在业务场景分支中，办公类采用两种构建路径：从任务规格说明和目标能力重建的任务，以及从抽象化的办公工作流扩展而来的任务。两者都被打包为独立的工区，其中仅包含可公开共享的输入，并通过相同的工区完整性、评估资产、校准和发布就绪检查。
重写协议。
任务并非以整洁的问题标题或教科书式习题的形式编写。当任务源自真实的上游工件时，其原始上下文会被逆向工程并重写为简短、口语化、信息不充分的自然语言请求；当任务基于业务场景创作时，请求会直接以同样的口吻编写。无论哪种方式，请求读起来都像是来自同事或客户的合理提问——代码类还会通过五种请求者角色（开发者、算法工程师、产品经理、QA、运维）为每项任务赋予声音，安全类则为每个任务领域分配一个专业角色——并且指令会隐去根本原因、参考差异以及任何会让智能体直接获得解决方案的框架信息，因此智能体必须先定位工区中的相关表面，然后才能采取行动。这与那些提供详细、已诊断好的问题报告的基准测试形成鲜明对比。
刻意信息不充分。
在所有四个子集中，请求的撰写方式都如同同事实际提问——包含意图和约束条件，而非一份技术规格说明——并且刻意留出信息不足的空间：它们通常会省略目标文件或模块、精确的模式或接口、边界情况处理，以及变更的确切范围。填补这些空白本身就是任务的一部分：智能体必须从工作区（代码仓库、数据夹具、现有代码或接口）中恢复缺失的上下文，并承诺一个合理的隐含假设，而非被动接受现成答案。这是有意为之，而非疏忽：它既测试代码合成能力，也测试需求消歧与落地能力，这正是真实工作请求与整洁问题标题之间的区别。奖励根据特定任务的检查项、评分细则或评估流程计算，而非通过匹配某个参考实现或表述方式。这些评估工具编码了预期的契约，因此一个看似合理但违反契约的输出仍可能失败。智能体的评判标准是是否满足该契约，而非是否还原了某个被认可的特定实现。
回合后评估隔离。
在整个回合中，智能体可以看到任务指令和声明的工作区，但看不到评分资产。只有在智能体完成操作后，特定任务的检查项、评分细则或评估流程才会被引入沙箱，或由评估流水线调用。“隐藏”或“保留”因此描述的是求解时的可见性，而非发布后的保密性：评估资产与数据集的其他部分一起公开。它们的形式因子集而异——代码子集采用隐藏测试，网页子集采用评分细则评估器，办公套件子集采用规则-裁判评估，安全子集采用确定性评分器——而共同属性是操作与评分之间的时间界限。代码子集的诊断性黄金补丁和预言机门控准入机制在第3节代码子集部分有详细描述。
任务目录格式。
任务采用基于Harbor [6]风格的任务目录约定进行打包，与标准Harbor布局相比有一个小改动：将智能体可见的工作区与回合后评估资产分离开来。
`instruction.md` 文件承载了上述自然语言请求。`task.toml` 文件在版本化架构下承载任务元数据——包括类别、难度、标签、资源限制以及按角色划分的超时时间。`environment/` 定义了沙箱环境：一个仅复制 `workspace/` 目录且不包含其他内容的 Dockerfile，使得智能体可见的范围恰好是待测试的代码仓库或业务制品。`tests/` 存放剧集结束后的评估资源：`test.sh` 是入口点，`grading/` 包含特定于任务的检查项或评估配置。可选的 `gold.patch` 是代码专用的诊断参考；其在代码预言机门控准入中的作用将在第 3 节中描述。由于 Dockerfile 仅构建可见的工作区，且 `tests/` 下的所有内容均保留在镜像之外，因此剧集结束后的评估边界是打包本身的一个属性，而非运行时配置。
执行。
打包后的任务如何执行——沙箱化容器的生命周期、模型连接性、测试框架后端以及每个轨道的评分规则——将在第 4 节中统一说明。
抗污染的任务构建。
抗污染能力首先源于任务构建方式。由于任务基于真实代码提交、CVE漏洞及业务场景构建，并改写为角色扮演式的自然语言请求，而非从公开问题陈述中复制，因此任何任务的指令文本都无法通过搜索底层问题、拉取请求或提交线程来获取：在任务编写完成的那一刻，可搜索提示词路径即被封闭，与任务发布的时间无关。由于数据集是公开发布的——包含任务目录、评分测试和参考解决方案——这种抗污染能力不能再依赖保密或隐藏评分答案。两个开放基准测试机制承担了剩余责任：数据集版本管理，即定期刷新并重新版本化该套件，使得已发布的快照在暴露积累到一定程度后可被取代；以及可选的警示字符串，用于检测后续对已发布数据集的训练爬取。剩余暴露风险也一并说明：模型可能已经见过原始的公开提交或拉取请求代码，或者——对于基于CVE的安全任务——见过对底层漏洞的公开漏洞分析；并且，与任何公开发布的基准测试（如SWE-bench）一样，公开任务集在发布后仍面临训练数据暴露的风险，版本管理可以缓解但无法消除这一风险。因此，这一主张是狭隘且诚实的：抗污染任务构建通过设计封闭了可搜索提示词路径，而开放发布的版本管理则随时间推移管理暴露风险——并非声称该套件完全无污染。
版本命名。
每个子集都带有一个内部版本标识符，由主索引号与日期戳组合而成，但主索引号的语义是子集特有的，而非统一按顺序排列，因此不同子集之间的版本号无法直接比较。
2.1 发布内容
该套件作为一个完全开放的、SWE-bench 风格的数据集发布：运行、评分和审计一项任务所需的一切都是公开的。上述构建协议、打包规范、任务目录、工作区/环境镜像、评估框架及其聚合代码、评分测试以及参考答案均已发布，因此任何第三方都可以重新运行单个任务并直接检查其内容——该基准测试完全可复现且可公开审计，而不仅仅是在已发布的协议层面可审计。表 2 列出了发布内容所包含的部分。唯一不包含的是用户数据，这是由于其本身不存在而非刻意隐瞒：在构建的任何阶段都没有使用任何原始用户提示词、会话或其他用户数据，因此没有任何数据可供发布。
| 组件 | 状态 |
|---|---|
| 任务目录框架和打包规范（本节） | 已发布 |
| 任务提示词和指令文本 | 已发布 |
| 用于离线第三方测试的工作区/环境镜像 | 已发布 |
| 评估框架和分数聚合代码 | 已发布 |
| 评分测试（在求解时对智能体隐藏的验证器） | 已发布 |
| 黄金补丁和参考答案 | 已发布 |
| 每项任务和聚合分数，以及公开排行榜 | 已发布 |
| 任何类型的用户数据 | 完全未使用——不存在任何数据可供发布 |
3 基准测试
腾讯工作助手基准测试（Tencent WorkBuddy Bench）由四个互补的子集组成——代码（Code）、网页（Web）、办公（Office）和安全（Security）——每个子集针对不同类别的现实智能体任务，同时共享通用的任务格式和评分理念。本节介绍代码子集；后续章节将依次介绍网页、办公和安全子集。
3.1 代码
代码子集衡量的是智能体能否针对一个完整的开源代码仓库执行真实的、角色扮演式的工程请求——而非单文件的玩具问题，也非预先诊断好的 bug 报告。智能体被放入一个在基线提交（baseline commit）处检出的项目中，必须跨模块定位相关代码、进行修改，并确保项目的隐藏测试全部通过。该子集的独特之处在于其角色和任务类型的多样性：每个任务都由五种请求者角色之一提出——开发者、算法工程师、产品经理、质量保证和运维——且涵盖的范围远不止 bug 修复工作（见表 4、图 2(a)）。
任务来源。
每个任务将其目标变更表达为自然语言的、角色扮演式的请求，因此解决它需要阅读并推理代码仓库本身。在 80 个任务中，有 34 个锚定于针对真实开源软件快照的真实上游提交（A 族）；其余 46 个没有上游代码，并按内部大致比例分为：洁净室重新实现（B 族，24 个任务，包括将 JavaScript/TypeScript/Rust 目标移植到 Python 的 4 个任务）和完全合成的工作空间（C 族，22 个任务），如表 3 所示。已发布的仓库数量会因是否包含洁净室和移植目标而有所不同，因此我们不报告汇总计数。
| 族 | 定义 | 计数 | 示例 |
|---|---|---|---|
| A | 上游提交处的真实开源软件快照；金标准补丁是实际的人工修复 | 34 | Django、Flask、pytest、Black、Pydantic、httpx、Celery（18 个仓库） |
| B | 目标库公共 API 的洁净室式 *_like 重新实现，未复制任何原始代码；包括 4 个跨语言移植（JS/TS/Rust 原版用 Python 实现） | 24 | fastapi_like/openapi.py 存根，而非 FastAPI 本身 |
| C | 完全合成的工作空间，包含 CSV/JSON 测试数据，旨在直接演练某个角色的工作流程 | 22 | 算法工作空间（12 个）和产品经理数据工作空间（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 是用于此验证的诊断性参考，并非唯一正确解法；任何能通过隐藏测试的补丁都将获得相应奖励。
| 维度 | 细分 |
|---|---|
| 角色 | 开发者 30 算法 19 产品经理 15 运维 10 质量保证 6 |
| 难度（编辑评定） | 简单 7 中等 31 困难 42 |
| 难度（L 阶梯） | L2 4 L3 27 L4 40 L5 9（以 L4 为中心） |
| 准入门槛 | 基线 0.3，oracle（gold.patch）1.0（针对隐藏测试） |
领域与难度。
任务涵盖 18 个细粒度类别，为便于阅读合并为六个使用领域（图 2(a)）。80 个任务中仅 10 个涉及缺陷修复；其余五个领域——功能与接口工作、代码工程、测试、算法工程以及产品/数据分析——承担了剩余的 70 个任务，这是对早期基准测试中“修复缺陷、添加功能”框架的有意扩展。难度主要来自跨模块探索——即确定在何处修改而非如何修改——并随着任务在 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 任务都使用两个评分组件：确定性规则检查和一个基于证据的大语言模型评判器。规则检查是对可精确评估的客观要求进行的二元测试，例如所需文件、模式、数值、源关系、状态转换、副作用和执行约束。每个语义评分标准定义一个二元质量条件，评判器根据任务结束后生成的固定证据（包括提交的交付物以及特定任务的状态或源摘要）来评估该条件。评判器不会检查实时工作空间，也不会更改已记录的规则检查结果。所有 50 个任务都使用这两个组件。对于选定的任务，状态差异（10 个任务）、受控环境（6 个任务）、执行轨迹（5 个任务）或运行时边界（3 个任务）为规则检查或语义评分标准提供证据；它们并非额外的评分渠道。第 4 节定义了每个任务如何组合规则分和评判器分、如何汇总试验结果，以及如何处理不可用的评判器结果。图 7 总结了评估流程。
3.4 安全
安全子集涵盖了安全团队的全频谱——红队发现与安全利用、恶意软件分析、安全运营以及智能体安全评估——它提出的问题比代码子集中的漏洞修复任务更为尖锐：智能体能否像安全研究员那样，在沙盒环境中定位真实漏洞并安全复现；能否像恶意软件分析师或安全运营中心操作员那样，分析恶意软件制品或对告警流进行分类；能否像AI红队成员那样，对使用工具的智能体进行探测。给定一个任务，智能体必须依次完成每一步，且不会预先获知漏洞位置或预期行为，每个任务都在沙盒化的评估环境中运行。该子集与套件中其他部分的不同之处在于，它完全不使用大语言模型评判器：每个任务都附带一个确定性评分程序，该程序直接将智能体输出转换为数值奖励，并由五层反作弊基础设施提供支持，以阻断硬编码和枚举行为。
安全子集包含60个任务，涵盖六个细粒度领域，这些领域整合为四个模块，横跨红队和蓝队两个专业方向（表5，图8）。按专业方向分组，该套件以红队为主——38个红队任务对22个蓝队任务——但仍覆盖了完整的防御/检测循环，且难度在设计中刻意偏向困难，这反映了真实安全工作的平衡，即困难案例多于简单案例。
| 模块 | 角色 | 任务数 | 专业方向 |
|---|---|---|---|
| 漏洞发现与利用 | 安全研究员 | 32 | 红队 |
| 恶意软件分析 | 反病毒工程师 | 14 | 蓝队 |
| 安全运营 | 安全运营中心分析师/检测工程师 | 8 | 蓝队 |
| 智能体安全 | AI红队 | 6 | 红队 |
难度在设计中刻意偏向困难。
每个任务的确定性评分器均在隔离的 Docker 容器内执行，并直接写入数值奖励，因此同一输出被重复评分两次将返回相同数值（图 8，右图）。第 4 节给出了各评分器的定义——PoC 与 flag 验证、IOC 匹配、零误报约束下的 YARA 匹配率，以及基于 macro-F1/Kendall-tau 的报告评分。
发现与利用模块涵盖白盒源码审计、黑盒二进制利用及 Web 利用三类任务。白盒审计任务复现了广泛部署的上游项目（binutils、curl、nginx、vim、jq 和 fluent-bit）中真实的历史 CVE，采用"发现漏洞-定位验证-确认利用"的两步结构，其中第二步的执行以第一步的通过为前提。以针对 binutils 的典型任务为例：第一步仅向智能体提供源码树，要求其阅读解析器、追踪数据流并定位漏洞代码路径，系统根据阈值评分后才会解锁第二步环境；此时智能体方可提交概念验证输入，该输入必须能在沙箱容器内稳定触发 ASAN 崩溃才算通过——这种节奏设计旨在模拟真实的"审计后利用"场景，而非直接告知缺陷位置。Web 利用任务围绕特定命名技术（如 Apple2 家族攻击和 ECDSA nonce 重用）构建，而非泛化的漏洞类别。六项智能体安全任务则针对使用工具的 AI 智能体特有攻击面进行探测——包括智能体间提示注入、ReAct 链劫持、多模态提示链注入、工具模式混淆、通过摘要工具的数据窃取以及延迟触发攻击——每项任务都要求智能体返回结构化发现报告并附上 CVSS 严重等级评分，模拟安全团队在智能体上线前安全审查中期望交付的成果。
反作弊机制。
为确保在完全自动化、无人工评判的验证条件下评分具有实际意义，每项任务都部署了五层反作弊基础设施，从输入、代码和输出三个维度阻断硬编码与枚举攻击：
- •
针对硬编码答案的禁用字面量扫描。
- •
重命名输入测试，检验提取器是否解析结构而非依赖文件名。
- •
针对尾部数据篡改的覆盖/篡改测试。
- •
编码依赖测试，要求检测规则锚定字节而非明文。
- •
低权重诱饵字段，抑制通过盲目枚举获取奖励。
与其他子集类似，安全子集在思考模式下同时使用 CodeBuddy Code 和 Claude Code 两种评测框架进行评分，取三次运行的平均值；结果见第 5 节。
4 评测框架与评分
一个基准测试的数值，其可信度完全取决于生成这些数值的机制。腾讯 WorkBuddy Bench 将这一机制视为首要贡献，而非实现细节：每项任务，无论属于哪个赛道，都作为一个独立的任务目录发布，并在共享框架下的沙箱化容器中执行；该基准测试完全开源——任务目录、环境镜像、评测代码、评分测试以及参考答案/标准解决方案均公开。外部人员无需特殊权限访问基准测试的内部基础设施，也无需为每个子集定制评测路径：仅凭公开发布的内容，即可复现分数，并对任何单个任务进行直接重新运行和审计。本节将描述该框架、智能体如何与被评测的模型连接，以及每个赛道适用的评分规则；上述各子集章节将评分细节统一归入此处说明。
沙箱化执行与模型连接。
每次试验都在一个隔离容器内运行任务环境；智能体只能看到任务声明的工区，而任务特定的评估资源只有在智能体完成行动后才会被引入沙箱或由评估流水线调用，因此评分过程绝不会泄露到智能体的上下文中。模型与沙箱的关注点被刻意分离：测试框架既可以直接访问模型后端，也可以通过执行协议转换、模型名称重写和请求日志记录的本地代理来访问，同时它既可以在本地机器上执行沙箱，也可以在远程隔离的沙箱后端上执行。当沙箱远程运行时，基准测试端不会在沙箱内部放置任何代理——原本应由代理处理的任何协议处理工作都留给模型服务自身完成——而无法满足这种分离要求的沙箱后端与连接模式的组合会被直接禁用，不会静默回退到其他路径。为完整起见，此处披露一种访问不对称性：本次评估中使用的 HY（混元）端点由其提供商以第一方方式提供服务，而所有其他模型均通过第三方服务端点访问；第三方的参数配置和请求处理方式可能会影响指标。
测试框架后端。
默认执行框架是 CodeBuddy Code；Claude Code 作为直接使用 Anthropic 协议的替代方案，在模型自身协议允许的情况下均可使用。所有四个赛道均在两种框架下并行运行并报告结果（双框架报告），因为相对排名可能在两者之间发生变化——在一个框架下领先的模型未必在另一个框架下同样领先（第 5 节）。推理模式（思考 vs. 不思考）是框架为每个模型记录的另一个配置维度，与下文所述的采样超参数并列；第 5 节的排行榜全程报告的是思考模式配置。在两种框架下，协议将推理努力度固定为高，将上下文窗口统一为 20 万 token 并设置通用的自动压缩阈值，同时禁用 WebSearch 和 AskUserQuestion 工具；除此之外，每个模型均使用其供应商默认的推理超参数运行，如下文所记录。报告的结果与本次评估中使用的两个框架的具体构建版本绑定，指标可能随框架版本演变而变化。
评分形式。
赛道任务集中的每个任务都会产生一个验证器奖励，而模型的赛道得分是未加权平均值
| (1) |
在多次独立运行中取平均，当赛道得分超过一次时。每个任务的奖励因赛道而异。对于代码赛道，奖励是智能体补丁的隐藏测试通过率。对于网页赛道，奖励根据任务特定的一组评分细则项计算：每个项目返回通过/失败；设 为失败的非致命项集合，每项带有惩罚 ；任何致命失败都将任务奖励设为零：
| (2) |
对于办公赛道，任务奖励是确定性规则得分和基于证据的裁判得分的任务特定混合，定义如下；对于安全赛道，每个任务的确定性评分器结合了三个程序化项（图 8），在三次运行中取平均。
各赛道评分。
每个任务都以相同方式打包和执行，但从中计算出的奖励是赛道特定的：
- •
代码——由 Harbor 测试框架 [6] 计算的运行级得分：每个任务隐藏测试分数的每次运行平均值，这是本报告中代码类别的核心指标。验证器采用三种形式之一——pytest 注入的测试套件（80 个任务中的 22 个）、无需 pytest 或网络访问的功能性布尔断言（80 个任务中的 54 个），或用于代码库理解任务的 JSON 报告评分器（80 个任务中的 4 个）；黄金补丁仅用于诊断，任何满足条件的补丁均可获得满分。任务级的单元测试通过率和 LLM 评判分数仅作为参考值记录。
- •
网页——对 786 个评分项进行评分表打分。规则检查涵盖 62 个确定性交付和预检查项；LLM/VLM 评判器覆盖 676 个涉及文本、代码、结构化内容、DOM 摘要、截图和视觉证据的项；智能体评判器覆盖 48 个需要操作运行中工件（如工作流完成、状态变更、持久化和跨状态一致性）的项。失败项会扣除配置的罚分，而致命失败则将任务奖励设为零。每个任务仍必须在声明的输出路径交付可运行的工件，且不得访问实时互联网、外部账户或密钥。
- •
办公——两个独立保留的评分通道，每个通道由二元检查组成。确定性规则检查验证文件中的客观事实、结构、数值、跨文件关系、状态变更、副作用和执行边界。每个语义评分表指定一个由 LLM 评判器在任务结束后评估的、基于证据的二元质量条件。评判器接收公开的任务指令、完整的规则检查结果，以及仅由被评估评分表指定的固定证据；它不检查实时工作空间，也不修改已记录的规则检查结果。每个任务预先配置两个通道分数的组合方式。
- •
安全——隐藏测试验证，无需大语言模型裁判：每个任务附带一个 scoring.py，在隔离容器中运行，直接输出一个数值奖励——利用类任务验证概念验证或捕获的旗标，恶意软件分析类任务将入侵指标与真实情况进行比对，YARA 规则类任务在零误报约束下检查匹配率，而安全运营中心报告类任务则通过与参考报告对比，基于宏 F1 值/肯德尔相关系数进行评分。每个分数取三次独立运行的平均值。一个五层反作弊基础设施（禁止字面量扫描、重命名输入测试、覆盖/篡改测试、编码依赖测试以及低权重诱饵字段）在输入、代码和输出三个维度上防范硬编码行为。
办公任务——裁判评分组合。
对于接受办公任务评测的模型，设 为该任务中通过的确定性规则检查项数量。规则评分为
| (3) |
如果任务包含语义评分标准，且评分标准返回 ，则裁判评分为
| (4) |
评测分数使用该任务预配置的规则权重 ：
| (5) |
每个任务的 固定在 0.70 至 0.95 之间；办公任务不使用单一的全局规则权重。设 为任务 的可用评测次数。这些评测结果首先取平均值，即 。如果任务 至少有一次可用评测，则办公任务分数为其等权宏平均值，
| (6) |
规则和裁判子分数采用相同的两级聚合方式，并保留用于诊断。证据提取失败或裁判调用失败仅将受影响的评分标准置零；其余评分标准继续执行。如果某次评测因裁判输入超出支持长度或所有裁判调用均失败而无法获得裁判分数，则评估器保留规则分数和错误状态，将该次综合评测分数标记为不可用，并从两个聚合层级中排除该次评测。
基于裁判的组件与评分风险。
该套件中的三个组件采用模型评判而非程序化方式：Web 的大语言模型/视觉语言模型及智能体评判量规项目（其惩罚项按任务配置）；Office 中用于语义质量检查的大语言模型评判层；以及 Code 的大语言模型评判分数（该分数仅作为参考值记录，从不计入主要指标）。已知风险在于模型评判偏差——评判模型可能系统性地偏好特定输出风格或自身所属模型家族。这种暴露程度通过设计得到约束：主要指标依赖于 Code 的确定性验证（隐藏测试）和 Security 的逐任务确定性评分器（无大语言模型评判）；Office 通过将每个二元语义量规绑定到固定的任务后证据、保留确定性规则结果作为独立分数、并防止评判结论改变这些结果，从而降低但未消除大语言模型评判风险；Web 则保留对交付和预检查约束的确定性规则检查，同时将大语言模型/视觉语言模型及智能体评判锚定在最终工件中的记录证据上。
推理超参数。
模型的有效采样行为可在三个不同层面设置——供应商自身的服务端默认值、基准测试的路由/网关层、以及任务配置中的显式覆盖——因此项目维护了每个模型的超参数记录（涵盖温度、top-p、最大 token 数、推理/思考开关等字段），以避免混淆这三个层面。该记录当前涵盖了一个为七个已评估模型填充的数据模式。实践中，大多数模型在无显式采样覆盖的情况下运行，而基准测试刻意固定并针对每个模型报告的一个参数是推理模式。
披露政策。
腾讯工作伙伴基准测试（Tencent WorkBuddy Bench）以完全开放基准的形式发布：任务目录、环境镜像、评估代码、评分测试以及参考答案/标准解决方案均与汇总排行榜一同公开，遵循 SWE-bench 风格惯例，即发布完整任务集而非仅提供汇总分数。术语“隐藏测试”（针对代码）和“保留评估资产”（更广义而言）描述的是求解时的可见性，而非保密性：这些内容在运行过程中对智能体的自身上下文不可见，仅在智能体完成操作后才被引入或调用（见上文），但它们在已发布的数据集中与所有其他任务工件一样是公开的。防污染能力因此依赖于任务在创作时的时效性——任务基于发布日期前从模型预训练语料库中排除的内容构建——而非在发布后对任务内容进行保密。
5 结果
本节报告腾讯工作伙伴基准测试排行榜，对照该套件旨在回答的问题进行解读：在代码、网页、办公和安全这四类不同的实际工作中，智能体能力如何排名？当测试框架本身发生变化时，该排名的稳健性又如何？每个分数均为思考模式下三次独立运行的平均值，且所有四个子集均在 CodeBuddy Code（cbc）和 Claude Code（cc）两种测试框架下进行评分。每个模型在每个赛道/测试框架组合上均有评分；一个单元格——Claude Opus 4.8 在 Claude Code 下的代码分数——来自一次修改指令的运行，已在表 6 中标注并在其标题中说明。
| 代码 | 网页 | 办公 | 安全 | |||||
|---|---|---|---|---|---|---|---|---|
| 模型 | 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 榜单上均独占鳌头，这本身就是一个发现：在这套评测集上，开源权重模型与封闭前沿模型之间的差距因赛道而异，而非普遍存在。
测试框架敏感性。在两种测试框架下对所有四个赛道进行评分后，测试框架显然不是一个中立的测量工具——四个赛道受到的影响程度也截然不同。代码赛道的变化最为一致：两种测试框架下模型在代码赛道上的排名顺序存在差异——在 cbc 框架下 GPT-5.5 领先于 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 在两种框架下均领跑网页赛道。办公赛道变化最小：七个双评分模型中有五个变化幅度低于两个点（中位数绝对变化为 0.86），例外情况是 GPT-5.5（）和 HY-3（）。安全赛道在两种框架之间显示出最大的排名重排：七个双评分模型的平均绝对变化为 8.6 个点。GLM-5.2 在两种框架下均领跑安全赛道，但其下方的排名发生了显著变化：GPT-5.5 从 cbc 框架下的第六名跃升至 cc 框架下的第二名，而 MiniMax-M3 则从第二名跌至第五名。
安全赛道的拒绝情况。少数安全赛道的运行因涉及安全类请求而在任务层面被拒绝。在三轮运行中，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 项目占据了大部分检查项和大部分失败项；规则失败主要反映在交付、预检、格式或可执行测试契约上，而智能体裁判失败则对应运行工件中的工作流或状态断裂。
按难度和任务类型划分的办公性能。图 9 展示了办公性能如何随难度和七种诊断任务类型而变化。在每个测试框架内，跨模型平均得分从简单到中等再到困难任务依次下降（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 提交中的常见失败模式。我们检查了选定低分任务的交付物以及规则/评判证据。相同的问题反复出现：相关交付物不一致，记录未明确关联其来源或当前状态，结构化文件无法解析，或者智能体在未经验证的情况下提交工件。由于 Office 验证器会检查文件、跨文件关系、状态、输出契约以及基于证据的语义要求，因此即使某个交付物看似合理，这些不完整的工作流程仍会导致扣分。
5.1 Token 与轮次效率
表 7 报告了代码子集上每次运行的平均助手轮次、输出 token 和输入 token。轮次计为唯一的助手消息数，包括主智能体之外的子智能体活动。输出 token 在两个测试框架之间具有可比性；输入 token 报告时包含缓存——即同时计入缓存的上下文读取和新输入——且在不同测试框架之间不可比，因为两个测试框架在上下文和缓存管理上采用不同约定，因此输入数据应仅在单个测试框架列内解读。输出 token 计数也不应视为跨模型效率指标：不同模型使用不同的分词器，因此一个 token 在不同模型之间并非恒定工作单位，以下比较仅为示意性，而非严格的跨模型效率排名。
| CodeBuddy Code (cbc) | Claude Code (cc) | |||||
|---|---|---|---|---|---|---|
| 模型 | 平均轮次 | 输出 (k) | 输入 (k) | 平均轮次 | 输出 (k) | 输入 (k) |
| 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 token 是标准协议运行中的最低值——而其他模型大多消耗 8–29k token；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。
各子集情况。
代码预算概况并非普遍适用。办公场景最为精简——各模型及测试框架下，每次运行需 16–42 轮交互，输出 10–30k 个模型 token；网页场景居中（13–39 轮），而安全场景则远超其他，每次运行需 30–89 轮交互。222安全场景的轮次与 token 统计仍沿用早期的轮次计数规则，尚未重新计算为唯一的助手消息；因此其轮次数无法与表 7 中的代码数据直接比较。安全场景的极端情况十分显著：MiniMax-M3 在 cbc 条件下，每次运行平均需 88.8 轮交互，输入约 1110 万个（含缓存）模型 token，得分为 74.14。在所有四个场景中，GPT-5.5 始终是最高效的高分模型：在 cbc 条件下，它在每个场景中的输出预算均为所有模型中最少——代码场景每次运行输出 6.9k 个模型 token，网页场景 13.5k，办公场景 10.2k，安全场景 7.5k。
6 相关工作
我们首先将腾讯 WorkBuddy Bench 与代码、网页、办公及安全领域现有的智能体基准进行定位比较；该基准套件自身的任务构建方法、子集设计及评估框架将在后续章节详述。这些是基准测试基于自身对任务设计的定性分析而得出的设计阶段比较，并非对这些套件中的智能体进行直接对比的实测评估。
代码。代码子集所涉及的问题空间与 SWE-bench 系列 [1, 2] 以及 Commit0 [7] 这类从零开始构建库的基准测试类似，但在指令风格和角色多样性上有所不同。SWE-bench 和 SWE-bench Verified 提供详细的 GitHub issue，而 Commit0 则提供测试驱动的规范供实现，相比之下，代码任务以简短、口语化的请求形式编写，更接近团队成员提出需求的方式，而非提交的 issue，并且有意将实现细节留白；此外，代码涵盖了除 bug 修复之外的 18 个类别中的五种请求者角色（开发者、算法工程师、产品经理、QA、运维），而非单一的 issue 解决框架。该系列在抗污染方面采用了不同策略：LiveCodeBench [8] 依赖于模型训练截止日期之后发布的问题，而代码则依赖于新编写的任务目录——包括真实的上游提交、隔离环境下的重新实现以及合成工作空间——这些目录在基准测试发布之前一直构建并保密，直到发布时，提示词、隐藏测试和标准补丁才会与其一同完整公开。RepoBench [9] 和 Aider Polyglot [10] 针对同一领域的更窄范围（仓库级补全和模板化多语言练习），而 Terminal-Bench [11] 评估的是通用终端智能体能力，而非仓库范围内的代码变更。
端到端与生产级编程智能体基准测试。Vibe Code Bench [12] 评估从文本规格说明到零基础网页应用开发的完整流程，通过针对已部署应用的浏览器智能体工作流测试进行验证，使其成为可运行前端交付物的紧密参考基准。CursorBench [5] 则通过不同路径追求类似的真实性目标：它将已提交的代码追溯至真实生产会话中的原始智能体请求，因此其任务分布锚定于某一家供应商用户的实际工作方式，而非经过筛选的问题文本。这些选择使两个基准测试都成为重要的参考点，但它们为我们的场景留下了不同的空白。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 | ||||||||||||
| CursorBench 3.1 | ||||||||||||
| Design2Code | ||||||||||||
| Interaction2Code | ||||||||||||
| FrontendBench | ||||||||||||
| WebArena | ||||||||||||
| VisualWebArena | ||||||||||||
| WorkBuddy Web | ||||||||||||
办公。近期基准涵盖了办公智能体工作的互补部分。Workspace-Bench 1.0 [16] 使用细粒度评分标准，在多个智能体框架上评估具有大规模异构文件依赖关系的任务。ClawsBench [17] 评估了在快照恢复的 Gmail、日历、文档、云端硬盘和 Slack 模拟环境中的能力与安全性。OdysseyBench [18] 针对长周期、多应用工作流及扩展交互历史，而 SpreadsheetBench 2 [19] 则探究复杂多工作表工作簿中的端到端构建、修复与可视化。
ClawsBench 和 OdysseyBench 强调跨多个应用的交互，SpreadsheetBench 2 聚焦于工作簿工作流，而 Workspace-Bench 则处理异构文件依赖关系。该套件中的 Office 子集 WorkBuddyBench-Office，专注于包含多种文件格式的本地工作空间中的完整交接。智能体必须将源信息带入交付物，保持相关文件和状态的一致性，并在 CodeBuddy Code 或 Claude Code 下遵守执行约束。确定性规则检查会验证文件、跨文件关系、状态变更、副作用和执行约束，同时一个基于证据的大语言模型评判器会根据任务后固定的证据，对二元语义评分标准进行打分。每个任务都设定自己的规则/评判器权重。这些比较涉及任务和验证设计；各基准测试使用不同的任务单元、环境和评分方案。
安全。现有的安全智能体基准测试各自覆盖了红队方面的一部分：Cybench [20] 和 NYU CTF Bench [21] 对专业级和竞赛级 CTF 挑战进行评分，InterCode-CTF [22] 将 CTF 解题视为带有执行反馈的交互式编码，CVE-Bench [23] 衡量对真实世界 Web 应用 CVE 的自主利用能力，而 Meta 的 CyberSecEval 系列 [24, 25] 则评估模型自身的网络安全风险和能力，涵盖从不安全代码建议到攻击性操作辅助等方面。安全子集在两个维度上有所不同：覆盖范围和评分。其 60 个任务在一个套件中涵盖了红队和蓝队工作——包括漏洞发现与安全利用、恶意软件分析、安全运营以及智能体安全——而不仅仅是 CTF 或单一利用，并且每个任务都由一个确定性的、每个任务独立的 scoring.py 在五层反作弊机制下进行评分，全程不涉及任何大语言模型评判器。其白盒发现任务锚定于广泛部署的上游项目中真实的历史 CVE，这些 CVE 被重建为经过重写、沙盒化的环境，并使其远离公开训练语料库以抵抗污染。
该套件新增的内容。该套件的差异化在于其广度和框架设计，而非引入新的任务类型。代码部分将仓库级任务与五种请求者角色以及一个基于日常口语化请求（而非已归档的问题提示）的18类别分类法相结合，通过设计上采用在发布前才保留的新建任务目录，从根本上抵御了可搜索提示和泄露答案的污染。网络部分将上述任务类型、生命周期模式、交互/状态以及评判维度统一整合到一个体系中，结合了规则检查、LLM/VLM评判，以及针对运行中前端产物的智能体评判验证。办公部分将混合格式、多产物的工作流视为完整的交接过程，通过独立保留的规则通道和评判通道，来衡量机器可检查的工作区状态和语义交付物质量。安全部分涵盖了红蓝对抗的全谱系，在公开基准仍稀缺的领域内，采用完全确定性的每任务评分。对可搜索提示以及泄露测试或答案的抵御，依赖于发布前才保留的新建任务目录以及其设计本身；基于分布信息的构建则依赖于分布匹配的任务，这些任务完全开源发布——任务目录、环境镜像、评估代码、评分测试和参考解决方案均公开——因此可以完全独立审计，而闭源厂商则无法做到。这些仍然是该基准自身设计阶段的定位声明，并非跨对比套件的智能体性能实测比较。
7 局限性与结论
本节讨论本报告中描述的腾讯WorkBuddy Bench当前存在的局限性，以及为应对这些局限性而规划的近期工作。
- •
一个排行榜单元格使用了修改后的指令设置。所有七个模型均在两个测试框架下对所有四个赛道进行评分。唯一一个可比性方面的注意事项是Claude Opus 4.8在Claude Code下的代码得分：如表6所述，除了禁用的AskUserQuestion工具外，该次运行还额外添加了一条明确的“禁止提问、一次性完成”的指令，因此其设置与其他运行略有不同，其得分在第五节中与代码测试框架偏移汇总一同报告，但未纳入其中。
- •
代码子集的语言侧重问题。代码子集的开源发布以 Python 任务为主；跨语言覆盖仅限于少量任务，这些任务将 JavaScript、TypeScript 或 Rust 项目的目标行为移植到 Python 中。本报告中关于编码难度、编码与数据/算法之间的差距以及评估框架差异的发现，在未经进一步评估的情况下，不应假定可推广至其他编程语言或生态系统。
- •
开源发布带来了发布后的数据污染风险。腾讯 WorkBuddy Bench 完全开源发布——任务目录、环境镜像、评估代码、评分测试和参考解决方案均公开，以便外部读者能够独立重新运行和审核单个任务结果，而不仅仅是复现本报告前面描述的流程。这种开放性的代价是，已发布的任务内容从发布那一刻起就面临被爬取并纳入未来模型训练数据的风险，这会随着时间的推移削弱抗污染能力。通过数据集版本管理（而非隐藏任务内容）可以缓解（但无法消除）这一问题——未来的版本可以淘汰或替换出现污染迹象的任务。
- •
基于评判器的组件存在模型评判器偏差。网页评分结合了基于规则的检查与 LLM/VLM 及智能体评判器对运行中前端产物证据的评估；办公评分将确定性规则检查与 LLM 评判器对固定任务后证据的评估相结合；代码评分则额外计算一个诊断性的加权 LLM 评判器分数（涵盖多个维度），该分数不计入主要指标。办公评分独立保留规则检查结果，因此评判器无法更改它们，但其语义评分仍受模型评判器偏差影响。更广泛地说，模型评判器可能偏好它们熟悉或易于理解的回答风格，而不管任务正确性如何——本报告尚未单独量化这一风险。
- •
评分结果与特定的服务端和测试框架条件相关。本评估中使用的 HY（混元）端点由其提供方第一方提供服务，而所有其他模型均通过第三方服务端点访问，后者的参数配置和请求处理方式可能会影响指标。同样，结果也与本次评估中使用的两个测试框架的特定构建版本相关，随着测试框架版本的演进，指标也可能会发生变化（第 4 节）。
- •
Office 以文本优先。当前的 Office 版本涵盖了本地混合格式的工作流程，但不需要 OCR、视觉语言模型、像素级布局判断或原生桌面 GUI 交互。因此，Office 的结果适用于文件处理、状态更新和基于证据的工作流程完成，而不适用于视觉感知或 GUI 操作。
近期工作聚焦于校准：继续进行 Web 评分标准校准，并在可行的情况下，将一种修改后的指令配置（Claude 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
*这些作者对本文贡献相同。作者顺序按字母顺序排列。†项目负责人。
参考文献
- 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 多语言基准测试。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。