实测两个 computer-use Agent 一个月：瓶颈不是模型而是机器占用率

每个人在基准测试 computer-use agent 时，衡量的是同一件事：任务成功率。它填对表单了吗？找到文件了吗？这些数字有用，但它们遗漏了真正决定一个 agent 是否值得运行的变量——宿主机的挂钟占用时间。

我在自己管理的基础设施上，让两个 agent 并行运行了一个月，处理真实工作。以下是我对时间都花在哪里的认知，以及为什么这个数字（而非准确率）才是应该驱动你的部署拓扑的关键。

通过其 computer-use 能力驱动的 Claude。

由 Grok 驱动的开源 agent。

一商一开，故意为之。我想把产品特定行为与类别层面的行为区分开来。几乎我观察到的一切都是类别层面的。

时间实际花在哪里

将 agent 的任务分解成阶段后，其分布与你从演示视频中猜到的截然不同：

1. 稳定等待。 每次导航和每次点击后，agent 都会等待以确认结果状态。它不能信任页面加载完成，所以会持续轮询直到有把握。这是正确的工程实践，但它也是我观察到的每条追踪记录中消耗挂钟时间最多的部分。

2. 动作启动延迟。 "决策做出"到"像素移动"之间存在不小的差距。单个动作来看很小。但当一个多步骤任务乘以这个差距，它就不再是小事了。

3. 意外状态下的消歧。 当屏幕与模型预期不符时，agent 会停下来重新定位。合理。昂贵。

4. 自我验证。 这是我没有预料到的行为。那个开源 agent 在填写表单时，逐个枚举每个 <select>，读取选项，然后截取屏幕截图来持久化这些值，以便后续可以对它们进行断言。本质上是一种回读验证——跟你会在不稳定的集成测试中写的模式相同。

最后一点是关键。agent 在无人监督的情况下优化正确性，它有实际上无限的时间预算来投入这件事。

没有人定价的不对称性

有一点值得内化：

时间对 agent 是免费的，对你是昂贵的。

agent 不会疲倦。它不知道当前任务背后还有排队的任务。花四分钟验证一个表单对它毫无成本。而你呢，你有一个支持队列和一项迁移要完成。

这种不对称性解释了为什么"等着就行"作为一种运营模式是行不通的。这不是说 agent 在绝对意义上慢得令人无法接受——而是说它们对慢的容忍度是无限的，而你的不是。

为什么这迫使你必须做拓扑决策

computer-use agent 不是像后台进程那样在应用程序旁边运行。它驱动的是和你一样的输入原语。具体来说：

• 它占用了你的浏览器——真实的配置文件，连同你的会话。
• 它占用了焦点。窗口激活是它的动作空间的一部分。
• 在任务中途干预是不安全的。你无法可靠地预测它的下一个目标元素，一次乱点的操作会改变它认为自己所处的状态。

所以宿主不是在忙。宿主被长期占用了。

将"被占用的宿主"与"无限验证时间"结合起来，你就得到了真正的发现：computer-use agent 和人类无法共享同一台桌面。不是偏好问题。这是 agent 的动作空间与你的完全重叠这一结构性后果。

解决方案是拓扑变更，不是配置变更

给 agent 自己的机器。这就是全部的干预措施。

agent 的二十分钟不再是你的二十分钟。它的验证循环跟你无关了，因为你不在看着它们。

目标机器的要求很平常：可靠的 Windows 环境、你的 agent 驱动的应用程序，以及 agent 运行时随时可用。不需要 GPU。没有什么稀有的东西。

一个容易做错的部署注意事项：计费模式在这里比实例规格更重要。agent 的重试-verify 行为产生的计费分钟数远远超过人类执行同样任务的分钟数，所以按量计费使得你的成本成为 agent 决定要多彻底的一个函数。包月托管则完全去除了这个变量。我把我的跑在 Infosaic desktops 上——每月 $14.95 的包月价格，注册后即时开通——但无论你选什么，一般性结论都成立：在这类工作负载上，可预测性比每小时便宜更重要。

我接下来会衡量什么

如果你在评估 agent，除了成功率之外，还要把这些加入你的测试工具：

• 宿主占用 —— agent 持有输入控制的挂钟分钟数
• 验证率 —— 回读而非变更的动作比例
• 恢复成本 —— 从意外状态到恢复进展的时间

成功率告诉你 agent 能否完成工作。这些告诉你让它运行你需要付出什么代价。

这是较长现场报告的开发者面向版本。更多虚拟桌面资料：infosaic.com/virtual-desktop-resources

Infosaic Technologies 自 2001 年以来一直提供云端托管 Windows 桌面。infosaic.com