这套东西跑起来之后是什么样
先说清楚终点，再回头看路怎么走。
跑通之后，你每天打开的不再是几百封未读，而是三个队列：
1. 待确认：智能体已经分好类、拟好草稿，你点「批准」或「改两句再发」。
2. 待人工：置信度不够、或者邮件里出现价格、折扣、合同这类敏感词的，需要你亲自看。
3. 已跟进中：你发出去但对方没回的，系统按天数自动提醒你跟，并帮你把催稿写好。
具体点：客户 A 周五下午发来一封「你们支持私有化部署吗、大概多少钱」，系统判定桶为 customer_inquiry，置信度 0.91，从 FAQ 里检索出两段资料，拟了一封 60 字的草稿：「支持，两种部署方式……价格这块我确认后单独回复你。」周一早上你花 15 秒看一眼，改掉称呼，点发送。同一封邮件进入跟进状态机，第三天没回信，系统给你准备好一封催稿草稿，仍然要你点批准。
全程没有任何一封邮件在你不知情的情况下发出去。这是这类工具能落地的关键——自动化负责跑腿，人负责签字。
下面这套配置和代码是通用骨架，字段名和具体开关以 LaterOn v2 官方文档当前版本为准，不同版本会有差异，照抄前先对照一遍。
前置条件清单
- 一个专用邮箱。建议新开一个子账号或独立邮箱，别拿主力邮箱做第一次实验。
- 邮箱的 IMAP/SMTP 服务已开启。Gmail、Outlook、常见企业邮箱通常需要应用专用密码或 OAuth 授权，开关位置各家不同，以各服务商官方文档当前版本为准。
- LaterOn v2 的工作区已创建，能拿到 API Key 或工作区令牌。
- 一个大模型服务的凭证。如果 LaterOn v2 自带托管模型，可以先用托管模型试跑，跑通再换。
- 一台能跑定时任务的机器：Linux 的 cron、macOS 的 launchd、或任意云函数，选顺手的。
- 会改 YAML/JSON，能看懂一小段 Python。
- 一段不被打断的时间，半小时到一小时。
第 1 步：先建沙盒，权限只给读
这一步最容易被跳过，也最容易出事。
接入邮箱时，只勾选 IMAP 读取权限，不要勾发送权限。等分类准确率稳定了、草稿口吻也对味了，再回头开 SMTP。理由很直接：分类错了只是标签错，草稿发出去就是事故。
如果邮箱服务商支持，建议再开一个「只读」的应用密码，专门给同步用。
第 2 步：把邮箱接入工作区
配置文件大致长这样，注意密码走环境变量或密钥管理，不要明文提交到 Git：
```yaml
lateron/mailboxes.yaml
结构示意，字段名以 LaterOn v2 官方文档当前版本为准
mailboxes:
- id: support
address: you@example.com
protocol: imap
host: imap.example.com
port: 993
tls: true
auth:
type: app_password # 或 oauth2
secret_ref: env:MAIL_PASSWORD # 只存引用，不存明文
folders:
inbound: INBOX
drafts: Drafts
processed: LaterOn/Processed
sync:
since_days: 7 # 试跑期只拉最近 7 天
polling_minutes: 5
```
同步范围先小后大。since_days: 7 是为了第一次跑得快、看得清。等流程顺了再回填历史邮件。
第一次同步完，先别急着写规则，翻十封邮件，看看解析出来的正文对不对、中文主题有没有乱码。
第 3 步：定义「桶」，先少后多
分类体系决定了后面所有事的准确率上限。一开始别设计十几个桶，先定六个：
```markdown
taxonomy.md —— 分拣用的桶
1. customer_inquiry 客户询价 / 售前问题
判断依据：问价格、问功能、问是否支持某场景
期望动作：24 小时内回复，转销售队列
2. existing_customer 已成交客户的需求、故障、续费
判断依据：域名或邮箱在客户名单里
期望动作：优先队列，附上客户卡片
3. partnership 合作、渠道、媒体、投资
判断依据：提到合作、推广、联合、采访
期望动作：转负责人，不要自动回复
4. billing 发票、账单、付款、对账
判断依据：含发票、账单、付款、invoice 等词
期望动作：归档 + 打标签，必要时转财务
5. internal 同事、内部流程、系统通知
判断依据：发件人在自家域名
期望动作：只打标签，不拟稿
6. noise 营销推送、订阅、自动通知
判断依据：含退订链接、批量发信头
期望动作：归档，不通知
```
给每个桶写清两件事：判断依据和期望动作。这两行字后面会直接变成提示词的一部分。花二十分钟把桶定义写清楚，比换个更强的模型有用。
第 4 步：确定性规则优先，模型只做兜底
规则能拦掉相当一部分邮件，而且免费、稳定、可解释。把明显的先拦掉：
```yaml
lateron/rules.yaml
rules:
- name: 账单类自动归档
when:
any_header:
- "From: *@billing.example.com"
- "Subject: *发票*"
then:
bucket: billing
confidence: 1.0
action: label_and_archive
- name: 已知客户
when:
from_domain_in: [customer-a.com, customer-b.com]
then:
bucket: existing_customer
confidence: 1.0
action: route_to_queue
- name: 批量邮件与订阅
when:
any_header:
- "List-Unsubscribe: *"
- "Precedence: bulk"
then:
bucket: noise
confidence: 1.0
action: archive
- name: 兜底交给模型
when: true
then:
action: classify_with_llm
```
顺序很重要：规则从上往下匹配，命中即停。把「已知客户」放在「批量邮件」前面，避免客户用邮件列表发信时被误判成噪声。
第 5 步：让智能体分类，并且逼它说置信度
分类提示词的关键不是写得多华丽，而是强制结构化输出、给几个例子、允许它说「不确定」。
```markdown
你是邮件分拣器。把下面这封邮件归入且只归入一个桶。
可选桶及判断依据：
{{taxonomy}}
示例：
- 「你们这个多少钱？」→ customer_inquiry, 0.9
- 「关于上次的合同续签」→ existing_customer, 0.8
- 「邀请参加行业沙龙」→ partnership, 0.6
- 「本月账单已生成，请查收」→ noise, 0.95
只输出 JSON，不要解释，不要代码块标记：
{"bucket": "...", "confidence": 0.0, "reason": "一句话依据", "needs_human": true}
置信度是你对自己判断的估计，0 到 1。拿不准就给低分，不要凑一个高分。
```
拿到结果后，用置信度做分流：
```python
route.py
def route(email, result, rule_hit):
if rule_hit: # 规则命中，直接采信
return "auto"
score = float(result.get("confidence", 0))
if result.get("needs_human"):
return "review"
if score >= 0.85:
return "auto"
if score >= 0.50:
return "review" # 进人工待确认队列
return "human" # 完全交给人工
```
分类阶段只做可逆动作：打标签、归档、进队列。删除、自动转发到外部地址这类不可逆的事，一律留到人工闸门之后。
第 6 步：让智能体起草，但给它上锁
草稿质量取决于三件事：语气样例、事实来源、明确的禁区。
```markdown
你是 <你的名字> 的邮件助理。请为下面这封来信起草一封回复，供人工审阅。
要求：
1. 用来信相同的语言回复；中文来信就用中文。
2. 三句话以内。先回答对方的问题，再说明下一步。
3. 只使用「背景资料」里的事实。资料里没有的信息——价格、折扣、
交付日期、合同条款、订单状态——写「这块我确认后单独回复你」，
不要推测，不要填占位符。
4. 不要生成任何链接、附件名、账号数字、金额。
5. 不要替发件人做承诺，道歉不超过一句。
6. 输出纯正文，不要主题行，不要署名。
背景资料：
{{retrieved_context}}
来信：
{{email_body}}
```
「背景资料」来自哪里，决定了幻觉有多少。可选来源：产品 FAQ、历史已发送邮件、CRM 里的客户卡片。检索范围越小，编造越少。给模型塞一整本手册，不如塞三段相关段落。
草稿一律落进 Drafts 文件夹，不要直接进发件箱。
第 7 步：跟进——给每封邮件一个状态机
「会跟进」是这个收件箱区别于普通分类器的部分。它靠一个简单的状态机实现：
```yaml
lateron/followup.yaml
follow_up:
states: [waiting_reply, nudged_once, nudged_twice, closed]
transitions:
- from: waiting_reply
after_days: 3
business_days_only: true
action: draft_nudge
to: nudged_once
- from: nudged_once
after_days: 5
business_days_only: true
action: draft_nudge
to: nudged_twice
- from: nudged_twice
after_days: 7
action: close_and_label
to: closed
stop_when:
- reply_received
- auto_reply_detected
- bounce_detected
- thread_closed_by_human
```
几个必须处理的情况：对方的自动回复不算「回信」；退信不算「已读」；有人在会话里被抄送进来，状态要重置。跟进草稿同样走人工闸门——第一次催稿尤其值得你自己看一眼，措辞不合场合会伤关系。
第 8 步：定时任务和静默时间
```bash
crontab -e
每 5 分钟拉一次新邮件并分拣
*/5 * * * * /usr/bin/env python3 /opt/lateron/run_intake.py >> /var/log/lateron-intake.log 2>&1
工作日早上 8:10 生成跟进草稿（只落草稿箱，不发送）
10 8 * * 1-5 /usr/bin/env python3 /opt/lateron/run_followups.py --business-days-only >> /var/log/lateron-followup.log 2>&1
每天 18:00 汇总当天未处理的待确认项
0 18 * * * /usr/bin/env python3 /opt/lateron/digest.py >> /var/log/lateron-digest.log 2>&1
```
静默时间单独配一条：22:00 到次日 08:00、以及周末，只生成草稿不发送。深夜发出的催稿邮件，即使内容再客气，观感也不对。时区和节假日一起判断，别只减 8 小时。
第 9 步：人工确认闸门
这是整套流程的签字台。每条待确认卡片上放四样东西：分好的桶、置信度、草稿正文、三个按钮（批准发送 / 编辑后发送 / 丢弃）。
批准后才真正调 SMTP，同时把草稿移出 Drafts，并记一条审计日志：
```python
audit.py（结构示意）
log_entry = {
"message_id": email["message_id"],
"bucket": result["bucket"],
"confidence": result["confidence"],
"action": "approved", # approved / edited / rejected
"edited": True,
"diff_ratio": 0.18,
"approved_by": user_id,
"approved_at": now_iso(),
}
```
被改动的部分是最值钱的训练材料。如果十个草稿里有八个都被你删掉同一句「感谢您的耐心等待」，那句话就该从提示词里拿掉。每周花十分钟翻一遍 diff 比例高的草稿，改提示词，比换模型见效快。
第 10 步：影子模式先跑一周
上线第一周，只分类和起草，不发送任何东西，连跟进也只在内部看板展示。然后对比：你人工判断的桶，和智能体判断的桶，对不上的有多少。
根据经验，容易出错的是这两组边界：「客户询价」和「合作意向」（对方既问价又谈合作），「已有客户」和「新客户」（同一家公司换了个人来问）。看到这类错误，就回去补 few-shot 例子，而不是调低阈值放过去。
常见坑与排错
1. 授权失败或授权过期。 OAuth 的刷新令牌会失效，应用专用密码在开启两步验证后需要重新生成。日志里搜 AUTH、LOGIN 关键字，多数是凭证问题而不是网络问题。
2. 中文主题乱码。 邮件头里的中文是 MIME encoded-word 编码（形如 =?UTF-8?B?...?=），必须解码后再喂给模型，否则分类基本全错。正文如果是 multipart，要挑 text/plain 优先，没有再用 HTML 转纯文本。
3. 同一封邮件被处理多次。 用 Message-ID 做幂等键，维护一张已处理表，重复同步时跳过。否则你会收到三份同样的草稿。
4. 回复跑成新会话。 发送草稿时要带上 In-Reply-To 和 References 头，主题保留 Re: 前缀。少了这两个头，对方邮箱会把回复拆成独立的一条线，跟进状态机也会跟着乱。
5. 自动回复引发死循环。 检测 Auto-Submitted、X-Autoreply 这类头，命中就不触发跟进，也不触发自动回复。
6. 半夜发信。 时区、工作时段、节假日要一起判断。注意有些邮箱服务端以 UTC 记录时间，别直接拿来和人看的钟点比。
7. 模型编造价格和交期。 提示词里明确禁止只是第一层，建议事后再加一层关键词扫描：草稿里出现「报价」「折扣」「合同」「天内交付」等词，直接标高亮，强制人工逐字看。
8. 退信率上升。 批量跟进有被判定为骚扰的风险。控制频率，监控退信和投诉，同一收件人短期内不要重复催。
9. 隐私与合规。 邮件正文可能包含个人信息、附件合同、客户名单。把哪些桶允许送到外部模型、哪些只走本地规则，提前定清楚，别等出事再补。
10. 首次同步拖慢系统。 试跑期限定同步天数，跑顺了再回填历史。全量拉取几千封邮件再逐封调模型，账单和等待时间都会让你后悔。
下一步建议
链路跑通、准确率稳定之后，可以按这个顺序加东西：
- 回写业务系统：把分拣结果和跟进状态写进 CRM 或工单系统，让邮件线索不再只活在收件箱里。
- 草稿里加预约入口：先检测语言和时区，再插入可预约时段，减少来回确认的轮次。
- 多语言模板：先做语言检测，再选对应的语气样例。中英混写的邮件单独归类。
- 看四个指标：首次响应时间、草稿采纳率、跟进回复率、误分类率。每周看一次，别天天看。
- 把编辑记录回灌提示词：定期从「编辑后发送」的记录里挑出高频修改，变成新的 few-shot 例子。
- 扩到第二个邮箱：桶和规则直接复用，只改接入配置和客户名单。
一句话收尾：先用一周影子模式把分类和口吻调顺，再打开发送权限。智能体负责跑腿，键盘最后的那个回车，留给人。