Hermes 的邮件接入：给 agent 一个专属邮箱※
Hermes Agent 的应用 · 第 1 篇
0x00 序※
起因是我那个笔记仓库：上游更新了，但我的 fork 同步流水线跑失败了。按老习惯，这种事得我自己上去看、手动处理。但那天我忽然想：这种活儿，能不能让 agent 自己来做？
要做，第一步是让它知道"有事发生"。问了问，第一反应是接 webhook——但再一想，webhook 是仓库专用的东西，每个仓库都得单独配，它只认流水线这一条路。而邮件是通用的：GitHub 会发、AUR 会发、什么服务都往邮箱里发。所以定了：给 agent 一个专属邮箱，让它自己收信、自己判断要不要处理。
0x01 为什么是邮箱※
这里其实有两个问题：为什么是邮箱（而不是 webhook），以及为什么是 agent 专属邮箱。
问题一：为什么是邮箱，而不是 webhook※
想让 agent 知道"有事发生"，最直接的想法是接 webhook——流水线一跑完，直接踢一脚给 agent。但 webhook 是仓库专用的：GitHub 的 webhook 只配给 GitHub 的仓库，AUR 的又得单独一套，每个服务都要拉一条专线，还得维护。哪天哪个服务不支持 webhook，那就直接没戏。
邮件不是，它是通用的：谁都能往邮箱里发，GitHub、AUR、Google、任何服务，只要会发邮件就行。一条通道，所有服务共用，不用给每个服务单独配。
问题二：为什么是 agent 专属邮箱※
既然用邮件，那就给 agent 单独开一个邮箱，不跟人的混在一起。三个理由：
- 机器专用——agent 处理的是机器通知（流水线、仓库、维护），和人收的邮件（账单、订阅）根本不是一类，分开各收各的；
- 安全——验证码这类敏感的东西，不该从 agent 的邮箱过，agent 邮箱只收机器通知，万一出了岔子，波及面也小；
- 能帮我干活——agent 自己的邮箱，它就能放开手处理：垃圾邮件、营销广告、各种通知，直接帮我在那边自动退订、分类、该扔的扔，不用等我自己去翻。
0x02 mailwatch：IMAP IDLE 实时通道※
通道定了，怎么实时收？不能轮询（每 30 秒查一次太笨、太慢）；用 IMAP IDLE 事件驱动——连接保持，Gmail 有新邮件主动推事件。
实现是一个常驻脚本 mailwatch.py（开源在 hermes-mailwatch 仓库）：代码里零硬编码，配置全部走环境变量（仓库自带 .env.example 模板，IMAP 服务器/端口/账号/推送目标都可配，通用 IMAP 不限于 Gmail）。本机配置放 mailwatch.env（chmod 600），systemd 服务用 EnvironmentFile 加载。
Gmail 新邮件 → IMAP IDLE 实时事件 → mailwatch.py 解析 → hermes send → QQ
关键点：
- 连接保活：Gmail IDLE 约 29 分钟断连，外层循环自动重连
- 增量处理：状态文件记录 last_uid，只处理新邮件，防重复推送
- 自动置已读：agent 处理过的邮件标记已读（BODY 抓取），收件箱保持干净，不重复打扰
- systemd 常驻：开机自启，Restart=always
0x03 一个实例：笔记仓库上游更新，流水线失败※
说个实际发生的事，走一遍全流程。
那天我的笔记仓库（Trilium 的 fork）上游更新了，fork 同步流水线跑失败了。放在以前，这事我得自己上去看 GitHub、翻 Actions 日志、手动处理。现在邮件通道接好了，流程变成了这样：
上游发版 → GitHub Actions 同步流水线跑失败 → 失败通知邮件发到 agent 邮箱 → mailwatch 捕获 → 推送到 QQ → agent 处理（看失败原因、决定怎么修）
具体到那一次：GitHub 给我发了封邮件，标题就是 [tsaitang404/trilium-next-notes] Run failed: Sync fork with upstream，正文带着 Actions 运行链接和失败原因。这封邮件进了 agent 邮箱，mailwatch 马上推到 QQ——我在 QQ 上直接看到"流水线失败了，是 fork 同步，原因是 fast-forward 冲突"。
接着就是 agent 的活：分析失败原因（fork 有本地提交导致 ff-only 失败）、给出处理方案（rebase 保留 workflow 提交 / 上游为准重建 develop）、我确认后执行，把仓库理顺。
整个过程我不用去 GitHub 翻，也不用盯 Actions 页面——邮件把事件送进来，agent 把事件处理掉，我只要在 QQ 上做决策。
0xFF 跋※
邮件接入把"外部事件"和"agent 处理"之间的路打通了——上游更新、流水线失败、issue 回复，都会自己流进 agent 的手里。接下来有两个方向想探索。
方向一：邮箱全面接管。目前 agent 邮箱只收机器通知，但想把它变成"对外统一入口"——AUR 里留的邮箱、注册各种服务用的邮箱，都逐步改成 agent 邮箱；只有验证码和私人邮件，才用自己的邮箱。这样大部分往来邮件都进了 agent 手里，它能处理的就更多了。这篇写完后第一个落地：把博客的联系邮箱（mailLink）也换成了 agent 邮箱——访客发来的信直接进 agent 邮箱，由它来处理。
方向二：其他场景。邮箱接进来之后，能做的事不止"通知"这一件：邮件内容分类、自动摘要、按发件人路由不同处理；营销邮件自动退订（已经在做了）；甚至以后新的自动化场景，都可以顺着这条通道接进来。
