Agent Harness 是什麼？別再把 prompt 越寫越長，Harness Engineering 的重點在模型以外
週四下午四點，謝承翰盯著螢幕，第五次把同一段請求貼進他的程式碼 agent。
他是一間電商公司的後端工程師。任務很小：修一個結帳流程的錯誤。但 agent 每次都改錯地方，於是他一次又一次補充：「注意我們的命名慣例」「不要動付款模組」「先看上次那份設計文件」。prompt 從三行變成三十行。
這一版終於過了。他鬆一口氣，順手把整段 prompt 存進記事本，打算下次直接貼。
那一刻他還不知道，自己正在做影片裡那位受訪者想避免的事。（承翰為示意性虛構人物，非真實客戶案例。）
Agent harness 是什麼：模型以外的全部
Google Cloud Tech 的影片先用一句話講清楚：AI agent 等於大型語言模型加上 harness，而 harness 就是 agent 裡不屬於模型的一切。
影片用了一個下雨的例子。你問 agent「我該穿雨衣嗎」，模型本身不知道天氣，它只能吐出一段意思是「去查天氣」的文字。接手的是 harness：它去取得天氣資料，把原本的問題和查到的結果一起重新交給模型，模型才答得出「今天晴朗，不用」。
所以，我們平常以為在跟模型講話，多半是在跟 harness 講話。工具呼叫、讀寫檔案、記憶、重試迴圈，都是 harness 的事。
受訪者的「lazy prompter」：偷懶是目標
影片中段是主持人 Tilda 與受訪者 Ryan 的對談（逐字稿音譯為 Ryan，稱他是 Google 員工、「agent harness」一詞的提出者；姓氏音譯不確定，本文不寫）。受訪者的目標很反直覺：他想成為極度懶惰的 prompter。
邏輯是這樣的：如果你已經把工具和脈絡準備好，讓模型能自己讀到需要的東西，就不必在第一句 prompt 裡把一切塞滿。他的觀察是，模型再進步，也不會自動變得更懂「你想要什麼」，所以要靠環境與脈絡去教它。
承翰那三十行 prompt，正是把「環境該告訴 agent 的事」全都壓在一個人的記事本裡。
把介入往前移：從重送 prompt 到寫進專案
受訪者列出一條由笨到巧的介入光譜。最原始的做法，是原封不動再送一次請求，碰碰運氣。這個辦法換一個隊友就失效，也無法把經驗留給團隊。
他說的是把介入「往前移」到軟體開發流程更早的階段（逐字稿譯為「移向開頭」），做法大致有三類：
補上文件，讓知識住在專案裡而不是某個人的對話裡
加一份 agents.md，指向那些文件
在測試裡加入靜態檢查，檢查本身也能成為提示 agent 的訊息
最深的一層，是讓 agent 自己去讀環境脈絡，而不是由人餵進去。受訪者還提到，他會在 Markdown 裡把連結放在段落旁邊作為參照，讓 agent 讀文字時省力、人類也讀得懂。
轉折：每一輪迴圈都在重送你的 prompt
承翰這時才想到一件事。他的 agent 不是問一次就結束，而是在迴圈裡跑：改程式、跑測試、讀錯誤、再改。影片後段的另一位講者就提到，agent 檢查目錄、改函式、跑單元測試的這串動作，一個任務可能重複 20、40 甚至 60 次，速度與成本會因此倍增。
這就是 harness 與帳單的交會點。你的 prompt 寫得多長、每一輪帶多少脈絡，由 harness 決定哪些被送出去。三十行手寫 prompt 如果每一輪都跟著走，就是三十行乘上迴圈次數的 token。
反過來，把穩定的知識放進文件與 agents.md，並且讓 agent 在需要時才去讀，送出的內容才可能變得精準。這裡是推論，不是影片給的數據；影片並沒有提供任何具體的 token 節省數字。
不要把 harness 蓋得太重
受訪者也給了一個提醒：別在 agent 周圍過度搭建結構。模型變強以後，過去的限制反而會變成束縛，而人又捨不得拆掉自己花過心力的東西，這是沉沒成本。
他的建議很樸素：用當下最好的模型，大膽嘗試；agent 失敗時追問原因，再把修正寫進環境裡，而不是只改 prompt。
用 AI Token King 對帳：看得見才調得動
如果你在使用 AI Token King 的 MCP 服務，可以用唯讀工具查詢可用模型、帳戶餘額，以及用量紀錄。這些工具只負責查詢與對帳，不會替你調整 harness，也不會自動降低用量。
比較務實的做法，是在改動 agents.md 或文件結構之前和之後，各看一次用量紀錄，再自己判斷有沒有差別。
回到承翰。隔週一，他把那三十行 prompt 拆開：命名慣例寫進 agents.md，付款模組的限制變成一條測試，設計文件加上了連結。新的 prompt 只剩一句話。
下次 agent 又改錯時，他第一個想的不是「再補一句」，而是「這件事該住在哪個檔案裡」。
常見問題
Agent harness 和 prompt engineering 有什麼不同？
Prompt engineering 處理你對模型說了什麼；harness engineering 處理模型周圍的工具、脈絡與迴圈，也就是模型以外的一切。兩者可以並用。
Harness 一定要自己從零打造嗎？
不一定。受訪者自述他自己沒有從零打造過這類環境，他的重點是持續觀察 agent 失敗的原因並調整周邊。影片後段另一位講者則示範了自建 harness 的不同模式，用來理解運作原理。
為什麼說 harness 會影響 token 用量？
因為每一輪 agent 迴圈送給模型的內容由 harness 組成。這是依影片說明所做的推論，影片本身沒有提供量化數據。
這支影片可以直接當作技術依據嗎？
建議不要。影片來自雲端廠商頻道，內容也涉及該廠商的產品，且本文依據的是阿拉伯語翻譯逐字稿，細節可能走樣。
資料來源聲明
本文依據 Google Cloud Tech 頻道影片《Harness Engineering Explained》（2026 年 9 月 14 日發布，觀看次數 54,033）重新整理與改寫，影片連結：https://www.youtube.com/watch?v=F8EZJAm9iO8
揭露事項：影片所屬頻道為 Google Cloud Tech，受訪者為該公司員工，內容提及該公司的相關產品，本文不構成對任何產品的推薦。本文所依逐字稿為阿拉伯語翻譯，姓氏音譯與細部措辭可能走樣，文中說法均標為「受訪者自述」。謝承翰為示意性人物，非真實客戶案例。
延伸閱讀
先看清楚用量，再談怎麼調
在動手改 harness 之前，先看清楚你的用量與餘額。到 AI Token King 看看可用的模型，再自己判斷哪些脈絡值得常駐。
留言