為什麼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提出方案，確定性代碼決定執行。只有這樣，代理才能從原型走向規模化生產。