設計智慧體系統時，務必審慎考量決策的方式與位置。
將更多決策交由 LLM 處理，可能讓系統泛化至更多任務，但也可能犧牲速度、可靠性與穩健性。
在可行的情況下，應盡量將決策流程從 LLM 移至明確的軟體程式碼中。對高風險和／或正式環境的工作流程而言尤其如此。
設計以 LLM 為基礎的智慧體系統時，最重要的抉擇之一，就是要決定由 LLM 模型封裝多少決策功能，以及有多少應由明確的軟體邏輯處理。
為便於理解，可以將這項選擇視為介於下列方法之間的光譜：
路由器型架構會在程式碼中明確定義執行順序與邏輯，確保窄領域任務具備可測試性、可預測性與穩健性（也稱為「工作流程智慧體」）。
編排器智慧體依靠大型語言模型（LLM），透過自然語言提示動態決定任務流程，適合預先定義邏輯不足或不可行的開放式互動。
對高風險的正式環境工作流程，我們通常建議採用較多路由器型功能，僅在需要靈活、通用對話的應用中使用編排器。
路由器型架構
路由器型智慧體系統：
透過程式碼或軟體明確定義決策流程，並使用 LLM 判斷軟體應採取哪條路徑。
更接近傳統軟體系統，具有清楚且可預測的路徑，因此能產生更一致的結果。
非常適合能夠嚴格定義的任務。
以下是航空公司訂位聊天機器人智慧體採用「路由器方法」的簡化範例。LLM 雖然會從三個選項中判別問題意圖，但最後仍由軟體將該意圖對應至預先設計的文字回覆。由於 LLM 受到高度約束，使用者會體驗到更一致的行為。
編排器架構
不同於路由器系統，編排器型智慧體系統：
使用自然語言提示而非軟體來定義邏輯流程。請注意：相較於程式語言，自然語言本身具有模糊性與靈活性（兩者既是優點也是缺點，稍後將進一步討論）。我們將此概念稱為「意圖重於指令」。
可提供多種處理選項，由 LLM 決定執行順序與方法。
能動態建立難以在軟體中明確定義的新邏輯路徑。
這種模糊性可能造成輸出不一致，但順利運作時，會讓人覺得宛如「魔法」。
以下範例針對同一個簡化的航空公司問題採用編排器方法。系統不再由軟體決定適當回覆，而是將決策交給 LLM 層。這是一套多智慧體系統，由「主管」編排器智慧體分流使用者查詢，轉交給專為變更航班而設計的智慧體，最後向使用者提供回覆。
在這個範例中，LLM 層同時扮演分類器、路由器和回覆撰寫者。在路由器範例中，LLM 只扮演分類器的角色，其餘部分由軟體處理。
在可行的情況下，我們建議採用路由器型架構，因為它具備下列優勢：
速度與效率：相較於依賴外部 API 的編排器，本機運算速度更快。此外，以 Python 處理「IF/ELSE」邏輯，遠比付費請 LLM 供應商透過其 4,000 億參數模型處理便宜。
可測試性與可預測性：運用成熟的軟體實務，偵錯、測試及維護都容易許多。
透明度與可靠性：行為差異較小，能簡化疑難排解。相較於不透明且難以解讀的 LLM 權重，應用程式有更多流程是以透明、受版本控制的軟體來呈現。
路由器方法的缺點是可能過於僵化、不靈活，也可能難以處理較開放的問題。聊天機器人若總是給出完全相同的回覆，使用者可能會覺得無趣或缺乏變化。
編排器設計具備強大功能：
規劃：能動態規劃回覆。
工具選擇／智慧體交接：選擇適當工具，或將任務委派給智慧體。
反覆組合輸出：以創新方式反覆調整並重新組合輸出。
判斷是否完成：判斷是否已收集足夠資訊，可產生最終回覆。
使用 Pydantic-AI 或 OpenAI Agents SDK 等框架，可以簡單迅速地實作編排功能。因此，這種方法非常適合展示或概念驗證。
這種方法的缺點包括：
我們無法保證 LLM 的規劃步驟及後續行動正確或適當。路由器系統也有同樣的問題，但因限制較多，其行為更容易預測。
對簡單且定義明確的任務而言，我們大概不需要多智慧體系統的完整能力。例如，在航空公司智慧體範例中，與航空公司支援系統互動的人實際想處理的查詢類型可能相當有限。
由於 LLM 包含更多邏輯，惡意人士更容易對其越獄或加以利用。
這種方法將決策抽象化並移入 LLM，因此更難理解系統運作方式（不過 Langfuse 或 Braintrust 等監控工具或許能提供部分協助）。
讀者注意：雖然模型能力正快速演進，但以下原則近期內不太可能改變。
界定問題範圍。
你能否輕鬆用圖表定義所需的決策邏輯？
你的應用程式是否無法容忍失敗或非預期行為？
上述任一問題若回答「是」，就表示路由器型功能可能更合適。
在能力所及的範圍內，我們建議優先採用路由器方法。一般原則是：系統中能用程式碼表達的部分，就應寫成程式碼（也就是不需要時，不要過度使用 LLM）。
當路由器方法達到極限時，可以在受限條件下重現編排器的部分開放式優勢。例如：
工具選擇／智慧體交接：可透過條件分支或 LLM 分類器輕鬆實作。
判斷是否完成：可利用簡單的 LLM 分類器，在將回覆傳給使用者前檢查其完整性。
不過，「規劃」與「反覆組合輸出」無疑更難在僵化的路由器系統中實現。因此，當任務需要這些能力時（由 LLM 分類器或其他邏輯判斷），我們建議在系統中建立限制較少的編排器分支。
選擇路由器或編排器架構時，應考量應用程式的明確程度、複雜度及互動方式。目前，路由器型方法能為定義明確的任務提供可靠性、效率與易測試性。編排器則能為更廣泛的對話式互動提供更高靈活性。
隨著 LLM 持續進步，這兩種方法之間的平衡可能隨之改變。對正式環境的工作負載，我們較傾向採用路由器型或混合架構；編排器則保留給需要動態、類人互動的開放式問題。