How Slack Solves AI Agent Memory and Context Management

現代語言模型面臨一個根本的技術侷限：它們在架構上是無狀態的。每當用戶提問時，模型都會以「失忆」狀態啟動，為了營造持續對話的假象，系統必須在每次推理時將整份對話歷史重新發送給模型。這種蠻力記憶戰術對短期應用是可行的，比如寫個快速郵件或問幾個基礎問題。但當任務跨越數小時、需要數百次推理請求、生成MB級別的輸出時，簡單地堆積消息歷史會導致AI回應品質下降、API成本暴增，最終硬性撞上上下文窗口的技術天花板，AI系統會徹底無法工作。

Slack工程團隊在處理內部安全調查時碰到了這個難題。他們構建了一個多智能體系統來自動化調查安全警報，由三個層次組成：Director智能體負責協調整個調查，Specialist Expert智能體從服務器日誌中收集證據，Critic智能體則嚴格審查所有發現。以一個真實案例作為參考點：一名開發者在工作站上安裝了標準軟體包，卻觸發了大規模安全警報。乍看是重大問題，但AI團隊最終發現這是虛驚一場。

Slack的第一個創新是給Director配備一個結構化的「日誌」作為工作記憶。Director不是被動接收原始的專家報告和混亂的數據轉儲，而是被要求持續更新日誌，將其思考分類為六種條目類型：決策、觀察、發現、問題、行動或假設。這個日誌成為整個團隊的共享敘事，所有智能體都能看到它。這個設計非常高明，因為共享精煉的日誌而非原始嘈雜的日誌檔案，使整個團隊對宏觀情況保持一致，避免過多的細節資訊觸發確認偏差。在那個開發者案例中，Director在上午9點34分記錄了關鍵突破：安全警報實際上是因為腳本路徑包含「KMOD」字樣，而非真正試圖執行危險的核心修改。

但從何處保證這些資訊的源頭可靠？這引出了第二個創新：Critic的評審機制。當Expert智能體從日誌中提取資訊時，它可能會幻覺或誤解數據。Critic智能體被部署來審計專家們，使用get_tool_call和get_tool_result等工具直接查看Expert查看的原始數據，以及它們用來得出結論的確切方法論。本質上是在別人做完題目後檢查他們的算數。Slack運行了17萬條發現通過這個批評者系統，結果非常震撼：超過25%的發現未通過可信度閾值，要麼是純粹猜測，要麼完全誤導。這個數據證明了為什麼Critic的嚴格審查是絕對必要的。如果只是將原始AI輸出往下傳，任何長期應用最終都會被hallucination鑽蛀。

第三個創新是時間線。Critic篩選出那些可信的發現後，將它們整合成一條乾淨的、經過驗證的事件時間線，去除重複的數據。如果兩名專家報告同樣的警報，它在時間線上只出現一次。通過嚴格的時間順序規則，任何虛假事件都很難邏輯上融入真實的、帶時間戳的事件序列——就像拼圖，假的拼片根本拼不進去。Critic還故意限制報告的數據空白點不超過三個最重要的，避免Director被無窮的小謎團淹沒。

最後，Slack做了一個激進的選擇：除了這些資源，他們不傳遞任何消息歷史。這完全背離了標準AI框架的做法。通過用日誌、評審、時間線這三個高度專門化的結構化記憶通道取代原始累積的消息歷史，Slack消除了上下文窗口的限制、大幅降低了API成本，甚至反而因為智能體只能看到精煉的已驗證資訊而不是數千行無關的歷史對話，提升了它們的創意和專注力。