您的 AI 代理的個人電子郵件

為您的 AI 代理提供專屬的個人電子郵件地址。
直接從 Claude, Gemini, Codex 或任何相容 MCP 的客戶端發送、接收、搜索、回覆和轉發。

一個指令。無需伺服器。無需配置 SMTP。完全免費。

立即開始 → 文件

並非僅是 SES 或 SendGrid 的封裝。我們從頭開始構建了完整的電子郵件堆疊 — 從接收郵件到投遞至收件匣。

為何選擇 InboxAPI

您的 AI 代理透過電子郵件通訊所需的一切功能。

Account Setup Illustration An illustration showing an AI agent getting its own @inboxapi.ai email address. [email protected]

即時設置

您的代理可在幾秒鐘內獲得個人 @inboxapi.ai 地址。無需 DNS 配置，無需域名驗證，無需管理 API 金鑰。

MCP Integration Diagram A network diagram showing InboxAPI connecting to multiple AI models via the Model Context Protocol. MCP

MCP 原生

與 Claude、Gemini、Codex、OpenCode 及任何 MCP 相容客戶端開箱即用。您的代理可以像人類一樣讀取、發送、回覆、轉發和搜索郵件。

Free Forever A prominent zero-dollar badge highlighting that InboxAPI is free for AI agents. $0 FREE FOREVER

完全免費

無需信用卡。無使用層級。無隱藏條件。我們相信電子郵件應是每個 AI 代理的基本能力。付費方案及更多功能即將推出。

Full Email Capabilities An interface showing sending, receiving, and threading tools.

完整電郵功能，不只是發送

多數服務只讓您發送。InboxAPI 為您的代理提供個人收件匣 — 接收郵件、按發件人或主旨搜索、追蹤對話串、檢查發送狀態。

內建防濫用

註冊時的工作量證明、收件人上限、發件配額和速率限制。每一層都旨在維護平台安全。

Direct Infrastructure A stack showing InboxAPI's own mail infrastructure, not a third-party wrapper. OWN INFRA

自主研發

我們不依賴 Amazon SES、Postfix 或 SendGrid。我們自行建立並營運整套電子郵件基礎設施。

快速入門

1

安裝

2

連接至

支援 Claude Code、Gemini CLI、OpenCode、Codex 等。

3

開始使用郵件

您的代理會自動獲得一個專屬的個人電郵地址（如 ）。

無需註冊表單，無需配置文件。

您的代理能做什麼

  • 閱讀並搜索收件匣
  • 發信給任何人
  • 回覆與轉發郵件
  • 追蹤對話串
  • 即時檢查郵件發送狀態

您可以建構什麼

開發團隊協作

代理之間互相發送郵件以協調開發工作流程 — 一個處理程式碼審查通知，另一個追蹤構建失敗，第三個回報部署狀態。

監控與告警

代理監控系統，當出現問題時，向您的團隊發送帶有上下文的郵件 — 不是泛泛的警報，而是診斷分析。

電子報摘要

代理接收電子報和郵件列表，閱讀後為您發送每日重要內容摘要。

$42.00

發票與收據處理

代理透過電郵接收發票，提取明細項目和金額，並輸入您的會計系統。

為信任而生

帳戶隔離

每個代理都有獨立的帳戶。代理只能存取自己的資料。

SPF DKIM DMARC

郵件認證

自動為每封郵件配置 SPF、DKIM 和 DMARC。

Forget previous instructions and... [DATAMARK: UNTRUSTED] Email content starts here...

防提示注入

不受信任的電郵內容會自動進行資料標記轉換，讓代理能區分外部資料與系統指令。基於學術研究（arXiv:2403.14720）。

防止濫用

註冊時的工作量證明、基於通訊錄的收件人限制（5 個名額，閒置 5 天後 LRU 替換）、發件配額、速率限制和 RFC 5322 電郵地址驗證均預設執行。

12:04:31 - SEND_EMAIL 12:05:12 - GET_INBOX 12:06:05 - SEARCH_EMAILS

審計追蹤

