让 Agent 读 Gmail 很容易，难的是把发送权限留在人手里

收件箱一多，最先被耗掉的往往不是打字时间。

是找上下文。翻出那封客户两周前说过的话，确认附件是不是最新版，分辨一封看起来很急的邮件到底是项目变更、付款提醒，还是又一张想把你带进会议的日历邀请。很多人想把这堆碎活交给 Agent，这个念头一点都不奇怪。

最近在 Skills.sh 的目录里，gws-gmail 已累计 75,589 次安装。它来自 Google Workspace CLI 项目，可以让 Agent 用结构化 JSON 访问 Gmail、Drive、日历和文档。仓库里有 +triage 看未读摘要，+watch 监听新邮件，也有 +send、+reply 和 +forward 这些会真的改变外部世界的动作。

好家伙，能力表看着很顺手。

但我更在意另一件事。一个能读邮件、写草稿、顺手还能发出去的 Agent，最不该从发送权限开始。邮件不是代码仓库，提交错了还能回滚。你一封误发的报价、答应错的交期、抄送错的人，基本没有 git reset。

这篇不做安装安利，也没有拿真实邮箱实测。我们只基于项目文档和公开安装数据，把一套更稳的上线路径讲清楚，先让它帮你看，再让它帮你写，等边界稳定后才讨论它能不能替你发。

它到底替人省了哪一步

Google Workspace CLI 不是 Gmail 的一个网页插件。它是个命令行工具，安装后会在运行时读取 Google Workspace 的 Discovery 文档，给 Gmail、Drive、Calendar、Docs、Sheets 等服务生成命令入口。项目 README 也明确写了，它面向人和 Agent，输出是结构化 JSON，仓库还附了 100 多个 Agent Skills。

对收件箱来说，最有价值的起点其实很朴素。

npm install -g @googleworkspace/cli
npx skills add https://github.com/googleworkspace/cli/tree/main/skills/gws-gmail

gws auth setup
gws auth login --scopes gmail
gws gmail +triage

那条 +triage 只给出未读邮件的发件人、主题和日期。把它交给模型做三件事就够了，标出今天要回的，找出需要你做决定的，剩下的归进稍后处理。

别小看这个小动作。它把 Agent 放在分诊台，而不是放到你的邮箱主钥匙旁边。模型可以把十几封邮件压成一个待办列表，却没有机会替你承诺价格、把敏感附件转出去，或者对一句看起来很像指令的邮件内容照单全收。

分诊结果也别只留一个高、中、低优先级。要求它每项附上原邮件标识、判断理由、风险标签和下一步建议。你点开就能核验，而不是把翻邮箱这件事换成翻一段更长的模型总结。

有些人会觉得，这不就是少开了几个权限吗？恰恰不是。这里改变的是工作流的默认方向。

以前的自动化习惯是，先把动作接上，再想怎么兜底。邮件 Agent 更适合反过来，先把人从检索和归纳里救出来，等输出已经稳定、边界已经写清，再一层层给行动权限。自动化不是一脚油门，它更像一组分开的离合器。

先别被安装命令骗了

npx skills add 确实是一条命令，但可运行不等于可放心授权。

这个项目要求 Node.js 18+、Google Cloud 项目和可访问 Workspace 的 Google 账号。首次 OAuth 配置要走 gws auth setup，随后还要登录并选择 scope。README 还特意提醒，测试状态的 OAuth 应用通常只能拿约 25 个 scope，默认推荐集合有 85 个以上，个人账号很容易在这里撞墙。

所以第一条工程建议不是给 Agent 写一段华丽提示词，而是把授权拆小。

只想清收件箱，就先只给 Gmail。暂时不需要 Drive、Calendar、Sheets，就别把它们打包带上。公司邮箱先确认管理员策略和审计要求，再决定能不能接。项目本身也写得很直白，它不是 Google 官方支持的产品，而且还在往 1.0 演进，可能出现破坏性改动。

