耶鲁大学、宾夕法尼亚大学、北卡罗来纳大学联手打造"电脑考官"：AI助手到底会不会用电脑？

这项由耶鲁大学NLP实验室牵头，联合宾夕法尼亚大学和北卡罗来纳大学教堂山分校共同完成的研究，发表于2026年5月，以预印本形式挂载在arXiv平台，编号为arXiv:2605.19769。研究成果以"OpenComputer: Verifiable Software Worlds for Computer-Use Agents"为题正式发布，感兴趣的读者可通过该编号检索完整论文。

你有没有想过，如果AI真的能像人一样使用电脑，它到底会不会用？不是那种"看起来在用"，而是真的把任务做对了？这个问题听起来简单，但背后藏着一个让研究者头疼已久的难题：你怎么知道AI真的完成了任务，而不只是做出了一副"完成了"的样子？

以一个具体的场景来理解这个难题。假设你请AI帮你在LibreOffice表格里填写佣金数据，并用嵌套公式计算各档位的提成比例。AI操作完毕，截图一看，表格看起来整整齐齐，字体加粗，列标题清晰。但如果有人悄悄打开文件，发现那些"公式"其实只是手动输入的数字，根本没有真正的IF嵌套逻辑呢？从截图上几乎看不出来，但任务根本没完成。

这就是这篇研究要解决的核心困境：如何给AI"电脑使用能力"建一套真正可靠的考试系统，而不是靠"看图猜答案"来打分。研究团队给这套系统起名叫**OpenComputer**，它是一个能够自动生成真实电脑任务、并用程序代码直接检查任务结果的完整框架，目前已覆盖33款桌面应用程序和1000道经过严格验证的任务题目。

---

一、为什么给AI"电脑考试"这么难

要理解OpenComputer解决的问题，先得弄清楚给AI出"电脑操作题"到底难在哪里。

出一道电脑操作题，远不是写一句"帮我在Chrome里添加书签"那么简单。出题的人要先把电脑环境准备好：浏览器里得有合理的历史记录，书签栏得有一定的初始状态，文件夹得存在，该登录的账号得登录。这些"布景工作"全都要手工完成，而且每道题都不一样，做起来极其耗时。据研究团队描述，这种准备工作"单调、高度依赖具体应用、难以标准化"，导致大规模出题几乎是不可能的任务。

更麻烦的是验证环节。电脑任务完成与否，很多时候根本不体现在截图上。一封邮件有没有真正发送？一个配置文件有没有正确写入？一个文档的元数据有没有被修改？这些结果藏在应用程序的内部状态里，截图根本看不到。于是很多系统退而求其次，用"让另一个AI来看截图打分"的方式来评估结果，也就是所谓的"AI当裁判"（LLM-as-a-judge）。

然而AI裁判有个根本性的缺陷：它只看表面。一个视觉上看起来"差不多对"的结果，很可能被它打了满分；而一个本质上完全正确但截图不够清晰的操作，可能被它误判为失败。更糟糕的是，同样的任务换个截图角度或者换个AI模型来判，结论可能完全不同——这对一个"考试系统"来说是致命的。

正是在这样的背景下，研究团队提出了一个核心理念：验证不是考试的附属品，而是整个系统的设计核心。从一开始就得想清楚"怎么检查答案"，才能知道该出什么题、该怎么布置环境。

---

二、OpenComputer的四个组成部分

整个OpenComputer框架可以用一个"流水线工厂"来理解：原材料是各种桌面应用程序，成品是一道道带有标准答案检验机制的考试题，中间经过四道工序，环环相扣。

**第一道工序：给每个应用程序装上"X光机"**

研究团队为33款桌面应用程序分别编写了专属的Python检查模块，每个模块都能像X光机一样透视应用程序的内部状态，而不是只看它的外观。这些"X光机"被称为验证器（Verifier）。

