AI邮件agent实现95%自动化：工作流委托而非起草邮件

我原本以为 AI agent 处理邮件任务意味着更好的草稿，但这家挖掘机公司的 5% 收件箱让我改变了看法

我原本预期在 Reddit 帖子里看到的是常见的邮件自动化故事：

Gmail 收到新邮件 GPT-5 写出一条像样的回复 大家都称之为"AI 自动化" 人类仍然承担真正的工作

结果，我发现了更好的东西。

在一个 r/openclaw 的帖子里，一位运营挖掘机公司的老板描述了一套收件箱设置，其中只有大约 5% 的邮件仍需要独特的个人操作。其他一切都被路由到运营状态，如 REVIEW（待审）、ACTION（待办）和 WAITING（等待）。

这不是"AI 写邮件"。

这是工作流委托。

而我认为大多数开发 AI 邮件系统的工程师瞄准了错误的目标。

邮件的真正瓶颈不在于写作

一份漂亮的草稿很不错。

但大多数企业收件箱失败的原因并非人们打字不够快。

它们失败是因为每封收到的邮件都会产生一个决策：

这条应该自动回复吗？ 应该变成一个任务吗？ 应该升级吗？ 应该更新 CRM 吗？ 应该发送到调度吗？ 应该等待后续吗？ 需要人类在任何操作之前先审阅吗？

如果你的自动化止步于"保存草稿"，困难的部分仍然是手动的。

这就是挖掘机公司设置引人注目的原因。这位运营商描述了一个包含以下内容的系统：

两个 Google Workspace 收件箱 一个具备公司和个人上下文的 OpenClaw agent 最初为 VA（虚拟助理）编写的规则 垃圾邮件和日常消息的过滤 一个 ACTION 文件夹，用于 agent 无法完全处理的事项 一个 WAITING 文件夹，用于已发送需要跟进的消息 一个 REVIEW 路径，用于需要独特人类判断的小部分邮件

这个架构比我见过的大多数 AI 邮件演示更有用。

把 Gmail 当作状态机，而非邮箱

如果你在构建这种流程，Gmail API 实际上比大多数人意识到的更好。

很多团队仍然把 Gmail 当作一个读取文本的地方，也许还能保存草稿。

这就浪费了很多杠杆。

你可以将收件箱处理建模为状态转换。

这给你的是一个操作队列，而非"未读但可怕"。

订阅收件箱变更

Gmail 支持使用 users.watch 进行推送通知：

POST https://gmail.googleapis.com/gmail/v1/users/me/watch
{
  "topicName": "projects/myproject/topics/mytopic",
  "labelIds": ["INBOX"],
  "labelFilterBehavior": "INCLUDE"
}

你会得到一个 historyId 和过期时间戳。

过期时间很重要。Watch 是可续期的，这意味着你的集成应该像服务一样运行，而非一次性设置脚本。

将标签更新为工作流状态

一旦对消息进行了分类，就更新标签：

POST https://gmail.googleapis.com/gmail/v1/users/{userId}/messages/{id}/modify
{
  "addLabelIds": ["Label_Action", "Label_Waiting"],
  "removeLabelIds": ["INBOX"]
}

这就是核心原语。

不是生成草稿。

Google 允许你在一次调用中添加和删除很多标签，这对于现实世界的分类系统已经足够。

如果收件箱很重要，就不要每小时轮询

Reddit 设置使用了每小时 cron 任务，这是合理的。Cron 简单可靠。

但如果你在构建常驻 agent，轮询通常不是正确的默认选择。

基于推送的摄入更清晰：

Gmail users.watch 将收件箱变更发布到 Cloud Pub/Sub 你的 webhook 或订阅者接收事件 你获取变更的消息或会话 你对意图、紧急程度、所有权和下一步操作进行分类 你触发下游系统 仅在置信度低或需要授权时才通知人类

这就是我所说的真正的 AI agent 任务完成。

不是"在 Gmail 里写一条礼貌的回复"。

一个实用的架构

这是我现在会构建的版本。

Gmail API 用于摄入和标签更新 Cloud Pub/Sub 用于推送事件 OpenClaw、n8n、Make 或 Zapier 用于编排 Slack / Asana / HubSpot / Salesforce / 内部工具用于下游操作 LLM 用于分类、摘要和回复生成

Gmail 收件箱变更
  -> Pub/Sub 事件
  -> 获取消息/会话
  -> 分类：意图、紧急程度、所有者、下一步
  -> 应用 Gmail 标签
  -> 触发下游系统
  -> 可选地起草回复
  -> 如需要则通知人类

那个状态模型才是杠杆所在。

OpenClaw 有趣在于它位于收件箱之上

引发这个话题的是关于 OpenClaw 的讨论，我认为有用的收获是：

OpenClaw 不仅仅是一个邮件起草工具。

它是一个编排层。

这很重要，因为当 agent 具备以下能力时，邮件自动化会变得更好：

触发下游操作的能力

帖子里有一句话一直留在我脑海中：这位运营商有一个独立 agent，拥有完整的公司和个人上下文，正在读取邮件账户。

这正是玩具演示和可运营系统之间的区别。

如果你把 GPT-5、Claude Opus 4.6、Grok 或任何其他模型放进一个收件箱，只有弱指令和没有业务记忆，它绝对会自信地犯错。

模型不是系统。

下游集成

OpenClaw 恰好是构建该系统的一种方式。

如果你刚开始上手，设置出奇地直接：

