Webhook 挂仓库，邮件挂在人身上

一句话：数字员工接外部系统的事件，第一入口应该是它自己的邮箱，因为只有邮件是按人投递的。 原文：/posts/agent-inbox-is-email/

主张

• 同一件事有三条接法，差别在事件挂在谁身上：Webhook 挂仓库或组织，GitHub App 挂应用，邮件通知挂人。要像员工一样干活，就得走人级那条。
• GitHub 给人的事件出口只有网页通知和邮件；给人的 REST 通道官方按轮询设计，响应带 X-Poll-Interval。想要人级又要推送，只剩「机器账号 + 能推的邮箱」。
• 邮件把「为什么是我收到」做成字段：X-GitHub-Reason、第二个 Cc 的 reason 后缀、List-Id；GitLab 同构并带 X-GitLab-Reply-Key。在 Webhook 里这是一段业务逻辑。
• 邮箱普遍只给只读连接器，于是退化成轮询。破局点是邮箱自己会推（AgentMail 的签名 Webhook + WebSocket 两条通道）。
• 不逐个接各家 API 的理由：各家 schema 不一样；而发到邮箱的内容本来就是写给人看的，对 Agent 也相对结构化。
• 邮箱够不够格取决于能不能设规则：按 API 开箱、三级收发名单（按 In-Reply-To 把回信和陌生来信分到两套）、标签当状态、双通道推送。
• 修正两处常见误解：GitHub 自定义路由是组织级不是仓库级，分仓库靠 List-Id 在邮箱侧过滤；Gmail 与 Microsoft Graph 都有推送，缺的是按 Agent 编程开箱。
• 反方成立：统一入口也统一了攻击面。邮件地址任何人可写，提示词注入是常态输入，所以判断收窄为邮箱适合当感知入口，不适合当授权入口。邮件到达没有 SLA，这条无解。