workbuddy-bench

WorkBuddy Bench：腾讯开源的编程 Agent 评测基准

图：WorkBuddy Bench 项目 Banner，四个子集分别是 Code、Web、Office、Security

---

场景切入：如何判断一个编程 Agent 是不是"真的能干活"？

现在的 Agent 榜单几乎都在刷同一个指标：让模型在一个 SWE-bench 风格的 Python 仓库里修一个 Issue，然后看测试通过率。但真实世界里，工程师面对的远比这复杂——前端页面写不出效果、Excel 里的透视关系搞不清、线上出了漏洞得复现和修复。这些场景，现有基准几乎覆盖不到。

更麻烦的是，谁来出题才公平？如果题目是研究者编的、脱离真实工程语境，那么测出来的分数和"这模型在我团队能不能用"之间，隔着一条鸿沟。

WorkBuddy Bench 给出的答案是：从真实岗位工作里逆向出题。腾讯 Youtu Lab、Keen Security Lab、WorkBuddy 和云鼎安全实验室联合出品，把真实的开发、PM、算法、QA、运维、安全任务，逆向改写成角色化的评测题目。给 Agent 一个沙箱工作区和一道题，它要交出正确的产物（一个 patch、一份文件、一份报告），最后由一套测试判分。

---

背景与起源

WorkBuddy Bench 于 2026 年 7 月在 GitHub 发布，目前 439 颗星、58 个 fork，Apache 仓库持续活跃（最近一次推送就在本月）。项目配套在 HuggingFace 上发布了数据集，官网 workbuddybench.com 同步上线。

它的作者阵容本身就说明了定位——既有做算法模型的研究团队（Youtu Lab），也有安全攻防团队（Keen Security Lab、云鼎安全实验室），还有 WorkBuddy 这个 AI 编程产品团队。也就是说，出题的人来自那些真的在用 Agent 做研发工作的一线团队。

设计上，项目明确把"题目来自真实工作"作为第一原则，这一点在 README 中被反复强调，也是它与同类基准最本质的差异。

---

四个子集：覆盖工程师的全部工作面

子集	题量	领域	Agent 具体要做什么
Code	80	仓库级软件工程（Python）	被放进真实项目的某个基线 commit，跨模块定位并修改代码，通过测试。18 类任务横跨开发、PM、算法、QA、运维五种角色
Web	70	前端 / GUI（HTML/CSS/JS）	生成、修改、分析、测试前端工作：页面交互、数据可视化、视觉设计、项目分析、页面实现、文档转换
Office	50	办公数据 / 文件工作流	操作 xlsx / csv / pdf / docx 混合格式文件，产出精确正确的产物。难度来自结构、关系、状态和证据链，而非行数
Security	60	安全 / 漏洞（红 + 蓝）	发现并安全复现真实漏洞、分析恶意软件、执行安全运维、探测 Agent 自身攻击面，覆盖 6 个安全域

合计 260 道题。 Office 子集的设计理念尤其值得注意——README 明确写道"难度来自结构、关系、状态和证据链，而不是行数"。这意味着它考的不是 Agent 能不能读懂一个大 CSV，而是能不能理清 Excel 里多层透视表、公式引用、跨表关联，最终产出数据完全一致的文件。

Security 子集的红蓝对抗设计同样有特色：不仅让 Agent 找漏洞，还包括"探测 Agent 自身的攻击面"——即用安全任务反向检验 Agent 的安全边界是否可靠。

---

技术架构：Harbor 编排 + Docker 沙箱 + 三层解耦

WorkBuddy Bench 的评测框架（而非数据集本身）是这个仓库的主体。核心设计是三层解耦：

1. 任务与数据集层

数据集不在 Git 仓库里，而是作为每个子集一个 .tar.gz 归档托管在 HuggingFace（tencent/workbuddy-bench），按需下载：

子集	归档	题量	体积
Code	wb-bench-code-v1.0.tar.gz	80	~196 MB
Web	wb-bench-web-v1.0.tar.gz	70	~22 MB
Office	wb-bench-office-v1.0.tar.gz	50	~10 MB
Security	wb-bench-sec-v1.0.tar.gz	60	~479 MB

下载脚本优先用 huggingface-cli，回退到 curl/wget，并用仓库内的 SHA256SUMS 做校验后解压。

每道题的任务目录结构高度标准化：

tasks/<task-id>/
  instruction.md              # 给 Agent 的自然语言任务说明
  task.toml                   # 任务元数据
  environment/
    Dockerfile                # 任务专属环境定义
    docker-compose.yaml
    scorer.py                 # 判分脚本
    workspace.tar.gz          # 沙箱初始工作区（保持打包）
  tests/                      # 测试用例

设计上有个细节很讲究：workspace.tar.gz 保持打包不展开，由任务 Dockerfile 在容器内 COPY 并解压到 /workspace。这避免了宿主机上解压几百 MB 归档的 I/O 开销，也防止 Agent 意外接触到不该看到的文件。

2. 编排运行时层

框架直接复用上游的 Harbor 作为编排运行时，并通过 [tool.uv.sources] 按 tag 固定到 v0.18.0——不依赖相邻的 editable checkout，升版本只需改 tag。

核心代码模块划分清晰：

src/workbuddy_bench/
  agents/     # Agent 适配层
  runner/     # 批量执行调度
  judge/      # 判分逻辑
  scorer/     # 分数计算
  proxy/      # 协议转换代理

其中 proxy/ 模块值得单独一提——它实现了一个 Anthropic ↔ OpenAI 协议转换代理（FastAPI + Uvicorn 实现）。这意味着同一套评测框架可以同时评测走 OpenAI 协议和走 Anthropic 协议的模型，端点地址由配置注入。

