English · 中文

为了让线上报错自己开 issue,我给系统配了个 Agent 邮箱——本来是想让它直接改 bug 的

2026-06-27 · 一次 Agent-first 的项目监控实验

起因很俗:线上半夜冒个 500,没人盯,等用户截图发群里、我再去翻日志,黄花菜都凉了。监控这事有现成的——我也挂过 Rollbar 那类看板。可说句实话:界面难看,免费档处处是限制,想解开就得掏钱。这是个业余项目,我不想为它花钱,更不想再养一个天天得盯着看的重控制台。

而且现在是 AI 时代了。我不太想再搭一套界面复杂、等人肉眼去盯的东西。我想试的是另一条路——Agent first:不要看板,让一个 agent 替我盯着项目,实时地盯。

落到具体,就是拿它做项目监控:让线上的报错自己发邮件到一个机器人邮箱,再让一个 agent(我本地的常驻进程)实时查这个邮箱,收到就动手。收件人不是我,是程序。

做着做着才意识到,我撞进了一个今年才冒头的新物种——「给 Agent 用的邮箱」。我找到两个代表 AgentMail 和腾讯的 Agently Mail,比了一圈,最后用其中一个搭出了这套。这篇就是这趟 build log,顺带把这两个拆开看看。

先看我搭了个啥

一句话:生产 Rails 一抛未处理异常,它就脱敏、去重、发邮件到一个 Agent 邮箱;我 Mac mini 上一个常驻进程每 10 秒轮询这个邮箱,收到就用 gh 自动开一个 GitHub issue。

这里有个看着绕、其实是整套设计命门的点:为什么是「邮件」?

卡了一下:本地服务公网进不来,webhook 根本推不到我,那它怎么知道线上出事了?

因为我的处理服务在本地,公网进不来——webhook 那种「你出事推给我」的玩法,本地根本收不到。而邮件天生就是跨网络、异步、带存储的信道:生产那头只管把信塞进信箱,我这头有空就去取,谁也不用知道谁的 IP。邮箱在这儿不是「发通知」,是当消息总线用。这件事,恰好就是「Agent 邮箱」这类产品赌的那个未来。

它真能跑。我在生产 console 里手动触发了一个测试异常,几十秒后,daemon 那头就动了,issue 自己冒出来:

$ python listener.py listen
👂 轮询监听 inbox=no8@…agentmail.to,每 10s 一次。Ctrl-C 退出。
======================================================================
📩 新错误邮件  from: autofix@leonclass…
   主题: [auto] NoMethodError #f89050d759aa
======================================================================
→ gh issue create --label auto-reported …
✓ created  https://github.com/leonx-ai/leonclass/issues/290

死的东西就这点好:它不会替你客气。该报的报,重复的不烦你——同一个错按指纹去重、还带个冷却窗,免得一个高频 500 把信箱刷爆。去重不是记在内存里,是落到一个文件,重启也不重复:

"f89050d759aa": { "action": "issue", "status": "created",
                  "issue": "…/leonclass/issues/290" }
"05bddfdfed03": { "action": "issue", "status": "created",
                  "issue": "…/leonclass/issues/292" }

本来我是想让它直接改 bug 的

说个实话。我第一版根本不是「建 issue」。我写的是:收到报错 → 起一个 headless 的 Claude Code,在独立 git worktree 里读代码、改、跑测试、直接开一个草稿 PR。整套都验通了。

然后我把它关掉了,退回到「只建 issue」(那个 fix 模式代码还在,一个环境变量的事)。

不是它不行——跑通了。是另一个问题先得回答:这个自己改码、自己开 PR 的回路,我到底该信它到什么程度?

线上信号驱动的自动改码,听着性感,真要常开,我得先答:它改得对不对?谁审?一个错误自己长出一个 PR,会不会半夜悄悄合进去?这些我答不利索之前,让它「先收集、先摆到我面前」才是诚实的姿态。Don't trust, verify——这回 verify 的对象,是我自己造的这套自动化。

护栏也是照这个心态拧的:fix 模式只开 draft PR、绝不自动合并、绝不动 main,并发上限默认 1。能力可以留着,默认得是克制的。

还有数据。报错信息会出境(发到美国托管的邮箱),所以我只发 fingerprint + backtrace + 脱敏后的 message,把邮箱、IP、长 token、长数字串全替换掉,请求参数和 user_id 一律不发。诊断力弱一点,换睡得着觉。

那「Agent 邮箱」到底是个啥新物种

普通邮箱是给人用的:你登录、你点开、你手动回。Agent 邮箱换了主语——主语是程序。它要的是:能用 API 建信箱、收到信能实时触发、有可被验证的身份去注册别的服务、还得和「人的邮箱」隔离开别串味。

