最近在浏览 GitHub 的开源项目时,我注意到一个有趣的现象:越来越多的开发者开始思考一个问题——为什么我们要让 AI Agent 去学会人类的交互方式(点击、拖拽、填表单),而不是直接给软件装上 CLI(命令行接口)?
OpenCLI 就是这个思路的一个具体实践。

与其说它是一个效率工具,不如说它在尝试一件更根本的事情:把过去 40 年来 GUI 做的工作反向操作一次——从让机器学会人的语言,变成让人和 AI 都说机器的语言。
项目核心定位
OpenCLI 的目标很直接:把任何有网页或 Electron 界面的应用都变成命令行工具。
这包括几类目标:
- 网站类:B 站、知乎、小红书、Twitter/X、Reddit、YouTube 等
- 桌面应用:Cursor IDE、Notion、Discord、飞书、微信、网易云音乐等
- 特殊应用:超星学习通、微信读书等垂直工具
目前已内置 80+ 个命令,覆盖 30+ 个站点和应用。
技术路线对比
在讨论 OpenCLI 之前,需要提一下同类项目 CLI-Anything

这样能更清楚地看出两者的差异:
| 维度 | CLI-Anything | OpenCLI |
|---|---|---|
| 技术思路 | 从源码出发 | 从浏览器出发 |
| 依赖条件 | 需要软件源码或 API 文档 | 只需浏览器访问权限 |
| 适用范围 | 开源桌面软件(GIMP、Blender、Audacity 等) | 网站、Electron 应用、闭源软件 |
| 实现方式 | 扫描源码,自动生成 CLI 适配器(基于 Python Click) | 通过 Chrome 扩展 + 浏览器协议直接操作界面 |
两个项目互补性很强:有源码的用 CLI-Anything 处理,无源码的则由 OpenCLI 处理。

核心技术架构
工作链路

OpenCLI 的架构相对轻量级:
CLI 命令 → 本地 Daemon → WebSocket → Chrome 扩展 → 网页/应用操作
具体流程:
- 在 Chrome 浏览器安装轻量级扩展(Browser Bridge)
- 本地启动守护进程(Daemon),监听 localhost:19825
- 用户在终端输入命令(如
opencli bilibili hot) - Daemon 通过 WebSocket 将指令发送给 Chrome 扩展
- 扩展在浏览器中执行相应操作,返回结果
- 结果格式化输出到终端
权限管理特点
OpenCLI 有一个设计要点:复用 Chrome 中已有的登录态。
- 你在 B 站登录了,Agent 就能用你的账号获取数据
- 不需要单独配置 Cookie、API Key 或密钥
- 用户密码和凭据始终不离开浏览器
- Daemon 空闲 5 分钟自动退出,不会常驻占用资源
这也隐含了一个权限边界问题:Agent 拥有的权限等于你在浏览器中的权限。你能发送的消息,Agent 也能;你能删除的内容,Agent 也能。这既是便利(即开即用),也是风险。
为 Agent 设计的三个核心命令
OpenCLI 最有意思的地方在于,它专门为 AI Agent 设计了三个自适应命令:
1. explore
作用:自动发现目标网站有哪些可调用的 API
工作方式:
- 不是静态扫描,而是真实打开浏览器
- 自动点击、滚动、观察网络请求
- 记录所有可用的 API 端点
2. synthesize
作用:自动生成 CLI 适配器
工作方式:
- 基于 explore 的结果自动生成对应命令
- 零代码输入,全自动包装成命令行工具
3. cascade
作用:自动探测目标网站的认证策略
工作方式:分级尝试,从简到复杂
- 第一级:公开 API(无认证)
- 第二级:Cookie 认证
- 第三级:网络请求签名拦截
- 更高级别的自定义认证方案
一条命令完成全流程
opencli generate https://example.com --goal "hot"
这意味着:AI Agent 即使是第一次接触某个网站,也能自动摸索出如何用命令行去操控它。
应用场景与使用示例
网站类命令示例
opencli bilibili hot -f json # B 站热门视频(JSON 格式)
opencli zhihu hot -f yaml # 知乎热榜(YAML 格式)
opencli twitter bookmarks -f md # Twitter 书签(Markdown 格式)
opencli youtube info # YouTube 视频信息
数据流转场景
举几个实际应用的例子:
- 内容聚合:从 B 站抓热门视频字幕 → AI 总结 → 发送到飞书群
- 数据分析:从雪球拉股票数据 → AI 分析 → 写入 Notion 文档
- 工作流自动化:监控 Reddit 特定话题 → 触发自定义脚本 → 更新本地数据库
输出格式支持
OpenCLI 支持多种输出格式,便于与其他工具组合:
- JSON(结构化数据处理)
- YAML(配置文件友好)
- Markdown(文档生成)
- CSV(数据分析工具友好)
Electron 应用支持的突破
OpenCLI 最近一个重要更新是对所有 Electron 应用的支持。这意味着什么?

