opencli-rs 实战：把 55 个网站和本地 CLI 变成 AI 可调用工具，速度比 Node 版快 12 倍

你缺的可能不是“再一个爬虫”，而是一个 AI 能直接调用的数据入口

现在很多人折腾 AI 工作流，问题根本不在 Prompt，而在“外部信息怎么接进来”。

你可能也有过这种体验：

• 想让 Claude Code 或 OpenClaw 帮你分析一个话题，但还是得自己先打开 GitHub、Hacker News、知乎、X、B 站
• 找到内容后再复制链接、复制正文、复制评论，喂给 AI
• 想把结果接进自己的命令行或自动化流程，又得额外写脚本
• 工具一多，环境依赖也跟着膨胀：Node、浏览器扩展、各种脚本、各种 cookie 处理

最后你会发现，真正拖慢你的，不是模型不会总结，而是信息入口太散，工具接口不统一。

这也是我今天觉得 opencli-rs 值得写的原因。

它不是一个“新爬虫站点合集”，而是把这件事做成了一个更适合 AI 工作流的底座：用一个 Rust 单文件 CLI，把网站、桌面应用、本地 CLI 都抽象成统一命令入口。对个人开发者、内容工作流、热点监控、投研信息流这几类场景，价值都很直接。

opencli-rs 到底是什么？先一句话讲清楚

opencli-rs 是一个用 Rust 重写的通用命令行工具，核心目标很明确：

让任何网站、部分桌面应用和本地 CLI，都能被统一成一个 AI 能发现、能调用、能编排的命令行入口。

它基于原来的 opencli 思路继续做，但换成了纯 Rust 实现。项目 README 给出的定位非常激进，也很直白：

• 完全重写自 TypeScript 版 opencli
• 功能基本对齐
• 体积更小：单个 4.7MB 二进制
• 运行时零依赖：不需要 Node.js
• 性能更快：一些真实命令测试里，最高能到 12x

如果你平时主要做的是：

• AI Agent 联网取数
• 热点抓取与监控
• 内容选题与资料整理
• 把本地工具接进统一工作流

那这个方向其实比“再多一个浏览器插件”更有意思，因为它解决的是入口标准化的问题。

它为什么比普通命令行工具更适合 AI 工作流？

我觉得可以从 4 个点看。

1）它不是只抓网站，而是想把“可调用能力”统一起来

README 里列得很清楚，opencli-rs 并不只覆盖网页数据。

它现在已经支持：

• 55 个站点，333 个命令
• 公共数据站点：Hacker News、Wikipedia、arXiv、Stack Overflow、Google News 等
• 需要浏览器登录态的站点：X、B 站、知乎、小红书、微博、雪球、YouTube 等
• 一部分桌面应用能力：Cursor、Codex、ChatGPT、Notion、Discord 等
• 外部 CLI 透传：gh、docker、kubectl、obsidian 等

这件事的意义不在“命令多”，而在于AI 不需要理解 10 套接口。

对 AI 来说，最友好的世界不是“到处都是网页和 API 文档”，而是“所有能力都长得像命令”。一旦它们都能变成：

opencli-rs <site> <command>

那你后面无论接 OpenClaw、Claude Code、还是你自己的自动化脚本，心智负担都会低很多。

2）它把安装门槛压得非常低

很多这类工具最容易死在第一步：你还没开始用，就先要配半天环境。

opencli-rs 的一个明显优势是分发方式足够干净。

官方最新 release 是 v0.1.3，直接提供了：

• macOS（Apple Silicon / Intel）
• Linux（x86_64 / ARM64）
• Windows
• 以及单独的 Chrome 扩展包

也就是说，你可以直接下载二进制就跑。不需要先装 Node 20，不需要拖一坨 node_modules，这对想在多台机器、云主机、边缘节点部署的人非常友好。

如果你只跑公共模式命令，比如：

opencli-rs hackernews top --limit 10
opencli-rs wikipedia trending
opencli-rs arxiv search "agent workflow"

甚至连浏览器扩展都不需要。

3）它对“AI 自动发现工具”这件事想得更前

这点我觉得最值得内容工作流和 Agent 玩家关注。

README 里明确写了两个很关键的设计：

• 可以把 opencli-rs list 放进 AGENT.md 或类似规则文件，让 AI 自动发现可用工具
• 可以通过 register 把本地 CLI 注册进去，让 AI 用同一套入口继续调用

这和很多“单纯给人用的 CLI”不一样。它明显是把 AI Agent 作为第一类用户 来设计的。

换句话说，你不是在装一个只给自己敲命令的工具，而是在给你的 AI 助手搭一层可发现的能力目录。

如果你现在已经在用 Claude Code、OpenClaw 或 Cursor Agent，这个思路就很顺：

• 公共信息 → 用 opencli-rs 取
• 浏览器登录态信息 → 用 opencli-rs 取
• 本地 CLI → 用 opencli-rs 统一转发
• AI 负责编排、筛选、总结和决策建议

这才是真正的“让 AI 去联网干活”，而不是你自己先跑一轮，再把结果手抄过去。

4）Rust 重写带来的，不只是快，还有更稳的交付方式

README 里给了几组很容易传播、也确实有价值的数据：

• 公共命令内存占用：15 MB vs 99 MB
• 浏览器命令内存占用：9 MB vs 95 MB
• 二进制大小：4.7 MB vs 约 50 MB node_modules
• bilibili hot：1.66s vs 20.1s
• zhihu hot：1.77s vs 20.5s
• xueqiu search 茅台：1.82s vs 9.2s

