# Session: 2026-03-04 23:21:19 UTC

- **Session Key**: agent:main:main
- **Session ID**: e13af1cd-cbea-417b-bb27-27de07f0937d
- **Source**: telegram

## Conversation Summary

assistant:   
assistant:  这是我的理解：

**核心概念**
这个系统用"学习"的方式帮你自动处理邮件——不是静态规则，而是观察你的决策后逐渐模仿你的偏好。它把两个事分开：LLM 负责**分类**（这是什么类型的邮件），历史数据负责**置信度判断**（你以前怎么处理这类邮件）。

**工作流程**
1. 扫描时，LLM 给每封邮件打标签（比如 `promotion`、`shipping`、`security`）并建议操作
2. 系统用 `(发件人邮箱 + 标签组合)` 作为签名，在历史记录里找匹配
3. 如果没匹配或置信度<85%，邮件进入待审队列；够高就直接执行

**学习机制**
- 每封邮件的置信度取决于"有多少次相同发件人+相似标签的邮件被你执行过同样操作"
- 要达到85%自动处理，需要至少9次一致的决策
- 你的每次手动审批（通过 `review` 命令）都会追加到历史，让系统更懂你的习惯

**标签体系**
21个固定标签（`receipt`、`promotion`、`notification` 等），用来区分同个发件人但是不同类型的邮件（比如密码重置 vs 促销邮件都发自同一服务）。

简单说：它不是一个"按规则过滤"的垃圾邮件系统，而是一个观察你、学习你、渐渐替你干活的助手。

有具体想问的部分吗？
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "1777",
  "sender_id": "8481137853",
  "sender": "8481137853"
}
```

好，所以你知道大致的用法吗
assistant:   
assistant:  知道，用熟了的话应该是这样的：

**日常用法**
```bash
# 跑扫描（cron 会自动做）
./email-processor.sh scan              # 扫未读邮件
./email-processor.sh scan --recent 7   # 只扫最近7天的

# 检查待审队列（每天早上看一眼）
./email-processor.sh review list

# 处理队列里的邮件
./email-processor.sh review 1 delete      # 同意第1封，删掉
./email-processor.sh review all archive   # 全部归档
./email-processor.sh review accept        # 按AI建议批量执行（懒人式）

# 看效果
./email-processor.sh stats                # 看看自动化率到多少了
```

**关键理解**
- `--dry-run`：测试用，只分类不执行，安全得很
- `accept` vs 手动指定动作：Accept 是按 AI 建议执行；手动覆盖（比如 AI 建议 archive 你偏要 delete）也是允许的，会记录你的实际选择
- review 队列里的编号是临时的，每次 `list` 可能会变，但邮件 ID（msg_xxx）是固定的

**实际场景**
比如今早 cron 跑了扫描，我一执行 `review list` 看到：
```
1. LinkedIn - 建议 delete (50%)    ← 不认识，排队了
2. Amazon shipping - 建议 archive (65%)  ← 也不太确定，排队了
```

然后要我手动批，批完系统就记一笔。以后遇到同样的发件人+标签组合，置信度慢慢涨上去，总有一天 LinkedIn promotion 邮件会直接消失，不用我操心。

**问一句**：你现在有配置好吗？需要我帮你跑个 `--dry-run` 看看最近的邮件会被怎么分类？
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "1780",
  "sender_id": "8481137853",
  "sender": "8481137853"
}
```

这个scan已经设置了cron了对吧？
assistant:  是的，根据我的记忆，配置了：
- **每天 08:30** 和 **17:00**（PST）运行 `scan`

要我帮你确认一下实际配置吗？可以检查：

```bash
openclaw status                    # 看 cron 任务列表
# 或
cat ~/.openclaw/crontab           # 直接看 cron 配置
```

如果你想调整时间或者加上 `--recent` 参数（比如只扫当天），跟我说。
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "1783",
  "sender_id": "8481137853",
  "sender": "8481137853"
}
```

不用了，还有一点，你知道怎么更新标签吧？
assistant:   
assistant:   知道，标签定义在 `classifier.py` 第28行的 `TAG_TAXONOMY` 列表里。

**加标签**（安全）：
直接编辑那个列表，加进去就行。新标签会立刻可用。

**改/删标签**（会破坏历史）：
- **不要重命名或删除**旧标签——会导致历史记录里的 `(sender_email, tags)` 签名匹配不上，置信度计算失效
- 如果必须重命名，**同时保留新旧两个标签**在列表里

**什么时候该加标签**：
检查发现某个发件人的邮件经常被分到不同操作（比如有的 delete 有的 keep），但现在它们共享一个大而模糊的 tag（比如都只有 `notification`）。这时候加个更细的 tag（比如 `security` vs `promotion`）能让系统区分对待。

要我现在帮你加一个吗？
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "1786",
  "sender_id": "8481137853",
  "sender": "8481137853"
}
```

关于标签更新的说明我大概写了一下，你重新看一下README
assistant:   
assistant:   看到了，关于"Refining the Tag Taxonomy"的新章节。写得很详细，我理解的核心：

**什么时候要调整标签**
- 某个发件人审了10+次还是排队（置信度上不去）
- 同个发件人历史里既有 delete 又有 keep（标签没区分对）
- LLM 打的标签太抽象、匹配效果差

**7步流程**（从发现问题到解决）
1. 找出那些"操作不一致"的发件人
2. 对比那些邮件（主题、摘要、现有标签）看哪里该区分
3. 判断是不是缺个标签，还是现有的标签 LLM 没用好
4. 验证新标签：够独特、能复用、不和现有标签混淆
5. 往 `TAG_TAXONOMY` 里加
6. 决定要不要清空历史（1-2个标签不用清，3+个标签或大规模改动建议清）
7. `--dry-run` 跑验证

**关键规则**
- 只增不减不重命名（历史兼容）
- 20-30个标签左右就够了，多了 LLM 反而乱选

这个流程挺实用的。不过第6步"清历史"我可能会再犹豫一下——一旦清了就得重新攒9个样本，如果是高频发件人（比如每天一封促销的）还好，低频的（比如每月一封账单）可能得等大半年。

我理解得对吗？
user: Conversation info (untrusted metadata):
```json
{
  "message_id": "1789",
  "sender_id": "8481137853",
  "sender": "8481137853"
}
```

理解的对，所以你以后知道怎么更新标签了吧？
assistant:       知道了——需要时我会按那个7步流程来：
    1. 从 `stats` 或日志里找"不一致操作"的发件人
    2. 对比 `decision_history.json` 里的条目，看标签有没有正确区分
    3. 确定是真正缺标签，还是只是LLM没用好现有的
    4. 确保新标签不与现有重叠
    5. 往 `classifier.py` 的 `TAG_TAXONOMY` 里加
    6. 小规模加不用清历史，大规模变动需要清
    7. `--dry-run` 验证后再动手

    涉及改 `classifier.py` 和清历史文件前，会问一句。