四块分数不能加总：腾讯 WorkBuddy Bench 把编码 Agent 拆成四套尺子

四块分数不能加总：腾讯 WorkBuddy Bench 把编码 Agent 拆成四套尺子

腾讯优图实验室、科恩安全实验室、WorkBuddy 和云鼎安全实验室的技术报告 Tencent WorkBuddy Bench 在 arXiv 的公开戳记是 2026 年 7 月 23 日（2607.20911）。PDF 封面写的日期是 July 24, 2026。WorkBuddy Bench 是一套编码 Agent 评测：不把「会改代码」收成一个总分，而是用四套不能互比的尺子，看仓库工程、前端、办公流程和安全任务各自做到哪。

公开套件防的是能被搜到的题目，不是把题藏起来

报告把现有编码评测分成两类。SWE-bench 和 SWE-bench Verified 在发布时就把题固定下来，题面和做法经常能在网上搜到，分数上升可能是记住了某条 issue 或 pull request，而且范围几乎都是单条缺陷修复。另一类从真实生产会话抽任务，分布更接近真实用法，但套件本身不公开，外人看不到选题偏没偏向自家 Agent。

WorkBuddy Bench 走第三条：任务分布对照内部用法分类来配比，但放进题里的不是原始用户提示、会话或用户数据。每道题都从真实 commit、pull request、历史 CVE，或一个具体业务场景倒推，再改写成很短的、口语化的、角色扮演请求。指令不给根因、参考 diff，也不把解法写进题面。题面因此不能靠搜索原来的 issue、pull request 或 commit 讨论串找回来。

套件是全公开的：任务目录、环境镜像、评测程序、测试和参考解都放出。抗污染靠的是这种改写，加上以后可以换掉被污染题目的数据集版本，不靠保密。公开的代价也写明了：发出去之后，题目可能被爬进以后的训练数据，抗污染会随时间变弱，版本替换只能减轻，不能消除。

四块为什么放在一套里：不是因为分数能加，而是任务形状一样。Agent 被放进一个工作区，按自然语言请求交一份产物，再由它看不到的验证器打分。真实组织里，同一个编码 Agent 会被要求做前端、对办公文件、看安全材料，不只改代码。

四块规模和四套打分

表 1 的首发规模：

• Code：仓库级软件工程，80 题。每轮用隐藏测试打分。「隐藏」是指解题时 Agent 看不到测试，不是对公众隐瞒；完整测试随公开包放出。
• Web：前端和界面，70 题。规则检查管确定约束，LLM/VLM 裁判管文本、结构和视觉语义，Agent 裁判去点正在运行的页面，看交互和状态。
• Office：办公数据和文件流程，50 题。确定规则查文件、结构、数值、状态和执行边界；证据固定之后，再用 LLM Judge 做二元语义评分。两分分开报，再按该题预先配好的权重合成。Judge 不能改规则检查的结果。
• Security：红队和蓝队，60 题。只用确定性的 scoring.py，不用 LLM 裁判。

因为尺子不同，四块分数不能横向比，套件不报一个总平均。报告把这写成设计，不是待补的缺口。开篇示意图上印过一列 Overall，例如 Claude Opus 4.8 显示 75.0%，还有 Kimi K2.7 且 Security 为空。正式表 6 没有 Kimi 这一行，正文也反复说没有套件总分。下面的排名只用表 6，不用那一列 Overall。

每道题先过准入：未改动的工作区基线奖励 ≤ 0.3，至少一份参考解的验证奖励 = 1.0。这样既排除「什么都不做就已经差不多做完」，也排除「参考解自己都过不了」。

每道题的验证奖励在 0 到 1。一条赛道的分数是全部题目的等权平均，再按 0–100 显示。表 6 的每个格子是 think 模式下 3 次独立运行的平均。两套 harness 并排：默认是 CodeBuddy Code（cbc），另一套是 Claude Code（cc）。两边都把推理强度固定为 high，上下文窗口统一 200k，并关掉 WebSearch 和 AskUserQuestion。其余采样参数用各家服务的默认值。HY-3（混元）走厂商自己的端点，其他模型走第三方端点；报告写明这不对称，参数和请求处理可能影响分数。

沙箱只给声明过的工作区。评分材料在 Agent 做完之后才放进来，避免漏进上下文。远程沙箱里不放评测侧代理；做不到这种隔离的那一种后端和连接组合直接禁用，不静默换路径。

题目怎么来，以及每块里有什么

Code 的 80 题：34 题来自真实上游（家族 A）；46 题没有上游代码，其中净室重实现 24 题（家族 B，含 4 题把 JavaScript、TypeScript 或 Rust 的目标行为移植到 Python），全合成工作区 22 题（家族 C）。请求通过五种角色来说：开发、算法、产品经理、测试、运维。缺陷修复只占 80 题里的 10 题。公开版以 Python 为主，跨语言只覆盖这少量移植题。