不同的应用程序有不同的透视方式。Chrome浏览器和VS Code编辑器可以通过一种叫做CDP（Chrome DevTools Protocol）的调试接口直接查询内部状态，相当于走了应用程序的"后门"。LibreOffice这类办公软件有一套叫做UNO的专属接口，可以直接读取文档里的单元格内容、公式逻辑和格式信息。Chrome、Firefox、VS Code、Darktable、Obsidian、Zotero等应用把很多设置和历史记录存在SQLite数据库文件里，验证器可以直接查询这些数据库。VLC媒体播放器和Gedit文本编辑器则通过D-Bus这个系统级消息总线来传递状态信息。GIMP图像编辑器可以用Python的Pillow图像库直接读取图片文件。Blender三维软件支持在无界面模式下运行Python脚本来检查场景里的对象。Audacity音频软件的输出文件可以用ffprobe工具分析媒体属性。

每个验证器被设计成一个命令行工具，调用不同的子命令可以获得JSON格式的结构化输出，比如"浏览器里有没有名叫X的书签""表格第三行第二列的值是不是0.08""Blender场景里有没有一个名为Rig的Empty对象"。

验证器的开发流程非常严格，完全按照软件工程的标准来做。每个验证器都要经过单元测试和集成测试，包括正常情况、异常情况（比如文件不存在、应用没有运行）、以及JSON输出格式是否正确。对于文档类应用，测试用的文件不是随便凑出来的玩具数据，而是带有真实结构和内容的合成文件。出了问题的检查函数要进入"调试-修复-重试"的循环，直到稳定可靠为止。

**第二道工序：让验证器自我进化**

即使经过了严格测试，验证器也可能在真实使用中出错。实验室里的测试毕竟是人工设计的场景，而真实的AI在操作软件时会产生各种意想不到的状态。为此，研究团队设计了一个叫做"自我进化验证层"的机制。

这个机制的工作方式像是一次内部质量审计。首先，针对每个应用程序，研究团队生成大约15道难度适中的"校准任务"，让一个能力较强的AI去完成这些任务，记录下完整的操作轨迹和最终状态。这批任务不是为了测试AI能力，而是为了"压力测试"验证器本身。

接着，对于同一个最终状态，让两个"评判者"独立打分：一个是程序化验证器，直接检查应用程序状态；另一个是AI评委，通过查看截图和操作记录来判断。然后把两个评判者的结论逐条对比，找出分歧。

分歧被分成两类：如果是AI确实没完成任务，那这个分歧就被丢弃；如果是验证器本身判断出错了，那就把这个错误作为反馈信号，去修复验证器的代码或文档。

修复完的验证器在同一个缓存的最终状态上重新运行，看看分歧有没有消除。这个过程最多迭代三轮。每次修复发现的问题和解决方法都会被记录下来，作为"应用程序专属经验"，在未来生成新任务时可以复用。

研究团队特别强调，这个自我进化步骤有一个严格的边界：只能修改验证器的代码和文档，绝对不能修改AI的操作轨迹、沙盒状态、任务目标或预期结果。这保证了进化方向是让验证器更准确，而不是让标准去迁就有缺陷的验证器。

**第三道工序：生成真实可检验的任务**

有了可靠的验证器，就可以大规模生成任务了。任务生成管道的设计哲学是先想"用户想干什么"，而不是先想"验证器能查什么"。这个顺序很重要，因为如果反过来，生成的任务就会过于偏向"容易检查"的方向，失去了真实用户场景的多样性。

候选任务首先要通过一个复杂度过滤器。研究团队明确倾向于多步骤、有一定难度的工作流，那种过于简单、线性或者难以提供有意义输入文件的任务会被排除。

通过筛选的候选任务接着被"配对"到验证器上。如果任务的预期结果已经有现成的检查端点可以验证，就直接保留。如果任务的结果原则上可以被检查、但验证器还没有对应的端点，就按照第一道工序的流程扩展验证器，新增一个专门的检查端点。如果任务的结果从根本上无法被程序化检查，就排除在外。

