腾讯 WorkBuddy Bench：面向编码智能体的多领域评测基准

导语

随着 Claude Code、CodeBuddy Code 等编码智能体进入日常开发流程，业界越来越需要一种更接近真实工作的评测方式。腾讯团队发布的 Tencent WorkBuddy Bench 正是围绕这一问题设计：它不是只考察模型能否补全函数或通过单一测试集，而是尝试评估智能体在代码工程、前端开发、办公流程和安全任务中的综合执行能力。

核心要点

• 覆盖四类工作域：WorkBuddy Bench 将任务划分为 Code、Web、Office、Security 四个子集，分别对应仓库级工程任务、前端开发、办公与业务流程，以及红蓝队安全场景。
• 强调抗污染构造：每个任务都从真实 commit、pull request 或业务场景反向设计，但最终提示会被改写成简短、口语化、带角色设定的请求。这样做的目的，是让用户无法简单通过搜索原始 issue、PR 或提交记录来还原题目。
• 开放而非保密：论文强调，基准并不依赖隐藏数据来防污染。任务目录、环境镜像、评测 harness、测试和参考解法都会开放，可信度来自构造方法与数据集版本管理。
• 统一运行协议：所有任务被包装成统一的任务目录格式，并在可复现协议下运行。论文中提到评测会覆盖 CodeBuddy Code 和 Claude Code 两类 agent harness。
• 不设总平均分：由于四个子集使用不同评分工具，论文明确指出各子集分数不能直接横向比较，也不会给出套件级平均分。

解读

WorkBuddy Bench 的关键价值，在于把“编码能力评测”从传统代码题进一步推向“工作任务评测”。真实开发往往不是孤立函数补全，而是理解仓库上下文、修改界面行为、处理业务文件、排查安全问题，并在给定环境中完成可验证交付。多领域设计有助于观察智能体是否具备跨工具、跨场景的执行稳定性。

它对数据污染的处理也值得关注。当前许多公开基准在被模型训练数据吸收后，排行榜分数可能被高估。WorkBuddy Bench 选择从真实开发痕迹中抽象任务，再重新表达需求，同时保留开放审计能力。这是一种折中：既不把评测变成黑箱，也尽量降低“背题”的可能性。

意义与影响

对模型厂商来说，这类基准能帮助区分“会写代码片段”和“能完成工作”的差异；对企业用户来说，它提供了更贴近日常研发、办公和安全场景的选型参考；对研究社区来说，开放任务、环境和评测流程则便于复现实验与审查缺陷。

不过，论文也提醒读者谨慎解读分数：不同子集验证方式不同，因此不能把它们强行合并成一个单一排名。未来编码智能体评测的重点，可能会从“谁的总分最高”转向“在什么工作域、什么约束下更可靠”。

来源：Hugging Face Daily Papers