OpenCLI：把任意网站变成 CLI，让 AI 代理用你的登录态操作浏览器

一个接口，三种自动化方式

OpenCLI 的核心主张是：把网站、浏览器会话、Electron 应用和本地工具统一成命令行接口。它同时面向人和 AI 代理。文档明确列出三种用法：内置适配器，比如 Bilibili、知乎、小红书、Reddit 和 HackerNews；让 AI 代理通过 `opencli browser` 原语操作任意网页；以及让开发者编写自己的适配器。这种设计把「网站数据获取」和「浏览器操作」两个问题放在同一个工具里。对个人用户，`opencli hackernews top --limit 5` 这类命令可以替代打开浏览器。对 AI 代理，它提供了结构化的 DOM 快照，而不是截图，这直接影响 token 消耗和操作准确性。

浏览器桥接：扩展加守护进程的架构

OpenCLI 连接 Chrome 的方式是浏览器扩展加本地守护进程。扩展负责与网页交互，守护进程负责与 CLI 通信，并且按需自动启动。文档强调每个 Chrome profile 运行各自的扩展实例，这意味着多 profile 场景下需要手动管理。`opencli profile list` 列出已连接的 profile，`opencli profile rename <contextId> work` 分配别名，`opencli profile use work` 设置默认。如果只有一个 profile，OpenCLI 自动使用；如果有多个且未设置默认，它会询问用户而不是猜测。这个设计避免了多开浏览器时的混乱，但也增加了配置负担。对于只用单个 Chrome 的用户，这一步可以跳过。

安装与验证：从 npm 到浏览器扩展

安装分两条路径。桌面用户推荐 OpenCLIApp，它打包了运行时并提供一个系统托盘界面，用于设置、诊断和更新。CLI 用户或服务器环境则用 npm 全局安装 `@jackwener/opencli`，但要求 Node.js 至少 20.18.1。安装后需要装浏览器扩展，推荐从 Chrome Web Store 安装，也可以手动下载 zip 文件，在 `chrome://extensions` 开启开发者模式后加载解压文件夹。验证命令是 `opencli doctor`，它诊断浏览器连通性。首次运行可以从 `opencli list` 开始，查看所有已注册命令。整个过程不涉及复杂的构建步骤，但浏览器扩展的安装是硬性依赖，没有它，浏览器相关命令无法工作。

AI 代理技能：`npx skills add` 的用法

OpenCLI 为 AI 代理提供了一组技能，通过 `npx skills add jackwener/opencli` 安装。技能分为六种：`opencli-adapter-author` 编写新适配器，`opencli-autofix` 修复失效的适配器，`opencli-browser` 驱动真实 Chrome 页面，`opencli-browser-sitemap` 结合站点地图导航，`opencli-sitemap-author` 记录稳定工作流，以及 `opencli-usage` 作为命令参考。每个技能对应一个使用场景，比如「帮我检查小红书通知」会触发 `opencli-browser`。文档明确指出这些命令是为 AI 代理设计的，不推荐手动运行。这种设计意味着 OpenCLI 不只是 CLI，还是一个 AI 代理的浏览器操作层。但它依赖代理正确调用技能，如果代理的指令遵循能力不足，效果会打折扣。

扩展机制：插件、适配器与外部命令

OpenCLI 提供了多种扩展路径。`opencli plugin create` 和 `opencli plugin install file://...` 用于在个人 Git 仓库中维护网站命令；`opencli browser init <site>/<command>` 快速起草私有适配器；`opencli adapter eject <site>` 可以修改官方适配器，`opencli adapter reset <site>` 恢复原状；`opencli plugin install github:user/repo` 安装第三方命令；`opencli external register <name>` 包装现有本地二进制。这个模型把适配器当作可版本控制的代码，而不是配置文件。文档提到 `~/.opencli/clis/` 作为本地草稿目录，说明适配器本质上是脚本或代码片段。对于想深度定制的用户，这个机制很灵活；但官方适配器的维护质量取决于上游更新频率，一旦网站结构变化，适配器可能失效，这时 `opencli-autofix` 技能就派上用场。

局限性：登录态依赖与多 profile 的复杂度

OpenCLI 的浏览器操作依赖已登录的 Chrome 会话，这是它的核心优势，也是最大的限制。如果浏览器未登录目标网站，AI 代理或 CLI 命令就无法访问受限内容。文档没有提及如何处理会话过期或登录失效，只提到 OpenCLIApp 提供「browser-login keepalive」功能，但具体机制未详述。另一个限制是多 profile 场景。如果用户有多个 Chrome profile 且未设置默认，OpenCLI 会交互式询问，这在脚本或自动化任务中会中断流程。文档建议用 `opencli profile use work` 指定，但如果你经常切换 profile，每次都需要显式传入 `--profile` 参数，例如 `opencli --profile work browser main state`。对于 CI 环境，npm 安装方式可行，但浏览器扩展无法在无头服务器上自动运行，除非额外配置。

替代方案：Playwright 与 Puppeteer 的差异

OpenCLI 的替代方案是直接的浏览器自动化库，比如 Playwright 或 Puppeteer。Playwright 和 Puppeteer 允许你编写脚本来控制浏览器，但需要自己管理登录态，通常通过保存 cookie 或使用持久化 profile。OpenCLI 的差异在于它复用了你日常使用的 Chrome 会话，无需额外维护登录信息。另一个差异是 OpenCLI 提供结构化的 DOM 快照，而不是截图，这对 AI 代理来说更节省 token 且更容易解析。但 Playwright 和 Puppeteer 更底层，允许精细控制网络请求和页面生命周期，而 OpenCLI 的适配器抽象可能隐藏这些细节。如果你的需求是快速抓取公开数据，OpenCLI 的内置命令可能足够；如果需要复杂的自定义流程，直接使用 Playwright 可能更灵活。

维护成本与许可证

OpenCLI 采用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，只要保留版权声明。仓库最近一次推送是 2026 年 8 月，版本为 v1.8.7，说明项目仍在活跃维护。维护成本主要体现在适配器上：网站结构变化会导致适配器失效，需要定期运行 `opencli doctor` 或使用 `opencli-autofix` 修复。官方适配器可以 eject 后修改，但 reset 会丢失自定义改动，所以修改前需要做好版本控制。插件机制允许你保持个人适配器独立于上游，减少冲突。总体而言，如果你只使用内置命令，维护成本较低；如果你深度定制，需要投入时间跟踪网站变化。

编辑结论

OpenCLI 适合两类人：一是希望用脚本或终端命令稳定访问 Bilibili、知乎、小红书等网站数据的个人用户，二是需要在 Claude Code、Cursor 等 AI 代理中操作真实登录态网页的开发者。不适合对浏览器自动化有严格隔离要求的企业环境，因为其依赖 Chrome 扩展和本地守护进程，且多配置文件场景需要手动指定 profile，否则会交互式询问。采用前应验证三件事：Node.js 版本是否高于 20.18.1，浏览器扩展能否正常连接，以及 `opencli doctor` 是否报告无错误。若你的场景只需要单向数据抓取且不涉及登录态，Playwright 或 Puppeteer 可能更直接；若需要 AI 代理自主决策，OpenCLI 的 DOM 快照机制比纯截图方案更节省 token。最终判断：OpenCLI 的价值在于把浏览器自动化封装成确定性 CLI，但它的成败取决于扩展与守护进程的稳定性，以及 adapters 的维护频率，建议先运行 `opencli list` 和 `opencli doctor` 确认基础链路可用再决定是否纳入工作流。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes