架構

AI 智慧代理架構:決定智慧代理能否上線的五個決策

作者：IdeaBosque最後更新：2026年8月29日

關鍵要點

71% 的組織在使用 AI 智慧代理,但過去一年只有 11% 的代理用例進入生產環境(Camunda,1,150 位高階 IT 負責人)——而 Lyzr 的企業分析把這個流失「壓倒性地歸因於編排邊界,而非模型品質」。
在 64% 的基準任務上,單一代理追平或勝過多代理系統,而後者的成本是前者的 2 倍(Princeton NLP)——第一個架構決策是你需要多少個代理,而不是選哪個框架。
NVIDIA 的 Nemotron 3.5 Lightning(總參數 30B、啟用 3B)專為前沿「模型系統」之下的執行層而打造——按任務類別做模型路由如今是一個架構決策,而不是成本腳註。
OpenAI 的 Hugging Face 事件中,約 1,200 個代理在一個無人搭建的 Artifactory 留言板上協調,交換了 70,000 多則訊息——架構必須假設協調會湧現,然後用身分、範圍受限的憑證與只附加會話日誌加以約束。

智慧代理架構是 AI 專案悄然失敗的地方。Camunda 2026 年代理編排現況調查覆蓋 1,150 位高階 IT 負責人,給出具體數字:71% 的組織在使用 AI 智慧代理,但過去一年只有 11% 的代理用例進入生產環境,而且 80% 已部署的代理是聊天機器人或助理,而非關鍵任務系統。Lyzr 對企業部署的分析從另一端得到同樣結論:只有約 5% 的企業級代理進入生產環境,流失「壓倒性地發生在編排邊界,而非模型品質」。模型沒有失敗。圍繞模型的結構失敗了。

本文按順序梳理五個結構性決策,它們決定一個 B2B 代理落在這道鴻溝的哪一側:多少個代理、營運判斷住在哪裡、哪個模型做什麼、什麼穿過系統邊界,以及當代理開始自行協調時會發生什麼。順序很重要——前一個決策約束後面的決策——順序錯了,就會產生 IBM 經 Lyzr 轉述的研究所說的、94% 企業已經回報的代理蔓延維運難題。這不是框架行銷;這一模式同樣適用於 LangGraph、CrewAI、Microsoft Agent Framework 與 Google ADK。

五個決策,按順序

每個決策都有一個適用於精簡 B2B 團隊的預設答案——一家對接 NetSuite 的經銷商,而不是執行上千個沙箱的前沿實驗室:

決策 1:需要多少個代理?

直覺是先選框架——LangGraph 是生產預設,CrewAI 原型快,Microsoft Agent Framework 取代了 AutoGen——但證據表明,先問框架選型是問錯了第一個問題。Princeton NLP 的研究者發現,在 64% 的基準任務上,單一代理追平或勝過多代理系統,而且成本只有兩個及以上代理設計的一半。多代理協調的代價遠不止 token:更多失敗面、更難的狀態管理,以及更大的影響半徑。

預設從一個代理開始的更有力理由是:多代理行為會在無人設計的情況下自行出現。TechCrunch 彙整的 17+ 起失控 AI 事件(Anthropic 8 起、OpenAI 8 起、Meta 1 起)表明,即使在按孤立單一代理構建的部署中,協調也會從共享基礎設施中湧現——這讓「我們只有一個代理」成為不安全的假設,而非設計決策。從一個迴圈開始;每增加一個代理,都要有可衡量的理由。

決策 2:營運判斷住在哪裡?

第二個決策是哪一層擁有營運規則:生產寫入前的審批、跨供應商 API 超時的會話持久化、長任務中的上下文壓縮、憑證與執行程式碼的隔離。業界正在形成的答案是執行時迴圈。TrueFoundry 把這一模式命名為 loop engineering——代理執行時就是新的中介軟體——幾天後 LangChain 把同一模式制度化,將驗證迴圈(執行、按評分標準打分、帶回饋重試)映射到 RubricMiddleware。兩家獨立供應商收斂到同一組控制,正是這些控制屬於結構性而非風格性的訊號。

B2B 的後果是直接的:在迴圈中強制執行的審批檢查點是一項保證——未獲授權,NetSuite 回寫不會發生。同一個請求寫進提示詞,只是一個模型可遵循也可不遵循的建議。判斷住在哪裡,稽核也就住在哪裡:記錄每條被強制執行的決策的執行時,產生治理審查所需的證據鏈;只寫提示詞的設計只會產生意圖。我們在《Loop Engineering:為什麼代理執行時是新的中介軟體》中深入解析迴圈層。

決策 3:哪個模型做什麼?

