先講結論
你幫團隊做了一個 Agent Demo，老闆看了很滿意，叫你把它推上線。結果一上線，Agent 改了不該改的檔案、聲稱任務完成但測試全紅、上下文塞爆後開始胡說八道。
問題不在模型不夠聰明。問題在你只幫它裝了大腦，沒幫它搭工作台。
Harness 就是包在 AI 模型外面的那層運行系統。 它負責把模糊的使用者目標轉成可執行任務，把正確的上下文餵給模型，把模型輸出轉成工具呼叫，再用測試、權限、日誌、審查機制判斷任務是否真的完成。
打個比方：模型是一位廚師的腦力，Harness 則是整間廚房。流理台、爐具、滅火器、食譜卡、出菜口那位檢查每道菜的副主廚，全都算在內。廚師再厲害，沒有廚房也只能路邊擺攤。
一、四個你一定遇過的翻車現場
把 Agent 從 Demo 推到生產，通常會撞見這四面牆。
需求會漂。 你一開始說「做個記帳工具」，Agent 很快生出一個漂亮頁面。你接著說「加個分類統計」，它又加了圖表。你再說「支援多人協作」，它開始亂改資料結構。到最後你自己也說不清這專案的核心目標是什麼。就像工地沒有藍圖，工人手腳很快，但牆越砌越歪。
上下文會爆。 Agent 做複雜任務時，會讀很多檔案、跑很多命令、產生很多日誌。上下文視窗再大也不是無限的。塞越滿，模型越容易忘記早期約束，或把過期資訊當成最新事實。這就像辦公室的桌面，文件堆到山一樣高，要找一張紙得翻半小時。
能跑不等於正確。 一個函式在某個樣例下能跑，不代表它滿足所有業務邊界。金額計算用了 float、四捨五入規則錯誤、邊界值處理有漏洞。沒有測試，Agent 很容易寫出「看起來對」的程式碼。就像一座橋，看起來很穩，但第一輛重型卡車開過去就塌了。
Agent 很會「自信地說完成了」。 很多 Agent 在沒有真正驗證時就回報「已完成」。人類工程師至少知道自己有沒有跑測試，但 Agent 如果沒被要求跑測試，它可能只靠程式碼表面判斷。這就像施工隊自檢自簽，沒人驗收。
二、為什麼舊做法不夠用
過去幾年，AI 應用開發的方法論經歷了三次升級，每一代解決的都是前一代留下的缺口。
第一階段：Prompt Engineering。 核心問題是「我怎麼問 AI，它才能回答得更好？」你把需求寫清楚，模型一次性生成答案。這在簡單任務上夠用，但遇到複雜工程就不行了，因為一句話裝不下整個專案的規矩。
第二階段：Context Engineering。 核心問題變成「我給 AI 什麼上下文，它才能在正確資訊裡工作？」你把專案目錄、現有程式碼、編碼規範都餵給模型。這比光寫提示詞好很多，但它仍然假設模型看完資料就能一次做對，沒有犯錯後自我修正的機制。
第三階段：Harness Engineering。 核心問題再往前一步：「我給 AI 什麼樣的任務環境、工具邊界、驗證機制、狀態管理和反饋循環，它才能持續、可靠、可審查地完成複雜任務？」
三者的層次差異，用廚房來比喻最清楚。Prompt Engineering 是告訴廚師「做一道紅燒肉」。Context Engineering 是把食譜、食材、廚具清單都放在他面前。Harness Engineering 是蓋好整間廚房，規定他只能用哪些爐具、每道菜出鍋前必須試溫、失敗了要重做而不是端出去。
三、核心概念拆解：九個模組
一個成熟的 Harness，可以拆成九個模組。不需要一次全建好，但要知道每個模組解決什麼問題。
任務規格。 不是一句「做個功能」，而是一份合同：目標是什麼、不做什麼、輸入是什麼、完成條件是什麼。把「感覺」變成「白紙黑字」。就像蓋房子之前要有建築圖則，寫清楚幾房幾廳、有沒有陽台。
上下文選擇。 上下文不是越多越好。你給太多，模型反而抓不住重點。正確做法是入口短、知識分層、按需讀取。就像廚房裡的食譜架，不需要把全世界食譜都擺上去，放今天用得上的就好。
工具訪問。 工具少而精，比工具多更重要。Agent 最怕的不是沒工具，而是兩百個工具擺在面前不知道選哪個。給它的工具應該像瑞士刀上的每一片刀片，每個做一件事，可以組合。
專案記憶。 對話會結束，上下文會壓縮，但倉庫裡的檔案會留下來。重要事實應該沉澱成文件，而不是留在聊天紀錄裡。就像辦公室裡的公告欄，重要的事貼上去，新人進來一眼就能看到。
狀態管理。 長任務不能只靠對話記錄。讓 Agent 寫一個計畫檔，記錄進度、風險、下一步。就算上下文被壓縮，它也能回到這個檔案繼續工作。
驗證機制。 這是 Harness 的靈魂。單元測試、整合測試、lint、typecheck、build。對 Agent 來說，最有價值的反饋不是「你寫得不錯」，而是「Expected Decimal('85.50'), got Decimal('90.25')」。這種反饋非常清楚，Agent 能基於它繼續修。
權限與沙箱。 Agent 需要自由，但不能無限自由。改測試可以自動，改核心支付邏輯需要審查，刪除資料必須拒絕，存取生產金鑰不允許。就像醫院手術室，主治醫師可以動刀，實習醫師只能在旁邊看。
可觀測性。 Agent 失敗不可怕，可怕的是失敗以後你不知道它為什麼失敗。每一步操作都應該有日誌：讀了什麼檔案、呼叫了什麼工具、哪一步失敗、怎麼修復。
人類接管。 高級不是全自動，而是該自動的自動，該停的停。Harness 的目標不是讓人消失，而是讓人從「手寫每一行程式碼」變成「設計規則、審查結果、處理關鍵決策」。
四、落地清單：四步就能開始
不需要一上來蓋一座大平台。四步就夠起步。
第一步：補最小專案上下文。 新增三個檔案：AGENTS.md（專案地圖）、docs/architecture.md（模組邊界）、docs/testing.md（測試命令與策略）。AGENTS.md 只做地圖，不寫手冊，控制在三十行以內。這就像幫新同事準備一份入職指南，不需要鉅細靡遺，但要讓他在第一天不會迷路。
一份夠用的 AGENTS.md，大概長這個樣子：
# 專案地圖
## 這個專案在做什麼
一句話說明核心目標，不要超過兩行。
## 目錄怎麼看
- src/api/ 對外接口
- src/core/ 領域邏輯，禁止在此呼叫外部 API
- tests/ 測試，只增不減
## 動工前必讀
- docs/architecture.md 模組邊界與依賴方向
- docs/testing.md 測試命令與策略
## 完成標準（必須全部通過）
pytest -q
npm run lint
npm run typecheck
## 禁止事項
- 不直接改 main 分支
- 不動 migrations/ 底下的既有檔案
- 不把金鑰寫進任何程式碼或設定檔
請注意它只有三個重點：專案在做什麼、目錄怎麼看、什麼叫做完。它刻意不寫成手冊，因為規則越長越容易被忽略；真正重要的東西，必須短到能一次讀完。這份地圖最大的價值，是讓 Agent 在第一次動手之前就知道邊界在哪裡，而不是撞牆之後才回頭問。
第二步：把「完成標準」機器化。 不要寫「程式碼品質要好」，要寫 pytest -q、npm run lint、npm run typecheck。能機器判斷的，就不要靠感覺判斷。這就像體檢報告，醫生不會說「你的健康狀況還不錯」，而是給你具體的數字和指標。
同樣的道理，工具邊界也該寫成白名單而非描述。底下是一份最小可用的權限規則示意（假設放在 docs/testing.md）：
可自動執行（無需審批）
pytest -q
npm run lint / typecheck / build
讀取任意專案內檔案
需人工審批
修改 src/core/ 底下任何檔案
新增或變更資料庫 migration
修改 CI 設定與部署腳本
永遠拒絕
寫入或讀取生產環境金鑰
刪除 tests/ 底下既有測試
執行 rm -rf / DROP TABLE 類指令
注意這份清單用的是「動作白名單」而不是「請小心」這種提醒。提醒會被忘記，白名單會被機器執行。
第三步：Agent 變更統一走 PR。 不要讓 Agent 直接改主分支。每個任務一個分支，Agent 提交 diff，CI 跑，人類 review，合併。PR 模板裡強制填寫驗證結果與風險等級。這就像銀行的雙人管控，一個人不能單獨完成大額交易，必須有第二個人審核。
第四步：記錄失敗並改進 Harness。 每次 Agent 出錯，不要只罵模型。要問：是任務沒寫清楚？上下文缺了？工具太多？沒有測試？權限太大？然後把經驗沉澱進 AGENTS.md、新測試、新 lint 規則、新審批規則。這就是閉環。
五、MCP 與 Harness 的關係
MCP（Model Context Protocol）是 AI 應用連接外部工具和數據源的標準接口。如果把 Agent 比作一位廚師，MCP 就像廚房裡那些標準化的插頭：瓦斯爐、水龍頭、抽油煙機，都有統一的規格，換了品牌也能用。
但 MCP 解決的是「工具怎麼接入」的問題，Harness Engineering 解決的是「工具接入後怎麼安全、可靠、可驗證地使用」的問題。這兩件事不一樣。
你可以給 Agent 接一百個 MCP 工具，但如果沒有權限、驗證和任務邊界，它仍然會迷路。就像廚房裡擺滿了各種高級器具，但沒有食譜、沒有出菜流程、沒有副主廚檢查，廚師照樣會手忙腳亂。
MCP 是標準化的插頭，Harness 是整棟建築的電路系統。插頭再多，沒有保險絲和配電盤，一樣會跳電。
六、三個常見誤解
誤解一：提示詞越長越好。 不對。提示詞太長會稀釋重點。正確做法是入口短、知識分層、規則明確、讓 Agent 按需讀取。就像好的辦公室不會把所有規章制度貼在同一面牆上，而是分類存放、需要時再查。
誤解二：工具越多越強。 不對。工具多會增加選擇成本。Agent 可能把低風險任務搞成高風險操作。工具要少、穩、可組合。就像好的廚房不會擺滿兩百種器具，主廚常用的就是那幾把刀、幾個鍋子。
誤解三：Harness Engineering 只適合大公司。 不對。小團隊更需要它，因為小團隊沒有那麼多人肉 review。哪怕只加一個 AGENTS.md 和測試命令，也比純 Vibe Coding 穩定很多。
帶走三句話
- 模型是大腦，Harness 是身體。 沒有工作台的大腦，只能在聊天裡空談；有了工具、驗證、權限和日誌，大腦才能真正動手做事。
- 完成標準不該由模型說了算。 測試通過、lint 通過、人類審查通過，才是真的完成。「我覺得對了」不算。
- 從一個 AGENTS.md 開始就好。 不需要一次蓋完九個模組。先讓 Agent 有地圖、有驗證命令、有 PR 流程，就已經贏過大多數團隊。
下一步
想繼續往下走，可以先補齊框架層的基礎（LangChain 完整教學 2026），再看工具如何標準化接入（MCP 協定詳解），最後用架構視角收束（三層 Agent 協同框架）。