忽视界面无法解决计算机使用问题
摘要
本文认为,当前的人工智能计算机使用代理通常通过直接访问API或编写脚本绕过实际用户界面,导致基准测试结果虚高,实际表现不可靠。文章指出,忽视界面是一种有缺陷的方法,无法泛化到杂乱的GUI环境中。
暂无内容
查看缓存全文
缓存时间: 2026/07/30 16:51
# 计算机使用远未解决
来源:https://steelmanlabs.com/blog/computer-use-is-far-from-solved
Steelman Labs · 笔记
2026年7月
目前,智能体化的计算机使用是人工智能在现实世界中产生最大影响力的杠杆之一。基于LLM的智能体正在改变软件开发,但大多数脑力工作仍然受限于软件的使用。当编码智能体已经如此出色时,人们自然会问:它们能否在政府门户网站上帮我报税、修复文本文档、测试网站?
我们尚未达到那一步。在 OSWorld-V2(一个衡量长周期计算机任务的领先基准)上,最佳模型仅达到 *20.6%* 的任务完成率。在 Agents' Last Exam 上,最佳结果为 *26.2%*。习惯于LLM在聊天交互中令人印象深刻表现的用户,期望在计算机使用上获得类似的结果。但他们的体验却是挫败感:智能体不可靠、速度慢且成本高。目前,还不如自己动手做。
散点图显示了 OSWorld-V2 的二进制奖励(y轴,最高约20%)与每个任务的输出 token 数(x轴,最高240K)之间的关系,涉及 GPT-5.5、Claude Opus 4.7 和 4.8、Claude Sonnet 4.6、MiniMax M3 和 Qwen 3.7-Plus,标记大小表示推理努力程度。OSWorld-V2 完成率(二进制奖励)与每个任务的输出 token 数,覆盖不同模型和推理努力设置。前沿最高约20.6%——每提高一个奖励百分点,token 消耗急剧增加。
在2024-2025年,每个主要AI实验室都推出了计算机使用原型。当时,它们在 OSWorld、WebArena、AndroidWorld 和 WebVoyager 等基准测试中表现出色,任务完成率从60.76%到97.4%不等。这些基准测试很适合这些智能体。除了少数例外,每个任务都被呈现为静态环境,带有清晰的文本表示和预定义的小型操作空间——这与现实世界中混乱的界面完全不同。因此,排行榜被夸大,用户期望与实际性能之间存在差距。
到目前为止,改进计算机使用的答案仍然是同样的老方法:更大的模型和更多的 token。*在我们看来,这条路是一条死胡同。*既有的方法在舒适环境中表现良好,但无法推广到真实的GUI工作。
## 计算机使用的核心缺陷
计算机使用有一些众所周知的难点,如感知、规划以及在长任务中保持上下文。这些问题社区正在解决,其中一些确实需要更智能的模型。然而,一个更简单的问题却较少受到关注,而它可能就是瓶颈:*使用界面的智能体大多在回避界面。*
在 OSWorld-V2 上,最佳模型通常根本不在操作 UI。在任务052(预订酒店套房)中,GPT-5.5 注入 JavaScript 读取网站源码,找到内部 API 端点,并通过 POST 提交了预订。在任务065(购买火车票)中,GPT-5.5 和 Claude Opus 都跳过了网站,直接向 API 发送 POST 请求。在任务003(在 GIMP 中合成两张图片)中,GPT-5.5 用 Python 编写了脚本。总体而言,大多数任务并非按预期方式解决,而是被绕过了。
智能体跟踪卡片,步骤195:一条助手消息显示“让我尝试通过 API 安全地将 last_score 更新为 150”,随后执行了一个“输入文本”操作,grep 了一个 JavaScript 文件中的 replaceState、PUT 和 /state——智能体直接编辑游戏状态,而不是玩游戏。OSWorld 任务068:Claude Opus 4.7 没有通过 UI 玩游戏,而是直接攻击状态——“通过 API 将 last_score 更新为 150”——直接 POST 分数,而不是通过游戏获得。
这可以被忽视甚至被视为优势。如果能调用 API,何必去碰 GUI?然而,有些工作只能通过 UI 完成。绕过 UI 可能会产生意想不到的副作用,因为软件并非设计为以这种方式使用。更重要的是,许多工作通过 UI 完成反而更容易——这对于实现经济上可行的计算机使用很重要。
点击按钮、填写表单和浏览网站并非困难任务。一个人可以不假思索地完成。逆向工程一个网站的 API、反汇编其 JavaScript 或从头编写一个合成器脚本,要比它所取代的点击操作复杂得多。直接通过 UI 操作会更便宜、更快、也更可靠。
然而,对于前沿模型来说,这并非一个选项。WebGames 基准测试挑战模型完成需要普通网站用户反应速度和运动控制的简单任务。人类的成功率超过 *95%*,但模型尽管智能,却远远落后。这个差距不会随着更多 token 或参数而缩小。这就是为什么在长周期任务中,模型会选择困难的解决方案:它们无法像人类一样使用界面,因此不得不绕过这一限制。
这导致了次优的计算资源分配。智能体将大部分动作花费在感知和行动上。OSWorld 2.0 的图10分解了动作预算:视觉定位、低级操作和工具使用开销占据了其余部分。规划如何解决一个任务本应比点击按钮更难,但大部分计算却用于观看和点击。推理、反思和错误恢复只能得到剩余部分。
分组柱状图显示了五个模型在推理、感知、行动和修正类别中的动作预算份额。感知(视觉定位、信息提取)和行动占据了预算的大部分。图10,OSWorld 2.0——按类别划分的动作预算份额(不同模型)。感知和行动占主导地位;推理、反思和修正只能得到剩余部分。
在我们看来,这就是智能体化计算机使用的核心问题:*我们使用万亿规模推理器来绕过点击操作。*正确的操控能力将使智能体能够将精力花在解决任务上,而不是为了绕过界面限制而进行黑客式操作。这将实现更快的执行速度、更少的浪费 token、更高的可靠性和更好的长周期性能。
## 迈向智能体化计算机使用的“钢铁侠”方案
迄今为止,所有计算机使用解决方案都建立在截图-工具调用循环之上:
1. 获取截图和环境的文本表示。
2. 让 LLM 对其进行推理。
3. 输出一个工具调用,如 `click(elem[#submit])`。
4. 执行。
5. 重复。
这是编码智能体 ReAct 循环在 UI 交互上的自然扩展。但是,对于此类智能体来说,简单的 UI 操作仍然困难,因为它们使用同一个大型模型来做所有事情。结果导致智能体过度依赖文本,丢失所有时间信息,并且无法及时反应。这种方法与 UI 对其用户所做的一切假设背道而驰。
增加更多参数和 token 无法解决问题。即使将此循环执行速度提高10倍,也只会更快地填满 LLM 的上下文。为了构建可用的计算机使用智能体,我们需要挑战核心假设。
在 Steelman Labs,我们围绕一个核心原则开展工作:*一个计算机使用智能体必须能够使用任何人类可以使用的界面。*为了满足这一条件,我们将规划与执行分离,并引入智能体的“系统1”:一个负责运动控制的操纵器。我们采用视觉优先的方法,将屏幕视为动态环境,并追求人类水平的反应时间。
您的浏览器无法播放嵌入式视频——[下载演示](https://steelmanlabs.com/blog/videos/steelman-demo.mp4)。
演示:一个 Steelman Labs 模型驱动实时 UI——实时感知和行动。
相似文章
最大的AI问题真的是界面而不是模型吗?
本文探讨了AI最大的挑战是否是界面设计而非模型改进,指出当前基于聊天的交互未能捕捉人类在任务中使用的丰富上下文。
下一代AI界面需要的远不止更好的聊天窗口
文章探讨了基于聊天的AI界面的局限性,并提出未来的AI代理需要更好的图形用户界面以及跨应用程序操作的审批机制。
GUI vs. CLI:仅屏幕和技能中介的计算机使用代理的执行瓶颈
本文研究了计算机使用代理中的执行瓶颈,比较了仅屏幕的基于GUI的方法与基于技能中介的CLI方法,识别了关键性能差异。
AI代理真的在杀死UI吗?(9分钟阅读)
这是一篇观点文章,认为AI代理并没有杀死UI,而是将产品转向混合界面:既需要面向代理的引导,也需要面向人类用户的控制,用于批准、审查和编排。
如何停止构建用户无视的智能体?
关于AI智能体为何难以获得采纳的反思:它们迫使用户切换上下文,产生的摩擦超过了感知价值。作者建议将智能体设计为直接集成到现有工作流程中。