用 WorkBuddy Bench 评估 AI 编程智能体

 

 

腾讯 WorkBuddy Bench 团队（优图实验室、科恩安全实验室、WorkBuddy、云鼎安全实验室）近期推出了一套编程智能体评测基准。该基准包含 260 个任务，覆盖代码工程、前端开发、办公工作流和安全攻防四大领域。

 

这套基准具备三个核心特征：任务并非直接复制公开 issue，而是从真实的 commit、PR 与业务场景中逆向工程得来；整个数据集完全开源，支持复现与审计；评测在 CodeBuddy Code 与 Claude Code 两个框架下，对 7 个大模型进行了测试。

 

 

评测到底覆盖了哪四种工作边界

 

在真实的企业环境中，编程智能体的职责早已超越了单纯的修改代码。同一个智能体往往需要兼顾搭建 Web 前端、生成与核对办公文档，甚至要分析安全工件。WorkBuddy Bench 将这些工作划分为 Code、Web、Office、Security 四大类别。这四类任务共享同一套任务目录格式、准入协议与执行基础设施，但各自配备了独立的评分工具。因此，不同子集的分数无法横向比较，该基准也不提供综合的套件级平均分。

 

 

所有类别下的任务形态保持高度一致：将智能体部署在一个工作区中，通过自然语言指令驱动其产出对应工件，最后交由智能体未知的验证器进行打分。

 

1. Code 类，80 个任务

 

主要考察智能体在完整的开源仓库中执行真实工程请求的能力。任务提问被细分为五种角色：开发者 30 个、算法工程师 19 个、产品经理 15 个、运维 10 个、QA 6 个。基于同一个仓库，不同角色的提问方式截然不同，这更贴近真实业务场景中“谁在问、为什么问”的差异化需求。

 

任务类型分布十分广泛：80 个任务中仅有 10 个属于 bug 修复，其余 70 个涵盖了功能与接口开发、代码工程、测试、算法工程以及产品数据分析。难度评级采用 L-ladder 标准，从 L2（小型、少量模块）一直延伸到 L5（大型多模块代码库），整体重心落在 L4。任务的主要难点在于跨模块探索，即需要先定位“在哪改”，而不是直接研究“怎么改”。评分依据隐藏单元测试的通过率，取三次运行结果的平均值。

 

2. Web 类，70 个任务

 

重点检验模型能否交付真正可运行、可校验的前端工件，而非仅仅生成一段看似合理的 HTML 代码。在七大类任务中，页面交互（21 个）与数据可视化（15 个）占比最高，其余任务涵盖了视觉设计、前端项目分析、代码测试、页面实现与文档转换。任务生命周期包含六种模式：从零构建（From Scratch）35 个、Bug 修复 8 个、功能扩展 8 个、审查与分析 7 个、测试生成 7 个、格式转换 5 个。其中有一半任务并非从零开始，这一设计有效避免了过度偏向只懂新建、不懂维护的模型。

 

在交互与状态复杂度方面，25 个任务为非交互式，45 个任务要求交互或状态维持，具体细分为单流程状态变更 15 个、持久化或离线及跨状态行为 13 个、多步骤工作流 9 个、轻量交互 8 个。评分环节在 786 个评分项上展开：包含 62 个确定性规则检查、676 个 LLM 或 VLM 评判器项，以及 48 个智能体评判器项。

 

3. Office 类，50 个任务

 

 

主要考察智能体在包含多种格式文件的本地工作区中，能否顺利完成自然语言下达的办公请求。输入文件格式包含电子表格、文档、PDF、JSON 导出、Markdown 笔记与文件树结构；输出结果则要求是更新后的工作簿、分析报告、结构化记录、状态文件与交接材料。在任务类型上，数据与电子表格等结构化处理占 24 个、文档报告与演示占 17 个、工作区自动化与状态化工作流占 9 个。评分采用确定性规则检查与基于证据的 LLM 评判器相结合的方式，两项得分独立记录，最后根据任务的预设权重进行合并。

 

4. Security 类，60 个任务

 

 

任务全面覆盖了安全团队的日常工作谱系。该赛道完全摒弃了 LLM 评判器，每个任务均配备确定性的评分程序。其背后依托五层反作弊基础设施：禁止字面量扫描、重命名输入测试、覆盖或篡改测试、编码依赖测试，以及低权重诱饵字段。

 

任务从哪来，又凭什么抗污染

 

每一个任务都有真实的来源依托：Code 赛道取材于开源仓库的历史 commit 或 PR（34 个）、净室实现（24 个）或完全合成的工作区（22 个）；Web 赛道来源于真实业务场景；Office 赛道基于任务规范或抽象办公工作流构建；Security 赛道则取材于真实历史 CVE 或安全运营场景。

 

实现抗污染的关键步骤在于改写协议：任务绝不会采用中规中矩的 issue 标题或教科书习题形式。原始上下文会经过逆向工程处理，被改写为简短、口语化且略带模糊的自然语言请求，读起来就像是同事或客户随口一提的问题。指令中既不包含根本原因，也不提供参考差异，更不会把现成的解法直接推送给智能体。

 

