Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction 精读

论文链接：Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction 代码仓库：github.com/Tencent/workbuddy-bench 排行榜：workbuddybench.com 数据集：huggingface.co/datasets/tencent/workbuddy-bench 发表时间：2026年7月 机构：腾讯（优图实验室、朱雀安全实验室、WorkBuddy 产品团队、云鼎安全实验室联合出品） 领域标签：编码智能体评测、Benchmark、Agent Harness

一、论文背景

1.1 编码智能体（Coding Agent）是什么

在理解这篇论文之前，需要先弄清楚"编码智能体"究竟是什么。

编码智能体不是简单地将"帮我写个排序算法"这种请求翻译成代码的插件。它是一种自主软件工程系统——给它一个自然语言的任务指令（就像同事给你提的需求），它能自主完成：理解需求 → 在代码仓库中定位相关文件 → 规划修改方案 → 编辑代码 → 运行测试 → 验证结果 → 提交修改。整个过程不需要人一步步指挥，智能体自己决定每一步该做什么。

目前业界最具代表性的编码智能体包括 Claude Code、CodeBuddy Code、OpenHands、Cursor 等。它们已经在真实的软件开发流程中承担越来越多的工作，从修 bug 到实现新功能，甚至处理跨多个文件的仓库级工程任务。

1.2 如何衡量编码智能体的能力——基准测试（Benchmark）

既然编码智能体越来越强，我们就需要一个公平的标尺来衡量"它到底有多好"。这就是**基准测试（Benchmark）**的使命——一组标准化的任务集，所有智能体在同样的任务上比拼，用统一的评分规则打分，排出高低。

这听起来简单，但构造一个好的基准测试极其困难。核心矛盾在于：任务要足够真实（否则测出来的分数没有说服力），但又必须公开可审计（否则没人信你的分数）。 而一旦任务公开真实，下一个问题就来了——

1.3 数据污染（Data Contamination）：当前基准测试的根本缺陷

这是本文要解决的核心痛点。数据污染指的是：基准测试的任务（问题描述、参考解决方案）在模型训练时就已经被模型"看过了"。当模型在基准测试上拿到高分时，我们无法分辨这究竟是因为它真正学会了推理，还是仅仅因为记住了答案。

这绝非杞人忧天。搜索调研中发现的一系列研究已经给出了铁证：

• Aleithan 等人的研究表明，SWE-Bench 中 94% 的实例创建时间早于主流大模型的训练截止日期，意味着这些 issue 极大概率已被纳入预训练语料。他们在剔除这些污染样本后构造的 SWE-Bench+ 上，解题率大幅下降。
• Zhou 等人量化发现，SWE-Bench Verified 对 StarCoder 等开源模型存在 10.6% 的数据泄露率，因为其数据来源 GitHub issue 恰好是 StarCoder 预训练语料的一部分。
• 最有力的证据来自一个"逻辑不可能"实验：研究者故意只给 Claude 模型 issue 文本（不给任何代码库上下文），让它去定位需要修改的文件——这本应是不可能完成的任务，但 Claude 在 SWE-Bench-Verified 上的文件定位准确率，竟是在类似但未被污染的数据集（BeetleBox、SWE-rebench）上的 3 倍。唯一的解释就是：模型记住了这些任务。

1.4 现有基准测试的两大阵营及其困境

也就是说：公开的容易被记住，封闭的没法被审计。 这就是 WorkBuddy Bench 试图打破的困局。

二、论文定位和关联工作

2.1 代码智能体基准的演进脉络

WorkBuddy Bench 并非凭空出现，它站在一条清晰的演进线上：

第一代：单点能力测试

• HumanEval / MBPP：函数级代码生成，给一个函数签名和文档串，生成函数体。粒度太细，无法反映真实工程。
• RepoBench：仓库级补全，关注代码片段预测而非完整任务解决。

第二代：仓库级问题解决

