声明：本文由 AI 辅助创作，经作者核实与修订。

这两天用 Google Antigravity 整理和分发博客文章的时候，我留意到一个细节：它操作我电脑上 Chrome 浏览器的方式，不用起 Playwright，也不走浏览器扩展，直接在终端里调 macOS 自带的 osascript（AppleScript）。

这引起了我的好奇。在此之前，我让 Codex 操作浏览器经常卡壳。要么是浏览器扩展报 Browser is not available，得手动去重连；要么是另起了一个干净的浏览器实例，里面什么登录态都没有，面对登录框干瞪眼。后来我让 Codex 也改用这套方式，直接通过 AppleScript 配合系统剪贴板去操作我已经打开的 Chrome，流程顺畅了不少。

macOS 原生指令在 Agent 浏览器操作里的隐藏优势头图
macOS 原生指令在 Agent 浏览器操作里的隐藏优势头图

为什么这套上世纪九十年代的技术在 2026 年反而比新的专用方案好用？既然好用，为什么平时很少听人提起？怎么引导 Agent 把它用好？结合日常用来辅助发文的经验，聊聊背后的逻辑和选型思路。

为什么日常任务里它比新方案更顺手

市面上给 Coding Agent 配浏览器的方案很多，体验差距很大，原因在于它们操作的对象不同。

主流的几类方式放在一起看：

方式 操作的对象 登录态 Agent 拿到的数据 主要短板
Playwright 新开的独立浏览器 默认没有，需单独登录或导 Cookie 页面无障碍文本快照，按编号点元素 工具说明和页面快照占大量上下文；处理不了 Canvas
Chrome 调试协议 (CDP) 新开 Chrome 或接调试端口 日常配置受安全限制，多为干净环境 DOM、控制台报错、网络请求 调试能力强但配置麻烦；受 Chrome 136 安全策略限制
视觉看图点击 (Computer Use) 屏幕上的任意软件 操作自己桌面时有 屏幕截图，按坐标点按 每步都要传图片，慢且贵；窗口移动或缩放容易点偏
浏览器扩展 (如 Claude 扩展) 日常使用的 Chrome 有，共享日常登录态 DOM、控制台、网络请求、截图 需要安装扩展并保持连接，偶尔断连，各家不通用
AppleScript 已经开着的 Chrome / Safari 有，进程本身就是日常登录状态 脚本里指定要什么就回什么文本 拿不到网络瀑布流；只能在 Mac 上跑

主流 Coding Agent 浏览器控制路线对比与选型
主流 Coding Agent 浏览器控制路线对比与选型

日常写代码或发文章时，AppleScript 让人觉得顺手主要有三个原因：

第一，省去登录步骤。
很多网页后台有短信验证、扫码或二次验证。用 Playwright 或独立 CDP，Agent 面对的是一个全新的浏览器窗口，进不了后台。AppleScript 直接操作你正在用的浏览器进程。网页里的请求带着你原有的登录凭据，站点把它当成正常的人类访问，省去了反复处理登录态的麻烦。

第二，避开了近年浏览器的安全收紧。
你可能会想，为什么不直接让调试工具连我们日常的 Chrome？因为官方把这条路收窄了。从 2025 年 3 月的 Chrome 136 开始，出于防范恶意软件窃取凭据的考虑，调试端口对默认的用户数据目录不再生效，必须指向独立的测试目录。Safari 那边更严格，底层调试通道需要苹果私有签名，第三方程序进不去；哪怕是苹果官方在 Safari 27 里内置的调试工具，也明确运行在隔离会话里，拿不到日常数据。想操作已经登录的日常浏览器，剩下的途径不多。

第三，对 Agent 几乎没有上下文负担。
给 Agent 加一套 Playwright 工具，几十个工具定义先吃掉上万 Token，每操作一步还要传一整屏页面结构。而 AppleScript 是 Mac 系统自带的能力，Agent 本来就有执行命令的权限，不需要提前塞入复杂的工具清单。想查个标题、开个网页，一行命令发出去，终端直接拿回结果。

它是怎么跑通的：三步通信与两道门禁

抛开晦涩的系统名词，这套机制在底层跑通的方式分为三步：

  1. 终端派发指令：Agent 在命令行调用 osascript，向 Chrome 或 Safari 发送控制语句。
  2. 浏览器执行操作：浏览器收到 Apple 事件后按指令执行，比如匹配标签页网址、读取页面属性，或者在当前上下文运行一段 JavaScript。
  3. 结果回传终端：页面执行后的纯文本结果直接经由标准输出返回，Agent 拿到文本再决定下一步操作。

绝大多数查询、文本提取和脚本点击可以在后台静默执行，不需要抢占光标，也不会打扰前台的日常工作。

整个流程里有两道门禁需要用户手动放行一次：

  • 第一道是系统权限：Mac 系统的隐私设置（自动化权限）。第一次运行时，系统会弹窗询问是否允许终端控制 Chrome，点允许后系统就记住了。
  • 第二道是浏览器权限：浏览器菜单里的开发者开关。如果只是读网址不需要这道门，但只要需要往网页里注入代码，就得去浏览器菜单里勾选「允许通过 Apple 事件运行 JavaScript」。Chrome 和 Safari 都有这个开关，勾上一次即可。

AI 技能是怎么把它整合进工作流的

在实际使用中，我们不会让 Agent 每次抓瞎现写系统脚本。以日常把 Markdown 文章自动化同步到各大内容平台草稿箱的流程为例，它被整合成了一条四步流水线：

Agent 辅助发文自动化流水线架构图
Agent 辅助发文自动化流水线架构图

  1. 按具体网址找标签页：Agent 先在后台扫描所有打开的窗口，找到具体匹配那篇草稿网址的标签页，绝不乱动用户正在浏览的其他网页。
  2. 把排版好的内容塞进剪贴板：复杂的网页富文本编辑器往往有内部状态，直接修改网页文字容易引起排版错乱。更稳妥的做法是脚本把 Markdown 转换好的富文本或图片，先放进 Mac 系统的剪贴板。
  3. 定位光标，敲一下粘贴：脚本通过后台代码把网页光标定位到正文位置，随后把浏览器窗口短暂切到前台零点几秒，模拟敲一下键盘上的 Cmd+V。在编辑器看来，这就是人类从剪贴板粘贴进来的内容，图片和排版会自动触发平台的正常上传流程。
  4. 重新核对并点保存：粘贴完成后，脚本立刻回到后台重新读取页面，确认表格行列没有丢失、图片已经加载完成，最后调用页面上的保存草稿按钮。

整个流程里，用户只需要对 Agent 说一句话，剩下的定位、排版、粘贴和校验都由后台脚本打配合搞定。

自动化接入时的避坑细节

在长期的使用中，这套浏览器控制方式之所以让人觉得顺畅，离不开几个实际踩坑后沉淀下的原则：

1. 富文本走系统剪贴板，避免直接篡改 DOM

以前尝试直接用爬虫接口往平台发包，或者用 JavaScript 脚本暴力改动网页 DOM，结果往往是格式错乱、账号被风控，甚至破坏了网页编辑器的撤销栈。

实践里更稳妥的做法，是顺应人类原有的使用界面：

  • 平台编辑器支持富文本粘贴，就通过脚本准备好标准的富文本放入系统剪贴板；
  • 平台需要单张上传配图，就模拟真实的粘贴按键，让编辑器自带的上传通道去接收图片；
  • 页面有内部状态校验时，直接修改输入框节点往往无法触发前端框架的数据绑定，模拟原生按键反而最不容易出 Bug。

2. 自动化止步于「保存草稿」

无论脚本跑得多顺，自动化的边界应当固定在「保存草稿」这一步，绝不允许 Agent 替人按下最终的「正式发布」。

这种保持边界感的设计，既让 Agent 承担了最枯燥的搬运和排版校验工作，又把最终的把关权牢牢留在人类手里。

这么好用，为什么平时很少听说？

很多人会疑惑：既然它省事又好用，为什么整个 AI 行业在宣传浏览器自动化时，都在提 Playwright、Puppeteer 或者各类云浏览器，很少大面积推它？

这里有几个现实的原因：

