OpenCLI：把任意网站、桌面应用和本地工具，收束成 AI Agent 可调用的一层 CLIOpenCLI：把任意网站

OpenCLI：把任意网站、桌面应用和本地工具，收束成 AI Agent 可调用的一层 CLI

最近这一批 Agent 工具，其实都在补同一个缺口：模型会思考、会规划、会写代码，但任务一旦落到真实世界，很快就会撞上几堵墙。

很多网站没有公开 API。就算有 API，权限、登录态、页面里的状态和反爬策略，也常常把外部调用挡在门外。再往前走一步，问题又变成了：就算能碰到这些工具，怎样把它们做成模型能稳定调用的一层表面？这件事远比“让浏览器点几下”难得多。

OpenCLI 值得认真看，不是因为它又做了一个浏览器自动化工具，而是因为它想把这几件事放进同一个框架里：把网站、浏览器会话、桌面应用和本地 CLI，都变成一层统一、可发现、可扩展、适合 AI Agent 消费的命令界面。

这不是一句空口号。按照仓库 README 的定义，OpenCLI 想做的是：

直接提供大量现成 adapter，让你像调用 opencli hackernews top 一样调用网站能力
让 AI Agent 通过你已经登录的浏览器去操作任意网站
让开发者继续把新的站点能力、桌面应用能力、本地工具能力接进来

如果只用一句话概括，我会把它理解成：OpenCLI 想做 AI Agent 时代的统一工具入口。

OpenCLI 到底是什么

OpenCLI 不是一个单点产品，更像四层东西叠在一起。

1. 它是一个网站能力的 CLI 表面

这是最容易理解的一层。仓库里已经内置了大量站点命令，覆盖内容平台、社区、搜索、学术、招聘、电商、知识工具等很多类别。

比如你可以直接这样用：

opencli hackernews top --limit 5
opencli bilibili hot --limit 5
opencli reddit hot
opencli zhihu hot

重点不在于“又多了几个命令”，而在于它把很多原本只能靠网页浏览，或者需要自己写脚本接接口的动作，变成了一层统一输出格式的命令能力。README 明确写了，内置命令都支持 table、json、yaml、md、csv 这些格式，这意味着它不只是给人看，也天然适合喂给脚本和 Agent。

2. 它是一个让 Agent 使用你真实浏览器的运行时

这是 OpenCLI 最有辨识度的一层。

它不是新开一个干净的 headless browser，也不是要求你先把网站研究透再写脚本，而是通过 Browser Bridge 扩展加本地 daemon，把你已经登录的 Chrome 或 Chromium 会话接给 Agent 使用。README 里反复强调的一点是：凭据留在浏览器里。

这点很关键。

很多自动化方案在演示里很好看，一旦碰到登录站点、付费内容、企业后台、社交平台，或者任何需要真实 Cookie 和用户上下文的页面，复杂度都会陡增。OpenCLI 没有回避这件事，而是直接承认：这些状态本来就在浏览器里，那就别再绕一圈去伪造一个外部接口。

所以它提供了一整套 opencli browser 原语，供 Agent 在背后调用，比如打开页面、读取 DOM 快照、点击、输入、等待、抓网络请求、切换 tab、抽取数据、做 recon、做 verify。用户表面上不一定要记这些命令，但正是这层原语，让它不只是“能读站点”，而是真的可以去操作网站。

3. 它是一个 adapter 系统

如果说浏览器原语解决的是“Agent 能不能碰到网站”，adapter 系统解决的就是“这些能力能不能沉淀下来，被反复调用”。

OpenCLI 的核心，不是让每个任务都临场做一次浏览器操作，而是鼓励把网站能力做成稳定命令。比如已经有 twitter trending、xiaohongshu notifications、notebooklm summary、quark ls、ones tasks 这一类具体能力，之后人和 Agent 都可以直接调用。

更重要的是，它把扩展路径讲得很清楚：

想快速写一个本地私有 adapter，可以放进 ~/.opencli/clis/<site>/<command>.js
想长期维护自己的命令集合，可以走 plugin 路线
想改官方 adapter，可以 eject 到本地覆盖
想把现有命令行工具纳入统一入口，可以注册 external CLI