• SWE-bench [Jimenez 2024]：里程碑式工作，从真实 GitHub issue 出发，要求智能体定位并修复 bug。但它的问题描述直接来自 issue 文本，可被网络搜索恢复，成为污染的重灾区。
• SWE-bench Verified：500 人工筛选子集，成为事实标准，但污染问题依旧。
• Commit0 [7]：库从零开始的基准，使用测试驱动规范。
• LiveCodeBench [8]：依赖模型训练截止日期后发布的问题来避免污染，思路巧妙但任务类型受限。
• SWE-rebench：持续更新的 SWE-bench 变体，用"新鲜度"对抗污染。

第三代：生产化与多领域

• Vibe Code Bench [12]：评估零到一的 Web 应用开发。
• CursorBench [5]：追踪提交代码到原始代理请求，任务分布最真实，但封闭源码。
• Terminal-Bench [11]：通用终端代理能力评估。

2.2 各垂直领域的关联工作

WorkBuddy Bench 横跨四个领域，每个领域都有垂直基准：

Web/前端领域：Design2Code [3]、Interaction2Code [13]、FrontendBench [14]、WebArena [4]、VisualWebArena [15]。论文给出的能力矩阵（表 8）显示，这些基准大多只覆盖"从零生成"和"部分能力"，没有任何一个同时覆盖 WorkBuddy Web 所具备的全部 12 个能力维度（UI、App、Data、Doc/Test、Scratch、Fix/Ext、Review/Convert、Action、State、Rule、VLM、Agent）。

Office 领域：Workspace-Bench 1.0 [16]（大规模异构文件）、ClawsBench [17]（Gmail/Calendar/Docs 模拟）、OdysseyBench [18]（多应用工作流）、SpreadsheetBench 2 [19]（多表工作簿）。

Security 领域：Cybench [20]（专业 CTF）、NYU CTF Bench [21]、InterCode-CTF [22]、CVE-Bench [23]（自主利用真实 CVE）、CyberSecEval 系列 [24,25]（评估模型自身的安全风险）。

2.3 本论文在研究脉络中的定位

定位结论：WorkBuddy Bench 是首个将"抗污染构建方法"与"完全开放审计"同时实现的多领域编码智能体基准。它不是对 SWE-bench 的增量改进，而是在抗污染的方法论层面和领域覆盖的广度层面的双重跃迁。

三、问题定义

3.1 从具体场景到本质问题

论文面对的具体场景是：如何为编码智能体构造一个既真实又公平的评估基准。但我们需要抓住它的本质。

核心洞察：现有基准的根本矛盾可以抽象为——“可搜索性"与"真实性"之间的耦合。一个任务越是真实（来自真实的 GitHub issue、真实的 CVE），它的描述文本就越容易在网络上被找到，就越容易被模型在训练时记住。

3.2 形式化的问题定义

给定：

• 一个任务来源空间 $\mathcal{S}$（真实 commit、PR、CVE、业务场景）
• 一个智能体能力空间 $\mathcal{A}$
• 一个评估函数 $\mathcal{E}: \mathcal{A} \times \text{Task} \to [0, 1]$

求：一个任务构造函数 $f: \mathcal{S} \to \text{Task}$，使得：

1. 分布保真：$f(\mathcal{S})$ 的任务类别和难度分布匹配真实的内部使用分类法（即测的是智能体实际会遇到的活，而非人为制造的偏科任务）
2. 抗搜索恢复：对于任意任务 $t = f(s)$，不存在高效的搜索程序能从 $t$ 的提示文本恢复出源工件 $s$（即模型不能通过"上网搜原始 issue"来作弊）
3. 可审计：$f$ 的全部产物（任务目录、环境、测试、参考方案）可公开发布
4. 评分有效性：$\mathcal{E}$ 能区分智能体的真实能力差异，而非区分记忆能力

这个定义的精妙之处在于约束 2 和约束 3 的看似矛盾——“抗搜索恢复"要求任务提示不暴露来源，而"可审计"要求所有材料公开。WorkBuddy Bench 的解法是：在构建时就斩断任务提示与源工件之间的可搜索链接，而非在发布后靠保密来维持。 这是一种"预防优于治疗"的设计哲学。

