這裡的每一條限制都是永久的、刻意的。沒有一條是 bug，而早點知道它們，會改變 你設定這套東西的方式。
如果其實是某一封特定的信沒有被回，那是要做診斷，不是限制的問題： AI 為什麼沒有回信。
它從連接那一刻開始。沒有歷史。
連接信箱啟動的是對新信的監看。連接之前的東西不會被匯入，事後你做什麼都 補不回來。
實際的後果：在你想要覆蓋的期間之前連接信箱。週五連上的信箱，對週四一無 所知；要給它更早的背景，唯一的方法是知識庫。
它只算從它本身寄出的回覆
平台記錄的是它自己寄出的信。同事在 Gmail 或 Outlook 裡打的一段回覆，對客戶 來說是貨真價實的回答，但在這裡不計入 —— 所以那串信仍可能顯示為等待中。
兩家提供方的失靈方式不一樣，把一個說成另一個都不安全。在 Gmail 上，監看掛在 收件匣上，所以他們的回覆根本不會到我們這裡。在 Outlook 上，寄件備份的訂閱 確實會把它送過來，但討論串仍然不會被標成已回覆。
所以在這裡，「沒有回覆」永遠的意思是我能看到的最後一封是對方寄的 —— 永遠不是你欠這個人一封回覆。
在 Gmail 上，它看得到收件匣，僅此而已
監看明確掛在 INBOX 上。跳過收件匣的信 —— 直接被篩進某個標籤，或一進來就
封存 —— 是看不見的。如果你的篩選規則很積極，你最希望被處理的信，可能正是
永遠到不了的那封。
指示屬於智慧體，不屬於信箱
沒有按通訊管道的指示。你告訴智慧體的話，在它回信的每個地方都適用。你可以 把指示寫得自己帶範圍 —— 「在 support@ 上回信時……」 —— 但那是對模型的 請求，不是任何東西會強制執行的設定。
真正需要不同行為的兩個信箱，需要兩個不同的智慧體。
指示攔不住草稿被寫出來
這是大家第一個會試的，而它不如表面上那樣有用。告訴智慧體*「別回行銷信」*， 改變的是回覆的措辭，不是回覆存不存在。一個提示詞要能不產出草稿，唯一的 方法是模型一個字都不吐，而被叫安靜的模型，通常會寫一段客氣的拒絕 —— 那就 成了草稿。
真正攔得住回覆的東西是確定性的，活在程式碼裡，跑在模型之前：自己表明是自動
信件的郵件會被丟棄，來自 no-reply 地址的信只顯示、永遠不寫草稿。那些是
過濾器，不是指示，而且不能按信箱設定。
草稿不是到處都有
在大多數信箱上，待核准的回覆也會寫進提供方的草稿匣。在 Microsoft 365 群組上不會 —— Graph 沒有針對群組對話的草稿 API，所以那些只存在於儀表板上。
也沒有按草稿的信心分數。一封草稿要嘛被分類標記，要嘛沒有；沒有東西為模型的 把握程度評分，任何暗示另有其物的介面都是在憑空發明。
沒設回覆模式，等於自主
如果儲存的模式遺失或無法辨識，後備行為是自主 —— AI 會寄。這是關於哪種 失敗更糟的一個刻意選擇，而它意味著：明確設一個預設值，比假設空的欄位代表 「什麼都別做」要好。
投遞不歸我們管
如果回覆從這裡寄出去了，卻從來沒有送達，那是 SPF、DKIM、你網域的信譽，或 收件方的垃圾郵件過濾器。那些住在你的郵件提供方和你的 DNS 裡。這個產品不 管理、不監控、也不回報它們，這裡沒有任何東西會告訴你某封信被當成了垃圾郵件。