这套设计成熟的地方在于，它没有强迫所有扩展方式都走同一条路，而是根据“代码要不要版本管理”“能力要不要分享”“是不是已经有现成二进制工具”这些现实差异，把路径拆开了。

4. 它还是一个 CLI Hub

OpenCLI 不只关心网站。

README 和文档里写得很清楚，它还能把本地已有命令行工具统一挂到自己的命令空间里。比如 gh、docker、longbridge、ntn、wx、discord、tg 这些工具，都可以通过 opencli <tool> ... 这种方式暴露给用户和 Agent。

这层能力真正有价值的地方，在于统一发现和统一入口。

今天很多 Agent 工作流的问题，不是能力不存在，而是能力散落在不同表面：一部分在浏览器里，一部分在你自己的 shell 里，一部分在某个 Electron 客户端里。OpenCLI 做的，就是尽量把这些入口压成一层看起来一致的命令表面。

它真正解决的，不是“自动化”，而是“工具表面碎片化”

如果把 OpenCLI 只看成浏览器自动化，你会低估它。

它更像是在回答一个更现实的问题：当 AI Agent 开始真正干活时，应该怎么接入那些原本只为人类准备的工具世界？

以前常见的思路大概有两种。

一种是 API-first：谁有 API 就接谁，没有 API 的先放着。这个思路很干净，但覆盖面有限，因为真实世界里没有 API 的站点和工具太多了。

另一种是 browser-first：直接让 Agent 自己用浏览器探索页面、点击、提取。这个思路更贴近真实世界，但如果每次都从零开始操作，成本很高，也不稳定。

OpenCLI 走的是第三条路：

先承认浏览器是重要入口，允许 Agent 直接使用真实浏览器
再把可复用的网站能力沉淀成 adapter
同时把本地 CLI 和桌面应用也接进来
最后让所有能力都出现在统一的命令发现面上

所以它不是简单的 browser automation，也不是传统意义上的 API wrapper，而更像一层 Agent-native tool surface。

为什么它对 AI Agent 特别有意义

我觉得 OpenCLI 最值得关注的，不是“支持的网站有多少”，而是它在设计上明显站在 Agent 这一侧考虑问题。

它区分了“人类直接调用”和“Agent 背后调用”

README 里有一段很明确：站点命令是给人和 Agent 都能直接用的，但 opencli browser 这一层原语主要是给 Agent 用的，普通用户不需要手敲。

这看起来只是文档措辞，实际上代表了产品边界很清楚。

很多工具的问题在于，既想做面向人的 CLI，又想做面向 Agent 的 runtime，最后两边都容易拧巴。OpenCLI 至少在概念上把这两件事拆开了：

对人，暴露的是稳定命令
对 Agent，暴露的是浏览器原语和技能体系

这样整个系统的职责会清楚很多。

它把“技能”当成一等公民

OpenCLI 不只是给命令，还给了一套围绕 Agent 的 skill。

以 opencli-adapter-author 为例，它不是一篇轻量说明书，而是一整套从站点侦察、API 发现、字段解码、output 设计、adapter 生成、verify 校验，到最后回写站点记忆的闭环方法论。它甚至明确要求开发者不要猜字段，不要只追求 verify 通过，而要做肉眼比对和 fixture 验证。

这说明作者并不是把 OpenCLI 当成“命令越多越好”的仓库，而是在认真想一件事：怎样让 Agent 或开发者以更低错误率扩展能力。

这点很重要。因为 Agent 时代真正稀缺的，不只是功能，而是可复用的操作经验。

它很强调确定性输出

README 里有一句话我觉得很关键：Zero LLM cost at runtime。

这句话不只是“省 token”那么简单。它其实在强调另一件事：已经做成 adapter 的能力，运行时尽量走确定性逻辑，而不是每次都交给模型现场发挥。

这对 Agent 工具来说是很务实的选择。

模型当然可以临场操作浏览器，但任何需要重复执行、需要进工作流、需要被组合调用的能力，最后都更适合沉淀成稳定命令。OpenCLI 的 adapter 体系，本质上就是在把一次性的 Agent 行为，转成可复用的程序化能力。

