177 lines
6.9 KiB
Markdown
177 lines
6.9 KiB
Markdown
# 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` 和清历史文件前，会问一句。
|