两周前，Readdle旗下的邮件应用Spark完成了一次不太寻常的更新。它没有改界面，也没加什么滤镜，而是给Mac版本装了一个命令行工具（CLI），同时开放了一套"代理技能"——Claude Code、Codex这类终端AI代理现在可以只读访问你的邮件、日历事件、联系人和会议笔记了。没过几天，这套功能又追加了邮件分类操作等更多能力。
这个设计的巧妙之处在于本地架构：你的邮件数据留在Mac上，同时对AI代理可见。
CLI正在成为今年生产力应用的热门趋势，一大批工具都在跟进。原因很实际：像Claude Code、Codex这类在终端运行的代理，可以直接调用本地CLI。这让token消耗大幅降低——代理只接收命令的文本输出，而不像MCP服务器那样需要随身携带工具模式（tool schemas）。
邮件CLI并非Spark首创。Google曾推出过一个叫googleworkspace的CLI，由官方团队开发但标注"非正式产品"，它能对接Gmail和多项Google服务，提供超过100项技能。两者的关键区别在于：googleworkspace CLI连接的是Google的云端服务器，直接在云上操作你的邮件；而Spark的CLI更像是Spark应用本身的遥控器，在Mac本地管理邮件，再通过桌面应用同步回Gmail。
我实际用过这两款CLI，Spark的上手难度明显更低——不需要搭建Google Cloud项目，也不用折腾OAuth授权。唯一的限制是Spark应用必须保持开启，因为所有操作都在本地完成。不过说实话，这算不上什么障碍：当你想用CLI或代理技能处理邮件时，邮件应用本来就会开着。
Spark的功能分为两个层级。只读CLI和技能对所有用户开放，无论是否订阅Spark Pro。这些操作包括搜索和总结邮件、获取上下文、阅读对话线程、查看日历、联系人和会议笔记。Pro订阅则额外解锁邮件起草、回复、稍后处理、置顶、标签、移动和归档，以及团队评论功能。这套指令集的语法与Gmail类似，对老用户来说几乎没有学习成本。
Readdle还发布了一套开源的"配方"（recipes）和"角色"（personas）。配方是针对具体场景的指令集，比如晨间和晚间邮件回顾、新发件人筛查、假期后邮件追赶等。角色则是更完整的收件箱处理策略，覆盖整个邮件会话并带有不同模式。例如"创始人"角色包含快速分类、激进委派、跨团队监督三种模式；其他角色还有执行助理、自由职业者、团队负责人等。每项配方和角色的完整细节都在Readdle的GitHub页面公开。
我花了一些时间实际使用这些功能，体验相当流畅。本地架构带来的隐私安全感是真实的——你的邮件不会为了配合AI而先上传到某个第三方服务器。代理请求通过CLI直达本机Spark，处理完再按需同步，这个链路比云端方案短得多。
不过这也引出一个值得观察的问题：当AI代理越来越深地嵌入日常工作流，"本地优先"会不会成为新的竞争壁垒？Spark的选择是把数据留在用户设备上，换取信任和更低的配置门槛；Google的方案则依托云端生态的广度。两种路径各有代价，也各自对应不同的用户场景。
对普通用户来说，Spark的门槛确实低得多。不需要开发者背景，不用读OAuth文档，安装完应用、打开终端就能开始。这种"开箱即用"的体验，可能是CLI从极客工具走向更广泛用户群的关键一步。
Readdle把配方和角色开源的做法也很有意思。这相当于把"怎么让AI帮你处理邮件"的方法论公开，让用户和社区可以迭代优化。比起封闭的黑箱功能，这种开放性反而可能加速功能本身的进化——毕竟邮件处理的高度个性化，很难靠一家公司穷举所有场景。
目前这套系统的边界也很清晰：只读功能免费，涉及"写"的操作需要付费。这个分层策略既降低了尝试门槛，也给深度用户留了升级路径。对于已经习惯用Claude Code或类似工具的人来说，能在终端里直接调取邮件上下文，意味着工作流的进一步整合——不用切换窗口、不用复制粘贴，一句话就能让AI基于你的实际邮件内容给出建议。
邮件客户端这个品类已经沉寂多年，Spark这次更新提供了一种新的解题思路：不做更大的收件箱，而是让它更容易被自动化工具调用。当AI代理成为新的交互层，应用本身或许正在从"目的地"变成"基础设施"——用户不再打开Spark来发邮件，而是让代理在需要时调用Spark的能力。
这个转变的 implications 还很难说清。但至少现在，对于每天被邮件淹没、又已经在用终端AI工具的人来说，Spark的CLI提供了一个相当务实的选择：数据留在本地，配置成本极低，功能覆盖从只读浏览到深度处理的全链条。剩下的问题可能是：其他邮件应用会不会跟进，以及"本地CLI+开源技能"会不会成为这一品类的标准配置。
热门跟贴