腾讯开源WorkBuddy Bench：多模型Agent评测基准深度解读

在人工智能飞速发展的今天，如何科学评估大模型在真实工作场景中的表现，成为业界共同关注的核心课题。腾讯WorkBuddy团队近日发布了一篇重要论文，宣布开源其内部使用的多模型Agent工作台选型评测基准——WorkBuddy Bench。这一评测工具的发布，为行业提供了一把可审计、可复现的「标尺」，也让外界得以窥见多模型切换策略背后的技术底牌。

核心方法论：三重机制保障评测可信度

WorkBuddy Bench的核心设计理念是「任务分布对齐真实工作场景，同时保持完全开源可审计」。该评测基准包含四个独立子集，每个子集配备独立的评分机制，分数跨赛道不可比，刻意不设置总平均分——这是一种经过深思熟虑的设计决策，旨在避免单一指标掩盖模型在不同场景下的真实表现差异。

开源的价值与启示

在评测污染防控方面，WorkBuddy Bench采用了极为严格的流程设计。首先，论文将「提示词可被搜索引擎检索」视为最重要的污染路径，并在任务生产环节就从源头阻断。具体而言，每个任务都锚定于真实的上游工件——开源仓库的历史提交记录、真实的安全漏洞（CVE）或具体业务场景，而非依赖原始用户请求或会话数据。 其次，所有任务都经过逆向改写处理，转化为简短、口语化、刻意欠规格（underspecified）的请求形式。以Code赛道为例，系统通过五种角色发声（开发者、算法工程师、产品经理、QA、运维），模拟真实协作场景。刻意欠规格的设计意味着：请求仅给出意图和约束，不提供目标文件、接口定义或边界情况，Agent必须自行从工作区找回缺失的上下文信息。这种设计考核的核心能力是需求消歧与环境适配，而非单纯的代码合成。 此外，评分资产在Agent行动期间完全不可见，评测结束后才注入沙箱环境。值得注意的是，「Hidden tests」仅指解题时不可见，并非发布后保密——全部测试用例随开源项目一并放出。

Code赛道：超越Bug修复的多元挑战

Code子集包含80个任务，其中Bug修复仅占10个，其余均为功能实现、重构、测试等多元化任务。Agent被置入一个checkout到基线提交的开源仓库环境，需自行定位代码、完成任务并保证隐藏测试通过。与业界知名的SWE-bench相比，WorkBuddy Bench的核心差异在于任务类型的多样性：五种角色与18个细分类目的组合，打破了传统评测「修issue」的单一框架。 准入门机制确保了评测任务的质量：每个候选任务先对未改动的工作区运行验证器（baseline reward必须≤0.3，证明任务并非「白给」），再打上标准补丁验证可解性（oracle reward必须=1.0）。构建过程中的早期评测还暴露了两类典型失败模式：Agent陷入修改测试文件的死循环，或在大仓库中迷失方向、修改了无关文件——这些观察揭示了真实工作中的导航与定位挑战。

评测结果揭示的关键发现

Web赛道采用「交付物契约」机制：Agent必须在声明的输出路径产出可运行工件，聊天中说得再好听但路径下没有可运行产物，直接判定失败。70个任务横跨前端生成、修改、分析、质检四大类别。 Office赛道评测的是混合格式文件（表格、文档、PDF、JSON、Markdown、文件树）中的完整工作交接。评测聚焦于最终工作区状态，而非答案文本本身——即便生成了一份看似合理的总结，若未同步更新关联的工作簿，仍会失分。评分采用双通道机制：确定性规则检查验证文件结构、数据准确性、跨文件关系；LLM Judge基于任务结束后的固定证据评估语义完整性。 Security赛道覆盖红蓝对抗全景：漏洞发现与利用（32个任务）、恶意软件分析（14个）、安全运营（8个）、Agent安全测试（6个）。白盒审计任务复现了binutils、curl、nginx、vim等广泛部署项目的真实CVE，采用「定位漏洞→验证PoC」的两步结构。Security赛道全程无LLM裁判介入，并配备五层反作弊机制，确保评测的公正性。

如有侵权，请联系删除。