我那个 126 邮箱注册了十几年未读邮件攒到 9200 封进回收站前最后一眼瞄到的几乎全是订阅推送、账单通知和每次大促必来的促销邮件。手动清理过两次每次删到一半就崩溃最后干脆「全选标记为已读」假装自己处理完了。这次不一样我决定用 Hermes 这个 AI 智能体把清理这件事自动化掉整个过程跑下来踩了好几个坑也摸出了一套「大模型决策 脚本执行」的邮箱清理套路。如果你也想让 Hermes 帮你处理邮箱或者正打算把这类重复性任务交给 AI这篇应该能帮你少走不少弯路。这篇文章会完整记录我用 Hermes 清理 126 邮箱的全过程包括 Hermes 本地部署、IMAP 接入、清理规则设计、实测效果以及五六个网上几乎查不到的踩坑细节。不管你是第一次接触 Hermes还是已经在用其他智能体工具只要想解决「邮箱爆炸」这个老大难问题这篇的思路可以直接抄作业。1. 懒到极致才会做的事让 Hermes 接管我的 126 邮箱先交代一下为什么选 Hermes而不是直接用 126 邮箱自带的过滤器或者干脆写个 Python 脚本一键删信。1.1 为什么不用邮箱自带的自动分类和过滤器126 邮箱本身支持「网易邮箱智能分类」「收支分析」「来信分类」这些功能公众号类的订阅也会被自动收进「订阅邮件」文件夹。听上去够用了但实际用下来你会发现一个问题它的判断逻辑是完全固定的只会根据发件人地址、主题关键词、收件规则来粗暴归类。举个例子我邮箱里有一批「账单」类邮件浦发银行信用卡、招商银行、联通话费、美团月结单这些。网易智能分类会把它们认成「账单」但它不会告诉你哪些账单可能重复扣费、哪些已经三个月没发了需要警惕、哪些其实只是营销广告伪装的账单。再比如一些技术社区的周报主题是「Your weekly digest from Hacker News」网易会把它们分到「订阅邮件」但里面偶尔会夹着一条人工审核通过的招聘帖。这种「语义层面的判断」恰恰是规则引擎做不了的而大模型天生擅长。Hermes 本质上就是一个接大模型跑决策的本地智能体把「读邮件、做判断、执行动作」整个闭环串起来正好补上传统过滤器的短板。1.2 Hermes 跑清理任务的闭环逻辑先给没接触过 Hermes 的朋友一个概念。Hermes 是当前热度比较高的开源 AI 智能体项目支持本地部署UI 形态有 WebUI、Studio 桌面版、命令行 CLI 三种。你可以把它理解成一个「自带手脚」的大模型不只是聊天它能通过工具调用去操作文件、调用接口、连接外部服务然后根据结果继续行动直到完成任务。我用 Hermes 清理 126 邮箱时实际跑起来是这个闭环Hermes 通过 IMAP 协议连接 126 邮箱读取邮件头、正文、附件信息内置的 Agent 流程把每封邮件的内容丢给大模型我接的是 DeepSeek后面会细说大模型按照我预设的分类规则输出决策比如「保存」「归档」「退订」「删除」Hermes 调用 IMAP 命令执行这些动作比如移动邮件到指定文件夹、标记删除、解析 List-Unsubscribe 链接并请求退订。简单说就是大模型负责看信、想清楚怎么做脚本负责执行。这两件事单独拎出来都不复杂但组合在一起就是一套完整的自动化清理流水线。而且因为 Hermes 支持多轮 tool-calling遇到拿不准的邮件它会先搁置、记录理由而不是直接暴力删除这点很关键。2. 前置准备126 邮箱的授权码、IMAP 参数和 Hermes 部署万事开头难开头全是坑。这一章先把硬件的准备工作说透每一步都是实测跑通的。2.1 最关键的一步用授权码而不是邮箱密码无论你是用 Hermes 还是任何第三方客户端比如 Foxmail、Thunderbird连 126 邮箱都不能直接用邮箱登录密码。126 邮箱的安全策略是凡是第三方客户端接入必须先在网页端开启 IMAP/SMTP 服务然后生成一个「客户端授权密码」用这个授权密码作为登录凭证。我第一次就是没搞清楚这点在 Hermes 配置里填了邮箱密码结果认证直接失败报错信息还是模糊到让人抓狂的「Login failed」。后来查了一圈才明白这不是 Hermes 的问题也不是密码输错而是 126 强制要求走授权码。操作路径给你写清楚登录 126 邮箱网页版进入 设置 → POP3/SMTP/IMAP开启 IMAP/SMTP 服务会要求你用手机号发一条短信验证验证通过后网页会生成一串客户端授权密码复制保存好。这串授权密码只在生成时完整显示一次忘了就得删掉重新生成。所以拿到后立刻放到 Hermes 的配置里或者存到本地密码管理工具中别随手丢在聊天记录里。2.2 IMAP 连接参数126 和 Gmail 差异不小126 邮箱的 IMAP 参数如下直接抄项目值IMAP 服务器imap.126.comIMAP 端口993SSL/TLSSMTP 服务器smtp.126.comSMTP 端口994SSL或 465认证方式授权码如果你在 Hermes 的集成配置里看到的是 OAuth2 选项126 是不支持的老老实实选密码认证然后填入授权码。还有一点126 的 IMAP 对第三方客户端的登录频率有限制。如果你在配置阶段反复测试连接连续失败多次会被临时锁定一段时间页面提示通常是「登录过于频繁请稍后再试」。我当时就因为在调试授权码时手滑连错了五六次被锁了 15 分钟只能干等。2.3 Hermes 的部署形态CLI、WebUI 还是 StudioHermes 的安装方式不算复杂但要看你打算怎么用它。我自己的选择是只在需要清理邮箱的这两周用了本地 CLI WebUI 模式没上 Studio 桌面版。原因很简单跑这种一次性批量任务没必要常驻一个桌面应用。从实际体验看三种形态的取舍是这样CLI 模式适合写批处理脚本、直接调用任务流。缺点是交互不那么友好调试 prompt 的时候比较费劲。WebUI 模式适合边看邮件列表边调整规则清理任务跑完后可以直观检查哪些邮件被分类到了哪里。我用的是这个因为要反复抽查分类结果。Studio 桌面版功能最全可视化编排任务流的体验最好但如果你机器配置一般跑起来会有点重。还有一个和资源消耗直接相关的坑如果你机器上有 Docker也装了 WSL2很多教程会推荐用 Docker 跑 Hermes。但我实测下来在 Windows 上用 Docker 跑 Hermes 比 WSL2 更省资源因为 Docker Desktop 的虚拟化层比 WSL2 更适合这类 IO 密集任务内存占用反而更低。如果你只是跑邮箱清理这种任务建议先试 Docker别一上来就折腾 WSL2。模型接入方面Hermes 本身不内置模型需要你自己配置。我接的是 DeepSeek因为其 API 便宜、上下文足够长处理单个邮件的平均成本可以做到很低。如果你追求数据完全不出本机也可以配本地模型但处理 9000 封邮件的速度会明显变慢——这点后面成本小节会详细对比。2.4 用 UID SEARCH 做粗筛而不是全量拉取这里插一点 IMAP 层面的优化思路。我一开始写读取逻辑时很自然地就是「INBOX 里所有邮件全部拉一遍」结果发现 126 的响应特别慢。后来改成先用search把邮件按主题或发件人做一个粗筛再针对筛选结果逐封拉取速度立刻上来了import imaplib mail imaplib.IMAP4_SSL(imap.126.com, 993) mail.login(你的邮箱126.com, 你的授权码) mail.select(INBOX) # 粗筛先按主题关键词扫一遍 typ, data mail.search(None, SUBJECT weekly) uids data[0].split()关键点是不要在 Hermes 的任务描述里让它把每封邮件正文都完整读一遍而是先让脚本用 IMAP 的search做一轮粗筛把明显是订阅类的邮件挑出来再进入大模型做精细化分类。这样 token 消耗和耗时都能降一个数量级。3. 把「清理规则」翻译成 Hermes 能执行的指令如果你上来就给你的智能体说「帮我清理一下邮箱」它的第一反应大概率是问你要清理标准。所以真正动手之前一定要先设计好分类体系。3.1 邮件分类策略六类足够覆盖绝大多数场景我参考了 Gmail 的收件箱分类逻辑结合自己 126 邮箱的实际情况把邮件分成了六类分类判定标准处理动作IMPORTANT来自亲人、同事、客户或主题涉及项目、合同、面试等保留在收件箱BILLING银行、支付、信用卡、话费、水电煤账单移入「_billing」文件夹SUBSCRIPTION技术周报、产品更新、Newsletter尝试退订退订后可删除SOCIAL_NOTIFY社交平台通知、论坛回复通知移入「_notify」文件夹PROMOTION促销、折扣、大促邮件删除或移入「_promo」待确认UNCERTAIN以上都无法确定不处理留在收件箱这个分类本身不稀奇关键在后面每封邮件的分类结果不是人来定的是 Hermes 调用大模型定的。3.2 让大模型输出结构化决策而不是自然语言这是我觉得整件事最核心的一环也是很多智能体教程不会讲的细节。当 Hermes 读了一封邮件后如果你只是让它「觉得是什么类型就说什么」它会给你回一段自然语言比如「我觉得这封邮件是账单建议归档」。但这么一来后续的脚本根本无法稳定执行因为输出格式不固定。正确做法是在任务指令里要求模型输出固定的 JSON 结构{ email_id: 12345, category: BILLING, action: archive, target_folder: _billing, confidence: 0.92, reason: 邮件内容包含信用卡消费提醒属于银行账单类 }把决策输出固化后后面接一层简单的 Python 代码就能根据action字段去执行真实的 IMAP 移动、删除、退订操作。大模型负责判断代码负责执行各干各擅长的部分。3.3 第一轮必须干跑dry-run别直接动真格这个建议我强烈希望你先听我的给 Hermes 挂上 DRY_RUN 模式让它只读邮件、输出决策不真正执行任何移动或删除操作。干跑的价值有两个。第一你可以快速评估分类准确率。我第一轮干跑完随机抽看了 50 封邮件的分类结果发现一个典型误判有些粗筛时被归为 SUBSCRIPTION 的邮件其实是 GitHub 的代码仓库安全告警这类应该算 IMPORTANT。于是我在 prompt 里补了一条规则「如果主题或正文里出现 vulnerability、security、critical优先级提升到 IMPORTANT」。第二干跑能让 Hermes 把拿不准的邮件单独挑出来标注成 UNCERTAIN 而不是硬分。我要求它凡是置信度低于 0.8 的一律归入 UNCERTAIN 等待人工确认。干跑结束后我只需要对着 UNCERTAIN 列表过一遍比对着几千封邮件逐个检查高效得多。整个干跑阶段大约消耗了 2 万 token算下来几块钱人民币换来了后面正式执行的信心和安全感非常值。4. 实测过程从 9200 封到 700 封的清理战役准备工作做完后正式开始清理。整个实测过程我分了三轮每轮的设计思路和效果都不太一样。4.1 第一轮先解决最痛的大头——订阅退订我这 9200 封未读邮件里订阅类邮件占了绝对的多数。粗略扫了一眼至少 6000 封以上是各种 Newsletter、周报、社区通知。处理订阅类邮件的常规思路是「永续删除」但真正有效的做法是「退订」。光删不退下个月还会收到新的。126 邮箱的订阅邮件大多会带一个List-Unsubscribe邮件头里面是一串退订链接。Hermes 能自动解析这个头提取退订 URL然后直接请求链接完成退订。我的策略分三步先用search按主题粗筛订阅类邮件解析List-Unsubscribe头能解析出链接的让 Hermes 请求链接完成退订退订成功的邮件直接标记删除退订失败的移入_subs_manual文件夹等待人工处理。实测下来2600 封我主动抽样的订阅邮件里约 70% 都带有可用的退订链接自动退订成功率相当可观。这一轮跑完我邮箱里每天新增邮件的数量直接降了一半多。有一个值得说的小坑有些退订链接并不是直接 GET 就能完成退订而是要求发一封带有特定 token 的邮件到某个地址。这种 Hermes 也能处理但需要额外对接 SMTP 发信。我当时嫌麻烦把这类邮件统一归到_subs_manual人工 5 分钟就清完了没有为它单独开发流程。4.2 第二轮账单归档和社交通知归档订阅清理完之后剩余的大头是账单和社交通知。账单类邮件的特征是不能删涉及财务记录但也没必要留在收件箱里占注意力。我的处理策略是无脑归档到_billing文件夹。只有一类例外——连续多个账期金额波动异常的账单我会让 Hermes 单独标出来人工再核查一下是否有重复扣费。社交通知类比如知乎的消息提醒、GitHub 的 follow 通知、豆瓣的评论提醒处理最简单统一归档到_notify设置为已读不保留在收件箱。第二轮跑完后收件箱里剩下的邮件大约 3800 封。4.3 第三轮人工复核 UNCERTAIN 和重要邮件3800 封里有大约 900 封属于干跑阶段标注的 UNCERTAIN 或 IMPORTANT 邮件。这一轮我没有再跑自动化流程而是把列表导出人工扫了一遍。900 封听起来很多但实际以「发件人」分组后需要逐一确认的只有 47 组。大部分是多年不联系的老同事、抽奖中奖通知、某些平台强制发送的验证码邮件。不重要的直接删除有那么十来封来自老朋友的邮件我甚至想找时间正经回一下。三轮跑完收件箱从 9200 封降到 700 封其中 600 封是真正需要保留的重要邮件剩下 100 封是我故意保留的「可删但不着急删」的类型。整个流程含干跑和人工复核累计耗时大约一个下午。4.4 成本盘点API 费用和耗时我知道你们最关心的问题一定是这么跑一趟到底花了多少钱我的配置是 DeepSeek API Hermes 本地部署模型选了 deepseek-chat 档位。实际消耗如下项目数据处理邮件总数约 8500 封含干跑token 总消耗约 62 万API 费用约 8 元人民币纯自动化耗时约 40 分钟人工复核耗时约 1.5 小时如果换成开源本地模型比如 Qwen 或者 Llama 的量化版费用为 0但单封处理速度会慢很多——我拿本地 13B 模型测试过同样的 8500 封估算要跑三个多小时而且分类准确率明显不如云端模型。综合性价比看接 DeepSeek API 商用模型 Hermes 的组合是最推荐方案。5. 踩坑实录这五件事在官方文档里绝对看不到流程跑通后你会觉得挺顺畅但过程中埋着不少坑。这一章全是实际踩出来的经验单独拎出来说。5.1 已读/未读状态被误改了导致分类规则失效这是我遇到的第一个隐蔽坑。用 imaplib 抓取邮件正文时默认的fetch操作会顺手把邮件标记为已读\Seen。如果 Hermes 在读取邮件时没有显式加BODY.PEEK它的读信动作本身就会改变邮件状态。这带来的问题是你原本想统计「哪些未读邮件该保留」「读一遍」之后全变成已读了后续筛选逻辑全部失真。解决方案是使用BODY.PEEK而不是BODYtyp, data mail.uid(fetch, uid, (RFC822.HEADER BODY.PEEK[]))5.2 中文主题乱码RFC 2047 编码解码问题126 邮箱里大量中文邮件主题经过 IMAP 返回时往往是?UTF-8?B?...?这种编码格式。如果 Hermes 没有先做解码直接把编码串丢给大模型去判断模型会一脸懵。我一开始就把这种原始编码串传给了 Hermes结果它把一封主题为「?GBK?B?u9Ph8g?」的邮件当作无意义邮件分类到了 PROMOTION。后来才意识到需要先解码from email.header import decode_header def decode_mime_header(raw): parts decode_header(raw) result [] for content, charset in parts: if isinstance(content, bytes): result.append(content.decode(charset or utf-8, errorsreplace)) else: result.append(content) return .join(result)在把邮件内容交给 Hermes 之前务必先对主题和发件人字段做一遍解码不然大模型的输入质量直接崩盘。5.3 高频请求被 126 风控临时限流清理到第 2000 封左右时IMAP 连接突然开始返回unexpected EOF再往后直接连接失败。我一开始以为是 Hermes 的 bug后来查了半天才发现是 126 的反垃圾策略把高频请求临时限制了。这不是永久封禁大概 10 到 15 分钟就解封但如果你在整个流程里不加节流它会反复触发。解决办法也很简单——在每次 IMAP 操作之间加短延迟同时加上重试退避逻辑import time import random def imap_call_with_retry(func, retries5): for i in range(retries): try: return func() except Exception: wait 2 ** i random.uniform(0, 1) time.sleep(wait) raise RuntimeError(连续重试多次仍然失败)实测下来单封邮件之间加 0.5 秒睡眠每 100 封操作后额外等待 5 秒基本就不会再触发限流。耗时从理论上的一小时拉长到了三四十分钟但胜在稳定值得。5.4 删除不等于删除126 的 Expunge 行为详解这是最让我后背发凉的一个坑。用 IMAP 把邮件标记为\Deleted然后执行expunge()你可能会以为邮件已经物理删除了。但 126 邮箱的实际行为是会被移入「已删除」文件夹而不是立即物理删除。大部分时候这反而是个保护机制但如果你用的是UID EXPUNGE这种命令部分 126 服务器上的行为会有差异。更需要注意的是不要在还没复核分类结果时就对大批邮件执行 delete 操作。我损失过一次教训某一类被误判为 PROMOTION 的邮件里混有一位客户的报价邮件好在当时只是移入了「已删除」而不是彻底清空才从回收站里捞了回来。我给 Hermes 的清理规则里加了一条铁律所有 delete 操作必须先 move 到_hermes_review文件夹保留 24 小时后再由另一个定时任务清空。这条规则现在依然生效强烈建议你用任何 AI 智能体清理邮箱时都保留这个「隔离期」。5.5 126 对「已发送」等系统文件夹的 IMAP 权限限制清理到后面我想顺手把「已发送」里曾经发错的邮件也处理一下结果发现 126 的 IMAP 对Sent文件夹的支持很别扭。具体表现是select(Sent)能成功但部分操作会报权限不足。这不是 Hermes 的问题是 126 的 IMAP 服务器实现限制。所以如果你计划清理系统文件夹建议先在网页端确认哪些文件夹支持 IMAP 操作别把流程设计成「已发送也要归集」。6. 复盘AI 智能体清理任务值得做但边界要清楚清理跑完后的一周里我几乎每天都会打开邮箱看一眼。收件箱维持在 700 封出头每天新增的订阅邮件从 20 封降到 5 封以下那种「打开邮箱扑面而来的焦虑感」消失了。但说句公道话这类 AI 智能体工具不是万能药它有明确的适用边界。6.1 适合交给 Hermes 的邮箱场景从这次实测看凡是「量非常大、规则相对清晰、错判代价可接受」的邮箱任务都适合交给 Hermes批量退订订阅邮件这绝对是性价比最高的场景账单类邮件自动归档配合财务记账效率翻倍定期清理「已读 3 个月以上」的大附件邮件每天定时对收件箱做一次分类汇总按重要程度排序未读邮件归零让收件箱恢复「打开就能看到真正重要的东西」的状态。6.2 不适合的场景也要心里有数涉及重要隐私和资产安全的邮件不建议完全交给 AI 自动删除。比如银行对账单、合同扫描件、法律文书这类即使分类准确率到了 99%也不能拿那 1% 的概率去赌。我的做法是这类邮件无论模型怎么分类一律只归档不删除最终保留在本地备份里。超大附件的批量处理也不适合。Hermes 读一封带 50MB 附件的邮件时会把附件内容拉进上下文做分析token 消耗瞬间爆炸。处理这类邮件应该单独写脚本只针对附件大小做判断不经过大模型。6.3 后续还能怎么玩这次清理跑完后我意识到一个更大的价值点Hermes 这类智能体可以把「维护邮箱健康」变成常态化运营而不是一次性突击。我现在已经在试验一个每周任务流每周末自动扫描收件箱统计本周订阅邮件来源、退订成功率、未读增长趋势然后生成一封摘要邮件发给我自己。下一步还想让它做到每月自动整理一次账单分类汇总直接用图表输出消费趋势。如果你也跟着把邮件清理自动化跑通了可以考虑把同一个 Hermes 任务流迁移到其他场景——比如自动整理本地下载文件夹、归档项目文档、定时抓取网页信息做报告。这次清理 126 邮箱的经历给我的最大感受是AI 智能体的价值不在于替你做决定而在于把那些你懒得做但不得不做的事变成一套可维护的自动化流水线。你只需要在关键节点保留人工复核的权力就够了。最后再分享一个小技巧给 Hermes 配完一套好用的清理任务流之后记得把任务定义和分类规则导出备份。这套东西就是你的「数字生活基础设施」下次再遇到邮箱爆炸或者想迁移到其他邮箱服务时直接复用即可不用从头再踩一遍我这篇里写的那些坑。