薄型協調者：如何透過減少路由器的負擔，讓 AI Agent 更可靠

單一全能模型易生幻覺，Meta 改用薄型協調者架構

Meta 把 AI Agent 用在自動化數據流程時，發現讓單一模型掌握所有知識，並不是最好的做法。過去團隊傾向建立一個具備全域知識的智慧代理，但在實際生產環境中，這種做法讓系統頻繁產生幻覺。為解決這個問題，Meta 提出「薄型協調者（Thin Orchestrator）」架構，把路由與可靠性檢查，跟領域推理任務分開處理，提升了系統效率與準確性。這個架構的核心，是一個只負責調度的輕量級協調器，搭配 14 個各自處理特定領域推理的專用 Agent，讓自動化流程更穩定。

背景知識過載，效能反而下降

Meta 的數據管線採用程式碼即配置（config-as-code）模式，由 Python 配置驅動 C++ 程式碼生成，再填充分析系統。在自動化數據欄位入網的過程中，單一欄位的變更要跨三個程式碼庫、三種程式語言，並經過最多六個管線階段才能保持同步。初期的單一 Agent 模型在示範中運作良好，但進入生產環境後，當上下文超過某個閾值，額外的知識反而拉低效能。模型會混淆不同子系統的欄位命名慣例，或把專為其他數據源設計的程式碼生成模式用錯地方。

研究指出，多 Agent 系統透過任務隔離，可將準確率從單一 Agent 的 16.6% 提升至 65.3%，Token 使用量最多減少 65 倍。Meta 遇到的正好是相反的情況：單一 Agent 被過多知識淹沒。另一種依賴手動提示工程的單一 Agent 方案，在工程師客製化系統提示時成功率有 70-80%，沒有手動干預時只剩 10-20%。Meta 認定這是架構問題，不是提示工程問題。

薄型協調者與十四個專家 Agent

修正方案是減少中央 Agent 的工作量，建立由確定性協調器與專門子 Agent 組成的雙層系統。協調器負責意圖分類、收集必要欄位、可靠性檢查及委派任務，本身不做任何領域推理，不生成配置，也不接觸程式碼庫。系統包含 14 個專門子 Agent，每個都是擁有隔離上下文的領域專家。例如，架構管理 Agent 熟悉配置註冊表，數據填充 Agent 掌握 10 種數據源的程式碼生成規則，驗證 Agent 則了解建置系統與品質檢查標準。每個 Agent 只看得到局部，這個設計能防止上下文污染。

協調器對每項請求都照固定的七步協議處理：先讀取相關子 Agent 的指令檔案，檢查目標是否已存在以免重複，接著向使用者收集必要欄位，並自動推斷可取得的資訊（如儲存庫類型）。然後進行可靠性閾值檢查，確認是否有活躍警告或需要審核者，再把完整上下文委派給對應的子 Agent，最後處理結果，確認成功或顯示錯誤。其中只有第六步會用到大型語言模型的推理，而且是在只載入該領域知識的隔離子 Agent 內進行，其餘步驟都是確定性操作。

用工作流模板取代新增 Agent

Meta 發現可以把「需要發生什麼」和「如何執行」分開。協調器透過工作流模板定義階段順序，這些確定性狀態機限制了 LLM 的決策空間。例如，數據欄位入網的順序是「架構→驗證→填充→測試」，事件入網是「架構→填充→驗證→測試→事件處理」，管線遷移則包含評估、規劃、填充、驗證與監控。要支援管線遷移這類全新用例時，團隊只要寫新的工作流模板，以不同順序排列現有 Agent，不必寫新的 Agent 程式碼。

每個子 Agent 都遵循標準化結構，包含：執行時載入的知識來源、協調器需要收集的預先清單、領域特定的執行計畫、在單一程式碼庫中尋找相關程式碼模式的發現模式，以及常見失敗的錯誤到解決方案映射。結構一致，新增子 Agent 就能照範本進行。知識檔案在子 Agent 執行時按需載入，不嵌入協調器。系統維護 25 個以上按領域組織的知識檔案，更新後下一個會話自動使用最新版本，不必修改協調器，同一份知識檔案也能服務多個平台實作。

效能提升與應用建議

實施薄型協調者後，新欄位的配置準備時間，從手動作業的三至四天、或早期配置驅動系統的一天，縮短到一小時內。約三分之二的系統變更不需要太多人工編輯就能落地。這個架構放棄通用性，換取深度的領域知識：協調器保持通用，子 Agent 則是專家。

Meta 建議其他團隊套用這個模式時，要把路由與推理分開。如果協調器在做領域決策，代表它的負擔過重，路由應該用關鍵字匹配或意圖分類等確定性方法。子 Agent 應設計成結構一致的專家，讓新增能力只是套用範本，而不是更動架構。擴展新用例時，應先嘗試重新排列現有 Agent 的順序，而不是建立新 Agent。知識應在執行時載入，更新才會即時生效。此外要明確劃分確定性與機率性的邊界：協調器負責確定性路由，子 Agent 負責機率性推理，這樣可以避免重型協調者的幻覺讓錯誤往下游蔓延，提升整體系統的可靠性。