官方亲自下场：用 gws 和 lark-cli 把 SaaS 搬进终端

引言

过去十年，SaaS 的入口是网页和 App。开发者想自动化，只能自己包一层 API：读文档、处理 OAuth、拼接分页、写重试逻辑，一个网盘列表接口能写出两百行胶水代码。

2026 年出现了一个明显变化：厂商自己开始发 CLI，而且不约而同地在 README 第一行写上 "built for humans and AI Agents"。这意味着产品设计目标变了——终端不再只是极客的玩具，而是 Agent 的默认操作面。

这一篇介绍两个近期的代表性项目：Google Workspace 的 gws，和飞书官方的 lark-cli。它们分别代表两种路线：动态生成命令面，与三层命令体系。

一、gws：一个二进制接管整个 Google Workspace

• 项目地址：https://github.com/googleworkspace/cli
• Star 数：约 32K（2026-11 初）
• 语言 / 许可：Rust，Apache-2.0

gws 最反直觉的设计是：它不维护静态命令列表。启动时读取 Google 自己的 Discovery Service，在运行时动态构建整个命令面。Google 每新增一个 API 端点或方法，gws 自动就能用——不需要等社区提 PR，也不会出现"文档更新了但 CLI 还是旧版"的尴尬。

覆盖面是 Drive、Gmail、Calendar、Sheets、Docs、Chat、Admin，基本等于把 Workspace 全家桶搬到 shell。

上手三步：

gws auth setup       # 引导完成 Google Cloud 项目配置（需要 gcloud）
gws auth login       # 后续 OAuth 登录
gws drive files list --params '{"pageSize": 5}'

实际写脚本时，几个细节很省事：

# 结构化 JSON 输出，直接接 jq
gws drive files list --params '{"pageSize": 100}' --page-all | jq -r '.files[].name'

# 建表
gws sheets spreadsheets create --json '{"properties": {"title": "Q1 Budget"}}'

# 先预览请求，不真正发出
gws chat spaces messages create \
  --params '{"parent": "spaces/xyz"}' \
  --json '{"text": "Deploy complete."}' \
  --dry-run

# 查任意方法的请求/响应 schema
gws schema drive.files.list

--dry-run、自动分页、NDJSON 流式输出、schema 自省，这四件事正好对应脚本化的四个痛点：怕误操作、怕分页写错、怕结果太大、怕字段猜错。

安装方式给得很全：

brew install googleworkspace-cli
npm install -g @googleworkspace/cli
cargo install --git https://github.com/googleworkspace/cli --locked
nix run github:googleworkspace/cli

认证不止一种姿势，这是它能进 CI 的关键：本地交互式 gws auth login（凭据用 AES-256-GCM 加密，密钥进系统钥匙串）；gws auth export --unmasked 导出后在无头机器上用 GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE 加载；服务账号直接指 key 文件；也支持 GOOGLE_WORKSPACE_CLI_TOKEN 复用已有 token。

面向 Agent 的部分也很实在：仓库内置 100+ 个 SKILL.md，每个 API 一份，另有 50 个覆盖 Gmail / Drive / Docs / Calendar / Sheets 的常用配方，一句 npx skills add https://github.com/googleworkspace/cli 就能装齐。

需要注意两点：README 明确写着这不是 Google 官方支持的产品；项目仍在向 v1.0 推进，会有 breaking change。另外 OAuth 应用处于测试模式时，Google 只允许约 25 个 scope，而 recommended 预设包含 85+ 个，未验证应用必然失败——这时应该按服务逐个授权，例如 gws auth login -s drive,gmail,sheets。

简要评价：动态命令面是个聪明的取舍——用一点启动开销换掉了"永远滞后"的维护负担。对个人用户，它把 curl 调 REST 的痛苦降到接近零；对 Agent，结构化输出加技能包意味着不用为 Workspace 写自定义工具。

二、lark-cli：把飞书 200+ 命令做成三层结构

• 项目地址：https://github.com/larksuite/cli
• Star 数：约 17.9K（2026-11 初）
• 语言 / 许可：Go 1.23+，MIT，由 larksuite 团队官方维护

