Tencent WorkBuddy Bench：一种具有抗污染任务构建的多领域编码智能体基准测试

TL;DR Tencent WorkBuddy Bench 是一个多领域编程智能体基准，所有任务均由真实代码提交反向重构为口语化请求，实现在完全开放数据集的同时抵抗训练数据污染。

问题

问题背景

当前编码智能体（coding agent）评估主要依赖两种基准：一种是基于公开代码仓库的 issue/PR 文本，另一种是竞速式刷榜。前者易受数据污染（模型训练时已见过任务原文），后者则偏向简单、可自动验证的任务，与真实工作场景脱节。业界亟需一个多领域、抗污染、贴近实际开发流程的评估体系。

现有方法局限

现有基准存在三个关键技术缺陷：

• 数据污染严重：直接从 GitHub issue 或 commit log 改编任务，导致提示词可被搜索引擎反向追踪，模型可能通过记忆而非推理完成任务。
• 领域单一：大多聚焦代码补全或仓库级 bug 修复，忽略前端开发、办公自动化、安全攻防等真实工作负载。
• 评估机制脆弱：依赖文本匹配或 pass@k 等简单指标，无法衡量智能体在模糊需求、多步交互、安全约束下的综合表现。

为什么这个问题难/重要

• 任务构造需防回溯：每个任务需从真实 commit/PR 逆向设计，并重写为口语化角色扮演请求，确保提示词无法通过公开信息还原，这要求大量人工重写和领域知识注入。
• 跨域统一执行：代码、Web、办公、安全四个领域验证风格迥异（如 Web 需视觉回归测试，安全需对抗评估），需设计统一任务包格式和沙箱化执行协议，技术复杂度高。
• 业界高度关注：随着 Claude Code、CodeBuddy Code 等产品落地，企业需要能甄别智能体在“模糊需求理解”、“长上下文工程”、“安全合规”等真实场景下能力的基准，而不仅是比赛刷分。

类似自动驾驶需要城市道路实测而非封闭场地绕桩，编码智能体也需要分布匹配的多域工作台来检验其真实生产力。

核心洞察

• **逆向工程真实开发轨迹并改写成口语化角色扮演请求，构建了搜索不可恢复的任务提示，从根本上阻断基准泄漏。** 与多数代码智能体基准直接抓取公开 issue 文本不同，WorkBuddy Bench 从真实的 commit、PR 或业务场景出发，重写为简短、口语化的用户请求，使得任务提示无法通过搜索底层 issue 或 commit 恢复。这种污染抵抗策略不依赖闭源或保密，而是在开放数据集、环境镜像和评测代码的前提下，通过任务构建方法及其版本管理实现防泄漏，这比常规的动态生成或隐式分割更为根本且可审计。
• **全量开源与统一可重现的执行协议相结合，以版本控制而非秘密保证公平性，这定义了评测可信度的新范式。** 该基准提供完整的任务目录、环境镜像、评测框架和参考解决方案，任何第三方均可复现和审计每项任务。与之对照，大量业界基准仅发布部分内容或依赖隐藏测试集防污染。WorkBuddy Bench 的透明化策略不仅增强了可重复性，还让数据集版本化成为一种持续的抗污染机制，使得模型训练方无法简单通过下载旧版数据获取优势，这对工业级评测生态具有重要启示。
• **跨子集评分完全独立且不计算总平均，尊重了不同工作领域的不可通约性，避免了误导性的一维排名。** Code、Web、Office、Security 四个领域各采用专属的评分仪器（如 Oracle-gated 准入、规则-裁判组合、红蓝对抗验证等），得分在域间不具备可比性，因此作者明确不报告整体平均分。这一设计批判了当前主流评测中强行加权聚合的倾向，更真实地反映编码智能体在多样化工作场景下的局部优势，引导行业从“全能幻觉”转向按需选择的务实评估观。

方法

任务构造：从真实提交到防污染提示

WorkBuddy Bench 的每一道任务均逆向工程自真实的 Git 提交、Pull Request 或业务场景，而非直接引用公开 Issue 文本。构造流程如下：

