让 AI Agent 从“点网页”变成“调命令”

最近看到一个很有意思的开源项目：OpenCLI。

它的想法很直接：把网站、浏览器会话、桌面应用和本地工具，包装成统一的命令行接口，让 AI Agent 可以像调用工具一样调用它们。

这听起来有点抽象。换句话说，OpenCLI 想解决的是一个越来越常见的问题：

AI Agent 想帮我们做事，但它的“手”很笨。

它可以打开浏览器，可以点击按钮，可以读取网页内容，但这些操作经常不稳定。网页结构一变，按钮位置一变，弹窗、验证码、登录态一出现，流程就可能失败。

OpenCLI 提供了另一种思路：不要让 Agent 每次都像人一样操作网页，而是把常用操作封装成命令。

比如：

opencli bilibili hot --limit 5opencli reddit search "OpenCLI"opencli hackernews topopencli xiaohongshu search "AI Agent"

Agent 执行命令，拿到结构化结果，再负责分析、筛选和总结。

这就像把 Agent 的操作方式，从“看屏幕、点按钮”，变成“调用命令、处理结果”。

OpenCLI 是什么

OpenCLI 是一个开源项目，官方描述是：

把网站、浏览器会话、Electron 应用和本地工具，统一变成适合人类与 AI Agent 使用的确定性接口。

简单说，它想做一层统一接口，让 Agent 可以通过命令行操作各种外部工具。

它覆盖的对象包括：

• 网站：例如 B站、知乎、小红书、Twitter/X、Reddit、HackerNews；
• 浏览器：通过 Chrome / Chromium 的登录态操作网页；
• Electron 应用：例如 Cursor、ChatGPT App、Notion、Discord；
• 本地工具：例如 gh、docker、obsidian 等 CLI 工具。

OpenCLI 并不是把所有应用真的改造成命令行程序，而是给它们包了一层命令行适配器。

有了这层适配器，Agent 不需要每次都重新观察网页、判断按钮、模拟点击，而是可以直接调用命令。

传统 Agent 是怎么工作的

假设你问 Agent：

帮我搜索最近关于 OpenCLI 的讨论，并总结一下。

传统流程大概是这样：

1. 打开浏览器；
2. 进入搜索引擎；
3. 输入关键词；
4. 查看搜索结果；
5. 点击多个网页；
6. 提取内容；
7. 回到对话中整理回答。

这很像一个人类实习生在电脑前操作。

这种方式的好处是通用。只要人能点，Agent 理论上也能点。

但问题也很明显：

• 页面复杂，容易误判；
• 弹窗、验证码、登录状态会打断流程；
• 网页结构变化后，原来的操作路径可能失效；
• 每一步都需要模型理解当前页面，消耗大量 Token；
• 速度慢，成功率也不稳定。

如果改用搜索 API 或 MCP，流程会更结构化，但也会带来新的问题：需要配置 API Key，可能产生费用，覆盖范围有限，也不一定能访问登录后的内容。

OpenCLI 想走第三条路。

OpenCLI 的工作方式

OpenCLI 的思路是：把常见的网站和应用操作封装成命令。

例如搜索、抓取热门内容、读取通知、下载文章、获取评论、操作桌面应用等，都可以变成类似这样的命令：

opencli reddit search "OpenCLI"opencli bilibili hot --limit 5opencli hackernews topopencli chatgpt-app ask "总结这段话"opencli notion search "项目计划"

Agent 不再需要像人一样一步步点网页，而是：

1. 判断任务需要什么信息；
2. 找到合适的 OpenCLI 命令；
3. 执行命令；
4. 获取结构化结果；
5. 基于结果进行总结和分析。

这时 Agent 的角色会发生变化。

以前它像是在操作电脑的人；现在更像是在调用工具的程序员。

为什么命令行对 Agent 友好

命令行看起来古老，但对 AI Agent 很友好。

