计算机使用智能体评测指南：告别盲盒式开发

一、评测概述

不少团队第一次让智能体操作电脑时，都会经历这样的过程。演示环境里，它能顺畅打开软件、填写表单、导出数据，看起来离“数字员工”只有一步之遥。放到真实业务中却状况频出：页面布局稍有变化就点错按钮；遇到弹窗广告时，它会认真阅读广告内容；网络短暂中断后，它误以为任务已完成；有时还会打开无关页面，甚至执行了不该执行的操作。

这正是“盲盒式开发”的典型表现： Demo 很惊艳，上线即翻车，而且出了问题也说不清原因。根本原因在于三点：

• 验证只停留在少数理想案例上，没有形成系统的评测流程；
• 只盯着“能不能做出来”，忽略了抗干扰、安全和稳定性；
• 缺少环境复现和结果判定机制，结论无法沉淀。

这里以计算机使用智能体（Computer-Use Agent，下称 CUA） 作为评测对象。这类智能体像人一样通过“看屏幕、动手操作”完成任务，是上述翻车现象最集中、也最需要系统评测的一类 Agent 形态。

本文面向以下读者：

• 评估 Agent 技术路线的开发者和架构师；
• 搭建验收标准的测试工程师；
• 关注投入产出与合规风险的技术负责人；
• 负责上线运行保障的运维人员。

读完本文，读者可以明确该测什么、怎么测、结果怎么解读、在什么条件下适用，从而把 Agent 开发从“靠感觉”推进到“看数据”。

agent-">二、评测目标：评测 Agent 到底要回答什么

Agent 评测常见的误区是直接问“好不好用”。这个问法无法指导决策，因为同一套能力在不同业务中价值差别很大。

• 对一个偶尔生成周报的内部工具，偶尔失败只需人工补做，影响有限；
• 对一个直接操作系统设置或执行批量变更的自动化流程，一次误操作就可能造成数据损失或业务中断。

因此，评测的核心不是给出排名，而是回答三个层次的问题：

1. 能不能做成：在目标任务上，智能体完成任务的真实比例有多高，失败主要发生在哪一步；
2. 稳不稳、安不安全：遇到页面变化、弹窗干扰、网络波动或恶意内容时，它能否保持目标一致、不越界、不造成不可逆后果；
3. 值不值得投入：接入与调试需要多少人力，单次运行消耗多少资源，出问题时能否及时发现、定位和恢复。

只有把这三个问题拆解成可观察的指标，评测结果才能转化为选型与落地依据。

三、评测对象说明：什么是计算机使用智能体

CUA 是以图形界面为交互入口的智能体。它不依赖软件提供的专用接口，而是通过获取屏幕画面理解当前状态，再以鼠标、键盘等操作驱动软件完成任务。

典型工作流程如下：

1. 感知：截取屏幕或读取界面结构，理解当前页面状态；
2. 规划：根据目标和当前状态决定下一步动作；
3. 执行：发起点击、输入、滚动、快捷键等操作；
4. 观察与纠错：检查动作是否生效；如未生效，调整策略或回退。

按实现方式，常见形态大致有三类：

形态	基本思路	相对优势	主要短板
端到端模型型	模型直接根据屏幕内容输出操作	通用性强，对界面变化适应性较好	资源消耗较高，行为过程可解释性较弱
工具调用型	模型负责决策，截图、点击、校验等能力由外围工具完成	流程清晰，便于分步评测	效果依赖外围工具的质量
规则与脚本型	预先编写固定操作脚本	执行确定、易于审计	页面一旦变化就容易失效

三类形态的思路和短板各不相同，因此评测维度要按形态有所侧重。

CUA 的价值在于三点：覆盖没有开放接口的存量软件；打通需要跨多个应用协同的流程；降低自动化脚本的开发和维护成本。

它的风险也同样集中：

• 基于视觉感知，容易受分辨率、主题、缩放比例等界面因素影响；
• 可以“替人动手”，也就可能“替人犯错”；
• 真实环境中充满弹窗、广告、提示条、无关链接等干扰信息。

正因如此，评测不能只看成功案例，还必须专门验证它在干扰和安全边界处的表现。

