当特斯拉 FSD 能够在复杂的城市道路中识别行人、规避障碍时，同样的视觉感知技术正在悄然迁移到你的电脑屏幕上。这一次，AI 想要操控的不再是方向盘，而是你的鼠标和键盘。

一、从 FSD 到 Computer Use：视觉决策的范式迁移

2024 年，Anthropic 发布 Claude 3.5 Sonnet 时首次正式推出 “Computer Use” 能力，紧接着 OpenAI 发布 Operator，Google 发布 Project Mariner。三大 AI 巨头在同一年内集体押注同一个技术方向——这在 AI 发展史上极为罕见。

核心逻辑并不复杂：如果神经网络能够理解现实世界的复杂场景并做出驾驶决策，那么理解一个高度标准化、规则清晰的 GUI 界面，理论上应该更容易。

但事实真的如此吗？

当我们深入拆解这套技术栈时，发现其背后的架构设计远比想象中复杂。它不仅仅是一个"看图说话"的 VLM（Vision Language Model），而是一个完整的感知-认知-执行闭环系统。

---

二、技术深潜：AI 如何"读懂"屏幕

2.1 Set-of-Mark (SoM)：视觉定位的核心突破

2023 年 4 月，微软研究院发表论文《Set-of-Mark: Visual Prompting for Large Vision Language Models》，这篇论文成为后来所有 Computer Use 系统的技术基石。

核心问题：传统的 VLM 擅长描述图像内容，但无法精确指向"第 3 个按钮"或"表格第 5 行第 2 列"。当 AI 想要操作界面时，它需要像素级的定位能力。

解决方案：SoM 通过在截图上叠加可交互元素的边界框和唯一标识符，将视觉问题转化为"选择题"。

# SoM 标注简化伪代码
class SetOfMarkAnnotator:
    def __init__(self, screenshot: np.ndarray, dom_tree: DOMNode):
        self.pixels = screenshot
        self.dom = dom_tree
        self.marks = {}
    
    def generate_marks(self) -> AnnotatedScreenshot:
        interactive_elements = self.dom.filter(
            lambda node: node.is_interactive()
        )
        
        for idx, element in enumerate(interactive_elements):
            bbox = element.bounding_box
            mark_id = self._generate_mark_id(idx)
            
            # 在元素上绘制标记
            self._draw_bounding_box(bbox, color=COLOR_PALETTE[idx % 10])
            self._draw_label(bbox.origin, mark_id)
            
            # 建立标记与元素的映射
            self.marks[mark_id] = {
                "element_type": element.tag,
                "bbox": bbox,
                "text_content": element.text,
                "attributes": element.attrs
            }
        
        return AnnotatedScreenshot(self.pixels, self.marks)

这套系统的精妙之处在于语义与视觉的对齐：AI 不需要理解"这个按钮是蓝色的"，它只需要知道"标记 [42] 是一个可点击的按钮"。

2.2 Action Space：从连续空间到离散决策

这是整个系统中最容易被忽视、却最关键的架构设计。

早期尝试将屏幕操作建模为回归问题：给定屏幕尺寸（如 1920×1080），直接预测鼠标的 坐标。但这种方法存在致命缺陷——1080p 屏幕有超过 200 万个像素点，模型需要在 200 万维空间中寻找最优解，误差累积极快。

现代方案转向分类+回归混合策略：

维度	纯回归方案	分类+回归混合	纯分类方案
坐标精度	理论无限	像素级	网格粒度
训练难度	极高	中等	低
推理速度	慢	中等	快
泛化能力	差	好	中等
代表方案	早期 MouseTrack	Claude/Operator	RPA 工具

2.3 认知层的上下文管理：记忆的诅咒与救赎

当一个 AI Agent 需要完成"帮我订一张去上海的机票"这样的复杂任务时，它需要跨越多个应用、处理数十个交互步骤。上下文管理成为核心挑战。

问题本质：VLM 的上下文窗口是有限的（Claude 3.5 约 200K tokens），而每一步操作都需要：

1. 当前屏幕截图（约 1000-3000 tokens）
2. DOM 树压缩信息（约 500-2000 tokens）
3. 历史操作记录（累积增长）
4. 任务规划与推理链

工程解决方案：分层记忆架构

class AgentMemoryManager:
    """
    三层记忆架构：
    - Working Memory: 最近 3-5 步的完整截图和动作
    - Episodic Memory: 关键状态快照 + 语义摘要
    - Semantic Memory: 任务目标 + 用户偏好 + 学习到的模式
    """
    
    def __init__(self, max_working_steps: int = 5):
        self.working_memory = deque(maxlen=max_working_steps)
        self.episodic_memory = VectorStore(embedding_model="text-embedding-3-small")
        self.semantic_memory = {
            "task_goal": None,
            "user_preferences": {},
            "learned_patterns": []
        }
    
    def compress_episode(self, steps: List[ActionStep]) -> EpisodeSummary:
        """将连续步骤压缩为语义摘要"""
        key_frames = self._extract_key_frames(steps)  # 提取关键帧
        action_summary = self._summarize_actions(steps)  # 动作摘要
        
        return EpisodeSummary(
            key_frames=key_frames,
            summary=action_summary,
            embedding=self._encode(key_frames + action_summary)
        )

这套架构的核心思想是：不是所有历史都同等重要。只有当任务失败需要回溯、或遇到相似场景需要参考时，才从 Episodic Memory 中检索相关经验。

---

三、电竞场景：为何 Faker 暂时还不用失业

3.1 OpenAI Five vs Visual Agent：上帝视角与人类视角的本质差异