原因很简单：命令行接口通常更清晰、更稳定、更容易组合。

比如一个网页按钮，Agent 需要判断它在哪里、能不能点、点完会发生什么。

但一个命令通常只需要知道：

• 命令叫什么；
• 参数是什么；
• 返回什么格式；
• 出错时如何处理。

这比理解一个复杂网页简单得多。

OpenCLI 也支持逐层发现命令。例如：

opencli listopencli bilibiliopencli bilibili hot --help

Agent 可以先查看有哪些能力，再按需查看具体参数。

这比一次性塞给 Agent 一大段 Skill 文档更节省上下文，也更适合工具调用。

和 Obsidian 的类比

这个思路可以用 Obsidian 来理解。

如果 Agent 想操作 Obsidian，传统方式可能是：

• 模拟点击 Obsidian 界面；
• 直接读写 Markdown 文件；
• 调用插件接口；
• 操作窗口或快捷键。

但如果有一套命令行工具：

obsidian-cli create-note "今日总结.md"obsidian-cli search "OpenCLI"obsidian-cli append "项目笔记""新增内容"

Agent 操作 Obsidian 就会简单很多。

OpenCLI 对网站和桌面应用做的是类似的事。

它不是让所有 App 真的互通，而是在中间加了一层命令行接口。Agent 通过这层接口，就可以更稳定地调用外部能力。

OpenCLI 与 Skill、MCP、API 的区别

可以粗略这样理解：

OpenCLI 并不是要完全替代 Skill 或 MCP。

它更像是提供了一种新的工具组织方式：把很多具体动作沉淀成可执行命令，让 Agent 在运行时调用。

对于“思考类任务”，Skill 仍然有价值；对于“执行类任务”，CLI 可能更简洁。

比如写作框架、研究方法、分析流程，适合放在 Skill 里；搜索、抓取、下载、查询、发送消息，这些动作更适合封装成 CLI。

它的价值在哪里

OpenCLI 最有价值的地方，不只是支持了多少网站，而是它提出了一种 Agent 操作外部世界的方式。

过去 Agent 的“手”主要有几种：

• 浏览器；
• API；
• MCP；
• Skill；
• 插件。

OpenCLI 给出的是另一条路径：

用命令行作为统一操作入口。

这有几个明显好处：

• 降低浏览器自动化的不稳定性；
• 减少模型在网页理解上的 Token 消耗；
• 输出结果更结构化；
• 更方便反复运行和脚本化；
• 更接近传统程序员工具链。

如果某个操作每天都要做，比如抓取热门内容、整理搜索结果、读取通知、同步资料，那么把它变成命令，比每次都让 Agent 打开网页重新操作更合理。

但它不是魔法

OpenCLI 的方向很有吸引力，但不能把它理解成“让一切障碍消失”。

现实中的问题仍然存在：

• 网站会反爬；
• 登录态可能失效；
• 验证码仍然会出现；
• 页面改版可能导致适配器失效；
• 某些操作有权限和安全风险；
• 安装环境和浏览器扩展也有门槛。

更准确的说法是：

OpenCLI 不是消灭所有障碍，而是通过命令行适配器，降低 Agent 操作网站和应用的难度。

它把一部分原本不稳定的图形界面操作，转化成更稳定的命令调用。

这已经很有价值。

结语

OpenCLI 的核心理念可以概括为一句话：

让 AI Agent 少做浏览器点击，多做命令调用。

它把网站、浏览器、桌面应用和本地工具包装成统一的 CLI，让 Agent 可以更稳定地调用外部能力。

从这个角度看，OpenCLI 不是一个单纯的网页自动化工具，而是一个 Agent 工具层。

未来的 Agent 如果要真正处理复杂工作流，光会聊天是不够的。它需要稳定地调用工具、读取数据、操作应用、处理结果。

命令行可能不是最炫的界面，但对 Agent 来说，它可能是最合适的接口之一。