以一道 Code 类任务（产品经理视角）为例：“结账文案实验结束了；我想首先知道新版本是否更好。数据中有展示和购买事件。请计算每组的转化率、收入和一个简单结论，并且不要计算很久之后才发生的购买。”这句话点明了意图与约束，却没说数据文件叫什么、模式是什么、归因窗口设多长，全得由智能体自己从工作区里把上下文找回来。

 

这种编写方式在任务构建阶段就切断了可搜索的提示路径。没有任何一道任务的指令文本能靠网页搜索还原出底层的 issue、PR 或 commit 线索。论文中也提示，由于数据集完全公开，这种抵抗力需要靠数据集版本控制来兜底，应对办法不是隐藏，而是定期刷新并重新版本化。

 

“刻意保留的不完整说明”是这套评测标准的核心设计之一：在四类任务中，请求的描述往往不够详尽，通常会隐去目标文件或模块、确切的模式或接口、边界情况的处理，以及变更的确切范围。补齐这些信息缺口本身就是任务的关键环节。智能体必须学会从工作区中找回缺失的上下文，并据此建立合理的假设，而不是被手把手指导。这里考验的是需求消歧与信息落地能力，其重要性毫不亚于代码生成本身。

 

行业为什么还需要一个新基准

 

回归到评测体系本身，目前行业现状处于两个极端。一端是 SWE-bench 等静态公开基准：任务集发布后便固定下来，问题描述和答案在网络上广泛流传，分数的上涨可能仅仅是因为模型“背题”了。此外，这类任务类型极其局限，绝大多数属于单 issue 的 bug 修复，远无法覆盖真实工作中智能体需要承担的各项事务。另一端是 CursorBench 等厂商生产环境基准：任务虽然取自真实的用户会话，分布也贴合实际使用情况，但基准本身并不开源。外部既无法检查任务分布情况，也无法排除对厂商自家智能体可能存在的选择偏差。

 

Tencent WorkBuddy Bench 选择了第三条路径：以真实工作需求来指导任务分布，通过“重构构建”而非“信息保密”来抵抗数据污染，并坚持全面开放发布。

 

评测怎么跑，结果怎么读

 

评测工作在 CodeBuddy Code（cbc）和 Claude Code（cc）两个框架下开展，开启 think 模式，每个任务独立运行三次并取平均值。

 

 

以下几个核心结论较为关键：

 

 

1. 没有哪个模型能在所有类型上通吃。八种类型任务里，Claude Opus 4.8 领先五类，GLM-5.2 领先两类（均为 Security），GPT-5.5 领先一类（cc 框架下的 Office）。
2. 开源模型 GLM-5.2 在 Security 上拿下双框架第一。在这套基准上，开源权重与闭源前沿之间的差距是“看任务类型”的，并非一刀切。
3. 框架本身不是中性的测量工具。Security 赛道在框架间重排最剧烈，七个模型平均绝对偏移 8.6 分；GPT-5.5 从 cbc 下的第六名跳到 cc 下的第二名。
4. 编程任务与数据 / 算法任务拉开差距。模型在数据与算法风格任务上的得分几乎一致地高于编程任务（平均约 74% 对 65%）。最难的 Code 子类是 bug_fix（均值 0.47）与 api_contract（均值 0.47），对应真实仓库的回归修复和严守契约的接口工作。
5. 开源权重模型并未落伍。GLM-5.2 在两个 harness 下都领跑 Security（拿下八个计分列中的两个），在 Claude Code 的 Code 榜上也只落后榜首不到一分，竞争力因榜单而异，并非全面碾压。
6. Harness 本身就是结果的一部分。同一模型换框架可能大幅波动：GLM-5.2 在 Web 上 67.43 对 60.71，GPT-5.5 在 Security 上 77.91 对 64.39，分数必须按 harness 分开看。
7. 接入细节会左右成绩。一次诊断性复跑中，给 HY-3 打开跨轮推理回传后，其 Code 分数提升 +3.82（CodeBuddy Code）/ +1.92（Claude Code）。

 

 

谁花最少的钱干最多的事

 

 

在节约成本方面表现最突出的模型是 GPT-5.5：在 CodeBuddy Code 框架下，它处理每一类任务消耗的 token 数都是最少的（Code 单次运行 6.9k、Web 13.5k、Office 10.2k、Security 7.5k），同时整体分数依然维持在顶尖水平。

 

相比之下，DeepSeek-V4-Flash 在 Claude Code 下的输出量约为 GPT-5.5 的 3.3 倍（28.6k 对 8.7k），但分数却低了约 15 分。目前，相关论文与数据集已在 arXiv、GitHub 与 Hugging Face 平台公开，第三方机构可以重新运行每一个任务并直接审查具体内容。

 

理解这套基准的评测逻辑，能帮你更客观地判断 WorkBuddy 在编程智能体上的真实表现。如果你正在为团队评估企业级 AI Agent 的选型与落地，可以直接找云巴巴聊聊。云巴巴是腾讯云 AI 智能体示范伙伴、腾讯 WorkBuddy 核心伙伴及官方授权服务中心，汇聚了 WorkBuddy、千问办公、TRAE Work 等多家主流 Agent 工具与方案，能结合你的数据边界、任务形态和团队能力，从选型对比、方案验证到陪跑落地提供一站式服务。欢迎咨询云巴巴，获取专属的 Agent 实施落地方案。