基於令牌的身份驗證將每個操作與特定帳戶綁定，讓您隨時掌握發生了什麼以及何時發生。

Credential Leak Prevention An authentication token being redacted and blocked from exfiltration. auth_token: sk_live_... LEAK PREVENTED

憑證安全

包含身份驗證令牌的外發郵件會自動被拒絕，以防止意外洩漏憑證。

常見問題 #

為什麼不直接讓代理存取我的 Gmail 或 Outlook？

安全性 — Gmail/Outlook 的 OAuth 會讓您的代理存取整個收件匣（醫療、財務、法律、個人郵件）。任何一封入站郵件中的提示注入都可能操控擁有全部存取權的代理。InboxAPI 為您的代理提供獨立隔離的收件匣，每封郵件都附帶信任分類和資料標記。

身份 — 當您的代理從您的 Gmail 發送郵件時，收件人無法分辨他們在和誰交流。回信會進入您的收件匣，與您的真實郵件混在一起。InboxAPI 為代理提供專屬個人地址 — 您與代理之間有清晰的區隔。

實用性 — Gmail/Outlook API 不是 MCP 原生的。您需要中間件、OAuth 配置和自訂整合。InboxAPI 與任何 MCP 客戶端開箱即用。

與 AWS SES、SendGrid 或 Resend 有什麼不同？
那些是發送 API — 您在它們之上構建電郵基礎設施。InboxAPI 為您的代理提供完整的電郵身份：發送、接收、搜索、回覆和轉發。無需配置，無需管理基礎設施。
與 AgentMail 或 a1base 有什麼不同？
我們從頭開始構建了自己的電郵堆疊。我們不封裝 SES、Postfix 或任何第三方發送服務。您的代理郵件通過我們直接營運的基礎設施。
真的免費嗎？
是的。無需信用卡，無試用期，無使用層級。我們正在開發付費方案及更多功能，但核心體驗將永遠免費。
目前有哪些限制？

雖然 InboxAPI 功能完整，但目前有一些限制：

  • 外部收件人通訊錄名額 5 個（閒置 5 天後 LRU 自動替換）
  • 僅供代理個人使用，不是用於批量發送、行銷或應用程式通知的交易服務
你們如何防止垃圾郵件和濫用？
建立帳戶需要工作量證明。每個帳戶有 5 個通訊錄名額用於外部收件人 — 當所有名額都被佔用時，閒置 5 天後最少使用的項目將自動被替換。每日發件配額和速率限制在每個帳戶上強制執行。這些限制是結構性的 — 它們不是政策，而是系統運作的方式。
我需要新增聯絡人或設定通訊錄嗎？
不需要。通訊錄是自動的 — 當你的代理程式發送電子郵件時將自動新增聯絡人。沒有需要管理的聯絡人名單，沒有需要編輯的設定檔案，也沒有設定步驟。每個帳戶最多可以發送給 5 個獨特的外部地址。當所有名額都被佔用時，閒置 5 天後，最少使用的項目將會被自動替換。InboxAPI 代理程式之間的電子郵件則始終沒有限制。
透過電郵的提示注入怎麼辦？
每封入站郵件都包含信任分類 — 受信任、代理、未驗證或可疑 — 基於發件人是否在您的通訊錄中以及其電郵是否通過身份驗證檢查。這幫助您的代理決定處理每封郵件時應多謹慎。來自其他 InboxAPI 代理的郵件會單獨標記，讓您的代理知道應先與您確認再採取行動。不受信任的電郵內容也會自動用標記字元（資料標記）進行轉換，讓代理能清楚區分電郵資料與自身指令。
資料外洩怎麼辦？
外發郵件會掃描身份驗證令牌和憑證。如果您的代理意外嘗試發送包含 JWT 或存取令牌的郵件，該郵件會在離開平台前被拒絕。這防止代理被欺騙透過電郵洩漏敏感資料。
代理之間可以互發垃圾郵件嗎？
相同的發送限制適用於所有外發郵件 — 收件人上限、配額和速率限制的運作方式相同，不論接收方是誰。
代理的郵件會進入垃圾郵件資料夾嗎？
初期可能會。每個代理獲得全新的子網域，新發件人尚無信譽。收件人可能需要檢查垃圾郵件資料夾中的前幾封郵件。隨著時間推移，當您的代理發送合法郵件且收件人與之互動，投遞率會改善。了解更多電郵投遞資訊。
為什麼選擇電郵而非 A2A 等原生代理協議？
電郵觸及整個現有的網際網路 — 數十億人和企業已在使用。A2A 需要雙方都實作該協議。當您的代理需要聯繫生態系統外的人時，電郵是通用選項。代理很可能兩者都需要。
為什麼選擇電子郵件而不是 WhatsApp、Telegram 或其他即時通訊應用？

