OpenCLI 使用指南

OpenCLI 容易被理解成“让 AI 点网页”。这个说法没错，但太窄。

更准确地说，OpenCLI 适合把一段网页流程变成命令：打开页面、复用登录态、点击、翻页、下载、提交、拿回结果。以后 Codex、Claude Code、Slock、Multica 或你自己的 Agent 都可以调用这条命令，而不是每次重新临时操作。

临时查一次资料，用浏览器自动化就够了。OpenCLI 更适合那些每周都会做、步骤基本固定、结果格式也比较明确的网页流程。

本文基于 2026 年 4 月到 5 月社区里的真实使用经验整理。OpenCLI 迭代很快，具体命令和适配器会变，这里主要写更稳定的使用方法和风险边界。

先判断是不是重复网页流程

判断一个任务要不要用 OpenCLI，先问三件事：

1. 这个网站有没有稳定 API 或成熟 CLI？有的话，优先用 API 或现成 CLI。
2. 这个任务是不是依赖网页登录态、菜单、表单、分页、上传下载或网页 AI？
3. 这个流程以后会不会反复做？

如果答案是“只做一次”，不要急着写 adapter。让 Agent 临时打开网页、读完、总结即可。

如果答案是“每周都做”，比如导出后台报表、整理收藏、查询企业信息、把论坛帖子保存进知识库，就值得把流程沉淀下来。

从低风险流程开始

不要一开始就让它运营小红书、批量发帖、管理 X 账号，也不要直接碰付款和删除。先选一个失败也没损失的公开网页流程。

比较稳的顺序是：

1. 准备 skill 和浏览器环境。 安装 OpenCLI skill 和浏览器插件，确认浏览器、profile、命令路径都可用。
2. 读一个公开页面。 让 Agent 打开公开帖子或文章，提取正文和链接，保存成 Markdown。
3. 做一个轻动作。 比如搜索一个关键词，打开结果，抽取标题和链接。
4. 换一个页面再跑。 看输出格式和错误处理是否稳定。

一个合适的新手任务：

打开这个公开帖子，提取正文和所有链接，保存到 notes/opencli-test.md，然后总结 5 条要点。

一个不合适的新手任务：

登录我的主账号，批量回复所有私信，顺手把能点的都点了。

前者是在验证能力，后者是在制造账号风险。

User case 比炫技更重要

OpenCLI 最该养成的习惯，是把跑通过的流程写成 user case。

一个好的 user case 至少写清楚：

• 入口：哪个网站，是否需要登录，是否依赖某个账号区域。
• 输入：关键词、URL、时间范围、账号名、导出格式。
• 动作：搜索、翻页、点击、复制、下载、上传、生成或提交。
• 输出：Markdown、JSON、CSV、图片、文件路径，还是交给另一个 Agent。
• 边界：哪些按钮不能点，哪些写操作必须等人确认。
• 复用方式：命令名、参数示例和失败时怎么排查。

不要只说“帮我操作这个网站”。更好的说法是：

帮我跑通这个流程，并整理成以后可以复用的 OpenCLI user case。输入、输出、权限边界和失败处理都写清楚。

社区里讨论过企查查、爱企查、CNKI、TradingView、广告后台、电商后台、大众点评、Instagram、Facebook、Indeed、Glassdoor 等需求。它们看起来分散，本质上都是同一类问题：业务流程在网页里，但 API 不顺手。

几类值得沉淀的流程

OpenCLI 最值得沉淀的，通常是这几类流程。

第一类是内容和知识库采集。比如保存微信公众号文章、提取论坛正文、整理资讯网站、导出 X 收藏、把网页链接批量导入自己的知识系统。重点不是“抓网页”，而是把结果带回本地知识库或 Agent 项目。

第二类是有登录态的业务后台。企业信息查询、电商后台、广告投放平台、内部 CRUD 系统、低代码表单，都可能先通过网页登录态跑起来。等流程稳定后，再决定要不要接正式 API。

第三类是网页 AI 产品调用。Grok、千问、豆包、Gemini、ChatGPT 这类网页产品，页面会话和登录态很重要。如果每次都像新访客一样打开，体验会差很多。按站点复用页面后，它更像一个持续在线的工具。

还有一些边缘但真实的场景，比如下载网盘照片、读取 Telegram 内容做比价、处理网页问卷。能力很广，但越接近账号资产、平台规则和真实提交，越要保守。

稳定性的关键不是 prompt

长期用下来，影响 OpenCLI 稳定性的往往不是 prompt，而是浏览器环境。

