数据集全公开，但搜不到原题｜Tencent WorkBuddy Bench是怎么做出“抗污染”评估的？
数据污染这件事，做过模型训练的人都很清楚——你的测试集在网上一搜就能找到原题，评估结果就变成了测记忆而非测能力。但问题没那么简单：把数据集藏起来确实能避嫌，却也堵死了外部审计的路。一个人不能既声称评估结果可信，又不让别人看评估细节。
这大概就是我看完Tencent WorkBuddy Bench论文后，觉得它最值得讨论的地方。
它不是要解决某个具体的模型能力问题，而是在设计一把更诚实的尺子——四把尺子，分别对应代码、网页、办公和安全四个真实工作场景。尺子完全公开，但任务本身经过了重构：从真实的commit、CVE或业务场景逆向工程而来，再改写为口语化的角色扮演请求。这意味着你没法通过搜索Prompt文本找到原来的GitHub issue或漏洞报告，因为那些文本压根不是从公开issue里抄来的。
先看整体架构，论文用一张图把整个工作流说得很清楚：
图1展示了Tencent WorkBuddy Bench的端到端工作流程。左边是真实世界的数据来源——Git提交、Pull请求、办公流程和安全事件；中间是统一的任务构建管道，四个任务轨道（Code、Web、Office、Security）各自经历标准化处理，包括任务包生成和验证；右边是沙盒执行环境与跨模型评估结果。这张架构图的逻辑很清晰：数据从真实世界来，经过结构化改造变成可复现的任务，最后在隔离环境中完成评分。
再看四个子集的概览，论文用表格做了清晰对比：
表1概括了四个子集的领域、规模和评估指标。Code包含80个仓库级软件工程任务，用隐藏测试评分；Web有70个面向前端工件的任务，用规则检查加LLM/VLM判断评分；Office覆盖50个混合格式文档工作流任务，用规则检查和LLM Judge混合评分；Security包含60个红队蓝队安全任务，完全由确定性评分程序评定。每个子集都在CodeBuddy Code和Claude Code两个框架下运行，子集之间分数不可比较——这是论文的刻意设计，因为评分工具完全不同。
这套基准的四个子集覆盖了相当不同的任务形态。Code子集不只是修bug——80个任务里只有10个是bug fix，剩下的分布在功能开发、代码工程、测试、算法工程、产品分析等领域。Web子集一半任务不是从零搭建，而是修复缺陷、扩展现有页面、生成测试、格式转换。Office子集不依赖视觉理解，核心是文本和表格层面的数据处理。Security子集覆盖了红队（漏洞发现与利用）和蓝队（恶意软件分析、安全运营），还有专门的Agent安全测试。
任务来源的构成也值得一提。以Code子集为例：
表3给出了代码子集的来源分布：A族34个任务锚定于真实开源软件快照，B族24个任务来自洁净室重实现，C族22个任务是完全合成的工作空间。这种混合策略很有意思——真实开源commit保证了任务在实际工作中的代表性，合成空间则能覆盖那些难以从开源项目中提取的边界场景，洁净室实现在两者之间做了平衡。
讲白了，这套基准的设计哲学可以概括为三句话：评估资产完全公开，但任务的Prompt无法被网络搜索还原；四个子集各测各的，不硬凑一个总平均分；真实感来自分布匹配而非直接复用用户数据。发布内容相当完整：
表2列出了数据集开放发布的所有组件，包括任务目录骨架、任务提示、工作空间镜像、评估框架、评分测试、参考解决方案等7个组件全部标注为Released，用户数据则明确标注为Not used at all。这验证了论文的开放承诺——任何第三方都可以重新运行每个任务并检查其内容。
抗污染，但坦承到底能抗多少
这是论文花了最多篇幅解释的设计点，我觉得也是最应该认真读的部分。
构建协议分四步：来源锚定、重写请求、欠指定、后回合评估隔离。来源要么是真实的开源commit/PR或CVE，要么是业务场景重建；然后重写为口语化的角色扮演请求；重写时故意保持欠指定，省略目标文件、精确模式、边界情况处理；最后评估资产只在Agent完成任务后才引入沙盒。
效果是：你无法通过搜索Prompt文本找到原始代码或漏洞线索。这个设计在任务编写阶段就关闭了最直接的污染路径。
但论文没有回避这种方法的边界，原文列出了三种明确的残余暴露。模型可能已经见过原始的公开commit或PR代码——在代码子集的A族任务中，底层仓库是真实开源的，模型预训练可能已经见过这些代码。对于基于CVE的安全任务，模型可能见过公开的漏洞分析。与任何公开发布的基准一样，发布后内容会被抓取、进入未来的训练语料——论文说通过版本控制缓解这个问题，但无法消除。
这种诚实是稀缺的。很多人写论文时会把自己的方法包装成“彻底解决了污染问题”，但这篇论文明确说的是：可搜索Prompt路径被关闭了，但这套基准不是零污染的。数据集版本控制是缓解手段而非解决方案。
安全子集还有一个独特的反作弊设计值得单拎出来说。因为它完全不用LLM裁判，所有评分靠确定性的scoring.py完成，这就必须防止模型靠硬编码或穷举答案来骗分。论文搞了五层防护：禁止字面扫描硬编码答案、用重命名输入测试检查模型是否真的解析了结构而非依赖文件名、覆盖/篡改测试防范尾部数据操纵、编码依赖测试要求检测规则基于字节而非明文锚定、低权重诱饵字段抑制盲目枚举。
四个子集各自的设计逻辑
每个子集都在解决一类特定的评估问题，且评估方法完全不同。
Code子集的独特之处在于Oracle门控准入——每个候选任务在入库前必须通过双重验证：Baseline Reward ≤ 0.3（初始工作空间不能已经满足契约），Oracle Reward = 1.0（参考方案能拿到满分）。这就筛掉了两类问题：初始工作空间已经过度满足要求的“假任务”，以及gold patch本身拿不到满分的“坏金标准”。
80个任务覆盖六个使用领域：
图2(a)展示了代码子集的领域分布，六个领域中bug fix仅占10/80，功能与界面工作、代码工程、测试、算法工程和产品/数据分析共同占据了剩余70个任务。图2(b)是Web子集的七类任务分布，页面交互和数据可视化占据主导。图2(c)展示了Web任务的生命周期模式，From Scratch恰好占一半，另一半分布在bug修复、特性扩展、审查分析、测试生成和格式转换中。
代码任务的评估流程在另一张图中有完整呈现：
图3展示了代码任务的端到端Pipeline：Agent接收用户指令后探索仓库、修改项目并生成补丁；后任务评估阶段包含单元测试评估和LLM裁判评估两个并行通道，前者快速检查测试通过率，后者基于意图覆盖和语义正确性进行加权评分；最终的任务级融合将两个分数按权重组合。这个设计说明代码评分不只是看测试是否通过——语义正确性也是一个独立维度。
Web子集的核心是“工件而非对话”的契约。Agent必须在声明的输出路径生成可运行的工件，如果该路径下没有东西，即使回答写得再漂亮也算失败。70个任务中45个需要交互或状态——单流程状态变化、持久化、跨状态行为、多步骤工作流——这些是纯静态页面生成基准不会测到的能力。评估使用规则检查（确定性交付约束）、LLM/VLM评判器（文本、结构、视觉语义）和Agent评判器（驱动运行中的工件检查工作流和状态）。
Web子集的评估流程设计得比较细致：
图4展示了Web任务的评估工作流程。左侧是查询工件——用户查询、Agent执行和生成的工件；中间是评估过程，提取证据后依次经过规则判断、LLM/VLM判断和Agent判断三道关卡；右侧是评分检查表，规则项负责确定性约束（文件、格式、预检），LLM/VLM项审查文本和视觉语义，Agent项驱动运行中的工件检查交互流程和状态。这个三道关卡的设计意味着即使一个工件看起来不错，在规则检查层面可能就被拦住，在语义层面可能被挑出问题，在交互层面可能暴露状态断裂。
论文还用表格比较了Web benchmark的能力覆盖：
表8比较了7个Web benchmark在四个维度上的覆盖情况：工作表面（UI、应用、数据、文档/测试）、生命周期（从零开始、修复扩展、审查转换）、运行时证据（操作、状态）和验证方式（规则、VLM、Agent）。WorkBuddy Web在所有维度上都是全覆盖（●），而其他benchmark在不同程度存在缺失。这个比较是定性的，基于各基准自身的描述，但它清楚展示了差异化设计——覆盖了从生成到审查、从静态页面到有状态交互、从规则检查到视觉语义评估的完整矩阵。
Office子集处理的是混合格式文件工作流。输入包括电子表格、文档、PDF、JSON导出、Markdown笔记和文件树，输出是更新后的工作簿、报告、结构化记录和交接材料。评估检查的是整个工作空间的状态，不只是Agent输出的文本答案。之所以这样设计，是因为只检查文本会漏掉很多实际错误——Agent可能写了个看似合理的摘要，但根本没更新它描述的表格；或者创建了文件，却导致依赖状态不一致。
Office子集的组成结构通过两组统计图展示：
图5(a)展示了50个任务的构建路线：30个来自选定任务库案例重建，20个来自办公工作流扩展。图5(b)展示了校准难度分布：13个简单、24个中等、13个困难。这个分布保证了任务不是两极分化——中等难度占多数，简单和困难各占约四分之一，使得分数有足够的区分度。
Office的覆盖维度更多：
图6从四个维度统计了Office任务：任务类型方面，数据/电子表格/结构化任务最多（24个），文档/报告/演示次之（17个），工作空间自动化/有状态工作流（9个）；诊断场景覆盖了数据与财务分析、文档与演示、对账与后台操作等六类；输出家族以xlsx（24个）、markdown（20个）和json（15个）为主；评估机制方面，所有50个任务都使用规则检查和LLM Judge，部分任务额外使用状态差异、模拟环境等方法。这些统计说明了Office子集的覆盖广度——不是单一的数据处理任务集，而是多种类型、多种场景、多种输出格式的组合。
Office评分用的是双通道设计——确定性规则检查验证客观要求（必需的文件、模式、数值、源关系、状态转换、副作用和执行约束），LLM Judge基于任务结束后提取的固定证据评估二元语义质量标准。每个任务预先配置两个分数的混合权重（0.70到0.95之间），Judge不能修改规则检查结果。换言之，模型分数里有一部分是“板上钉钉的对错”，另一部分是“语义质量的好坏”，前者比重大得多。
评估流程的完整链路也有详细展示：
图7展示了Office任务的评估四阶段：Agent执行任务并生成最终工作区；后任务评估由规则检查验证工作区状态、LLM判断评估固定证据；任务级分数由规则贡献和判断贡献按任务预配置权重组合；跨任务聚合对多个试验结果取平均（每任务平均3次试验，50个任务等权重宏观平均）。这个流程的关键设计是Judge在任务结束后只看到固定证据，不检查实时工作空间，不能修改规则检查结果——两条评分通道相互独立。
Security子集与另外三个形成鲜明对比：不用任何LLM裁判，全靠确定性的scoring.py评分。60个任务横跨红队（38个）和蓝队（22个），包含白盒源码审计、黑盒二进制利用、Web利用、恶意软件分析、安全运营和Agent安全六个领域。
安全子集的核心信息集中在这两张图表：
表5展示了安全子集的四块粒度结构。漏洞发现与利用块任务数最多（32个），属红队学科，对应安全研究员和漏洞利用工程师角色；恶意软件分析（12个）和安全运营（10个）属蓝队学科；Agent安全块任务最少（6个），也属红队学科。这个分布反映了真实安全工作负载中红蓝任务的比例关系。
白盒审计任务的设计尤其值得注意。给出源码树，要求Agent阅读解析器、追踪数据流、定位易受攻击的代码路径——第一步评分达到阈值后，环境才解锁第二步，允许提交概念验证输入，且只有输入能在沙箱容器内可重复触发ASAN崩溃才算通过。这模拟的是真实的“审计后利用”工作流，不是一开始就给明缺陷位置让你写攻击代码。
Agent安全任务是六个测试工具型Agent安全边界的新型挑战，包括Agent间Prompt注入、ReAct链劫持、多模态Prompt链注入、工具模式混淆、通过摘要工具的数据外泄和延迟触发攻击。这类任务的评估目标不是让Agent编写修复代码，而是要求它返回结构化发现报告并附CVSS严重性评级——模拟的是安全团队在发布前进行Agent安全审查的场景。
安全任务的设计背景在这张图中有完整呈现：
图8展示了Security任务基准的三部分设计。任务构建从真实漏洞开始，将其转化为可重现案例；安全任务类型涵盖六种红队和蓝队任务，包括白盒源码审计、黑盒二进制利用、Web利用、Agent安全、恶意软件分析和安全操作；评估流程以隔离Docker评分容器为核心，Agent输出进入沙盒后由确定性评分程序直接生成数值奖励。
排行榜告诉了我们什么，没告诉我们什么
论文报告了7个模型在4个子集×2个评估框架（CodeBuddy Code和Claude Code）下的8个排行榜。所有分数是3次独立运行的think模式平均值。
先看整体格局：
表6展示了完整排行榜。8个榜单的领先者被三方瓜分：Claude Opus 4.8在Code、Web和Office-cbc共五个榜单领先；GLM-5.2在两个Security榜单领先；GPT-5.5在Office-cc领先。没有单一模型包揽所有榜单，这本身就是信息——不同模型在不同类型任务上各有优势，不能简单说“某个模型最强”。
从表6可以看出几个具体发现：
Claude Opus 4.8在代码任务上表现最强，两个框架下分别74.43分和77.90分（cc下标注了‡，是修改指令运行）。Web任务也是Claude领先，但分数分布在68-70分区间，比代码任务低不少，说明Web任务的评估更严苛或任务本身更难。Office任务上竞争相当激烈，cbc下Claude的82.37分和HY-3的82.08分差距极小。Security任务上GLM-5.2（76.32和80.86）明显拉开差距，这个开源模型在安全领域的表现是一个值得关注的发现。
最值得讨论的发现是评估框架不是中性的测量工具。同一个模型在CodeBuddy Code和Claude Code下分数可以差很多。在Security子集上最明显——七个双评分模型的平均绝对偏移达到8.6分，排名也发生变化：GPT-5.5从cbc下的第6名跃升到cc下的第2名，MiniMax-M3从第2名跌至第5名。Code子集上，GPT-5.5和GLM-5.2在两个框架下的相对排名是反的。Web子集上，两个框架的排名顺序也不同。
这说明一个方法论层面的问题：你用什么评估框架来跑模型，会显著影响你得到的排名结论。论文用双框架并行报告来应对这个问题，而不是回避它。表7补充了token和轮次数据：
表7比较了7个模型在Code子集上两个评估框架下的效率指标。GPT-5.5在cbc下输出仅6.9k token，是所有分析模型中最少的，但得分（72.90）并不低；GLM-5.2在cc下输出22.0k token拿到77.06分，而GPT-5.5在cc下仅用8.7k token拿到了76.63分。换句话说，GPT-5.5在Code任务上表现出了极少token下的高效能——输出token是其他模型的三分之一到十分之一，得分差距在可接受范围内。但这不是通用结论，不同子集的效率特征差异很大。
另一个具体的分析是关于代码任务难度的。论文按类别细分了Code子集的平均Reward。最难的两个类别是bug_fix和api_contract，平均Reward都是0.47。bug_fix涉及真实仓库的回归修复——模型要从一句话的症状描述中定位间歇性故障，修改不破坏周围契约。api_contract更难在语义正确但契约不匹配：模型实现了正确行为但用了错误的函数名、参数形状或输出格式，验证器会直接判零。最容易的是feature_pipeline（0.94）和testing（0.88），这些是定义良好的合成Pipeline和测试编写任务。
还有编码与数据/算法之间的系统性差距。所有模型在所有框架下，数据及算法任务的得分几乎一致高于编码任务（约74%对65%）。在两种框架下都有评估的每个配置中，编码得分都低于同一配置的Office得分——通常低十分以上。
Web子集的能力切片也揭示了具体模式。视觉设计和分析报告是最强类别，代码测试和页面实现居中，页面交互和数据可视化语义暴露最多的失败。交互和状态复杂度方面，非交互式和轻量交互工件远优于有状态工件——单流程状态变更、多步骤工作流、持久化和跨状态行为是最困难的切片。
关于Office子集的难度和任务类型分析，论文提供了详细图表：
图9(a)展示了在CodeBuddy Code和Claude Code两个框架下，模型平均分数随难度从简单到中等再到困难依次下降的折线趋势。cbc框架下分别为84.6/80.3/73.1，cc框架下为83.9/78.9/72.0。这说明难度分级是有效的——困难任务的区分度更大。图9(b)按七种任务类型给出了模型性能的详细对比表格，加粗标记了每类任务的最佳分数。一个值得注意的细节：GLM-5.2在两个框架下总得分几乎不变（79.60 vs 79.57），但其多文件提取得分从87.7下降到70.5，而复杂规则执行得分几乎保持不变（83.1 vs 83.3）——总分掩盖了下属能力的显著漂移。
局限与人设边界
论文用了一整节讨论局限性，内容比我读过的许多基准论文学都要具体。
排行榜上有一个单元格用了修改指令。Claude Opus 4.8在Claude Code下的Code分数（77.90分）除了常规禁用的工具外，还额外添加了“请勿提问，一次性完成”的指令。论文明确标注了这个差异，并把这次运行的分数从跨框架聚合中排除。Code子集以Python为主，跨语言覆盖仅限少量任务（JavaScript/TypeScript/Rust移植到Python的实验性任务），关于编码难度和测试框架差异的发现不应假设可推广到其他语言。
基于评判的组件存在模型评判偏差——Web的LLM/VLM和Agent评判器、Office的LLM Judge层、还有Code的LLM Judge参考分数，都可能系统性偏好特定输出风格或自身模型家族。论文说这个风险在构建上受约束但未单独量化，需要进一步消融研究来测量的评判偏差。
评估框架不是中性工具这个发现本身也是局限。Security子集上的平均绝对偏移达到8.6分，说明改变评估基础设施会显著改变排名结论。论文把双框架报告作为临时缓解措施，但框架敏感性的根本缓解需要进一步工作。
发布后污染暴露。开放发布的代价是任务内容被未来的模型训练抓取，随着时间推移会削弱抗污染能力。数据集版本控制可以缓解，但不会完全消除。
对读者有什么用
如果你不做安全Agent，不测前端生成，这套基准对你有什么实际价值？
对于做基础模型评估的人来说，抗污染任务构建方法值得借鉴。具体步骤是：从真实工作产物（commit、PR、CVE、业务场景）出发，重写为口语化请求，故意留白关键信息，让评估对象无法通过搜索找到原题。发布时资产全公开，依赖构造方式和版本控制防污染。这套协议可以迁移到其他领域的评估构建。
对于做编码Agent产品的团队，代码子集中发现的能力差异——bug_fix和api_contract最困难，数据算法类任务普遍更容易——可以指导测试集设计和产品迭代优先级。如果你产品面向的是真实仓库的bug修复和API开发，就别只看那些合成Pipeline上的高分来做决策。
对于关注评估实践的研究者，双框架报告的做法提供了一个处理“评估基础设施偏差”的参考方案。与其假设评估框架透明，不如并行报告、直接展示偏差。评估框架的敏感性数据本身就是有价值的研究对象。
对于关注大模型安全的人，Security子集覆盖的Agent安全任务是独特且稀缺的——Agent间Prompt注入、ReAct链劫持、工具模式混淆这类攻击面，目前的公开评估资源很少。60个任务虽然规模不大，但覆盖了六个安全领域的红蓝对抗场景，而且完全靠确定性规则评分，没有LLM裁判引入的偏差。
最后，这套基准的开放程度值得作为参考标杆。任务目录、环境镜像、评估代码、评分测试、参考解决方案全部公开，任何第三方可以不依赖腾讯的基础设施独立复现结果。对于想建立评估信任的研究组织来说，这比“我们内部测出来分很高”有说服力得多。
🤔 深度思考：这篇论文提出了一组评估基准和构建方法，尝试在“公开审计”和“防污染”之间找到平衡。但从数据来看，评估框架不是中性的——同一模型在两个框架下Security得分差了8.6分。假如换一个框架，排名结论会变多少？评估偏差和模型真实能力的边界，恐怕还需要更多实验才能摸清。
💝 支持原创：如果这篇文章帮你理清了这套基准的设计逻辑和适用边界，欢迎分享给同样在做模型评估的朋友。
🔔 关注提醒：我会持续追踪大模型评估领域的进展，关注后可以第一时间收到深度解读的推送。
#AI技术 #深度学习 #模型优化 #技术干货 #论文解读
参考
Tencent WorkBuddy Bench: A Multi-Domain Coding-Agent Benchmark with Contamination-Resistant Task Construction