【Agent】Tencent WorkBuddy Bench:面向真实工作的Benchmark

发布时间:2026/8/9 9:41:57
【Agent】Tencent WorkBuddy Bench:面向真实工作的Benchmark noteTencent WorkBuddy Bench 的核心贡献不是提出新 Agent 模型而是提出了一套更接近真实工作的 Agent Benchmark。抗污染任务构造从真实 Commit/PR/业务场景反向构造 Prompt而不是直接复制公开问题。Outcome-based Evaluation评测 Agent 最终修改后的 Workspace 和 Artifact而不是聊天答案。Model × Harness 联合评测证明 Agent Harness 本身会显著影响模型最终表现。WorkBuddy Bench 正在把 Agent 评测从“模型会不会答题”推进到“Agent 能不能真正完成一项工作”。不存在一个模型在所有 Agent 场景中全面领先。Claude 在 Code/Web 上较强GLM-5.2 在 Security 上表现突出HY-3 则在 Office 场景表现较好。Agent Performance ≈ Model × Tool Calling × Context Management × Agent Loop × Harness四个 Track 的评测方法也有所区别CodeHidden TestsWebRule LLM/VLM Judge Agent JudgeOfficeDeterministic Rule Evidence-grounded LLM JudgeSecurity完全程序化 Scorer不使用 LLM JudgeOffice Benchmark举例让 Agent 真正修改办公 Workspace任务结束后同时用“确定性 Rule Check”验证硬指标用“Evidence-grounded LLM Judge”评价语义质量再加权得到单任务分数每个任务跑 3 次最后对 50 个任务做等权平均文章目录noteTencent WorkBuddy Bench面向真实工作的多领域 Agent Benchmark1. 研究动机2. 论文核心2.1 抗污染任务构造3. Agent 评测方式4. 实验结果5. Harness 会显著影响 Agent 能力6. 论文分析Tencent WorkBuddy Bench面向真实工作的多领域 Agent Benchmark1. 研究动机现有 Coding Agent Benchmark 主要有两个问题。一是数据污染。SWE-bench 等公开数据集的 Issue、PR、Commit 和参考答案长期存在于公开网络模型可能在预训练阶段见过相关内容因此高分不一定完全代表真实的 Agent 推理和工程能力。二是任务过于单一。真实 Coding Agent 不只负责修 Bug还需要完成前端开发、数据分析、办公文件处理、安全分析等复杂工作流。因此Tencent WorkBuddy Bench 想回答一个更实际的问题把 Agent 放进真实 Workspace 后它能否自主理解需求、探索环境、调用工具并最终完成工作2. 论文核心WorkBuddy Bench 共构建260 个 Agent 任务覆盖四个领域Track任务数主要能力Code80Repository-level 软件工程Web70前端开发、交互、测试Office50文档、表格、数据工作流Security60漏洞、安全分析、红蓝队不同 Track 使用不同 verifier因此论文明确指出四个领域的绝对分数不能直接横向比较也不计算统一总分。2.1 抗污染任务构造论文最核心的设计是Contamination-Resistant Task Construction。它不直接复制公开 Issue而是真实 Commit / PR / CVE / 业务场景 ↓ 反向理解真实需求 ↓ 重新改写成自然、口语化的用户请求 ↓ 隐藏 Root Cause / 修改位置 / Reference Diff ↓ Agent 自主探索 Workspace 并完成任务例如真实问题可能对应某个明确的代码修改但最终给 Agent 的 Prompt 只会表达“这个排名在相同分数时不太稳定帮我处理一下。”Agent 必须自己找到对应模块、理解现有实现并完成修改。论文将这种设计称为Deliberate Underspecification需求故意不提供完整 specification以测试 Agent 的需求理解、环境 Grounding 和自主决策能力而不仅仅是代码生成能力。需要注意论文强调的是contamination-resistant而不是 contamination-free。公开数据发布后仍可能进入未来训练集因此通过 Dataset Versioning 等方式缓解污染而无法彻底消除。3. Agent 评测方式这篇论文另一个重要特点是评测最终结果而不是模型最后说了什么。Agent 的基本执行过程是User Request ↓ Explore Workspace ↓ Read / Search / Tool Call ↓ Modify Files / Execute ↓ Debug / Iterate ↓ Final Workspace ↓ VerifierAgent 执行期间只能看到任务和 Workspace看不到测试代码任务完成后才运行对应 verifier。四个 Track 的评测方法也有所区别CodeHidden TestsWebRule LLM/VLM Judge Agent JudgeOfficeDeterministic Rule Evidence-grounded LLM JudgeSecurity完全程序化 Scorer不使用 LLM Judge其中 Web 的 Agent Judge 会真正操作页面检查按钮、状态变化、持久化和多步 Workflow而不仅仅比较 HTML 或截图。举例office任务Office 一共 50 个任务输入可能是 Excel、Word/PDF、JSON、Markdown、文件目录等要求 Agent 完成真实办公流程比如跨表格对账、数据汇总生成报告或演示材料修改 Excel / JSON / 状态文件保证多个输出文件之间数据一致遵守任务中的执行边界和约束论文强调如果 Agent 只是“回答得像对的”但没有真正更新目标文件也算失败。一个典型例子是hospital_bed_utilization给 Agent 病区配置表、入院记录和床位政策表要求它计算月度利用率并生成两张工作表。难点不只是算数而是要做跨文件 key 对齐、日期规范化、套用正确规则并保证明细表和汇总表一致Office Benchmark 让 Agent 真正修改办公 Workspace任务结束后同时用“确定性 Rule Check”验证硬指标用“Evidence-grounded LLM Judge”评价语义质量再加权得到单任务分数每个任务跑 3 次最后对 50 个任务做等权平均。4. 实验结果论文在CodeBuddy Code和Claude Code两套 Agent Harness 上分别测试多个模型。以 CodeBuddy Code 为例ModelCodeWebOfficeSecurityClaude Opus 4.874.4368.1482.3764.37GPT-5.572.9061.1481.9664.39GLM-5.271.5467.4379.6076.32HY-362.9067.7182.0864.50MiniMax-M360.1458.0078.2874.14结果表明一个比较明显的现象不存在一个模型在所有 Agent 场景中全面领先。Claude 在 Code/Web 上较强GLM-5.2 在 Security 上表现突出HY-3 则在 Office 场景表现较好。这说明 Agentic Capability 很难用一个单一 Benchmark 分数概括。5. Harness 会显著影响 Agent 能力论文同时使用CodeBuddy Code 和 Claude Code两种 Agent Harness。同一个模型换 Harness 后性能可能发生明显变化。例如 GPT-5.5 的 SecurityCodeBuddy Code64.39 Claude Code77.91提升超过13 个百分点。因此这篇论文实际上揭示了一个很重要的问题Agent Benchmark 测到的并不是纯粹的 Base Model 能力而是 Model × Harness 的联合能力。实际 Agent 性能更接近Agent Performance ≈ Model × Tool Calling × Context Management × Agent Loop × Harness所以比较 Agent 模型时不能只看“底座模型是谁”还需要关注它运行在哪套 Agent Framework 中。6. 论文分析WorkBuddy Bench 最值得关注的并不是排行榜而是它体现出的Agent 评测范式变化。传统 LLM Benchmark 更像Question → Answer → Accuracy而 Agent Benchmark 正逐渐转向Task ↓ Environment Interaction ↓ Multi-step Tool Use ↓ State Modification ↓ Final Artifact ↓ Verifier换句话说Agent 的核心指标正在从“回答是否正确”变成“任务是否真正完成”。论文在 Code 场景中也发现Agent 的典型失败并不一定是“代码不会写”而是在大型 Repository 中迷路、定位错文件或者进入无效循环。这意味着 Repository Navigation、Grounding、Planning 和长程执行已经成为 Agent 能力的重要瓶颈。