將 LLM 降級為修補匠：一種更務實的 AI 系統工程哲學

當前許多 AI 系統的開發，都朝著打造端到端（end-to-end）自主代理的宏大目標前進，但這條路徑往往犧牲了系統的穩定性與可預測性。我認為，一個更穩健、更適合生產環境的工程哲學，是將大型語言模型（LLM）的角色從系統的總設計師，降級為一個專注於局部生成與修復的「修補匠」。透過將 LLM 的隨機性與創造力限制在一個確定性（deterministic）的框架內，我們才能在享受其效率的同時，不失對系統行為的掌控力。這不僅是技術上的取捨，更是一種務實的工程成熟度展現。

這股對全自主代理的狂熱，讓我們時常陷入一個困境：系統看似強大，卻極其脆弱。一個微小的提示詞（prompt）變動，或模型底層的更新，都可能導致整個系統的行為發生災難性漂移。除錯過程如同在黑箱中摸索，因為問題的根源可能來自於模型在某個中間步驟的「幻覺」，而非明確的程式碼 bug。這種不確定性對於需要高度可靠性的生產級應用來說，是難以接受的。當我們將整個系統的控制權交給一個非確定性的模型時，我們也同時放棄了傳統軟體工程數十年來建立的穩定性與可維護性原則。

如何將 LLM 從系統核心降級為輔助工具？

日本開發者 midomo 所打造的 Discord Bot 生成系統 C2B，便是一個絕佳的範例。C2B 的目標是讓使用者透過對話，就能快速生成並部署一個功能完整的 Discord Bot。然而，其底層架構並非一個單純的聊天代理，而是一個更接近「編譯器管線」（Compiler Pipeline）的設計。

在這個管線中，大部分的基礎建設，例如專案的資料夾結構、主程式進入點、設定檔等，都是由傳統的、確定性的程式碼模板生成的。這確保了每個 Bot 都有一個穩固且一致的骨架。LLM 的任務被嚴格限制在兩個環節：

• 局部模組生成： 根據使用者需求，生成特定功能的程式碼片段（在 Discord Bot 的框架中稱為 Cog）。
• 錯誤修復： 當生成的 Cog 無法正常運作時，由系統自動觸發 LLM 進行修補。

這種分工讓 LLM 的創造力得以發揮在最需要的地方——實現客製化功能，同時又將其「關在」一個可控的範圍內。系統的整體行為依然由確定性的框架主導，大幅降低了失控的風險。這與微軟研究院提出的 AutoGen 框架有異曲同工之妙，後者同樣強調透過多代理人對話與預先定義的工作流程，來約束並引導 LLM 的行為，使其更像是一個可預測的計算元件。

為什麼「局部修復」比「全盤生成」更可靠？

C2B 系統最精妙的設計，在於它如何處理「程式能跑，但功能不對」的狀況。這類錯誤在傳統軟體測試中很難捕捉，但在 AI 生成的程式碼中卻很常見。為此，開發者導入了一個名為「使用者體驗合約分析器」（UX Contract Analyzer）的機制。

這個分析器的工作原理是，在 Bot 部署後，模擬真人使用者與其互動，並檢查 Bot 的回應是否符合預期的「體驗合約」。例如，使用者要求一個計時器 Bot，分析器就會實際發送「設定 10 秒計時器」的指令，然後驗證 Bot 是否在 10 秒後確實發出了提醒訊息。如果 Bot 沒有回應，或回應了無關的內容，即使程式本身沒有崩潰，分析器也會判定為「體驗毀約」。

一旦偵測到體驗毀約，系統不會要求 LLM 重寫整個 Bot，而是將出錯的 Cog 模組連同錯誤日誌、使用者原始需求等上下文資訊，一同回傳給 LLM，並下達一個極其明確的指令：「修復這段程式碼」。

這個「偵測-隔離-修復」的循環，遠比讓 LLM 從頭生成一切來得可靠。因為修復是一個收斂性問題（convergent problem），有明確的目標和限制；而從零開始生成則是一個發散性問題（divergent problem），充滿了無限的可能性與變數。這種專注於自我修復（Self-repairing）的作法，將 LLM 的能力用在解決已知問題上，而非探索未知空間，大幅提升了最終輸出的成功率與品質。

一種更成熟的 AI 工程哲學

從 C2B 的案例中，我們可以提煉出一套更成熟、更務實的 AI 系統工程哲學。這套哲學的核心，是承認並管理 LLM 的不確定性，而非盲目追求完全的自主性。我們可以將兩種開發模式做個簡單比較：

• 端到端代理模式： 將 LLM 視為系統的大腦，負責從輸入到輸出的所有決策。優點是潛力巨大、彈性高；缺點是行為難以預測、除錯困難、可靠性低。
• 確定性框架 + LLM 輔助模式： 將確定性程式碼作為系統的骨架，LLM 則作為填充特定功能血肉的工具。優點是系統穩定、行為可控、易於測試與維護；缺點是犧牲了部分通用性與彈性。

對於絕大多數需要部署到生產環境的應用而言，後者的權衡顯然更為明智。這就像現代的飛機駕駛艙，雖然有先進的自動駕駛系統，但最終的控制權與核心決策依然掌握在人類飛行員與確定性的飛控電腦手中。AI 在其中扮演的是強大的副駕與顧問，而不是取代一切的總司令。

當我們停止將 LLM 神話為無所不能的通用智慧，而是將其視為一種帶有隨機性的、功能強大的函式庫（a powerful, stochastic library），我們的工程思路會變得清晰許多。我們的工作不再只是「設計最好的 prompt」，而是回歸到軟體工程的本質：設計穩固的架構、清晰的介面與可靠的錯誤處理機制，然後在最合適的位置，呼叫這個強大的「LLM 函式」。這條路或許不那麼性感，但卻是通往真正可信任、可治理 AI 系統的必經之路。OpenAI 官方也曾分享多種提升 LLM 應用可靠性的技術，強調工程實踐的重要性。

延伸閱讀

• C2B: 誰でもDiscordで話しかけるだけでBot生成・デプロイまで完結するAIシステム (原文案例)
• Self-repairing Large Language Models (arXiv)
• AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Microsoft Research)
• Techniques to improve reliability (OpenAI Cookbook)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。