SpringForAll社区

菜单

hello
发布于 2026-06-27 / 2 阅读
0
0

别再让 AI 只会聊天：这个工具让 Agent 开始操作 Gmail 和文档

这两天，一个叫 gws 的 Google Workspace 命令行工具有点出圈。

故事本身很抓人：

前 Google 工程师 Justin Poehnelt 做了一个 Workspace CLI，能用命令行操作 Gmail、Drive、Calendar、Docs、Sheets 等 Google 办公套件。外媒报道说，这个项目冲上 Hacker News 第一，短时间拿到大量 GitHub star 和用户关注，然后他被 Google 开了。

这类故事很容易写成大厂宫斗。

但我更关心另一个问题：

为什么一个“办公软件命令行工具”，会在 AI Agent 时代突然变得这么敏感？

因为它解决的不是“人类想不想在终端里发邮件”这个小问题。

它真正打开的是：

AI Agent 能不能绕开聊天框，直接、安全、结构化地操作你的办公系统。

它是什么？

gws 的全名可以理解为 Google Workspace CLI。

项目 README 里写得很直接：它是一个面向人和 AI Agent 的 Google Workspace 命令行工具，可以覆盖 Drive、Gmail、Calendar，以及其他 Workspace API。

它的核心目标不是做一个更酷的终端玩具，而是把 Google Workspace 变成 Agent 能稳定调用的工具层。

以前你想让 Agent 操作 Google Workspace，大概有几种方式：

方式问题
直接写 REST API要处理 OAuth、接口路径、参数、分页、错误
自己封装工具函数每接一个服务都要重新写一遍
让 Agent 操作网页不稳定，容易受页面变化影响
用现成自动化平台很方便，但对开发者和 Agent 不一定足够可控

gws 的思路是：

把 Workspace 的 API 变成一套统一命令，输出结构化 JSON，让人和 Agent 都能读。

比如列出最近的 Drive 文件、创建一个表格、发送 Chat 消息、读取某个接口的请求和响应 schema，都可以走命令行。

这件事对人类来说是少写样板代码。

对 Agent 来说，意义更大：

它终于有了一个可枚举、可解释、可组合、可审计的办公入口。

为什么它适合 Agent？

我觉得 gws 最值得看的，不是它支持了几个 Google 服务，而是几个设计选择刚好踩中了 Agent 的需求。

第一，它输出结构化 JSON。

聊天模型最怕的不是调用工具，而是工具返回一团给人看的文本。JSON 输出意味着 Agent 可以继续解析、过滤、组合下一步动作。

比如读取邮件列表之后，不是让模型从终端输出里猜，而是直接拿到结构化字段：

邮件列表 -> JSON -> 模型筛选重要邮件 -> 继续读取详情 -> 生成回复草稿

第二，它不是手写一张固定命令表。

README 里提到，gws 会在运行时读取 Google 的 Discovery Service，然后动态生成命令面。也就是说，当 Google Workspace 增加新的 API endpoint 或 method，它可以自动拾取到新的能力。

这点对 Agent 很关键。

如果一个工具的能力表总是过期，Agent 就会在“文档说有、实际不能用”之间反复撞墙。动态读取 API schema，至少让工具层更接近真实服务。

第三，它带 Agent Skills。

项目里不只是有 CLI，还提供了一批 SKILL.md 文件。README 里说，它包含 100+ Agent Skills，覆盖支持的 API，也有 Gmail、Drive、Docs、Calendar、Sheets 这些常见工作流的 recipes。

这意味着它不是只给人看的 CLI，而是明确在给 Agent 生态铺路。

Agent 不只需要一个命令，它还需要知道：

  • 什么时候该用这个命令；
  • 参数该怎么组织；
  • 返回结果该怎么看；
  • 常见任务怎么拆步骤；
  • 哪些权限和失败情况要注意。

这就是 Skills 的价值。

第四，它可以接 Gemini CLI。

README 里有专门的 Gemini CLI Extension 安装方式。装上之后，Gemini CLI Agent 就可以直接访问 gws 命令和 Google Workspace agent skills。

这就从“我手动在终端里敲命令”，变成了：

你告诉 Agent 目标，Agent 自己调用 Workspace 工具完成任务。

能做什么？

如果只看命令行，gws 好像就是另一个开发者工具。

但如果从 Agent 办公角度看，它能串起来的场景就很多。

场景Agent 可以怎么做
邮件整理列出未读邮件，按发件人和主题归类，提炼需要回复的内容
会议准备读取今日 Calendar，查找关联文档，生成会议前摘要
周报生成从日历、邮件、文档里抽取本周事项，整理成草稿
Drive 检索根据关键词找文件，读取元数据，按项目归档
表格创建创建 Sheet，写入结构化数据，追加统计结果
团队通知任务完成后，把摘要发到 Google Chat

这些事情以前也能做，但通常要写很多胶水代码。

Agent 时代的问题不是“有没有 API”，而是：

这些 API 能不能被模型低成本理解，并且以可控方式调用。

gws 的价值就在这里。

它把办公软件从“网页界面”和“开发者文档”，变成了一组 Agent 可以操作的命令。

为什么命令行突然重要了？

过去，命令行主要是开发者自己的生产力工具。

但现在它正在变成 Agent 的工具接口。

原因很简单：

  • 命令行天然可脚本化；
  • 输入输出容易记录；
  • 权限边界可以通过环境和凭证控制；
  • 每一步执行都能留下日志；
  • 比网页 UI 更稳定；
  • 比随手封装的工具函数更通用。

