为什么业务 Agent 不应一开始自动发邮件

01核心判断CORE JUDGMENT

业务 Agent 的早期价值，不在于把邮件链路完全自动化，而在于帮助人更快看清：这封邮件属于什么任务、缺少什么信息、可能触发什么风险、下一步应该由谁确认。自动发送是一个对外动作，生成草稿只是一个候选输出。两者之间隔着责任、语境、事实核验和组织授权。

所以第一版业务邮件 Agent 更合理的目标是 decision support：分类、摘要、缺失信息提示、风险标记、回复草稿和人工审核队列。它可以降低阅读和整理成本，但不直接替代人完成外部承诺。

这个判断不是反对自动化，而是反对把自动化放在最容易出事的位置。真正成熟的业务自动化通常先稳定输入、规则、审核和反馈，再逐步减少人工动作。邮件场景尤其如此，因为它既包含自然语言，也包含关系、承诺、时效和语气。

邮件不像内部便签。它通常会进入对方的收件箱，形成可转发、可截图、可引用的记录。一次错误发送可能不是简单的"模型答错"，而是对事实、承诺、价格、时间、权限或语气的错误表达。对于业务场景，这类错误会带来信任成本。

风险并不只来自模型幻觉。更常见的问题是上下文不完整：邮件线程缺少附件、前置沟通不在同一线程、审批口径在别处、某些词在不同关系里含义不同。Agent 即使写出流畅文本，也不代表它知道哪些内容可以承诺，哪些内容只能询问，哪些内容需要升级给负责人。

还有一种风险是"沉默的错误"。系统没有报错，邮件也成功发出，但某个条件被省略、某个限制没有写清、某个语气显得过度确定。收件人看到的是最终文本，不会知道系统当时缺了哪些上下文。因此，发送前的确认不是低效率环节，而是风险控制的一部分。

很多原型会先展示一个很顺滑的能力：输入邮件，模型生成回复。这个演示容易让人误以为系统已经具备自动回复条件。实际上，生成能力只证明模型能写一段像邮件的文本，不证明它能承担发送动作。

业务邮件里真正难的部分往往不是措辞，而是判断：是否已经掌握事实，是否需要补问，是否涉及敏感条款，是否应当保留模糊空间，是否需要引用历史约定。把"能写"直接升级成"能发"，会把最需要人确认的责任环节藏起来。

另一个误区是只用"准确率"讨论发送权。即使大多数邮件可以被正确处理，少数高影响邮件仍然需要被识别和拦截。业务系统不能只追求平均表现，还要处理尾部风险：低频、复杂、影响大的任务，往往决定了系统是否可信。

更好的 v1 是一个审核前工作台。Agent 先读取邮件主题、正文和必要的元信息，给出任务分类，例如咨询、跟进、交付确认、资料补充、风险提醒。随后生成摘要，标出缺失条件，列出建议动作，并生成一版可编辑草稿。

草稿应当默认处于未发送状态。人可以接受、修改、退回或标记风险。系统记录这次判断：为什么建议这样回复、哪些信息尚未确认、谁做了最终确认。这样 Agent 的输出不是黑箱，而是可复盘的协作过程。

界面上也应避免把"发送"做成最显眼的默认动作。更合理的主动作是"进入审核""复制草稿""标记缺失信息"或"升级处理"。这些动作虽然不炫目，但更适合第一版上线验证：它们能快速证明 Agent 是否真的减少了整理成本，而不是提前承担外部后果。

责任边界要在产品里显式出现，而不是只写在文档里。Agent 负责整理和建议；审核人负责确认事实、语气和权限；发送人负责最终动作；业务负责人承担对应后果。这个边界看似保守，但它能防止系统在最脆弱的阶段过度承诺。

如果团队还没有稳定的分类规则、升级规则和审核记录，就不应该把发送权交给 Agent。自动化可以逐步增加，但每一步都应有明确的回退路径和人工接管点。

责任边界还需要体现在日志里：谁确认了草稿，谁修改了关键句，谁决定暂缓，谁把任务升级。没有这些记录，后续复盘只能停留在"模型当时为什么这样写"的猜测。对业务 Agent 来说，复盘能力本身就是产品能力。

一个可发布的最小闭环可以很简单：收件进入队列，Agent 生成分类、摘要、缺失信息和草稿；人审核并选择发送、修改、搁置或升级；系统保存最终动作和反馈。下一次同类任务出现时，Agent 参考经过确认的结构，而不是直接学习未审核输出。

这个闭环的价值在于把不确定性留在系统内部，把确定后的动作交给人。它让团队先获得效率收益，同时保留审计能力。

闭环的评估指标也应克制。第一阶段可以看摘要是否减少阅读时间、缺失信息提示是否有用、草稿是否减少重复写作、人工修改集中在哪些位置。不要一开始就用"自动回复多少封"作为核心指标，否则系统会被推向错误方向。

当审核记录足够稳定后，可以逐步放开低风险动作。例如自动打标签、自动提醒超时、自动补齐常见问询模板、自动生成多语言草稿。再进一步，某些低风险、强模板、可撤回的通知可以考虑半自动发送，但仍应保留规则、日志和人工覆盖。

更高等级的自动化不是第一版目标。它应该来自长期验证，而不是来自一次看起来流畅的模型演示。

如果未来要扩大自动化范围，应该先定义哪些任务永远需要人工确认，哪些任务可以半自动，哪些任务只允许内部提醒。这个分层比"开或关"更重要。成熟路线不是一次性替代人，而是在可验证的边界内逐步减少低价值操作。