AgentMail 處理量突破 10 億封：AI 專用信箱、MCP 與重複寄信問題怎麼解？
AgentMail 共同創辦人宣布累計處理超過 10 億封郵件。本文整理 AI 專用信箱的用途，比較 MCP、SDK、API 與命令列入口，解釋收件通知重送、對話狀態與寄信批准，幫助團隊從可追蹤的小型流程開始導入。
代理替你找到一家供應商，準備申請試用時，卻停在「請查看驗證信」。
因為不少網站登入和商務往返仍依賴電子郵件，所以會搜尋、能填表，還不代表能把流程走完。
AgentMail 提供由程式建立的專用信箱，讓代理有自己的收件地址，也能保留後續對話。共同創辦人 Michael Kim 在十月二十一日宣布，累計處理量超過十億封。
這是服務規模的里程碑，但郵件總量不能直接告訴我們，某個代理是否能正確回信，或會不會重複寄出。
我認為持續對外溝通的團隊，可以先從專用收件、分類與回覆草稿開始。把身份、事件與批准流程接好，才有條件逐步開放寄送。
要知道專用信箱為什麼有幫助，先看它和把你的私人信箱直接交給代理有什麼差別。
AgentMail 專用信箱，解決的是哪個工作缺口？
AgentMail 讓代理有獨立的收件身份，並把郵件和對話變成程式可以管理的工作資料。
依官方產品說明，開發者可以用一次呼叫建立信箱，收發郵件、讀取對話與處理附件。API 是供程式呼叫服務的介面，因此建立信箱可以成為工作流程中的一個步驟。
這對長時間工作的代理尤其有用。假設一個代理負責整理供應商回覆，它可以用專用地址收信，團隊也較容易知道哪些往返屬於這項任務。
如果所有任務都借用同一個人的私人信箱，工作狀態容易和私人對話混在一起。人改了信件標籤，或另一個工具讀走相同訊息，都可能讓流程判斷更複雜。
獨立信箱把這些關係拆開，讓停用某項任務時可以找得到對應地址。但它仍需要一個負責的人，來決定地址可以用於什麼工作、誰能查看以及何時停用。
官方快速入門也區分不同註冊方式。代理可以走程式註冊流程，沒有先連結人類時取得僅能收件的信箱，之後再依流程完成驗證以開放更多權限。
這個差別說明，能建立地址與能對外寄信是不同狀態。團隊在測試時應先看自己的權限，避免把收不到寄送結果誤判為模型沒有理解指令。
官網首頁列出的十億封以上處理量與一千萬個以上信箱，描述的是不同指標。信箱數不等於活躍使用者，郵件數也不等於全部寄送成功，不能把兩者混成同一個成長故事。
共同創辦人的原始公告說，前一年處理量不到兩千萬封。這讓規模變化有了比較起點，但仍是廠商公布的數字，沒有提供每一類工作各占多少的明細。
註冊確認信和商務對話，為什麼需要不同狀態？
註冊確認信通常服務一次性的驗證，商務對話卻可能來回多天。兩者都進入信箱，但流程需要記住的事情不同，不能只用「已讀」作為所有工作的終點。
對驗證流程，應知道連結對應哪個服務、是否仍有效，以及完成後帳號呈現什麼狀態。對商務對話，則要知道誰正在等待誰，最新附件是否已經被處理。
信箱的訊息和對話分組提供了保存關係的地方。開發者仍要把自己的案件狀態接上，讓代理每次回來時，不必只靠整段文字猜測目前進度。
例如，一封新信可能只是補上附件，並沒有推翻先前已確認的價格。若模型只看最新信件，可能漏掉原本約定，所以讀取範圍應按工作所需安排。
反過來，讓代理每次讀完整信箱也會增加無關資料。用專用地址與案件關係縮小範圍，能讓模型取得足夠背景，也讓人更容易查出它為什麼這樣回答。
這種設計的成果，可以由交接測試看出來。換一個代理或人工接手後，若仍知道哪些問題已答、哪些尚待對方回覆，就代表狀態保存在系統裡，而非只留在一次對話中。
對準備導入的人，較有用的問題是自己的任務如何收信、保留上下文和完成回覆。身份建立好之後，才需要選擇程式從哪個入口操作它。
MCP、SDK、API 與命令列，應該如何選擇？
由誰決定寄信，決定了最合適的入口，而信箱本身可以由不同入口共同存取。
團隊在十月二十二日發布的官方介面比較中，建議模型選工具時用 MCP，程式決定流程時用 SDK。
MCP 是讓 AI 客戶端取得外部工具的一種共同介面。使用者在對話中交辦任務，模型可以從工具清單選擇讀信或回覆，適合仍需要彈性判斷的工作。
SDK 則是開發者匯入程式的工具套件。什麼時候收信、何時起草、哪些條件可以寄出，都可以由既有程式決定，重試和錯誤處理也能放在同一處。
如果團隊只想在訂單系統確認後寄出固定通知，SDK 或直接 API 呼叫通常比較容易描述清楚。因為寄送時機早已確定，沒有必要再請模型自行選擇。
相反地，若工作是讀取一段往返，再判斷需要補問什麼資料，模型工具入口更符合這種互動。但團隊仍可以把最後寄送留給人批准，讓理解和行動分成兩步。
API 適合沒有對應套件的語言與服務整合。命令列則把同樣能力放進終端機，方便已經透過命令工作或執行排程的代理呼叫。
這些入口會碰到同一個信箱，所以不是選了 MCP 就失去程式查詢能力。團隊可以讓模型起草，再由服務程式記錄狀態與寄送結果，按責任分工。
但介面不同也意味著身份驗證和可達功能需要分別核對。不要因為某個入口能收發郵件，就假設所有管理操作都以相同方式提供，應查對應工具與權限說明。
對新手而言，第一次不必全部接上。先選一種最符合工作決策方式的入口，走通收件到回覆，再補其他介面，較容易定位失敗原因。
入口選對之後，流程仍會遇到一個常見問題：同一封信可能被系統通知不只一次。
為什麼同一封信，可能讓代理回覆兩次？
通知重送是郵件系統必須預先處理的情況，不能只期待模型記得自己剛做過什麼。
服務的官方去重說明指出，收件通知採至少送達一次的方式，接收端若沒有及時回覆成功狀態，通知就可能重送。
這裡的 webhook 是服務主動通知另一個程式的機制。例如新信到達時，系統傳一個事件給你的服務，讓它不必一直詢問有沒有新信。
問題是模型回覆可能需要時間。若服務等模型想完、寄完信，才回覆「已收到事件」，就可能超過通知的等待時間，讓同一事件再次抵達。
代理若把第二次通知當成新工作，客戶就會收到兩封相同答案。從收件者角度看，系統像是失控；從程式角度看，則是沒有記錄已經做過的事情。
官方把處理原則放在冪等性，也就是同一工作執行兩次，結果和執行一次相同。這個詞聽起來抽象，用在郵件上就是重試不應變成重複寄出。
實作時需要分清通知事件和原始郵件。事件識別碼可以幫忙排除同一次通知重送，郵件識別碼則讓程式知道內容屬於哪封信，兩者服務不同層次。
團隊也需要在代理採取動作前保存工作狀態。因為服務可能在寄信後、寫入完成紀錄前中斷，只靠一句「處理完成」容易在恢復時又寄一次。
對一般產品負責人，不必親自寫這些程式，但可以把驗收問題講清楚：同一事件送兩次會怎樣，寄送途中斷線後如何確認，以及人工重跑會不會多寄。
這些測試比只看一次成功畫面更能反映可靠度。第一次展示通常走順利路徑，實際服務卻必須承受通知延遲、重新連線與中途恢復。
這項服務提供信箱和事件能力，工作服務仍要正確記錄狀態。這份責任分工釐清後，下一個問題才是來信內容能不能直接指揮代理。
收到驗證信，是否代表代理可以自行辦完所有事情？
能讀信只代表取得一份資料，後續能不能付款、簽約或修改帳號，仍應由任務授權決定。
例如供應商回信附上一個新付款連結，代理可以整理金額與要求，卻不能只因對方寄了信，就自行改掉原本核准的付款流程。
這個限制來自郵件的角色。信件是外部來源，寄件者可能描述真實需求，也可能有錯誤或惡意內容，所以收信工具不應同時成為放寬操作規則的入口。
若團隊用專用地址辦理試用，應先說明可註冊哪些服務、可接受哪些條款，以及遇到付款或額外驗證時由誰接手。這讓代理在流程中斷時有明確下一步。
驗證連結也應放回原本任務核對。收件者、服務名稱與正在進行的註冊是否一致，能幫助團隊區分預期信件與無關訊息，降低自動點開所有內容的需要。
對客服流程，則可以先讓代理分類問題並起草回覆。若涉及退款、帳號權限或對客戶的承諾，再交回人處理，這樣能保留最有價值的自動整理，也看得見決策者。
對採購流程，郵件往返還應和訂單或案件編號連在一起。因為同一家供應商可能同時回覆多項工作，只靠相似主旨，容易把新的報價放到錯誤案件。
專用信箱的對話分組與訊息能力提供了保存上下文的基礎，但業務系統仍要知道這段對話對應哪項工作。這部分做清楚，代理才不會每次都從零猜測。
來信附件也應按工作需求處理。需要整理報價時，保留檔案名稱、來源與處理結果，能讓人回到原件核對，避免只剩模型摘要而失去細節。
這些安排不是要把每封信都變成人工審查。目的是讓低影響的分類與整理持續執行，讓會改變權利或支出的步驟有清楚責任。
當身份、狀態與操作邊界都看得見，團隊就能設計一個規模小、結果可比較的試點。
延伸閱讀：1Password for Agents：讓 AI 登入帳號，密碼為何不用交給模型？
第一次導入 AgentMail，應該怎麼判斷是否有效？
先讓代理處理有限種類的收件，保存完整對話與人工修改，再決定是否開放有限寄送。
一個可行的起點，是把固定來源的通知寄到專用信箱，請代理擷取日期、案件名稱與需要的人類動作。因為答案容易回到原信核對，團隊能較快看出遺漏與誤判。
第二階段可以加入回覆草稿，觀察需要修改哪些句子。若代理常漏掉對方的限制條件，應先調整資料與流程，不能只靠換更積極的語氣來掩蓋理解問題。
等內容穩定後，再考慮開放固定範圍的寄送。例如只寄給已知對象、只用核准格式，並保留寄出時間、收件者和對應原信，讓追查有完整線索。
試點也要刻意測通知重送和服務重啟。因為一個流程能持續運作，需要的不只是模型會寫信，還包括系統能在失敗後恢復，而且不把同一工作做兩次。
官方快速入門提供免費測試額度，但實際方案、信箱與郵件限制可能調整。開始前應以當日文件核對，並把使用量和業務成果分開記錄。
成果可以看每件工作減少多少人工搬資料，哪些回覆仍要重寫，以及錯誤能否回到原始郵件解釋。這比把總信量當成進步，更接近團隊付出與得到的差別。
也應保留停止方式。某個任務結束後，對應信箱和外部連接要有人接管，否則代理停止工作，新的郵件仍可能繼續進來，變成沒有人看的工作入口。
AgentMail 的十億封里程碑說明代理郵件基礎設施已累積相當使用量。對個別團隊，價值仍要由一段可重現、能追查的工作流程證明。
延伸閱讀：Grok Bot 更新整理：自己的信箱、Shopify 與草稿審核，代理更接近日常工作
AgentMail 常見問題 FAQ
AgentMail 是替我整理 Gmail 的工具嗎？
它的核心是提供代理專用信箱與程式介面。是否接入既有公司信箱，是另一個整合問題，不能和建立新地址混為一談。
AgentMail 的十億封，是十億名使用者嗎？
不是，這是官方公布的郵件處理量。信箱數、活躍使用者與郵件送達率都是不同指標。
接上 MCP 就不用處理重複寄信嗎？
仍要處理通知重送、工作紀錄與寄送狀態。工具入口讓代理能呼叫功能，可靠的恢復流程則需要由系統設計完成。
結語：代理有地址之後，還需要可追蹤的工作流程
AgentMail 適合想讓代理持續收件、處理對話的團隊。若只是偶爾起草一封信，先用既有工具可能更簡單。
可以從固定來源收件與回覆草稿開始，確認身份、去重和人工修改都留得下來，再擴大寄送。想持續掌握 AI 代理工具與實際導入方法，歡迎免費訂閱 AI 郵報。
