如果说 2023 年是 ChatGPT 把大模型带进对话框，那么 2025 年之后真正让工程界兴奋的，是 Computer Use 智能体——一种能像人一样“看”屏幕、“点”按钮、“填”表单的 AI。它不再依赖固定的后端 API，而是直接操作图形界面，把任意软件都变成可被调用的能力。从自动填表、跨系统搬运数据，到替代脆弱的 RPA 脚本，Computer Use 正在重塑我们与软件交互的方式。本文梳理它的定义、主流方案、核心架构与落地挑战，帮你看清 2026 年人机交互的新范式。
要理解它为什么重要，得先和「传统 API Agent」做个对照。过去我们让 AI 干活，要么是调一个写好的 函数（见我们的 Function Calling 工具调用实战指南），要么是让智能体按 ReAct 循环调用工具（参考 从零手写 AI Agent：ReAct 智能体实战）。但这些都要求目标系统“开放接口”。而现实里大量软件——老旧的 ERP、只有界面的后台、网页表单——并没有给你 API。Computer Use 的价值，正是绕开了“有没有接口”这个前提，用人类的操作方式去驱动任意界面。
一、什么是 Computer Use 智能体
简单说，Computer Use 智能体 = 多模态大模型 + 屏幕感知 + 模拟输入。它的输入是一张张屏幕截图，模型从中理解“当前界面上有什么、按钮在哪里”；输出则是一系列动作：移动鼠标到某个坐标、点击、输入文字、滚动页面，甚至组合出多步操作。动作执行后产生新的截图，模型再根据新状态决定下一步——这就构成了一个持续闭环。
和传统 RPA（机器人流程自动化）相比，最大区别在于“理解”而非“录制”。RPA 靠人工录制固定坐标和选择器，界面一改就失效；Computer Use 靠视觉理解界面语义，界面微调时往往仍能自适应。它把“图形用户界面”本身变成了一种通用、即插即用的接口。
当然，它也不是银弹。后面会讲到，视觉定位的精度、长任务的可靠性、以及误操作的安全风险，都是当前落地的真实拦路虎。但在“没有 API 也要自动化”的场景里，它的性价比正在快速超过传统 RPA。
二、主流玩家与里程碑
近两年，Computer Use 从论文概念迅速变成大厂与开源社区争相落地的方向。下面这张表梳理了几个代表性方案。
| 方案 | 提供方 | 形态 | 核心特点 |
|---|---|---|---|
| Claude Computer Use | Anthropic | 模型原生工具 | 以“computer”工具输出鼠标/键盘动作，截图闭环，可私有化部署 |
| Operator | OpenAI | 云端 Agent | 面向浏览器任务自动化，关键步骤需用户确认，降低误操作风险 |
| Project Mariner | 浏览器 Agent | 早期实验，专注于网页场景的任务执行 | |
| browser-use | 开源社区 | 开源框架 | 基于 Playwright，可自托管、易二次开发，社区活跃 |
| UFO / AppAgent | 微软 / 学术 | 桌面 Agent | 面向 Windows 等操作系统级的 GUI 操作 |
可以看到，路线分化为两类：一类是模型原生把“操作电脑”作为一项内建能力（如 Claude Computer Use），另一类是框架封装，用开源的浏览器/桌面自动化底座（如 Playwright）承接模型决策（如 browser-use）。前者上限高、集成紧；后者灵活、可控、成本低，更适合工程团队自己搭。
有意思的是，Computer Use 和前面提到的 Function Calling 并不矛盾，而是互补：能调 API 的地方优先调 API（稳定、可校验），没有 API 的界面才交给视觉操作。两者结合，才是完整的“万能执行层”。
三、核心架构：感知—规划—执行闭环
无论具体实现如何，一个 Computer Use 智能体的骨架都逃不出下面四步循环：
3.1 感知（Perceive）
把当前屏幕截图，必要时结合 DOM 结构或无障碍树（accessibility tree），交给多模态模型。截图让模型“看见”像素，无障碍树则提供可点击元素的语义标签，两者结合能大幅提升定位准确率。
3.2 规划（Plan）
模型根据“当前界面状态 + 用户目标”，推理出下一步最合理的动作，例如“在用户名输入框输入 admin”“点击登录按钮”。复杂任务会被拆成多步，模型需要维护一个隐式的任务进度。
3.3 执行（Act）
把模型输出的抽象动作，映射成真实的鼠标、键盘或滚动事件。这一步通常由 Playwright、操作系统无障碍 API 或远程桌面协议完成。
3.4 反馈（Observe）
动作产生新状态，再次截图，回到感知环节。循环直到模型判断任务完成，或触发超时、人工接管等终止条件。
下面用一个最小化的伪代码骨架，把这套闭环讲清楚。
# 最小化的 Computer Use Agent 闭环（示意：plan 步骤调用多模态大模型）
from playwright.sync_api import sync_playwright
def agent_step(page, goal, llm_plan):
# 1) 感知：截图并交给多模态模型理解当前界面
page.screenshot(path="screen.png")
# 2) 规划：模型根据截图 + 目标返回下一步动作
action = llm_plan(screenshot="screen.png", goal=goal)
# 3) 执行：把模型输出的动作映射成真实操作
if action["type"] == "click":
page.mouse.click(action["x"], action["y"])
elif action["type"] == "type":
page.keyboard.type(action["text"])
elif action["type"] == "done":
return action["result"]
# 4) 反馈：进入下一轮循环
return agent_step(page, goal, llm_plan)代码里的 llm_plan 是关键：它接收截图、输出结构化动作（类型 + 坐标/文本）。生产实现中，这一步往往还会附带“反思”机制——模型自己检查上一步是否达成预期，失败了就换策略。
四、一个最小可运行示例
如果你更想立刻动手，可以用开源的 Playwright 把“感知—执行”先跑起来，再把中间的规划换成任意多模态模型。下面这段脚本演示了如何截图、定位元素并操作，是搭建 Computer Use 智能体的最小底座。
# 用 Playwright 打开页面并截图，供模型感知；再回填与点击
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page(viewport={"width": 1280, "height": 800})
page.goto("https://example.com/login")
page.wait_for_load_state("networkidle")
page.screenshot(path="step.png") # 交给 VLM 识别按钮位置
page.fill("input[name=username]", "admin") # 也可由模型定位后回填
page.click("button:text('登录')")
browser.close()真实项目里，你不会手写死选择器，而是让模型从截图里预测坐标，再用 page.mouse.click(x, y) 执行；或者把无障碍树交给模型，让它输出 CSS 选择器再交给 Playwright。两种方式各有取舍：坐标法更通用，选择器法更稳健。
想把它接成完整的 AI 工作流，可以部署一个带多模态能力的推理服务（例如我们介绍过的 Dify+Ollama 本地化方案），把“截图→决策→动作”编排成一条流水线，再配合 Claude Code 这类 AI 编程智能体 做二次开发。
五、关键技术挑战
1）视觉定位精度。 模型要在截图里准确指出“登录按钮在哪”，坐标稍有偏差就可能点错。引入无障碍树、元素高亮、OCR 辅助，是目前主流的提升手段；对小图标、重叠弹窗仍是难点。
2）动作空间与坐标漂移。 不同分辨率、缩放比例下，同一元素坐标会变。相对坐标、语义锚点（先识别元素再定位）比绝对坐标更鲁棒。
3）可靠性与长任务规划。 十步以上的任务，任何一步失败都可能让后续全乱。需要任务分解、中间校验和回滚机制，否则“走一步看一步”很容易翻车。
4）安全与权限。 能操作界面，就意味着能误删、误发、误付费。生产环境必须做权限隔离、关键动作人工确认、操作审计——Operator 这类方案正是用“用户确认”来兜住风险。
5）成本与延迟。 每轮都要截图 + 调用多模态大模型，token 与耗时都不低。缓存静态界面、用更小的专用模型做定位，是常见的降本手段。
六、落地场景与边界
最适合的场景：没有 API 的遗留系统自动化、跨多个不互通系统的数据搬运、UI 自动化回归测试、批量表单录入、以及为视障用户做界面代理。这些恰恰是传统 RPA 最痛、也最贵的领地。
需要谨慎的场景：涉及资金、删除、对外发送的高风险操作，应当保留人工确认；对像素精度要求极高、界面频繁大改的产品，当前成功率仍不足以完全无人值守。
一句话总结：Computer Use 不是要取代所有 API，而是补上“没有 API 的那一块”。把它放在工具链的最后一道、处理那些接口缺失的脏活累活，ROI 最高。
七、2026 年趋势展望
展望接下来一年，Computer Use 会沿着三条线演进。其一是从 Demo 到生产：更强的自我校验、可观测的执行轨迹、细粒度的安全护栏，让它能真正 7×24 跑在业务里，而不只是发布会上的炫技。
其二是与 Agent 协议融合：Computer Use 负责“操作界面”，MCP/Function Calling 负责“调用服务”，两者在同一智能体里分工协作，形成既能调接口、又能点界面的完整执行层。
其三是端侧轻量化：把视觉定位等子任务交给更小的专用模型，在本地完成感知，既降成本又护隐私。当“让 AI 操作电脑”变得像“装一个驱动”一样普遍，软件自动化的范式就真的被改写了。
对开发者而言，现在正是动手的好时机：开源底座已经成熟，模型的视觉与决策能力每月都在涨。从一个“自动登录并导出报表”的小脚本起步，你就能切身感受到这场人机交互范式转移的威力。