你要知道它用哪个浏览器、哪个 profile、哪个账号、插件是否连接、页面是否复用、任务结束后 tab 是否关闭、同一个站点下次打开时是新页面还是旧页面。

OpenCLI 支持按站点复用会话，形态大致像这样：

browserSession?: {
  reuse?: 'none' | 'site'
}

这对网页 AI 产品尤其重要。Grok、千问、豆包、Gemini 这类网站，如果每次都重新开页面，就会丢上下文、变慢，也更容易触发登录检查。

multi profile 也重要。多账号、多浏览器、指纹浏览器，本质上都绕不开 profile 管理。Chrome 系、能装插件的浏览器通常更容易接入；WSL、VPS、远程桌面或非标准浏览器，需要提前确认图形环境和插件怎么跑。

速度也要当配置。公开页面读取可以快一点，登录态后台慢一点，社交平台写操作更要慢。OpenCLI 不是规避风控的工具，它只是把网页动作工程化。

它在 Agent 工具链里的位置

OpenCLI 最舒服的位置，是被其他 Agent 调用。

Codex 和 Claude Code 负责理解需求、写代码、整理文件和生成报告；Slock 更像聊天指挥入口；Multica 更像 issue 和 workspace 的协作层；OpenCLI 负责进入网页、保持登录态、操作页面，把结果拿回来。

排障时也要按这条链路拆：

• Agent 是否真的加载了 OpenCLI skill。
• OpenCLI 命令是否在当前环境可执行。
• 浏览器插件是否连接成功。
• profile 是否对应正确账号。
• 页面是复用还是每次新开。
• adapter 是否适配当前页面语言和 DOM。
• 失败发生在网页动作、命令调用、权限确认，还是 Agent 解析结果。

不要只说“OpenCLI 坏了”。很多问题其实出在 Agent 没加载 skill、命令路径不对、权限提示没处理，或者浏览器 profile 不是你以为的那个。

写操作要慢，账号要分级

读和写是两种风险。

读取公开网页风险低；读取自己登录后的收藏、点赞、后台数据风险中等；回复、发帖、批量关注、批量提交、下载大量文件、支付、删除数据，风险就高了。

比较稳的账号策略是：

1. 公开读取用低权限环境。 不要给采集任务挂主账号。
2. 个人知识库用个人 profile。 整理收藏可以用真实登录态，但先只读。
3. 后台操作用专门账号。 权限越小越好，能只读就只读。
4. 写操作必须有人确认。 发帖、回复、提交表单、删除、付款、下单，都不应该默认无人值守。

小红书、X、抖音、Instagram、Facebook 这类平台尤其要小心。平台当然可能识别异常行为，尤其是频率、IP、设备、鼠标轨迹、账号历史和写操作同时异常时。

容易卡住的地方

浏览器没起来。 先看浏览器和插件是否安装，是否是 Chrome 系，WSL/VPS 是否有图形环境或能连到宿主浏览器。

插件显示 connected，但 Agent 说 not connected。 检查浏览器是否是 OpenCLI 期望的浏览器。有人把扩展装在 Brave 里，结果 Codex 不认，换到正确浏览器后才解决。

任务完成后 tab 全留下。 先升级版本，再看 adapter 和页面关闭策略。早期 Google Search tab 残留就是这类问题。

网页 AI 产品每次都像新会话。 检查 browserSession.reuse 和 profile。网页 AI 更适合按站点复用页面。

同一个流程在 Claude Code 能跑，在 OpenClaw 跑不通。 先检查 OpenClaw 是否真的加载 OpenCLI skill，命令路径、权限提示和输出格式是否被正确传递。

采集列表漏数据。 对无限滚动、分页、推荐流和社交平台，要定义翻页策略、时间边界、去重规则和失败重试。

不要把它当万能浏览器

OpenCLI 不适合所有临时需求。它适合反复做、步骤固定、结果格式清楚、失败不会造成严重损失的网页流程。

比较适合沉淀：

• 把常看的论坛帖子或资讯页保存成 Markdown。
• 把某个平台收藏过的文章链接导出到知识库。
• 从后台导出固定报表并保存成 CSV。
• 查询企业基础信息并整理为结构化记录。
• 调用网页 AI 产品生成结果，再交给 Codex 继续处理。

暂时不要碰：

• 批量发帖、批量回复、批量关注。
• 支付、下单、转账、退款。
• 删除数据、修改权限、提交不可撤销表单。
• 高风控社交平台的主账号运营。
• 没有明确边界的“全网采集”。

OpenCLI 的成熟用法不是让 Agent 随便逛互联网，而是把你每天真的会打开的几个网页，变成 Agent 能稳定调用的工具。