OpenCLI：把网站、桌面应用和本地工具统一成命令行入口

OpenCLI 的目标很直接：把原本只能在网页、桌面应用或不同命令行工具里完成的操作，统一收敛到一个命令行入口。

CLI（Command Line Interface，命令行界面）本身并不新鲜，很多开发工具都有自己的命令行版本，比如 GitHub 有 gh，Docker 有 docker，Kubernetes 有 kubectl。麻烦在于，网站和桌面应用通常没有这样统一的入口。想查热榜、搜索内容、操作已经登录的网站账号，往往要打开浏览器；想让 AI Agent（人工智能代理）调用这些能力，还得自己写接口、写爬虫或封装脚本。

OpenCLI 解决的是这一层割裂：终端只调用 opencli，后面由它负责连接网站、浏览器、Electron 应用和本地 CLI 工具。

项目地址：

https://github.com/jackwener/opencli

OpenCLI 适合解决什么问题

典型场景可以分成四类：

API（Application Programming Interface，应用程序编程接口）当然更稳定，但不是每个网站都提供公开 API，也不是每个功能都能通过官方接口访问。OpenCLI 的价值在于把这些分散的操作包装成统一命令，让自动化脚本和 AI Agent 可以直接调用。

整体结构：一个命令入口，连接多类工具

OpenCLI 不是某个网站的专用客户端，而是一个通用框架。它把不同平台做成适配器，再通过统一命令暴露出来。

flowchart LR
    U[开发者 / 脚本 / AI Agent] --> T[终端 opencli]
    T --> C[OpenCLI Core]

    C --> R[命令与适配器注册表]
    R --> W[网站适配器]
    R --> E[Electron 应用适配器]
    R --> L[本地 CLI 适配器]
    R --> P[插件]

    W --> B[Browser Bridge]
    B --> CH[Chrome 已登录会话]

    E --> EA[Cursor / ChatGPT / Notion / Discord 等]
    L --> LC[gh / docker / kubectl / 自定义 CLI]

这个结构里有几个关键角色：

也就是说，opencli bilibili hot、opencli zhihu hot、opencli docker ps 看起来都是一类命令，但背后可能走的是完全不同的执行路径。

核心机制：复用 Chrome 登录态

OpenCLI 最重要的设计是复用 Chrome 的登录状态。

很多网站功能必须登录才能访问，比如关注动态、收藏内容、推荐列表、个人工作台。如果按照传统方式做命令行工具，通常要解决认证问题：

• 申请 API Key（接口访问密钥）
• 走 OAuth（开放授权）流程
• 保存 Token（访问令牌）
• 处理过期刷新
• 维护账号权限

这些步骤不仅麻烦，还会引入凭证保存和泄露风险。

OpenCLI 的做法是通过 Browser Bridge 连接 Chrome，让命令在浏览器已经登录的上下文里执行。账号凭证仍然留在浏览器中，OpenCLI 不需要把账号密码或 Token 写进自己的配置文件。

sequenceDiagram
    participant User as 用户终端
    participant CLI as OpenCLI
    participant Bridge as Browser Bridge
    participant Chrome as Chrome 浏览器
    participant Site as 目标网站

    User->>CLI: opencli zhihu hot -f json
    CLI->>Bridge: 请求执行知乎适配器
    Bridge->>Chrome: 在已登录上下文中发起操作
    Chrome->>Site: 使用浏览器现有会话访问
    Site-->>Chrome: 返回页面或接口结果
    Chrome-->>Bridge: 交回可解析数据
    Bridge-->>CLI: 返回结构化结果
    CLI-->>User: 输出 JSON / 表格 / CSV 等格式

这个设计带来的直接效果是：只要 Chrome 里已经登录过目标网站，命令行就可以在相同账号上下文里工作。对需要登录才能访问的数据来说，这比重新申请平台接口权限省很多步骤。

不过这也意味着 Browser Bridge 是安全边界里的关键组件。安装扩展时要确认来源可信，尽量只安装来自项目官方渠道的版本，并定期检查扩展权限。

支持的网站、桌面应用和本地 CLI

