Slack 工程師公開了一份架構說明 —— InfoQ 於 4 月 28 日跟進報導 —— 介紹他們如何在長期多 agent 系統中管理上下文。在他們的場景裡,一個應用可以橫跨數百次請求,產生數兆位輸出。標準 agent 框架在每次呼叫之間累積聊天歷史,但在長期生產會話中,這種做法會撞上 context window 的天花板,並在硬上限之前就讓回答品質明顯下滑。Slack 資深工程師 Dominic Marks 描述了替代方案:用結構化的記憶通道、專門的 critic agents、以及一條貫穿全程的蒸餾 timeline,取代「累積聊天日誌」。
整體架構是 coordinator/dispatcher 模式。中央 coordinator 接收請求,並把它們分派給下游的專門 agent —— 由 experts 做實際工作,由 critics 評估 experts 的輸出。critics 是必需的,因為(用 Slack 自己的話)expert 的部分發現「要嘛是憑空編造,要嘛是對資料的嚴重誤讀」。三條結構化的上下文通道承載執行時狀態,而不是無界的聊天日誌。director's journal 存放 director 的結構化工作記憶 —— 發現、觀察、決策、懸而未決的問題、假設 —— 它被形容為「讓其他 agent 不偏離主線的共同敘事」。critic's review 是一份帶可信度評分的發現報告,由 critics 撰寫,指令被收緊到「只對所提交的發現作判斷」—— 不漂移、不臆造。critic's timeline 則從 director's journal、最新的 critic's review 與上一個 timeline 出發,建構一條連貫的敘事:去重,並按可信度加權的證據來解決衝突。
這套模式之所以重要,是因為對短的、單 agent 互動有效的「累積聊天日誌」策略,無法擴展到多步生產工作流。Slack 的設計已經暗示了三件如今對長期 agent 是產業常識的事:必須有 critic agent —— 因為 expert agent 的幻覺率不容忽視;結構化記憶勝過原始聊天歷史 —— 因為它強制做摘要與可信度評分;以及按時間排序的敘事蒸餾 —— Slack 的「timeline」—— 是讓 agent 在數百次請求裡仍然連貫所必需的。該模式可推廣:任何團隊若執行的多 agent 工作流橫跨分鐘到小時而非秒級,都需要某種形式的 director/critic/timeline 劃分,或與之相近的等價物。具體通道名稱與結構會有差異,但三種角色 —— 敘事承載者、可信度評分者、timeline 建構者 —— 極可能在各框架間收斂。
對 builders 而言,三件具體事情。第一,如果你的 agentic 工作流跨越的狀態超過單一聊天視窗,不要只累積訊息歷史 —— 從第一天起就把帶可信度 metadata 的結構化記憶通道設計進來。事後改造這個模式會非常痛苦。第二,被嚴格限定為「只對所提交發現下判斷」的 critic agents,是 Slack 找到的最便宜的反幻覺防線:窄範圍 + 專職角色 + 可信度評分。把它做進你的多 agent 層,別指望 expert agent 能自己抓到自己的錯誤。第三,工程文化有講究:Slack 把這套架構公開發表,意味著未來的開源框架很可能會以 coordinator/director/critic/timeline 為標竿收斂。留意 LangGraph、AutoGen 與 CrewAI 在未來數月裡,把這種模式落成一等抽象。