什麼是 Agent Harness?把 LLM 包成可上線系統的鷹架工程實作

Agent Harness(代理鷹架)是包在 LLM 外圍的一整套工程結構,負責把模型「會回答」變成系統「能上線」:它決定模型在每一步拿到什麼情境、能呼叫哪些工具、記得什麼、以及出錯時怎麼收拾。換句話說,harness 不是模型,而是讓模型能被信任地放進生產環境的那層鷹架。

我們踩過一個很典型的雷。一個內部法遵助理,單看對話品質相當好,GPT 級的模型接上公司知識庫,問什麼答什麼。上線兩週後,法遵長把它關了。原因不是答錯——是它偶爾會漏引一條最新的函令、偶爾把兩份版本不同的合約混在一起回答,而且沒有任何一步留下可稽核的紀錄。模型沒問題,問題是它外面什麼都沒有。這就是缺 harness 的樣子。

為什麼裸的 LLM 上不了線

一個 prompt 加一次 API 呼叫,能做出很好的 Demo,卻做不出可上線系統。差別在於生產環境有四件事永遠成立:輸入是髒的、工具會失敗、對話會很長、而且錯誤會被放大到有人要負責。裸模型對這四件事一律沒有預設答案——它只會盡力生成下一段文字,包括在該說「我不知道」的時候硬掰一個答案出來。

把這四件事系統性地接管起來,就是 agent harness 工程要解決的問題。它不是讓模型更聰明,而是讓一個能力固定的模型,在每一次真實請求裡都表現在可接受的下限之上。

agent harness 工程:鷹架的四層

我們在客戶現場反覆收斂出一套分層方法論,把 harness 拆成四個各自可測、可替換的層。這四層是我們設計每一個 agent 的起手式:

情境層決定每一步餵給模型的視窗內容。它是 RAG、狀態摘要、權限過濾的集合,核心是「少而準」而非「多而全」——把整個知識庫塞進去,反而稀釋了關鍵那一條。工具層把模型的行動能力用結構化 schema 框死,每個工具的參數都要能被驗證,不合法就擋在呼叫之前,而不是讓外部系統去承接一個幻覺出來的參數。

記憶層處理時間。短期記憶是這輪任務的工作狀態,長期記憶是跨對話的偏好與事實,兩者要分開存、分開淘汰,否則長流程一定會在某一步爆掉上下文。錯誤處理層是最常被跳過、也最決定生死的一層:工具逾時要重試還是換路、模型信心不足要不要停下來問人、每一步的輸入輸出有沒有留痕。前面那個被關掉的法遵助理,缺的正是這一層。

harness 不是 prompt,也不是 framework

這是最容易混淆的地方,值得說清楚。Prompt 是你對模型說的話,framework(LangChain、LlamaIndex 那類)是你用來搭 harness 的工具箱。Harness 是介於兩者之間、真正屬於你這個業務場景的那套結構——它把情境、工具、記憶、錯誤處理黏合成一個對「你這家公司哪裡不一般」有答案的系統。同一個模型、同一個 framework,兩家公司的 harness 幾乎不會一樣,因為他們的資料形狀、合規紅線、可容忍的失敗模式都不同。

也因此,harness 是可以被獨立評估的一類工程物件:你可以對情境層做召回測試、對工具層做參數合法性測試、對記憶層做長流程壓力測試、對錯誤處理層做故障注入。這四類測試能不能被寫出來,基本上就決定了這個 agent 能不能上生產線。

從 Demo 到生產線

我們的做法很直接:接案時先不急著調模型,而是把這四層拆開,一層一層問「這裡失敗會怎樣、我們怎麼知道、怎麼收」。多數看起來像「模型不夠強」的問題,最後都落在某一層 harness 沒做。Demo 很美不算數,harness 撐得住真實流量、而且有人每天在用,才算把 LLM 真的包成了一個系統。