今年冒出来两个很不一样的代表。

AgentMail:为机器对机器而生

AgentMail 的自我介绍很直白——「为 AI agent 打造的 API-first 邮件服务」。YC S25 出身,2026 年初由 General Catalyst 领投融了 600 万美元,赌的就是「每个 agent 都该有自己的信箱」。

它给你的是一整套机器接口:REST API、Python / TypeScript SDK、Webhook、WebSocket 实时事件、IMAP/SMTP,还有一个 MCP server。程序化建信箱、邮件一到就推事件、按 message id 取正文取附件——全是给代码用的动作,没有一处是为「人点鼠标」设计的。免费档就给 3 个信箱、每月 3000 封,够你把闭环先跑起来。

我这套用的就是它。对「无人值守、错误自动归集」这种纯管道场景,它顺得不需要思考。

腾讯 Agently Mail:给 Agent 一个「有身份、人盯着」的邮箱

腾讯 QQ 邮箱团队的 Agently Mail(agent.qq.com)出发点不太一样。它强调给 agent 一个独立身份、和你个人邮箱隔离的信箱,但骨子里是「人机协作」:

• 所有写操作(发/回/转/删)走两阶段确认——agent 先生成操作摘要,你点头它才真做;
• 读邮件时对 prompt 注入做防护;
• 接入是装 CLI + 微信扫码授权,挂在 agent 的对话窗里用,已适配 Claude Code、Cursor、Codex、Kimi、豆包等一票主流 agent;
• 国内原生,CLI 在 GitHub 上 Apache-2.0 开源,也上了腾讯 SkillHub。

注意:它有没有 webhook 推送、协议细节这些目前没怎么披露——它的形态更像「让一个 agent 替你打理一个有身份的邮箱」,而不是「后台 daemon 收到信就触发」。

所以它俩根本不同在哪

不是功能多少的差别,是世界观的差别。一个赌「无人值守的机器总线」,一个赌「人盯着的 agent 身份邮箱」。

放到我的场景里,选择是显然的:我要的是「没人在的时候它自己干活」,AgentMail 的 webhook/轮询模型天然合身。但如果我要的是「让一个 agent 替我盯收件箱、该回的拟个稿等我点发」,那 Agently Mail 的两阶段确认反而是特性不是麻烦。

顺便交代几个坑(死的东西不会骗你)

• 偶发丢信。 SendCloud → 邮箱之间,我亲眼见过一封秒到、另一封石沉大海。对错误归集还能忍——同一个错下个冷却窗会再发一次。但这提醒你:邮件这条管子也不能全信,关键链路得有重试或对账。
• 容器里没有 git。 生产 issue 里 git_sha 一开始是 unknown——镜像里没有 .git。这种小事不亲手跑一遍永远不知道。
• 跨进程去重得用共享缓存。 生产是多容器多进程,进程内的去重等于没去重,得落到共享缓存上才算数。

往后看:邮箱可能是 Agent 时代最被低估的基础设施

把视野拉远一点。我赌几件事会发生。

邮箱会变成 agent 的「系统级收件箱」:不只是收发 email,而是人↔agent、系统↔agent、agent↔agent 之间一条统一的异步信道。我这套「报错→邮件→处理」只是它最小的一个用例。

从「收集」走向「自愈」:issue → 草稿 PR → 自动验证 → 回灌——这条链我已经搭好了骨架,只是故意没全开。真正的门槛从来不是技术,是信任的标定:你愿意把多大的自治权,交给一个由线上信号驱动的回路。

身份与信任会变成主战场:agent 一旦有了可验证的邮箱身份,就能注册服务、走 OAuth、被审计——能力解锁的同时,prompt 注入、数据出境、自治边界,全成了要正面回答的治理题。腾讯那个两阶段确认 + 防注入,押的就是这条线。

最后

绕了一圈,回到开头那个我没法立刻回答的问题:这个自己会发邮件、自己会开 issue 的回路,我到底该信它到什么程度?我的答案是——先让它只说、别让它做;攒一阵真实的 issue,看清它的脾气,再一格一格地把自治权交出去。一个 50 岁的老协议,配上一个肯克制的回路,可能比「全自动」性感的口号靠谱得多。

说句私货:我们在认真做的 leonclass.com,一个帮理科老师审题的 AI 助手,骨子里也是个验证器——判一道题自不自洽、有没有命中要考的能力。跟这套自愈回路是同一件事:能力都不难造,难的是「敢不敢信它」,而让它可信的唯一办法,是先让它在你眼皮底下只说不做,跑够了再放权。

你要也在琢磨验证 / 教育 / agent,欢迎来聊。