OpenCLI 的架构，为什么比看起来更完整

从 README、adapter 列表、扩展指南和 skill 文档来看，OpenCLI 已经不是“几十个脚本”的状态了，而是有一套比较完整的分层。

第一层：命令表面

用户看到的是 opencli <site> <command>、opencli <tool> ...、opencli browser ... 这些命令入口。

这层负责统一调用体验，也负责统一输出格式和退出码。README 里甚至列出了比较完整的 Unix 风格 exit code 约定，比如空结果、认证失败、配置错误、临时失败分别对应不同 code。这个细节很小，但说明它不是只想“能跑”，而是想让它能自然嵌进 shell、CI、脚本和 Agent 编排里。

第二层：Browser Bridge + daemon

这一层把本地浏览器接进来。扩展负责和浏览器交互，daemon 负责桥接命令和浏览器状态。

从产品视角看，这层最有价值的地方不是“能点页面”，而是它复用了用户原有的登录态和上下文。对于 X、Reddit、知乎、小红书、BOSS 直聘、NotebookLM 这类站点，这几乎决定了工具到底能不能进入真实可用状态。

第三层：adapter 与 plugin

这层负责把一次次探索沉淀成能力资产。

OpenCLI 给出的路径很实用：临时本地 adapter、长期 Git 管理 plugin、官方 adapter 覆盖、外部 CLI 注册，各走各的。你会发现它并不追求抽象得特别漂亮，而是优先保证现实里的协作方式顺手。

比如长期维护的能力，就鼓励放进正常项目目录和 Git；临时实验能力，就允许你直接放在用户目录下跑；已有工具，就不要重写，直接 register 进来。

这是一种很偏工程化的设计，不浪漫，但很有效。

第四层：Agent skill 体系

这一层是 OpenCLI 和很多普通 CLI 工具差别最大的地方。

很多项目把“给 Agent 用”理解成“加一个 MCP 接口”就够了，但 OpenCLI 更进一步，把如何写 adapter、如何修 adapter、如何搜索现有能力、如何使用浏览器原语，分别做成独立 skill。

这件事的价值在于：它不只是提供能力，也在提供能力生产流程。

它的能力边界到底有多大

如果只看 README 一页，你可能会以为 OpenCLI 主要是做社交平台和内容网站。

但 adapter 索引说明，它的边界比这个大得多。

1. 浏览器型网站 adapter

这是最显眼的一类，覆盖面非常广：Twitter、Reddit、知乎、小红书、Bilibili、YouTube、LinkedIn、BOSS、Google、Amazon、NotebookLM、Claude、Gemini、ChatGPT、Doubao、Instagram、TikTok、Facebook、Quark、Xianyu 等等。

这类 adapter 的共性是，能力往往和真实浏览器状态强绑定，很多命令需要登录态、Cookie 或页面上下文。

2. Public API adapter

它也不是所有东西都硬走浏览器。

像 Hacker News、arXiv、PubMed、OpenReview、Binance、Wikipedia、npm、PyPI、Docker Hub、MDN、OSV、Homebrew 这类天然更适合 API 调用的站点，OpenCLI 也提供了公共接口型 adapter。

这说明它不是“浏览器原教旨主义”，而是很务实地在选最合适的接法。

3. Desktop adapter

这一层很有意思，也容易被忽略。

文档里已经列出了一批 Electron 桌面应用 adapter，比如 Cursor、Codex、ChatGPT App、ChatWise、Doubao App、Discord 等。这意味着 OpenCLI 不只是想接网页，也在尝试把桌面端 AI 工具纳入统一控制平面。

如果这个方向继续走下去，它会越来越像一个跨网页、跨本地 CLI、跨桌面应用的 Agent 操作总线。

4. CLI Hub

这层反而可能是最被低估的。

很多团队已经有自己的 CLI，只是还没变成 Agent 可发现的能力。OpenCLI 通过 external CLI registration 提供了一条低改造成本的接入方式。相比重写适配器，这条路对已有工具资产更友好。

上手其实没有想象中复杂