Web 的 70 题覆盖生成、修改、分析和质量保证。七类里页面交互 21 题、数据可视化 15 题，合计 36 题。生命周期上，从零开始占 35 题；其余是缺陷修复 8、功能扩展 8、评审分析 7，以及测试等。25 题是非交互的。题目必须把声明的产物交到声明的路径，运行时没有外网、外部账号、密钥或在线数据。

Office 的 50 题分两条建造路线：30 题按任务规格和目标能力重建，20 题从抽象办公流程展开。内容是 24 个数据、表格或结构化处理，17 个文档、报告或演示，9 个工作区自动化或有状态流程。难度 13 易、24 中、13 难。产出可以多标签：表格 24、Markdown 20、JSON 15，另有纯文本等。这版是文本优先，不做 OCR、像素级版面判断，也不操作桌面 GUI。

Security 的 60 题偏红队：红队 38，蓝队 22，卷成四块，细类有漏洞发现与安全复现、恶意样本分析、安全运营和 Agent 安全评估。报告写的目标不是写补丁。题面不预先给缺陷位置或期望行为，全部在沙箱里跑。

表 6：没有一个模型四块都第一

七个模型，分数是 0–100。列顺序是 Code、Web、Office、Security，每列先 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

‡ 只有 Claude Opus 4.8 在 Claude Code 上的 Code 分，是改过指令的运行：在已经关掉 AskUserQuestion 之外，又加了一条「不要提问、一次做完」。这个格子不能和别人的 Code 完全并排。报告把它报出来，但没有折进 Code 的 harness 偏移汇总。

八列里第一名分成三家。Claude Opus 4.8 拿五列：两边的 Code（cc 那列是 ‡）、两边的 Web，以及 cbc 的 Office（82.37，HY-3 的 82.08 紧跟）。GLM-5.2 拿两列 Security：cbc 76.32，cc 80.86。GPT-5.5 只拿一列，cc 的 Office，86.05。开源权重的 GLM-5.2 能在安全两列都第一，说明开源和闭源的差距随赛道变，不是处处同一方向。

换 harness，名次会动，安全动得最大

Code 上，cbc 里 GPT-5.5 的 72.90 高于 GLM-5.2 的 71.54；cc 里反过来，76.63 低于 77.06。

Web 上，七个模型里四个在 cc 下降，从 HY-3 的 −1.28 到 GLM-5.2 的 −6.72；三个上升：Claude Opus 4.8 +1.72，DeepSeek-V4-Flash +3.00，GPT-5.5 +3.72。有符号平均偏移 −1.14。Claude Opus 4.8 在两边都领先。

Office 动得最小。七个里五个的绝对偏移不到 2 分，绝对偏移的中位数是 0.86。例外是 GPT-5.5 +4.09，HY-3 −2.00。

Security 的平均绝对偏移是 8.6 分，重排最大。GLM-5.2 两边都第一，但下面换位：GPT-5.5 从 cbc 的第六升到 cc 的第二，MiniMax-M3 从第二掉到第五。

安全题上有拒答，而且拒答的轮次仍然算进平均。三次运行里，Claude Opus 4.8 在 Claude Code 上 13 次任务级拒答，在 CodeBuddy Code 上 0 次；GPT-5.5 在 CodeBuddy Code 上 2 次；其余模型 0 次。

另有一次诊断，不进榜。HY-3 打开跨轮思考回传后，Code 的 cbc 从榜上配置到 66.72（+3.82），cc 到 68.18（+1.92），仍是三次运行。榜上报的是标准配置。

难的是对着现有契约改仓库，不是把算法写出来

Code 内部，各模型加 harness 的配置几乎都是数据和算法题高于编码题，大约 74% 对 65%。按全部有效配置的平均奖励，最难的两类是 bug_fix 0.47 和 api_contract 0.47；最容易的是 feature_pipeline 0.94 和 testing 0.88。product_analytics 从 0.08 到 1.00，跨度几乎拉满。报告的读法是：数据和算法题难在业务语义；对着现有契约精确改一个真实仓库，才更能拉开差距。

表 6 和这个读法一致：同一个模型加 harness，Code 分都低于它自己的 Office 分，常常低 10 分以上；Code 高于 Web 的情况里，只有 HY-3 例外，cbc 是 67.71 对 62.90，cc 是 66.43 对 66.26。

