Agent Evaluation Benchmark

我为什么开始做这件事

当 agent 逐渐从“能聊天”走向“能执行任务”，评测问题就变得非常不一样。

我越来越不满足于只看这些说法：

• “它看起来很聪明”
• “演示视频效果不错”
• “这次跑通了”

这些都不是 benchmark。它们无法回答一个更重要的问题：这个 agent 到底可靠到什么程度？

我提出的框架

基于这个判断，我设计了一套 4-pillar confidence model，用来评估 browser-use / personal assistant 一类 agent：

• Statistical：用 Wilson CI、必要时结合 bootstrap，处理有限样本下的成功率不确定性
• Judge：关注评测者一致性，例如 Cohen’s κ，而不是把裁判输出当成天然真值
• Coverage：看任务集是否覆盖真实世界的重要分布，而不是默认均匀采样就合理
• Stability：多次运行下是否稳定，而不是单次跑通就算完成

这个项目里我最满意的一点

我识别并纠正了一个我认为非常关键的设计误区：

coverage 不应该以“尽量均匀”为目标，而应该尽量贴近真实任务分布。

如果真实世界里某类任务出现频率远高于另一类，那么评测集的权重设计就不应该假装它们同等重要。否则 benchmark 只是在用一种看似中立、其实失真的方式制造错觉。

它和我其他项目的关系

这个项目表面上是统计和评测，底层其实和我做过的很多事情连在一起：

• 传播研究训练让我更敏感于“指标如何塑造结论”
• 多智能体模拟让我更关注系统行为而非单次输出
• 工程落地经历让我知道，生产环境不会接受“看起来差不多”

已有验证资产

框架已进入真实任务验证，而不只停留在方案层：当前材料包括 120 个标注任务、17 个 Chrome 自动化脚本。其中一个 50 任务批次记录了 1,152 个动作步骤和 1,020 张截图，另有 72 次运行级审计记录用于检查跨运行稳定性。

这个 benchmark 仍在持续扩展，但目标不是一份漂亮的 leaderboard，而是一套能说明置信区间、裁判分歧、覆盖盲区和运行波动的诚实评测方法。

真实工作流扩展

在另一条 LexBench-Browser 扩展工作流中，我先用认知复杂度矩阵和 probe task 判断任务是否真正可执行，再设计并接入四组更接近日常工作的案例：

• 10 个 RPA 任务
• 10 个即时通信任务
• 10 个跨系统任务
• 10 个邮件任务

这 40 个任务已进入 browseruse-bench 数据集，但目前证据只支持“设计并接入完成”，不支持把它们写成已经跑完的 benchmark 结果。原数据集的 210 个 baseline task 也不是我的个人产出。