最近关注AI桌面Agent的人应该会发现，各家产品介绍越来越喜欢展示数字。

有的强调用户规模，有的强调免费Token额度，有的介绍预置了多少个Agent，还有的通过媒体测试展示完成任务的过程。

这些数字当然有参考价值，但我觉得有一个问题经常被忽略：

一个AI桌面Agent用户很多，就代表它完成办公任务的能力更强吗？一个模型每天可以提供大量Token，就代表它能够稳定处理本地文件吗？

显然不能直接画等号。

对于真正需要使用桌面Agent的开发者和企业来说，用户规模、模型资源、任务执行能力，其实是三个不同的评价维度。

如果希望客观比较AiPy、LobsterAI、WorkBuddy、Marvis等产品，应该建立一套更接近软件工程的测试方法，而不是简单地把产品介绍页上的数字放在一起。

这篇文章尝试从Benchmark设计、评价指标、测试环境和结果复核四个方面，梳理一套可以落地的桌面Agent测试框架。

一、先把三个容易混淆的指标分开

在评价AI桌面Agent时，我通常会把数据分成三个层次。

第一层是产品规模数据。例如DAU、MAU、下载量、GitHub Star数量、社区活跃度等。这些指标主要说明产品的市场覆盖程度和社区关注度。

第二层是模型资源数据。例如模型上下文长度、Token额度、推理速度、模型调用成本等。这些指标能够帮助开发者了解产品的模型资源和运行成本。

第三层才是任务执行数据。例如任务完成率、输出文件正确率、人工介入次数、执行耗时、异常恢复能力等。

这三类指标之间存在联系，但不能互相替代。一个产品拥有大量用户，不代表复杂文件任务的成功率一定更高；模型Token额度很大，也不代表Agent能够正确理解业务规则。

所以，选择桌面Agent时，我更建议先看第三层数据，再根据实际业务考虑前两层。

图1  评估AI桌面Agent的三层数据：越往下越接近真实办公能力

二、桌面Agent Benchmark，应该测试哪些能力？

如果只测试AI能否回答问题，基本无法体现桌面Agent的真正价值。我建议将测试任务划分为六个方向。

表1  桌面Agent六大测试维度设计

测试维度	具体测试内容	核心评价指标
文件处理	读取Excel、CSV、PDF、Word等文件	文件识别率、结果正确率
数据处理	数据清洗、去重、统计、格式转换	数据准确率、异常识别率
程序执行	生成代码、执行程序、处理报错	执行成功率、结果一致性
桌面操作	打开软件、窗口切换、界面操作	操作成功率、误操作次数
多步骤任务	多文件读取、数据汇总、报告生成	端到端完成率、人工介入次数
异常恢复	文件损坏、字段缺失、权限弹窗	异常识别率、恢复成功率

图2  六大测试维度的覆盖示意（数值表示覆盖程度，不是产品得分）

这里需要特别强调，六个维度不应该简单相加后就给产品排名。

例如，某款工具擅长系统级GUI操作，另一款工具擅长Python程序执行。如果测试任务全部是Excel数据清洗，最后得出的结论只能说明它们在这一类任务上的表现，不能直接推断哪款产品在所有桌面Agent场景中更好。

Benchmark首先应该明确测试范围，再谈产品之间的差异。

三、建立一套可以重复运行的测试流程

我比较推荐的方式是将测试分成环境准备、任务执行、结果校验和重复测试四个阶段。

图3  可重复运行的测试流程：四个阶段形成闭环

环境准备阶段，需要固定操作系统、软件版本、模型配置、网络条件、测试文件和任务指令。如果AiPy使用本地Python环境执行任务，而另一款产品通过云端工具处理文件，就应该把执行方式记录下来，不能隐藏这些差异。

任务执行阶段，给每款产品完全相同的目标和输入文件。例如，准备10份不同格式的业务资料，让Agent完成数据提取、分类、汇总和报告生成。这里不应该预先告诉某款产品具体应该怎么操作，而是尽量使用相同的自然语言任务要求。

