浏览器智能体从"单次自动化脚本"走向"长会话执行体",把身份、会话和治理作为一等工程问题摆上台面。2026 年 4 月,Francesco 在 Hacker News 发布 Cua Driver(Drive any macOS app in the background without stealing the cursor),192 分热度背后不是又一个鼠标宏,而是把"持久身份 + 后台会话 +
浏览器智能体从"单次自动化脚本"走向"长会话执行体",把身份、会话和治理作为一等工程问题摆上台面。2026 年 4 月,Francesco 在 Hacker News 发布 Cua Driver(Drive any macOS app in the background without stealing the cursor),192 分热度背后不是又一个鼠标宏,而是把"持久身份 + 后台会话 + 多 Agent 共存"做成了一组可被治理的工程基线;同年 1 月,同一个团队开源的 Cua-Bench 则把"Computer Use 工程基线"扩展到了评测、训练和 RL 闭环。两件事合在一起,标志着浏览器智能体正在从"演示工程"转向"生产工程"。
一、Computer Use 不再是脚本,而是会话
过去两年,业界对 Computer Use 的关注集中在模型本身:屏幕分辨率、能看见多少 token、是否能点对按钮。但当一个模型被部署到真实客户的生产环境,真正决定它能不能用的,是它背后的"会话"。Cua Driver 的开场提问就直指这一点:
- UI 自动化进程运行时,人类的工作流被吞掉——光标被拖走、键盘焦点被抢占、窗口被拉前台;
- 为了绕开这个问题,工程团队过去只能把所有 Agent 关进虚拟机或 GUI 容器,以牺牲性能和延迟为代价换并发与隔离;
- 但当模型越来越聪明、Agent 数量越来越多,VM 隔离路线不仅成本失控,也无法回答"同一个主机上的多个 Agent 如何不互相碰撞"。
这意味着浏览器智能体的下一个必答题不是"点得多准",而是"会话是否可以被持续地、安全地、可审计地持有"。身份、状态、轨迹、回放、并发边界、权限回收——这五条从传统浏览器自动化里被忽略的治理线,正在被重新定义。
二、Cua Driver 给出的工程基线:六条隐性要求
Cua Driver 在 macOS 上解决的是"不抢前台、不到处跳转 Space、不抢用户光标"这一类体感问题。它的工程路径,实际上回答了浏览器智能体的六条隐性要求。
2.1 输入路径必须脱离硬件层
macOS 的 CGEventPost 走的是 HID 硬件输入流,光标必然随之移动;CGEvent.postToPid 看似绕开了 HID,却在 Chromium 渲染层被识别为"不可信事件"而直接丢弃。这就是为什么早期的浏览器自动化工具"看似能动,实际点不进去"——它们没有拿到 WindowServer 的受信通道。
Cua 团队找到的解法是 SkyLight 的 SLEventPostToPid:它和公开的 per-PID 调用同源,但走的是 WindowServer 的内部信道,Chromium 会把它当作"来自应用自身的事件"接收,而不是"来自合成输入的事件"。这一层切换决定了 Agent 是真在"操作应用",还是在"模拟一个键盘"。
2.2 焦点切换必须做到"激活但不拉前台"
要让 Agent 在用户看不见的窗口里工作,只是"不抢光标"还不够——窗口一旦被强行提到前台,用户的 Space 顺序、应用栈、屏幕录制、注意力全部被打断。Cua Driver 用了 yabai 的 focus-without-raise 模式,加上一次 (-1, -1) 的"预备点击",让点击真正落到目标窗口而不必前置切换焦点。
2.3 Electron 应用的可观测性需要 SPI
当应用窗口不可见,Electron 的 AX tree(无障碍树)很容易被回收,导致 Agent 拿到的是一片空白或一份过时的快照。这是浏览器智能体在长会话里最隐蔽的故障源:不是不能点,是"看不见结构"。Cua Driver 在驱动层补了一段 private remote-aware SPI,确保 AX tree 在窗口遮挡时仍然活跃。
2.4 轨迹必须可回放、可审计
Cua Driver 提供了一组 CLI 命令(例如 cua-driver recording start),可以在执行的同时记录轨迹、截图、操作流和点击标记。第一批内部用例就是"委托 Agent 录产品演示":让 Claude Code 驱动应用,后端抓轨迹,产物类似 Screen Studio,但来源是 Agent 自己——而不是人工操作。
这一点对"持久身份"至关重要:身份不仅意味着"我是同一个 Agent",还意味着"我能证明我做了什么"。
2.5 与 Agent CLI 的低耦合
默认接口是 CLI,而不是 SDK。这一选择决定了 Cua Driver 可以直接被 Claude Code、Codex、Hermes、Cursor 等通用 Agent CLI 调用,而不需要重新适配。它可以替换 Vercel 的 agent-browser、其他 browser-use 类工具,绕开 Chrome DevTools Protocol 这一整套复杂度。
2.6 真实用例验证工程边界
Cua 团队自报的内部用例覆盖了四类:① 替代 agent-browser 类工具;② QA Agent 复现 bug、改代码、验证 UI 时不抢编辑器焦点;③ iMessage 等原生 App 自动化;④ 从 Chrome、Figma、Preview、YouTube 等窗口里抓视觉上下文,不依赖应用方提供 API。这四类组合起来,基本覆盖了"Agent 替我做后台劳动"的全部想象空间。
三、Cua-Bench:把"基线"做成可复现的工程契约
如果说 Cua Driver 解决的是"Agent 怎么操作一台机器",那么 1 月开源的 Cua-Bench 解决的是"我们怎么知道这台机器的边界在哪里"。它的出发点是一个被忽视的事实:同一个 Agent,在 Windows 11 上 90% 成功的任务,到了 Windows XP 可能只有 9%。
这种巨大的方差不是因为模型不够强,而是因为主题、浏览器版本、UI 变体从来不被基准覆盖。OSWorld、Windows Agent Arena、AndroidWorld 这些早期基准,各自有各自的脚手架、数据格式和评估管线——没法让同一个 Agent 在统一环境里跨平台跑测试。它们也只能"测",不能"训"。
3.1 一份契约,覆盖评测与训练
Cua-Bench 的核心设计是"统一环境 + 全生命周期"。一个 CLI 同时支持:多基准评估(原生任务 + OSWorld + Windows Agent Arena 适配器)、跨 OS 变体测试(Windows 11/XP/Vista、macOS 多主题、Linux、Android via QEMU)、从自然语言生成新任务、为 RL 训练提供可编程奖励的模拟环境(HTML/JS 模拟 Spotify、Slack 等)、Oracle 校验在评估前确认环境正确性,以及实时 trace + 截图监控。
这套东西的意义是,浏览器智能体第一次有了一个能在 macOS、Linux、Windows、Android 上自我托管的工程基线,而不是只能跑在实验室云桌面里。
3.2 训练用环境与评估用环境的分与合
Cua-Bench 把"训练用环境"和"评估用环境"做了区分。评估用环境追求真实(原生 OS + 原生应用);训练用环境追求可控(HTML/JS 模拟应用 + 程序化奖励)。两者的接口、CLI 命令、输出 schema 是同一套,这是工程上非常重要的一点——它意味着你不需要为训练和评测维护两套代码。
3.3 实战场景
Cua 团队公开的使用案例覆盖:训练桌面/移动端的 Computer Use 模型、为实验室生成百万级跨 OS 截图数据集、RL 微调、安全/红队评估、回归对比新模型和旧模型。Cua-Bench 的存在意味着,"基线"这个词在浏览器智能体领域第一次有了可复现的工程含义。
四、为什么"持久身份"是 Computer Use 的下一道门槛
把 Cua Driver 和 Cua-Bench 摆在一起看,会发现一个共同的底层需求:持久身份。身份在 Agent 工程里至少有三层含义:
4.1 身份 = 会话状态的可持续性
一个长会话的浏览器智能体,需要在小时甚至天级别保留登录态、本地缓存、Tab 树、Cookie、扩展状态、IndexedDB 数据。如果每次执行都从零冷启动,那不是 Computer Use,只是"点 50 次鼠标然后退出"。Cua Driver 的轨迹记录只是其中一小块,真正难的是跨进程、跨重启的会话延续。
4.2 身份 = 多 Agent 共存的可区分性
当一台主机上同时跑多个 Agent 时,每个 Agent 必须有可区分的输入通道、可区分的窗口/工作区、可区分的会话记录。否则 Agent A 的点击会被 Agent B 的轨迹污染,合规审计和故障复盘无从谈起。Cua Driver 用 SLEventPostToPid + 独立 workspace 隔离,本质上是在做"每个 Agent 都有自己的通道"。
4.3 身份 = 可问责性
当一个 Agent 在企业 ERP 里改了一行字段、给一个客户发了邮件、删了一条订单,业务方必须能反查到:是哪个 Agent、哪个模型版本、哪个任务、哪一次会话、基于哪份提示词和工具调用记录、产生了这一行为。这正是 Cua-Bench 把 trace + 截图作为一等公民的原因:训练和评测的同一套接口,正好也是审计所需的同一套接口。
五、浏览器智能体"会话治理"的新样本
围绕上述三道门槛,2026 年陆续出现了一批"会话治理"类工程样本,大致可以归到三类。
5.1 驱动层样本:Cua Driver / Agent Desktop
Cua Driver 把"驱动层"做成了独立工程层。同一时期,GitHub 上的 agent-desktop(99 分) 也用类似思路把 macOS 桌面自动化封装成 CLI,主打"原生后台驱动 + 不抢用户输入"。这两个项目的共同点是:它们都把"Agent 调用 OS"这一步从 Agent 框架里拆出来,变成可治理的中间层。
5.2 API 层样本:Coasty / Kampala
YC S26 的 Coasty(44 分) 走的是另一条路——把"Computer Use"封装成单一 API。它把 Goal、Plan、Machine、Loop 四层都开放给调用方,任意一层都可以被替换或接管。本质上是把 Computer Use 变成可以被版本化、被限流、被计费的 API 资源。同期 Kampala(100 分) 则把"原生 App 反向工程成结构化 API",让 Agent 不必再用 Computer Use 来点击,直接拿到结构化调用面。
两条路看似相反,实则互补:Computer Use 解决"还没有 API 的应用",结构化反向工程解决"已经有 API 的应用"。两者共同把浏览器智能体从"只能点页面"扩展到"可以点页面 + 可以走 API"。
5.3 评测与训练样本:Cua-Bench / PA-Bench / Vision-Agents 评测
评测侧的样本在 2026 年明显增加。Cua-Bench 提供跨 OS 的统一基线,PA-Bench 用真实个人助理工作流评测 Web Agent,Vibrant Labs 上线的"Vision agents vs. structured APIs on the same internal tool task"则在结构化 API 与 Computer Use 之间做横向对比。三类基准合在一起,意味着"哪个 Agent 在哪个任务上更强"终于有了工程化的可比答案。
六、企业落地 Computer Use 的三条工程建议
对于计划在生产环境落地 Computer Use 的团队,基于 Cua Driver / Cua-Bench 提供的基线,有三条可直接落地的工程建议。
6.1 先建驱动层,再谈模型
不要直接把"Claude Code + 浏览器插件"作为最终方案。第一步是隔离一个"驱动层",负责输入路径、窗口焦点、AX tree 生命周期、轨迹记录。这一层独立之后,模型升级、Agent 框架替换才不会引发连锁返工。Cua Driver 用 CLI 而非 SDK,正是为了让这一层不被任何具体 Agent 锁定。
6.2 把 trace 当作一等公民
trace 不是调试工具,而是产品功能。Cua-Bench 把 trace + 截图开放给训练和 RL,意味着同一份 trace 既能驱动模型改进,也能驱动合规审计、故障复盘、安全红队。生产级 Computer Use 系统里,trace 必须像日志一样有结构、有版本、有保留策略。
6.3 先用基线测一遍,再决定走 Computer Use 还是结构化 API
同一个内部工具任务,Vision Agent 和结构化 API 哪个更便宜、更稳、更可解释?不要凭直觉决定。Vibrant Labs 的对照评测和 Cua-Bench 的多平台跑分,共同提供了一套"先测再选"的工程流程。这一步走完,选 Computer Use 还是选 API,就不再是猜测。
七、结语:身份、会话与治理的工程基线
Cua Driver 用 SkyLight 的 SLEventPostToPid 解决了"不被信任的输入"问题,用 yabai focus-without-raise 解决了"焦点被打断"问题,用私有的 remote-aware SPI 解决了"看不见的 AX tree"问题。Cua-Bench 则把这些能力封装成可复现的基线,让"训练—评测—部署"第一次能在同一个 CLI 体系内闭环。
两件事共同回答了一个根本问题:浏览器智能体如何拥有持久身份。答案是——身份必须建立在驱动层之上,会话必须可记录、可回放、可审计,治理必须从训练阶段就内建,而不是在部署之后补救。
当 Computer Use 从演示走向生产,从实验室走向 ERP、从浏览器扩展走向独立驱动层,持久身份就不再是某一款模型的特性,而是整个工程栈的契约。这是 2026 年浏览器智能体最重要的工程转向,也是 Computer Use 真正"可以落地"的起点。