1. 源素材提取：从实际代码仓库、Web 开发、办公自动化或安全攻防操作中捕获任务需求，确保分布 inform。
2. 重写协议：将需求转换成一段短小、口语化的角色扮演提示（如“帮我在这个项目里加一个缓存层”），故意保留不确定性（deliberate underspecification），模拟人类同事间的模糊请求。
3. 不可回溯性：重写后的提示无法通过 Web 搜索关联到原始 commit/PR 线索，从根本上防止基于检索的数据污染。

统一评估框架

• 任务目录格式：每个任务打包为独立目录，内含环境镜像、测试用例、参考方案和评分配置，确保任意第三方均可复现。
• 双代理运行：在 CodeBuddy Code 和 Claude Code 两个通用 Coding Agent 平台上执行，使用统一的沙盒和 API 连接协议。
• 分域评分：四个子集（Code、Web、Office、Security）各自采用独立的评分仪器：
  • Code：Oracle-gated 准入 + 基于测试的通过率；
  • Web：前端 UI 动作匹配与 DOM 校验；
  • Office：规则引擎 + 大模型判定复合打分；
  • Security：防作弊设计下的红蓝队对抗指标。 因评分标准不可直接比较，报告中不计算跨子集平均分。

防污染与开放性

数据集完全开放下载，凭借提示重写 + 数据集版本控制而非保密来抵御污染，版本命名规则允许追踪任务演化。这一机制使基准既能接受公开审计，又能长期保持评估有效性。

与同类工作的关键差异：不同于 SWE-bench 等直接从公开 Issue 改编任务的做法，WorkBuddy Bench 通过角色扮演式重写切断了提示与公开文本的链接，避免了因搜索匹配导致的分数虚高，同时坚持全开放生态，兼顾了可复现性与防污染需求。

实验

实验设计

Tencent WorkBuddy Bench 的实验设计围绕多领域统一评估框架展开。任务源自真实提交记录、PR 或业务场景，经反向工程重写为简短口语化提示，构成四个子集：

• Code：仓库级工程任务，含 Oracle 门控准入；
• Web：前端开发任务；
• Office：办公与业务流程任务，采用规则与判定复合评分；
• Security：红/蓝队安全任务。

所有任务遵循统一目录格式，在 CodeBuddy Code 和 Claude Code 两个代理框架上运行，使用可复现的沙盒执行协议。每个子集采用独立的评分工具，因此跨子集的分数不可直接比较，不汇报总平均分。评估覆盖多个模型家族，输出跨模型排行榜。

关键发现

• 多领域评分异质性：不同子集的评分机制差异显著（如代码任务的测试用例通过率、办公任务的规则判定），这导致同一个模型在各子集上的排名可能不同，凸显了单一维度基准的局限性。
• 抗污染的有效性：通过任务构建方法（不直接使用公开 issue 文本）及数据集版本管理，即使数据集完全开放，也能有效抵抗网络搜索导致的数据污染，保证了评估的公正性。
• 代理框架的影响：对比 CodeBuddy Code 与 Claude Code 两个代理执行环境，可观察不同代理架构对模型表现的影响，为代理选型提供参考。

与基线的对比解读

与传统编程基准（如 HumanEval、MBPP）相比，WorkBuddy Bench 的关键区别在于：

1. 任务来源与污染控制：传统基准常使用公开代码片段或问题描述，易被模型记忆；WorkBuddy 的任务从非公开的提交/业务需求重新生成，且发布后通过版本化避免搜索泄漏，对模型真实泛化能力要求更高。
2. 评估广度：覆盖仓库级工程、前端、办公自动化、安全攻防四个实际工作领域，而非仅代码生成，更能反映编码代理在现实复杂场景下的综合能力。
3. 执行环境：提供了完全可复现的沙盒与统一的代理接口，标准化了评测流程，增强了结果可审计性。该基准为编码代理的多维评估设立了新范式，尤其适合考察模型在真实工作流中的实用性。

行业影响

落地场景

Tencent WorkBuddy Bench 是一套针对 Coding Agent 的多领域评测套件，覆盖 Code、Web、Office、Security 四类真实工作场景。其任务构造直接从实际 commit、PR 或业务场景逆向生成，可评估智能编程助手在以下产品形态中的能力：

