CLI 这波，Google 终于把 Workspace 真往 agent 方向接了

最近 Google Workspace 团队把一个叫 gws 的命令行工具放上 GitHub 了。

以前大家说 agent 能干活，很多时候还是停在本地文件、代码仓库、终端命令这些偏开发环境的东西。真到了办公流，事情立刻变碎：日历一个接口，邮件一个接口，网盘一个接口，文档和表格又是另一套。你要让 AI 真去“办事”，中间那层胶水得自己补，很烦。

gws 做的，差不多就是这层胶水。

你现在完全可以想象这种用法：在 Claude Code、Gemini CLI 这种环境里，直接丢一句“看下我明天日程”“把这个文件传到 Drive”“往这张 Sheets 里补一行数据”。以前这种工作流不是做不了，是得东拼西凑。现在至少路开始顺了。

我觉得这比“又多了个 CLI”重要得多。

还有个细节挺关键：它不是那种预先写死一大坨子命令的工具。项目说明里提到，gws 是运行时去读 Google Discovery Service，再动态生成命令面。这意味着 Workspace API 这边只要有新能力放出来，它理论上跟起来会更快，不必每次都等开发者手动补子命令。对 agent 来说，这种结构就很友好。

安装这块也比我想象中现实。

虽然底层是 Rust 写的，但官方主推的方式其实是：

npm install -g @googleworkspace/cli

原因也很简单：npm 包里已经带了各平台预编译二进制，正常用户不需要先配一套 Rust 工具链。你愿意折腾，当然也还能走别的安装方式，但它显然是在尽量压低第一步门槛。这个判断挺对，工具要传播，先别让用户卡死在安装上。README 和 release 页面都能看到这套分发方式。

再往 agent 那边看，它也不是只把 CLI 丢出来就完事。

仓库现在已经把 agent skills 一起带上了，README 写的是 40+ agent skills included，还能给兼容客户端起 MCP 服务。你能感觉到，这项目一开始想的就不只是“给开发者多一个命令行工具”，而是想往 agent 工作流里直接塞。

不过这玩意儿也别吹太满。

一个是 README 写得很明白：这不是 officially supported Google product。再一个，项目还在很快地迭代，最近几天 release 还在频繁更新。它显然还没到那种“企业用户闭眼上”的成熟度。

还有认证这关，门槛也并没有 magically 消失。你还是得准备 Google Cloud project、OAuth 凭证、启用对应 API。这部分官方文档写得很完整，但也正因为完整，才说明这不是一个“点一下就能彻底无脑开箱”的消费级产品。

甚至现在 GitHub issue 里都已经有人在提多账号切换的问题。也就是说，这东西很新，很能打，但还明显带着早期工具那股毛边感。

但说实话，我反而觉得这正是它有意思的地方。

它不是在重新发明一个 AI 叙事，而是在补那层一直缺着的基础设施。 大家这两年总在说“AI 能替你干活”，可很多时候那个“活”，还是停在写代码、改文案、总结网页。真正高频、琐碎、每天都得碰的办公动作——邮件、日历、表格、文档、网盘——其实一直没被很好地接进来。

gws 这种项目的价值就在这儿：它不一定代表 Google 立刻做出了一个成熟产品，但它至少把一个方向摆得很明确——agent 不只是会写，而是开始接 Workspace 这种真实工作流了。

所以这项目值不值得看？

我觉得值得，而且不是那种“收藏一下以后再说”的值得。 如果你本来就在折腾 Claude Code、Gemini CLI，或者你就对 agent 怎么碰到真实办公系统这件事有兴趣，这仓库基本已经可以先盯上了。

它现在当然还不完美。 但很多时候，真正值得看的也不是“已经完成的产品”，而是那种你一眼就知道：这东西一旦跑顺，会很麻烦，也会很有用。