现代桌面应用中有大量使用 Electron 构建:VS Code、Slack、Discord、Notion、飞书、微信开发者工具、Figma 等。简单说,你能叫出名字的现代应用,有一半以上跑的都是 Chromium 内核。
实现原理
- 通过 Chrome DevTools Protocol(CDP) 与应用内核通信
- 每个应用分配固定端口(Cursor 9222、ChatGPT 9224、Notion 9230)
- 通过 DOM 操作读取和注入内容
处理复杂交互的方案
对于 React 等框架的富文本编辑器,OpenCLI 采用了巧妙的做法:
不直接设置 .value 属性(这样框架内部状态不会更新),而是使用 document.execCommand('insertText') 模拟真实的文本输入,绕过框架的状态管理。
这样 Agent 可以:
- 在 Cursor 中直接写代码
- 在 Notion 中编写文档
- 在 Discord 中发送消息
- 全程通过命令行操作
安装与部署
基础需求
- Chrome 浏览器(安装 OpenCLI 扩展)
- Node.js 环境(运行本地 Daemon)
- 终端/命令行工具
快速开始步骤
- Clone 项目到本地
- 安装 Chrome 扩展
- 启动本地 Daemon 进程
- 在终端执行 CLI 命令
具体步骤可参考官方 GitHub 仓库的 README 文档。
相关对标项目
除了前面提到的 CLI-Anything,还有几个相关方向的项目值得关注:
- Browser Automation 工具:Playwright、Puppeteer(底层技术相近,但定位不同)
- API 自动生成工具:FastAPI、Pydantic(反向思路)
- Agent 框架集成:LangChain、LlamaIndex 等 Agent 框架都在探索工具调用的标准化
现状与社区反应
从 GitHub 的星数增长可以看出开发者的热情:
- CLI-Anything:已达 15000+ Stars
- OpenCLI:短短几天内涨到 2300+ Stars
这反映了一个明确的趋势:开发者社区正在重新审视软件的交互方式。
总结与思考
从产品经理的角度看,OpenCLI 的意义不只在于工具层面。
过去 40 年,计算机交互的主线是 GUI 化——把机器的复杂性隐藏在图形界面后面,让非技术用户也能使用。但这种设计有一个隐含的前提:用户是人。
现在 AI Agent 的出现改变了这个前提。对 Agent 来说,GUI 反而是最低效的交互方式。Agent 的"母语"是文本和结构化数据——也就是 CLI 的本质。
所以 OpenCLI 做的事情,是在补一个 40 年的"翻译缺口":
- 人用 GUI,AI 用 CLI
- 以前需要人手动搬运数据,现在 Agent 可以自动编排
- 以前每个软件是孤岛,现在它们都变成了可组合的"积木"
配合 CLI-Anything(处理有源码的桌面软件),整个软件世界正在被重新"插上插头"。OpenCLI 代表的不是一个工具的创新,而是一次人机交互范式的递进——从"人机对话"时代,进入"机器自主"时代。
如果你在做 Agent 应用开发,或者在思考如何让多个系统之间流畅地协作,OpenCLI 值得关注。它不会立即改变你的工作方式,但它在构建的基础设施,可能会决定未来 5 年 Agent 生态的样子。
相关链接
```