3. 配置层

三层 YAML 配置，职责分明：

• 模型配置 configs/models/<provider>/<slug>.yaml：声明模型 ID、协议类型（openai 或 anthropic）、以及存放 base URL 和 API Key 的环境变量名
• Harness 配置 configs/harnesses/：描述要评测的 Agent CLI，当前内置 claude-code 和 codebuddy-code 两个 harness
• Job 配置 configs/jobs/：一次评测运行 = 一个模型 + 一个 harness + 一个数据集

# configs/jobs/<slug>.yaml
model: <provider>/<slug>
harness: codebuddy-code/<version>
dataset: datasets/wb-bench-code-v1.0/tasks

密钥全部通过 .env 注入，代码里只存环境变量名，不进版本控制。

---

上手体验：让 Agent 帮你配好一切

项目最有意思的设计是内置的 wbbench-run-setup skill（位于 .agents/skills/，同时链接到 .claude/skills/）。

用支持技能的 Agent（如 Claude Code、CodeBuddy Code）打开这个仓库，直接调用 /wbbench-run-setup 或说"帮我配置一次 WorkBuddy Bench 运行"，skill 会一步步带你完成：下载数据集、准备环境、配置模型、填写 .env 凭据、生成 job 文件、启动运行，最后产出分析报告。

这是一个很聪明的产品设计。 评测基准的门槛往往不在评测本身，而在"配置地狱"——几十个环境变量、YAML 嵌套、路径对齐。把这些繁琐步骤封装成 skill，让 Agent 来做，本身就是用被评测的对象来完成被评测工具的初始化，堪称自我指涉的妙招。

手动配置的等价路径也很清晰：

# 1. 安装依赖
uv sync
cp .env.example .env

# 2. 下载数据集
./scripts/dataset/fetch-dataset.sh code    # 或 web / office / sec / all

# 3. 配置模型
cp configs/models/_template.model.yaml configs/models/<provider>/<slug>.yaml

# 4. 配置 job
cp configs/jobs/_template.job.yaml configs/jobs/<slug>.yaml

# 5. 先 dry-run 预览
uv run ./scripts/run.sh --job <slug> --dry-run

# 6. 正式运行
uv run ./scripts/run.sh --job <slug>

结果落在 results/ 目录下，捕获内容包括 patch、完整轨迹（trajectory）、测试结果和效率指标。

---

局限与挑战

数据集不在仓库，需外部下载。 这在工程上是合理的（避免仓库膨胀），但增加了首次使用的不确定性：全部四个子集加起来约 707 MB，且 Security 子集单独就占了 479 MB。官方社区 Relay 之外的环境若无 HuggingFace 访问权限，会比较棘手。

评测维度偏"正确性"。 框架主要通过测试套件判分，捕捉的是"产物是否正确"。但真实工程中的隐性维度——代码可维护性、与团队规范的契合度、变更的影响面评估——很难通过自动化测试表达。

Harness 覆盖面有限。 目前内置的 harness 只有 claude-code 和 codebuddy-code 两种，其他主流 Agent CLI 需要自行按 HARNESS_AUTHORING.md 编写适配。

许可证有地域限制。 LICENSE 文件明确写着 "WorkBuddy Bench IS NOT INTENDED FOR USE WITHIN THE EUROPEAN UNION"，这是腾讯自定义许可证而非标准开源许可证，商用和再分发需仔细审阅条款。这一点与它"开源评测基准"的定位存在张力。

安全子集的双刃剑属性。 红蓝对抗题目（漏洞复现、恶意软件分析）对安全研究有正向价值，但也需要使用者明确授权环境、隔离运行。项目通过 Docker 沙箱做了隔离设计，但使用者仍需自行确保合规。

---

行业意义：Agent 评测从"刷分"走向"实战"

WorkBuddy Bench 的意义可以分三层来看。

第一，评测维度的扩展。 当主流 Agent 基准还在围绕"Python 仓库修 bug"打转时，WorkBuddy Bench 已经把题目扩展到前端 GUI、办公文件工作流和安全攻防。这三块恰恰是当前 Agent 最不擅长、也最有实际价值的地方——一个能修 Python bug 但写不出前端页面交互的 Agent，在真实研发团队里的价值是有限的。

第二，出题方法的转变。 "逆向改写自真实岗位工作"这个方法论，比人造题目更接近评测的终极目的。SWE-bench 的贡献是确立了"从真实 GitHub Issue 出题"，而 WorkBuddy Bench 试图把这一理念从"单个 bug"扩展到"完整岗位工作流"——这在题目粒度和评分设计上都需要新的方法论。

第三，自举式的工具设计。 用 Agent 技能包来配置 Agent 评测环境，看似绕了一圈，实际上精准击中了当前评测基准最大的落地障碍：可及性。如果一套基准需要三天才能配好跑起来，它的评测价值再高，实际影响力也会大打折扣。

从产业节奏看，随着 Agent 从"辅助写代码"走向"承担完整工作流"，评测需求必然从"代码正确率"扩展到"交付物可用性"。WorkBuddy Bench 出现的时机，恰好在这个转折点上。

---

想试试？

最快的方式是：用 Claude Code 或 CodeBuddy Code 打开这个仓库，调用 /wbbench-run-setup，让它带着你完成从数据集下载到跑出报告的全流程。想深入理解评测框架怎么工作的，可以先读 configs/README.md 和 src/workbuddy_bench/runner/ 的实现。

项目地址： https://github.com/Tencent/workbuddy-bench 数据集： https://huggingface.co/datasets/tencent/workbuddy-bench