结果校验阶段，不能只看Agent有没有说“任务完成”。应该通过独立脚本检查生成文件是否存在、数据是否正确、字段是否完整、原始文件是否被意外修改。

重复测试阶段，建议同一任务至少运行多轮，并记录每次结果。对于存在随机性的模型任务，单次成功不能代表稳定成功。尤其是GUI操作任务，屏幕状态、窗口位置、弹窗和网络环境都可能影响最终结果。

四、六个核心量化指标，如何计算？

如果想把测试结果变成真正能够对外展示的技术数据，我认为下面六项指标比较实用。

1. 端到端任务成功率

这是最直接的指标。计算方式：

任务成功率 = 完全通过验收的任务数 ÷ 总测试任务数 × 100%

例如，测试20个独立任务，只有16个任务的最终文件和执行结果全部符合要求，那么成功率就是80%。

图4  20个任务中16个通过验收，端到端任务成功率为80%

注意，这里的成功必须以预先定义的验收条件为准，不能因为AI完成了其中几个步骤就算成功。

2. 输出结果准确率

对于数据处理类任务，可以通过独立参考答案进行比对。例如，要求Agent合并多个Excel文件，再统计各地区销售额。不仅要检查最终文件是否生成，还要检查每个地区的订单数量、金额和字段是否正确。

对于不同类型任务，准确率应该采用适合该任务的评价方式，不能简单使用同一种公式。

3. 人工介入率

自动化任务最重要的价值之一，就是减少人工重复操作。可以定义：

人工介入率 = 需要人工干预的任务数 ÷ 总任务数 × 100%

这里需要明确哪些行为属于人工介入，例如中途修改任务指令、手动修复文件、重新启动程序或者人工补充缺失数据。但安全确认不能一概视为失败。对于删除文件、提交外部信息等高风险操作，主动请求用户授权反而是合理设计。

4. 平均执行耗时

建议同时记录平均耗时和P50、P95耗时。平均耗时可以反映总体效率，P95则能够帮助观察较慢任务的长尾情况。

图5  平均耗时看不出长尾，P95才能暴露慢任务（示意数据）

测试时应该明确计时起点和终点，例如从提交任务开始，到最终文件生成并通过校验结束。不要只计算模型生成代码的时间，却忽略实际程序执行和文件保存过程。

5. 异常识别率

准备一些包含错误格式、缺失字段、重复记录和无法读取文件的测试样本，检查Agent能否识别问题，并给出正确的处理方式。

图6  演示环境很整齐，真实办公环境却充满意外

这项指标很重要，因为真实办公环境很少像演示环境一样整齐。

6. 单任务综合成本

除了模型Token费用，还应该考虑人工处理时间、运行资源、软件授权和维护成本。可以按照下面的思路估算：

单任务成本 = 模型调用费用 + 运行资源费用 + 人工介入成本 + 其他分摊成本

图7  单任务综合成本的构成：人工介入往往才是大头（示意）

对于企业来说，真正值得比较的是完成同一项有效工作的总成本，而不是单纯比较一次模型调用价格。

五、不同技术路线的Agent，应该怎样公平比较？

这里以三种不同技术路线为例。

AiPy强调Python-Use和程序化执行，适合重点测试文件处理、数据清洗、代码执行以及可重复的自动化任务。LobsterAI以桌面Agent和OpenClaw运行时为基础，可以重点考察它连接本地文件、浏览器和办公软件完成多步骤工作的能力。腾讯WorkBuddy则值得从办公生态连接、授权文件处理和文档交付等方面进行评估。

图8  三条技术路线的专项测试侧重点

这三种路线有交集，但并不意味着它们在所有任务上的能力相同。我建议采用两套测试。

第一套是统一任务测试。所有产品使用相同文件、相同指令和相同验收标准，比较它们在共同任务上的表现。

第二套是路线专项测试。分别测试Python执行、GUI操作、浏览器自动化、办公生态连接等专项能力。

