全面的评价下computer use对于frontier模型，coding agent，通用agent三方面到底有没有用，值不值得放大量时间去钻研。以及说去对比browser use和mcp或者其他潜在方案

Computer use 有用，但“模型应该具备这个能力”和“应用开发者值得把大量时间押在它上面”，是两回事。 我的判断是：对 frontier 模型，它是重要的训练与评测方向；对 coding agent，最有价值的是补齐运行、观察、验证的闭环，不是用鼠标替代终端；对通用 agent，它是覆盖长尾软件的重要能力，但通常不应该成为所有任务的默认执行方式。 如果你是以开发产品为目标，我更建议深挖“混合工具执行、状态管理和验证”，而不是单押截图点鼠标。 一、先用一个具体任务把概念分开 假设让 agent 完成：从业务系统导出本月数据，生成报表，上传到另一个系统。 如果系统提供合适的 API，直接取数据、处理文件、上传，通常最清晰。 如果没有 API，但能在网页里操作，可以通过浏览器读取页面结构，找到“导出”按钮，下载文件。这不一定需要模型看整张屏幕、猜坐标。 如果目标系统是只能通过远程桌面访问的旧软件，既没有可用 API，也拿不到有意义的页面结构，这时截图、鼠标、键盘就很有价值。 如果只是生成报表，能通过代码处理文件，就没必要让模型逐个点击电子表格单元格。 所以，合理方案往往是： API 取数据，代码做计算，浏览器上传，遇到特殊桌面界面才启用 computer use。 重点不是“全程像人一样操作”，而是“可靠地交付结果”。 这里也要澄清：computer use、browser use 和 MCP 不是同一层面的三个竞品。 Computer use 通常指操作计算机界面的能力；这里主要讨论截图加鼠标键盘的桌面操作。 Browser use 是浏览器内的操作能力，可以用 DOM、可访问性树，也可以用截图和坐标。Browser Use 还是一个具体项目的名字，不能把项目和能力完全等同。 MCP 是连接工具与数据源的协议。它既可以承载业务 API，也可以承载浏览器操作，甚至桌面操作。Playwright MCP 本身就是“browser use 和 MCP 同时成立”的例子。 二、对 frontier 模型：值得投入，但不是通用智能的单项证明 举个例子：让模型修改一张演示文稿，把指定图表放到正确位置，保持其他内容不变，导出后检查是否溢出。 它需要的不只是认出一个按钮，还包括理解目标、定位对象、操作、观察变化、发现错误、恢复，以及判断什么时候真的完成。 这使 computer use 成为一个很有价值的研究环境：模型的理解会变成行动，行动的后果又会反馈回来。 它对 frontier 模型的价值主要在三个方面。 第一，扩大可操作的软件范围。 不必等每个软件厂商都提供 agent 专用接口，模型也有机会完成任务。这是 GUI 作为通用交互入口的战略价值。 但“接口形式通用”不等于“所有软件都能熟练操作”。专业软件的领域知识、隐藏状态和复杂流程依然需要学习。 第二，训练和评测长程交互能力。 文本回答可以写得非常顺，但实际操作会暴露：是否记得约束、能否判断保存成功、页面变化后会不会重新观察、遇到缺失信息会不会问人。 这些能力比单纯的点击精度更接近真实 agent 的瓶颈。 第三，提供可验证的交互任务。 在可重置的环境里，可以用文件内容、应用状态和最终产物判断任务是否完成。这有利于构建训练与评测闭环。 但成本也很实在：环境维护、重置、任务生成、奖励设计、长轨迹推理，以及防止模型钻评分规则的空子，都不是免费获得的。 有一组数据特别能说明边界。 OpenAI 在 2026 年 3 月的 GPT‑5.4 发布文中报告，OSWorld‑Verified 成功率为 75.0%。但 2026 年 6 月的 OSWorld 2.0 论文，把任务扩展到 108 个长程工作流，人类完成任务的中位操作时间约为 1.6 小时；论文所测最强配置在 500 步预算下，严格完整完成率只有 20.6%，部分得分为 54.8%。 这不是同一套题的成绩下降，也不是当前所有模型的最新排名。它说明：短任务表现很好，并不意味着长程工作已经解决。 论文归纳的主要失败还不只是点不准，而是丢失约束、漏看中途信息、猜测而不询问、跳过验证。 因此，我认为 frontier lab 值得大量研究这个方向，但更值得研究的是长程状态、动态反馈、纠错和安全，不只是继续刷坐标定位分数。 也不能仅凭 computer-use 分数提高，就推断数学、代码或通用推理一定同步提高；这种能力迁移需要单独实验。 三、对 coding agent：非常有用，但价值容易被归错因 假设 agent 做完一个数据看板，编译和单元测试都通过了，但手机尺寸下筛选按钮被遮住，图表标签重叠，点击提交没有任何反馈。 只读代码和测试输出，不一定能发现这些问题。让它实际打开网页、操作并查看渲染结果，就能补齐交付闭环。 但这个过程中至少有三种不同能力： 看见渲染结果，是视觉能力。 读取 DOM、控制浏览器、获取控制台和网络信息，是浏览器工具能力。 操纵整个桌面、处理原生窗口，是桌面 computer use。 不能把前两者带来的所有收益都记到第三者头上。 我的优先级是： 后端、算法、库开发：优先文件编辑、终端、测试、调试器和运行日志。纯 GUI 操作通常是低优先级。 Web 前端、全栈：很值得接入浏览器执行和截图检查，但通常先用 Playwright 一类的结构化操作，再补视觉观察。 原生桌面软件、复杂桌面集成、只能通过 GUI 触发的流程：完整 computer use 的价值明显更高。 最理想的开发闭环是： 修改代码，运行应用，复现问题，读取相关日志，检查界面，修复，再把可重复的行为固化为测试。 不是每次回归都让大模型从零自由探索一遍。 微软 Playwright MCP 的当前 README 也明确提示：已有 coding agent 的场景，可以考虑 CLI 加 Skills，以减少工具定义和冗长页面快照对上下文的占用。 不过这不代表 CLI 天生优于 MCP。状态能否保留、输出是否精简、工具能否按需加载，都取决于实现。CLI 也可能输出大量垃圾，MCP 也可以做得很克制。 所以对 coding agent，我的结论是：值得花时间研究“浏览器与视觉验收闭环”，不值得为了看起来更自主，让它用 GUI 完成本来终端一条命令能做的事。 四、对通用 agent：长尾覆盖很重要，但商业价值取决于任务分布 通用 agent 最容易遇到的问题是：用户希望它办的事，恰好不在已有连接器覆盖范围里。 比如从某个小众供应商门户下载文件，再上传到一个老旧内部系统。开发者不可能提前为所有网站做集成，GUI 就提供了额外的可达路径。 因此，computer use 不只是玩具，也不永远只是兜底。对于“软件很多、接口很少、任务变化大”的产品，它可能就是核心执行能力。 但任务分布不同，结论会完全不同。 如果每天要处理大量同类订单，系统也有稳定 API，让模型逐个打开页面操作通常不划算。 如果用户偶尔提出一个从未集成过的跨软件任务，为此开发专用连接器可能更贵，这时 GUI 即使慢一些，也可能有经济价值。 如果任务涉及付款、删除记录、对外发送信息，则“偶尔成功”远远不够。监督和失败补救成本可能超过节省的操作时间。 我会按这个方式算账： 净收益 = 节省的人工成本 − 推理与环境成本 − 人工监督成本 − 失败补救成本 − 集成维护成本。 GUI 可能降低预先集成成本，却提高单次执行和监督成本；API 往往相反。没有脱离任务频次、风险和接口条件的绝对赢家。 通用 agent 应该追求结果覆盖广，不是操作方式始终一致。 五、与 browser use、MCP 和其他方案怎么选 API、SDK、业务工具 适合语义明确、批量、高频、需要可靠回执的操作。 优势是直接表达业务动作，例如“创建订单”，而不是把它拆成几十次点击。更容易围绕参数校验、权限、幂等和审计做工程保障。 限制是接口可能缺失、功能不完整，或者用户无法获得相应授权。也不能把 API 返回成功等同于业务结果必然正确。 浏览器结构化操作 适合网页表单、后台系统、数据下载、Web 应用测试。 能按按钮名称或元素引用操作，通常比固定坐标更能抵抗布局变化；还能读取控制台、网络和页面结构。 限制是页面语义质量、动态 DOM、自定义控件等。Canvas 或远程桌面画面可能无法提供有意义的结构。 浏览器内的视觉操作 适合视觉布局检查、图表、Canvas、结构化定位失效的区域。 很多任务到这里就够了，并不需要运行完整桌面。结构化读取和视觉观察可以混用，而不是二选一。 完整桌面 computer use 适合原生应用、跨窗口操作、系统对话框、远程桌面，以及其他接口无法覆盖的流程。 优势是覆盖面，代价是更多隐含状态：窗口焦点、缩放、遮挡、弹窗、加载时机、剪贴板等。你看到的屏幕与实际执行时的屏幕也可能不一致。 系统可访问性接口、应用插件、脚本接口 这是容易被忽略的中间层。 有的桌面软件虽然没有 Web API，却有可访问性树、自动化接口或插件机制。此时未必需要退回纯坐标操作。 限制是平台和应用支持差异，需要适配。 确定性工作流与 RPA 适合已经跑通、重复度高、变化可控的流程。 可以让 agent 负责探索、理解例外和修复，让程序负责稳定执行。不是每一步都需要重新让模型做决定。 Skills 适合沉淀操作方法、前置条件、异常处理和验证规则，但本身不是新的执行通道，也不会自动赋予权限。 MCP 适合把以上某些能力标准化接入不同 agent。 真正影响成功率的，往往是 MCP 后面的工具粒度、实现和反馈质量，而不是“用了 MCP”这件事本身。 工程上的默认思路是：先选满足任务要求、权限可控、反馈清晰的接口；缺少覆盖时再扩展到结构化浏览器和视觉操作。若任务本身就是检查 GUI，则直接从 GUI 开始，不必机械地先绕一圈 API。 六、真正值得钻研的难点 我认为最值得投入的不是“让模型再多点对几个按钮”，而是下面这些问题。 状态管理：到底处理了哪些记录？哪些只是打开了，哪些已提交？刷新、压缩上下文或进程中断后，如何恢复？ 结果验证：点击“保存”不等于保存成功。最好读取最终文件、目标系统记录或可靠回执，而不是只相信 agent 自述完成。 安全重试：提交后超时，不能直接再点一次，否则可能重复下单。需要先判断第一次动作是否已经生效。 工具切换：何时读取页面结构，何时截图，何时调用 API，何时写脚本，何时请求人工接管？ 延迟与成本：重点不只是模型出字速度，还包括连续决策轮次、页面等待、截图处理和恢复次数。批量执行可以省轮次，但也会减少中间观察机会。 权限与提示注入：网页和文档里的内容是不可信输入。它们可能诱导 agent 泄露数据或执行无关操作。MCP、API 和 GUI 都不是天然安全边界；桌面和浏览器会话还可能继承很宽的用户权限。 所以需要独立环境、最小权限、受控数据访问、关键动作确认和可审计记录，而不只是提示词写一句“不要做危险操作”。 这些能力即使将来底层模型大幅进步，仍然有产品价值。 七、值不值得你投入大量时间 如果目标是 frontier 模型研究：值得，尤其是长程交互、训练环境、奖励设计、状态恢复、视觉动作和安全评测。但要避免只追一个公开榜单。 如果目标是 coding agent 产品：值得先把 browser use、截图验收、调试信息和自动测试做深。完整桌面控制应由真实需求推动，而不是默认成为架构中心。 如果目标是通用 agent 产品：值得掌握并接入，但不建议在没有目标用户和任务数据前，花几个月重造一个纯截图桌面框架。 如果是个人学习或求职：做一个带评测、失败分析和恢复机制的混合执行项目，比只做“输入一句话，模型帮我点网页”的 demo 更能体现技术深度。 我的具体建议是先做一轮两周左右的验证，而不是立即长期押注。这是建议计划，不是已有实验结果。 挑 30 个真实任务，覆盖结构化网页、视觉网页、桌面软件和跨应用流程。 对比纯视觉、结构化工具、混合路线。缺少接口的任务要标记为不覆盖，不能偷偷排除。 尽量固定模型版本、初始状态、权限和预算，每个任务重复运行数次，避免挑成功录像。 记录完整完成率、人工介入次数、总耗时、总成本、误报完成率和有副作用的错误。基础设施故障也要记账，但与模型决策错误分开分析。 成功标准放在最终产物或系统状态上，不放在模型最后说了什么上。 然后