當 AI 代理需要要求批准、報告完成、接收新工作，或在目前程序結束後繼續對話時，電郵和訊息就成為後端基礎設施。管道必須具備穩定身份、傳送狀態、工作流程關聯、重試規則和審計紀錄。
應用程式內通知適合用戶仍然在線的情況。如果交接必須在分頁關閉、代理閒置後繼續存在，電郵會更實用。
溝通基礎設施的四項工作
要求批准
訊息應說明確切操作、資源、範圍、相關成本和批准到期時間。同時有多個請求時，只回覆「好」並不安全。應使用有簽署、用途單一，而且綁定一個操作 ID 的批准操作。
報告完成或失敗
傳送人需要的結果，而不是代理的思考過程。內容應包含工作流程 ID、最終狀態、相關成果或 URL，以及下一個操作。只有收件者有權查看時，才能附上日誌連結。
接收新工作
專用收件箱可以將傳入郵件轉化為代理工作。系統需要寄件者驗證、附件限制、討論串身份、提示注入處理，以及介於收件和執行之間的佇列。收到電郵不應自動授予寄件者執行工具的權限。
協調系統
需要結構化傳送和重試的機器對機器事件，webhook 比電郵合適。需要由人閱讀或回覆時，電郵仍然有用。有些工作流程兩者都需要：webhook 更新系統狀態，電郵則請人作出決定。
AI 代理基礎設施指南把這些管道與數據庫、工具、身份和執行系統放在同一層級，而不是當作 UI 裝飾。
按照交接需求選擇管道
| 需求 | 建議預設 | 原因 |
|---|---|---|
| 更新目前顯示中的工作階段 | 應用程式內事件 | 延遲低，而且已有用戶上下文 |
| 通知不在線的人 | 電郵 | 工作階段結束後仍會保留，並能傳送至已知地址 |
| 傳送結構化系統事件 | Webhook | 設有簽署的承載數據、機器解析和重試合約 |
| 讓代理管理對話 | 專用收件箱 | 穩定地址、討論串和收發歷史 |
| 要求影響重大的決策 | 設有簽署的批准頁面加上通知 | 將同意綁定到一個確切操作 |
當接收端是另一個服務，而且需要嚴格的傳送保證時，不要把電郵當作佇列。應使用 webhook 或訊息系統，電郵只負責人需要查看的部分。
獨立收件箱或後端整合收件箱
以閱讀、分類和回覆郵件為主要工作的代理，適合使用獨立的代理郵件產品。AgentMail就是一個以代理收件箱為核心設計的電郵 API。
如果應用程式原本就需要數據庫、託管、身份驗證和儲存空間，電郵只負責偶爾的通知或回覆，則適合使用整合在後端的收件箱。Cohesivity Inbox 透過同一個項目為租戶提供地址，以及發送、接收、列出、讀取、回覆和刪除操作。暫時租戶的發送和收件者限制較嚴格；認領後會解鎖每月額度和選用的 webhook。
差異在維護方式。以郵件為核心的代理會受益於專用產品更深入的控制；產品代理則可能更適合讓電郵與其他後端資源共用身份和生命週期。
設計訊息合約
每一則寄出訊息都應記錄：
- 租戶、工作流程和操作 ID；
- 收件者與寄件者身份；
- 範本或訊息版本；
- 可取得時的供應商訊息 ID；
- 嘗試次數和最終傳送狀態；
- 訊息代表的外部副作用；
- 預期的回覆或批准操作。
使用冪等鍵，避免中斷的工作流程重複發送同一封批准或完成通知。失敗復原指南解釋如何在重試前釐清結果未知的操作。
將傳入內容視為不受信任
電郵可能包含指示、連結、附件、轉寄的密鑰，以及另一位寄件者的引文。應把它當作數據解析，不能讓郵件文字覆寫代理政策或工具權限。
寄件者與討論串身份要分開驗證；按照類型和大小限制附件；以明確的保留政策儲存原始內容。傳入訊息若要觸發破壞性或財務操作，必須重新取得批准。
在用戶不在線時測試一次交接
在工作流程最關鍵的人工依賴點暫停，關閉應用程式，再傳送通知並按照連結或回覆路徑操作，確認工作流程只恢復一次。接着重複傳送，確認不會重複執行操作。
下方提示會在不傳送任何內容的情況下，找出一項真實工作流程中缺少的交接點。