OpenCLI 调研：它真的能省 token 吗？

这次调研 OpenCLI，我最关心的问题很朴素：它到底是在做一套新的 agent runtime，还是把 browser use / computer use 换了个 CLI 包装？如果它真能省 token，省在哪里？如果省不了太多，那它的真实价值又在哪里？

我的结论先放前面：

OpenCLI 的核心价值在于把浏览器自动化变成 agent 友好的 CLI 原语，并且鼓励把一次性的网页探索沉淀成可复用 adapter。它确实能省 token，但这个收益主要发生在“adapter 写好之后重复运行”的阶段。临时操作未知网页时，它依然会消耗上下文，只是比截图式 computer use 更节制。

它到底怎么实现？

我看了 README、package.json、src/browser/page.ts、extension/src/cdp.ts、src/runtime.ts 和一些设计文档。关键事实很清楚：

• 它没有把 Playwright 或 Puppeteer 当运行时依赖。
• 它的主路径是：CLI 发命令给本地 daemon，daemon 通过 WebSocket 转给 Chrome extension，extension 再用 chrome.debugger 调 Chrome DevTools Protocol。
• 页面读取主要靠 Runtime.evaluate 在页面里执行 JS，生成经过裁剪的 DOM snapshot。
• 点击、键盘、截图、文件上传、网络抓取，用的是 CDP 的 Input.*、Page.captureScreenshot、DOM.*、Network.*。
• Electron app 的控制走直连 CDP，前提是目标 app 暴露 remote debugging port。

所以它更接近一个 browser-use runtime。它用 CLI 把浏览器操作标准化，并且把“网页能力”沉淀成 adapter。这个定位挺聪明：agent 可以先用浏览器原语探索，等流程稳定后，写成 opencli 某站点 某命令，下一次就不用反复看页面了。

它和 computer use 的差异

截图式 computer use 的典型路径是：截图、视觉理解、点击坐标、再截图。这个方式通用，但贵，慢，而且对复杂网页的结构理解很粗。

OpenCLI 尽量走结构化路径：

• 用 DOM snapshot 给 agent 看页面结构。
• 给交互元素分配 [N] ref。
• 网络层默认只返回响应 shape，再按需取具体 body。
• 错误输出尽量结构化，比如 selector ambiguous、stale ref、not found。

这对 agent 是有帮助的。它把“看图猜按钮”改成了“读结构、按 ref 操作、按错误码分支”。这会减少无效 token，也减少一部分误点。

但它没有摆脱 browser automation 的本质。遇到 SPA 重渲染、虚拟列表、custom dropdown、iframe、Shadow DOM、反爬、A/B 测试，还是要 state -> click -> wait -> state 这样一步步来。只是每一步更像机器可读的工具调用。

token 真的能省吗？

能省，但要讲清楚省在哪里。

第一种省法：DOM snapshot 替代截图。
如果任务只是找按钮、填表、读列表，结构化文本通常比图片更便宜、更可操作。截图仍然有用，但适合图表、验证码、纯视觉布局这些场景。

第二种省法：网络响应只看 shape。
很多页面真正的数据在 JSON API 里。OpenCLI 的 browser network 会先给 shape preview 和 cache key，agent 再决定取哪一个详情。这比把所有 XHR 响应一口气塞进上下文要克制。

第三种省法，也是最关键的一种：adapter 沉淀。
一次性探索时，agent 仍然会花 token。可一旦写成 adapter，比如 opencli bilibili hot、opencli 1688 item，后续运行就是确定性 CLI 输出。重复 100 次、1000 次，这时 token 成本才真正掉下来。

所以我不会把它理解成“临时浏览网页也零 token”。更准确的说法是：它把探索阶段的 token 消耗，换成后续可复用的工程资产。

我觉得它真正有价值的地方

它的真实价值不在于“模拟人类点网页”，而在于把网页操作工程化。

普通 agent browser 工具很容易停在一次性操作：今天帮我点完，明天又从头看一遍页面。OpenCLI 的 adapter 模型让 agent 有机会把经验保存下来：这个站点怎么鉴权、endpoint 在哪里、字段怎么映射、什么时候要用 UI fallback、如何 verify。

这有点像把“浏览器操作经验”变成一套小型 SDK。对高频网站、内部系统、运营后台、数据抓取、客服工单、内容平台，这个方向是有意义的。

风险在哪里？

第一，安全边界非常敏感。
它复用你已经登录的 Chrome。daemon 和 extension 有能力读页面、执行 JS、截图、抓网络响应。官方远程编排文档也提醒，daemon 协议没有内置认证；端口暴露出去，风险接近把解锁浏览器交给别人。

第二，本地恶意进程仍然是问题。
它做了 Origin 检查和 X-OpenCLI header，主要防网页 CSRF。可如果本机有恶意进程能访问 localhost，这类防护挡不住。

第三，账号风控和合规风险。
复用真实登录态做自动化，可能触发平台风控。自动点赞、关注、发帖、下载、评论、下单这类写操作更危险。技术上能做，不代表业务上该做。

第四，稳定性不便宜。
adapter 会随网站改版失效。更麻烦的是，verify 通过也可能字段语义错位，比如价格单位、百分比倍率、排序字段、地区字段发生变化。这个项目自己的 adapter-author 文档里也反复强调：别只看 “works”，要肉眼核对字段。

第五，调试痕迹可能泄露数据。
trace、screenshot、network cache、fixtures 都可能落盘。只要里面有 cookie、token、用户数据、后台截图，就会变成新的数据治理问题。

第六，CDP 会和其他工具抢资源。
Chrome 的 debugger attach 机制会和 DevTools、1Password、Playwright MCP Bridge 等工具互相干扰。它源码里也专门写了 attach retry 和冲突提示。

我的最终判断

OpenCLI 是一个务实的方向。它没有发明全新的浏览器控制魔法，它把已有的 CDP 能力、DOM snapshot、网络抓取、adapter 注册、CLI 输出格式组合到一起，做成了一个更适合 agent 的运行面。

如果只拿它做一次性网页点击，收益有限。它会比截图式 computer use 更省、更稳一些，但复杂页面照样要多轮交互。

如果拿它做高频站点自动化，并且愿意把探索过程沉淀成 adapter，价值会明显放大。这个时候 token 才不是核心问题，核心问题变成：这个 adapter 是否稳定、是否安全、是否合规、字段是否可信。

我会把它放在这样的工具箱位置：

• 临时网页任务：可用，但别期待零成本。
• 已登录站点读取：很有吸引力，但要管好权限和数据落盘。
• 高频重复流程：值得写 adapter。
• 高风险写操作：必须加人工确认、审计和回滚意识。
• 企业内部系统：潜力最大，但安全边界要先设计清楚。

一句话：OpenCLI 真正厉害的地方，是把 agent 的网页操作从“临时手艺”往“可复用工程资产”推了一步。这个方向对，但别被 “Zero LLM cost” 这句话带偏。成本会下降，前提是你真的把流程固化了。