四、问题解法

4.1 总体架构：四轨道统一框架

WorkBuddy Bench 由四个并行子集构成，共享统一的任务目录格式（采用 Harbor [6] 风格），但每个子集有独立的评分工具：

关键设计决策：四个子集使用不同的评分工具，因此分数不可跨子集比较，套件不报告全局平均分。这避免了用一把尺子量四种不同工作导致的荒谬比较。

4.2 核心机制一：抗污染的任务构建协议

这是本文最重要的贡献。任务构建遵循一条严格的流水线：

第一步：来源采集

• Code 子集：真实开源仓库的历史 commit/PR（涵盖 Django、Flask、pytest、Black、Pydantic、httpx、Celery 等 ~18 个仓库）
• Security 白盒审计：真实历史 CVE（binutils、curl、nginx、vim、jq、fluent-bit 等项目）
• Web/Office 及部分合成任务：具体业务场景

第二步：逆向工程重写 这是抗污染的关键步骤。将真实的 commit/PR/CVE 逆向工程后，完全重写为一个简短的、口语化的、角色扮演式的自然语言请求。

以 Code 子集为例，重写时会分配五种请求者角色之一：开发者、算法工程师、产品经理、QA、运维。一个产品经理角色、产品分析类、困难难度的任务示例：

“checkout-copy 实验完成了；我想先知道新版本是否更好。数据有曝光和购买事件——请计算每组的转化率、收入和一个简单结论，不要计算很久之后发生的购买。”

注意这个请求的特征：它隐瞒了根因、参考 diff 和任何会给代理解决方案的框架线索。你无法通过搜索这段话找到它对应的原始 PR。

第三步：刻意欠规范（Deliberate Underspecification）

请求故意省略：

• 目标文件/模块（不告诉你改哪个文件）
• 精确 schema/接口（不告诉你函数签名长什么样）
• 边缘情况处理（不告诉你边界条件）
• 变更的精确边界（不告诉你改动范围到哪里）

解决这些差距本身就是任务的一部分。 这模拟了真实工作中常见的场景——同事给你的需求往往是模糊的，你需要在代码库中自己探索、推理、做出合理假设。这把评测从"纯代码合成"推向了更真实的"需求消歧与定位"能力。

第四步：回合后评估隔离（Post-Run Evaluation Isolation）

• 智能体在整个回合中只看到任务指令和声明的工作空间
• 只有智能体完成后，才引入任务特定的检查、评分标准或评估程序
• “隐藏测试"描述的是求解时不可见，而非发布后保密——所有测试随基准一起公开发布

4.3 核心机制二：任务目录格式

每个任务是一个自包含的目录（Harbor [6] 风格）：

task_name/
├── instruction.md      # 自然语言请求（重写后的口语化指令）
├── task.toml           # 任务元数据（类别、难度、标签、资源限制、超时）
├── environment/
│   ├── Dockerfile      # 定义的沙箱环境
│   └── workspace/      # 声明的工作空间（基线代码快照）
├── tests/
│   ├── test.sh         # 回合后评估入口
│   └── grading/        # 评分资产（回合后注入）
└── gold.patch          # Code 专用：诊断参考补丁（可选）

这种格式的关键特性：环境与评估分离。智能体在 environment/ 定义的沙箱中工作，完成后才运行 tests/ 中的评估。

4.4 核心机制三：多层次的评分体系

WorkBuddy Bench 拒绝"一刀切"的评分，每个子集量身定制评分机制：

Code 子集——运行级隐藏测试分数

任务奖励 $r_t$ 基于隐藏测试的通过率。三种验证器形式：

• pytest 注入套件（22/80 任务）
• 功能性布尔断言（54/80 任务）
• JSON 报告评分器（4/80 任务）

Oracle 门控准入：只有满足以下条件的任务才被收录——基线奖励 $\leq 0.3$（空补丁不能蒙混过关），Oracle 奖励 $= 1.0$（gold patch 必须能拿满分，确保任务可解且测试有效）。