如果你把它当成一个“我想试试”的工具，上手路径并不长。

给普通用户的最短路径

安装 Node.js 21+
npm install -g @jackwener/opencli
安装 OpenCLI 的浏览器扩展
跑一次 opencli doctor
先试几个内置命令

比如：

opencli list
opencli hackernews top --limit 5
opencli reddit hot

如果你有多个 Chrome profile，还可以给 profile 命名并切换默认 profile。这一点在多账号、多身份场景里很实用。

给 Agent 用户的最短路径

如果你的目标是让 Claude Code、Cursor 之类的 Agent 用 OpenCLI，README 推荐的是直接安装 skill：

npx skills add jackwener/opencli

也可以只安装某几个，比如：

opencli-adapter-author
opencli-autofix
opencli-browser
opencli-usage
smart-search

这一步其实也说明了 OpenCLI 的产品思路：它不是只想被人手动使用，而是明确把“被其他 Agent 消费”当成主线之一。

如果你想自己扩展，OpenCLI 提供了四条非常清楚的路

扩展指南是整个项目里我很喜欢的一份文档，因为它没什么空话，几乎全是现实选择题。

路线一：本地私有 adapter

适合快速实验，代码直接放到 ~/.opencli/clis/<site>/<command>.js。

这是最快的闭环。你想先证明能力能不能跑，不需要先搭一个独立仓库，也不需要先处理发布问题。

路线二：本地 plugin / Git 管理的长期命令

如果你希望能力长期维护、版本控制、分享给别人，官方推荐走 plugin。这时命令源代码留在正常项目目录里，再用 opencli plugin install file://... 接进 OpenCLI。

这个取舍很合理，实验阶段追求快，长期阶段追求可维护。

路线三：覆盖官方 adapter

如果官方 adapter 差一点点就够用，或者你想先在本地修一个问题，可以先 eject 到用户目录修改。

这里文档还特意提醒：本地 override 会持续 shadow 官方更新，所以修完提交 PR 之后要 reset。这种提醒说明项目已经踩过真实协作里的坑，而不是只停留在 happy path。

路线四：注册已有 external CLI

如果你已经有成熟命令行工具，最好的办法通常不是重写，而是注册进去。

这一条特别适合团队内部工具、已有数据工具、已有运维 CLI。对很多组织来说，这可能是 OpenCLI 落地最快的一步。

OpenCLI 最聪明的地方，是它没有假装“一种方式能接一切”

很多类似项目最后都会掉进一个坑：用一种看起来很漂亮的统一抽象，试图把所有网站、所有工具、所有运行时都压成同一种模型。

OpenCLI 没完全这么做。

它承认不同对象应该有不同接法：

公共数据站点，直接走 API
强登录态站点，走真实浏览器
可复用能力，做成 adapter
已有工具，直接 external register
长期维护的自定义能力，做成 plugin

这种“分层统一，而不是底层强统一”的思路，我觉得比很多一上来就追求完美抽象的方案成熟。

因为真实互联网本来就是异构的。

它也不是没有代价

如果要把 OpenCLI 当成严肃基础设施看，它当然也有一些很现实的门槛和代价。

1. 浏览器桥接本身就有环境要求

它依赖本地 Chrome 或 Chromium、浏览器扩展、daemon，以及已有登录态。任何一个环节没接好，体验都会受影响。所以 opencli doctor 这种诊断命令不是锦上添花，而是实际可用性的关键组成。

2. Node 版本要求不低

标准安装路径要求 Node.js 21+。对个人开发者这不算大问题，但对一些偏保守的公司环境来说，可能还是要先处理 runtime 兼容性。

3. 浏览器型能力天然会遇到站点变更

这不是 OpenCLI 独有的问题，而是所有浏览器驱动方案都会遇到的问题。站点改 DOM、改接口、改 token 策略，adapter 就可能失效。

不过 OpenCLI 至少没有假装这件事不存在，而是通过 autofix、verify、fixture、site memory 这些机制，尽量把修复过程工具化。

4. 它更像工程工具，而不是零门槛玩具

你当然可以直接拿来跑几个命令，但如果想真正吃到它最强的那部分价值，比如为自己的工作流沉淀 adapter、把内部工具纳入统一表面、让 Agent 稳定消费这些能力，那还是需要一点工程意识。

换句话说，OpenCLI 不是“装完就一切自动发生”的产品，它更像一套很有野心、但也要求使用者理解一些工程边界的基础设施。

为什么我觉得 OpenCLI 值得社区认真讨论

看这类项目时，我最关心的不是“今天能跑多少 demo”，而是它有没有抓住一个会持续存在的问题。

OpenCLI 抓住的那个问题，我觉得会长期存在：

AI Agent 的能力越来越强，但真实世界的工具表面依旧碎片化，而且大多数并不是为 Agent 设计的。

网站有网站的状态，浏览器有浏览器的上下文，本地 CLI 有自己的调用方式，桌面应用又是另一套壳。OpenCLI 做的不是替换它们，而是试图在上面铺一层更统一的接入面。

这件事一旦做成，它的价值就不只是“多一个命令行工具”，而是让很多原本零散、难组合、难被模型稳定调用的能力，开始变成真正可编排的 Agent 组件。

这也是为什么它现在增长很快：截至 2026-05-18，GitHub 上已经超过 2.1 万 star，fork 超过 2100，最近两个月发布节奏非常密，5 月中旬还在持续增加 external CLI 能力和修补具体 adapter。这个信号至少说明，它已经不只是一个概念项目，而是在被大量真实用户拿去碰真实工作流。

如果你准备试 OpenCLI，我会建议从这三个入口开始

先把它当成“现成命令集”

先别急着研究 adapter authoring，先跑几个内置命令，看它的输出格式和能力边界是不是符合你的预期。

再把它当成“浏览器桥接层”

如果你手头有必须依赖登录态的网站任务，比如读取通知、收集内容、导出信息、完成重复性操作，再去试 Agent + Browser Bridge 这一层。你会更容易理解它和普通抓取工具的差异。

最后再决定要不要沉淀自己的 adapter 或 plugin

只有当你遇到重复任务，或者团队内部已经有一批稳定流程时，扩展系统的价值才会真正体现出来。

常见误解

误解一：OpenCLI 就是另一个 Playwright

不对。

它当然能做浏览器操作，但它的目标不只是自动化页面，而是把网站能力和工具能力沉淀成统一命令界面。Playwright 更像测试与自动化框架，OpenCLI 更像 Agent 工作流的工具层。

误解二：OpenCLI 只是抓网站热点的命令集合

也不对。

热门站点命令只是最容易看见的一部分。它真正有潜力的地方，在于浏览器 runtime、adapter 体系、plugin 体系、external CLI hub、desktop adapter 这些层叠起来后的组合能力。

误解三：有了模型，就不需要 adapter 了

恰恰相反。

模型越强，越值得把高频、重复、可验证的操作沉淀成稳定 adapter。这样模型才不会每次都从零探索页面，也不会在同一件事上不断重复付费和试错。

一个更大的判断

如果把时间线拉长一点看，我觉得 OpenCLI 代表的是一类会越来越重要的基础设施：

不是去要求互联网为 Agent 重写一遍接口，而是为 Agent 架一层能进入现有互联网的统一桥。

这条路不一定完美，也肯定会遇到浏览器兼容、站点变化、认证复杂度、扩展维护成本这些现实问题。但和“等所有工具都原生支持 Agent”相比，它显然更务实。

在这个意义上，OpenCLI 最值得看的，不是它今天已经接了多少网站，而是它把一个越来越清晰的命题做成了产品：

网站能力可以被命令化
浏览器上下文可以被 Agent 安全复用
本地工具和桌面应用也可以被纳入同一层入口
一次性的操作经验，可以沉淀成可验证、可分享的 adapter

如果你在做 Agent、自动化、研究工作流，或者在想“怎么把团队已有工具资产真正接给模型”，OpenCLI 很可能是最近最值得亲自装起来跑一遍的项目之一。

OpenCLI：把任意网站、桌面应用和本地工具，收束成 AI Agent 可调用的一层 CLI