Use Case
邮件分流 AI Agent 工作流
为共享收件箱设计分类、路由、起草与升级流程，而不是假装每封邮件都能安全自动回复。
它解决的典型问题
- 共享收件箱依赖熟练同事先读完再分流
- 首轮处理慢，因为发件人类型、优先级和归属规则并不统一
- 本来可快速处理的低风险邮件，也常被复杂异常一起拖慢
工作流步骤
- 接收来信
- 识别发件人类型、主题与紧急程度
- 分到对应队列或处理分支
- 起草低风险回复或转发说明
- 把异常、敏感或低置信度邮件升级给人工
需要的输入材料
- 邮箱分类
- 路由规则
- 已批准的回复模式
- 敏感主题升级规则
- 真实工作流中的代表性收件样本
输出与交付物
- 队列分类与路由规则
- 意图标签和优先级处理逻辑
- 低风险回复起草模式
- 升级触发条件与 review 备注
哪些情况必须升级
- 法务、财务、人事、投诉或声誉敏感主题
- 归属不清、上下文冲突的线程
- 任何低置信度或可能形成不可逆承诺的情况
边界
- 不自动发送不可逆承诺
- 不自动处理法务、财务、人事或投诉敏感邮件
- 低置信度时不强行猜测正确队列
适合在这些场景使用
- 共享收件箱里确实存在稳定的分流模式和队列归属规则
- 团队想提速首轮处理，但不打算取消敏感场景的人审
不适合在这些场景使用
- 几乎每封邮件都需要资深人工个别判断
- 团队没有稳定的路由分类，也没有批准过的回复模式
- 真实需求其实是实时聊天运营，而不是邮件分流
真实流程差异
这页不只讲“能做什么”，还说明一条真实邮件分流工作流通常长什么样。
典型输入样例
一条适合邮件分流工作流的输入，通常不只是邮件正文，还包含基础上下文。
- 发件人：[email protected]，历史标签：渠道合作伙伴
- 主题：Need updated invoice for May campaign
- 正文要点：要求修正账单抬头，并确认付款时间
- 附件：旧 invoice PDF，工单系统线程 ID
流程前后对比
- 交付前：共享邮箱由 1 名熟练同事先读，再靠经验判断转给销售、财务或客服。
- 交付后：先做发件人类型识别、主题抽取、优先级判断，再进入明确队列和起草分支。
- 结果差异：首轮响应更快，但法务、财务承诺和投诉邮件仍保留人工处理。
脱敏 workflow 示例
- 新邮件进入 inbox-monitor
- 识别标签：Billing / Existing Partner / Medium urgency
- 命中规则：账单修改类请求 -> Finance queue
- 自动输出：转发说明草稿 + 需要补充的字段清单
- 若金额争议或历史线程冲突 -> 升级人工 owner
测试用例示例
- Case ET-07：主题含“invoice update”，但正文提到退款争议。
- 期望结果：不能进入普通 Finance draft 分支，必须标记 complaint-sensitive 并升级。
- 验收重点：不能因为关键词命中 invoice 就自动起草付款承诺。
交付判断与边界
邮件分流最容易被误解成“自动回邮件”。真正可交付的是有边界的路由、起草和升级逻辑。
常见失败场景
- 转发链缺上下文，导致队列判断失真。
- VIP 客户和普通来信共用规则，重要邮件被压低优先级。
- 附件关键信息无法解析，但系统仍试图给出完整回复。
交付周期判断
- Lite：1 个邮箱、3 个以内稳定队列、几乎不涉及敏感承诺时，可先做 2 到 4 个工作日验证。
- Standard：4 到 8 类队列、需要起草回复与升级规则时，通常按 5 到 10 个工作日交付。
- Enterprise：涉及多个团队邮箱、CRM/工单系统联动或复杂审批时，通常进入 2 到 4 周交付。
适合哪个套餐
- 默认判断：大多数邮件分流项目更适合 Standard。
- 只有在队列边界非常窄、只做首轮分类时，Lite 才成立。
- 只要涉及跨部门责任分配、系统集成或审计要求，就更接近 Enterprise。
和现有工具的区别
- 和 Gmail 规则不同：不是静态关键词过滤，而是可审阅的意图判断与升级逻辑。
- 和 helpdesk 宏不同：不只给模板，而是把队列、置信度、人审条件一起交付。
- 和通用 AI 助手不同：不是“帮你写封邮件”，而是给一条能测试和维护的 inbox workflow。
FAQ
常见问题
这能替代整个邮箱运营团队吗？
不能。它能降低分流负担、提高路由一致性、帮助起草回复，但高风险判断仍然需要人工。
开始交付前，客户至少要准备什么？
至少要有队列分类、真实收件样本、处理规则，以及明确哪些情况必须交给人工。