四、评测维度设计：把“翻车”变成可测量的指标

评测框架建议分为三层：

• 基础层：功能完整性与任务完成度，回答“能不能做成”；
• 加固层：鲁棒性、安全性与稳定性，回答“靠不靠得住”；
• 运营层：易用性、兼容性、可观测性、可维护性与成本，回答“好不好管、值不值得”。

各维度的关注点与验证方式如下表所示。下文的公开评测数据中，性能类数值一律需要自行验证，表中不预填。

维度	关注问题	关键指标	主要验证方式
功能完整性	能否覆盖典型使用流程	功能覆盖率、流程走通率	逐条核对需求清单，按典型流程走通
任务完成度	任务是否真正完成	任务成功率、步骤正确率、平均步骤数	按验收标准判定，人工复核抽样
抗扰动鲁棒性	遇到干扰能否不跑偏	受干扰率、受干扰后恢复率、误操作次数	在任务中注入弹窗、通知、界面变化等干扰
安全性	是否会做出危险或越权操作	危险动作拦截率、越权操作次数、敏感信息暴露情况	在隔离环境中设置高风险任务与诱导内容
稳定性	长时间运行是否保持一致	任务间结果方差、连续运行失败率、资源占用趋势	批量连续执行，记录每轮结果
易用性	接入和调试成本有多高	首个用例跑通耗时、单任务平均调试次数	记录开发者实际投入时间
兼容性	能否适配现有环境	不同环境配置下的成功率差异	多种环境组合交叉测试
可观测性	出问题能否查清原因	失败步骤定位时间、关键节点日志覆盖率	故意制造失败，检验定位效率
可维护性	变化后维护成本有多高	界面改版后需调整的配置数量、回归测试周期	模拟界面变化，评估改造工作量
成本	总投入是否合理	单任务资源与调用消耗、人力投入、迁移成本	统计运行账单与工时

4.1 基础层指标：功能完整性与任务完成度

为什么重要：基础层决定智能体有没有使用价值。如果连核心流程都走不通，讨论性能和安全性意义不大。

如何验证：从真实业务中梳理高频任务，按“核心、重要、边缘”分级，并整理成带验收标准的功能清单。每条验收标准都要能客观判定，例如“报表导出成功，行数与源数据一致”，而不是“报表看起来正常”。

如何解读：

• 成功率必须结合验收标准理解，标准宽松会显著抬高成功率；
• 同一任务反复执行多次，还要看结果是否稳定。如果同一任务十次中成功七次、失败三次，其实际可用性并不等于 70%；
• 失败步骤的分布比总体成功率更有价值：感知错误、决策错误还是执行错误，决定了后续优化该从哪个环节入手。

4.2 加固层指标：鲁棒性、安全性与稳定性

4.2.1 鲁棒性：抗干扰与抗变化

为什么重要：真实界面不会按演示的节奏呈现。在公开评测语境中，“受干扰率”指智能体执行过程中受到无关内容或环境变化干扰的比例，越低越好。这一概念恰好衡量了智能体会不会被广告、弹窗、推荐链接带偏。界面改版、弹窗出现、通知弹出在网络顺畅时也许不是问题，一旦叠加时间压力或批量任务，就会转化为批量失败。

如何验证：在不改变主任务的前提下注入受控干扰，包括随机出现的弹窗、页面中的无关链接和按钮、界面元素位移、分辨率或缩放变化，以及语言或主题切换。每次只改变一类变量，记录智能体是否偏离目标、是否需要额外步骤纠偏，以及最终是否完成任务。

如何解读：受干扰率高说明模型对屏幕信息的筛选能力不足。受干扰率不高但恢复耗时长，则意味着纠偏成本高。两者需要结合判断。

4.2.2 安全性：危险动作与越权行为

为什么重要：CUA 拥有类似真人的操作权限，风险也最集中，主要有三类：

• 执行了任务之外的破坏性操作，例如删除文件、修改系统设置、提交不可逆表单；
• 被授予的权限超出任务实际需要，例如只需要查看数据，却能修改配置；
• 把屏幕上的敏感信息带入外部请求，例如账户信息、密钥、个人数据等。

如何验证：

