`Computer Use` 解决的是 `Agent` 与现有软件之间最后一段执行连接，传统 `Agent` 依赖 `API`、`MCP`、`CLI`、数据库或其他结构化接口，这些接口已经把业务能力转换成机器可调用的函数。现实环境里仍然存在大量只有图形界面的系统，包括桌面软件、企业存量业务系统、远程桌面、`Office`、`IDE`、各种工具等等。`Computer Use` 把屏幕、鼠标、键盘以及操作系统提供的可访问性接口纳入 `Agent` 的工具空间，使模型能够继续操作这些软件。

从工程实现上看，**`Computer Use` 可以理解为一套“模型动作协议 + 本地执行器 + 操作系统自动化接口”的组合能力**。模型读取屏幕和界面状态，产生 `click`、`type`、`scroll`、`keypress` 等结构化动作；`Agent Runtime` 将动作发送给运行在目标机器上的 `Local Executor`；执行器再通过浏览器协议、系统可访问性接口或输入注入接口控制目标进程。

​![image.png](https://developer.qcloudimg.com/http-save/yehe-8159227/f0afd6cef90d884fde95ad7a85e8ace5.png)

# Computer Use 解决的问题是什么？
一个 `Agent` 想完成真实业务任务，最终必须改变外部系统状态。目标系统提供 `REST API` 时，可以直接调用接口；提供 `MCP Server` 时，可以通过 `MCP` 获取资源或执行工具；本地程序提供 `CLI`、`RPC`、`Socket` 时，也可以直接通过结构化接口通信。这些方式具有明确的参数、返回值和错误码，执行链短，确定性高。

问题出现在软件只提供面向人的操作界面时。很多桌面程序能够被用户熟练操作，却没有稳定的外部接口；另外一些系统只开放了部分 `API`，完整业务流程仍然需要在页面或桌面程序中完成。**`Computer Use` 为这类“机器接口缺失或覆盖不完整”的系统增加了一条通用执行路径**：读取当前界面，通过模型理解软件状态，再沿着软件原有的人机交互方式执行操作。

当前主流实现已经明确超出了浏览器范围。`OpenAI` 的官方文档把 `Computer Use` 定义为让模型操作“浏览器和桌面界面”，应用负责提供环境并执行模型返回的操作；`Anthropic` 的完整 `Computer Use` 面向桌面环境，而网页内任务可以使用独立的 `Browser Use`；`Gemini Computer Use` 当前直接覆盖浏览器、移动设备和桌面三类环境。

所以它在 `Agent` 工具体系中的位置比较清晰 /：有稳定业务接口时优先使用 `API/MCP/CLI`，网页内部可以使用 `DOM`、`A11y`、`CDP`、`Playwright` 等语义化接口，需要跨桌面程序、远程环境或者纯图形界面时使用 `Computer Use`。/ **它扩展的是 `Agent` 的软件可操作范围。**

# 一次操作从模型到本地进程经过哪些层
要理解 `Computer Use` 的实现，需要把 “模型调用工具” 和 “本地进程如何被操作” 拆开。**当前并不存在一个跨厂商统一的 `Computer Use Wire Protocol`** 。`OpenAI`、`Anthropic`、`Gemini` 都定义了自己的模型侧工具结构：模型产生结构化动作，宿主程序执行动作，再把截图、结果和错误信息返回模型；厂商协议主要约束模型与 `Agent Runtime` 之间的数据格式。

在企业或本地 `Agent` 中，`Agent Runtime` 往往还需要跨进程甚至跨机器控制实际桌面，因此中间通常增加一个  `Local Executor`  或  `Computer Use Daemon`。这一层负责接收动作、维护执行会话、捕获截图、处理坐标映射、访问可访问性树、注入键鼠事件、返回错误和执行状态。`Agent Runtime` 与执行器之间采用什么传输协议属于系统设计选择，可以使用 `stdio`、`Unix Domain Socket`、`Named Pipe`、`HTTP`、`gRPC` 或 `WebSocket`；这层协议需要解决会话和执行问题，与模型厂商提供的 `tool_call/tool_result` 结构处于不同层级。

![2.png](https://developer.qcloudimg.com/http-save/yehe-8159227/8075ee00d05a5364babf30362fa10abd.png)

从上到下可以看到三层协议关系。第一层是**模型工具协议**，表达模型希望执行什么，例如 `click(x,y)`、`type(text)` 或 `keypress(keys)`；第二层是**执行器传输协议**，负责把动作送到具体机器，并维护 `session_id`、截图流、状态和错误；第三层是**操作系统或应用控制接口**，它负责最终改变目标进程的状态。

模型只需要理解统一动作空间，不需要知道目标机器是 `Windows`、`macOS` 还是 `Linux`；`Local Executor` 负责根据运行环境选择不同的 `Adapter`。因此 **`Computer Use` 能够跨平台的关键，在于上层动作协议与底层系统自动化接口之间存在一层适配器。**

# 本地进程可以通过两条技术路径被控制
操作本地程序通常存在两条执行路径。第一条是语义化控制，直接访问操作系统暴露出来的 `UI Tree`、控件属性和操作能力；第二条是视觉与输入事件控制，通过截图找到屏幕位置，再模拟鼠标和键盘。一个成熟的桌面 `Agent` 通常同时具备这两种能力，根据软件是否提供稳定的可访问性信息选择执行方式。

![3.png](https://developer.qcloudimg.com/http-save/yehe-8159227/49edcf762f6fce9f465d1420649e3f83.png)

在 `Windows` 上，`UI Automation` 能够跨进程读取桌面控件，获得按钮、输入框、菜单等 `UI Element` 的属性和层次，并通过相应 `Control Pattern` 操作控件。微软文档明确说明，`UI Automation Client` 可以访问其他应用的界面元素并通过程序方式控制它们；当需要模拟真实键鼠时，还可以使用 `SendInput` 向系统输入流注入键盘、鼠标移动和点击事件。

在 `macOS` 上，对应能力主要来自 `Accessibility API`。`AXUIElement` 可以表示另一个进程中的可访问界面元素，提供元素位置、层次、属性以及支持的操作，`AXUIElementPerformAction` 可以要求控件执行指定动作；低层输入事件则可以通过 `Quartz Event Services` 处理和注入。Apple 文档明确说明这些接口可以与可访问应用通信并控制它们。

`Linux` 桌面通常可以通过 `AT-SPI` 获取可访问性语义，再根据桌面栈连接 `X11` 或 `Wayland` 的输入机制。浏览器的路径更加丰富：可以从 `DOM`、`Accessibility Tree` 获取元素语义，也可以通过 `Chrome DevTools Protocol` 发送鼠标和键盘事件，或者由 `Playwright` 等自动化框架操作页面。

所以 **浏览器只是 `Application Adapter` 的一种实现**。同一套 `Computer Use` 上层可以连接浏览器，也可以连接 `Windows` 桌面、`macOS` 应用、`Linux` 桌面甚至远程桌面客户端；差异主要发生在 `Local Executor` 下面。

# 一次完整的 `Computer Use` 执行链是怎样的
一次完整操作从目标进程当前状态开始，`Local Executor` 从显示系统捕获 `Screenshot`，如果支持语义接口，还会读取当前窗口、控件树或页面结构；这些状态通过执行器协议返回 `Agent Harness`，再进入多模态模型。模型结合用户任务、已有任务状态和当前界面生成下一步 `Action`，`Harness` 校验动作后把它发送回执行器。

![4.png](https://developer.qcloudimg.com/http-save/yehe-8159227/77f69f77c7a42194393b08ceb0de113b.png)

执行器收到动作以后，根据目标类型选择对应 `Adapter`。浏览器操作可能进入 `CDP` 或 `Playwright`，`Windows` 桌面可能使用 `UI Automation` 或 `SendInput`，`macOS` 可能使用 `AXUIElement` 或系统事件接口。目标进程收到操作后更新自己的内部状态，并重新绘制窗口；执行器重新读取界面，把新的截图、控件状态、错误和执行结果返回 `Harness`，模型再决定下一步操作。

这个循环中存在两套长期状态。**环境状态**存在目标机器里，包括窗口、焦点、登录会话、文件、当前页面和目标应用内部状态；**任务状态**存在 `Agent Runtime` 中，包括已经完成的业务步骤、待执行步骤、关键参数、重试记录和验收条件。[`OpenAI` 官方文档特别提到](https://developers.openai.com/api/docs/guides/tools-computer-use)，`API` 对话状态和执行环境状态需要分别维护，继续模型会话并不会自动恢复浏览器登录状态或运行时变量。

这也是 `Computer Use` 与一次普通工具调用差异最大的地方，它运行在持续变化的外部状态之上，每次动作都会改变下一轮输入，因此 **执行器、环境和模型共同组成一个有状态的交互 Runtime**。

# `Computer Use` 与本地进程协议怎么设计
如果把 `Computer Use` 做成企业级本地能力，建议把协议明确划成 `Tool Protocol` 和 `Executor Protocol` 两层。
* `Tool Protocol` 面向模型，动作保持简单稳定，例如 `screenshot`、`click`、`double_click`、`move`、`drag`、`scroll`、`type`、`keypress`、`wait`；结果包含 `tool_result`、`screenshot`、`error` 和少量执行元数据。当前 `OpenAI` 和 `Anthropic` 都沿用了这种结构化动作思路，`Anthropic computer_toolset_20260801` 当前包含截图、点击、输入、局部放大等多个成员工具。
  
* `Executor Protocol` 面向远端或本地守护进程，需要比模型协议多维护一些运行时信息。一次请求至少应具有 `session_id`、目标环境、动作序列、坐标空间、超时、权限上下文等信息；返回需要包含动作执行状态、截图、当前窗口、错误、可恢复状态以及环境版本。这一层还可以支持 `Snapshot`、`Reset`、`Process List`、`Window List`、`Accessibility Tree`、文件交换和剪贴板等扩展能力，使 `Agent` 可以处理完整桌面任务。

这一层采用 `gRPC`、`WebSocket` 还是本地 `Unix Socket/Named Pipe` 取决于部署模式。本机桌面 `Agent` 更适合本地 `IPC`，云端 `Agent` 控制用户机器时通常需要长连接和双向状态传输，云端沙箱则可以直接把执行器和桌面环境放在同一节点。**协议设计的关键是保持模型动作与操作系统实现解耦，同时给本地环境保留足够的会话和状态管理能力。**
# 总结
`Computer Use` 的覆盖面很广，每次操作都需要经过界面观察、模型判断、动作执行和状态反馈，执行成本会高于结构化调用。一个程序已经提供 `CLI` 时，直接执行命令通常更加稳定；业务系统存在 `API` 或 `MCP` 时，结构化调用能够直接表达业务意图；浏览器已经能够通过 `DOM` 或 `Playwright` 精确定位元素时，也可以避免大量视觉 Grounding。

因此生产环境可以把整个执行体系看成三层。最上层是业务级结构化接口，覆盖 `API/MCP/CLI/RPC`；中间层是应用语义接口，例如 `DOM`、`A11y`、`UI Automation`、`AXUIElement`；最下层是视觉 `Computer Use`，通过屏幕、坐标和键鼠覆盖剩余环境。**这三层共同构成 `Agent` 的执行能力栈，`Computer Use` 负责把执行范围扩展到人能够操作、机器接口却不完整的软件。**

从这个角度理解以后，`Computer Use` 的定义会非常具体：它是一套连接多模态 `Agent` 与图形计算环境的执行机制，上层模型负责根据屏幕和任务生成动作，中间协议负责传递动作、截图和会话状态，本地执行器负责连接操作系统自动化接口，最终控制浏览器或其他本地进程。它解决的软件工程问题也非常明确——**让 `Agent` 可以沿着现有软件的人机界面继续执行任务，而不要求每个目标系统先建设专门的 `API` 或 `MCP Server`。**


Computer Use 解决的是 Agent 与现有软件之间最后一段执行连接，传统 Agent 依赖 API、MCP、CLI、数据库或其他结构化接口，这些接口已经把业务能力转换成机器可调用的函数。现实环境里仍然存在大量只有图形界面的系统，包括桌面软件、企业存量业务系统、远程桌面、Office、IDE、各种工具等等。Computer Use 把屏幕、鼠标、键盘以及操作系统提供的可访问性接口纳入 Agent 的工具空间，使模型能够继续操作这些软件。

Computer Use 怎么实现：从 Tool 协议到本地进程控制

Computer Use 解决的是 Agent 与现有软件之间最后一段执行连接，传统 Agent 依赖 API、MCP、CLI、数据库或其他结构化接口，这些接口已经把业务能力转换成机器可调用的函数。现实环境里仍然存在大量只有图形界面的系统，包括桌面软件、企业存量业务系统、远程桌面、Office、IDE、各种工具等等。Computer Use 把屏幕、鼠标、键盘以及操作系统提供的可访问性接口纳入 A

高级系统架构师

人工智能

开发工具

操作系统

ComputerUse构建Agent与图形界面软件的通用执行路径，通过屏幕捕获、键鼠模拟及系统可访问性接口实现跨桌面操作。其分层架构涵盖模型工具协议、执行器传输协议与OS适配器，覆盖API/MCP/CLI缺失场景，支持浏览器、Windows、macOS及Linux环境，确保复杂任务的状态反馈与自动化执行。

人机交互

软件工程

数据库

WebSocket

Windows

Wayland 

Linux

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Computer Use 怎么实现：从 Tool 协议到本地进程控制-腾讯云开发者社区-腾讯云

Computer Use 怎么实现：从 Tool 协议到本地进程控制

Computer Use 怎么实现：从 Tool 协议到本地进程控制

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