Official CLI vs Website-as-CLI

# Official CLI vs Website-as-CLI：哪条路线更适合 AI Agent？

整理日期：2026-03-15

## 问题是什么

当我们说“让 AI Agent 使用一个网站/服务”时，实际上有两条完全不同的路线：

1. **Official CLI**
   - 产品官方直接提供 CLI
   - 例如：Resend CLI

2. **Website-as-CLI**
   - 原本只有网页，没有官方 CLI
   - 再通过浏览器上下文、适配器、YAML 描述、MCP bridge 等方式，把网站“包装成 CLI”
   - 例如：OpenCLI 这类方向

这两条路最终都通向一个目标：

> **让 AI / Agent 能够稳定、结构化地调用现实世界里的服务能力。**

但它们在稳定性、成本、权限边界、演化方式上，有很大差异。

---

## 路线一：Official CLI

Official CLI 指的是：

- 产品官方自己提供 CLI
- 由产品团队维护
- 命令结构、权限模型、身份切换、输出格式都属于官方能力的一部分

典型例子：
- Resend CLI
- GitHub CLI
- Docker CLI
- Vercel CLI

### 它的优点

#### 1. 稳定性通常更高
因为它不是“外部补丁”，而是官方产品的一部分。

这意味着：
- 功能与服务本身同步演进
- 不容易因为网页改版突然失效
- 边界更明确

#### 2. 更适合长期接入 Agent
Agent 最怕的不是不会用工具，而是：
- 工具今天能用，明天失效
- 参数不稳定
- 输出不稳定
- 上下文语义不清楚

Official CLI 往往更适合：
- 自动化
- 长期流程
- 团队工作流
- 大规模复用

#### 3. 身份和权限模型通常更清晰
像 Resend CLI 这种，已经开始考虑：
- team / profile 切换
- 多账号上下文
- 工作身份管理

这对 Agent 特别重要，因为 agent 一旦搞错身份，后果就是真实的。

#### 4. 更容易和 AI 工具层融合
Official CLI 通常天然更适合被包进：
- MCP
- Agent tools
- CI/CD
- Shell workflow
- 脚本系统

也就是说，它本来就更接近“机器接口”。

### 它的缺点

#### 1. 不是每个产品都愿意做
这是最大的现实问题。

很多网站：
- 根本没有 CLI
- 没有清晰 API
- 不把 Agent / 自动化场景当重点

#### 2. CLI 能力往往只覆盖官方愿意暴露的范围
如果产品方没暴露某个能力：
- 你就没有
- 想做也做不了

所以 Official CLI 的上限有时候受制于产品策略，而不是技术能力。

---

## 路线二：Website-as-CLI

Website-as-CLI 的思路是：

- 即便官方没有 CLI
- 也尝试把现有网页能力抽象成命令接口
- 让网站像 CLI 一样被调用

它通常依赖：
- 真实浏览器上下文
- 已登录 Chrome 会话
- MCP bridge
- 适配器描述（例如 YAML）
- 页面操作模式抽象

### 它的优点

#### 1. 覆盖面极广
这是它最大的优势。

因为现实世界里绝大多数网站：
- 没有官方 CLI
- 没有好 API
- 只有网页

Website-as-CLI 让这些网站第一次有机会进入 Agent 工作流。

#### 2. 对现实工作更有穿透力
很多高价值操作都在：
- 登录后的后台
- 运营系统
- SaaS 控制台
- 数据面板
- 管理后台

这些地方，官方未必给 CLI，但浏览器里能做。

Website-as-CLI 的意义就是：

> **让 Agent 不依赖官方产品战略，也能进入真实工作场景。**

#### 3. 更灵活，适合快速实验
如果你只是想：
- 先跑通一个流程
- 先做出自动化原型
- 先让 Agent 能操作某个系统

Website-as-CLI 通常会比等官方出 CLI 更现实。

### 它的缺点

#### 1. 稳定性天然更差
因为它建立在：
- 网页结构
- 浏览器行为
- 前端逻辑
- UI 流程

之上。

任何一层变化，都可能导致适配失效。

#### 2. 更容易碰到身份、风控和上下文问题
如果 Website-as-CLI 不依赖真实浏览器上下文，就会撞上我们最近一直在讲的“身份隔离”问题：

- 登录态不同
- Cookie 不同
- 页面上下文不同
- 工作流被切碎

所以这条路线如果想做好，几乎必然要和：
- Chrome attach
- 真实登录态复用
- 浏览器上下文共享

绑定在一起。

#### 3. 维护成本高
一旦网站：
- 改页面
- 改按钮
- 改流程
- 改前端框架

适配器就可能要改。

这意味着它更像：
- 持续维护工程
- 而不是一次写好永久稳定的接口

---

## 对 AI Agent 来说，哪条路线更好？

如果只问“哪条路线更适合长期、稳定、规模化”，答案其实很明确：

> **Official CLI 更好。**

因为对 Agent 来说，最重要的是：
- 明确的命令边界
- 稳定的参数结构
- 可预测的输出
- 清晰的身份切换
- 长期可靠性

Official CLI 在这些方面天然占优。

但如果问“现实世界里哪条路线更重要”，答案又会变成：

> **Website-as-CLI 更不可或缺。**

因为现实世界里大多数系统，根本没有 Official CLI。

所以真正成熟的 Agent 生态，不会只押一条路，而会同时接受：

- **能用 Official CLI 的地方，优先 Official CLI**
- **没有 Official CLI 的地方，再用 Website-as-CLI 去补足**

---

## 这两条路线不是竞争关系，而是分层关系

一个更合理的理解方式是：

### 第一层：Official CLI / API / MCP
- 最稳
- 最清晰
- 最适合长期接入

### 第二层：Website-as-CLI / Browser Tooling
- 覆盖官方没开放出来的能力
- 进入只有网页的真实系统
- 解决现实落地问题

换句话说：

> **Official CLI 是理想层，Website-as-CLI 是现实补全层。**

这两者不是互斥，而是互补。

---

## OpenClaw / OpenCLI / Resend CLI 三者可以怎么放在同一张图里

如果把最近你在研究的东西放到同一张图里，可以这样理解：

### OpenClaw Chrome Attach
解决的是：
- Agent 如何进入真实浏览器环境
- 如何减少身份隔离

### OpenCLI
解决的是：
- 进入浏览器环境后，如何把网站进一步工具化 / CLI 化

### Resend CLI
代表的是：
- 最理想情况：产品方自己直接提供 CLI
- 不需要再“把网站包装成工具”

所以这几者不是分散话题，而是同一条演化路线上的不同阶段：

> **进入真实环境 → 抽象网站能力 → 官方原生工具化**

---

## 对你当前研究最重要的结论

如果压成一句实用建议：

### 优先级建议
1. **优先使用 Official CLI**
   - 更稳
   - 更清晰
   - 更适合 Agent 长期工作流

2. **没有 Official CLI 时，再考虑 Website-as-CLI**
   - 特别适合网页后台和已登录系统

3. **如果要走 Website-as-CLI，就尽量复用真实浏览器上下文**
   - 否则会再次掉进“身份隔离”的坑

---

## 一句话总结

如果要给这两条路线下一个最简洁的判断，我会这么说：

> **Official CLI 是 AI Agent 最理想的工具形态，Website-as-CLI 是现实世界里最必要的补丁层。**

真正成熟的 Agent 生态，不会二选一，而会同时拥有这两条能力线。