这些数字最打动我的地方，不只是“快”，而是它意味着你更容易把它放进真实工作流里。

因为一旦一个工具：

• 启动快
• 占用小
• 不依赖 Node 运行时
• 能作为单文件分发

它就更适合被放进：

• 定时任务
• 远程机器
• 本地自动化脚本
• 多节点采集系统
• Agent 的工具箱

对个人用户来说，这比 benchmark 本身更重要。

你今天就能怎么用？我更建议先从 3 类场景下手

场景 1：做热点监控和内容选题

这是这个博客最直接的场景。

你完全可以把 opencli-rs 当成一个统一取数层，先跑这些命令：

opencli-rs hackernews top --limit 10 --format json
opencli-rs bilibili hot --limit 20
opencli-rs zhihu hot --limit 20
opencli-rs twitter search "OpenClaw" --limit 10

然后把输出交给 AI 去做第二层处理：

• 哪些值得写
• 哪些只是噪音
• 哪些已经和最近 7 天文章重复
• 哪些更适合写成教程，而不是新闻摘要

这样你就不需要自己来回切站点了。

场景 2：给 OpenClaw / Claude Code 增加统一联网能力

如果你用的是 Agent 型工作流，那 opencli-rs 的价值会更明显。

因为很多时候你不缺模型，你缺的是：

• 一个可枚举的工具目录
• 一套稳定的取数入口
• 一个能兼容公共页面和登录态页面的统一接口

它在 README 里还提供了 AI discovery 能力，比如：

opencli-rs explore https://www.example.com --site mysite
opencli-rs generate https://www.example.com --goal hot
opencli-rs cascade https://api.example.com/hot

这意味着它不只是“已有站点命令大全”，还在尝试帮你探索接口、生成适配器、判断认证方式。

对于经常碰到“这个网站有没有现成接口”“能不能快速做个命令适配”的人来说，这一步很值钱。

场景 3：把你原来零散的本地命令也收进同一个入口

这是我觉得很多人会低估的点。

opencli-rs 不只抓外部世界，还能把本地世界也统一一下。比如 gh、docker、kubectl 这些原本就常用的 CLI，可以继续从这个入口透传出去。

这带来的好处是：

• 你的 AI 更容易知道“它到底能调用什么”
• 规则文件更容易维护
• 工作流更容易组合

对个人开发者来说，你最终想要的不是 20 个分散工具，而是一个可组合的命令总线。

它的工作方式，为什么比“硬写爬虫”更耐用？

README 里把能力拆成几种认证和执行策略：

• public
• cookie
• header
• intercept
• ui

再加上 YAML pipeline、浏览器桥接、外部 CLI 透传，这说明它并不是在押注某一种单点方案，而是在做一个更通用的执行层。

这种设计的好处是：

能处理公开数据，也能处理登录态数据

很多热点、资讯、论文站点走公开接口就够了；很多社媒、社区、平台型站点又必须依赖浏览器登录态。

如果你要两套系统分别维护，复杂度会越来越高。opencli-rs 的做法，是尽量把这两类世界放到一个命令系统里。

新站点不一定要手写一坨代码

它的适配器机制是 YAML pipeline。README 里直接给了样例：通过 fetch、select、map、filter、sort、limit 这些步骤描述一个站点命令。

这至少说明两件事：

• 新增站点能力的门槛被压低了
• 站点命令更容易被维护和审阅

对于经常需要小步快跑加数据源的人，这种方式明显比“每次都开新脚手架写一套逻辑”更省力。

什么时候该优先试 opencli-rs？什么时候不用急着上？

我自己的判断标准很简单。

适合优先试的情况

1. 你已经在做 AI 工作流，但联网取数还很散
2. 你需要同时覆盖公共站点和登录态站点
3. 你讨厌为了一个 CLI 再装一整套运行时
4. 你想把网站能力、本地命令、Agent 工具统一起来
5. 你在意部署体验，希望能单文件扔到机器上就跑

可以先不急的情况

1. 你现在只需要一两个固定 API
2. 你根本没有 Agent / 自动化工作流需求
3. 你只在浏览器里临时手动看，不打算沉淀成命令系统

说白了，opencli-rs 最适合的不是“偶尔查一次数据”，而是你已经意识到：

信息获取，正在成为 AI 工作流里的基础设施。

我对这个项目最看重的，不是“Rust 重写”，而是它把工具边界重新定义了

很多人看到这类项目，第一反应是：“哦，把 Node 版换成 Rust 了。”

但如果只看到这里，就把它看小了。

我更看重的是它传递出来的一种方向：

• 网站不一定只能在浏览器里看
• 桌面 App 不一定只能手点
• 本地 CLI 不一定各自为战
• AI 不一定只能吃你复制进去的文本

这些能力如果都能统一成一个稳定的命令入口，后面的自动化空间会大很多。

尤其对想做以下事情的人：

• 内容自动化
• 热点监控
• 投研信息流
• 多工具编排
• 个人 AI 助手

这类“统一入口”工具的价值，往往比某个单点模型更新更持久。

总结

如果你现在已经在用 OpenClaw、Claude Code、Cursor Agent，或者你本来就在折腾热点抓取、信息流、内容工作流，那 opencli-rs 很值得你花一小时上手。

它最大的吸引力，不只是 Rust 重写后更快、更小、更省资源，而是它把一个很关键的问题往前推了一步：

怎么把外部世界，变成 AI 可以稳定调用的工具世界。

这件事一旦跑通，AI 才不只是“会聊天”，而是真的开始替你处理信息、执行动作、串联流程。

对个人开发者来说，这比单纯追新模型，实用得多。