openclaw onboard

仅此一项不能解决邮件问题。但它指向了正确的抽象：agent 编排，而非仅仅是草稿生成。

草稿仍然有用。它们只是不是主场景。

有很多工作流，措辞才是瓶颈：

企业销售跟进 敏感的客服案例

在这些情况下，来自 GPT-5 或 Claude 的强草稿已经值回票价。

但如果你止步于此，你自动化的只是打字，而非运营。

更好的成熟度模型是这样的：

阶段 1：草稿辅助

使用 ChatGPT、Claude 或 Gemini 减少写作时间。

阶段 2：分类

添加意图检测、紧急程度评分和标签。

将消息转化为分配、审批、等待状态和升级。

阶段 4：跨系统操作

自动更新 Slack、Asana、HubSpot、Salesforce、调度软件或内部数据库。

大多数团队在阶段 1 庆祝。

挖掘机公司的设置已经更接近阶段 3 在运营。

这就是它有趣的地方。

生产环境中什么先出问题：上下文

这个设置有效的原因是这位运营商已经有一套为 VA 编写的规则。

这意味着已经有人完成了定义：

什么算作日常 什么需要升级 什么需要所有者判断 什么应该自动回复

如果你跳过这个设计步骤，你的系统不会只是生成糟糕的文本。

它会错误地路由工作。

一份糟糕的草稿可以被编辑。

一次糟糕的路由决策会悄悄地赔钱。

供应商请求被埋进 WAITING 客户问题永远不会被升级 报价请求在 REVIEW 里放太久 调度问题被标记为正常对话

这就是为什么我在上线任何这类系统之前会坚持这三件事。

1) 设计真实的状态

不要使用模糊的标签，如：

使用映射到实际业务操作的标签：

如果一个标签不暗示接下来会发生什么，它就不是一个有用的状态。

2) 建立明确的升级规则

低置信度决策需要立即有人类处理路径。

if confidence < 0.82:
  route: REVIEW
  notify: owner

if intent == "billing_dispute":
  route: ESCALATE
  notify: finance_lead

if intent == "field_schedule_change":
  route: DISPATCH
  notify: ops_channel

你需要对风险情况做出确定性处理。

可观测性不是可选项。

为什么一条消息被如此分类 应用了哪些标签 触发了哪些下游系统 人类是否覆盖了决策 涉及哪些提示词、规则或工具

如果你的 agent 在处理业务关键邮件，沉默失败是不可接受的。

最小实现草图

这是一个 webhook 消费者的粗略 Node 风格流程：

async function handleGmailEvent(event) {
  const message = await fetchChangedMessage(event.historyId)

  const classification = await classifyMessage({
    subject: message.subject,
    body: message.body,
    thread: message.thread,
    customerContext: await getCustomerContext(message),
    businessRules: await getBusinessRules()
  })

  if (classification.confidence < 0.82) {
    await applyLabels(message.id, ["REVIEW"], ["INBOX"])
    await notifySlack("owner-review", {
      messageId: message.id,
      reason: classification.reason,
      summary: classification.summary
    })
    return
  }

  switch (classification.route) {
    case "WAITING":
      await applyLabels(message.id, ["WAITING"], ["INBOX"])
      break
    case "ACTION":
      await applyLabels(message.id, ["ACTION"], ["INBOX"])
      await createTaskInAsana(classification.task)
      break
    case "DISPATCH":
      await applyLabels(message.id, ["DISPATCH"], ["INBOX"])
      await sendToDispatchSystem(classification.dispatchPayload)
      break
    default:
      await applyLabels(message.id, ["REVIEW"], ["INBOX"])
  }

  if (classification.replyDraft) {
    await saveDraftReply(message.threadId, classification.replyDraft)
  }
}

这是我希望更多"AI 邮件"产品能展示的模式。

const draft = await llm.generateReply(email)

如果你在规模化运行这个，Standard Compute 的位置

这种工作流用 naive 的方式会很快变得昂贵。

不是因为一份草稿贵。

而是因为生产邮件 agent 做的不仅仅是起草：

对每条入站消息进行分类 在需要时起草回复 在路由分支中调用多个提示词

这正是按 token 定价变得烦人的地方。

特别是如果你在 n8n、Make、Zapier、OpenClaw 或你自己的 worker 中 24/7 运行 agent。

你开始围绕成本而非可靠性进行优化。

这就是为什么我认为固定月费推理比传统 token 计费更适合自动化工作负载。

Standard Compute 就是为这个特定问题构建的：

OpenAI API 兼容 与现有 SDK 和 HTTP 客户端配合使用 固定月费而非按 token 计费 适用于常驻 agent 和自动化 跨模型动态路由，如 GPT-5.4、Claude Opus 4.6 和 Grok 4.20

如果你的邮件管道在做真正的编排而非一次性的提示词，可预测的成本比人们承认的重要得多。

挖掘机公司故事最有趣的部分不是"AI 写出了好邮件"。

这个我们早就知道了。

有趣的是只有大约 5% 的消息仍需要独特的人类操作。

这意味着这个系统做到了大多数邮件自动化遗漏的事情：

起草只是工作流的一个输出。

而非工作流本身。

如果你在构建 AI 邮件系统，我认为这是更好的问题：

"当一条消息到达时，它应该进入什么状态，谁拥有它，什么系统应该改变，如果没有人响应会发生什么？"

这比"生成一条回复"更不花哨。

但这也是让你获得真正运营收益的问题。