今天的 AI agent 幾乎能呼叫任何 API。那是簡單的一半。困難的一半是接收。agent 設定 Stripe 整合、啟動一次 Replicate 預測，或串起 GitHub 自動化時，結果都會以 Webhook 的形式回來，而 Webhook 需要一個公開連得到的網址。這正是待在終端機或沙箱裡的 agent 所沒有的東西。
這篇談的就是這個缺口：今天的工具在哪些地方預設了一個拿著瀏覽器的人類，以及 agent 要靠自己取得端點需要什麼。
重點摘要
- AI agent 需要接收事件，才能驗證自己建好的整合。在一個帶簽章的事件真正跑過一遍之前，Stripe 整合都不算完成。
- 大多數 Webhook 工具都預設使用者是人類：註冊表單、驗證碼、只能在儀表板設定，或是一個要安裝、還要一直顧著的執行檔。
- AI agent 能操作的服務需要四樣東西：一次呼叫就能建立、可透過 API 讀取的事件紀錄、機器可讀的文件，以及交接給人類的途徑。
- 行得通的模式：agent 透過 API 或 MCP 自行建立端點 → 接收並檢視事件 → 把認領後的帳號交給它的使用者。
為什麼 AI agent 需要接收 Webhook
有三種情況一再出現。
第一種是驗證自己的成果。寫了 Stripe Webhook 處理程式的 agent，在一個真實、帶簽章的 checkout.session.completed 事件打進來之前，無從得知處理程式能不能用。模擬 payload 會跳過正式環境中真正會壞的部分：簽章、標頭、重試。agent 需要一個真實的端點，接住一次真實的傳遞。
第二種是等待非同步的結果。Replicate 預測、OpenAI 批次工作、影片算圖、CI pipeline：完成的訊號都是 Webhook。沒有端點的 agent 只能卡在輪詢，把 token 和速率限制都耗在「好了沒」上面。
第三種是從頭到尾建立整合。使用者說「把我的 Shopify 商店接到這個 Slack 頻道」時，agent 需要一個地方接住 Shopify 的事件，還要有一份它讀得到的紀錄，用來除錯實際收到了什麼。
AI agent 試著取得端點時，哪裡會出問題
站在 agent 的角度試一次，不管選哪個工具，幾乎馬上就會撞牆。
註冊門檻和驗證碼存在的目的，就是擋下自動化。任何要先解一道驗證碼才發網址的服務，在設計上就是對 agent 關閉的。
只能在儀表板設定，是下一道牆。如果目的地網址或簽章密鑰只能透過一路點選介面來設定，agent 就得動用瀏覽器自動化，去做原本一個 HTTP 呼叫就該完成的事。
隧道需要一個執行檔，還需要有人顧著。ngrok 這類隧道對做本機開發的人類來說很好用，但 agent 得安裝執行檔、完成認證、讓行程一直活著，還得接受網址會隨 session 一起消失。如果沙箱是用完即丟的，而大多數 agent 的沙箱都是，非同步工作還沒完成，端點就已經沒了。
暫時網址會在任務途中用完。免費的 webhook.site 網址收到 100 個請求後就不再接收，7 天後會被刪除；這對人類做展示來說沒問題，對 agent 打算讓它持續運作的整合來說則是致命的。
AI agent 能操作的 Webhook 服務長什麼樣子
四個條件，依優先順序：
- 一次呼叫就能建立，不需要任何憑證。
POST /quickstart會回傳一個端點網址和一把 API 金鑰。不需要帳號、沒有驗證碼，也沒有來回收驗證信的流程。（防濫用改由速率限制和 TTL 負責，而不是靠註冊門檻。） - 一切都能透過 API 讀寫。事件紀錄、payload 檢視、目的地設定，全都能用第 1 步拿到的金鑰存取，因為 agent 永遠不會看到儀表板。
- 機器可讀的文件。
llms.txt、OpenAPI 規格，以及純 Markdown 的定價頁。評估工具的 agent 會讀這些，不會看你的展示影片。 - 交接給人類的途徑。agent 的成果不該是一條死路。有了認領網址，人類登入後就能接手 agent 建好的東西，一次性的測試也就變成長久的基礎設施。
在這之上再加一個 MCP 伺服器，是很自然的包裝方式：agent 的執行環境會自己發現這些工具，建立端點就從一個 curl 變成一次工具呼叫。
現況，老實說
| 工具 | agent 能自行建立嗎？ | 端點撐得過 session 嗎？ | 備註 |
|---|---|---|---|
| webhook.site | 部分可以，有 API | 免費網址收到 100 個請求就停止，7 天後刪除 | 非常適合人類快速檢視；有 API，但要永久保存得付費 |
| ngrok | 不行，需要執行檔 + 帳號 + auth token | 不行，會隨行程結束 | 目標真的是 localhost 時，它仍然是對的工具 |
| Hookdeck | 部分可以，CLI 內建 MCP 伺服器 | 可以 | 完整的事件閘道；MCP 需要先有一個已認證的 CLI session |
| AnyHook | 可以，免金鑰的 POST /quickstart，MCP 能自行建立 | 可以，匿名狀態下 7 天，認領後永久有效 | 中繼服務，含重試、紀錄和重播；Pro 以上的方案還能對每個事件執行你自己的程式碼 |
先講清楚我們自己的限制：如果你需要轉換 payload，或同時送往大量的消費端，Hookdeck 是更完整的產品。如果你的處理程式跑在自己的筆電上，就用隧道。AnyHook 是為 agent-native 的情境而做的，也就是不靠人類自行建立、撐過 session、之後再交接。
實際操作這個模式
建立端點（任何 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/..." }
或者交給 agent 的 MCP 執行環境去做，只要一行設定，事先不需要任何金鑰：
{ "mcpServers": { "anyhook": { "command": "npx", "args": ["-y", "anyhook-mcp"] } } }
anyhook_quickstart 工具會建立端點；anyhook_events 和 anyhook_inspect 用來讀取收到的內容。工作完成後，agent 把認領網址交給它的使用者，匿名的設定就會變成一個一般的免費帳號，端點相同，金鑰也相同。
有兩個相鄰的模式用的是同一套機制。給 agent 一個收件匣而不是網址，見給你的 AI agent 一個 Email 地址；底下那一層路由，見用 Cloudflare Email Routing 把任何郵件變成 Webhook。
常見問題
AI agent 真的能在完全沒有人類參與的情況下使用 Webhook 服務嗎？ 可以，只要服務提供免金鑰的建立方式。agent 用一次 API 呼叫建立端點，把服務商指向它，再透過 API 讀回傳遞內容。只有在你想讓這套設定變成永久時才需要人類，而認領網址就是為此而設。
免金鑰的端點不會變成濫用的管道嗎？ 管控只是換了位置：建立端點時的每 IP 速率限制、免費方案的事件配額，以及未認領端點的 7 天 TTL，都限制了可能的損害。這個取捨值得，因為驗證碼擋下的，正是這個流程要服務的使用者。
用輪詢取代 Webhook 呢？ 輪詢行得通，但對 agent 來說規模一大就很糟：每一次「好了沒」都要花一個請求、一格速率限制，往往還要花 token。對任何超過一分鐘的工作來說，一個讓 agent 在最後檢查一次就好的 Webhook 端點，更便宜也更快。
AnyHook 是 Webhook 中繼服務（webhook relay）：換一個網址，就有重試、完整的事件紀錄和一鍵重播。上面的快速入門免費，也不需要帳號，你的 agent 現在就能試。