采购邮件智能体最危险的时刻，通常不是模型写错一句话，而是团队还没有定义它能做什么，供应商就已经拿到了邮箱、CRM、客户数据和发信身份的权限。

这些权限当然可以带来效率。好的系统能够分类来信、起草回复、路由线索、准备跟进、更新CRM，并把异常情况交给人工。但同一套集成也可能制造送达率问题、暴露敏感数据、用错发信身份，或者让团队在事故发生后根本还原不了“为什么会发出这封邮件”。

所以采购问题远不止“哪个模型最聪明”。

在任何供应商或实施伙伴接入生产邮箱之前，先把下面的问题问完。一个成熟的供应商应该用架构、权限、日志和实际流程回答，而不是只给一个漂亮Demo。

1. 智能体到底可以读取什么？

先从数据范围开始。

让供应商逐项列出系统可以访问的对象：

  • 邮件正文；
  • 附件；
  • 联系人记录；
  • 日历上下文；
  • CRM字段；
  • 客服历史；
  • 内部备注；
  • 邮件里的文件链接；
  • 认证token；
  • 发信域名配置。

然后继续问：这是全租户权限、单邮箱权限、单标签权限，还是只开放某个工作流？

一个好的回答应该像：“只读取这个共享邮箱里的邮件，以及CRM里的这几个字段。”

“我们连接你们的工作空间，需要什么就读取什么”，不是好答案。

红旗： 明明工作流很窄，却要求非常宽的权限。

2. 读取、起草和发送能不能拆成不同权限？

“能看邮件”不应该自动等于“能直接发邮件”。

至少要能分别控制：

  • 读取；
  • 分类；
  • 创建草稿；
  • 修改CRM；
  • 排期；
  • 发送；
  • 删除；
  • 归档；
  • 修改标签；
  • 触发其他系统。

高风险流程里，智能体可以准备动作，但不一定能执行动作。

必须问： 能不能让系统自动分类和起草，但“发送”强制需要人工批准？

3. 客户数据存在哪里？保存多久？

你需要的是数据流图，不是一句“企业级安全”。

问清楚：

  • 邮件内容在哪里处理；
  • 日志存在哪里；
  • 保留多久；
  • prompt或邮件内容是否会被拿去训练模型；
  • 备份怎么处理；
  • 客户删除数据后，衍生存储是否同步删除；
  • 有哪些subprocessor。

不同公司、合同和司法辖区的正确答案会不同。采购纪律的重点，是让路径可见、可审计。

4. 用的是哪个模型？供应商能不能不通知就换？

很多邮件智能体会同时编排多个模型。

这未必有问题，但会影响成本、行为、数据处理和可复现性。

问供应商到底采用：

  • 固定单模型；
  • 自动模型路由；
  • 客户自选模型；
  • fallback模型；
  • 本地模型或第三方模型；
  • 自己微调的模型。

然后继续问：模型版本变化时会发生什么？

更成熟的合同应该说明：重大行为变化是否会通知，客户能不能先测试再进入生产。

5. 智能体如何处理“邮件正文里的指令”？

邮件本身是不可信输入。

客户、垃圾邮件发送者甚至攻击者，都可能在正文里写一段看起来像“对AI的指令”。如果智能体把客户内容和内部运营规则混成一层，就可能被操纵。

问供应商如何隔离：

  • 客户内容；
  • 系统指令；
  • 公司内部政策；
  • 工具权限；
  • 检索知识。

NIST 的 Generative AI Profile 很适合作为采购参照，因为它把生成式AI风险看成贯穿设计、部署、监控的管理问题，而不是只问“模型准确率高不高”。

红旗： 供应商全部安全解释只有一句：“模型自己能识别恶意指令。”

6. 我们能不能还原一封邮件为什么会被发送？

你需要审计链。

对于重要动作，系统至少应该记录：

  • 输入事件；
  • 工作流版本；
  • 使用的模型或规则；
  • 检索到的上下文；
  • 建议动作；
  • 审批状态；
  • 最终发信身份；
  • 外部工具调用；
  • 结果或错误；
  • 时间戳。

目标不是要求供应商暴露“模型内部思维”，而是还原运营链条。

客户投诉一封邮件时，团队必须能回答：是谁/什么系统发的、依据哪条规则、用了什么数据。

7. 发信身份怎么保护？

先问智能体能从哪些地方发信：

  • 员工个人邮箱；
  • 共享邮箱；
  • 别名；
  • 交易邮件系统；
  • 营销平台。

然后问系统怎么防止“用错身份”。

Google Gmail 和 Yahoo 的发信要求，让基础设施这一层也非常重要。认证、投诉率和退订机制都会影响送达。邮件智能体不能把deliverability当成上线后的美容问题。

8. SPF、DKIM、DMARC到底谁负责？

不要接受一句“你们IT负责”就结束。

供应商可能不控制DNS，但必须清楚说明它需要哪些配置，以及谁负责验证。

Google 当前 Gmail 指南要求面向个人 Gmail 的bulk sender满足认证和退订等要求，其FAQ也解释了bulk sender识别与spam rate执行。Yahoo同样要求大批量发送者使用更强认证、易退订，并维持较低投诉率。