最后，系统为每道题生成并打包所需的初始文件：文档、文件夹、配置文件、应用程序数据库等等。每道题最终以一个JSON文件的形式存储，包含三个部分：给AI看的自然语言任务描述、用于初始化沙盒环境的脚本、以及机器可执行的成功判定标准。

为了防止同一个应用程序的任务越来越同质化，研究团队还设计了一个"任务扩展"流程：定期审查每个应用的任务集，按功能区域找出覆盖缺口，针对性地补充新任务类型。

**第四道工序：让AI实际上场，用程序打分**

评估的时候，系统把验证器和任务文件上传到一个干净的沙盒桌面环境，启动目标应用程序，然后运行截图-动作循环：抓取当前桌面截图，送给AI，AI预测下一步操作，系统执行操作，记录推理过程、动作序列和截图。

AI停止操作或达到步数上限后，系统对有"保存"需求的应用程序尝试执行一次最终保存操作，然后在沙盒内执行验证器命令。最终得分是通过检查项数量除以总检查项数量，支持按比例得分，也就是说即使没有全部完成，完成了一部分也能得到对应的分数。

这套评分机制既是精确的（每一条判定标准都有程序直接执行），又是可审计的（任何人都可以重新运行验证器命令，独立核实结果）。

---

三、一道题、两种判法：验证器到底比AI裁判强多少

研究团队从1000道题中随机抽取120道，把AI完成的轨迹同时交给三方打分：真人注释员、AI裁判和硬编码验证器。结果非常说明问题。

在任务级别的判断上，硬编码验证器和人类的一致率达到94.1%，也就是120道题里有113道的判断和人类一致。AI裁判的一致率是79.2%，只有95道和人类一致，差了整整18道题。在更细粒度的单条检查项级别，硬编码验证器的一致率达到97.3%，AI裁判只有92.2%。

为什么差距这么大？研究团队给出了两个典型的失败场景。

第一种情况出现在界面密集的应用程序里，比如电子表格软件。一个AI在操作时把"alpha"和"beta"两个词打进了同一个单元格，而正确做法是分别填入相邻的两个单元格。从截图上看，表格里出现了这两个词，一切看起来正常。AI裁判很可能判为通过，因为它只能通过像素判断，而单元格之间的分界线在高分辨率截图里极细。但硬编码验证器直接读取工作簿文件，立刻就能发现两个词在同一个单元格里。

第二种情况出现在终端密集的工作流里，比如Blender或开发工具的任务。成功与否往往取决于终端的滚动历史、错误日志或中间文件的存在与否。截图只能捕捉一个时刻的一个窗口状态，AI裁判需要从有限的视觉信息里推断整个执行过程，非常容易误判。程序化验证器则可以直接检查文件是否生成、日志里有没有错误行，完全不依赖截图。

---

四、自我进化到底修了多少漏洞

研究团队专门用450道校准题测试了自我进化机制的实际效果。

在450次执行中，有159次出现了程序化验证器和参考评估之间的分歧。经过逐一分析，其中76个分歧被归类为验证器本身的错误，而不是AI确实没完成任务。自我进化程序成功修复了其中68个，修复率达到89.4%。

从修复速度来看，47个问题在第一轮迭代就解决了，15个需要第二轮，6个需要第三轮（也就是研究团队设定的上限），剩余8个在三轮内没能修复。

把自我进化前后的验证器放回同一批120道人工标注题上测试，进化前验证器和人类的一致率是85.2%，进化后提升到94.1%，整整提高了8.9个百分点。

论文附录里还给出了一个具体的案例，展示了这个机制如何工作。任务是在Darktable照片管理软件里导入三张图片、创建一个叫做"batch_processed"的标签、把标签挂到三张图片上，并分别设定不同的星级评分。AI完成了所有操作，AI裁判也判定全部通过。但程序化验证器一开始却判定四条与标签相关的检查项全部失败。

