什麼是 Agent Harness?把 LLM 包成可上線系統的鷹架工程實作
很多企業 AI 的問題不在模型,而在模型外面什麼都沒有。Agent Harness 就是把「會回答」的 LLM 包成「能上線」系統的那層鷹架。這篇我們公開 Tenten 在客戶現場收斂出的 harness 分層方法論——情境、工具、記憶、錯誤處理四層,以及為什麼它是決定 agent 能否上生產線的關鍵。
作者
Tenten AI 研究團隊
應用 AI
發佈日期
2026年2月14日
閱讀時間
6 分鐘
Agent Harness(代理鷹架)是包在 LLM 外圍的一整套工程結構,負責把模型「會回答」變成系統「能上線」:它決定模型在每一步拿到什麼情境、能呼叫哪些工具、記得什麼、以及出錯時怎麼收拾。換句話說,harness 不是模型,而是讓模型能被信任地放進生產環境的那層鷹架。
我們踩過一個很典型的雷。一個內部法遵助理,單看對話品質相當好,GPT 級的模型接上公司知識庫,問什麼答什麼。上線兩週後,法遵長把它關了。原因不是答錯——是它偶爾會漏引一條最新的函令、偶爾把兩份版本不同的合約混在一起回答,而且沒有任何一步留下可稽核的紀錄。模型沒問題,問題是它外面什麼都沒有。這就是缺 harness 的樣子。
為什麼裸的 LLM 上不了線
一個 prompt 加一次 API 呼叫,能做出很好的 Demo,卻做不出可上線系統。差別在於生產環境有四件事永遠成立:輸入是髒的、工具會失敗、對話會很長、而且錯誤會被放大到有人要負責。裸模型對這四件事一律沒有預設答案——它只會盡力生成下一段文字,包括在該說「我不知道」的時候硬掰一個答案出來。
把這四件事系統性地接管起來,就是 agent harness 工程要解決的問題。它不是讓模型更聰明,而是讓一個能力固定的模型,在每一次真實請求裡都表現在可接受的下限之上。
agent harness 工程:鷹架的四層
我們在客戶現場反覆收斂出一套分層方法論,把 harness 拆成四個各自可測、可替換的層。這四層是我們設計每一個 agent 的起手式:
| 層 | 負責的問題 | 沒做好會怎樣 |
|---|---|---|
| 情境層 (Context) | 這一步該把哪些資訊放進模型視窗 | 答非所問、引用過期或不相關的來源 |
| 工具層 (Tools) | 模型能對外界做哪些動作、參數怎麼約束 | 亂呼叫、參數幻覺、動到不該動的資料 |
| 記憶層 (Memory) | 跨步驟、跨對話該記住與遺忘什麼 | 長對話崩掉、重複提問、忘記前面的決定 |
| 錯誤處理層 (Errors) | 工具失敗或模型不確定時怎麼收 | 靜默給錯答案、無法稽核、無法重試 |
情境層決定每一步餵給模型的視窗內容。它是 RAG、狀態摘要、權限過濾的集合,核心是「少而準」而非「多而全」——把整個知識庫塞進去,反而稀釋了關鍵那一條。工具層把模型的行動能力用結構化 schema 框死,每個工具的參數都要能被驗證,不合法就擋在呼叫之前,而不是讓外部系統去承接一個幻覺出來的參數。
記憶層處理時間。短期記憶是這輪任務的工作狀態,長期記憶是跨對話的偏好與事實,兩者要分開存、分開淘汰,否則長流程一定會在某一步爆掉上下文。錯誤處理層是最常被跳過、也最決定生死的一層:工具逾時要重試還是換路、模型信心不足要不要停下來問人、每一步的輸入輸出有沒有留痕。前面那個被關掉的法遵助理,缺的正是這一層。
harness 不是 prompt,也不是 framework
這是最容易混淆的地方,值得說清楚。Prompt 是你對模型說的話,framework(LangChain、LlamaIndex 那類)是你用來搭 harness 的工具箱。Harness 是介於兩者之間、真正屬於你這個業務場景的那套結構——它把情境、工具、記憶、錯誤處理黏合成一個對「你這家公司哪裡不一般」有答案的系統。同一個模型、同一個 framework,兩家公司的 harness 幾乎不會一樣,因為他們的資料形狀、合規紅線、可容忍的失敗模式都不同。
也因此,harness 是可以被獨立評估的一類工程物件:你可以對情境層做召回測試、對工具層做參數合法性測試、對記憶層做長流程壓力測試、對錯誤處理層做故障注入。這四類測試能不能被寫出來,基本上就決定了這個 agent 能不能上生產線。
從 Demo 到生產線
我們的做法很直接:接案時先不急著調模型,而是把這四層拆開,一層一層問「這裡失敗會怎樣、我們怎麼知道、怎麼收」。多數看起來像「模型不夠強」的問題,最後都落在某一層 harness 沒做。Demo 很美不算數,harness 撐得住真實流量、而且有人每天在用,才算把 LLM 真的包成了一個系統。
