OpenCLI：将任意网站变成命令行工具

图1：OpenCLI 项目封面图

你或许有过这样的经历：深夜赶工时，需要从某个网页抓取一批数据，AI 助手却只能对着 HTML 源码干瞪眼——它根本看不懂那个页面的结构。这类痛点，正是 OpenCLI 试图解决的问题。

起源：从 Browser Use 痛点说起

OpenCLI 的作者 jackwener 在 2024 年初发现，随着 AI 编程工具（Claude Code、Cursor 等）的爆发，AI 代理操控浏览器成了刚需。但当时的方案要么需要昂贵的云服务，要么需要复杂的配置。jackwener 决定做一个更务实的工具：让用户自己的 Chrome 浏览器直接变成 AI Agent 的操控终端。

这个思路迅速获得了社区认可。2024 年中，OpenCLI 在 GitHub 上突破 10,000 Star，并在同年被评为「最值得关注的 AI Agent 工具」之一。2025 年底，OpenCLI 推出了 Adapter 框架，允许开发者为任意网站编写适配器，将网站的操作封装成稳定的 CLI 命令，AI Agent 无需理解页面 DOM，直接调用命令即可完成任务。截至 2026 年 5 月，项目已积累超过 22,000 Star，fork 数超过 2,200，成为浏览器自动化领域的标杆项目。

核心能力：三条腿走路

OpenCLI 提供了三种不同的自动化模式，每种对应不同的使用场景：

第一种：内置适配器。 项目内置了大量热门网站（B站、知乎、小红书、Reddit、HackerNews、Twitter/X 等）的适配器，用户安装后即可通过命令行直接操作这些平台。例如 opencli bilibili hot --limit 5 即可获取 B 站热门榜前 5 条内容，无需打开浏览器。这种模式的优势是稳定可靠——适配器经过手工调优，字段映射精确，不会因为页面改版而失效。

第二种：AI Agent 浏览器操控。 这是 OpenCLI 最核心的创新。用户安装 Chrome 扩展「Browser Bridge」后，OpenCLI 的本地守护进程会与扩展建立 WebSocket 连接，让 AI Agent 通过 opencli browser 原语（navigate、click、type、extract、screenshot 等）直接操控用户已登录的 Chrome 浏览器。整个过程中，AI Agent 可以使用用户本人的登录态，无需再处理 Cookie 或 OAuth 问题。对于需要登录才能操作的场景（如 Gmail、企业内部系统），这个能力尤为关键。

第三种：自定义适配器开发。 OpenCLI 提供了 opencli-adapter-author skill，引导开发者从页面分析、字段解码、代码编写到自动化验证的完整流程。开发者只需 opencli browser init <site>/<command> 即可在本地 ~/.opencli/clis/ 目录下快速起草一个私有适配器，测试通过后可发布为独立插件。

除了网站自动化，OpenCLI 还扮演「CLI 集线器」的角色——它可以将本地的 gh、docker、tg、discord 等命令行工具注册到同一个发现界面，用户通过 opencli list 统一浏览所有可用命令，显著降低了在多个 CLI 之间切换的心智负担。此外，它还支持 Electron 桌面应用的适配（Cursor、Codex、ChatGPT 等），让这些图形化工具也能被 AI Agent 调用。

技术架构：轻量守护进程 + Chrome 扩展

从架构上看，OpenCLI 的设计非常务实：

本地守护进程（Daemon）： 由 Node.js 编写，通过 WebSocket 与 Chrome 扩展通信。当 AI Agent 发送 opencli browser 命令时，守护进程接收指令，通过 Chrome DevTools Protocol（CDP）操控浏览器，并将结果返回给调用方。守护进程按需启动，无需用户手动管理生命周期。

Browser Bridge 扩展： 安装在用户 Chrome 中的轻量扩展，负责在 OpenCLI 守护进程和用户浏览器之间建立双向通信通道。它无需申请任何敏感权限，仅在用户手动触发时激活，充分保障了隐私安全。OpenCLI 官方提供了 Chrome Web Store 安装渠道，也支持手动加载扩展程序。