1. 它是 macOS 独占技术，无法做成通用商业标准。
大部分商业 AI Agent 运行在云端服务器、Linux 容器或者 Windows 环境下。云端根本没有 Mac 系统，自然无法依赖 AppleScript。商业软件追求的是跨平台和容器化部署，这让行业的主流投资全部倒向了以 Chromium 为基础的跨平台自动化框架。

2. 缺乏网络层面的可观测性。
它面向桌面级协同控制，没有针对专业的前端开发调试场景做设计。在 AppleScript 里，你看不到接口请求的具体返回、抓不到报错堆栈，也无法精确判断静态资源是否下载完毕。对于要写自动化测试、抓包分析的工程师来说，它的能力是不够用的。

3. 语法小众，且异步处理反直觉。
AppleScript 本身的语法风格特殊，年轻一代开发者很少接触。加上它属于同步机制，遇到现代网页里常见的异步操作（比如网络请求），如果不加处理，它拿到的结果通常是一行没有实际意义的提示文本，并且不会报错。没踩过坑的人很容易卡在这里，误以为这套机制无法胜任复杂操作。

4. 哪些工具其实在悄悄封装它？
虽然在云端不常见，但在 Mac 系统的本地效率工具圈子里，它几乎是底层事实上的通用基石。比如：

  • Raycast 和 Alfred 的浏览器插件：用来列出标签页、一键搜索当前网页、收集书签的扩展，底层基本都是通过它来读取浏览器的。
  • 本地宏工具：Keyboard Maestro、BetterTouchTool 操作日常网页和管理标签页的动作，用的也是这套接口。
  • 面向本地的 AI 插件：比如开源的 safari-mcp、claude-for-safari，以及各类控制日常 Chrome 的本地 Skill，核心走的都是相同的通信路径。

人类该怎么引导 Agent 使用，如何选型

作为使用者，不用去记具体的脚本语法，清楚什么场景选什么方案、给 Agent 明确边界即可。

如何引导 Agent 使用这套能力

如果你希望你的 Agent（无论是 Codex、Claude Code 还是 Antigravity）在本地操作浏览器时更顺手，可以在提示词或项目的规范文件里给它明确这几条指引：

  1. 限定操作对象：明确告诉它优先控制本地已经打开的日常浏览器，不用去启动无头浏览器或连外部扩展。
  2. 锁定目标网址：要求它在操作前必须通过完整的 URL 匹配标签页，禁止用“第一个标签页”这种模糊定位，防止误伤正在看的其他网页。
  3. 遇富文本用系统剪贴板：面对公众号、语雀、知乎等富文本编辑器，提醒它优先将排版内容送入系统剪贴板再触发粘贴，避免直接篡改页面结构导致状态混乱。
  4. 安全底线停在草稿：明确要求所有自动化操作到保存草稿为止，最后的公开发布由人工点击确认。

什么时候该用它，什么时候换别的

没有万能的方案，选择取决于任务所处的环境：

  • 选 AppleScript + 日常浏览器：
    适合个人在 Mac 电脑前完成日常高频操作。比如把写好的稿子发到几个平台的草稿箱、抓取自己已经登录的系统后台数据、对多个标签页做整理。几步内就要出结果，不想花时间去登录验证，也不想让浏览器扩展频繁报错。
  • 选 Chrome 开发者工具协议 (CDP / DevTools)：
    适合做网页开发和排查 Bug。需要盯着控制台有没有红字报错、查看接口返回慢不慢、排查样式错位，这时候需要专业调试协议提供的数据。
  • 选 Playwright / 自动化测试框架：
    适合正式的工程化验证。需要跨 Windows、Linux 多个平台运行，或者要把测试流程放进代码仓库的自动化流水线里每天夜间回归测试。
  • 选视觉看图点击 (Computer Use)：
    适合作为最后的兜底手段。比如网页是一个整块由 Canvas 渲染的游戏或设计图表，DOM 里面没有文字节点可抓，或者需要操作非网页的独立桌面软件时，才值得用成本更高的截图识图方案。

分清楚这些工具的边界，在合适的环节用对应的手段，本地编写和自动化的体验就会顺畅得多。

参考资料

关于作者