Meta 用逾五十個專精代理整理資料管線「部落知識」，稱工具呼叫量顯著下降

企業資料管線最麻煩的常常不是 SQL 寫不出來，而是「到底誰知道這段管線為什麼長這樣」。註解散落、Runbook 過期、關鍵決策只存在某個離職員工的腦袋裡——工程圈把這種隱性依賴叫做 tribal knowledge（部落知識）。Meta 在 Engineering at Meta 部落格發表的文章描述了一套用超過五十個專精 AI Agent 協作的內部系統，目標是把這類知識從「人與人傳說」拉回到可被檢索、可被驗證的結構。對正在評估代理式工作流的組織來說，這篇文章最有價值的地方不是炫目的模型名詞，而是它敢寫出 工程指標：例如完成任務時工具呼叫次數顯著下降的量化描述。

這套系統到底解了什麼問題

大型組織的資料管線程式庫往往橫跨數千檔案，依賴關係與商業邏輯交錯。新人或跨團隊支援要上手，典型路徑是串門子、翻舊文件、以及在聊天室裡打撈歷史訊息。Meta 的描述是把這個「人肉知識檢索」試著自動化：讓不同專長的代理分工讀 codebase、整理相依性、補齊文件缺口，並把結果收斂成後續任務可用的上下文。換句話說，它處理的是 知識治理，不是替你把每一行 ETL 重寫。

為什麼要用「很多小代理」而不是一個超大通用代理

這裡牽涉到代理系統設計裡很務實的 trade-off。單一通用代理在面對超大程式庫時，常見失敗模式是工具呼叫爆炸：為了找答案不停嘗試、上下文被無關片段塞滿、最後輸出看似自信其實缺證據。把任務拆給多個專精代理，本質上是在做 搜尋空間裁剪：每個代理的工具權限、目錄範圍與輸出格式更窄，整體系統反而更容易控制成本與錯誤型態。Meta 文章宣稱在任務層級上工具呼叫次數下降約四成，若屬實，這比任何「模型變聰明」的形容都更接近企業買單的理由——因為它直接對應到延遲、費用與故障面。

技術限制：自動整理不等於自動正確

再強的代理系統也無法憑空知道商業決策背後的歷史原因；它只能根據程式碼、設定檔與文件表面線索做推論。這代表輸出必須被當成「候選知識」，而不是「核准真相」。實務上若缺少 human-in-the-loop 的簽核與版本控制，系統很容易把推測寫成定論，反而加速錯誤擴散。Meta 這類內部工程分享通常會假設讀者理解這些防線，但對外讀者而言，這一點必須被放大寫清楚。

對開發者工作流的啟發：RAG 之後的下一層是「可驗證的組織記憶」

許多團隊已經在用 RAG 把文件丟進向量庫；這篇文章提示的方向是，企業內部知識往往不只存在於文件，而存在於 程式與變更歷史 的組合結構裡。若你的代理只能讀 PDF，卻讀不懂 repo，就會永遠在資料工程世界裡缺一角。把代理專長化、並與程式庫導覽工具結合，本質上是在做更昂貴、但更貼近真實的組織記憶體。

與其他公司做法的對照

雲端與 DevTools 廠商近季也紛紛推出「程式庫助理」類產品，差異通常在於：誰能提供更深的工作流整合（CI、Issue、PR、Runbook），以及誰能把成本與權限邊界講清楚。Meta 的分享屬於「我們內部怎麼做」範本，外部團隊不能照抄參數，但可以照抄 問題分解方式：先把「找得到」與「說得對」拆開衡量，再談自動化覆蓋率。

小結：值得偷走的不是口號，是衡量方式

如果你正在導入 AI Agent，建議你用 Meta 這篇文章當成檢查清單：你的任務是否明確到可以分工？你的工具是否過多導致探索爆炸？你有没有把「降低工具呼叫」當成核心 KPI，而不只是看模型回答漂不漂亮？當企業內 生成式 AI 從 demo 走向日常，勝負往往就藏在這種無聊但可量測的工程細節裡。