适配器层： 每个网站适配器是一个独立的 TypeScript 模块，定义了该网站的操作端点、参数解析和结果映射。项目内置的 60+ 适配器覆盖了中美主流平台。用户也可以通过 opencli plugin install github:user/repo 安装第三方插件，或者用 opencli plugin create 开发自己的私有适配器。

执行管道（Pipeline）： 借鉴了 MCP（Model Context Protocol）的设计思想，OpenCLI 的 Pipeline 模块将复杂操作拆解为可组合的步骤（Step），支持模板变量、条件分支和结果转换。这使得适配器的逻辑既可以简单到一行配置，也可以复杂到包含多步交互逻辑。

代码质量方面，OpenCLI 使用 TypeScript 编写全量代码，通过 Vitest 实现了完整的单元测试、端到端测试和适配器测试套件。项目采用 VitePress 构建文档站，有详尽的开发者指南、适配器规范和设计文档，整体维护水准在同类开源项目中属于顶尖水平。

上手体验：门槛低，但有前提

对于普通用户，OpenCLI 的上手路径非常清晰：安装 Node.js >= 20，安装 OpenCLI npm 包，安装 Chrome 扩展，运行 opencli doctor 验证环境，完毕。全程不超过 10 分钟。内置的 Bilibili、知乎、HackerNews 等适配器开箱即用，无需任何配置。

对于 AI Agent 使用场景，门槛稍高一些——需要 Agent 支持安装 skills（如 Claude Code、Cursor 等主流工具均支持），然后通过 npx skills add jackwener/opencli 安装相应 skill。安装后，Agent 即可在对话中调用 opencli browser 系列原语，操控用户的浏览器执行复杂任务。

有一点需要特别注意的是：OpenCLI 的浏览器自动化能力依赖于用户本地的 Chrome 环境，这意味着它天然不支持纯服务器端（headless）部署。Docker 容器中没有图形界面，Browser Bridge 扩展无法加载，因此不适合作为云端自动化服务来使用。对于需要服务器端运行的项目，建议搭配 puppeteer 或 playwright 的 Docker 镜像方案。

局限与争议

OpenCLI 最大的局限在于对浏览器环境的强依赖——它不是为无头（headless）浏览器设计的，这在某些自动化场景下是硬伤。此外，适配器的维护是一个持续投入的工作，网站改版可能导致适配器失效，需要开发者及时更新。好在 OpenCLI 的 opencli browser verify 命令提供了自动化验证能力，可以快速检测适配器是否仍然正常工作。

另一个潜在争议点是隐私——Browser Bridge 扩展能够读取浏览器中的操作，这要求用户对 OpenCLI 保持充分信任。项目在 PRIVACY.md 中明确声明了数据处理原则，扩展本身也不申请过多的浏览器权限，但如果是处理高度敏感的操作，建议用户评估后使用。

行业意义与未来

OpenCLI 的出现，折射出一个更宏观的趋势：AI Agent 正在从「纯文本交互」向「真实世界操作」跃迁。在 Claude Code、Cursor 等工具已经证明 AI 可以写代码之后，OpenCLI 进一步证明 AI 也可以操控浏览器、执行真实的业务操作。这种「Terminal-first」的 Agent 工具链思路，与 Anthropic 的 MCP 协议形成了互补——MCP 定义了工具的通信标准，而 OpenCLI 则提供了实际可用的浏览器自动化实现。

从增长曲线看，OpenCLI 从 2024 年到 2026 年 Star 翻了超过两倍，适配器数量从最初的个位数扩展到了 60+ 个，背后有活跃的社区贡献者生态。2026 年 4 月，作者在 YouTube 上发布了一段深度演示视频，系统性地展示了 Browser Use 能力，引发了新一轮的关注热潮。可以预见，随着 AI Agent 场景的持续爆发，OpenCLI 这类「让 AI 操控真实浏览器」的工具将变得越来越重要。

图2：项目作者 jackwener 的 GitHub 头像

图3：OpenCLI Chrome 扩展图标