腾讯 WorkBuddy Bench：抗数据污染的多领域代码智能体基准测试套件 Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction

完整步骤如下。Sourcing：每个任务锚定到一个具体来源——Code 有 34 个真实 OSS snapshot 上游 commit（Family A）、24 个 clean-room 类库重实现（Family B，含 4 个 JS/TS/Rust 移植到 Python）、22 个全合成带 CSV/JSON fixture 的工作区（Family C）；Security 白盒任务锚定真实历史 CVE；Web/Office/部分 Code 与 Security 用业务场景。配比对照内部用法分类学（请求意图类别与请求结构模式），但绝不复用原始用户数据。Rewriting：把原始上下文写成同事/客户的口语化、欠规范请求，Code 套上 5 种角色（developer 30、algo 19、pm 15、ops 10、qa 6），Security 每域配专业角色，请求故意省略目标文件、精确 schema、边界处理，逼智能体自己从工作区恢复上下文。组装与隔离：构建 Docker 镜像，agent episode 期间只见 instruction 与声明工作区。准入校验（Code）：未改基线 baseline reward $\le 0.3$，套 gold patch 后 oracle reward $= 1.0$；Web/Office/Security 各有子集特定校验（如 Web 786 项 rubric、Office 每题 Rule/Judge 权重 0.70–0.95、Security 五层防作弊）。打包发布：task.toml/instruction.md/environment/tests/ 全量公开，grading 测试与 gold patch 也一并发布。执行：两次 harness 下 think 模式、3 次独立 run 取均、reasoning effort 固定 high、上下文窗口统一 200k、关闭 WebSearch 与 AskUserQuestion 工具。打分公式：任务级奖励 $r_t \in [0,1]$，轨道分 $S = \frac{1}{|T|}\sum_{t \in T} r_t$；Web 失败项扣配置罚分（0.1/0.2/0.3），致命失败置零；Office 三试取均后做 50 题等权宏均；Security 三次独立 run 取均。

技术新颖性体现在'把分布、抗污染、可审计三者用一套构造协议同时满足'。与 LiveCodeBench 靠'题目发布晚于训练截止'抗污染不同，本文靠'重新构造的任务目录'在写作时刻就关闭可搜索路径，并在发布后用版本管理接力。与 CursorBench 闭源真实会话不同，本文分布匹配的是分布而非数据本身，因此可全量开放、可逐题审计、可证伪厂商偏置。Security 子集的'零 LLM 裁判 + 五层防作弊（banned-literal 扫描、renamed-input 测试、overlay/tamper 测试、encoding-dependence 测试、低权重诱饵字段）'在公开安全基准中罕见，把输入/代码/输出三条轴上的硬编码与穷举都堵住。Code 用诊断性 gold patch 做准入而非评分（任何满足隐藏测试的补丁都拿满分），并把 LLM-Judge 分明确隔离为参考值、绝不进头条分，是对'裁判偏置'最干净的处置。Web 把规则检查、LLM/VLM 判、Agent-Judge 驱动运行产物三类判分绑定到从最终产物抽取的证据上，是对前端评测'闭环工程'维度的扩展。整体上，新颖性是广度+构造哲学而非新任务类型，作者亦坦承这一点。

第一个弱点是 Security red/blue 比例失衡（38 红 vs 22 蓝）且刻意偏难，对'日常检测/运维'类能力的代表性不足；改进方向是补足蓝队检测工程与 SOC 日常任务的覆盖，使难度更贴近真实分布而非研究级攻防。第二个弱点是 Code 单语言偏 Python，结论外推风险高；改进方向是引入原生多语言任务目录（直接在 JS/TS/Rust/Go/Java 仓库里造题），而非'移植到 Python'。第三个弱点是榜单格存在修改指令配置（Claude Opus 4.8 Code-cc），破坏可比性；改进方向是按作者近计划，把该格纳入标准指令协议。第四个弱点是 Office 文本优先、缺 OCR/VLM/GUI，无法覆盖真实办公中的截图、扫描件、桌面交互；改进方向是新增视觉-办公任务与原生 GUI 操控任务。第五个弱点是后发布污染无根治手段；可改进为引入更细粒度的 canary 检测 + 自动化污染体检 + 更高频版本轮转，并把'被污染任务'纳入退役流水线。第六个弱点是裁判偏置未量化；改进方向是做多裁判交叉验证（不同家族裁判一致性）、引入裁判自评偏置基线、并对 Office Judge 做 ablation。第七个弱点是 Security 轮次/Token 计数口径不一致；改进方向是统一为'唯一助手消息'口径以与 Code 可比。第八个弱点是作者自承'这些比较是设计期定性自述而非实测跨套件 agent 对比'，缺乏与 SWE-bench/CursorBench 的同模型同 harness 实测；改进方向是做一个跨套件的桥接评测。

作者近计划明确两项：一是继续 Web rubric 校准；二是在可行时把唯一的修改指令配置（Claude Opus 4.8 在 Code under Claude Code）纳入标准指令协议。中长期路线是建设公开榜单，持续扩展两 harness 下的模型覆盖。基于本成果可延伸的方向包括：（1）多语言原生 Code 子集与跨语言编码难度研究；（2）把'分布知会'方法论扩展到更多业务域（数据分析、运维 SRE、数据工程），形成更长尾的工作分布匹配；（3）对 harness 敏感性本身做系统性研究——既然同一模型在两 harness 间 Security 可移 8.6 分，可设计'harness 无关能力'指标或 harness 归一化；（4）把 Security 的零裁判 + 五层防作弊范式迁移到 Code/Web 的判分，进一步压低裁判偏置；（5）加入多轮、长时程、人机协作（human-in-the-loop）任务，测试 agent 在真实组织里的'交接'能力；（6）建设自动化污染监测与版本轮转流水线，量化开放发布的污染衰减曲线；（7）跨套件桥接评测，把同模型同 harness 在 WorkBuddy Bench、SWE-bench、CursorBench 上的表现并列，检验分布外泛化。

复现性是本套件的卖点之一，评级为高。它以 SWE-bench 风格全量开放：任务目录骨架与打包规范、任务 prompt 与指令文本、工作区/环境镜像（支持离线第三方测试）、评测 harness 与分数聚合代码、grading 测试（即 solve 时对 agent 不可见、但发布时公开的验证器）、gold patch 与参考解、每任务及聚合分数与公开榜单——全部发布。唯一不发布的是用户数据，且是'因为根本没用所以没有'，而非'有但藏起来'。任何第三方无需特殊访问即可复跑单题并审计内容。可复现的工程门槛在于：每个任务需在隔离 Docker 容器内执行（自带 Dockerfile 与 setup.sh），两 harness（CodeBuddy Code 默认、Claude Code 备选）需各自能直连或经本地代理连模型后端，代理只做协议转换/模型名改写/请求日志；远端沙箱时禁止把基准侧代理放进沙箱，唯一无法满足该分离的'sandbox 后端 × 连接模式'组合被直接禁用而非静默回退。算力方面，Security 最重（MiniMax-M3 在 cbc 单 run 88.8 轮、约 11.1M 输入 token），Office 最轻（16–42 轮、10–30k 输出 token），完整跑一遍 8 块榜（7 模型 × 4 轨 × 2 harness × 3 run）成本不低，但单题复跑成本可控。需注意的复现陷阱：分数绑定本次所用两 harness 的具体构建、模型 serving 端点（HY 一方直供 vs 其余第三方）与采样超参，故'复现'应理解为'协议级 + 任务级可复跑'而非'数字逐位一致'。