为编程、网络安全与电脑操作智能体选择评测
先把智能体的工作对应到可验证结果，再选择一组覆盖不同失败方式的评测。
这些分类会交叉，但成功条件不同。应从智能体必须产出的成果或状态出发选择评测，再为工具调用、界面定位或安全代码等薄弱环节补充测试。
先定义结果，再选择分类
首先描述智能体成功时，用户应得到什么：代码修改、经过验证的安全发现、完成的浏览器事务，还是编辑后的文档？这些结果对应不同验证器。补丁可以在仓库中测试，应用工作流可以检查最终状态。都使用了语言模型和工具，不代表这些测试可以互相替代。
然后确定系统边界：评估的是底层模型、你的智能体框架，还是完整应用？比较候选时应保持同一边界。否则，提示、恢复逻辑或环境配置的改进，可能被误认为模型本身的变化。下面是编辑团队关于如何选择评测组合的建议，并不声称某个基准能够覆盖所有部署场景。
编程智能体要匹配修改的工作规模
对代码补全助手，函数级测试可以揭示生成代码能否满足一份简短要求。对自主处理仓库的助手，还应加入需要阅读现有代码、交付修改并通过项目测试的任务。它们覆盖工作流中的不同部分：一个诊断局部代码生成，另一个评估整合能力。
检查成功提交具体包含什么。测试套件可能检查所需行为和回归问题，但未必评价设计是否清晰、安全，或是否容易长期维护。如果这些属性影响用户，就应增加明确的复核或评测。不能让执行成功率变成对整体工程质量的概括承诺。
网络安全智能体要明确证明了什么
安全评测应明确它测量的能力。Cybench 研究挑战解题，CyberGym 要求按照验证规则生成漏洞复现用例，ExploitBench 关注一种专门的漏洞利用设置。安全代码生成又是另一问题：生成的软件是否避开指定弱点。一个笼统的“cyber 分数”无法替代这些区别。
应选择最接近目标安全工作流的任务，并仔细阅读起始信息。提供源码、详细漏洞描述或中间提示，都会改变问题。比较时要匹配协助程度和预算。同时，把能力与政策行为分开：拒绝有害请求，不能证明会修复软件；完成挑战，也不衡量是否会恰当地拒绝请求。
Cybench official project · CyberGym research paper · ExploitBench official project · CyberSecEval benchmark collection
电脑操作要分别测试定位与完成
如果智能体通过图形界面操作，先检查它能否定位指令描述的元素，再在相关环境中测试完整任务。系统可能点得准，却无法保留文档状态、切换应用，或从错误动作中恢复。完整工作流的成绩，也可能掩盖某个在不同布局下容易失败的组件。
观察渠道应与产品匹配。只看截图、使用无障碍信息、读取结构化浏览器内容，得到的证据不同。也要匹配操作限制和应用版本。OSWorld 提供了桌面环境中基于执行结果的任务评测示例，AndroidWorld 则面向移动环境。两者都不能作为所有界面的通用指标。
SeeClick and ScreenSpot · OSWorld and OSWorld Verified · AndroidWorld
让评测组合中的每项测试都有明确用途
选择一项接近完整工作的评测，再为需要诊断的失败方式加入专项测试。例如，基于浏览器的编程助手，可能需要分别评估仓库工作和界面交互；安全编程助手则可能同时需要功能正确与安全代码检查。交叉主题标签在这里有用，因为一项工作流可能依赖多种能力和某个专业领域。
对每项选定评测，记录预期产物、验证器、允许获取的信息、资源限制和已知盲点。在扩大使用范围前，用实际应用中的代表性样例复核失败。如果没有公开基准匹配某个关键要求，应记录这个缺口，并建立针对性的本地测试，而不是让无关排行榜承担它无法提供的证据。