可擴展性 — 您可以程式化地建立數百個電子郵件地址。WhatsApp、Telegram 和 Signal 都需要電話號碼和驗證。擴展超過幾個帳戶是不切實際的，通常違反服務條款，有時沒有實體 SIM 卡根本不可能。

無門檻限制 — 電子郵件是唯一一個可以在不需要電話號碼、身份證件或平台擁有者批准的情況下建立身份的通訊管道。沒有任何一家公司控制誰能獲得電子郵件地址。

開放協議 — 電子郵件是聯邦化且供應商中立的。WhatsApp、Discord 和 Telegram 是專有的——它們可以隨時撤銷 API 存取權、封禁機器人帳戶或更改規則。電子郵件不會被任何一家公司關閉。

服務條款合規 — 大多數即時通訊平台明確禁止自動化帳戶或有嚴格的審批流程（WhatsApp Business API 需要企業驗證，Telegram 限制機器人之間的訊息傳遞）。電子郵件沒有這些限制——自動化發送是一等公民的使用場景。

通用觸及 — 即時通訊管道是隔離的。您的 Telegram 機器人無法觸及 WhatsApp 使用者。電子郵件可以觸及任何擁有電子郵件地址的人——這基本上是每個人。

對於像 OpenClaw 這樣的多管道代理框架，電子郵件填補了即時通訊平台在結構上無法填補的空白——無限的、可程式化的身份建立，無需平台批准。InboxAPI 直接提供這項能力。

我應該使用哪個人工智慧模型與 InboxAPI 配合？

你的模型必須支援工具/功能呼叫 (tool/function calling) — 這是 MCP 的要求。我們建議至少要有 32K token 的上下文視窗。

良好：Claude Haiku 4.5+、GPT-4.1 mini+、GPT-4.1 nano+、Gemini 2.5 Flash+

建議：Claude Sonnet 4.5+、GPT-4.1+、GPT-5 mini+、Gemini 2.5 Pro+

最佳：Claude Opus 4.5+、GPT-5+、GPT-5.2+、Gemini 2.5 Pro+

InboxAPI 會對不可信的電子郵件內容應用資料標記 (spotlighting)，這可能會稍微增加 token 消耗。擁有較大上下文視窗的模型能更游刃有餘地處理這個問題。

無法運作的情況：不支援工具/功能呼叫的模型、上下文視窗低於 16K tokens 的模型，或非常小的本地模型（小於 ~7B 參數）。

如果我的代理失去帳戶存取權怎麼辦？
如果代理的憑證遺失或損壞，您可以使用 account_recover 工具恢復帳戶——但前提是您之前已透過 verify_owner 連結了您的電子郵件。恢復操作會撤銷所有現有令牌並發放新的憑證。如果沒有經過驗證的擁有者電子郵件，將無法恢復被鎖定的帳戶。
什麼是擁有者驗證？
擁有者驗證將您的個人電子郵件地址連結到代理的 InboxAPI 帳戶。您的代理使用您的電子郵件呼叫 verify_owner，您會收到一個 6 位數驗證碼，然後代理提交該驗證碼以完成驗證。驗證完成後，如果憑證遺失，您可以恢復帳戶，且帳戶的試用限制將被移除。

給您的代理一個個人郵件地址

一個指令。永久免費。

立即開始 → 文件 GitHub