googleworkspace/cli

解决什么问题

自动化 Google Workspace 的痛点很具体：OAuth 流程、官方客户端库或对着 REST 文档手写 curl、分页循环、每个接口各自的 JSON 结构，几乎每个项目都要重新搭一遍。gws 把这些收进一个二进制：运行时读取 Google 的 Discovery Service 动态生成命令面，每个方法都以结构化 JSON 的形式暴露出来。

有什么不同

常见做法有两条路。一是官方客户端库，语言原生、类型完整，但绑定某种语言，而且请求/响应模型仍需自己处理；二是自己写 curl 脚本，没有 schema 感知，也没有分页。gws 取中间路线：命令面由 Discovery 生成，新接口不用等发版就能用；gws schema 可以直接查任意方法的请求/响应结构；--dry-run、自动分页和 NDJSON 流式输出让它对 shell 友好。另一个差异点是仓库自带的 agent skills——每个 API 一份 SKILL.md，外加整理好的常用配方，让 LLM Agent 无需自建工具即可操作 Workspace。这是定位上的选择，官方客户端库并不提供。

适合谁

适合在 shell、CI 或服务器上脚本化 Workspace 的开发者和运维，以及需要让 Agent 访问 Drive、Gmail、Calendar、Sheets、Docs、Admin 的团队。前提是你已有 Google Cloud 项目并能完成 OAuth 配置。如果你需要的是应用代码里的强类型绑定，或者拿不到 OAuth 凭证，它帮不了你——这部分要求没有被消除。企业管理员还要考虑：README 明确写了这不是 Google 官方支持的产品，审计和托管能力需要自行评估。

上手成本

需要一个 Google Cloud 项目和 OAuth 客户端；用 npm 安装需要 Node.js 18+，其他方式有预编译二进制。认证是真正卡人的地方：测试模式下的 OAuth 应用同意范围上限约 25 个 scope，README 也提示 recommended 预设包含 85+ scope，未验证应用会直接失败，所以需要自己按服务挑选 scope（如 gws auth login -s drive,gmail,sheets）。凭证以 AES-256-GCM 加密存储，密钥放在系统 keyring，也提供文件后端作为兜底。项目自称 v1.0 前会有破坏性变更，README 写得很长也很细，直接以它为准。

点评

仓库很新（2026 年 3 月创建），但已积累约 3.18 万 star，本周 Rust 榜 +274 排到第 13，发布时还有一条 953 分的 Hacker News 讨论——这说明是强势尖峰而非长期积累，且未上过日榜。按 Discovery 动态生成命令面，对这么宽的 API 面来说是对路的设计，agent skills 的打包也踩准了时机。建议把它看成有潜力但快速演进的项目，不要当稳定件：放进 CI 就锁版本，v1.0 之前预期会有变动。