Web 子集——三层评分标准（786 个评分项）

Web 任务奖励的数学定义：

三个评分层次：

• 规则检查（62 项）：确定性交付和预检项，如输出路径非空、HTML 可解析
• LLM/VLM 评判（676 项）：评估文本、代码、结构化内容、DOM 摘要、截图、视觉证据
• Agent 评判（48 项）：评估工作流完成、状态变化、持久化、跨状态一致性

失败的评分项按严重程度扣分（0.1/0.2/0.3），致命失败直接将任务奖励归零。

Office 子集——规则与评判的加权融合

Office 任务的核心评分公式：

其中 $w_i \in [0.70, 0.95]$，规则权重远高于评判权重——这意味着 Office 评分主要依赖确定性规则检查（文件、schema、数值、跨文件关系、状态变化），LLM 评判只在固定证据标准上做补充。

Office 总分采用等权宏观平均：$\text{Overall}_m = \frac{1}{T}\sum_{i=1}^{T} \bar{S}_{m,i}$

Security 子集——纯程序化评分

Security 任务奖励：

完全不使用 LLM 评判——所有评分通过确定性 scoring.py 程序运行三次取平均。这避免了 LLM 评判可能引入的偏差。

Security 子集还设计了五层反作弊基础设施，这是本文独有的精巧设计：

4.5 评估框架：双 Harness 并行

所有任务在两个代理框架上运行并报告：

• 默认：CodeBuddy Code（腾讯自研）
• 替代：Claude Code

协议固定参数：

• 推理努力设为高（thinking 模式）
• 上下文窗口统一 200k tokens
• 禁用 WebSearch 工具（否则抗污染就形同虚设——模型可以直接搜原始 issue）
• 禁用 AskUserQuestion 工具（模拟真实无人值守场景）
• 每个配置运行 3 次取平均

这种双 Harness 设计揭示了一个重要发现：框架是结果的一部分。同一个模型在不同框架下的分数可能剧烈波动，因此分数必须按框架分开解读。

4.6 完全开放的发布清单

WorkBuddy Bench 的开放程度在编码智能体基准中极为罕见。论文明确列出了发布清单（表 2）：任务目录骨架、任务提示文本、工作空间/环境镜像、评估框架代码、评分测试、Gold 补丁和参考方案、每任务及聚合分数、公共排行榜——全部发布。

唯一不发布的：用户数据——因为"完全未使用，不存在可发布的内容”。

五、评估指标与实验证据

5.1 评估指标体系

5.2 数据集设计如何证明论文主张

论文要证明的核心主张是：WorkBuddy Bench 能有效区分智能体的真实能力差异，而非区分记忆能力。 实验设计从多个角度支撑这一主张：

证据一：Oracle 门控确保任务有效 Code 子集要求基线奖励 $\leq 0.3$ 且 Oracle 奖励 $= 1.0$。这个设计的证明力在于：空补丁拿不到分（排除"什么都不做也能蒙对"的任务），而 gold patch 能拿满分（排除"任务本身无解或测试有误”）。只有同时满足两个条件，任务才有评测意义。

证据二：任务难度的梯度分布 Code 子集难度分布为 easy 7、medium 31、hard 42，以 hard 为重心（L4 阶梯 40 个任务）。如果基准只能测简单任务，分数会普遍偏高、区分度低。hard 任务占多数确保了基准有足够的区分度。

证据三：分数的框架敏感性证明分数反映真实差异 关键实验发现——同一个模型在不同 Harness 下分数剧烈波动：

如果分数只反映记忆，同一模型的分数不应该随框架变化如此剧烈。框架敏感性恰恰说明分数反映的是真实的能力差异——同一个模型在不同执行环境（工具调用方式、上下文管理、提示模板）下展现出不同的工程能力。

5.3 核心实验结果：跨模型排行榜

（cbc = CodeBuddy Code，cc = Claude Code，‡ = 修改指令运行，三次运行平均，思考模式）

5.4 实验揭示的关键发现