• IDE 编程插件（如 GitHub Copilot、CodeBuddy）：代码仓库级重构、特性开发、安全修复等任务。
• 低代码/无代码平台：根据自然语言描述生成前端页面、Office 文档自动化（Excel 数据处理、PPT 生成）。
• 安全运营中心（SOC）：红蓝对抗中的漏洞挖掘、渗透测试或日志分析，适用于 AI 安全分析师。
• 企业 RPA/自动化工作流：Office 与业务流任务可直接映射到财务、HR 等部门的报表生成、邮件自动化。

商业价值

该基准直接服务于 AI 编程工具的产品迭代与选型决策，通过标准化评测降低客户试错成本：

• 降本：自动评估替代人工评审，加快模型/Agent 选型与回归测试，减少内部 QA 人力投入。
• 增收：为 Coding Agent 供应商提供“性能标尺”，支撑对外营销与竞品分析，加速客户采纳。
• 体验提升：通过防污染任务构造（contamination-resistant），确保评估客观性，避免模型“背诵”公开代码，推动 Agent 在真实业务场景下的实用体验。

排行榜不设跨子集平均分，避免“刷榜”误导，更贴近实际工作中各领域独立择优的需求。

与现有产品/工作流接口

• 统一任务目录格式：所有任务打包为标准化目录（含环境镜像、评测 harness、测试用例、参考方案），可直接接入 CI/CD 流程，例如在 Jenkins 或 GitHub Actions 中实现 Agent 的自动化回归评测。
• 模块化 Harness 后端：支持 CodeBuddy Code 和 Claude Code 两种 Agent harness，并公开完整的执行协议，第三方可轻松添加新 Agent 框架（如 LangChain、AutoGPT）。
• 版本化发布：任务集带版本命名，可配合 模型版本与数据集版本联动，形成持续评测的工程 pipeline。

具体落地用例

1. 电商平台智能开发助手：某电商平台自研 Coding Agent 辅助前端团队开发促销活动页。使用 WorkBuddy Bench 的 Web 子集 评估 Agent 根据简短角色扮演式需求生成 HTML/CSS/JS 的能力，通过全自动化运行 50+ 任务，3 小时内即可给出 Agent 在前端开发上的多维度得分（布局正确性、交互逻辑、响应式适配），并识别出在“动态表单生成”等子场景的短板，从而针对性微调模型。

2. 安全厂商 AI 渗透测试工具：一家安全公司推出基于 LLM 的自动化渗透测试产品。使用 Security 子集（红蓝对抗）构建内部 CI，每次新模型版本发布前，自动执行防御绕过、漏洞挖掘等任务，并以该子集的专用打分器（如漏洞利用成功率、隐蔽性检测）量化性能，防止模型在公开 CTF 数据上过拟合，确保产品在面对真实企业网络时的有效性。

局限

• **跨子集分数不可比且无整体指标**，削弱了基准的综合评估能力。由于四个子集（Code、Web、Office、Security）各自采用不同的评分工具与验证逻辑，得分仅在子集内可比，无法汇总为全局排名。这对需要快速对比多个模型综合能力的技术决策者并不友好，而多数同类基准（如 SWE-bench）至少提供单一主指标。此外，子集间难度未校准，导致某模型在某子集的优势可能被评分差异淹没，基准的实用指导价值因此受限。
• **开放发布模式下的污染抵抗性存在实际风险**。虽然任务构造通过逆向工程和口语化重写避免了直接搜索泄露，但完整发布任务目录、环境镜像、测试用例甚至参考解决方案，意味着模型开发者可能将整个基准纳入训练数据。宣称的“版本控制”仅能对抗未来版本，但固定版本的训练仍可作弊；真正防污染需依赖社区诚信，这对大规模商业模型评估的公平性构成潜在威胁。
• **任务构造与评估覆盖存在主观性与泛化局限**。所有任务均由真实提交/业务场景经人工重写为角色扮演请求，这一过程引入主观判断（如口语化程度、缺失信息的设计），可能导致难度不一致，且难以系统性控制分布。同时，基准仅覆盖四个领域，缺少数据科学、ML 工程等常见编程代理场景。此外，目前仅在两款代理框架（CodeBuddy Code 和 Claude Code）上验证，对其他流行代理（如 AutoGPT、Devin）的泛化性未经验证。