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