继续追问：上线以后，谁来验证这些配置真的正常工作？

9. 退订与suppression如何被强制执行？

成熟系统应该有一层“智能体不能随便绕过”的suppression机制。

对于营销邮件，问清：

  • 退订状态存在哪里；
  • 多久同步到所有发送路径；
  • 所有工作流是否强制遵守；
  • 需要时如何处理one-click unsubscribe；
  • 人工能不能误把已suppression的人重新发出去。

美国商业邮件还要关注FTC执行的CAN-SPAM要求，包括真实header、非欺骗subject、可用退订机制以及对退订请求的处理。

但不要把它误解成“CAN-SPAM等于所有冷邮件都天然合法”。不同司法辖区、不同场景规则不同。供应商应该提供合规控制，而不是给一个笼统的法律许可。

10. 投诉率到什么程度会自动停？

Google目前建议bulk sender把用户举报spam rate控制在0.1%以下，并避免达到0.3%或更高。Yahoo 的Sender Hub也把0.3%作为关键要求之一。

所以必须问：

  • 投诉数据能不能进入系统；
  • 能不能自动暂停某个活动或工作流；
  • 谁收到报警；
  • 恢复流程是什么。

一个能自动发数千封邮件的系统，也必须具备在信誉恶化时自动刹车的能力。

11. 智能体“不确定”时会怎样？

最糟糕的回答是：“我们的模型不会幻觉。”

真正该看的是异常策略。

例如：

  • 缺订单号 → 追问；
  • 出现法律威胁 → 升级人工；
  • 退款金额超过权限 → 审批；
  • CRM数据冲突 → 不发送；
  • 附件类型不支持 → 人工处理。

一个真正可用的邮件智能体，必须知道什么时候不应该行动。

12. 人工审批真的无法被绕过吗？

界面里有一个“Approve”按钮还不够。

问审批是否由后端强制执行。工作流更新、API调用、另一个发送路径，能不能绕过审批？

你需要的是权限控制，不是UI习惯。

13. 模板、政策和知识库怎么版本化？

如果周一销售政策发生变化，你必须知道后续哪些邮件还在使用旧版本。

问供应商是否对这些内容保留版本：

  • prompts；
  • 工作流规则；
  • 批准模板；
  • 知识库；
  • 价格表；
  • 升级/转人工策略。

运营系统必须有change control。

14. 真正的单位成本是多少？

不要只看模型token价格。

还要把这些算进去：

  • 平台费；
  • 邮箱/seat费用；
  • 模型调用；
  • 数据补全；
  • CRM自动化；
  • deliverability工具；
  • 实施费用；
  • 人工审批；
  • 日常监控；
  • 异常处理；
  • 错发调查。

便宜模型完全可能运行在昂贵的运营系统里。

15. 如果发送量翻倍，哪里先坏？

在撞上限制之前先问。

需要确认：

  • API配额；
  • 邮箱限制；
  • 队列延迟；
  • 模型rate limit；
  • CRM写入能力；
  • 日志保存量；
  • 人工审批量。

好答案应该包含backpressure和优雅失败，而不是“到时候升级套餐”。

16. 离开供应商时，我们能导出什么？

退出本身就是采购的一部分。

至少问这些能不能导出：

  • 联系人；
  • 邮件历史；
  • 工作流定义；
  • 模板；
  • prompt版本；
  • 审计日志；
  • suppression名单；
  • 绩效指标。

关键状态如果只能留在供应商后台里，切换成本最终会变成运营风险。

17. 出事故时谁负责？

上线之前把升级路径写清楚。

至少覆盖：

  • 意外群发；
  • 凭证泄露；
  • 数据暴露；
  • deliverability崩溃；
  • 用错域名发送；
  • 模型行为事故；
  • 供应商服务中断。

“你们可以联系支持”不等于事故预案。

18. 上线30天以后，什么叫成功？

成熟供应商应该和你一起定义运营指标，而不是只承诺“提高效率”。

一个pilot的评分表可以包含：

  • 草稿接受率；
  • 人工修改率；
  • 首次回复时间；
  • 转人工率；
  • 发送错误率；
  • 投诉率；
  • 退订率；
  • 有效回复率；
  • 单次会话处理成本；
  • 需要人工恢复的事故数。

真正目标不是“让AI多发邮件”，而是减少工作量，同时不制造隐藏风险。

一个简单采购评分表

每家供应商按0–2分打分：

  • 0： 模糊、没有；
  • 1： 有，但依赖人工或限制明显；
  • 2： 系统强制、有观察能力、能导出。

六个类别可以这样加权：

类别 权重
数据与权限 25%
Deliverability与合规控制 20%
审批和异常处理 20%
审计与change control 15%
成本与扩展 10%
可迁移性与事故响应 10%

不要让一个漂亮Demo抵消“权限、suppression或审计为0分”。

邮件智能体一旦能读取客户数据，并通过你的发信身份做动作，它就不再只是写作工具，而是运营基础设施的一部分。

采购时也应该按基础设施的标准来审。

Sources

Related Reading