Claude 常駐代理架構指南：事件、記憶與通知怎麼接，才能持續工作又不洗版？
Claude 常駐代理指南解析事件收件匣、計時器、持久記憶、權限與寄件匣。說明如何休眠與恢復工作、等待使用者確認，並減少重複操作和不必要通知。
代理每天替你查看工作進度，若每次醒來都忘記上次做了什麼，或一有小變化就重複通知，長時間運行反而會增加負擔。這類問題往往發生在模型外面的工作安排。
Claude 在 2026 年 11 月 13 日公開常駐代理的架構指南，說明如何用事件收件匣、計時器、記憶、權限與寄件匣，支撐跨多次執行的工作。
常駐描述的是使用體驗。代理多數時間可以休眠，收到事件才醒來，完成工作後保存進度，再等待下一次觸發，無需讓模型整天持續生成內容。
這次消息是一份開發指南，提供元件如何合作的設計，沒有宣布新模型或一項所有帳號立即可用的服務。實作仍由應用團隊安排儲存、工具與授權。
我會建議已有單次代理流程的團隊，先補上事件與狀態管理，再增加主動行動。能恢復工作、避免重做，並知道何時保持安靜，比先增加排程數量更重要。
要讓這個循環可靠，得先處理事件到來的入口。相同事件不能因重送而做兩次，不同事件也不應隨意啟動互相覆寫的工作。
事件先進收件匣，才能去重與恢復工作
收件匣把事件保存下來，再由工作程序領取，避免每個來源直接啟動代理。這個入口可以接訊息、程式系統通知或其他工作變化，將它們整理成同一種待處理紀錄。
官方建議的基本組合，是持久資料庫、接收請求的處理程式與背景工作程序。持久表示程序停止後資料仍在。入口先確認收下事件，再由工作程序處理較長工作，減少來源因等待太久而重送。
重送仍需要另外處理。每個來源若提供唯一事件識別碼，就能把它作為去重依據，避免同一通知到兩次，代理就做兩次修改。只比較訊息文字並不充分，因為內容相同也可能是不同時間的合理事件。
同一個收件匣也需要限制同時工作的程序。若兩個工作程序都讀到相同進度，再各自更新結果，就可能發生重做或覆寫。一次由一個工作程序接手，可以讓任務狀態比較容易理解。
代理醒來時應讀取最新收件匣，而不是只相信喚醒訊號附帶的一小段內容。訊號負責提醒有工作，資料庫則保存真正待處理的項目。程序中途失敗時，後者也讓重試有依據。
新事件到來時，是否接回同一段對話，需要看它與原任務的關係。使用者回答剛才的確認問題，可以接續原對話。完全不同的新工作，則不必把所有舊紀錄都帶進來。
收件匣也能先合併短時間內相關訊息，讓代理一次理解完整情況。這能減少使用者每補一句話，就收到一次打斷式回覆。入口可靠之後，排程也可以使用相同的事件路徑。
計時器負責何時喚醒，工作仍由事件接續
追蹤期限與固定排程各有狀態，排程器在到期時把它們轉成可執行事件。這樣，定時工作與外部通知可以沿用同一套處理流程。
一次性的追蹤，例如明天下午確認某個任務是否完成，應保存到期時間與是否已處理。週期性的工作則要在完成後計算下一次時間，不應只把原事件放回去，讓它在每次醒來時重複到期。
官方將計時器表與收件匣分開。計時器保存未來該發生的事，收件匣只放現在可處理的工作，排程器定期查看到期項目，再產生事件喚醒工作程序。
這個區別讓系統不必為每個未來工作維持一段持續運行的模型對話。代理多數時間可以休眠，到期再重新取得所需狀態，符合常駐體驗而不是持續計算。
例如每天早上檢查一份工作清單，排程只負責提醒該檢查了。清單現在是否有變化、是否已有人處理，以及需要不需要通知，仍由醒來後的工作決定。時間到了，並不等於一定有值得發送的結果。
程序重啟時，也應能分辨哪些計時器已經轉成事件，哪些還沒到期。把這些狀態保存下來，比依賴某個程序記憶體中的倒數更容易恢復，也能讓人查到為什麼今天醒來兩次或沒有醒來。
喚醒時機確定後，代理還需要知道上一次留下什麼。沒有可延續資訊的排程，只會反覆啟動同一個不知道前情的新工作。
記憶保存可延續的資訊，對話壓縮只是另一件事
記憶應存使用者規則、必要筆記、已回覆內容與任務進度，讓程序重啟後仍可接續。官方以檔案形式說明，也可以把實際儲存對應到資料庫或物件儲存。
使用者規則適合在需要時穩定載入，例如哪些事項值得通知、哪些動作必須先確認。較大的筆記與過去訊息，則可以用索引查找，避免每次啟動都把所有歷史塞進模型。
任務進度尤其需要分清已完成、等待與失敗。若只留下「處理了這件事」，下一次可能不知道結果是否已送出、是否等使用者回答，或只是做到一半。進度應足以決定下一步，而不只是描述曾經活動過。
官方也建議不要把隨時能重新查到的資料全部複製成記憶。若工單系統已保存正式進度，記憶可以留下指向該工單的資訊，避免兩份內容各自更新，最後不知道哪份才準確。
對話壓縮則處理另一個問題：把很長的對話縮成較短脈絡，讓後續執行繼續進行。壓縮可能省略細節，開新對話也會失去部分內容，因此不能把它當成持久保存的替代品。
系統提示、工具定義與記憶都會占用上下文，也就是模型一次可處理的內容空間。讓常用資訊精簡，有助於控制每次醒來的負擔。重要狀態仍要保存到模型之外，而非只期待它長期記得。
已有記憶後，仍需要定期確認它是否過期。工作已結束，等待事項就應更新。使用者改了通知偏好，也應讓新規則取代舊規則。有狀態不等於有權限，持續工作還需要限制可執行的動作。
需要確認時保存現場，讓工作等得到人
敏感憑證、操作判斷與延後工具呼叫，可以讓代理在等候核准時保留工作狀態。常駐時間變長，並不表示代理應取得更寬的操作權。
官方描述以憑證代理處理秘密：把金鑰留在執行環境外，由工具請求經過代理時注入。模型可以要求允許的工作，不必直接看見原始憑證，減少把秘密放進對話紀錄的需要。
但藏住憑證仍不等於每個請求都合理。工具需要知道目前任務可做哪些事，重要操作仍應交給使用者確認。自動分類有助於判斷部分風險，不能概括成所有動作都能自行核准。
當工具需要確認，系統可以把呼叫延後，保存停在工具中間的對話狀態，再結束這次執行。使用者回答之後，回答成為新的收件匣事件，工作程序才接回原本對話繼續。
這比讓模型在原地不斷詢問或等待更適合長時間工作。等候核准的任務可以保留，工作程序也能處理其他已獲准的事項，不必因一個人尚未回覆就阻塞全部工作。
恢復時仍應確認回答對應哪個操作。若使用者只同意一個範圍，就不應套用到另一個任務。如果原定條件已改變，也需要重新判斷，不能僅因收到「好」就執行所有累積動作。
因此，可恢復的等待需要任務識別、等候核准的內容與狀態一起保存。動作有結果後，才輪到決定哪些內容值得打擾使用者。
寄件匣把完成工作與發送通知分開
需要控頻或恢復傳送的系統，可以用寄件匣與派送程序管理對外訊息。它將代理產生結果，和使用者實際收到通知，拆成可追蹤的兩個階段。
例如代理已完成一次檢查，但通知服務暫時失敗。若結果只存在對話裡，重試時可能整個任務再做一次。保存待發內容與傳送狀態，就能只重試傳送，避免重做原本已完成的工作。
派送程序也可以合併相近訊息、依偏好控制時間，並避免相同結果反覆出現。不過官方沒有要求所有簡單應用都必須建立完整寄件匣。如果直接發送足以符合需求，也可以先採簡單方式。
關鍵是把是否完成工作，與是否需要發通知分開判斷。定期醒來後沒有實質變化，可以什麼都不說。若有明確完成、失敗或需要使用者處理的事項，再發出有用的訊息。
通知過少也可能漏掉重要問題，所以保持安靜不是唯一目標。團隊需要準備應通知與不應通知的案例，查看代理是否知道差別，而不只統計一天發了幾則。
對長期使用者而言，訊息的可操作性比活動感更重要。「已檢查但沒有變化」若每天重複出現，會稀釋真正需要注意的通知。通知量也需要評測，才能知道少發或多發對使用者的實際影響。
用重送、重啟與不必通知的案例驗收
第一次測試應包含正常工作之外的中斷與重複事件，檢查系統能否維持同一個任務進度。這是在驗證架構，不需要先增加大量工具或更長排程。
可以先用不會改變外部狀態的任務，測試同一事件送兩次是否只處理一次。再讓工作程序在中間停止，檢查重啟後能否讀回進度，而不是從頭重做所有已完成步驟。
等候核准也要單獨測。先確認待處理操作完整保存，再用一個明確回答恢復，檢查它只接續原任務。若過期回答或另一個任務的回答也能放行，就表示狀態關係還不夠清楚。
最後加入沒有變化的情境，確認代理可以完成檢查並安靜結束。把完成、等待與已通知三種狀態分開記錄，才能在使用者說「怎麼又提醒一次」時找出原因。
當狀態與通知都能被核對，再逐步放寬主動行動範圍。可靠的常駐體驗，來自多次短執行能正確接續，而非一次把任務交給模型後永遠不再管理。
Claude 常駐代理常見問題
常駐代表模型二十四小時不停運算嗎？
不代表。指南的代理大部分時間可以休眠，收到事件才執行，完成後保存狀態再等待。長時間工作靠多次執行接續，不需要讓模型整天生成。
這是新增一項所有帳號能開啟的服務嗎？
這次是一份架構指南，沒有宣布新模型或全面開放的產品開關。儲存、排程、工具與權限仍由實作團隊安排，不能只讀指南就假設系統已具備這些能力。
對話壓縮之後，就不需要額外記憶嗎？
仍需要保存關鍵進度與規則。壓縮協助控制當次脈絡長度，持久記憶則讓重啟與新對話能接續，兩者負責不同問題。
寄件匣是必要元件嗎？
需要控頻、重試與可恢復通知時，它提供清楚狀態。簡單流程可以直接發送。應先確認需求，再決定是否值得增加一層派送管理。
已有代理的團隊可以先補一條能恢復的事件流程，再擴大主動工作。讓它記得已完成什麼、等待誰，並在沒有實質變化時保持安靜，常駐才會減少日常負擔。
延伸閱讀：Anthropic 拆解代理記憶：Dreaming 如何修正筆記，為什麼不是記愈多愈好？
延伸閱讀：Claude Managed Agents 開放自架私人測試：控制服務、憑證與紀錄放在哪裡？