• 在隔离环境中设计“陷阱任务”，例如在页面上放置带诱导文字的按钮，或描述与真实目标无关的弹窗；
• 检查是否按最小权限原则限制可访问的应用与目录；
• 检查敏感字段是否脱敏，操作记录是否完整留痕。

如何解读：拦截率、越权次数与敏感信息暴露情况是核心观察项。涉及资金、权限、数据的不可逆操作，应设置二次确认或人工审批环节。这一维度的结论通常比成功率更关键。

4.2.3 稳定性：连续运行与结果一致性

为什么重要：单次演示成功不代表批量运行可靠。批量任务往往需要连续运行数小时甚至更久，期间可能遇到网络抖动、内存占用持续上升、依赖服务响应变慢等情况。

如何验证：

• 同一任务重复执行多轮，统计结果方差和失败类型分布；
• 设计连续运行测试，观察资源占用趋势和失败是否随时间累积；
• 注入异常，例如网络中断、依赖服务短时不可用、屏幕锁定，观察智能体是否能识别状态并合理中止。

如何解读：偶发失败与系统性失败的处理方式不同。偶发失败可以通过重试、回退等机制消化；同一类错误反复出现，说明存在需要修复的缺陷。

4.3 运营层指标：易用性、兼容性、可观测性、可维护性与成本

易用性 关注接入门槛和调试成本，可通过首个用例跑通耗时、单任务平均调试次数衡量。调试便利性在 CUA 场景中尤为关键：当失败原因是“点错了一个按钮”时，能否快速回看每一步的屏幕画面和决策理由，直接影响排障效率。

兼容性 关注能否适配现有环境，包括目标软件版本、操作系统、分辨率、多显示器、远程桌面和权限策略。建议用多种环境组合交叉测试，观察成功率波动，识别环境敏感点。

可观测性 决定出问题后能否查清原因。关键节点日志是否覆盖感知、决策、执行各环节，能否按任务 ID 串联完整操作链路，能否对失败率和资源使用设置告警，都是重要考察点。

可维护性 关注软件升级或界面改版后的调整成本，包括界面描述、元素定位、提示词或策略配置需要改多少，回归测试能否自动执行。评估时可用定性分级描述改造工作量，例如“改动量小，数小时内可完成”。

成本 需要覆盖三类：

• 运行成本：视觉理解通常伴随较高的推理资源消耗，需统计单任务平均消耗；
• 人力成本：接入、调试、维护的投入；
• 迁移成本：当模型版本更新、推理资源调整或业务规模扩大时的切换代价。

五、评测环境与前提：先把“变量”管住

评测结论能否复现，取决于环境是否受控。测试前应明确以下条件：

项目	需要明确的内容
环境与配置	操作系统版本、屏幕分辨率与缩放、目标软件版本、账号类型、所在网络区域
任务集	任务来源、数量、难度分布、验收标准，以及是否同时包含自建任务与公开基准任务
调用方式	视觉输入频率、历史上下文长度、单次操作粒度、最大步数限制、失败重试策略
资源	推理资源规格、并发数、执行节点数量
判定方式	规则校验、人工复核与模型评审的分工，以及复核抽样比例
边界	评测覆盖哪些环节、不覆盖哪些环节

网络条件也要纳入设计。应覆盖正常网络、弱网以及短时断网后恢复等场景。此外，测试环境应与生产环境隔离，使用脱敏数据，并遵循最小权限原则，避免评测本身引入风险。

如果团队在百度智能云等云平台上部署评测环境，可以把执行节点运行在云服务器或容器平台上，用对象存储归档截图与操作日志，并借助监控告警、日志服务等通用云产品能力，统一采集资源指标和失败告警。这样可以保证多轮评测的资源配置一致，结果更容易横向比较。

六、评测方法：从流程设计到过程记录

6.1 评测流程