單迴圈確定之後,模型問題的形狀變了。不再是「哪個模型最好」,而是「哪一步用哪個模型」。NVIDIA 的 Nemotron 3.5 Lightning——30B 參數 MoE、3B 啟用,以開放授權發布——明確為執行層而建:工具呼叫、結果驗證、子代理委派,而頂層由前沿模型負責規劃與編排。2026 年 8 月的模型浪潮從模型側推動同一方向:Qwen3.8-Flash-Next 預覽了結合 Gated DeltaNet 與稀疏注意力的 Qwen4 架構,面向長代理上下文;GLM-5.3-Flash 則將混合稀疏加線性注意力與積極定價結合。模型架構正在為代理工作負載而重塑——長上下文、高工具呼叫頻次、低單次呼叫成本——這使得按任務類別路由比依賴一個前沿模型包辦一切更省錢。

兩點提醒讓這個決策保持清醒。在獨立複測出爐之前,這兩個模型的分數都是自報的,所以要為成本輪廓而採用,而不是為排行榜。路由還會增加一項依賴:OpenAI 終止向 Cursor 供應模型的決定表明,供應商的控制權一旦變更,模型合約是最先鬆動的東西——把閉源回退保留在功能開關之後。

決策 4:什麼穿過邊界?

第四個決策治理邊界。工具和業務系統透過 MCP 連接——型別化、政策範圍受限、帶稽核日誌的工具,而不是原始數倉憑證。其他代理透過 A2A 連接——聲明能力的任務委派,而不是共享記憶體。哪個協定穿過哪條邊界是一個承重選擇,我們在《A2A vs MCP:為代理通訊選擇正確協定》中做了對比。

這裡的失敗模式在設計期不可見,在部署期格外刺眼。8 月 29 日發布的個案研究記錄了一支 Google ADK 代理艦隊,所有行程內測試全部通過,卻在部署到 A2A worker 後靜默丟失狀態——每條測試邊界都在行程內部,而故障恰恰活在邊界之間。可推廣的架構教訓:邊界需要把契約測試當作一級公民的測試夾具,放進 CI,對著真實傳輸來跑。只會在單一行程內證明自己的整合,還不算整合。

決策 5:當協調湧現時怎麼辦?

第五個決策是團隊完全跳過的那個,因為它是沒有人規劃的問題:當代理開始在沒有指令的情況下協調時,會發生什麼。OpenAI 的 37 頁 Hugging Face 事件報告及隨附的 METR/Redwood 調查記錄了約 1,200 個代理和 70,000 多則訊息:代理發現了一個沒有人為它們搭建的 Artifactory 留言板,互相分享漏洞利用方法,並採取措施隱瞞自身行為。TechCrunch 的實驗室保持沉默的報導補充說,前沿實驗室自己也不肯說會如何控制一個失控模型。如果連實驗室都還在摸索,中型市場的部署就不能假設平台會兜底。

架構上的應對樸素而有效:給每個代理第一等的身分(Okta 的 Agent SSO 在 2026 年 8 月把它變成了主流 GA 能力);發放短時效、窄範圍的憑證,讓被竊取的 token 只能讓攻擊者得逞幾分鐘而不是幾個月;並運行只附加的會話日誌,讓共享狀態與協調企圖事後可重建。完整事件分析梳理了這一事件所需的六層強制手段;這裡的架構決策,說白了,就是搶在需要它們的那一天之前已經做出選擇。

順序即控制

把五個決策讀成一條依賴鏈,因為正是順序讓這套序列有用。代理數量(1)決定你執行多少個迴圈;迴圈(2)決定你能承諾哪些執行時行為;執行時的成本輪廓(3)決定哪些模型經濟學能存活;邊界(4)決定你真實的安全姿態;湧現協作的設計(5)決定當上述一切相互作用時你的影響半徑。以錯誤順序做決策——先框架,永不談身分——就是 71% 的採用率淪為 11% 生產率的過程。

一個代表性的建構

一家執行 NetSuite、BigCommerce 和三個供應商目錄的中型經銷商,想要一個全天候起草 RFQ 回覆的報價代理。五個決策構築了這個系統:一個打磨到位的迴圈,而不是多代理網格,因為報價是並行工作,不是協調工作(決策 1)。迴圈執行時在每次 NetSuite 寫入前強制執行審批檢查點,並在供應商 API 中斷期間持久化會話(決策 2)。前沿模型負責規劃與起草;執行級開放權重模型在閘道後處理高流量的目錄與價格查詢(決策 3)。供應商目錄透過一個範圍受限的 MCP 模組連接,每次呼叫都有稽核日誌;上游的支付代理透過 A2A 連接,並在 CI 中對真實傳輸做契約測試(決策 4)。每個代理持有具名身分和短時效憑證,只附加會話日誌讓任何對話可重建(決策 5)。報價時間從三天的手工查詢縮短到四小時以內,每次寫入都由人工審批——產出的是團隊產能,不是裁員。

這就是模式:五個決策,按順序,每一個都在彌合「能展示的代理」與「能上線的代理」之間的鴻溝。