发现一：没有单一模型通吃 八个计分列的榜首分散在三个模型之间：Claude Opus 4.8 拿下五个（Code/Web 双 Harness + Office/cbc），GLM-5.2 拿下两个（Security 双 Harness），GPT-5.5 拿下一个（Office/cc）。

发现二：开源权重模型在安全领域领先 GLM-5.2 在两个 Security 排行榜上均以明显优势登顶（76.32 / 80.86），远超第二名。这是本基准最引人注目的发现之一——安全能力与代码/前端能力的排名解耦了。

发现三：难度切片揭示能力短板

• Code 子集中，bug_fix（0.47）和 api_contract（0.47）是最难的类别，而 feature_pipeline 高达 0.94——智能体擅长写新功能，但弱于修复和理解既有代码契约。
• Web 子集中，最弱的是页面交互和数据可视化语义；有状态工件（持久化/离线/跨状态）远难于非交互工件。
• Office 按难度呈线性下降：Easy 84.6 → Medium 80.3 → Hard 73.1（cbc 均分）。
• Security 是 token 消耗最大的子集：MiniMax-M3 在 cbc 下平均 88.8 回合、约 1,110 万缓存输入 token。

发现四：效率与排名不一致 GPT-5.5 在 CodeBuddy Code 下四个子集的输出 token 预算都是全场最小（Code 6.9k、Web 13.5k、Office 10.2k、Security 7.5k），却保持了 Code 和 Office 的第一梯队分数。而一些中游成绩要花 3-4 倍的 token。

5.5 消融实验的证据力

消融一：跨回合推理传递 为 HY-3 启用跨回合推理传递（thinking 内容跨回合传回后端）后重新运行 Code 子集：CodeBuddy Code 66.72（+3.82），Claude Code 68.18（+1.92）。这证明了推理链的持续传递对仓库级任务有实质性帮助。

消融二：修改指令运行 Claude Opus 4.8 在 Claude Code 下添加"不要提问、一次完成"的明确指令后：Code 得分 77.90，回合数从标准 18-44 降至 13.2，输出 token 降至 4.7k。这揭示了一个重要的工程洞察——框架的提问行为本身会消耗大量回合和 token，指令层面的约束可以显著影响效率和分数。

六、效果优势的根源解释

6.1 为什么抗污染构建方法比"截止日期后数据"更根本

对比对象：LiveCodeBench 依赖模型训练截止日期后发布的问题来避免污染。

LiveCodeBench 的根本局限：它的抗污染能力依赖于时间差——任务必须在模型训练截止日期之后发布。这意味着：(1) 任务来源受限（只能用刚发布的新问题）；(2) 随着时间推移和新模型发布，“新鲜度"不断贬值，需要持续刷新；(3) 最关键的是——它没有解决"可搜索性"问题，只是把搜索窗口推后了。

WorkBuddy Bench 的根本改变：它在构建时就斩断了任务提示与源工件之间的可搜索链接。任务从真实 commit/CVE 逆向工程而来，但被重写为口语化的角色扮演请求，任何搜索程序都无法从提示文本恢复出源 commit/PR。这把抗污染从"时间维度"转移到了"信息论维度”——不依赖新鲜度，而依赖提示与源之间的信息断裂。

因果链：逆向工程重写 → 提示文本与源工件的可搜索链接断裂 → 模型即使见过原始 commit/PR 代码，也无法将口语化请求与之关联 → 分数反映的是推理能力而非记忆能力。

6.2 为什么完全开放 + 抗污染构建的组合优于封闭基准

对比对象：CursorBench 从真实生产会话中提取任务，任务分布最真实，但基准封闭。

CursorBench 的根本局限：封闭性使得外部无法审计任务分布——可能存在对厂商自身代理的选择偏差（任务恰好是厂商代理擅长的类型）。这使得其排行榜的公信力依赖于对厂商的信任，而非可验证的证据。

WorkBuddy Bench 的根本改变：它用"匹配分布而非请求本身"的策略同时满足了分布真实性和审计性。任务匹配的是真实请求的类别和难度分布（内部使用分类法），但每个具体任务都是重新构造的。外部审计者可以检查任务目录、评估框架、测试、参考方案，排除选择偏差。

