OpenCLI Admin 实战：可视化舆情监控（多账号采集 + AI 打标 + 飞书推送）

你需要的不是“再一个爬虫”，而是一套可视化的信息流水线

如果你做「投研 / 竞品 / 舆情 / 内容选题」，大概率都踩过同样的坑：

• 数据来源太散：微博、知乎、小红书、B 站、X……每天要开一堆 App
• 采集脚本太脆：今天能跑，明天页面一改就挂；维护成本越来越高
• 登录态很难搞：尤其是国内平台，多账号更是灾难
• 就算采到了，也还是“原始信息”——你还要花时间读、筛、打标签

我这次看到一个很对路的开源项目：OpenCLI Admin（xjh1994/opencli-admin）。

它的定位不是“再造一个 opencli”，而是把 opencli 变成一个可视化的采集中枢：

• 统一管理多渠道采集（opencli / RSS / API / Web 爬虫 / 通用 CLI）
• 可视化配置 cron 定时、任务链路、错误追踪
• 支持 多节点 / 多账号（本地 Mac + 云服务器混合）
• 采集后可接 AI 自动摘要 / 打标签
• 最后把结果推送到 飞书 / 企微 / 钉钉 / Webhook / Email

如果你之前已经在用 OpenCLI 抓热榜，这个项目刚好补上了“工程化”的最后一公里。

---

OpenCLI Admin 是什么？（一句话讲清楚）

OpenCLI = 把网站变成 CLI 命令。

OpenCLI Admin = 把这些命令，变成“可视化采集系统 + 分布式调度 + AI 处理 + 通知推送”。

它本身是一个三段式系统：

1. 前端管理台（React）：数据源、计划、任务、记录、节点、通知，全部可视化
2. 后端 API（FastAPI）：调度器 + 流水线（collect → normalize → store → ai → notify）
3. Agent 节点：真正去跑 opencli、连接 Chrome、持有登录态；节点之间可以 WS 反向通道跨网连回中心

项目 README 里给了一个很典型的家庭集群场景：

• Mac Mini A 当中心（opencli-admin）
• Mac Mini B 登录国内平台（小红书 / B 站等）
• Mac Mini C 登录海外平台（Twitter/X 等）
• 中心按“站点绑定路由”，任务自动发到对应节点执行

这比“在一台机器上塞一堆账号 Cookie”更稳，也更可控。

---

它解决的 3 个核心问题

1）把“采集”变成可配置的任务，而不是一堆脚本

OpenCLI Admin 内置了：

• 数据源管理：卡片式配置，多渠道统一入口
• 定时计划：结构化 cron，支持时区 / 一次性执行
• 采集任务：实时状态、链路追踪、错误详情
• 采集记录：全文搜索，展开看格式化 JSON + AI 分析

这意味着你可以把采集需求“产品化”——以后新增一个平台/关键词，不需要改代码，直接在页面加一个数据源就行。

2）多账号采集的正确打开方式：把登录态留在本地，把计算搬到云端

很多人把“抓取”做崩溃，根源是把登录态、脚本、定时、推送都塞进同一台机器。

OpenCLI Admin 的推荐思路是：

• 本地机器负责登录态（Chrome Profile 持久化，Cookie 不出内网）
• 云端负责公开数据的高并发抓取（HN / RSS / BBC 等）
• 通过 WS 反向通道解决跨网连通（NAT 也能用）

对安全敏感一点的同学，这个架构非常加分。

3）把 AI 放到流水线里：采完自动摘要、打标签，再推送

它支持采集后自动触发 AI 处理（README 里列了 Claude / OpenAI / DeepSeek / Kimi / GLM / MiniMax / Ollama）。

这很符合我一直强调的一句话：

opencli 负责把数据从网上搬下来，AI 负责把数据变成决策。

如果你每天都要看几十条热榜、几百条帖子，真正节省时间的不是“抓到数据”，而是“抓到后自动把它加工成你能读的东西”。

---

一套你可以直接照抄的落地工作流（热点监控主线）

下面这套配置，我建议你用来做「热点监控 / 舆情 / 竞品跟踪」：

1. 数据源（opencli）
   • 知乎热榜 / 微博热搜 / 小红书搜索（关键词）/ B 站热榜
   • X 搜索（关键词）
2. 数据源（RSS / Public）
   • HackerNews Top
   • Reuters / Bloomberg / arXiv（看你的领域）
3. 定时计划
   • 每 1 小时跑一次（高频）
   • 早晚各跑一次（低频）
4. AI 智能体
   • 输出字段建议固定：摘要、标签、是否值得深挖、下一步行动建议
5. 通知推送
   • 飞书：单条推送（适合日常）
   • 企微：汇总推送（适合团队）

这样你每天打开飞书，就能看到已经被“加工过”的信息流。

---

快速上手：你先选 Docker 还是本地 Shell？

这个项目的部署方式很明确：

方式 A：Docker Compose（最省事）

README 给的最简启动是：

docker compose up -d

它会启动中心 + agent-1。然后你可以在管理台里动态加 agent-2、agent-3（每个 Agent 独立 Chrome Profile）。

如果你不想在宿主机跑 Chrome，还有一个带 Chromium 的 Agent 镜像变体（体积更大，但更“傻瓜”）。

方式 B：本地 Shell（适合个人开发/轻量使用）

复用本机 opencli 和 Chrome：

cp .env.example .env
./start.sh

并且支持：

./start.sh --no-chrome
./start.sh --no-frontend
./start.sh --cdp-port 9223

---

关键特点 / 对比分析：为什么它比“自己写几个脚本”更值得做

第一，它不是只解决“能不能抓”，而是解决“能不能长期稳定跑”。

第二，它把节点管理做成了产品能力。你可以按平台绑定节点，把某个平台的登录态固定在某台机器上，这比人工记一堆浏览器配置靠谱得多。

第三，它把 AI 处理接到了采集之后，而不是让你导出 JSON 再手工喂给模型。对真正做信息工作流的人来说，这一步是效率差距最大的地方。

第四，它给了 Docker 和 Shell 两套路径：你可以先在本机试，再迁到多机部署，不需要推翻重来。

如果拿它和纯 opencli 对比：

• opencli 更像“命令层”
• opencli-admin 更像“系统层”

前者适合单次调用，后者适合每天都跑、多人可用、可视化维护的场景。

---

总结

如果你只是偶尔查一次热榜，OpenCLI 已经够用了。

但如果你已经进入下面这些阶段：

• 想长期监控多个平台
• 想把采集任务稳定跑起来
• 想让多台机器、多账号分工协作
• 想让 AI 自动做摘要、打标签、推送

那你需要的就不是“再写一个脚本”，而是一套真正能落地的信息流水线。

OpenCLI Admin 值得看的地方，不在它多了一个界面，而在它把 opencli 升级成了一套可以持续运转的采集系统。

---

3 个标题候选

1. OpenCLI Admin 实战：可视化舆情监控（多账号采集 + AI 打标 + 飞书推送）
2. 还在手写爬虫和定时脚本？OpenCLI Admin 把热点监控做成了可视化系统
3. 想做一套长期可跑的信息流？试试 OpenCLI Admin：采集、AI 摘要、推送一条龙

我最终选第 1 个：工具名明确、场景明确、收益明确，更像会被点开的公众号标题。

资料来源

• OpenCLI Admin：xjh1994/opencli-admin
• OpenCLI：jackwener/opencli
• OpenCLI WebUI：xjh1994/opencli-webui

（本文基于上述仓库 README / Release 信息整理；未对项目做实际部署测试，建议你在本地用 Docker Compose 先跑一遍再上生产。）