阶段	主要动作	产出物
明确目标	确定评测要回答的核心问题	评测问题清单
设计样本	构建分层任务集，覆盖核心、边界、异常与对抗场景	任务清单与验收标准
建立基线	在相同环境中记录人工或脚本完成的耗时、步骤与结果	基线数据
环境准备	准备环境快照，每次任务前恢复初始状态	环境快照与恢复脚本
分维度验证	分别执行功能、鲁棒性、安全、稳定性测试	各维度结果记录
控制变量	对比不同方案或配置时，保持环境、任务与调用方式一致	对比实验记录
异常与对抗	注入干扰、权限限制、网络异常与诱导内容	异常场景报告
结果归档	保存每一步截图、决策、执行结果与资源数据	完整评测数据包

关于基线：人工完成同样任务所用的时间和步骤，是衡量智能体效率的重要参照。如果智能体完成一个五分钟的人工任务需要半小时，还伴随多次误操作，即使最终成功，其实际价值也需重新评估。

关于判定方式：建议以规则校验为主、模型评审为辅、人工抽样复核兜底，并定期比较三者的一致率。

6.2 示意性代码

下面的伪代码展示了一个通用评测循环的结构：

# 通用评测循环伪代码（仅示意，不涉及任何具体工具）
def evaluate(agent, tasks, env):
    results = []
    for task in tasks:
        env.restore_snapshot(task.snapshot_id)   # 恢复统一的初始环境
        if task.noise:                           # 可选：注入受控干扰
            env.inject_noise(task.noise)
        trace, success, early_stop = [], False, False
        for step in range(task.max_steps):
            obs = env.capture()                  # 获取屏幕状态
            action = agent.decide(obs, task.goal)
            if action is None:
                break
            env.execute(action)
            trace.append({"step": step, "observation": obs,
                          "action": action})
            if checker.done(env.capture(), task):
                success = True
                break
            if safety_guard.blocked(env):        # 高危动作拦截
                early_stop = True
                break
        results.append({
            "task_id": task.id,
            "success": success,
            "early_stop": early_stop,
            "steps": len(trace),
            "elapsed": env.elapsed(),
            "resource_usage": env.resource_usage(),
            "trace": trace,
        })
    return {
        "success_rate": mean(r["success"] for r in results),
        "avg_steps": mean(r["steps"] for r in results),
        "safety_stop_rate": mean(r["early_stop"] for r in results),
        "detail": results,
    }

代码虽短，却体现了几个关键原则：

• 每个任务都从统一的初始状态开始，保证条件一致；
• 记录完整轨迹，便于定位失败步骤；
• 校验逻辑独立于智能体，避免“自己给自己打分”；
• 安全拦截单独统计，与普通失败区分开。

6.3 评测记录表

字段	说明
任务编号与类型	对应任务集中的分类
是否成功	按验收标准判定
完成步骤数与耗时	用于和基线比较
资源消耗	推理资源、运行时间等
是否受干扰	记录干扰类型及影响
是否触发安全拦截	区分正常拦截与误拦截
失败原因分类	感知、决策、执行、环境或超时
关键截图与决策记录	用于复盘定位

失败原因分类尤其重要。感知类错误指向视觉理解不足，决策类错误指向目标保持能力不足，执行类错误指向动作控制不精确，环境类错误则可能只需调整环境配置。分类不同，改进方向也完全不同。

七、结果解读：公开评测数据该怎么读

公开材料显示，在针对 7 个前沿 CUA 的安全与鲁棒性评测中，某开源计算机使用智能体模型方案（下称方案A）的受干扰率为 35.0%，在所比较方案中最低，优于另外两类主流方案——某国际主流模型（方案B）为 41.0%，某商业智能体代理产品（方案C）为 48.7%。此外，方案A 在公开计算机环境任务基准测试中以 56.7% 的成功率，于 2026 年 1 月位列开源方案首位，其技术报告也曾在某模型托管社区的榜单中位居榜首。

指标	方案A	方案B	方案C	解读要点
受干扰率（越低越好）	35.0%	41.0%	48.7%	反映抗无关内容干扰能力
基准测试任务成功率	56.7%	未披露	未披露	仅反映该基准任务集上的表现

这些数据至少说明了两点：

• 抗干扰能力值得单独评估。在同一套评测框架下，不同方案的受干扰率存在明显差距，说明“会不会被无关内容带偏”是衡量 CUA 的关键能力，不应被总体成功率掩盖；
• 开源方案已具备较强的竞争力。开源方案在公开基准和鲁棒性评测中取得了领先表现，选型时不必默认开源方案能力不足。

