AI智能體為何總“翻車”？或許，它缺的只是一個好“駕馭”！

AI 智能體曾需要 SDK，然后是框架 (Frameworks)，再是腳手架 (Scaffolding)。現在，它們需要一個駕馭 (Harness)。

每種方法在靈活性與結構性的權衡譜系中處于不同的位置。

OpenAI 和 Anthropic 現在都已正式使用這個術語。

這不是一個流行詞，而是決定 AI 智能體能否在生產環境中真正發揮作用的、缺失的架構層。

駕馭并非智能體本身。

它是一個軟件系統，用于管理智能體的運作方式。

Philipp Schmid 用一個計算機類比作出了精妙詮釋……

模型是原始處理能力。

智能體是運行于其上的應用程序。

我之前介紹了構建 AI 智能體的三種架構方法。

以下是一個駕馭與這三種方法的關系。

SDK、腳手架和框架回答的是你如何構建一個 AI 智能體的問題。

而一個駕馭回答的是一個完全不同的問題，即 智能體如何運行。

你可以使用這三種方法中的任何一種來構建一個駕馭。駕馭不是它們的替代品，而是位于它們之上的一個層級。

parallel.ai 團隊識別出了六個核心組成部分……

這與 OpenAI 和 Anthropic 已發布的內容相符。

通過定義的協議將模型連接到外部 API、數據庫、代碼執行環境和自定義工具。

動態地管理每次模型調用中出現的信息。

引導模型通過結構化的任務序列，而不是試圖一次性完成所有事情。

驗證檢查、格式驗證、安全過濾器。即自我修正的循環。當智能體遇到困難時，駕馭將此視為一個信號，用以識別缺失的環節。

可插拔的組件，可以獨立地啟用、禁用或替換。

Claude Code 就是一個駕馭。

OpenAI Codex 使用了駕馭工程。

他們的團隊構建了一個超過 100 萬行代碼的代碼庫，完全沒有手動輸入的代碼，將駕馭視作主要接口。

OpenAI 的 CUA 示例應用 是一個用于計算機使用的駕馭。

模型決定做什么，駕馭則安全地執行它。

智能體定義、消息路由、任務生命周期、依賴管理、生成工作單元……大約 80% 開發者使用框架的功能，現在模型都能夠原生處理。

剩下的 20%：持久化、確定性重放、成本控制、可觀測性和錯誤恢復——這正是一個駕馭所提供的。

框架層并不僅僅是在消失，它正在分裂。智能部分移入了模型，而基礎設施部分則移入了駕馭。

框架告訴開發者如何構建一個應用程序。

駕馭告訴智能體如何安全地運作。

使用框架時，由開發者編寫編排邏輯。

使用駕馭時，由模型制定計劃，駕馭確保其不偏離軌道。

對于今天正在構建 AI 智能體的團隊來說，問題正在轉變。

不再是“我們應該使用哪個框架？”，而是“我們的駕馭應該是什么樣的？”

駕馭決定了一個智能體的成敗。

從簡單開始。

構建穩健的原子化工具。讓模型來制定計劃。

增加護欄、重試和驗證機制。

這就是駕馭工程。

大語言模型本身成為循環控制器——它讀取駕馭的規則并遵循它們。

當 LLM 的能力足夠強，可以自我指導，并且你希望在不更改代碼的情況下進行快速迭代時，這是最佳選擇。