「駕馭工程」時代：當頂級模型的智慧不再是瓶頸，我們該如何建構 AI 系統？

最近在設計與建構多 Agent 系統時，我觀察到一個反直覺的現象：當我們採用業界最頂尖的基礎模型（無論是 GPT-4o、Claude 3.5 Sonnet 或 Gemini 1.5 Pro）來執行一個複雜、長週期的任務時，最終的失敗點，往往不是因為模型「不夠聰明」，無法理解指令或進行推理；恰恰相反，失敗幾乎總是發生在系統層面——執行的鏈路斷裂、工具調用出錯、狀態管理混亂，或是多個 Agent 之間的協作失調。整個系統性的編排（Orchestration）先崩潰了。

這個觀察讓我確信，我們正在從一個「模型為王」的時代，快速過渡到一個「系統為王」的時代。模型本身就像一顆性能無比強悍的引擎，但光有引擎，你哪裡也去不了。你需要方向盤、煞車、傳動系統、導航儀，以及一個能看懂儀表板的駕駛。這整套將原始動力轉化為可控、可靠動能的系統，我認為可以稱之為「駕馭工程」（Harness Engineering）。

這不是一個全新的概念，而是 OpenAI、DeepMind、Anthropic 這些頂級團隊在無數次實踐中，逐漸收斂出的一套工程共識。身為一個同時具備產品管理與技術專案管理（TPM）背景的建構者，我發現這套思維與傳統的軟體系統設計、大型專案管理有著驚人的相似之處，但又針對 AI 的特性進行了特化。它要求我們從一個「提示詞工程師」或「模型調校師」的角色，徹底轉變為一個「AI 系統架構師」。

綜合我的實踐經驗與對業界趨勢的觀察，我認為「駕馭工程」建立在以下幾個核心原則之上：

原則一：人類退後，成為系統的設計師

在駕馭工程的框架下，我們不再是親手撰寫每一行腳本、處理每一個 API 回傳結果的執行者。我們的角色後退了一步，成為整個工作環境的設計師與規則的制定者。日常工作從「寫程式碼」變成了「設計系統」：定義 Agent 的角色與能力邊界、配置它們可以使用的工具、建立有效的回饋與修正閉環、設計多個 Agent 之間的協作與溝通協議。

OpenAI Codex 團隊的負責人 Ryan Lopopolo 有個絕佳的比喻：這就像從一個獨立貢獻的工程師，轉變為一個帶領 500 人團隊的技術領導者（Tech Lead）。你不能再陷入某個具體的功能實現細節裡，而是必須用系統性的思維，從更高維度去思考如何讓這 500 個「人」（Agent）高效、可靠地協同工作，共同達成一個遠超單一個體能力的宏大目標。

原則二：修復流程，而非修復結果

當 AI 系統產出一個錯誤的結果時，最直覺的反應是手動去修改那個錯誤的 JSON 檔案或文字報告。這在原型驗證階段或許無可厚非，但若要建構一個可擴展、可維護的系統，這無異於飲鴆止渴。每一次手動修正，都是在掩蓋系統底層的缺陷。

駕馭工程的核心精神是「修復產生錯誤的流程，而非修復錯誤的結果」。我們應該像偵探一樣追問：是哪個環節導致了這次失敗？是提示詞的指令不夠清晰，讓 Agent 產生了誤解？是提供給它的工具（Tool/Function）定義有缺陷，或是回傳的資訊不足？是工作流程的設計在某個邊界條件下考慮不周？找到根源並從系統層面進行修正——無論是優化提示詞模板、改善工具的 API 設計，還是調整 Agent 的協作流程——才能確保同類錯誤不再發生。這才是唯一能讓系統持續成長與演進的方式。

原則三：可觀測性是新的「斷點調試」

傳統軟體開發，我們有斷點、有日誌、有 Debugger，可以清晰地追蹤程式的每一步執行狀態。但在一個由大型語言模型驅動的 Agent 系統中，其內部的「思考過程」本質上是一個黑盒子。如果我們無法觀測到系統的運行狀態，那除錯過程就會變成一場災難性的猜謎遊戲。

因此，建立完善的可觀測性（Observability）是駕馭工程的基礎設施。我們需要一個像汽車儀表板一樣的系統，能夠即時、清晰地展示：

• 當前是哪個 Agent 在執行任務？
• 它接收到了什麼樣的輸入與指令？
• 它內部的「思考鏈」（Chain of Thought）或推理步驟是什麼？
• 它決定調用哪個工具？傳入了什麼參數？
• 工具返回了什麼結果？
• 它最終輸出了什麼，並傳遞給了誰？

將這些關鍵節點的資訊視覺化，才能讓我們在系統偏離軌道時，迅速定位問題，並做出有效的調整。沒有可觀測性，任何嚴肅的 AI 系統工程都無從談起。

原則四：任務拆解與分層控制的必然

指望單一一個「萬能 Agent」處理所有複雜任務，是一種不切實際的幻想。正如人類社會透過精細分工來完成複雜的專案，AI 系統也必須走上同樣的道路：任務拆解與分層控制。

一個設計良好的 AI 系統，其架構往往是分層的、模組化的。通常會存在一個「經理 Agent」（Manager Agent）或「編排器」（Orchestrator），它的核心職責不是執行具體工作，而是理解宏觀目標，將其拆解成一系列更小、更明確的子任務，然後將這些子任務分派給對應的「專家 Agent」（Specialist Agents）去執行。例如，一個「研究報告生成系統」可能包含：一個負責規劃大綱的「規劃 Agent」、一個專門上網搜尋資料的「搜尋 Agent」、一個負責整合與撰寫初稿的「寫作 Agent」，以及一個負責審閱與潤飾的「編輯 Agent」。

這種分層控制的架構，不僅讓每個 Agent 的職責更單純、提示詞更簡潔、行為更可控，也大幅提升了整個系統的穩定性與可維護性。

原則五：將「失敗」視為系統的內建回饋

傳統軟體追求的是在交付前消除所有 Bug，達到「零失敗」的理想狀態。但在與充滿不確定性的現實世界互動的 AI 系統中，「失敗」是常態，而非例外。API 可能超時，網頁結構可能改變，模型的輸出可能不符合格式要求。一個強固的系統，必須從設計之初就擁抱失敗。

駕馭工程要求我們將失敗視為系統的內建回饋機制。這意味著：

• 優雅地處理錯誤：為工具調用設計重試機制（Retry with exponential backoff）、為模型輸出設計驗證與修復邏輯（Validation & Self-correction）。
• 建立回饋閉環：當系統無法自動修正錯誤時，應設計清晰的升級路徑（Escalation Path），將問題提交給人類監督者進行仲裁。
• 從失敗中學習：每一次失敗，無論是自動修正還是人工介入，都應該被記錄下來，成為優化系統流程、提示詞和工具的寶貴數據。

從這個角度看，我們建構的不再是一個靜態的程式，而是一個能夠在與環境互動中持續學習和演化的動態生命體。

總結來說，當模型的原始智慧不再是稀缺資源時，真正的價值創造來自於我們如何設計、編排、駕馭這些強大但不完美的智慧。這場範式轉移，對產品經理、架構師和工程師都提出了新的要求。我們需要跳出「模型思維」，建立起真正的「系統思維」。未來，最優秀的 AI 應用，比拼的將不再是誰用了最新的模型，而是誰的「駕馭工程」做得更出色。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。