排查后发现原因：验证器的代码假设标签信息存在library.db这个数据库文件里，但实际上在当前版本的Darktable中，标签定义被存储在另一个文件data.db里，图片与标签的关联才存在library.db。这导致验证器查询时找不到相关表，把所有标签相关的判断都当作"不存在"处理。自我进化机制识别出这是验证器的错误，把SQL查询的目标数据库改正了，跨数据库的关联查询也重写了，问题随即解决。整个过程不改动任何任务描述或AI操作记录，只修改验证器内部逻辑。

---

五、当前最强AI在这套考题上考了几分

研究团队用8个模型测试了OpenComputer，涵盖了目前最顶尖的商业模型和开源模型。

测试结果显示，即便是最强的模型也未能全部通关。GPT-5.4表现最好，成功完成了68.3%的任务，平均得分（按通过检查项比例计算）达到88.4%。也就是说，GPT-5.4差不多每三道题就有一道没能完全做对，虽然它在大多数任务上都取得了一定进展。Claude-Sonnet-4.6的成功率是64.4%，平均得分76.6%；Kimi-K2.6成功率58.8%，平均得分70.7%。

GPT-5.4还有一个明显特点：它每道题平均只用19步就能完成，而Claude-Sonnet-4.6需要31.5步，Kimi-K2.6需要35.7步。这是因为GPT-5.4经常把多个低级操作合并成一步执行，而且它不输出冗长的推理过程，只输出可执行动作，减少了很多不必要的开销。

中等规模的开源模型Qwen-3.5-27B成功率是32.3%，而Gemini-3-Flash只有16.4%（需要注意的是，Gemini-3-Flash在这套设置下并非使用原生动作空间，而是被改造成用Qwen风格的指令格式来操作，可能影响了它的发挥）。

更引人注意的是小型开源模型的表现断崖。GUI-OWL-1.5-8B在OSWorld-Verified基准测试上报告了52.3%的成绩，但在OpenComputer上只有5.7%；EvoCUA-8B在OSWorld上报告46.1%，在OpenComputer上只有10.9%。这种大幅跳水说明，在OSWorld上表现好看的模型，其能力可能高度依赖那个特定测试集的特征，换到更广泛、更多样的软件环境后，能力会急剧萎缩。

研究团队还专门做了一个GUI操作与命令行操作的对比实验。他们从1000道题里挑出14个可以用命令行完成的应用程序的343道题，分别让GUI方式的GPT-5.4、GUI方式的Claude Sonnet 4.6，以及命令行方式的Claude Sonnet 4.6（配合Claude Code工具）来完成。结果是GUI方式的GPT-5.4以75.2%的成功率领先，GUI方式的Claude Sonnet 4.6是73.0%，命令行方式的Claude Sonnet 4.6是67.2%。虽然GUI方式成功率更高，但命令行方式在速度上有显著优势：Claude Code平均每道题只需141秒，而GPT-5.4 GUI方式需要288秒，Claude Sonnet 4.6 GUI方式更是需要622秒。这说明视觉交互确实提供了很多有效的操作线索，不是简单地"多此一举"，但命令行方式在效率上的优势也不可忽视。

---

六、OpenComputer目前的边界在哪里

研究团队在论文里坦诚地说明了这个系统的局限。

并非所有桌面任务都能被程序化检查。有些任务的成功依赖于视觉或空间判断，这类标准很难用应用程序的内部状态来表达。以Draw.io流程图工具为例，验证器可以确认图形对象、标签文字和连接线的存在，但很难用代码可靠地判断某条箭头在视觉和语义上是否以正确的方式连接了两个特定的方框，因为"正确的方式"在某些情况下依赖于位置关系和渲染结果，而不只是连接关系的记录。类似的情况还出现在需要判断空间布局、视觉对齐或排版效果的场景里，这些属性只能从最终渲染的画面上看出来，文件格式或API接口未必能完整暴露。

