為什麼AI代理無法擴充套件：這是一個工程問題，而非AI問題

AI代理的擴充套件問題並非源於大語言模型（LLM）的能力不足，而是一個系統工程挑戰。當代理從演示階段進入真實使用者環境時，基礎設施的複雜性迅速凸顯。

首先，使用者行為的不可預測性是第一大障礙。當LLM直接面向消費者時，使用者可能做出各種意想不到的操作，因此需要一層規劃器來約束LLM的執行路徑。當前許多工具如Claude Code、Cursor和Windsurf都採用了這種“計劃-執行”模式：代理提出一個計劃，然後在該計劃內執行，而不是自由發揮。這種確定性防護欄能夠有效防止使用者“瘋狂行為”導致的失敗。

其次，資料可訪問性是真正的瓶頸。超過90%的企業資料是非結構化的，包括合同、PDF、電子郵件和轉錄檔案。目前的生成式AI專案僅利用了不到1%的企業資料。代理即使推理能力再強，如果無法訪問所需資料，也只能給出基於“感覺”的錯誤答案。因此，構建一個高效的非結構化資料管道——包括資料分塊、嵌入、治理和服務——是必須優先解決的問題。這是資料工程問題，而非模型問題。

第三，多代理協調帶來了錯誤傳播的挑戰。當五個代理串聯工作時，即使每個代理的失敗率僅為5%，整體可靠性也會降至約77%。若代理B產生幻覺，其錯誤將沿著鏈條傳播並放大。解決方案包括在每個代理跳轉之間新增確定性驗證、設定回退路徑，並建立一個代理登錄檔以便發現和排程合適的代理。

第四，企業特定知識的融入是另一個關鍵挑戰。LLM在第一天對你的業務一無所知。微調成本高昂且速度慢，RAG雖然成本較低，但依賴於穩健的資料管道。大多數公司在這一步停滯不前——代理在公共知識上表現良好，但在內部流程上失敗。

最後，監控方面存在巨大缺口。傳統APM工具（如Datadog、Grafana）僅監控延遲和錯誤，而代理監控需要跟蹤決策質量：代理是否選擇了正確的工具？計劃是否合理？輸出是否事實正確？目前這一可觀測性層幾乎沒有現成工具支援。

為了應對這些挑戰，文章提出了一個包含規劃器/路由器、驗證器、聚合器以及可觀測性迴圈的架構。規劃器將使用者請求分解為子任務並選擇專業代理；每個代理後接驗證器進行確定性檢查；聚合器合併結果並檢測矛盾；可觀測性迴圈提供決策審計和質量評分。

最終，團隊需要將AI代理視為分散式系統問題，而非單純的AI問題。確定性系統應包裹非確定性模型，而非相反。LLM提出方案，確定性程式碼決定執行。只有這樣，代理才能從原型走向規模化生產。