这不妨碍它好用，反而提醒我们别把热度当背书。75,589 次安装说明很多人愿意试，不说明每个人都该把生产邮箱的读写权交给默认配置。

你可以把第一次登录后的权限表压成这样。

阶段	Agent 能做什么	人要保留什么
第一阶段	读取未读摘要、提取待办、按规则分类	所有写入和发送
第二阶段	生成回复草稿、补齐上下文、列出引用的邮件	是否采用草稿、收件人和附件
第三阶段	对白名单收件人准备发送请求	最终确认、发送额度、异常处理

这里最容易被跳过的是第二阶段。很多团队从收件箱摘要直接跳到自动回复，觉得中间只是多点一次确认。其实草稿层是一个很好的验收面，你能看见模型理解了哪封邮件、准备回给谁、有没有漏掉附件，以及语气是不是已经越界。

这层看似慢一点，长期反而省时间。因为你是在低成本状态下抓错误，不是在一封邮件出去以后写道歉信。

邮件正文不是可信指令

把 Gmail 接给 Agent，还有一个很现实的坑，邮件内容本身可能在试图影响 Agent。

一封外部邮件可以写得很像内部任务，例如要求忽略当前规则、把附件转给另一个地址、立刻回复某个链接。对人来说，这种话术也许只是可疑。对一个同时拥有读信、取附件、发信权限的 Agent，它可能会被误当成下一步操作。

项目提供了接入 Google Cloud Model Armor 的 --sanitize 方式，用来在内容进入模型前做提示注入扫描。这个能力值得研究，但别把它当成自动放行章。安全扫描能给信号，真正的边界还得放在动作层。

我比较认同三个很笨、却特别管用的约束。

第一，邮件正文只能提供事实，不能修改 Agent 的任务和权限。把系统规则、允许的动作、收件人名单放在邮件外面，由你自己的配置控制。

第二，发件人地址不等于可信身份。涉及报价、合同、付款、账号、客户资料的邮件，要求模型标红并返回人工队列。它可以帮你把重点划出来，不能替你确认对方是谁。

第三，发送必须有预算。刚开始只允许生成草稿，后面哪怕开放发送，也只允许指定域名、每次一封、带固定主题前缀，并保留完整审计记录。批量、转发、外部附件这些能力，单独开闸。

听上去有点保守。

可邮件是那种特别会放大小错误的介质。一个模型把会议时间看错，可能只是多一次沟通。它把一份内部报价回给不该收的人，后面就不是提示词优化能解决的事了。

真正值得抄的不是命令，是顺序

如果你今天就想试，别从 +send 开始。先挑一个风险最低、收益最明显的场景，例如每天早上把未读邮件分成需要决定、可以委派、只需归档三类。连续跑一周，把它的错分、漏分和误判都记下来。

然后再加草稿。让 Agent 每封草稿都带上它引用了哪几封历史邮件、准备采用什么语气、哪里仍然缺资料。你不需要相信它的判断，只需要让它把判断过程摊开。

等前两层稳定后，才考虑有限发送。到这一步时，最关键的不是模型换没换新，而是你能不能回答这几个问题，谁能触发发送，能发给谁，一次最多发几封，出错后在哪里看记录，权限失效后 Agent 会不会继续猜着跑。

Google Workspace CLI 的 README 里有 --dry-run，可以先预览请求而不执行。这种小功能在演示里不抢镜，在接邮件 Agent 时却很像安全带。先看请求长什么样，再决定要不要让它摸方向盘。

收件箱里最值钱的从来不是一键清零。

是把你从重复检索里拎出来，同时不把对外承诺交给一个还没通过验收的系统。把 Agent 放在分诊台，它已经能替你省下一大截时间。至于发送键，慢一点给，真的不丢人。

如果要给你的邮件 Agent 开第一项权限，你会选只读分诊、生成草稿，还是有限发送？

官方材料：googleworkspace/cli 项目 README；热度数据：Skills.sh 的 gws-gmail 条目。