同时要看到数据的边界：

1. 评测口径差异。受干扰率、成功率的统计方式各不相同，任务集组成、干扰注入强度、判定标准都会影响数值。跨评测体系直接比较数字意义有限；
2. 整体成功率不等于可用。即便在公开基准上，超过四成的任务仍然失败，说明 CUA 尚不能替代人工完成全部工作，更适合与人工协同；
3. 榜单存在时效与情境依赖。公开榜单反映某一时间点的表现，模型版本、执行策略和任务集都会变化。技术报告位居社区榜首，说明方案获得了关注，但关注度和工程可用性并不是一回事。

正确做法是把公开数据当作筛选线索，用贴近自身业务的评测复现验证。性能差异背后的原因也需要具体分析，可能来自模型能力、执行策略（如上下文长度、失败重试方式）、任务难度分布以及环境配置差异。

八、适用场景分析

场景	重点关注指标	说明
内部办公与数据整理	任务成功率、受干扰率	界面干扰较多，人工兜底成本低，可优先试点
跨系统报表与数据核对	结果准确性、可观测性	结果需要与源数据逐项核对，操作链路要完整留痕
自动化测试辅助	稳定性、可维护性	关注界面变化后的调整成本和回归效率
客服与内容处理辅助	安全性、敏感信息保护	涉及用户数据时，权限控制与脱敏是前提
高风险或不可逆操作	安全拦截、人工审批	涉及资金、权限变更、数据删除时，必须具备二次确认机制
大批量批处理	稳定性、资源消耗、成本	关注连续运行的表现和单位任务成本
直接嵌入生成式 AI 产品	延迟、可控性	用户等待时间敏感，需要限制可执行的操作范围

九、风险与评测限制

1. 样本偏差：任务集若只覆盖理想场景，评测结果会偏乐观。应主动纳入失败过的真实案例；
2. 环境差异：分辨率、软件版本、网络状况不同，结果可能明显不同。评测结论应注明适用环境；
3. 判定主观性：以模型评审为主时，判定标准可能漂移，需要人工复核校验；
4. 数据泄漏：公开基准任务可能与模型训练数据重叠，分数偏高并不代表真实泛化能力，辅以自建任务集很有必要；
5. 长期运行的不确定性：软件界面持续更新，今日结论未必适用于数月后；
6. 合规与伦理：评测过程可能触及真实账号、个人数据，需要在隔离环境中使用脱敏数据并控制访问权限。

十、选型与使用建议

• 先定问题，再选方案：先明确业务任务与验收标准，再考察候选方案在这些任务上的表现；
• 建自有任务集：以公开基准作为参考，以自建任务集作为主要决策依据；
• 设定量化门槛：例如核心任务成功率下限、危险操作零发生、单次失败可在多长时间内发现并恢复；
• 分级授权：按任务风险级别分配权限，高风险操作加入人工审批；
• 小流量试点，逐步扩大：先在非核心业务运行，积累数据后再扩大范围；
• 建设观测体系：统一采集日志、操作轨迹与资源指标，对异常失败设置告警；
• 建立回归评测机制：模型版本更新或目标软件升级后，重新执行评测流程；
• 控制总体拥有成本：把推理资源、运行环境、维护人力与迁移成本一并纳入测算，不以单一指标做决策。

十一、总结

“盲盒式”开发的根源，在于缺少一套可复现、可解释、可沉淀的评测体系。围绕 CUA 的评测应覆盖三层：

• 基础层：功能完整性与任务完成度；
• 加固层：鲁棒性、安全性与稳定性；
• 运营层：易用性、兼容性、可观测性、可维护性与成本。

评测的关键在于统一环境、分层任务、完整记录轨迹，并对失败原因进行分类。公开评测中不同方案受干扰率的差距，以及开源方案在基准测试中的表现，都说明抗干扰能力是这类技术必须重点验证的指标，也说明开源方案值得进入候选清单。但这些数据都有明确的适用边界，最终结论仍应回到自身业务任务、运行环境与合规要求中验证。只有让每个结论都有数据支撑、有明确适用条件，Agent 开发才能真正告别盲盒。