两种丢分方式被单独写出来。一种是行为大体对，但契约没对上：OpenAPI 题漏一两个必填字段，或把路径参数的 required 留在默认值，十几项逐字段检查会连带记零。另一种是代码能跑，业务规则没读懂：口语要求不算「过了很久才发生的购买」，高分模型按归因窗口过滤，低分模型把所有购买都算进去。

Web 没有在正文里给各类的精确分。报告只给方向：视觉设计和分析报告最强，代码测试和页面实现次之，页面交互和数据可视化语义失败最多。非交互和轻交互高于有状态；单流程状态变化、多步工作流、持久化、离线和跨状态最难。丢分主要不是画不出页面，而是状态来源、显示、持久化和最终载荷对不齐。检查条数和失败条数大多落在 LLM/VLM 项；规则失败多是交付、预检、格式或可执行测试；Agent 裁判失败对应运行中的流程或状态断了。

Office 按难度的跨模型均值：cbc 是易 84.6、中 80.3、难 73.1（这一面板 10 个模型）；cc 是 83.9、78.9、72.0（9 个模型）。这不是表 6 那七个模型的子集均值。题量是易 13、中 24、难 13。Claude Opus 4.8 在两边都领先多源合并与对账。GPT-5.5 在 cc 上领先图里七类中的五类，包括聚合与指标推理、复杂规则执行和结构化抽取。GLM-5.2 的 Office 总分几乎不随 harness 变（79.60 对 79.57），但多文件抽取从 87.7 掉到 70.5，复杂规则执行仍是 83.1 对 83.3。图 9 里 HY-3 的分项早于它更新后的 Office 运行，所以面板均值里还有旧分。抽查的低分提交反复出现：相关产物互相不一致、记录对不上来源或当前状态、结构化文件解析不了、交卷前不自检。

输出长短和名次对不齐

Code 上，回合数按不重复的助手消息计，含子 Agent。输出 token 可以在两套 harness 之间看，但不同模型的分词器不一样，不能当成严格的效率排名。输入 token 含缓存读取，两套 harness 的上下文和缓存约定不同，不能跨 harness 比。Security 的回合统计还没按这套新口径重算，不能和 Code 的表 7 直接比。

GPT-5.5 在 cbc 上每轮输出 6.9k token，是该 harness 最低；cc 上 8.7k，是标准协议里最低。cc 上绝对最低的是 Claude Opus 4.8 那次改指令运行，4.7k。DeepSeek-V4-Flash 在 cc 上输出大约是 GPT-5.5 的 3.3 倍（28.6k 对 8.7k），Code 分却低 14.74（61.89 对 76.63）。GLM-5.2 的 cc Code 分 77.06 只用比 GPT-5.5 高 0.43，输出却是 22.0k 对 8.7k。Claude Opus 4.8 在 cbc 上输出最高，22.3k，同时拿到 cbc 的 Code 第一。

标准协议的回合数大约差 2.4 倍，从 HY-3 在 cc 上的 18.07 轮（Code 分 66.26）到 DeepSeek-V4-Pro 在 cbc 上的 44.01 轮。cbc 上回合最多的两个，V4-Pro 44.01 和 V4-Flash 40.30，也是 cbc Code 分最低的两个。改指令的 Claude Opus 4.8 在 cc 上是 13.2 轮，低于标准范围。

这个花费结构不能外推到其他三块。Office 最省，大约 16–42 轮、每轮输出 10–30k token。Web 在中间，13–39 轮。Security 最重，30–89 轮。极端是 MiniMax-M3 在 cbc 的 Security：平均 88.8 轮、大约 1110 万含缓存输入 token，换来 74.14。GPT-5.5 在 cbc 上四块都是输出最少的那一档：Code 6.9k，Web 13.5k，Office 10.2k，Security 7.5k。

这些数不能被读成什么

没有套件总分，示意图上的 Overall 不能用来排名。四块分数不能比高下。Claude Opus 4.8 的 cc Code 分是改指令运行。Code 以 Python 为主，不能推到其他语言。Web 和 Office 的语义分带模型裁判偏差，报告没有单独量化这种偏差；Code 另有一个加权 LLM 裁判分，不进头条指标。Office 不做视觉和 GUI。HY-3 和其他模型的服务端不对称。分数绑在这次用的两套 harness 构建上。安全拒答被平均进去，不是剔除后的能力分。难度曲线的模型数（cbc 10、cc 9）和表 6 的七个模型不是同一集合。公开之后的污染只能靠以后换题减轻。相关工作里和其他基准的对照是设计比较，不是同一批 Agent 的实测对打。

出处：腾讯，Tencent WorkBuddy Bench Team（Siqi Cai、Shaopeng Chen、Xiang Fei 等），Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction，2026-07-23，https://arxiv.org/abs/2607.20911