AI 代理要撐住正式環境：Meta 組織第二大腦、Google 挑戰賽四模式、微軟修補 SPFx 技能落差
engineering.fb.com · 2026-09-02
Meta engineering 部落格於 2026-09-02 說明公司如何把專家腦中的判斷邏輯，轉換成 AI 代理可用的組織知識系統。同一天，Google Developers Blog 整理出 AI Agents Challenge 中撐得住正式環境的四種工程模式；Microsoft 365 Developer Blog 公布測試代理處理 SharePoint Framework（SPFx）升級任務時發現的落差與修補方式。三篇文章分別對應知識治理、多代理架構、技能驗證，回答同一個問題：AI 代理的輸出能不能被生產環境信任。
Meta 的難題：專家判斷留在腦中，寫不進系統
Meta 內部的合規審查團隊長期面對同一種困境：相似問題在數百次產品審查中重複出現，每次評估卻仍要專家花數天手動研究，判斷結果也常因人而異。文章指出，這類專業判斷通常只存在於專家腦中而非任何文件系統，導致組織難以規模化複製，專家時間也被大量消耗在重複性問題上。知識留在人腦裡，就無法被系統化驗證或重複使用。
解法：四層式的組織第二大腦架構
Meta 的做法不是單純依賴 RAG，而是建立四層架構：第一層是 200 多份檔案組成的知識系統，含定義組織立場的 position files、作為權威詞彙表的 taxonomy files，以及對應處理程序的 routing indexes；第二層是與知識檔案刻意分離的「推理配方」（composable recipes），規範多步驟分析流程；第三層是人機協作查核點，讓代理在關鍵步驟交由專家審核；第四層是自動化的自我改進機制，把專家修正轉換成通過回歸測試的更新，整個過程不需要重新訓練模型。
六週後：評估時間從天數降到分鐘
系統經過六週開發後，專家對輸出的信任度達到「幾乎每次都有用」的程度，個別評估時間從數天縮短到數分鐘，多輪改進下來沒有出現回歸問題。因為採用漸進式揭露，只在需要的階段提供指令，每次查詢消耗的 token 減少約 80%。這套架構被認為也能套用到法遵、財務風險、安全審查等仰賴專家經驗的領域。
Google 挑戰賽：真正撐得住的四個工程模式
Google Developers Blog 指出，本屆 AI Agents Challenge 不少團隊自稱做出「multi-agent system」，其實只是單一模型透過提示鏈串接、掛上代理之名。文章從真正打磨過的作品中歸納出四種反覆出現的工程模式，多半建構在 Agent Development Kit (ADK) 與 Gemini 模型之上。能否撐住正式環境，關鍵在底層工程細節，而非稱不稱得上「多代理」。
- Bidirectional MCP：代理同時是工具使用端，也是能被其他代理呼叫的伺服端。某效能監控代理把遙測分析包成
MCP伺服器，讓寫程式的代理直接查詢任務效能，資料庫存取也被限制在固定的工具介面內。 - Event-Driven Concurrency：代理不再排隊等彼此，而是透過非同步事件匯流排對共享訊號做出反應。某臨床監測系統用
asyncio.Queue搭配主題訂閱，步態速度下降 15% 時，CLINICAL.ANOMALY_DETECTED事件會同時觸發多個代理。 - Same-Bar Fallback：備援模型須通過與主模型相同的驗證。某臨床推理代理從
Gemini 3.1 Pro降級到Gemini 3.6 Flash時，兩者都要跑過同一支validate_clinical_response()，確認回覆真的引用臨床指引。 - Tiered Routing：先用便宜判斷擋掉大部分請求，再讓昂貴模型出手。某三層分類器先跑正規表達式，再用溫度 0.1 的 Gemini 做簡易分類，這兩層就能處理 40% 的請求。
微軟的測試：代理升級 SPFx 專案為何失敗
Microsoft 365 Developer Blog 描述 SPFx Dev Skills 這套預覽版技能包，用來引導代理完成 SharePoint Framework 的 Web Part、擴充功能開發，以及在 Heft 與 gulp 兩種建置工具間做出選擇。基準測試中，GitHub Copilot Chat 把專案從 SPFx 1.21.1 升級到 1.22.2——需從 gulp 換成 Heft。五次測試都通過執行關卡，但設定正確率只有 38/85，相依套件更新程度只有 34/50。能跑得動，不代表升級升對了。
修補方式不是加技能包，而是改文件
團隊比較了純基準、加上引導代理查閱權威文件的「反幻覺」技能，以及該技能再加 context7 MCP 伺服器三種做法。真正帶來改善的是修改官方文件：在 CLI 建議前加上警語，並重寫遷移指南，引導代理改用 CLI for Microsoft 365 的 spfx project upgrade 指令，改動以 #10855 與 #10921 兩個 PR 併入文件。改進後，相依套件更新程度提升到 50/50，設定正確率提升到 83/85，文件修正上線後五次測試設定正確率達 85/85。光靠技能包提示還不夠，得同步修正底層文件才補得齊落差。
原始來源：Meta Engineering、Google Developers Blog、Microsoft 365 Developer Blog