如今，AI 智能体（AI Agent）几乎可以调用任何 API。这是容易的那一半。难的那一半是接收。当智能体配置一个 Stripe 集成、启动一次 Replicate 预测，或者搭一个 GitHub 自动化流程时，结果都以 Webhook 的形式返回，而 Webhook 需要一个可以公开访问的 URL。这恰恰是待在终端或沙箱里的智能体所没有的东西。
本文讨论的就是这个缺口：如今的工具在哪些地方默认了一个拿着浏览器的人，以及智能体要怎样才能自己拿到一个端点。
TL;DR
- 智能体需要接收事件，才能验证自己搭建的集成。一个 Stripe 集成，要等一个带签名的事件真正走通之后才算完成
- 大多数 Webhook 工具都默认有人在操作：注册表单、验证码、只能在控制台里完成的配置，或者一个需要安装并一直照看的二进制程序
- 一个智能体能自己操作的服务需要四样东西：一次调用即可创建、可通过 API 读取的事件日志、机器可读的文档，以及移交给人的路径
- 可行的模式是：智能体通过 API 或 MCP 创建端点 → 接收并检查事件 → 把认领后的账号交给它背后的人
AI 智能体为什么需要接收 Webhook
有三种情况反复出现。
第一种是验证自己的工作。一个写了 Stripe Webhook 处理程序的智能体，在一个真实的、带签名的 checkout.session.completed 事件打到处理程序之前，根本无从知道它能不能用。模拟请求体会跳过生产环境里真正会出错的部分：签名、请求头、重试。智能体需要一个真实的端点，接住一次真实的投递。
第二种是等待异步结果。Replicate 预测、OpenAI 批处理任务、视频渲染、CI 流水线：完成信号都是一个 Webhook。没有端点的智能体只能轮询，在“好了没有”上消耗 token 和限流额度。
第三种是端到端地搭建集成。当用户说“把我的 Shopify 店铺接到这个 Slack 频道”时，智能体需要一个地方来接收 Shopify 的事件，还需要一份它能读取的日志，用来排查究竟收到了什么。
智能体想要一个端点时，会卡在哪里
站在智能体的角度试一试，无论选哪个工具，几乎马上就会碰壁。
注册墙和验证码本来就是为了阻止自动化而存在的。任何要求先过这一关才发放 URL 的服务，在设计上就对智能体关上了门。
只能在控制台里完成的配置是下一堵墙。如果转发目标 URL 或签名密钥只能在界面上一路点击来设置，那么本该是一次 HTTP 调用的事，智能体却得动用浏览器自动化。
内网穿透工具需要一个二进制程序，还需要有人照看。ngrok 这类内网穿透工具很适合做本地开发的人，但智能体得安装二进制程序、完成认证、让进程一直活着，还得接受 URL 随会话一起消失。如果沙箱是临时的（大多数智能体的沙箱都是），异步任务还没完成，端点就已经没了。
临时 URL 会在任务中途失效。一个免费的 webhook.site URL 在收到 100 个请求后就不再接收，7 天后被删除；这对人做演示没问题，对智能体打算长期运行的集成却是致命的。
智能体能自己操作的 Webhook 服务是什么样子
四项要求，按优先级排列：
- 一次调用即可创建，无需凭据。
POST /quickstart返回一个端点 URL 和一个 API 密钥。没有账号，没有验证码，没有邮件验证的来回。（防滥用改由限流和 TTL 负责，而不是靠注册门槛。） - 一切都能通过 API 读写。事件日志、请求体检查、转发目标配置，全都能用第 1 步拿到的密钥访问，因为智能体永远不会看到控制台。
- 机器可读的文档。
llms.txt、OpenAPI 规范，以及纯 Markdown 的价格页。评估工具的智能体会读这些，它不会看你的演示视频。 - 移交给人的路径。智能体的工作不应该是一条死胡同。一个认领 URL，让人登录后接管智能体搭好的东西，就能把一次性的测试变成长期的基础设施。
在此之上再加一个 MCP 服务器，是很自然的封装方式：智能体的运行时会发现这些工具，创建端点就从一条 curl 变成了一次工具调用。
现有工具，实话实说
| 工具 | 智能体能独立创建吗？ | 会话结束后端点还在吗？ | 备注 |
|---|---|---|---|
| webhook.site | 部分可以，有 API | 免费 URL 收到 100 个请求后停止接收，7 天后删除 | 很适合人快速查看；有 API，但长期保留要付费 |
| ngrok | 不能，需要二进制程序 + 账号 + auth token | 不在，随进程一起消失 | 目标确实是 localhost 时，它仍然是合适的工具 |
| Hookdeck | 部分可以，CLI 自带 MCP 服务器 | 在 | 完整的事件网关；MCP 需要先有一个已认证的 CLI 会话 |
| AnyHook | 能，无需密钥的 POST /quickstart，MCP 可自行创建 | 在，匿名状态保留 7 天，认领后永久保留 | 转发服务，带重试、日志和重放；Pro 及以上套餐还能对每个事件运行你自己的代码 |
坦白说一下我们自己的局限：如果你需要转换请求体，或者扇出到很多消费者，Hookdeck 是更完整的产品。如果你的处理程序跑在你的笔记本电脑上，就用内网穿透工具。AnyHook 是为智能体原生的场景设计的，也就是：无需人工即可创建，会话结束后依然存在，之后再移交给人。
实际操作
创建端点（任何 HTTP 客户端都行，无需账号）：
curl -X POST https://anyhook.net/api/v1/quickstart
# → { "inbound_url": "https://in.anyhook.net/q-8f3a/quickstart",
# "api_key": "ahk_live_...", "claim_url": "https://anyhook.net/claim/..." }
或者让智能体的 MCP 运行时来做，只要一行配置，事先不需要密钥：
{ "mcpServers": { "anyhook": { "command": "npx", "args": ["-y", "anyhook-mcp"] } } }
anyhook_quickstart 工具创建端点；anyhook_events 和 anyhook_inspect 读取收到的内容。工作完成后，智能体把认领 URL 交给它背后的人，匿名的配置就变成一个普通的免费账号，端点不变，密钥也不变。
有两个相邻的模式用的是同一套机制。给智能体一个收件箱而不是 URL，见给你的 AI 智能体一个邮箱地址；它底下的路由层，见用 Cloudflare Email Routing 把任意邮件变成 Webhook。
常见问题
AI 智能体真的能在完全没有人参与的情况下使用 Webhook 服务吗？ 能，前提是服务支持无需密钥的创建。智能体用一次 API 调用创建端点，让平台指向它，再通过 API 读回投递记录。只有当你希望这套配置长期保留时才需要人参与，认领 URL 就是为此准备的。
无需密钥的端点不会被滥用吗？ 管控只是换了位置：创建时按 IP 限流，Free 套餐限制事件配额，未认领的端点有 7 天 TTL，这些共同限制了可能造成的损害。这个取舍是值得的，因为验证码挡住的恰恰是这个流程要服务的用户。
用轮询代替 Webhook 呢？ 轮询可行，但对智能体来说扩展性很差：每一次“好了没有”都要花掉一个请求、一个限流名额，往往还有 token。对于任何超过一分钟的任务，一个智能体最后查看一次就行的 Webhook 端点，更便宜也更快。
AnyHook 是一个 Webhook 转发服务：只改一个 URL，就能获得重试、完整的事件日志和一键重放。上面的快速开始是免费的，也不需要账号，你的智能体现在就可以试。