爆火的腾讯WorkBuddy发了篇论文，公开了自家底牌

继上次的分享：11000 star，吴恩达开源版WorkBuddy，牛了，今天分享一篇腾讯WorkBuddy团队最新发表的论文，他们给自己造的内部尺子，现在把它开源了。

这篇论文不是孤立的学术工作，而是 WorkBuddy 产品工程的副产品——把内部的模型选型评测、Harness 回归测试、任务分布洞察打包成一个开源 Benchmark。腾讯把多模型 Agent 工作台的选型底牌摊开了——GLM-5.2 在安全域双杀闭源模型、GPT-5.5 最省 token、Claude Opus 综合最强，这些数据直接解释了 WorkBuddy 为什么要做多模型切换而不是绑定混元。提速500倍，29s学会一个新Skill，清华和自变量开源HOST框架

一、WorkBuddy优势

WorkBuddy Bench 优点：任务分布对齐真实工作（distribution-informed），但完全开源可审计。

四个子集各有独立的评分仪器，分数跨赛道不可比，套件刻意不报总平均分——这是设计决策，不是缺陷。

表1：套件一览（四个子集，双 Harness 评分）

二、核心方法论：抗污染来自真实业务

论文把提示词可被搜索引擎找到视为最重要的污染路径，然后在任务生产环节就把它堵死：

表2：开源清单——运行、评分、审计一个任务所需的一切全部公开

• 任务来源：每个任务锚定一个真实上游工件（开源仓库的历史 commit / PR、真实 CVE）或具体业务场景。匹配的不是原始请求本身，而是内部使用分布（查询意图类别、请求结构模式）——任何原始用户 prompt、会话数据都不进入任务。
• 改写协议：逆向工程后改写成简短、口语化、刻意欠规格（underspecified）的请求。Code 赛道还通过五种角色发声（开发者、算法工程师、产品经理、QA、运维）。
• 刻意欠规格：请求只给意图和约束，不给目标文件、接口定义、边界情况——Agent 必须自己从工作区里找回缺失的上下文。这考的是需求消歧与 grounding，而不只是代码合成。
• 赛后评测隔离：评分资产在 Agent 行动期间完全不可见，结束后才注入沙箱。“Hidden tests”指的是解题时不可见，而非发布后保密——全部测试随开源一起放出。

三、四大赛道拆解

3.1 Code：80 个任务里只有 10 个是修 Bug

Code 子集把 Agent 扔进一个 checkout 到基线 commit 的完整开源仓库，要求它自己定位代码、改完、并保证隐藏测试通过。和 SWE-bench 最大的不同是角色与任务类型多样性：五种角色、18 个细分类目，Bug 修复只占 10/80。

表3：Code 子集来源家族（A=34，B+C=46）

表4：Code 子集构成（80 任务开源版）

准入门机制值得一提：每个候选任务先对未改动的工作区跑一遍验证器（baseline reward 必须 ≤ 0.3，证明任务不是”白给”），再打上 gold patch 跑一遍（oracle reward 必须 = 1.0，证明任务可解）。构建期的早期评测还暴露了两类零分模式：Agent 陷入改测试文件的死循环直到超时；在大仓库里迷路、改了完全不相干的文件——难度来自导航与定位，而非代码合成。

3.2 Web：交付物契约——说得再好，路径下没有可运行工件就是零分

Web 子集的硬核设定是 artifact-not-chat 契约：Agent 必须在声明的输出路径产出可运行工件（如 HTML 入口），聊天里写得天花乱坠但路径下没东西，直接挂。70 个任务横跨生成、修改、分析、质检四类前端工作。

3.3 Office：评的是最终工作区状态，不是答案文本

Office 子集测的是混合格式文件（表格、文档、PDF、JSON、Markdown、文件树）里的完整工作交接。评测盯的是最终工作区状态——写了一份看似合理的总结却没更新它描述的那张工作簿，照样丢分，这是纯文本评分抓不到的失败。

评分是双通道：确定性 Rule checks 验证文件、schema、数值、跨文件关系、状态变更、副作用边界；LLM Judge 基于任务结束后生成的固定证据评估二元语义 rubric，不看实时工作区、也不能改写 Rule 结果。每个任务预配自己的 Rule 权重 w_i ∈ [0.70, 0.95]。

