為什麼資深工程師在建構AI 智能體時會遇到困難？ @_philschmid 分享了一個有趣的悖論：為什麼經驗豐富的資深工程師在開發AI 智能體時，往往比初級工程師更慢、更難取得進展？ Schmid 認為，根源在於傳統軟體工程強調確定性和消除歧義，而智能體工程本質上是機率性的，需要工程師學會「信任」 LLM 來處理非線性流程和自然語言輸入。他透過五個關鍵挑戰，剖析了這種思維轉變的困難點，並提供實用洞見，幫助工程師適應這個範式。 主要觀點：從確定性到機率性的典範轉移傳統軟體開發追求可預測性：輸入固定、輸出確定、錯誤透過異常處理隔離。相較之下，智能體依賴LLM 作為“大腦”，透過自然語言驅動決策，允許多輪互動、分支和自適應。但資深工程師的本能是“編碼消除不確定性”，這反而阻礙了智能體的潛力。 Schmid 指出，初級工程師往往更直觀地擁抱這種不確定性，能更快推出可運作的原型，而資深者則需克服多年養成的習慣。 五個核心挑戰列出五個傳統工程習慣與智能體開發的衝突點，每個挑戰都配以解釋和範例，強調如何轉向更靈活的方法。 1. 文字即狀態（Text is the New State） 傳統系統使用結構化資料（如布林值is_approved: true/false）來表示狀態，確保離散性和可預測性。但現實意圖往往藏在自然語言的細微差別中，例如用戶反饋「This plan looks good, but please focus on the US market」（這個計劃不錯，但請聚焦美國市場）。如果強制轉換為二元結構，就會失去這些nuance（細微差別），導致智能體無法動態回應。 洞見：保留原始文字作為狀態，讓LLM 在上下文中解讀。例如，儲存使用者偏好「I prefer Celsius for weather, but use Fahrenheit for cooking」（天氣用攝氏度，烹飪用華氏度），而非簡單布爾值。這要求工程師從「結構化優先」轉向「語義靈活」。 2. 交出控制權（Hand over Control） 傳統架構如微服務依賴固定路由和API 端點來控制流程。但智能體只有一個自然語言入口，由LLM 根據工具和上下文決定下一步——可能循環、回溯或轉向。例如，一個「取消訂閱」意圖可能透過談判轉為「提供折扣以挽留」。硬編碼這些流程會扼殺智能體的適應性。 洞見：信任LLM 處理控制流，利用其對完整上下文的理解。工程師應設計支援這種「非線性導航」的系統，而不是預設所有分支。 3. 錯誤只是輸入（Errors are just inputs） 在傳統程式碼中，錯誤（如缺失變數）會觸發異常，導致崩潰或重試。但智能體每次執行都消耗時間和成本，無法承受全盤失敗。作者強調，錯誤應被視為新輸入，回饋給智能體以實現自癒。 洞見：建構彈性機制，將錯誤循環回LLM 進行恢復，而不是隔離處理。這體現了機率性思考：失敗不是終點，而是迭代機會。 4. 從單元測試到評估（From Unit Tests to Evals） 單元測試依賴二元斷言（pass/fail），適合確定性輸出。但智能體的輸出是機率性的，例如「總結這封郵件」可能產生無數有效變體。模擬LLM 的測試也僅驗證實作細節，而非整體行為。 洞見：轉向「評估」（evals），包括可靠性（成功率，如45/50次通過）、品質（用LLM 作為評判者打分幫助性和準確性）和追蹤（檢查中間步驟，如是否查詢知識庫）。目標不是100%確定，而是高置信度的機率成功。 5. 智能體在演化，API 不會（Agents Evolve, APIs Don't） API 設計時假設人類使用者能推斷上下文，但智慧體是「字面主義者」——如果get_user(id) 中的「email」被誤解為UUID，它可能幻覺出錯誤回應。 API 的歧義會放大LLM 的限制。 洞見：設計「傻瓜式」 API，使用詳細語意類型（如delete_item_by_uuid(uuid: str)）和文件字串。智能體能即時適應API 變化，比傳統程式碼更靈活。 解決方案與啟示 Schmid 不主張完全拋棄工程原則，而是尋求「信任，但驗證」（trust, but verify）的平衡：透過評估和追蹤管理機率性，建構彈性系統。同時，認識到智能體並非萬能——簡單線性任務更適合工作流程，而非智能體。例如保留使用者回饋的文字狀態、讓錯誤驅動恢復循環，以及用評估量化智能體表現（例如，成功率90%，品質分4.5/5）。 部落格網址：