因果链：分布匹配 + 重新构造 → 任务真实但不依赖特定真实请求 → 完全开放审计成为可能 → 排行榜公信力建立在可验证证据上而非信任上。

6.3 为什么多评分工具体系比统一评分更能区分能力

对比对象：传统基准（如 SWE-bench）主要用通过/失败单元测试评分。

单元测试评分的根本局限：它只能区分"代码是否能通过预定义测试”，无法评估代码质量、交互体验、状态管理等维度。对于前端任务（视觉设计、交互逻辑）和办公任务（多文件数据一致性），单元测试根本不适用。

WorkBuddy Bench 的根本改变：每个子集量身定制评分工具。最突出的设计是 Security 子集完全不使用 LLM 评判——搜索调研显示，LLM/VLM 作为评判存在严重的可靠性问题（VIABLE 基准发现即使最强的 GPT-5.4 作为评判也只有 52.6% 的单次失败诊断准确率，却表现出 94.2% 的自我偏好）。Security 用纯程序化评分避免了这一偏差源。

因果链：评分工具与任务特性匹配 → 每个维度的能力都能被精确测量 → 不同子集的能力短板被暴露（如 Code 中 bug_fix 最弱、Security 中 GLM-5.2 最强）→ 排行榜呈现出"没有单一模型通吃"的真实图景。

6.4 为什么 GLM-5.2 在安全领域领先值得深入解读

这不是"碰巧好"，而是有结构性原因。Security 子集的核心是漏洞发现与利用，这要求模型具备：对底层系统机制（内存布局、控制流、协议状态机）的深层理解，以及在对抗性场景中不被安全对齐机制过度抑制的能力。

数据佐证：Claude Opus 4.8 在 Claude Code 下记录了 13 次安全拒绝，而 GLM-5.2 无拒绝记录。Security 子集的双框架最大重排序（平均绝对偏移 8.6 分）也主要发生在安全相关任务上。这暗示安全能力排名高度依赖于模型的安全对齐策略与任务需求之间的匹配度——过度保守的安全对齐会牺牲安全研究能力。

6.5 坦诚的局限：抗污染的保质期

论文诚实地承认了一个不可回避的局限：开放发布本身会创建发布后污染暴露。一旦任务公开发布，就可能被爬取到未来模型的训练数据中。WorkBuddy Bench 通过数据集版本控制来缓解（定期刷新和重新版本化），但无法根除。

这意味着抗污染构建方法的有效性有一个保质期——从发布到被大规模爬取训练之间。这是一个诚实的方法论边界，而非缺陷。

七、必要知识反推

假设一个完全没有知识和信息的人要去构造 WorkBuddy Bench 这样的基准，他最少必须掌握什么？

7.1 领域知识层

知识一：编码智能体的真实工作模式

• 为什么必须：不理解智能体实际做什么（定位→修改→验证），就无法设计能区分真实能力的任务。论文的任务设计（五种角色、刻意欠规范）直接来源于对真实工作流的观察。
• 融合节点：理解"需求消歧与定位是真实工作的核心难点"→ 设计出刻意欠规范的任务。

知识二：四大领域的专业纵深

• Code：仓库级软件工程、Python 生态、18 个主流 OSS 仓库的结构
• Web：前端工程全生命周期（生成→修改→分析→QA→转换）、12 个能力维度
• Office：多文件业务工作流、电子表格/文档/JSON 的结构关系
• Security：红队（漏洞发现/利用/Web 利用技术如 House of Apple2）、蓝队（恶意软件分析/安全运营）、Agent 安全（提示注入/链劫持/工具混淆）
• 为什么必须：每个子集的评分工具必须匹配该领域的专业特性。不懂安全就不可能设计五层反作弊。

7.2 方法论知识层

知识三：基准测试的污染机制与防御策略

