看屏幕、读结构、敲命令：AI Agent 操控电脑的三条技术路线深度解析
深度解析 Vision-based、Structure-based、Command-based 三种 Agent 操控电脑范式。
看屏幕、读结构、敲命令：AI Agent 操控电脑的三条技术路线深度解析
Agent 操控电脑已经不是新鲜事了。GPT-5.4 在 OSWorld 上跑到 75.0%，首次超过人类基准；Claude Code 搭载 Claude 4 Opus 连续工作 7 小时不掉链子；browser-use 8000 行代码融了 $1700 万。Agent 能操作电脑这件事已经没有争议——真正值得深究的是：它到底是怎么做到的？
从底层看，Agent 操控电脑有且只有三条路：
| 范式 | 感知 → 操作 | 一句话 | |------|------------|--------| | 📷 Vision-based | 截图 → VLM 理解 → 坐标点击 | 像人一样看屏幕、动鼠标 | | 🌐 Structure-based | DOM / A11y Tree → 选择器操作 | 像开发者一样读结构、精准定位 | | ⌨️ Command-based | stdout/stderr → Shell 命令 | 像运维一样敲终端 |
本文逐一拆解每条路线的底层原理、工程实现和真实局限，再看实际产品如何混合使用，最后给出选型建议。
一、Vision-based：截图 + 视觉理解 + 模拟点击
1.1 技术原理
Agent 像人一样"看"屏幕——截图、理解、定位、操作，循环往复：
每一步的技术选择：
感知层——通过系统截图 API / 虚拟桌面 / RDP 获取屏幕画面，交给 VLM 识别 UI 元素和语义。
定位层（Visual Grounding）——这是 Vision-based 的核心难题，目前有三种方案：
| 方案 | 代表 | 原理 | 适用 |
|------|------|------|------|
| 绝对像素坐标 | Anthropic CU | 模型直接输出 (x, y) 像素坐标 | 固定分辨率场景 |
| 标准化网格 | Gemini 2.5 CU | 统一映射到 0-999 坐标空间，跨分辨率通用 | 多设备适配 |
| Set-of-Mark | OmniParser V2 | 先用检测模型画编号框，模型输出框 ID 而非坐标 | 消除坐标偏差 |
执行层——xdotool/pyautogui（系统级模拟）、云端浏览器沙箱（Operator）、Accessibility API、RDP/VNC。
里程碑：GPT-5.4（2026.03）——首个将 Computer Use 作为原生能力内置的通用模型。OSWorld 75.0% 首超人类（72.4%），不需要外挂工具，模型本身就能理解截图并操作。
1.2 主流实践
| 项目 | 厂商 | 时间 | 核心特点 | |------|------|------|---------| | Computer Use | Anthropic | 2024.10 | 首个商用 CU API；绝对坐标；Web + 桌面 | | Operator (CUA) | OpenAI | 2025.01 | GPT-4o 视觉 + RL；云端沙箱；敏感操作暂停 | | UI-TARS | 字节跳动 | 2025.01 | 开源 VLM；ScreenSpot Pro 38.1%（SOTA） | | Gemini 2.5 CU | Google | 2025.03 | 1000×1000 标准化网格；13 种操作；首个面向开发者 CU API | | OmniParser V2 | Microsoft | 2025 | 开源 UI 解析；Set-of-Mark 标注；可搭配任意 LLM | | ⭐ GPT-5.4 | OpenAI | 2026.03 | 原生 CU；OSWorld 75.0% 超人类；100 万 token；Token 降 47% |
1.3 优劣势
| ✅ 优势 | ❌ 劣势 | |--------|--------| | 通用性最强——任何有 GUI 的应用都能操作 | 延迟高——截图→推理→操作，单步 2-10 秒 | | 无需适配——不依赖 DOM/API/内部结构 | Token 贵——一张截图的视觉 Token 是纯文本的 50-100 倍 | | 跨平台——Windows/macOS/Linux/Android | 精度有限——元素密集时容易误点 | | 直观可调试——录屏即可看到 Agent 行为 | 脆弱——分辨率/DPI/主题切换都可能导致失败 |
GPT-5.4 正在改写"万金油但不银弹"的结论——当成功率超越人类，这条路线的天花板需要重新评估。
二、Structure-based：DOM / Accessibility Tree 结构化解析
2.1 技术原理
不看像素看结构——把页面的语义化表示（而非截图）交给 LLM：
核心差异：Vision 给模型一张截图（几百 KB），Structure 给模型一段文本（几 KB）。精度从"坐标级"提升到"元素级"。
DOM 序列化——一个真实网页 DOM 可能有上万节点，直接传给 LLM 会浪费 Token。核心是智能裁剪：过滤不可见/装饰元素 → 提取可交互元素 → 保留文本+层级 → 分配索引。裁剪后：
[1] Link "首页" [2] Input placeholder="搜索..." [3] Button "搜索"
[4] Link "登录" [5] Heading "热门推荐" [6] Button "加入购物车"
比截图的 Token 消耗低 1-2 个数量级。
Accessibility Tree 比 DOM 更适合 Agent——它本身就是为"非视觉用户"设计的：只含语义元素、有 role/state 信息、跨前端框架一致。Vercel agent-browser 用 A11y Snapshot 替代完整 HTML，Context 节省 93%。
元素操作——模型输出 click_element(3) 这样的索引指令（而非 CSS 选择器），由 Playwright/CDP 精确执行。browser-use 还支持单步多动作（[click(2), type(3, "hello"), click(5)]），减少推理轮次。
2.2 主流实践
| 项目 | 厂商/社区 | 核心特点 |
|------|----------|---------|
| browser-use | 开源（$17M 融资） | 索引化 DOM + 智能元素跟踪 + 单步多动作 + 工作记忆；8000 行代码 |
| Stagehand | Browserbase | act()/extract()/observe() 三个语义 API；用自然语言替代选择器；Vision+DOM 双模式 |
| agent-browser | Vercel Labs | A11y Snapshot，Context 节省 93%；CLI 形态；2 天 3.4k Star |
| PageAgent | 阿里巴巴 | 纯前端 JS 注入，Agent 寄生在页面内部；零后端依赖；数据不出浏览器 |
| Playwright MCP | Microsoft | MCP 协议暴露 Playwright 能力；标准化浏览器控制接口 |
2.3 优劣势
| ✅ 优势 | ❌ 劣势 | |--------|--------| | 精确——元素级操作，不存在坐标偏差 | 仅限 Web——桌面原生应用无法覆盖 | | 省 Token——结构化文本 2-15 KB vs 截图几百 KB | Canvas/WebGL 盲区——渲染内容 DOM 无法表达 | | 快——纯文本推理 + Playwright 执行，单步 <1 秒 | 反自动化——网站可能检测并阻止 Playwright | | 稳定——不受主题/分辨率/DPI 变化影响 | 结构噪音——大型 SPA 需要智能裁剪算法 |
Structure-based 是 Web 自动化的最优解——精确、高效、省钱，但它的世界只有浏览器。
三、Command-based：CLI / Terminal 命令行操作
3.1 技术原理
绕过 GUI 直接跟系统对话——LLM 生成命令、沙箱执行、解析输出、迭代推理：
核心逻辑：GUI 是给人看的"可视化外壳"，CLI 才是系统的原生接口。Agent 直接调用 Unix 工具链——文件管理（find/grep）、网络（curl/ssh）、版本控制（git）、包管理（npm/pip）、数据库（psql/redis-cli）……几乎所有计算机操作都有 CLI 等价物。
Agent Loop 架构（以 Claude Code 为例）：模型接收任务 → 选择工具（read_file/write_file/bash/search）→ 执行并获取输出 → 决定是否继续。通过 allowlist/denylist 控制安全边界：ls/cat 始终允许，git commit 需确认，rm -rf/sudo 始终禁止。
安全保障——CLI 命令的不可逆风险通过多层防护应对：dry-run 预览、白名单限制、Docker/受限 Shell 沙箱隔离、输出校验。
3.2 主流实践
| 项目 | 厂商 | 时间 | 核心特点 | |------|------|------|---------| | Claude Code | Anthropic | 2025.05 | Claude 4 Opus（SWE-bench 72.5%）；权限白/黑名单；连续工作 7 小时 | | Codex CLI | OpenAI | 2025 | 三档沙箱：suggest / auto-edit / full-auto | | Gemini CLI | Google | 2025 | 终端内多模态；支持图片输入 | | Open Interpreter | 开源 | 2024 | 本地代码执行器；Python / Shell / AppleScript | | GPT-5.4 + Codex | OpenAI | 2026.03 | 原生 CLI 能力；快速模式 Token 提速 1.5x；GDPval 83% 达专家水平 |
3.3 优劣势
| ✅ 优势 | ❌ 劣势 |
|--------|--------|
| 最快——直接系统调用，毫秒级完成 | 不能"看"——无法处理视觉任务 |
| 最省 Token——纯文本 I/O，无图片开销 | 覆盖有限——Figma/Photoshop 等无 CLI 接口 |
| 最确定——同命令=同结果，高度可复现 | 跨平台差异——bash vs PowerShell vs zsh |
| 可组合——Unix 管道自由拼接工作流 | 安全风险——rm -rf / 类误操作不可逆 |
| 安全可控——Docker/chroot/权限系统精确限制 | Web 动态内容盲区——JS 渲染页面需借助浏览器 |
CLI 是 Agent 操控电脑的"快车道"——但只有在路修好的地方才能开。
四、三种范式对比
核心洞见：没有银弹，选择范式的关键在于你的任务场景。
4.1 多维度对比表
| 维度 | 📷 Vision-based | 🌐 Structure-based | ⌨️ Command-based | |------|-----------------|--------------------|--------------------| | 感知输入 | 截图（像素） | DOM / A11y Tree（结构化文本） | 命令输出（文本流） | | 操作方式 | 坐标点击 / 键盘输入 | 元素选择器操作 | Shell 命令执行 | | 单步延迟 | 2-10 秒（截图+VLM推理） | < 1 秒（文本LLM+Playwright） | 毫秒级（命令直接执行） | | 单步 Token | ~1500-3000（图片Token） | ~200-800（结构化文本） | ~50-200（纯文本） | | 精确度 | 中（坐标偏差 5-20px） | 高（元素级精确） | 高（命令级确定性） | | 通用性 | 最强（任何 GUI 应用） | 中（主要 Web） | 中（需 CLI 接口） | | 可靠性 | 较低（UI 变化/分辨率敏感） | 较高（结构稳定） | 最高（同命令=同结果） | | 安全风险 | 截图泄隐私、视觉幻觉误操作 | Prompt Injection via HTML | 命令注入/越权执行 | | 典型场景 | 跨应用、移动端、传统桌面软件 | Web 自动化、表单、数据提取 | 开发工作流、系统管理 | | 代表项目 | Operator, GPT-5.4 CU, UI-TARS, Gemini 2.5 CU | browser-use, PageAgent, Stagehand | Claude Code (Claude 4), Codex, Gemini CLI |
4.2 选择决策树
五、混合范式：实际场景中的融合
核心洞见：现实任务往往跨越多种交互模式，最佳实践是"CLI 优先 → DOM 次选 → 视觉兜底"。
5.1 为什么需要融合？
现实中的任务很少"纯粹"落在某一种范式里。考虑这个场景：
"帮我 review GitHub 上这个 PR 的改动，然后在 Slack 上发个总结给团队。"
这一个任务就涉及：CLI（git diff）+ DOM（GitHub PR 页面讨论）+ 可能的 Vision（CI 状态图标）+ CLI（Slack API 发消息）。
单一范式无法覆盖完整链路——需要融合。
5.2 两种融合架构
架构一：统一调度器（Task Planner 模式）
一个中心 LLM 作为 Task Planner，根据子任务特征自动分发到不同执行引擎：
代表：OpenAI Responses API——同时提供 computer_use_preview（Vision）和 bash（CLI）两个工具，模型在 Agent Loop 中根据任务动态选择。
架构二：分层降级（Fallback 模式）
不是并行选择，而是优先用高效方案，失败后降级到通用方案：
代表：Claude Code + Playwright MCP——默认用 CLI 操作文件/代码，遇到 Web 任务自动调用 Playwright MCP 进行 DOM 操作。
5.3 主流产品的融合方式
| 方案 | 融合方式 | 具体实现 |
|------|---------|---------|
| GPT-5.4（2026.03） | Vision + CLI 原生融合 | 首个将 Computer Use 作为原生能力内置的通用模型——不需要选择工具，模型自己判断截图操作还是命令执行；OSWorld 75.0% 首超人类 |
| Claude Code + MCP | CLI + DOM | 终端内 CLI Agent（Claude 4 Opus）处理文件/代码；通过 Playwright MCP Server 获得浏览器控制能力；两层独立，按需调用 |
| Agent S (Simular) | Vision + DOM | 双通道感知：同时用 Accessibility Tree（精确定位）和截图（理解视觉布局），交叉验证后操作 |
| Stagehand | Vision + DOM | act() 先尝试 DOM 定位，失败后自动 fallback 到 Vision 模式（截图+VLM 定位） |
| Microsoft Copilot | Vision + DOM + CLI | Windows Agent Workspace 中集成 OS 级 GUI 控制、Web 自动化和 PowerShell |
5.4 融合最佳实践
基于对各方案的分析，"CLI 优先"原则 是目前业界的共识：
原因很简单——同一个任务，三种路径的成本差异巨大：
| 操作 | CLI 路径 | DOM 路径 | Vision 路径 |
|------|---------|---------|------------|
| 查看文件内容 | cat file.txt（0.01s, ~50 tokens） | 在文件管理器网页打开（~1s, ~500 tokens） | 截屏+识别文件图标+双击（~5s, ~2000 tokens） |
| 提交代码 | git commit -m "fix"（0.1s, ~30 tokens） | GitHub 网页填写表单（~3s, ~800 tokens） | 截屏+定位+点击+输入（~15s, ~6000 tokens） |
总是选能达到目标的、最高效的范式。
六、安全与风控
核心洞见：每种范式有独特的安全盲区，通用原则是"沙箱 + 最小权限 + 人在回路"。
| 范式 | 核心风险 | 应对措施 |
|------|---------|---------|
| Vision | 截图泄露隐私（密码、聊天记录）；视觉幻觉导致误操作（"取消"看成"确认"） | 截图前遮盖敏感区域；不在真实生产屏幕运行；关键操作二次确认 |
| DOM | Prompt Injection via HTML（恶意网页嵌入指令）；反自动化检测封禁 | DOM 内容做注入检测和清洗；使用隐身模式减少指纹 |
| CLI | 命令注入/越权（rm -rf /）；环境污染（修改系统配置） | 命令白名单；禁止 sudo/rm -rf；Docker 沙箱执行 |
通用安全原则：
- 沙箱隔离：所有范式都应在容器/VM/受限环境中运行
- 最小权限：只授予完成任务的最小权限
- 人在回路：支付、删除、发送等不可逆操作必须人工确认
- 操作审计：记录每一步操作，可追溯、可回滚
- 速率限制：防止 Agent 失控循环
七、未来展望
核心洞见：三种范式的融合已经发生，下一个战场是"Agent 原生操作系统"和协议标准化。
1. 端到端模型已消除范式边界（✅ 已发生）
GPT-5.4（2026.03）正式验证了这一趋势——它是首个将 Computer Use 作为原生能力内置的通用大模型，无需外挂工具即可理解屏幕并操作。OSWorld 75.0% 超越人类基准 72.4%，标志着 Vision-based 范式迎来质变。Claude 4 Opus 在 SWE-bench 达到 72.5%，终端编程能力也在逼近天花板。"选哪种范式"正从工程决策变为模型内部的自动选择。
2. 四大 Agent 协议并行推进
2026 年初，Agent 通信协议进入"爆发期"——不再是 MCP 一枝独秀：
| 协议 | 发起方 | 定位 | |------|--------|------| | MCP（Model Context Protocol） | Anthropic | Agent ↔ 工具/数据源 的标准连接协议 | | A2A（Agent-to-Agent） | Google | Agent ↔ Agent 的协作通信协议 | | A2UI | 社区 | Agent ↔ 用户界面 的交互标准 | | AG-UI | 社区 | 通用 Agent-GUI 交互协议 |
这意味着 Agent 生态正在从"各自为战"走向"互联互通"——一个 Agent 可以通过 MCP 调用工具，通过 A2A 指挥其他 Agent，通过 A2UI/AG-UI 操作界面。
3. OS 原生 Agent 支持
操作系统正在把"让 Agent 操作"作为一等公民能力来设计：
- Microsoft Windows Agent Workspace：原生沙箱 + 权限管理 + Cloud PC 隔离
- Apple Intelligence App Intents：系统级 Agent API，让 Siri 能跨应用操作
- 这意味着 Vision 范式将获得操作系统级别的坐标精度和权限控制
4. RPA 行业正在被重构
传统 RPA（UiPath、Blue Prism）基于规则脚本，脆弱且维护成本高。GPT-5.4 级别的 Agent 带来的"自适应自动化"正在重新定义这个市场——不再需要为每个 UI 变化重写脚本，Agent 能自动适应。
5. "Agent-native"应用设计成为标配
GPT-5.4 的 Token 消耗降低 47% 的工具检索优化，预示着下一代应用设计范式：GUI（给人用）+ CLI（给 Agent 高效调用）+ MCP Server（给 Agent 标准化调用）三接口并行。就像今天的应用同时提供 Web 界面和 REST API。
6. 下一个里程碑：持续自主工作
Claude 4 Opus 已经展示了"连续工作 7 小时"的能力。下一步是 多 Agent 协同的长时自主任务——一个 Agent 团队 7×24 小时持续运行，自动分工、自动协调、自动恢复。这要求在安全、监控和对齐方面有本质性突破。
八、参考资源
项目链接
| 项目 | 链接 | |------|------| | Anthropic Computer Use | https://docs.anthropic.com/en/docs/build-with-claude/computer-use | | Claude 4 (Opus/Sonnet) | https://www.anthropic.com/claude | | Claude Code | https://docs.anthropic.com/en/docs/claude-code | | OpenAI GPT-5.4 | https://openai.com/index/gpt-5-4/ | | OpenAI Operator | https://openai.com/operator | | Gemini 2.5 Computer Use | https://ai.google.dev/gemini-api/docs/computer-use | | ByteDance UI-TARS | https://github.com/bytedance/UI-TARS | | Microsoft OmniParser V2 | https://github.com/microsoft/OmniParser | | browser-use | https://github.com/browser-use/browser-use | | Stagehand (Browserbase) | https://github.com/browserbase/stagehand | | Vercel agent-browser | https://github.com/vercel-labs/agent-browser | | Alibaba PageAgent | https://github.com/alibaba/page-agent | | Playwright MCP | https://github.com/anthropics/anthropic-cookbook | | MCP 协议规范 | https://modelcontextprotocol.io/ |
延伸阅读
- Agentic Computer Use: Ultimate Deep Guide 2026
- Best AI Computer Use Agents (CUA) of 2026
- GPT-5.4 深度解读 — 掘金
- Agent Protocols: MCP, A2A, A2UI, AG-UI (2026)
- Top 50 AI Funded Startups (March 2026)
- OmniParser V2 研究文章
本文基于 2024-2026 年 3 月的公开资料整理，最新更新至 GPT-5.4 发布（2026.03.06）。技术方案和产品形态在快速演进中。如有遗漏或错误，欢迎指正。