3.4 Security：60 个任务全程无 LLM 裁判 + 五层反作弊

Security 子集覆盖红蓝队全景：漏洞发现与安全利用（32，红）、恶意软件分析（14，蓝）、安全运营（8，蓝）、Agent 安全（6，红）——38 红 vs 22 蓝，难度刻意偏硬。

白盒审计任务复现 binutils、curl、nginx、vim、jq、fluent-bit 等广泛部署项目的真实历史 CVE，采用 find-vuln → poc-verify 两步结构：先读源码定位漏洞路径（过阈值才解锁第二步），再提交能在沙箱里稳定触发 ASAN crash 的 PoC。

表5：Security 子集构成（60 任务，四块粒度）

四、榜单结果：没有全能冠军，Harness 一换排名就洗牌

表6：WorkBuddy Bench 总榜（0–100，think 模式，三次运行均值）

八块榜三分天下：Opus 4.8 拿五块（Code 双榜、Web 双榜、Office cbc），GLM-5.2 以开源权重身份拿下 Security 双榜——开源与闭源的差距是分板块的，不是均匀碾压；GPT-5.5 拿 Office cc 一块。

Harness 敏感性的几个爆点：

• Code 排名在双 Harness 间直接换位：GPT-5.5 在 cbc 下领先 GLM-5.2（72.90 vs 71.54），在 cc 下被反超（76.63 vs 77.06）。
• Security 洗牌最狠：七模型平均绝对位移 8.6 分；GPT-5.5 从 cbc 第六蹿到 cc 第二，MiniMax-M3 从第二跌到第五。
• Office 最稳：七个双跑模型里五个位移不到 2 分（中位数 0.86）。
• 工程细节能值 4 分：HY-3 开启跨轮 reasoning passback 后 Code 分数 cbc +3.82、cc +1.92。
• 拒答也值得记录：Opus 4.8 在 Claude Code 下对安全任务出现 13 次任务级拒答（cbc 下为零），GPT-5.5 在 cbc 下 2 次。

最难的类目暴露了真问题：Code 子集里最难的是 bug_fix（均值 0.47）和 api_contract（0.47）——真实仓库的回归修复和严守契约的接口活；最易的是 feature_pipeline（0.94）和 testing（0.88）。product_analytics 类目模型间差距几乎拉满 0–1.0 全程：高分模型会正确推断”别把隔很久才买的算进来”这个隐含归因窗口，低分模型代码跑得干干净净但把全部购买都算了进去——差距完全在业务语义理解，不在代码能不能跑。另一个典型失败是”语义对但契约错”：行为合理却丢了一两个必需字段（如 OpenAPI 的 deprecated、examples），验证器一打 per-field 布尔检查就连环清零。

表7：Code 子集每轮开销（轮次 / 输出 token / 含缓存输入 token，千为单位）

花钱多 ≠ 分数高：DeepSeek-V4-Flash 在 cc 下输出约为 GPT-5.5 的 3.3 倍（28.6k vs 8.7k），分数却低 14.74 分；GLM-5.2 的 cc 榜首成绩 77.06 花了 22.0k 输出 token，而 GPT-5.5 只用 8.7k 拿到 76.63。GPT-5.5 是全场四赛道一致的”最省高分者”（cbc 下 Code 6.9k / Web 13.5k / Office 10.2k / Security 7.5k 输出）。Security 是最重的赛道（30–89 轮/次），MiniMax-M3 在 cbc 下平均 88.8 轮、约 11.1M 含缓存输入 token 换 74.14 分。

六、与现有工作的对位

表8：Web 方向 Benchmark 能力矩阵（∙ 全覆盖，◦ 部分覆盖，空白 未覆盖）

这些是自报的设计期对比，不是跨榜单实测。差异化在于广度与框架而非新任务类型——Security 子集是公开 Benchmark 稀缺的红蓝全覆盖 + 全确定性评分；Office 把混合格式多交付物工作流当”完整交接”来测；Code 用五角色 + 18 类目跳出”修 issue”框架。