OpenCLI 的定位是“通用 CLI 枢纽”，支持范围不局限于网站。按照能力划分，可以分成三层。

Electron 是一种用 Web 技术构建桌面应用的框架，很多现代桌面软件都基于它开发。OpenCLI 支持把这类应用 CLI 化后，终端命令就能触发桌面应用里的能力。

例如 AI Agent 可以调用：

opencli cursor send "帮我解释当前文件里的函数"
opencli chatgpt ask "把这段日志里的错误原因整理成列表"

这类能力的意义不只是“少点几下鼠标”。更重要的是，它把桌面应用变成了可编排的工具。脚本、自动化流程、AI Agent 都可以把这些应用纳入自己的执行链路。

面向 AI Agent 的命令

OpenCLI 专门给 AI Agent 准备了一组命令，用来发现网站能力、生成适配器和判断认证方式。

这些命令让 Agent 不再只能调用已经写死的 API。对于一个新网站，Agent 可以先探索接口，再尝试生成适配器，最后把新能力注册进 OpenCLI。

工作流大致如下：

flowchart TD
    A[AI Agent 接到任务] --> B[调用 opencli explore 探索目标站点]
    B --> C[分析可用接口和页面行为]
    C --> D[调用 opencli synthesize 生成适配器]
    D --> E[注册新命令]
    E --> F[Agent 调用新命令完成任务]

把 OpenCLI 写进 Agent 的工具说明后，Agent 就能先执行 opencli list 查看当前可用命令，再根据任务选择合适的工具调用。对 Agent 开发来说，这相当于把网站、应用和本地工具放进同一个工具箱。

统一调用本地 CLI

OpenCLI 也可以管理已有的命令行工具。例如 GitHub CLI、Docker、Kubernetes 都可以通过 opencli 调用：

# GitHub：查看最近 5 个 Pull Request
opencli gh pr list --limit 5

# Docker：查看运行中的容器
opencli docker ps

# Kubernetes：查看 Pod
opencli kubectl get pods

如果系统里缺少某个工具，OpenCLI 可以尝试自动安装。对于需要在多台机器上配置开发环境的人来说，这能减少“脚本依赖某个命令但机器没装”的问题。

自定义 CLI 也可以注册：

opencli register mycli

注册后，自己的工具就能和内置平台一样被统一发现和调用。

安装与基础使用

OpenCLI 通过 npm 安装。npm 是 Node.js 生态常用的包管理器，安装前需要本机已经有 Node.js 环境。

npm install -g @jackwener/opencli

安装完成后，先查看可用命令：

opencli list

如果要使用需要登录状态的网站，还需要配置 Browser Bridge 扩展。这个扩展负责让 OpenCLI 和 Chrome 建立连接，从而使用浏览器里的登录会话。

常见命令示例：

# Hacker News 热帖，公开数据，不依赖浏览器登录
opencli hackernews top --limit 5

# B 站热榜，需要 Chrome 中已登录相关账号时才能访问登录态能力
opencli bilibili hot --limit 5

# 知乎热搜，以 JSON 格式输出
opencli zhihu hot -f json

# Twitter 趋势
opencli twitter trending

# 搜索小红书内容
opencli xiaohongshu search "AI 开源项目"

输出格式支持多种类型：

例如把结果交给 jq 处理：

opencli zhihu hot -f json | jq '.[] | {title, url}'

遇到连接问题，可以先运行诊断命令：

opencli doctor

它会检查扩展、daemon 和浏览器连接状态。daemon 指后台常驻进程，负责在命令行和浏览器扩展之间维持通信。

插件与扩展方式

OpenCLI 通过适配器和插件扩展平台能力。适配器负责描述某个平台有哪些命令、如何执行、如何解析结果；插件则可以把一组适配器或聚合能力打包发布。

适配器可以理解成一层翻译：

flowchart LR
    A[opencli 命令] --> B[适配器]
    B --> C{目标类型}
    C --> D[网页 / 浏览器会话]
    C --> E[Electron 应用]
    C --> F[本地 CLI]
    D --> G[结构化输出]
    E --> G
    F --> G