• 为什么必须：不理解数据污染如何发生（可搜索性、预训练语料重叠），就无法设计有效的抗污染策略。论文的逆向工程重写正是建立在对污染路径的深刻理解上。
• 融合节点：理解"可搜索性是污染的根因"→ 在构建时斩断可搜索链接。

知识四：评估方法论的设计原理

• 规则检查 vs LLM 评判 vs Agent 评判 vs 程序化评分的适用场景
• LLM/VLM 作为评判的可靠性局限（自我偏好、组合偏差、跨语言不一致）
• 为什么必须：选择错误的评分工具会导致排行榜失真。Security 不用 LLM 评判的决策直接源于对 LLM 评判偏差的理解。
• 融合节点：理解"LLM 评判有偏差"→ Security 采用纯程序化评分。

知识五：Harbor 框架与任务目录约定

• 为什么必须：Harbor [6] 提供了成熟的任务目录格式（instruction.md + task.toml + environment/ + tests/），直接复用确保了任务的可复现性和生态兼容性。

7.3 工程知识层

知识六：Docker 沙箱隔离与模型-Harness 关注点分离

• 为什么必须：每次试验在隔离容器中运行、智能体只看到声明的工作空间、评分资产回合后注入——这些工程实现确保了评估的隔离性和公平性。

知识七：双 Harness 协议的标准化设计

• 推理努力高、200k 上下文、禁用 WebSearch/AskUserQuestion——这些协议参数的设定直接影响排行榜的可比性。
• 融合节点：理解"WebSearch 会破坏抗污染"→ 协议中禁用它。

7.4 知识融合的关键节点

整个 WorkBuddy Bench 的创造性在于多个知识层在关键节点上的化学反应：

八、论文中可以提取的通用性灵感

灵感一：用"信息断裂"代替"时间延迟"来对抗记忆污染

核心思想：当需要防止系统对特定数据产生记忆优势时，与其依赖时间新鲜度（数据晚于训练截止日期发布），不如在构建时就斩断输入与来源之间的可搜索信息链接——保留分布真实性但破坏可恢复性。

论文证据：WorkBuddy Bench 从真实 commit/CVE 逆向工程出口语化请求，使得搜索程序无法从提示恢复源工件。SWE-rebench 等依赖新鲜度的方法随时间贬值，而构建层面的抗污染不依赖时间。

推广场景：

1. 考试防作弊：考题不从题库直接抽取，而是从真实业务场景逆向工程出全新表述的题目，保留知识考点分布但破坏可搜索性。
2. AI 安全红队测试：对抗性测试用例不直接复用已知攻击模式，而是从攻击原理重构出新形式的攻击场景。
3. 推荐系统 A/B 测试：测试用例不从历史数据采样，而是从用户行为模式逆向工程出新情境，避免模型对历史模式的记忆干扰评估。
4. 学术同行评审：审稿分配不基于论文标题/关键词匹配（可被优化），而是从研究方法逆向工程出能力画像。

灵感二：把"欠规范"从缺陷变成被测能力

核心思想：传统评测追求输入规范完备（给出所有细节），但真实世界的任务天然是欠规范的。刻意制造欠规范，可以测量系统的"需求消歧与定位"能力——这在真实工作中往往比纯粹的执行能力更重要。

论文证据：WorkBuddy Bench 故意省略目标文件、精确接口、边缘情况，让"解决这些差距"成为任务本身。结果发现智能体在 feature_pipeline（从零写新功能）上得分 0.94，但在 bug_fix（理解既有代码契约）上只有 0.47——执行能力强但理解能力弱。

推广场景：

1. 编程面试：不给出完整的函数签名和测试用例，而是给出模糊的业务需求，考察候选人的需求澄清和代码定位能力。
2. 产品经理评测：给一个模糊的用户反馈而非完整需求文档，考察 PM 的需求拆解和优先级判断。
3. 自动化运维评估：给一个模糊的故障现象（“服务变慢了”）而非精确的监控指标，考察运维的根因定位能力。
4. AI Agent 通用评测：所有 Agent 评测都应包含"信息不完整"维度，因为真实部署中 Agent 几乎不会收到完备指令。

灵感三：评分工具必须与被测能力的本质匹配，警惕"万能评分器"

核心思想：用统一的评分工具（如 LLM-as-Judge）评估所有维度的能力是危险的。不同能力维度需要不同本质的评分工具——确定性的能力用确定性评分，主观性能力才用评判式评分。当 LLM 评判本身存在已知偏差时，在高风险评测中应避免使用它。

论文证据：Security 子集完全不使用 LLM 评判，用纯程序化 scoring.py + 五层反作弊。调研发现即使最强的 VLM 评判也只有 52.6% 诊断准确率且有 94.2% 自我偏好。Office 子集让规则权重（0.70-0.95）远高于评判权重。

推广场景：

1. 代码评审系统设计：安全关键代码的评审不应依赖 LLM 自动评审，而应用静态分析 + 确定性规则。
2. 教育评估：主观题用人工/LLM 评判，但客观能力（计算、逻辑）应用程序化评分。
3. 可信代码评测体系（与用户当前研究方向高度相关）：评测体系应分层——确定性的正确性用测试，结构质量用规则，语义合理性才用 LLM 评判，且后者的权重应被严格限制。
4. 竞赛评审：不同赛项采用不同评审机制，避免"一把尺子量所有"。

灵感四：完全开放 + 分布匹配的审计范式

核心思想：当一个评估体系需要公信力时，“匹配分布而非复用实例"的策略可以同时实现真实性和可审计性——审计者可以检查分布设计是否合理，而不需要看到任何特定真实实例。

论文证据：WorkBuddy Bench 匹配内部使用分类法的分布，但每个任务都是重新构造的，使得完全开放发布（包括参考方案）成为可能而不牺牲抗污染。

推广场景：

1. 政府/公共评估：公共政策评估可以匹配真实社会问题的分布但重新构造案例，使评估公开可审计。
2. 医疗 AI 评测：匹配真实病例分布但重新合成匿名化病例，同时保护隐私和确保可审计。
3. 企业内部 Benchmark 开源：企业可以开源内部能力评测的分布设计和方法论，而不泄露任何真实业务数据。
4. 可信代码评测标准化：评测标准应规定"分布设计 + 构建方法"的开放性，而非只公布分数。

灵感五：效率与排名的解耦——评测应报告资源消耗维度

核心思想：只报告准确率/分数的排行榜会误导决策。效率（资源消耗）与效果（分数）是两个独立的维度，一个完整的评测体系必须同时报告两者，因为"花 3-4 倍 token 换来相近分数"在真实部署中可能不可接受。

论文证据：GPT-5.5 在 CodeBuddy Code 下四个子集的输出 token 全场最小，却保持第一梯队分数；而中游模型可能花 3-4 倍 token。MiniMax-M3 在 Security 上平均 88.8 回合、1,110 万输入 token。

推广场景：

1. 模型选型：企业选择 LLM 时不应只看基准分数，应综合考量 token 成本和延迟。
2. Agent 系统设计：多 Agent 系统的评测应报告总资源消耗，而非只看最终输出质量。
3. 可信代码评审系统（用户研究方向）：自迭代评审系统的评测必须包含"每轮迭代的资源消耗"维度，否则可能选出"效果好但成本不可承受"的方案。
4. 绿色 AI 评估：碳排放维度的评测需要 token/计算消耗数据作为基础。

附录：本文对可信代码评测体系建设的启示

这篇论文对用户正在构建的面向全链路软件工程的可信代码评测与验证体系有直接的方法论参考价值：

1. 抗污染构建方法可直接借鉴：从真实 commit 逆向工程出重写任务，用于代码评审系统的评测数据构建。
2. 多层评分体系的分层思路（规则 vs LLM 评判 vs 程序化）可应用于评审结果的可信度评估。
3. 双 Harness 并行的设计提示：评测结果应报告在不同执行框架下的表现，而非单一配置。
4. 效率维度的纳入对"自迭代"系统的评测尤为重要——每轮迭代的资源消耗是衡量系统可行性的关键指标。