AI Agent 不是換模型就會變可靠：從 Harness Engineering 談我的實作心得
模型像一顆大腦，但讓它長期工作的，是周圍那套不會遺失規則、能檢查結果，也知道何時停下來的環境。這是我讀完文章後最直接的體會。
我讀到 rari 在 X 發表的〈Harness Engineering: How to Build AI Agents That Don't Fall Apart〉。文章一開始描述了一個很常見的場景：能自己使用工具、分步完成任務的 AI 助理（AI Agent）做不好，使用者先改 Prompt，再換更強的模型，接著改用一次能讀取更多內容的模型。結果 Agent 還是會忘記之前的決定、用錯工具、跳過驗證，甚至卡在同一個循環裡。
這段話讓我很有感。因為我現在每天使用 AI 寫程式、查資料、整理需求與維護不同專案，慢慢發現真正影響成果的，往往不是模型排行榜上多了幾分，而是我有沒有替它準備一個可靠的工作環境。
這個環境，就是文章所說的 Harness。Harness 原意是馬具，這裡指包在模型外面、讓它能安全做事的整套工作環境。
Prompt 是指令，Harness 是工作現場
Prompt Engineering 解決的是「我要怎麼把話說清楚」；Context Engineering 解決的是「模型現在能看到哪些資料」；Harness Engineering 則更進一步，處理「模型要在什麼世界裡行動」。
這個世界包括專案檔案、終端機、瀏覽器、測試、記憶、權限、日誌、部署流程與停止條件。模型可以推理下一步，但它不應同時兼任檔案系統、權限管理員、記憶資料庫與稽核紀錄。
同一個模型放在聊天視窗裡，通常只能回答問題；放進有程式碼、有測試、有瀏覽器、有專案規則，而且能留下工作紀錄的環境，就可能完成一段可驗收的工作。模型權重沒有改變，改變的是它的工作環境。
我自己的理解是，人腦也有類似限制。人的工作記憶容量有限，如果每次工作都要靠腦中重新回想「上次決定了什麼、哪個檔案不能動、部署前要檢查什麼」，注意力很快就被細節耗盡。清單、文件與自動測試是一種認知卸載；Harness 對 Agent 做的是類似的事。
一套可靠的 Harness，要完成七件事
文章整理了七項核心工作。以下依照原文架構，補上我在日常開發裡遇到的情況。
一、把需求變成可以驗收的契約（Turn the request into a contract）
「幫我把網站做好」不是契約，只是一個方向。真正能執行的契約需要說明目標、輸入資料、輸出形式、限制條件與驗收標準。
如果沒有清楚邊界，Agent 很容易做完另一件看似合理的工作，最後仍宣告完成。這也是我處理客戶需求時，會先把語音、截圖與對話整理成規格文件的原因。不是為了把流程變複雜，而是避免每個人心中的「完成」不一樣。這其實也是專案經理每天在做的事。
二、給它地圖（Give the agent a map）
Agent 需要知道專案結構與規則放在哪裡，但不需要每次讀完所有文件。比較有效的做法，是準備一份簡潔的入口指南，告訴它遇到登入問題看哪裡、修改文章看哪裡、部署前要載入哪套流程。
詳細知識留在最接近程式碼與工作流程的位置，需要時再載入。這樣既保存脈絡，重要的要求也不會被過長的上下文淹沒。
三、提供正確的工具與環境（Expose the right tools inside the right environment）
工具不是一排按鈕，而是模型接觸真實世界的介面。讀檔、修改程式、查資料庫、開瀏覽器、部署網站，每一種工具都要有清楚用途、穩定輸出、失敗狀態與權限邊界。
如果工具只回覆「完成」，卻沒有可驗證結果，Agent 就只能猜。以我的工作來說，猜測在聊天裡或許只造成一句錯話，在正式環境裡則可能變成漏改資料、錯誤部署或重複收款。
四、把記憶保存成持久狀態（Externalize memory into durable state）
對話不是最終紀錄。專案決策、修改檔案、測試結果、未解風險與下一步，應保存成文件、資料庫、版本紀錄、任務狀態或執行紀錄。
這樣即使對話內容重置、工作中斷或換另一個模型接手，新的工作階段仍能從實際產物恢復，而不是依賴一段可能遺漏細節的口頭轉述。
五、先增加感測器，再增加自主性（Add sensors before adding autonomy）
Agent 無法修正自己看不到的錯誤。測試、程式碼檢查、截圖、執行紀錄、數據指標與資料格式檢查，都是它的感測器。
模型負責建立產物，環境負責提供證據。以我的工作來說，網站改版後是否真的顯示、登入修復後瀏覽器登入狀態是否清除、部署後正式網址是否載入新版本，都不能只靠模型說「應該可以」。自主程度愈高，觀測能力也必須愈完整。
六、在模型之外執行權限（Enforce permissions outside the model）
模型可以建議刪除資料、發送訊息或部署正式環境，但真正的授權應由外部規則與人做最後確認。
同一個機率式系統不應同時提出方案、批准風險，再自己執行不可逆操作。尤其是付款、刪除、發文、改會員資料及碰正式資料庫時，權限分離不是不信任 AI，而是正常的治理設計。
七、留下軌跡，並從局部失敗恢復（Record traces and recover locally）
每次執行都應留下可讀紀錄：做了哪些事、使用哪些工具、修改哪些檔案、測試是否通過、還有哪些問題。
沒有軌跡，失敗只剩一句「AI 又出錯了」；有軌跡，才知道應該補測試、改工具還是收緊權限。最好的修復不只是救回這一次，而是讓同類錯誤下次更難發生。
有了軌跡，失敗時也能從出錯的那一步重試或由人接手，不必把整個任務重新跑一遍。
我的心得：我不是只想要一個更會聊天的模型
我現在想建立的，不是另一個聊天視窗，而是一個能依照 OceanAds 工作方式長期協作的系統。
它可以像現在這樣跟我對話，但對話只是入口。更有價值的是，它知道不同專案放在哪裡、哪些檔案別人正在修改不能動、某類網站要跑哪些測試、正式部署後還要回頭驗證什麼。當客戶傳來一串零碎對話、語音或截圖時，它能先抓出需求與風險，再把工作交給適合的工具或流程。
這套能力對我最直接的幫助，是減少每天重新交代背景的成本。OceanAds 實際處理網站、電商、會員系統、內容、廣告與自動化，不同客戶有不同帳號、平台、規則及交付方式。單靠人的短期記憶，很容易把 A 專案的假設帶到 B 專案。把規則寫進專案地圖、固定作業流程、測試與權限後，系統才能像一位有交接紀錄的 PM，快速抓到細節，而不是每次都從陌生新人開始。
我持續使用 AI，不是因為它每次都答對，而是因為錯誤可以被轉成系統改善。最實際的例子是網站部署：過去只看到部署指令成功，很容易把「上傳完成」當成「客戶已看到新版」。後來我把正式網址重新讀取、檢查關鍵文字與畫面，加入固定的部署後驗證。這條規則不只救一次，而是之後每個網站都能沿用。修的是錯誤類型，不只是當下答案。
這也是 Harness Engineering 最吸引我的地方。它把「希望 AI 下次記得」改成「讓環境替它記得」。
中小企業不一定要訓練自己的大模型
談到建立自己的 AI，很多中小企業第一個想到的是訓練模型，接著就被 GPU、資料量與成本嚇退。但多數企業需要的，並不是從零訓練一顆新的大腦，而是用現有模型搭出自己的工作環境。
企業獨特的資產通常是：報價方式、服務流程、客戶分類、審核規則、常見例外、品牌語氣、文件位置與誰能批准什麼。把這些整理成模型可讀的地圖，再配上 CRM、雲端硬碟、網站後台、測試與通知工具，就已經能形成一套照著自家流程做事的 Agent。
可以先從一條重複、可驗證、出錯後能復原的流程開始。例如整理客戶需求、建立報價草稿、檢查網站內容、彙整訂單或準備客服回覆。先讓 AI 提案、由人審核；導入前也先確認哪些客戶資料可以交給外部 AI 服務。證據與規則成熟後，再逐步開放更多自動化。
不要一開始就追求全自動，也不必先建一個龐大平台。Harness 的複雜度應該跟它要控制的風險相稱，先從小範圍開始。任務愈高風險，測試、權限與人工確認就應愈完整。
從「誰最聰明」轉向「誰最可靠」
我會聯想到海德格對技術的提醒：工具也會改變我們看待工作的方式。當團隊只追逐最新模型，流程、責任與證據反而容易被忽略。
Harness Engineering 把注意力拉回一個更樸素的問題：這份工作如何被清楚定義、可靠執行、客觀驗證並安全交接？模型可以換，工具與政策可以留；這次對話可以結束，專案歷史不能消失。
對我來說，好的 AI 協作不是把判斷全部交出去，而是把記憶負擔與重複操作交給系統，讓人保留方向、風險與價值判斷。這讓我想到《莊子・山木》的「物物而不物於物」：使用工具，但不要反過來被工具牽著走。
結論：先打造工作環境，再追求更強模型
如果 Agent 一直忘記、用錯工具或跳過驗證，先不要急著換模型，而是先回頭檢查前面七項是否完整。
Prompt 告訴模型做什麼，Context 決定它看見什麼，Harness 則決定它能否可靠地完成工作。
我對中小企業最實際的建議是：不要先問「哪個 AI 最強」，先選一條日常流程，建立任務契約、專案地圖、工具、持久紀錄與人工確認點。當這個小閉環穩定後，再增加自主性。
能長期累積的，不是一段神奇 Prompt，而是一套會記得、會檢查、能追蹤，也知道何時把決定交還給人的工作系統。
本文整理並回應 rari（@0xwhrrari）於 2026 年 8 月 29 日在 X 發表的〈Harness Engineering: How to Build AI Agents That Don't Fall Apart〉：https://x.com/0xwhrrari/status/2093685107534000560。文中 OceanAds 工作方式、中小企業導入建議，以及延伸的哲學與認知類比，均為作者個人實作心得。