AI 操控浏览器，到底有多烧钱？
最近半年，AI Agent 这个赛道火得一塌糊涂。Cursor、Devin、OpenHands……各种"AI 程序员"轮番登场。但如果你自己动手搭过一个能操作浏览器的 Agent，大概率踩过同一个坑——token 消耗炸了。
这事挺反直觉的。让 AI 看一眼网页，你以为是"看一眼"，实际上它要么接收一大坨原始 HTML（一个复杂页面动辄 10 万 tokens），要么收一张截图让视觉模型去猜（GPT-4o 每步大概 $0.01，多步操作下来钱包在滴血）。
Hacker News 上有个帖子说得很直白：Vision 模型做浏览器操控，每步 3-10 秒延迟，$0.01 成本，还会"幻觉坐标"——按钮在 (200, 300)，AI 点到了 (210, 298)，刚好偏了十像素，就点到了广告上。
你想想，让一个 AI 帮你"去某个网站下载个报告"，光来回交互就可能烧掉好几百 tokens 的截图费用。这谁顶得住？
开发者社区对此的吐槽从来没停过。有人用 Playwright + LLM 套了一层，发现一个月账单比服务器还贵；有人试了 Raw DOM 方案，100k+ tokens 的上下文窗口直接爆掉。
这事儿的核心矛盾是：浏览器世界是给"人眼"设计的，不是给"模型"设计的。
直到最近刷 GitHub，看到一个叫 PinchTab 的项目，才觉得这思路对了。
PinchTab：把浏览器"翻译"给 AI 听
PinchTab 是一个用 Go 写的独立 HTTP 服务，干的事情很朴素——让 AI Agent 通过 API 操控 Chrome。
没有花哨的名字，没有"颠覆性范式转移"的营销话术。GitHub 项目描述就一行：
Browser control for AI agents
它的核心卖点有三个：
1. Token 消耗压缩到 ~800 tokens/页
不是截屏，不是原始 HTML。PinchTab 用的是 Accessibility-first 的方式，把页面"翻译"成结构化的快照。可交互元素带上稳定的 ref 引用（比如 e5），AI 不需要去猜坐标，直接用 ref 就能点击、填写。
800 tokens 对比原始 HTML 的 100k+，差了一个数量级以上。官方声称 5-13 倍的成本节省，这个数字我没测过，但思路本身是对的——丢掉图片、CSS、脚本这些对 Agent 决策无用的噪音，只保留结构化的交互信息。
2. 单文件 ~15MB，零外部依赖
一个 Go 二进制，下载下来直接跑。不需要装 Node.js，不需要 Python 环境，不需要 Docker。curl 一行命令就装好：
curl -fsSL https://pinchtab.com/install.sh | bash
这在"一个 Chrome 扩展加三个 npm 包才能跑"的浏览器自动化圈子里，简直是清流。
3. 同时支持 Headless 和 Headed 模式
Headless 就是后台无窗口运行，适合自动化抓取。Headed 模式会打开真实的 Chrome 窗口——这意味着你可以用已有的登录态、Cookie、浏览器扩展。
比如让 Agent "登录我的工作账号，下载本周报表"，用 Headed 模式 + 已保存的 Profile 就能直接干，不用反复输密码。
核心原理：它到底怎么省 Token？
PinchTab 的关键设计可以拆成几层来看：
Server-Bridge 架构
PinchTab 不是直接在 Agent 进程里启动 Chrome（那是 Playwright/Puppeteer 的老路）。它把控制面和数据面分开了：
- Server：主控进程，暴露 HTTP API，管理 Profile、实例、路由
- Bridge：每个 Chrome 实例对应一个轻量 Bridge 运行时
这样做的好处是 Agent 不用操心 Chrome 生命周期，Server 统一调度，支持多实例并行。
Accessibility Tree 而非 DOM
这是最关键的一步。传统方案要么把 document.body.innerHTML 全倒出来（噪音太多），要么截图让视觉模型看（太贵太慢）。
PinchTab 用 Accessibility Tree 做中间层——浏览器本身对可访问性有完整的支持，能精确告诉你页面上有哪些按钮、输入框、链接，它们的位置关系是什么。这个信息对 Agent 做决策来说，已经足够了，而且体积小得多。
Ref 引用代替坐标
很多浏览器自动化方案让 AI 猜坐标。PinchTab 给每个可交互元素分配一个稳定的 ref（如 e5）。Agent 说"点击 e5"，而不是说"点击 (200, 300)"。坐标会因屏幕尺寸、缩放比例变化而失效，ref 不会。
结构化快照
PinchTab 的 snap 命令返回的是类似这样的结构：
[e3] input: "搜索框"
[e5] button: "搜索"
[e7] link: "关于我们"简洁、无歧义、省 token。Agent 拿到这个就知道该点哪个、该填哪个。
动手试试
安装完之后，整个流程就三步：
第一步：启动服务
# 安装并启动后台 daemon（推荐日常使用）
pinchtab daemon install
pinchtab daemon
# 或者直接前台运行
pinchtab server服务默认跑在 http://localhost:9867。
第二步：用 CLI 操控浏览器
# 打开一个页面
pinchtab nav https://pinchtab.com
# 获取可交互元素快照
pinchtab snap -i
# 点击第 5 个元素
pinchtab click e5
# 填写输入框
pinchtab fill e3 ""
# 按回车提交
pinchtab press e7 Enter
# 提取页面文本（token 高效方式）
pinchtab text
第三步：HTTP API 调用
如果你是在写 Agent 代码，直接调 HTTP API 更方便：
# 创建 Profile
PROF=$(curl -s -X POST http://localhost:9867/profiles \
-H "Content-Type: application/json" \
-d '{"name":"work"}' | jq -r '.id')
# 启动 Headless 实例
INST=$(curl -s -X POST http://localhost:9867/instances/start \
-H "Content-Type: application/json" \
-d "{\"profileId\":\"$PROF\",\"mode\":\"headless\"}" | jq -r '.id')
# 打开标签页
TAB=$(curl -s -X POST http://localhost:9867/instances/$INST/tabs/open \
-H "Content-Type: application/json" \
-d '{"url":"https://pinchtab.com"}' | jq -r '.tabId')
# 获取页面快照
curl "http://localhost:9867/tabs/$TAB/snapshot?filter=interactive"
# 点击元素
curl -X POST "http://localhost:9867/tabs/$TAB/action" \
-H "Content-Type: application/json" \
-d '{"kind":"click","ref":"e5"}'API 的设计风格很 RESTful，状态都是通过 ID 引用的，干净利落。
安全这事，它做得挺谨慎
PinchTab 的安全策略一句话概括：默认只绑定 127.0.0.1，默认只允许访问本地网站。
这很重要。给 Agent 开浏览器控制权，本质上是在开一个大口子——恶意网页可以反过来利用浏览器自动化接口做坏事。PinchTab 默认的 IDPI（本地域名白名单）机制确保 Agent 不能随便导航到互联网上的任意页面，除非你主动开放。
另一个细节：它把"attach 外部 Chrome 实例"这个高级功能默认关闭了。这功能很方便，但也很危险——意味着任何能访问本机的进程都能接管你的浏览器。默认关掉是正确决策。
当然，如果你想搞分布式部署（多台机器、远程桥接），它也支持，但官方文档反复强调：这是高级用法，你自己负责安全配置。
适合什么场景？
几个我觉得比较实际的使用场景：
网页数据抓取：让 Agent 自动翻页、提取结构化数据，token 消耗远低于截图方案。
表单自动化：自动填表、提交、验证。Headed 模式可以复用已登录的 Chrome Profile。
QA 测试：多实例并行跑测试，每个实例独立 Profile，互不干扰。
树莓派上的 Agent：官方明确说 ARM64 是"first-class 支持"，自动检测系统 Chromium。这意味着你可以把 PinchTab 跑在树莓派上，作为一个轻量级的"AI 浏览器后端"。
MCP 集成：项目自带 SMCP 插件，暴露 15 个工具（navigate、snapshot、action 等），可以直接接入支持 Model Context Protocol 的 Agent 框架。
聊聊槽点
话说回来，PinchTab 也不是没有问题。
Windows 支持是 best-effort。官方原文："Windows support is currently limited and best-effort"。如果你主力 Windows 开发环境，可能会遇到一些兼容性问题。
文档还在建设中。README 写得不错，但完整文档（pinchtab.com/docs）目前内容不算特别丰富。很多配置项需要翻源码才能搞清楚。
社区还比较早期。GitHub 上 star 数不多，Hacker News 上也才刚被分享不久。出了问题大概率得自己翻 issue 或者看源码。
它不是 Playwright 替代品。如果你需要的是精细的 CSS 选择器控制、复杂的等待策略、跨浏览器兼容性测试，Playwright 依然是更成熟的选择。PinchTab 解决的是一个更聚焦的问题：让 AI Agent 以最低的 token 成本操控浏览器。
写在最后
PinchTab 给我的感觉是那种"做对了核心抽象"的工具。它没有试图做一个大而全的浏览器自动化框架，而是聚焦在 AI Agent 这个场景，把最核心的矛盾——token 成本——用 Accessibility Tree + 结构化快照 + ref 引用这套组合拳解决了。
15MB 的二进制，一行命令安装，HTTP API 干净，CLI 直觉好用。这种"小而精"的工具，在 AI 工具链越来越臃肿的今天，反而显得稀缺。
如果你想搭一个能操作浏览器的 AI Agent，或者对现有的截图方案 token 消耗不满意，PinchTab 值得试试。