这也是为什么 Claude Code、Codex、Gemini CLI 这类工具会让开发者兴奋。

Agent 不一定非要长出一个全新的“AI 专用操作系统”。很多时候，它只要能稳定调用已有命令行，就已经能做很多真实工作。

gws 放到这个趋势里看，就不是一个孤立项目。

它代表的是：

办公软件正在被重新包装成 Agent 可操作的基础设施。

Gmail 不只是收件箱，Drive 不只是网盘，Calendar 不只是日程表，Docs 不只是文档编辑器。

对 Agent 来说，它们都是任务上下文、输入源、输出位置和执行对象。

但别急着全权交给它

这里必须泼一点冷水。

gws 很有想象力，但它操作的是你的真实办公数据。

邮件、文档、日历、网盘、表格，这些东西的敏感程度比普通网页高很多。让 Agent 能访问它们，等于把一部分工作上下文交给了模型和工具链。

所以真正用的时候，最重要的不是“能不能跑通 Demo”，而是权限边界。

我建议从这几个原则开始：

原则说明
先只读先让 Agent 读邮件、读日历、读文件列表，不要上来就发邮件、删文件
最小 Scope只授权当前任务需要的 Gmail / Drive / Calendar 权限
单独账号尽量用测试账号或低权限工作账号验证
人工确认发邮件、改文档、共享文件、创建日程前必须确认
留日志记录每次调用了什么命令、读了什么、改了什么
可撤销写入类操作要优先选择能回滚或低风险的任务

README 里也提醒，这个项目还在 active development，向 v1.0 演进过程中可能有 breaking changes。它还明确写着：这不是 Google 官方支持的产品。

这句话要认真看。

不是说不能用，而是不要把它当成已经稳定多年的企业级产品。

更适合的姿势是：

先把它当成 Agent 办公自动化的实验工具，从低风险、可回放、可人工确认的流程开始。

我会怎么用？

如果我今天要试 gws，不会先让它“帮我管理整个邮箱”。

我会从几个很小的任务开始：

第一，让 Agent 做每日邮件摘要。

只读最近一天未读邮件，按项目分组，输出“需要我处理 / 可以忽略 / 等别人回复”三类。

第二，让 Agent 做会议准备。

读取明天日程，找到会议标题和参与人，再去 Drive 里搜相关文档，最后生成一页准备清单。

第三，让 Agent 做周报素材整理。

从 Calendar 里拉本周会议，从 Drive 里找最近修改的文档，再让我自己确认哪些内容写进周报。

第四，让 Agent 做表格初始化。

比如创建一个项目跟踪表，填好列名和几个初始行，但不自动分享给别人。

这些任务有一个共同点：

读多，写少；可检查，低风险。

这才是 Agent 办公工具比较健康的起点。

真正值得关注的不是这个工具本身

gws 会不会成为长期主流工具，现在还不好说。

它可能继续演进，也可能被 Google 官方能力吸收，也可能变成某些 Agent 平台背后的组件。

但它指向的方向很明确：

当 Agent 要进入真实工作流，办公软件必须提供更适合 Agent 的操作层。

网页 UI 是给人点的。

REST API 是给程序员写代码的。

Agent 需要的是介于两者之间的东西：

  • 比网页稳定；
  • 比 API 易懂；
  • 有清晰 schema；
  • 有可控权限；
  • 能被模型组合；
  • 能被人审计。

命令行、MCP、Skills、结构化输出，本质上都在往这个方向走。

所以这个选题真正有意思的地方，不是一个前 Google 工程师的故事，而是它提前暴露了一个趋势：

AI Agent 越有用，越会碰到办公软件的核心入口。

谁控制这些入口，谁就控制 Agent 能做什么。

最后说一句

以前我们聊 AI 办公，很多时候是在聊“帮我写封邮件”“帮我总结一下文档”。

但 gws 这种工具让问题变了。

它问的是：

如果 AI 不只是生成文字，而是真的能读取日历、搜索网盘、整理邮件、创建表格、发送消息，我们该给它什么权限？

这个问题比 Demo 本身重要得多。

我对 gws 的判断是：

它不是普通效率工具，而是一个很好的 Agent 办公样本。

可以试，但不要裸奔。

先只读，后写入；先个人，后团队；先低风险，后关键流程。

真正的 AI 办公自动化，不是让 Agent 拿到所有权限，而是让它在正确边界里做更多事。

标题备选

  1. Google 员工做了个 AI 办公命令行，火了，然后人没了
  2. 别再让 AI 只会聊天：这个工具让 Agent 开始操作 Gmail 和文档
  3. AI Agent 要进办公室，第一步可能是命令行
  4. 一个 Workspace CLI 为什么会让开发者兴奋，也让大厂紧张？
  5. Gmail、Drive、日历都能给 Agent 调了：Google Workspace CLI 值得看

摘要

Google Workspace CLI gws 最近因为前 Google 工程师 Justin Poehnelt 的故事出圈。但比故事更重要的是它背后的趋势：AI Agent 正在从聊天框走向真实办公系统。它把 Gmail、Drive、Calendar、Docs、Sheets 等 Workspace 能力包装成结构化命令，并提供 Agent Skills，让模型可以更稳定地读取、组合和执行办公任务。

封面文案

主标题：AI 开始操作办公软件
副标题：Google Workspace CLI 值得看

资料来源

别再把资料塞进聊天框了：AI Ag...

评论