面对这种情况，研究团队的做法是把这类标准标注为"需要AI视觉判断"，而不是当作可程序化验证的条件来处理。为了保持正式基准测试的可审计性，这17道包含此类标准的任务被排除在1000道正式题目之外，只保留用于分析研究，不参与模型评分。研究团队表示，这些任务会随代码库一起发布，并附上识别视觉判断标准的流程和AI裁判管道的说明，以便未来的研究者在此基础上探索混合验证方案。

---

七、这套系统的实际意义

说到底，OpenComputer做的事情，是给"AI会不会用电脑"这个问题提供了一个更诚实的回答方式。

当前大多数对AI操作电脑能力的评估，要么依赖人工出题和人工判分（成本极高），要么依赖AI看截图来打分（可靠性存疑）。OpenComputer的思路是把验证这件事做到"硬核"：直接查应用程序的数据库、直接调调试接口、直接读文件结构，而不是猜。这种方式的代价是需要为每个应用程序单独开发检查模块，但一旦开发完成，就可以无限复用，而且结果完全可重复——任何人在任何时间重新运行验证器，得到的结论都一样。

对于AI能力评估来说，这意味着一个更可靠的"尺子"。从实验结果来看，即便是目前最强的商业模型，在这把尺子面前也还差得远——接近三分之一的任务无法完整完成。对于开源模型来说，差距更为显著，说明目前的一些"好成绩"可能存在一定程度的过拟合，真实的通用能力还有很大提升空间。

对于想要改进AI系统的研究者来说，这套框架的价值不只是评估，还在于训练数据的生成。有了机器可检验的正确答案，就可以自动筛选出真正成功的操作轨迹，用于监督学习，或者用奖励信号驱动强化学习，而不必依赖人工标注。研究团队已经把完整的代码、验证器模块、任务规范、环境初始化脚本和执行框架开源发布，支持本地Docker运行，也支持部署到AWS或其他云平台进行并行评估。

归根结底，判断AI有没有真正学会用电脑，不能只靠截图。一个合格的"AI电脑操作考试"，需要能直接核查结果的检验机制，而OpenComputer正是朝着这个方向迈出的一大步。如果你对其中的技术细节感兴趣，可以通过arXiv编号2605.19769找到完整论文。

---

Q&A

Q1：OpenComputer和OSWorld有什么区别？

A：OSWorld是一个以人工出题为主的桌面操作基准测试，依赖手工准备环境和编写验证逻辑。OpenComputer则是自动化生成任务和验证代码的框架，核心区别在于验证方式：OpenComputer用程序直接查应用程序的内部状态（数据库、调试接口、文件结构等），而不是依赖AI看截图来打分，因此结果更可靠、可重复。两者有部分模型重叠，但测试结果显示OpenComputer上的得分普遍低于OSWorld，说明它对AI能力的考察更为严格全面。

Q2：为什么开源小模型在OpenComputer上的成绩下降那么多？

A：主要原因是跨基准泛化能力不足。部分开源模型在OSWorld上取得了相对不错的成绩，但OSWorld的任务覆盖面有限，模型可能在训练或微调时接触过类似的任务模式。OpenComputer覆盖33款不同类型的桌面应用，任务更多样、要求更细粒度，模型之前学到的"套路"在新场景下就不管用了。这种大幅下降说明，在特定基准上的高分不等于真正具备广泛的桌面操作能力。

Q3：OpenComputer的自我进化验证器是怎么避免"作弊"的？

A：自我进化机制有一个硬性约束：只允许修改验证器的代码和文档，绝对不能修改AI的操作轨迹、沙盒的最终状态、任务描述或预期结果。这意味着进化的方向只能是让验证器更准确地反映真实结果，而不是通过降低标准来消除分歧。每次修复完成后，更新后的验证器会在同一个缓存的最终状态上重新运行，验证分歧是否消除。这就好比考试改卷——你可以修正评分标准里的歧义，但不能改学生的答卷，也不能改题目的正确答案。