什麼是 Agent Harness?支撐 AI Agent 上生產線的工程骨架

Agent Harness,是包在大型語言模型外面的那一整套工程結構——它管好 Agent 的執行迴圈、工具呼叫、記憶與狀態、錯誤重試、權限邊界與可觀測性,讓一個「會思考」的模型,變成一個「能在生產環境穩定完成任務」的系統。一句話:模型是引擎,Harness 是讓引擎裝上車、能上路、能被監理的底盤。

我先說個現場。去年底我們幫一家製造業客戶做設備維修 Agent,POC 階段它答得又快又準,工程主管看得眼睛發亮。真正接上工單系統那週,問題全冒出來了:模型偶爾把同一張工單重複派工三次;呼叫庫存 API 逾時後,它不是重試,而是自己「腦補」一個料號;跑到第七步,前面查到的機台編號早就忘光。模型沒變笨。是它外面什麼都沒有。

Agent Harness 是什麼:不是模型,是模型的骨架

很多人把 Agent 想成「一個很強的 prompt」。這是上不了線的根源。

一個真正跑在生產線的 Agent,拆開來看,模型的推理其實只佔一小塊。真正決定它能不能撐住流量、撐住真實資料、撐住三個月不出事的,是外面那圈工程。這圈工程,就是 Agent Harness。它回答的不是「模型會不會」,而是「當模型偶爾出錯時,整個系統會不會跟著崩」。

我們通常把一套 Harness 拆成六個承重件:

這六件事,沒有一件是靠換更強的模型能解決的。GPT 再升一代,你的 Agent 該有的重試邏輯還是得自己寫。

為什麼 Demo 會過,上線會垮

Demo 環境有一個奢侈的前提:輸入是乾淨的,流量是零星的,出錯了現場有人接。生產環境三個都沒有。

Demo 裡你問十題,九題對,大家鼓掌。生產裡一天跑五千次,那 10% 的錯誤就是五百次真實的派錯工、回錯客、算錯帳。而且錯誤不是均勻分布的,它專挑你資料最髒、流程最特殊的那些角落爆發——偏偏那些角落,才是這家公司真正的業務。

Harness 的價值,就在把「偶爾會錯的模型」關進一個「錯了也不會釀成事故」的結構裡。它不追求模型永遠對,它追求系統永遠可控。這是兩種完全不同的工程目標,而後者才是上線的門檻。

我們踩過的一個雷值得講。早期我們太信任模型的判斷,把 Loop 設計得很「自由」,讓它自己決定要不要呼叫工具。結果它在成本敏感的任務上,為了「保險」反覆呼叫昂貴的檢索 API,一個月帳單漂亮地翻了四倍。後來我們把迴圈改成有明確預算上限與步數天花板,並在關鍵動作前插入人工核可點。Agent 沒變笨,但它終於變得可以被財務接受。這就是 Harness 在做的事。

Harness 是「上得了線」與「只是好看」的分水嶺

回到那句話:Demo 很美不算數,上線且有人在用才算數。中間隔的,幾乎全是 Harness 的工程量。

所以評估一個 AI Agent 專案能不能落地,我的建議是別只看 Demo 的準確率,去問三個問題:它出錯時會怎樣?它的每一步能不能被追查?哪些動作卡了人工核可?如果對方答不出來,那不是一個 Agent,那是一個很會演的 prompt。

在 Tenten,我們做 Agentic 工作流時,工程師是直接進客戶現場的——不是交一個 Demo 就走,而是把這整套 Harness 接上你真實的系統、真實的髒資料、真實的權限規則,陪著它跑到使用率真的長出來為止。骨架搭對了,模型的聰明才有地方使力。