当大多数 AI Agent 还在通过 API 和 Function Calling 与数字世界交互时,Anthropic 在 2024 年 10 月发布的 Computer Use 功能打开了一扇全新的大门:让 AI 像人类一样,通过"看屏幕、移鼠标、敲键盘"来操控计算机。这不是一个渐进式的改良,而是 Agent 交互范式的根本性扩展——从结构化 API 调用,进入到了非结构化的 GUI 操控领域。
本文将从架构原理、工程实现、安全设计到真实落地场景,系统剖析 Computer Use 技术的全貌,帮助你判断何时该用它、如何用好它、以及它当前的边界在哪里。
核心要点
- Computer Use 本质:基于多模态视觉能力的截图-推理-操作循环,让 Agent 通过 GUI 而非 API 与软件交互
- 架构核心:截图采集 → 视觉模型理解 → 坐标级操作指令 → 执行反馈,形成持续闭环
- 与 API Agent 互补:API Agent 快速、确定、低成本;GUI Agent 通用、灵活、适应非结构化界面
- 安全是硬约束:必须在沙箱隔离环境中运行,设置操作白名单和人工确认机制
- 混合架构最优:生产环境中,确定性步骤用 Playwright/Puppeteer,模糊步骤用 Computer Use
什么是 Computer Use
Computer Use 是 Anthropic 为 Claude 模型提供的一组特殊工具调用能力,使模型能够与计算机的图形界面进行交互。它本质上将 LLM 的计算机视觉能力与操作系统级别的输入控制结合在一起,形成了一个"感知-思考-行动"的完整闭环。
与传统的 Function Calling 不同,Computer Use 不需要目标系统暴露任何 API。它的工作方式更接近人类操作员:观察屏幕上的内容,理解当前的界面状态,然后决定下一步该点击哪里、输入什么文字。
三种核心工具
Anthropic 的 Computer Use 实现提供了三种工具原语:
| 工具 | 功能 | 典型操作 |
|---|---|---|
computer |
屏幕交互 | 鼠标移动/点击、键盘输入、截图获取 |
text_editor |
文件编辑 | 查看文件、创建/编辑文本内容 |
bash |
命令执行 | 运行 Shell 命令、安装软件包 |
其中 computer 工具是 Computer Use 的核心——它赋予模型操控 GUI 的能力。text_editor 和 bash 工具则是对文件系统和终端的补充,使 Agent 能够执行完整的计算机操作任务。
架构解析:截图-视觉-操作循环
Computer Use 的核心架构是一个持续运行的感知-执行循环。理解这个循环的每个环节,对于工程实现至关重要。
循环流程
用户指令 → [LLM 推理] → 调用 computer 工具(screenshot)
↓
截取当前屏幕 → Base64 图像
↓
[LLM 视觉推理] 分析屏幕内容
↓
生成操作指令(click/type/key/scroll)
↓
在操作系统层面执行操作 → 界面状态变化
↓
再次截图 → 回到视觉推理步骤
↓
判断任务是否完成?→ 是 → 返回结果
→ 否 → 继续循环
每一轮循环包含四个阶段:
- 截图采集:通过系统级 API(如
xdotool或screencapture)获取当前屏幕截图,编码为 Base64 格式 - 视觉推理:将截图作为图像 token 送入模型的上下文窗口,模型分析界面元素、文字内容和空间布局
- 操作决策:模型输出具体的操作指令,包括精确的屏幕坐标(如
click(x=450, y=320))或键盘输入内容 - 执行与反馈:在操作系统层面执行操作,界面状态发生变化,进入下一轮截图
API 调用结构
以下是 Computer Use 的核心 API 调用方式:
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=4096,
tools=[
{
"type": "computer_20250124",
"name": "computer",
"display_width_px": 1920,
"display_height_px": 1080,
"display_number": 1,
},
{
"type": "text_editor_20250124",
"name": "str_replace_editor",
},
{
"type": "bash_20250124",
"name": "bash",
},
],
messages=[
{
"role": "user",
"content": "打开 Firefox 浏览器,访问 qubittool.com,截图给我看首页内容。",
}
],
)
模型返回的工具调用可能包含如下操作指令:
{
"type": "tool_use",
"name": "computer",
"input": {
"action": "mouse_move",
"coordinate": [960, 540]
}
}
坐标系统与分辨率适配
Computer Use 使用像素坐标系统进行定位。工程实现中需要特别注意分辨率处理:
# 推荐的屏幕分辨率配置
# Anthropic 建议使用 XGA(1024x768)以获得最佳性能
RECOMMENDED_RESOLUTION = (1024, 768)
# 如果实际屏幕分辨率更高,需要进行缩放
def scale_coordinates(x, y, actual_width, actual_height):
scale_x = actual_width / RECOMMENDED_RESOLUTION[0]
scale_y = actual_height / RECOMMENDED_RESOLUTION[1]
return int(x * scale_x), int(y * scale_y)
模型在较低分辨率下的定位精度更高,因为图像 token 数量更少、关键元素在图像中的占比更大。在生产环境中,通常将虚拟桌面分辨率设为 1024x768 或 1280x800,而非原生 4K 分辨率。
与传统 API Agent 的本质对比
要理解 Computer Use 的定位,必须将它与基于 Function Calling 的传统 AI Agent 方案进行系统对比。两者不是替代关系,而是互补关系。
关于 API Agent 的工作原理,可以参考 AI Agent 架构设计与代码实战指南。
| 维度 | API Agent (Function Calling) | GUI Agent (Computer Use) |
|---|---|---|
| 交互方式 | 结构化 JSON 函数调用 | 像素级屏幕操作 |
| 前提条件 | 目标系统必须提供 API | 只需有 GUI 界面 |
| 执行速度 | 毫秒级 | 秒级(2-5 秒/步) |
| 确定性 | 高(相同输入相同结果) | 低(视觉理解可能出错) |
| 成本 | 低(纯文本 token) | 高(图像 token 消耗大) |
| 适应性 | 低(API 变更需更新 Schema) | 高(UI 布局变化可适应) |
| 覆盖范围 | 仅限有 API 的系统 | 理论上覆盖所有 GUI 软件 |
| 可观测性 | 高(结构化日志) | 中(需要录屏回放) |
什么时候该用 Computer Use
Computer Use 并非万能方案。根据实际工程经验,它在以下场景中价值最高:
- 无 API 的遗留系统:老旧的 ERP、CRM、政府办公系统,只有 Web 或桌面 GUI
- 跨系统端到端流程:需要在 5 个以上不同系统间搬运数据,逐一开发 API 集成成本过高
- 动态 UI 的自适应测试:页面结构频繁变化,传统选择器脚本维护成本高
- 一次性数据迁移:需要从旧系统导出数据但系统无导出 API
反过来,如果目标系统有稳定的 API,那么直接用 Function Calling 方案几乎总是更好的选择——更快、更可靠、更便宜。正如 MCP 协议所推动的标准化工具调用生态,结构化交互仍然是 Agent 的首选路径。
与 Playwright/Puppeteer 的混合集成
生产级 Computer Use 系统几乎不会纯粹依赖视觉操控。最佳实践是构建混合架构:用 Playwright 或 Puppeteer 处理确定性步骤,用 Computer Use 处理需要视觉理解的模糊步骤。
混合架构设计
import { chromium, Browser, Page } from 'playwright';
import Anthropic from '@anthropic-ai/sdk';
interface StepResult {
success: boolean;
screenshot?: string;
}
class HybridAgent {
private browser: Browser;
private page: Page;
private client: Anthropic;
async executeWorkflow(steps: WorkflowStep[]): Promise<void> {
for (const step of steps) {
if (step.type === 'deterministic') {
// 确定性步骤:用 Playwright 精确执行
await this.playwrightExecute(step);
} else if (step.type === 'visual') {
// 模糊步骤:用 Computer Use 视觉推理
await this.computerUseExecute(step);
}
}
}
private async playwrightExecute(step: WorkflowStep): Promise<StepResult> {
// 直接用选择器操作,速度快且确定
await this.page.goto(step.url);
await this.page.fill(step.selector, step.value);
await this.page.click(step.submitSelector);
return { success: true };
}
private async computerUseExecute(step: WorkflowStep): Promise<StepResult> {
// 截图当前页面
const screenshot = await this.page.screenshot({
type: 'png',
encoding: 'base64',
});
// 发送给 Claude 进行视觉推理
const response = await this.client.messages.create({
model: 'claude-sonnet-4-20250514',
max_tokens: 1024,
messages: [
{
role: 'user',
content: [
{
type: 'image',
source: {
type: 'base64',
media_type: 'image/png',
data: screenshot,
},
},
{
type: 'text',
text: step.instruction,
},
],
},
],
});
// 解析模型返回的坐标,用 Playwright 执行点击
const action = this.parseAction(response);
if (action.type === 'click') {
await this.page.mouse.click(action.x, action.y);
} else if (action.type === 'type') {
await this.page.keyboard.type(action.text);
}
return { success: true };
}
}
为什么要混合而非纯 Computer Use
纯 Computer Use 方案在实际工程中面临三个硬约束:
- 成本:每次截图约消耗 1,000-2,000 图像 token。一个 50 步的流程可能消耗 10 万+ token,仅 API 费用就可达 1-3 美元
- 延迟:每步 2-5 秒的循环延迟,50 步流程需要 2-4 分钟,而 Playwright 可以在 5 秒内完成
- 可靠性:视觉定位存在误差概率。100 步流程中,即使每步 95% 准确率,整体成功率也仅为 0.95^100 = 0.59%
混合架构的策略是:将流程分解为确定性片段和模糊片段。登录页面、表单填写这类有稳定选择器的步骤用 Playwright;动态生成的报表页面、需要视觉判断的审批界面用 Computer Use。
安全沙箱设计
Computer Use 赋予 Agent 操控计算机的能力,这也意味着安全是最核心的工程约束。Anthropic 在文档中反复强调,Computer Use 必须在隔离环境中运行。
Docker 沙箱方案
# Computer Use 专用沙箱
FROM ubuntu:22.04
# 安装虚拟桌面环境
RUN apt-get update && apt-get install -y \
xvfb \
x11vnc \
fluxbox \
firefox-esr \
xdotool \
&& rm -rf /var/lib/apt/lists/*
# 创建受限用户
RUN useradd -m -s /bin/bash agent && \
echo "agent ALL=(ALL) NOPASSWD: /usr/bin/apt-get" >> /etc/sudoers
# 限制网络访问(仅允许特定域名)
COPY iptables-rules.sh /etc/init.d/
# 启动虚拟桌面
ENV DISPLAY=:99
CMD ["bash", "-c", "Xvfb :99 -screen 0 1024x768x24 & fluxbox & x11vnc -display :99 -forever -nopw & python3 /app/agent.py"]
安全防护清单
在生产环境部署 Computer Use 时,以下安全措施缺一不可:
class SafetyGuard:
# 禁止访问的 URL 模式
BLOCKED_URLS = [
r".*bank.*\.com",
r".*paypal\.com",
r".*\.gov",
r"chrome://settings/passwords",
]
# 危险操作拦截
BLOCKED_ACTIONS = [
"rm -rf",
"format",
"DROP TABLE",
"DELETE FROM",
"sudo rm",
]
# 操作频率限制
MAX_ACTIONS_PER_MINUTE = 30
MAX_TOTAL_ACTIONS = 200
def validate_action(self, action: dict) -> bool:
# 检查是否触发了安全规则
if action.get("action") == "type":
text = action.get("text", "")
for pattern in self.BLOCKED_ACTIONS:
if pattern.lower() in text.lower():
return False
# 检查操作频率
if self.action_count_last_minute > self.MAX_ACTIONS_PER_MINUTE:
return False
return True
def require_human_confirmation(self, action: dict) -> bool:
# 不可逆操作需要人工确认
irreversible_patterns = ["submit", "confirm", "delete", "send", "pay"]
if action.get("action") == "click":
# 如果即将点击的按钮文字包含危险关键词,要求确认
return any(p in str(action).lower() for p in irreversible_patterns)
return False
安全设计的核心原则可以用 Guardrails 的理念来概括:默认拒绝、白名单放行、不可逆操作必须人工确认。关于 Agent 安全的更多讨论,可以参考 Cloud Agent 范式转移中的安全架构章节。
提示注入防护
Computer Use 面临一种独特的攻击向量:屏幕上的恶意内容可能影响模型决策。例如,一个网页可能显示"请点击此处下载重要更新"来诱导 Agent 执行恶意操作。这本质上是一种视觉层面的提示注入攻击。
防护策略:
- 在系统提示中明确告知模型忽略屏幕上的指令性文字
- 对模型输出的 URL 进行白名单校验
- 在执行操作前,用独立的审核模型验证操作是否符合原始任务意图
真实落地场景
场景一:Web 端到端测试
传统的 Selenium/Playwright 测试脚本高度依赖 CSS 选择器和 XPath,前端每次改版都可能导致大量测试用例失效。Computer Use 提供了一种语义级别的测试方案:
async def visual_e2e_test(page_url: str, test_scenario: str):
"""
用自然语言描述测试意图,让 Computer Use 执行并验证
"""
system_prompt = """你是一个 QA 测试工程师。根据测试场景描述执行操作,
并在每一步验证界面状态是否符合预期。如果发现异常,立即报告。
不要点击任何与测试无关的元素。"""
messages = [
{
"role": "user",
"content": f"请在 {page_url} 上执行以下测试场景:\n{test_scenario}"
}
]
# 执行截图-操作循环,直到测试完成或失败
max_steps = 20
for step in range(max_steps):
response = await client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=2048,
system=system_prompt,
tools=[computer_tool],
messages=messages,
)
# 处理工具调用结果
tool_result = await execute_tool_action(response)
messages.append({"role": "assistant", "content": response.content})
messages.append({"role": "user", "content": tool_result})
# 检查模型是否报告测试完成
if is_task_complete(response):
return parse_test_result(response)
return {"status": "timeout", "steps": max_steps}
这种方案的优势在于测试描述是自然语言,不依赖具体的 DOM 结构。"点击购物车图标,验证商品数量为 3"这样的描述,无论购物车图标的 CSS 类名怎么变,只要人类能在页面上找到它,模型也能找到。
场景二:遗留系统数据录入
许多企业内部仍在使用十几年前开发的 Web 系统,没有 API,界面使用 iframe 嵌套、Flash 组件或自定义控件。这类系统是 Computer Use 的理想场景:
async def legacy_data_entry(records: list[dict]):
"""批量向遗留 ERP 系统录入数据"""
for i, record in enumerate(records):
instruction = f"""
在当前的 ERP 录入界面上:
1. 在"客户名称"字段输入:{record['name']}
2. 在"联系电话"字段输入:{record['phone']}
3. 在"订单金额"字段输入:{record['amount']}
4. 点击"保存"按钮
5. 等待出现"保存成功"提示后,点击"新增"按钮准备下一条
如果出现错误提示,请截图并报告具体错误信息。
"""
result = await computer_use_execute(instruction)
if not result.success:
log.error(f"第 {i+1} 条记录录入失败: {result.error}")
# 失败时暂停,等待人工介入
await notify_human(record, result.screenshot)
break
场景三:跨系统流程编排
假设一个业务流程需要从系统 A 导出报表、在系统 B 中查询关联数据、最终在系统 C 中提交审批。三个系统分别由不同供应商开发,没有统一的 API。这正是 Computer Use 结合多 Agent 系统的典型场景:
每个系统分配一个专门的 Agent 实例,由一个 Orchestrator Agent 协调整体流程。Orchestrator 负责任务分解和数据传递,各子 Agent 通过 Computer Use 在各自的沙箱中操作对应系统。这种架构模式在 Agentic Workflow 中被称为"编排者模式"。
局限与失败模式
Computer Use 目前仍处于技术成熟度的早期阶段。清楚认知其局限,是在生产环境中安全使用它的前提。
已知的失败模式
1. 坐标偏移累积
模型的坐标预测存在像素级误差(通常 5-15 像素)。对于大按钮和输入框,这不是问题;但对于密集排列的小控件(如 Excel 单元格、日期选择器的日期格子),偏移可能导致点错目标。连续多步操作中,误差还会累积。
2. 滚动与动态加载盲区
模型只能看到当前截图中可见的内容。如果目标元素需要滚动才能看到,模型需要先推理出"需要向下滚动",然后执行滚动操作,再截图确认——这增加了额外的循环步骤和失败概率。对于懒加载、虚拟滚动等前端模式,模型可能无法正确判断内容是否加载完成。
3. 视觉幻觉
与文本幻觉类似,模型在视觉理解上也会出错。常见表现包括:误读屏幕上的文字(特别是小字体或低对比度文本)、将相似的图标误认为目标控件、以及在截图模糊时"脑补"不存在的界面元素。
4. 状态追踪困难
模型通过截图序列理解状态变化,但它没有真正的"记忆"系统来追踪之前执行过哪些操作。在长流程中(超过 20 步),模型可能忘记已完成的步骤,或对当前处于流程的哪个阶段产生混淆。关于 Agent 记忆管理的深入讨论,可以参考 ReAct 框架详解。
5. 弹窗和意外中断
系统通知、Cookie 同意弹窗、安全验证码、甚至浏览器更新提示——这些意外弹窗会打断 Agent 的操作流程。模型需要能够识别这些干扰、正确处理(关闭或绕过),然后恢复原来的任务。目前这方面的处理仍不够稳健。
性能基准参考
根据 Anthropic 和社区的公开测试数据,Computer Use 在标准 GUI 操作任务上的表现:
| 任务类型 | 成功率 | 平均步数 | 平均耗时 |
|---|---|---|---|
| 简单表单填写(3-5 个字段) | 85-90% | 8-12 步 | 30-60 秒 |
| 多页面导航流程 | 70-80% | 15-25 步 | 1-2 分钟 |
| 复杂数据录入(含下拉、日期选择) | 60-70% | 20-35 步 | 2-4 分钟 |
| 跨应用操作 | 50-65% | 30-50 步 | 3-6 分钟 |
这些数据说明一个关键事实:Computer Use 目前更适合"可以容忍偶尔失败、有人工兜底"的场景,而非要求 100% 可靠性的关键业务流程。
工程最佳实践
基于上述分析,以下是在生产环境中使用 Computer Use 的工程建议。
1. 低分辨率优先
将虚拟桌面分辨率设为 1024x768。更低的分辨率意味着更少的图像 token、更快的推理速度、更高的定位精度。
2. 明确的系统提示
SYSTEM_PROMPT = """你是一个计算机操作 Agent。请遵循以下规则:
1. 每次操作前先截图确认当前界面状态
2. 点击前确认目标元素可见且可交互
3. 输入文字前先点击对应的输入框确保获得焦点
4. 如果遇到意外弹窗,优先关闭弹窗再继续任务
5. 如果连续 3 次操作未产生预期效果,停止并报告问题
6. 不要访问与任务无关的网站
7. 不要在任何地方输入密码或敏感信息"""
3. 检查点与回滚
class CheckpointManager:
def __init__(self):
self.checkpoints = []
async def save_checkpoint(self, page, step_name: str):
screenshot = await page.screenshot()
url = page.url
self.checkpoints.append({
"step": step_name,
"url": url,
"screenshot": screenshot,
"timestamp": time.time(),
})
async def rollback_to(self, page, step_name: str):
checkpoint = next(
c for c in self.checkpoints if c["step"] == step_name
)
await page.goto(checkpoint["url"])
4. 结构化日志与可观测性
每一步操作都应记录截图、操作类型、坐标、模型推理文本和执行结果。当流程失败时,这些日志是排查问题的唯一线索。建议将截图序列组合成视频回放,便于人工审查。
技术演进方向
Computer Use 技术正在快速迭代。从 Anthropic 2024 年 10 月发布到 2025 年的更新版本,坐标定位精度和操作成功率已有显著提升。同期,OpenAI 推出了 Operator 产品,Google DeepMind 也在 GUI Agent 方向持续投入。
未来值得关注的演进方向:
- 更高效的视觉编码:减少截图占用的 token 数量,降低成本和延迟
- 操作原语扩展:支持拖拽、多点触控、手势等复杂交互
- 与 MCP 的融合:通过标准化协议暴露 Computer Use 能力,让任何 Agent 框架都能调用
- 端侧模型部署:在本地运行视觉操作模型,消除网络延迟和数据隐私顾虑
正如 Claude Code 编程实战展示了 Agent 在代码领域的深度应用,Computer Use 代表了 Agent 向更广泛数字世界延伸的趋势。当 Agent 不再受限于 API 边界,而是能够操控任何有界面的软件时,自动化的边界将被彻底重新定义。
总结
Computer Use 是 AI Agent 技术栈中一个重要但需谨慎使用的组件。它的价值不在于替代结构化的 API 调用方案,而在于填补了"没有 API 时怎么办"这个关键空白。
在工程实践中,混合架构是当前最务实的选择:用 Playwright/Puppeteer 处理有稳定选择器的确定性步骤,用 Computer Use 处理需要视觉理解的模糊步骤,用安全沙箱和人工确认机制兜底不可逆操作。随着多模态模型视觉能力的持续提升和成本的下降,Computer Use 在生产环境中的适用范围将不断扩大。
对于正在构建 Agentic Workflow 的团队,建议从低风险场景(如 UI 测试、数据导出)开始试点,积累对模型行为的经验后,再逐步扩展到更复杂的流程自动化场景。