6.9 KiB
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 负责分类（这是什么类型的邮件），历史数据负责置信度判断（你以前怎么处理这类邮件）。
工作流程
- 扫描时，LLM 给每封邮件打标签（比如
promotion、shipping、security）并建议操作 - 系统用
(发件人邮箱 + 标签组合)作为签名，在历史记录里找匹配 - 如果没匹配或置信度<85%，邮件进入待审队列；够高就直接执行
学习机制
- 每封邮件的置信度取决于"有多少次相同发件人+相似标签的邮件被你执行过同样操作"
- 要达到85%自动处理，需要至少9次一致的决策
- 你的每次手动审批（通过
review命令）都会追加到历史，让系统更懂你的习惯
标签体系
21个固定标签（receipt、promotion、notification 等），用来区分同个发件人但是不同类型的邮件（比如密码重置 vs 促销邮件都发自同一服务）。
简单说：它不是一个"按规则过滤"的垃圾邮件系统，而是一个观察你、学习你、渐渐替你干活的助手。
有具体想问的部分吗？ user: Conversation info (untrusted metadata):
{
"message_id": "1777",
"sender_id": "8481137853",
"sender": "8481137853"
}
好，所以你知道大致的用法吗
assistant:
assistant: 知道，用熟了的话应该是这样的：
日常用法
# 跑扫描（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：测试用，只分类不执行，安全得很acceptvs 手动指定动作：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):
{
"message_id": "1780",
"sender_id": "8481137853",
"sender": "8481137853"
}
这个scan已经设置了cron了对吧？ assistant: 是的，根据我的记忆，配置了：
- 每天 08:30 和 17:00（PST）运行
scan
要我帮你确认一下实际配置吗？可以检查：
openclaw status # 看 cron 任务列表
# 或
cat ~/.openclaw/crontab # 直接看 cron 配置
如果你想调整时间或者加上 --recent 参数（比如只扫当天），跟我说。
user: Conversation info (untrusted metadata):
{
"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):
{
"message_id": "1786",
"sender_id": "8481137853",
"sender": "8481137853"
}
关于标签更新的说明我大概写了一下，你重新看一下README
assistant:
assistant: 看到了，关于"Refining the Tag Taxonomy"的新章节。写得很详细，我理解的核心：
什么时候要调整标签
- 某个发件人审了10+次还是排队（置信度上不去）
- 同个发件人历史里既有 delete 又有 keep（标签没区分对）
- LLM 打的标签太抽象、匹配效果差
7步流程（从发现问题到解决）
- 找出那些"操作不一致"的发件人
- 对比那些邮件（主题、摘要、现有标签）看哪里该区分
- 判断是不是缺个标签，还是现有的标签 LLM 没用好
- 验证新标签：够独特、能复用、不和现有标签混淆
- 往
TAG_TAXONOMY里加 - 决定要不要清空历史（1-2个标签不用清，3+个标签或大规模改动建议清）
--dry-run跑验证
关键规则
- 只增不减不重命名（历史兼容）
- 20-30个标签左右就够了，多了 LLM 反而乱选
这个流程挺实用的。不过第6步"清历史"我可能会再犹豫一下——一旦清了就得重新攒9个样本，如果是高频发件人（比如每天一封促销的）还好，低频的（比如每月一封账单）可能得等大半年。
我理解得对吗？ user: Conversation info (untrusted metadata):
{
"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` 和清历史文件前，会问一句。