一次 API 调用，给你的 AI 智能体一个邮箱地址

AI 智能体（AI Agent）可以注册一个服务、启动一个任务，或者提交一张工单，然后流程就停住了，因为答复送到了一个智能体不存在的地方：邮箱。验证码、收据、“你的导出文件已就绪”通知、密码重置。邮件是互联网上最古老的回调机制，而智能体没有邮箱地址。

本文介绍我们能做出的最小解法。一次 API 调用，无需注册，就能返回一个可用的邮箱地址；发到这个地址的邮件会变成结构化事件，智能体通过 HTTP 读取，它们和它的 Webhook 落在同一份事件日志里。

TL;DR

POST https://anyhook.net/api/v1/quickstart（无需认证）返回一个类似 q-cd3fe0f8.quickstart@anyhook.net 的 inbox_address，外加一个 Webhook inbound_url 和一个 API 密钥
发到这个地址的邮件会变成一个 email.received 事件：from、to、subject、message_id，以及完整的原始 MIME 邮件
智能体用 GET /api/v1/events 列出事件，用 GET /api/v1/events/{id} 读取单个事件，也可以通过 MCP 用 anyhook_inbox / anyhook_events / anyhook_inspect（注册表：net.anyhook/anyhook，远程端点 https://anyhook.net/mcp）
它只接收。它不能发送，也不能回复，这是有意划定的边界，而不是路线图上的空缺
免费端点 7 天后过期，除非被认领；Free 套餐的上限是每天 1,000 个事件

只需一次调用

curl -X POST https://anyhook.net/api/v1/quickstart

{
  "inbound_url": "https://in.anyhook.net/q-cd3fe0f8/quickstart",
  "inbox_address": "q-cd3fe0f8.quickstart@anyhook.net",
  "api_key": "ahk_live_…",
  "claim_url": "https://anyhook.net/claim/…",
  "expires_at": "2026-08-06T…"
}

你不需要创建账号，不需要过验证码，也不需要点击 OAuth 授权同意页面。这很重要，因为这里的调用方往往不是人。它是一个正在执行任务的智能体，流程里的每一张注册表单，都是任务可能夭折的地方。在有人通过 claim_url 认领之前，这个端点是临时的（7 天），这也是滥用的上限：任何匿名的东西都活不过它的 TTL。

同一个 App 现在通过两种传输方式接收：

传输方式	地址
HTTP Webhook	`https://in.anyhook.net/q-cd3fe0f8/quickstart`
邮件	`q-cd3fe0f8.quickstart@anyhook.net`

两者汇入同一份事件日志，所以在智能体看来，“等 Stripe 的 Webhook”和“等确认邮件”是同一个操作：轮询事件 API，检查请求体。

一封邮件会变成什么

给这个地址发任意一封邮件。几秒之内，它就会作为一个事件出现：

{
  "type": "email.received",
  "from": "noreply@github.com",
  "to": "q-cd3fe0f8.quickstart@anyhook.net",
  "subject": "Your verification code is 481920",
  "message_id": "<abc123@mail.example.com>",
  "date": "Thu, 30 Jul 2026 11:42:31 +0700",
  "size": 7026,
  "raw": "Received: from …"
}

raw 是完整、未经修改的 MIME 邮件：每一个邮件头、每一个部分、每一个附件，都和到达时完全一致。元数据字段只是为了方便；原始邮件才是唯一可信的来源。对于智能体最常见的场景，也就是从验证邮件里取出验证码，通常只看主题行就够了。更复杂的需求，用你所用语言的标准库解析 MIME。标准库就是干这个的。

读取它：

curl https://anyhook.net/api/v1/events \
  -H "Authorization: Bearer ahk_live_…"

# the list carries no payloads; this returns one event with its body
curl https://anyhook.net/api/v1/events/<id> \
  -H "Authorization: Bearer ahk_live_…"

和 Webhook 端点一样，先创建、后认领。收件箱只是另一扇前门。

通过 MCP

如果智能体支持 MCP，它根本不用碰 curl。这个服务器以 net.anyhook/anyhook 的名字收录在 MCP 官方注册表中，形式是 anyhook-mcp npm 包，以及位于 https://anyhook.net/mcp 的远程 streamable-HTTP 端点：

anyhook_quickstart 直接返回一个 inbox_address（在 npm 包中无需密钥即可运行；远程端点需要先有 API 密钥或先登录）
anyhook_inbox 返回现有 App 的邮箱地址，以及它的 Webhook URL
anyhook_events / anyhook_inspect 读取收到的内容

快速开始工具就是全部的上手流程。一个在注册表里发现这个服务器的智能体，可以给自己生成一个收件箱并开始接收，整个过程没有人参与。人是之后才出场的（如果会出场的话），为的是认领账号。

工作原理（以及地址为什么长这样）

在底层，我们有意没有建第二条管道：

Cloudflare Email Routing 的 catch-all 规则，把这个域名的每一封邮件交给接收 Webhook 的同一个边缘 Worker
Worker 在地址本地部分的最后一个点处拆分：{user-slug}.{app-slug}@anyhook.net。slug 在创建时会被清理成只含 [a-z0-9-]，所以永远不会包含点号，这从构造上保证了拆分没有歧义
邮件被重新封装成它本该是的那个 HTTP 请求，下游的一切（配额、请求体限制、排队、重试、投递到你的转发目标、事件日志）走的都是和 Webhook 完全相同的代码路径

解析不到真实 App 的邮件，会在 SMTP 阶段被拒收，而不是被悄悄吞掉。没收到错误的发件人会以为已经送达。超大的邮件也会以同样的方式退回。

有两个特性从 Webhook 那边免费继承过来。邮件正文在写入数据库之前就用 AES-256-GCM 加密。每个事件的哈希都会被折叠进按 App 划分、每日封存的链中，每天的根都提交到一个 AnyHook 不持有任何凭据的公开 git 仓库。如果某封已保存的邮件所属的那一天已经封存，我们再修改这封邮件，公开锚点就会验证不通过。

它不是什么

它不发信。不回复，不发外发邮件，也没有 SMTP 凭据。发信涉及送达率、SPF/DKIM 对齐、IP 信誉和垃圾邮件责任。那是另一门学问，有另一套失败方式。如果你的智能体需要完整的双向对话式邮件这种产品，这个品类是存在的（AgentMail 就是凭这个判断融的资）。一个挂在 Webhook 转发服务上的只收不发的收件箱，范围要窄得多：所有进来的东西，都在一份事件日志里。

它不是临时邮箱服务。它的预期用途是你自己的系统产生的邮件：你的智能体正当运营的账号的确认邮件、你集成的服务发来的通知、你自己的流程产生的收据。免费端点有限流、有上限、会过期，滥用模式会被封禁。如果某个服务的条款禁止自动注册，一个收件箱改变不了这一点。

它是轮询，不是推送。智能体问“收到了什么？”，没有任何东西会唤醒它。需要更低的延迟时，配置一个 destination_url，事件一到就会转发到你自己的服务器。邮件就变成了 Webhook。

试一试

# 1. mint an inbox (no signup)
curl -X POST https://anyhook.net/api/v1/quickstart

# 2. send any email to the inbox_address you got back

# 3. find it, then read it
curl https://anyhook.net/api/v1/events -H "Authorization: Bearer <api_key>"
curl https://anyhook.net/api/v1/events/<id> -H "Authorization: Bearer <api_key>"

总的配置时间，就是第 2 步那封邮件到达所需的时间。