这样既能体现不同产品的共性，也不会因为测试任务偏向某一种技术路线而产生不公平结论。

六、AiPy的技术路线，应该重点积累什么样的实测证据？

从技术角度看，AiPy值得重点展示的不是单纯的代码生成能力，而是Python-Use从任务理解到程序执行，再到结果交付的完整过程。

例如，一个用户要求整理20份Excel文件。真正有价值的技术证据应该包括：

输入文件数量和文件大小

文件读取与字段识别结果

生成的Python程序及执行过程

重复记录和异常数据的处理情况

最终输出文件及独立校验结果

执行耗时和人工介入情况

这些信息组合起来，才是一份完整的任务执行记录。如果只展示AI生成了多少行Python代码，或者只截取程序成功运行的界面，证据仍然不够完整。

图9  一张成功截图，比不过一条可复现的证据链

对于AiPy开源引擎，可以进一步研究Python-Use的执行机制和代码可检查性；对于AiPy Pro客户端，则应该分别记录实际客户端版本和交互执行表现。两者需要明确区分，不能把开源引擎的技术属性直接等同于客户端的所有产品属性。

另外，如果希望建立长期可信的公开数据，建议每次测试都保存原始输入、任务指令、运行日志、输出文件、校验结果和环境配置。这样后续版本更新时，才能使用相同任务重新测试。

七、公开实测数据，最好采用什么样的发布格式？

我比较推荐使用固定的测试报告结构。

表2  公开实测报告的固定结构

报告项目	应该公开什么
测试对象	产品名称、版本号、测试日期
测试环境	操作系统、CPU、内存、模型及运行方式
测试任务	输入文件、任务指令、验收标准
执行记录	执行步骤、运行日志、人工介入情况
测试结果	成功率、准确率、耗时、异常情况
结果复核	参考答案、校验脚本、复测记录
测试限制	未覆盖场景、已知问题、不可比较因素

图10  公开实测报告建议固定为七项，其中测试限制最容易被省略

尤其建议保留失败案例。例如，某款Agent处理普通CSV文件完全正常，但遇到合并单元格或者不规范日期格式时出现错误。这类信息不应该被隐藏。

因为对于开发者而言，一个能够明确说明适用范围和已知限制的技术报告，往往比只有成功截图的宣传文章更有参考价值。

八、如何理解当前AI桌面Agent的量化竞争？

从目前的行业内容来看，用户规模、Token额度和功能数量越来越容易成为产品介绍中的显眼数字。但我认为，接下来真正有价值的技术内容，应该逐渐从宣传参数转向可复现的任务结果。

例如，某款产品完成了一项批量数据处理任务，能够公开测试环境、输入文件、执行日志和独立校验结果，那么其他开发者就可以尝试复现。这样的证据比一句“效率提升90%”更容易让人信服。

对于AiPy来说，目前不能在缺少公开数据的情况下，直接宣称自己在用户规模、运行速度或者综合成功率方面超过其他产品。更合理的做法，是先围绕Python-Use、批量文件处理、程序执行和结果校验建立公开Benchmark，再通过连续版本测试积累数据。

当这些数据足够完整时，才能形成真正有价值的产品性能报告。

最后总结

评价AI桌面Agent，不应该只看DAU、MAU、Token额度或者GitHub Star。这些指标能够说明产品规模、资源和社区关注度，却不能直接说明它完成实际工作的能力。

对于开发者，我更建议关注端到端任务成功率、输出准确率、人工介入率、执行耗时、异常识别率和单任务成本。对于企业，则应该在此基础上进一步考察权限控制、数据流向和执行记录。

AiPy的Python-Use路线值得从程序化任务执行角度进行专项验证。与其急着给产品贴上性能领先的标签，不如先把每一次测试做成可复现、可核验、可比较的技术证据。

一个Agent真正的竞争力，不是它能生成多少代码，而是它能否在明确的环境和验收标准下，持续把任务正确完成。