AI 開發社群越來越認識到，成功的生產就緒型 LLM 應用通常需要一種更加模組化、可控的方法，而不是依賴於包羅永珍的代理框架。這一見解來源於圍繞 12 Factor Agents 原則的討論，該原則概述了構建可靠 LLM 應用的最佳實踐。
框架與庫的爭論
開發者們發現，雖然代理框架承諾簡單性和快速部署，但在擴充套件到生產環境時往往會帶來限制。社群正在形成一種共識，即 LLM 作為庫而非框架實現時效果最佳，這給予工程師對關鍵元件更大的控制權。這種方法允許更好的定製化、更可預測的行為，以及在問題不可避免地出現時更容易進行除錯。
「大多數進入生產環境的'AI 代理'實際上並沒有那麼具有代理性。最好的代理主要是在關鍵點上融入了 LLM 的精心設計的軟體。」
這種觀點反映了許多開發者在從演示轉向需要可靠且經濟高效的生產系統時所面臨的實際情況。圍繞完全自主代理的興奮往往會讓位於更加務實的實現，即 LLM 能力增強現有軟體架構而非完全替代它。
常見實現模式：
- 工作流與智慧體：90%的生產環境實現使用工作流模式，而非完全自主的智慧體
- 控制流：保持開發者對執行過程的控制，而非將控制權委託給框架
- 測試策略：確保可靠性超越"99%時間有效"的門檻
- 成本管理：儘可能使用確定性元件以減少令牌消耗
 |
|---|
| 結構化輸出透過利用庫而非框架，使開發者對 LLM 應用擁有更大的控制權 |
控制流和狀態管理
社群討論中強調的一個關鍵原則是保持對執行流和狀態管理的控制的重要性。成功的實現往往是讓工程師掌控 LLM 元件如何以及何時被呼叫，而不是將控制權交給黑盒框架。
開發者注意到，統一執行狀態與業務狀態（因素 6）以及擁有控制流（因素 8）對於構建可以正確除錯、監控和最佳化的系統至關重要。這種方法使團隊能夠處理框架設計者可能未預見到的邊緣情況和故障模式。
12 Factor Agents 的關鍵原則：
- 因素 1：自然語言到工具呼叫
- 因素 2：掌控你的提示詞
- 因素 6：統一執行狀態和業務狀態
- 因素 7：透過工具呼叫聯絡人類
- 因素 8：掌控你的控制流
- 因素 10：小型、專注的代理
- 因素 11：從任何地方觸發，在使用者所在之處與其會面
- 因素 12：將你的代理設計為無狀態的歸約器
 |
|---|
| 控制流管理對於可靠的 LLM 應用至關重要，可確保行為可預測並簡化除錯過程 |
規模化的成本考慮
社群提出的一個重要實際考慮因素是大規模執行 LLM 應用的成本。令牌消耗可能很快變得昂貴，特別是當代理在迴圈中進行多次 LLM 呼叫時。開發者建議在訴諸 LLM 呼叫之前儘可能使用確定性元件。
這種注重成本的方法不僅改善了底線，而且通常會產生延遲更低的更可靠系統。透過仔細選擇在哪裡應用 LLM 能力，團隊可以最大化價值，同時最小化不必要的支出。
測試和可靠性挑戰
社群強調了基於代理系統固有的可靠性挑戰。即使代理 99% 的時間都能正確工作，那 1% 的失敗率在生產環境中也可能成為問題。增加更多基於 LLM 的防護措施並不一定能解決問題，因為它依賴於同樣可能出錯的技術。
這導致許多團隊採用更結構化的工作流程而非完全自主的代理，特別是對於可預測性和可靠性至關重要的企業應用。隨著這些系統承擔更多關鍵任務，測試、驗證和確保一致行為的能力變得越來越重要。
總之，雖然自主 AI 代理的前景繼續吸引想象力並推動創新，但構建生產就緒型 LLM 應用的實際情況往往引導開發者採用更加可控、模組化的方法。透過理解這些原則和權衡，團隊可以構建更可靠、更具成本效益和更易於維護的 AI 增強系統，為使用者提供真正的價值。