lark-cli 覆盖 18 个业务域、200+ 条精选命令、26 个 Agent Skills：消息、文档、多维表格、电子表格、幻灯片、日历、邮箱、任务、会议、知识库、通讯录、考勤、审批、OKR 都在里面。

它最值得抄的是三层命令体系：

这个分层解决了一个真实矛盾：给 Agent 用的命令要短、参数要少、默认值要聪明；而完整能力又必须保留。三层并存，让同一套工具既能被 LLM 稳定调用，又不会因为"简化"而丢失覆盖面。

上手三步，设计得相当克制：

npx @larksuite/cli@latest install   # 安装
lark-cli config init                # 一次性配置应用凭据（引导式）
lark-cli auth login --recommend     # 登录，自动选择常用权限
lark-cli calendar +agenda           # 开始用

README 里甚至专门写了一段"给 AI Agent 的安装流程"：config init --new 和 auth login 都要求后台运行，把输出的授权 URL 提取出来发给用户，用户浏览器里完成后命令自动退出，最后用 auth status 验证。这类把交互式登录改造成"Agent 可编排、人类只做授权"的流程，是 agent-native 设计里最容易被忽略、也最实用的一环。

安全方面给了三条硬措施：输入注入防护、终端输出净化、凭据存进操作系统原生钥匙串。对要处理群消息、邮件、审批这类高敏数据的 CLI，这些不是加分项，而是及格线。

企业场景也有出口：extension/ 包支持通过包装 main 来嵌入自己的 Agent，集中管理凭据（数据库 / Vault / 配置中心）、统一审计日志、收窄命令面，不需要改 CLI 源码。

简要评价：官方维护意味着接口变更和权限模型有保障，这是第三方封装永远给不了的。三层体系加上 26 个 Skills，对中文办公场景几乎是最优解。小遗憾是项目域（Meegle）拆成了独立的 meegle-cli，需要单独安装。

三、为什么是 CLI，而不是又一个 MCP

看到这两个项目，很容易问：现在不是 MCP 的时代吗，为什么厂商发的是 CLI？

几个现实原因：

1. 上下文成本。MCP 工具要把 schema 塞进上下文，工具一多就吃掉大量 token。CLI 只需要一行 --help，用到再查，成本低一个量级。
2. 可组合性。管道、jq、xargs、shell 变量，CLI 天生能和已有工具链拼起来；MCP 调用是离散的，组合要在 Agent 侧写逻辑。
3. 可审计。每条命令都是一条可复现、可 grep、可写进 runbook 的字符串；排障时人和 Agent 看到的是同一份东西。
4. 权限边界清楚。给 Agent 一个受限的 shell 白名单，比给它一堆能读遍全盘的 MCP 工具更容易收敛风险。

两者并不冲突。agent-browser 同时提供 skills 和 mcp，lark-cli 也把能力沉淀成 Skills——CLI 是执行层，Skills 是知识层，MCP 是另一种接入协议。选哪个取决于你的 harness 更擅长哪一种，而不是谁更"先进"。

两个项目横向对比：

总结

gws 和 lark-cli 代表同一个趋势的两个侧面：SaaS 正在把"人机共用"当作默认设计目标，而不是事后补一个 API。

具体到使用建议：

• 你的工作流主要围绕 Google 生态，又要进 CI：选 gws。动态命令面意味着不会因为 Google 上新而落后，--dry-run 和 NDJSON 输出对脚本极友好。记得先解决测试模式的 scope 限制。
• 你的团队在飞书里办公：选 lark-cli。官方维护 + 三层体系 + 中文场景覆盖，几乎没有替代品。让 Agent 自己跑安装流程，你只需要在浏览器里点授权。
• 两个都用：把"从邮件/日历拉上下文"和"在多维表里写结论"串成一条 shell 管道，这才是终端作为 Agent 主场的真正价值。

一句话判断一个 CLI 是否"agent-native"：它的默认输出是给 LLM 读的结构化文本，它的失败是明确错误码而不是模糊成功，它的安装和登录能被 Agent 自己编排完。 这两个项目都过了这三关。