2018 年，OpenAI Five 击败 Dota 2 顶级职业选手。2024 年，Google DeepMind 的 SIMA 在多款游戏中展现出色表现。但为什么至今没有任何 AI 能在《英雄联盟》中战胜 Faker？

核心原因：接口依赖度的本质差异

维度	OpenAI Five (Dota 2)	Visual Agent (LoL 理论)
感知方式	游戏内部 API	纯视觉像素
信息完整度	100%（上帝视角）	受限于屏幕范围
决策延迟	<50ms	500-2000ms
操作精度	像素级精确	依赖视觉定位，存在误差
训练数据	数十亿自我对局	无大规模训练数据
环境确定性	完全确定	需处理视觉噪声

3.2 反应速度的鸿沟：数据说话

指标	人类顶级选手	普通玩家	当前 VLM Agent
视觉反应时间	150-200ms	200-300ms	300-500ms (视觉编码)
决策时间	50-100ms	100-200ms	500-1500ms (LLM 推理)
操作执行	50-100ms	100-150ms	50-100ms (API 调用)
总延迟	250-400ms	400-650ms	850-2100ms

结论：在需要毫秒级反应的 MOBA 游戏中，当前的 Visual Agent 在 Faker 面前，就像一个喝醉酒的青铜玩家。马斯克若真想用 AI 挑战电竞选手，必须解决 VLM 推理延迟这一根本性瓶颈。

---

四、安全与伦理：当 AI 拥有你的鼠标权限

4.1 沙箱隔离架构

当 AI 能够控制你的电脑时，安全设计不再是"可选项"，而是"生死线"。

4.2 危险操作的定义与拦截

业界（Anthropic、OpenAI）普遍采用分级权限模型：

{
  "action_classification": {
    "SAFE": {
      "description": "只读操作，无副作用",
      "examples": ["截图", "读取文件", "浏览网页"],
      "auto_approve": true
    },
    "CAUTION": {
      "description": "有副作用但可逆",
      "examples": ["发送邮件", "填写表单", "复制文件"],
      "auto_approve": false,
      "require_confirmation": "first_time_only"
    },
    "DANGEROUS": {
      "description": "不可逆或高影响操作",
      "examples": ["删除文件", "系统设置修改", "金融交易"],
      "auto_approve": false,
      "require_confirmation": "always",
      "require_reason": true
    },
    "FORBIDDEN": {
      "description": "绝对禁止",
      "examples": ["格式化磁盘", "修改密码", "安装软件"],
      "auto_approve": false,
      "block_regardless_of_user_consent": true
    }
  }
}

---

五、技术展望：从工具使用到工具创造

5.1 当前局限与突破方向

技术瓶颈	当前状态	潜在突破方向	预计时间线
VLM 推理延迟	500-2000ms	专用推理芯片 + 模型蒸馏	2025-2026
跨应用状态保持	不稳定	统一上下文协议 (MCP)	2024-2025
复杂任务规划	5-10 步后失效	Tree-of-Thought + 世界模型	2025-2027
小目标识别	<20px 元素困难	高分辨率视觉编码器	2024-2025
动态界面适应	依赖重新截图	视频流实时理解	2025-2026

5.2 终极形态：AI 不只是使用工具，而是创造工具

当 Visual Agent 足够成熟时，最震撼的应用场景不是"帮我订机票"，而是：

“帮我写一个自动化脚本，每天早上 9 点检查我的邮件，把所有来自老板的紧急任务汇总成 Notion 待办事项，并在 Slack 上给我发送摘要。”

这不是科幻——而是 Agent 编写 Agent 的递归能力。AI 不再是工具的使用者，而是工具的创造者。

---

六、结语：人机关系的范式重构

站在 2025 年的节点回望，Computer Use 的意义可能不亚于当年的图形用户界面（GUI）。

GUI 让人类可以通过"看"和"点"来操作计算机，降低了使用门槛。而 Computer Use 让 AI 也获得了同样的能力——AI 不再需要 API 接口，它可以像人一样使用任何软件。

这意味着：

• 软件开发商不再需要专门开发 AI 接口，任何有 GUI 的软件都是 AI-ready
• 自动化门槛将降至零，任何会描述任务的人都能拥有私人自动化助手
• 人类与计算机的交互方式将被重塑，我们可能不再需要亲自操作软件

回到 Faker 与 AI 的对比：今天，AI 在反应速度上还远不及人类顶尖选手。但 AI 的进化速度是指数级的，而人类的生理极限是恒定的。Faker 今年 28 岁，他的反应速度已经开始下滑。而 5 年后的 VLM，可能会比今天快 100 倍。

当那一天到来时，我们面临的问题可能不是"AI 能否战胜人类"，而是"人类还有什么独特价值"。

这个问题的答案，将决定我们与 AI 共处的下一个时代。

---

参考资源

核心论文：

• Set-of-Mark: Visual Prompting for Large Vision Language Models - Microsoft Research, 2023
• Grounding Large Language Models in Interactive Environments - Microsoft Research

开源项目：

• Anthropic Computer Use Demo - 官方 Computer Use 实现示例
• OpenAI Operator - OpenAI 官方 Agent 产品
• OS-Copilot - 开源通用计算机控制框架
• UFO - 微软 Windows Agent 框架

行业规范：

• Model Context Protocol (MCP) - Anthropic 主导的 Agent 上下文协议
• OpenAI Function Calling - OpenAI 工具调用规范

性能基准：

• OSWorld - Computer Use 评估基准
• World of Bits - OpenAI 早期 Agent 环境