在智能代理系統中，務必審慎考慮決策的方式和位置。
把更多決策交由 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 持續進步，兩種方法之間的取捨或會改變。對生產環境工作負載，我們傾向採用路由器式或混合式架構；協調器則留給需要動態、類似人類互動的開放式問題。