AREX Feed Article
腾讯 WorkBuddy Bench 开源：260 道题测 Agent，两条自动化流水线白送
7 月 23 日，腾讯 WorkBuddy 团队将一套多领域 coding agent 评测基准完整开源。论文上线 arxiv（），与 HuggingFace 数据集同步公开。260 道任务横跨 Code 80、Web 70、Office 50、Security 60 四个子集，全部从真实 commit、PR 或业务场景逆向构造。
榜单之外，仓库 .agents/skills/ 目录下藏着两个 agent skill：wbbench-run-setup 管跑评测，wbbench-report-skills 管写报告。你跟 Claude Code 或 CodeBuddy Code 说一句话，它一阶段一确认地带你跑完整轮评测——从拉数据集到配环境、写模型配置、填凭据、dry-run，再到正式跑分和自动出报告。
大多数开源 benchmark 给你一个排行榜。WorkBuddy 给你的是复现排行榜的完整流水线。
没人讨论分数，都在拆那两条 Skill
8 月 9 日，软件开发者 Lucky J（）发长推拆解 WorkBuddy Bench，称它"说白了就是腾讯内部用来选模型的评测体系，现在整个打包公开了"。
他的关注点不在榜单，而在两条 Skill。wbbench-run-setup 分七个阶段，从拉数据集到 dry-run 确认再到正式跑，每个阶段一确认。
推文指出 Skill 设计有三条反常识的规矩：读实时模板不靠记忆里的字段名、运行时发现选项不硬编码列表、全程用你的语言回复。他的判断是——"本质上是把跑评测最容易踩的坑，直接固化成了 agent 能执行的 playbook。"
wbbench-report-skills 则路由 Office、Web、Code 三个 benchmark 的报告生成。第一步不是分析数据，而是搞清楚 RUN_DIR 指向哪一层目录——Harbor 的结果结构是 JOB → RUN → TRIAL 三层嵌套，选错了整份报告就错了。Skill 选不出唯一候选就回头问用户，不猜默认路径。
更早的讨论集中在论文的反 contamination 设计。AI 研究者 Gill（）7 月 28 日写道，当前大多数 agent benchmark"从根本上就是坏的，因为模型只是在记忆网页"，而 WorkBuddy 把真实 commit 逆向改写成口语化的、凌乱的任务请求，"你没法靠搜索引擎蒙混过关"。他认为这套设计"让 agent 被迫做真正的仓库级推理"。
中文科技自媒体 @金尘马（）在 7 月 24 日也总结道：每道题从真实 commit、PR 或业务场景逆向构造，再改成口语化角色请求，"降低数据污染"。同一天， 发布了完整数据摘要：双 harness 三跑平均，八个计分列中 Claude Opus 4.8 领先五列，GLM-5.2 领先 Security 两列，GPT-5.5 领先 Claude Code 下 Office 列。
SWE-bench 的题能被搜出来，WorkBuddy 的搜不出来
Coding agent 评测面前有两类基准，各有致命伤。
SWE-bench 这类静态公开套件：题目和答案在互联网上流转，模型分数上升可能反映的是对特定 issue 线程的记忆，而非真正的仓库级推理。前端生成和 web agent 的基准也面临同样困境——它们从公开仓库和网站取材，而这些素材本身就能被爬取训练。
CursorBench 这类厂商内部基准则走向另一个极端：从真实生产会话抽题，任务分布确实跟踪了 agent 的实际使用方式，但基准本身闭源。外部无法检查其任务分布、无法排除厂商对自己 agent 的选择性偏向。
WorkBuddy Bench 论文把这两个困境写在了摘要第一段。它的解法不是保密，而是从构造环节关闭搜索通道：每道题从真实 commit、PR 或业务场景出发，改写成口语化、故意不充分的角色扮演请求——指令有意省略目标文件、具体 schema 和修改边界。论文把这称为 "deliberate underspecification"——故意的信息不足，不是疏忽。
agent 必须自己从仓库里挖出缺失的上下文才能行动，搜索引擎帮不上忙。论文诚实地说清楚了局限——模型可能已在训练阶段见过原始公开 commit 或 CVE 分析，版本化只能延缓而不能消灭暴露。
四套评分器，不设总分，GPT-5.5 最省 token
四类任务用四套完全不同的评分器。Code 用隐藏测试——agent 解题时看不到，但评测结束后连同整套测试代码一起公开。
Web 用规则检查、LLM/VLM 语义评判和 agent 交互评判的三层 rubric。Office 融合确定性规则检查和带证据链的 LLM Judge。Security 用纯确定性评分器（PoC 验证、YARA 匹配、ground-truth 比对），不引入 LLM。
因为评分器不同，分数不可跨子集比较，基准也不报告任何"套件总分"。论文写明：这是故意的设计决定，"不是一个需要填补的缺口"。
的公开榜单显示，没有哪个模型能通吃。Claude Opus 4.8 拿下八个计分列中的五个（Code 双 harness 74.43/77.90，Web 双 harness 68.14/69.86，CodeBuddy Code 下 Office 82.37）。开源权重模型 GLM-5.2 在 Security 上两个 harness 均排第一（76.32/80.86）。
更有意思的是 token 效率。GPT-5.5 在 CodeBuddy Code 下四个子集的输出 token 预算全场最小——Code 每次运行仅 6.9k，Web 13.5k，Office 10.2k，Security 7.5k——同时在 Code 和 Office 保持第一梯队分数。GLM-5.2 的两个 Security 榜首是用 token 换来的：每次运行 30-31k 输出 token。最快的是 Claude Opus 4.8 在 Claude Code 下的 4.7k。
同一模型在不同 harness 下剧烈波动。GLM-5.2 在 Web 上 Claude Code 跑出 67.43，换 CodeBuddy Code 掉到 60.71。GPT-5.5 在 Security 上 CodeBuddy Code 下 77.91，Claude Code 下只剩 64.39。报告强调"harness 是结果的一部分"。
Code 子集 80 道题中，bug 修复只占 10 道。其他 70 道覆盖功能开发、代码工程、测试、算法和数据分析。五个 requester 角色——developer、算法工程师、PM、QA、ops——各自用自己的口吻发出请求。难度来自跨模块探索：找对要改的文件，比写出改动本身更难。
评测的下半场：从排行榜到评测工厂
此前的 agent 评测，门槛在于"有没有好题"。WorkBuddy Bench 把门槛转移到"能不能把评测本身跑对"。
wbbench-run-setup 的七个阶段是一份防错清单。任务数据不在 GitHub 仓库里，而是四个 .tar.gz 归档托管在 HuggingFace 的 ，附带 SHA-256 校验值。Skill 引导 agent 从正确地方拉取、校验、再解压，而不是凭记忆猜路径。
wbbench-report-skills 暴露了更深的工程现实。Harbor 框架的结果目录有三层嵌套——JOB → RUN → TRIAL——只有 RUN 层包含 job.log 和 task 子目录。Skill 先校验 RUN_DIR 指向正确层级，再跑 scorer 生成 metrics.json，最后写 report.md。全程只读输入，只往 REPORT_DIR 写，不动原始数据。
这套规范里藏着一组真实的工程教训：reward（每任务均值）和 pass_rate（整题全过的占比）不是一回事；Rule-only 和 Rule+Judge 评分不能直接比——配了 LLM judge 才有 Judge 分；每个判断必须绑定 task ID 和证据；只改测试、不动产品代码的改动不算有效修复。
当 agent 本身成为评测的执行者，benchmark 的设计对象就从人类研究员变成了另一个 agent。WorkBuddy 的两条 Skill 就是这个转变的成品示例：不只是怎么写好一份 playbook，更是怎么让 agent 在真实评测场景中不踩坑。
开源的不是排名，是产生排名的方法
论文、任务目录、workspace 镜像、评测 harness、评分代码、测试套件、参考方案——全部公开。连"隐藏测试"也公开，只是 agent 解题时看不到。第三方可以逐题复现、逐题审计。
论文特意列了一张表说明开放范围，并在末尾注明：唯一不存在的组件是用户数据，因为构建过程中根本没用到。
两条 agent skill 以纯文本 Markdown 存放在 .agents/skills/ 目录下，任何人 clone 仓库即可阅读、修改、复用。腾讯开源的是一套完整的评测基础设施——从数据、到执行、到报告、到审计——而不仅仅是一张排行榜。