例如“多平台热榜聚合”这类插件，可以同时调用多个平台适配器，把结果合并成统一格式输出。这样上层脚本不需要关心每个平台的接口差异，只处理 OpenCLI 返回的结构化数据。

适合和不适合的使用场景

OpenCLI 很适合个人自动化、信息聚合、AI Agent 工具调用，但不应该被当成所有场景下的官方 API 替代品。

判断是否该用 OpenCLI，可以看三个问题：

1. 这个操作是否本来就经常在浏览器或桌面应用里手动完成？
2. 这个操作是否需要被脚本或 AI Agent 调用？
3. 即使适配器暂时失效，是否不会影响关键业务？

三个答案都偏向“是”，OpenCLI 通常比较合适。反过来，如果这是稳定性要求很高的后端链路，官方 API 仍然是优先选择。

使用时需要注意的坑

1. 登录态依赖 Chrome 和 Browser Bridge

复用 Chrome 登录态的前提是浏览器里已经登录对应网站，并且 Browser Bridge 能正常通信。如果换了浏览器配置、清理了 Cookie、禁用了扩展，命令可能会失效。

排查顺序可以按这个来：

# 检查 OpenCLI、扩展、daemon、浏览器连接
opencli doctor

# 查看当前有哪些命令可用
opencli list

2. 网站变化会影响适配器

很多网站没有承诺内部接口稳定，页面结构、接口字段、鉴权策略都有可能调整。适配器一旦依赖这些细节，就可能因为网站改版而失效。

因此，OpenCLI 更适合做个人工作流、辅助工具和 Agent 能力扩展，不适合承载强稳定性要求的业务主链路。

3. 插件和扩展要审查来源

OpenCLI 的插件能力让扩展变得方便，也意味着插件会进入执行链路。安装第三方插件前，需要确认它做了哪些事、是否会访问浏览器会话、是否会执行本地命令。

尤其是能调用 docker、kubectl、自定义 CLI 的环境，插件权限边界要格外注意。

4. 不要绕过平台规则

命令行调用不代表可以无限制访问平台数据。很多网站有频率限制、反爬机制和使用条款。OpenCLI 可以减少手动操作，但不应该用来规避平台规则或进行高频抓取。

一个完整使用链路示例

假设目标是让 AI Agent 获取几个平台的热点内容，再整理成 Markdown 摘要。OpenCLI 可以作为中间工具层：

sequenceDiagram
    participant Agent as AI Agent
    participant CLI as OpenCLI
    participant Web as 网站适配器
    participant Browser as Chrome 登录会话

    Agent->>CLI: opencli list
    CLI-->>Agent: 返回可用命令
    Agent->>CLI: opencli zhihu hot -f json
    CLI->>Web: 调用知乎适配器
    Web->>Browser: 通过 Browser Bridge 访问
    Browser-->>Web: 返回结果
    Web-->>CLI: 结构化数据
    CLI-->>Agent: JSON 输出
    Agent->>Agent: 生成 Markdown 摘要

对应的命令可以这样组织：

opencli zhihu hot -f json > zhihu.json
opencli hackernews top --limit 10 -f json > hackernews.json
opencli xiaohongshu search "AI 开源项目" -f json > xhs.json

然后把这些 JSON 文件交给 Agent 处理，Agent 不需要知道每个平台怎么登录、怎么访问、怎么解析页面，只需要处理 OpenCLI 输出的数据结构。

小结

OpenCLI 的核心价值不是“又多了一个命令行工具”，而是把网站、Electron 应用和本地 CLI 放进同一套调用模型里。它通过 Browser Bridge 复用 Chrome 登录态，降低了认证成本；通过适配器和插件扩展平台能力；通过 AI 专属命令，让 Agent 可以探索、生成和调用更多工具。

如果日常工作里经常需要从网站取数据、批量操作桌面应用，或者正在给 AI Agent 设计工具调用层，OpenCLI 可以作为统一入口来评估。对于稳定性要求高、调用频率大、合规边界严格的场景，官方 API 和专门服务仍然更合适。