喵喵宠物医院
86.09M · 2026-04-08
| 时间 | 事件 |
|---|---|
| 2025-12-13 | Google Cloud gogcli 个人开源项目发布首个版本（Go，覆盖 15+ Google API） |
| 2026-03-17 | 钉钉宣布已完成全面 CLI 化 |
| 2026-03-23 | 钉钉初次提交 CLI 代码 |
| 2026-03-27（周五） | 钉钉正式开源 dingtalk-workspace-cli |
| 2026-03-28（周六） | 飞书被钉钉倒逼临时开源 larksuite/cli |
| 2026-03-30（周一 00:17） | 企业微信首次提交代码，09:28 公关总监宣布开源 wecom-cli |
三天之内，三大平台全部"CLI 化"。但细看之下，三家的技术成熟度和开发策略天差地别。这是一场被 AI Agent 趋势倒逼的技术军备竞赛。
答案只有一个：AI Agent 需要 CLI。
传统的 GUI 界面是为人类设计的。人眼识别按钮、手指点击、大脑理解界面布局——这一切对 AI Agent 来说都是灾难。截图识别脆弱、UI 变更即失效、每一步都需要 LLM 推理，慢且贵。
而 CLI 天然适合 Agent：
--format json 返回的数据可以直接解析gogcli 的作者 steipete 在 2025 年底就看到了这个趋势。他在 Go 中把 Gmail、Calendar、Drive 等 15 个 Google API 打包成一个二进制 gog，并且专门为 Agent 设计了 --no-input（CI 模式不弹交互）、--enable-commands（命令白名单限制 Agent 能力）、GOG_AUTO_JSON=1（非 TTY 自动 JSON 输出）等特性。
这个个人项目成了国内大厂 CLI 化的"技术先声"。
飞书的 CLI 虽然是被倒逼开源的，但从代码质量看，明显已经开发了一段时间。Git 提交记录不连续，说明此前在内部迭代过。
Layer 1: Shortcuts（快捷命令）
+agenda → 查看今日日程
+messages-send → 发送消息
→ 手工编写，封装复杂多步逻辑
Layer 2: Service Commands（服务命令）
calendar events instance_view
im messages create
→ 自动从 OpenAPI 元数据生成，1:1 映射 2500+ API
Layer 3: Raw API（原始调用）
lark-cli api GET /open-apis/calendar/v4/calendars
→ 直接透传 HTTP 请求，逃生舱机制
这种设计的精妙之处在于分层满足不同用户：普通用户用快捷命令完成日常办公，AI Agent 用自动生成的服务命令进行结构化调用，开发者用 Raw API 覆盖所有边缘场景。
这是飞书架构中最精妙的部分。飞书的元数据机制不是简单的"编译时嵌入"，而是一个混合方案：
fetch_meta.py 从飞书开放平台拉取最新 2500+ API 定义，写入 meta_data.jsongo:embed 指令将元数据打包进二进制，作为兜底基线MergedRegistry 做两件事——
graph LR
subgraph BUILD[" 构建前"]
B1["fetch_meta.py"] -->|"拉取 2500+ API"| B2["meta_data.json"]
end
subgraph COMPILE["️ 构建中"]
B2 -->|"go:embed 嵌入"| C1["lark-cli 二进制<br/>内置完整元数据"]
end
subgraph RUNTIME[" 运行时"]
C1 -->|"读取嵌入数据<br/>（基线/离线兜底）"| R1["MergedRegistry<br/>合并引擎"]
S1["飞书开放平台<br/>最新 API 元数据"] -->|"运行时拉取"| R1
R1 -->|"合并 → 动态生成"| R2["Cobra 命令树"]
end
style R1 fill:#c62828,color:#fff
style R2 fill:#e53935,color:#fff
style B2 fill:#1976d2,color:#fff
style C1 fill:#1976d2,color:#fff
这意味着什么？
对比钉钉的"纯运行时 MCP 发现"，飞书的方案多了一层编译时兜底，兼顾了离线可用性和实时同步——可以说是两边优点都要了。
钉钉的 dingtalk-workspace-cli 走了一条与飞书截然不同的路——不硬编码任何产品命令。
graph TB
subgraph MARKET[" MCP 市场 mcp.dingtalk.com"]
MS1[calendar 服务]
MS2[aitable 服务]
MS3[chat 服务]
end
subgraph PIPELINE["发现驱动管道"]
D1["Market<br/>拉取服务注册表"]
D2["Discovery<br/>MCP initialize + tools/list 握手"]
D3["IR 中间表示<br/>Product → Tool 目录规范化"]
D4["CLI 命令层 Cobra<br/>inputSchema → Flags 映射"]
D5["Transport<br/>MCP JSON-RPC 执行"]
end
MS1 & MS2 & MS3 --> D1
D1 --> D2 --> D3 --> D4 --> D5
subgraph CACHE["缓存策略"]
CA1["命中且未过期 → 零网络请求"]
CA2["过期 → 尝试刷新，失败用过期缓存"]
CA3["无缓存 → 完整 MCP 握手"]
end
D2 --- CA1
D2 --- CA2
D2 --- CA3
style D4 fill:#ff6b00,color:#fff
style CA1 fill:#51cf66,color:#fff
style CA2 fill:#ffd43b,color:#000
style CA3 fill:#ff6b6b,color:#fff
最大价值主张：钉钉在 MCP 市场上线任何新服务，用户无需升级 dws 即可自动获得新命令。这是"平台驱动"而非"客户端驱动"的能力扩展模型。
| 维度 | 飞书（混合模式） | 钉钉（纯运行时发现） |
|---|---|---|
| 元数据来源 | 编译时嵌入 + 运行时服务端拉取，合并使用 | 纯运行时从 MCP 市场发现 |
| 离线可用 | 嵌入的元数据兜底 | ️ 依赖本地缓存（stale-fallback） |
| 新 API 同步 | 运行时拉取增量更新，合并生效 | 自动获得，零升级成本 |
| 命令稳定性 | 高（嵌入基线保证稳定性） | 依赖服务端稳定性 |
| 二进制体积 | 较大（含完整元数据） | 较小（不含元数据） |
skills/
├── SKILL.md ← 第一层：单一入口（AI 只读这个）
├── references/ ← 第二层：按需加载的深度文档
│ ├── products/ ← 各产品命令参考（9 个产品）
│ ├── intent-guide.md ← 意图路由指南（防 AI 猜错）
│ └── error-codes.md ← 错误码 + 调试流程
└── scripts/ ← 第三层：12 个 Python 批处理脚本
intent-guide.md 是一个被低估的设计。它明确列出了易混淆场景的边界：
| 用户说… | 真实意图 | 应该用 | 不要用 |
|---|---|---|---|
| "帮我建一个项目跟踪表" | 创建数据表格 | aitable | todo |
| "帮我记一下明天要做的事" | 创建待办 | todo | aitable |
| "让机器人在群里发通知" | 机器人群发 | chat bot send | chat webhook send |
硬件绑定 Token 加密也是亮点：PBKDF2-HMAC-SHA256（600,000 次迭代）+ 设备 MAC 地址 + AES-256-GCM，Token 文件拷贝到其他设备无法解密。
如果说飞书是"蓄谋已久"、钉钉是"主动出击"，那企业微信就是"被迫营业"。
证据链：
架构分析验证了"临时拼凑"的判断：
本质上，企业微信的方案是用 MCP 做了一层薄封装，把远端的能力"透传"到命令行。没有飞书的元数据工程，没有钉钉的服务发现管道，更像是一个 MCP Client 的 CLI 壳。
jackwener/opencli 的定位是"让任何网站、Electron 应用或本地工具成为你的 CLI"。
双引擎架构：
核心机制是 Browser Bridge：Chrome Extension (MV3) + 本地 Daemon (localhost:19825) + WebSocket 通信，通过 Chrome DevTools Protocol 控制浏览器，复用 Chrome 已登录状态（Cookie/Token）而不存储任何凭据。
五级认证策略（PUBLIC → COOKIE → HEADER → INTERCEPT → UI）适配不同安全等级的网站，opencli cascade 命令可自动探测最佳策略。
最大卖点：零 LLM 运行时成本。所有命令执行都是确定性操作，运行 10000 次也无需付费——这对定时数据提取和 AI Agent 集成至关重要。
HKUDS/CLI-Anything 的理念是 "Use the Real Software — Don't Reimplement It"。
通过 7 阶段流水线，分析软件源码 → 设计命令架构 → 实现 CLI → 测试 → 发布为 pip 包：
Phase 0: 源码获取（git clone）
Phase 1: 代码分析 → SOFTWARE.md
Phase 2: 架构设计 → 命令组 + 状态模型
Phase 3: 实现 → Click CLI + REPL + --json
Phase 4: 测试计划 → TEST.md
Phase 5: 测试实现 → test_core.py + test_full_e2e.py
Phase 6: 测试文档
Phase 6.5: SKILL.md 生成
Phase 7: PyPI 打包发布
生成的 CLI 通过 subprocess 调用真实软件后端（GIMP、Blender、LibreOffice 等），而非重新实现。已注册 30+ 应用，涵盖图像、3D、视频、音频、办公等类别。
综合分析这六个项目，可以提炼出 CLI 化浪潮的几个核心趋势：
graph LR
subgraph OLD["传统 GUI 路径"]
A1[截图] --> A2[LLM 识别] --> A3[模拟点击] --> A4[截图验证]
style A2 fill:#ff6b6b,color:#fff
end
subgraph NEW["CLI 路径"]
B1["dws calendar event list<br/>--format json"] --> B2["结构化 JSON 输出"] --> B3["Agent 直接解析"]
style B1 fill:#51cf66,color:#fff
end
style OLD fill:#fff0f0,stroke:#ff6b6b
style NEW fill:#f0fff0,stroke:#51cf66
所有项目都把 Agent 友好作为首要设计目标：
--format json / --json 成为标配--dry-run 和 --yes 让 Agent 能安全地自动执行| 层级 | 用途 | 用户 |
|---|---|---|
| L1 快捷命令 | 高层封装，一步完成 | 普通用户 |
| L2 服务命令 | API 级别的结构化调用 | AI Agent |
| L3 原始 API | 透传一切，逃生舱 | 开发者 |
飞书和 gogcli 都采用了这种分层。钉钉因为"发现驱动"的架构特性没有 L1/L3 的显式分层，但其 Skill 脚本层（Python 批处理）在功能上等价于 L1 快捷命令。
钉钉和企业微信都选择了 MCP（Model Context Protocol）作为底层通信协议。这意味着 CLI 本质上是一个 MCP Client 的终端壳，服务端能力通过 tools/list 标准化暴露，新服务接入成本趋近于零。
飞书虽然没用 MCP，但其 OpenAPI 元数据驱动的自动生成机制在效果上等价——都是"平台侧定义能力，CLI 侧薄壳透传"。
graph TB
S1[" 凭据层<br/>OS Keyring + AES-256-GCM<br/>硬件绑定 / 双层锁"]
S2[" 传输层<br/>TLS 1.2+ / 可信域名白名单<br/>请求签名 / 审计头注入"]
S3["️ Agent 安全层<br/>命令白名单 / 危险操作三步确认<br/>意图决策树 / 输出 ANSI 防护"]
S4[" Prompt 注入防护<br/>安全红线 NEVER DO / MUST DO<br/>结构化输出 / 非自然语言"]
S1 --> S2 --> S3 --> S4
style S4 fill:#c62828,color:#fff
style S3 fill:#ff6b00,color:#fff
当 CLI 被 AI Agent 调用时，攻击面从"人类用户"扩展到了"Agent 的推理能力"——传统安全模型需要全面升级。
飞书的混合元数据方案（编译时嵌入 + 运行时拉取合并）和钉钉的纯运行时 MCP 发现，代表了两种"平台驱动"的模式。核心思想一致：命令的定义权在平台侧，CLI 只是一个薄壳。
这意味着平台可以随时扩展能力，用户无需升级客户端。对企业 IT 基础设施来说，这是一个巨大的运维优势。
这波 CLI 化浪潮背后有三个深层趋势值得关注：
第一，MCP 正在成为协议标准，CLI 是它的实现层。 钉钉和企业微信已经基于 MCP 协议构建 CLI，飞书虽然用 OpenAPI 元数据驱动，但做的事情等价——都是把平台的业务能力通过标准化协议暴露出来，CLI 只是面向用户（包括 AI Agent）的命令行壳。当底层协议趋同，CLI 层就可以被统一，AI Agent 用一套方式就能调用钉钉、飞书、企业微信，不需要为每个平台单独写适配器。
第二，CLI 化的本质不是"回归命令行"，而是"重构为 API"。 三家平台的 CLI 都不是对现有 GUI 的简单翻译，而是把业务能力重新组织为结构化的命令接口。这个过程本身就是在倒逼平台把内部能力标准化——CLI 只是暴露出来的那一层。
第三，安全将成为下一阶段的核心战场。 现在的安全设计还在"凭据存储 + 传输加密"的阶段，但当 AI Agent 大规模调用 CLI 时，新的攻击面会出现：Agent 被诱导执行高风险操作、Skills 文档被注入恶意指令、多租户环境下的权限隔离。谁先把安全做透，谁就拿到企业市场的入场券。
72 小时内三大平台争相开源 CLI，表面上是"被钉钉逼的"，深层原因却是 AI Agent 正在重塑企业软件的交互范式。
当 AI Agent 成为企业办公的主要用户之一，GUI 的意义正在被重新审视。CLI 不是倒退到命令行时代，而是进化为人类与 AI 共享的标准化接口。
这场竞赛才刚刚开始。
