既然我們知道「Agent = Model + Harness」，那麼在實務上，我們到底該如何著手建置、評估或診斷一個專案的 Harness 系統？
Google 的 AI 開發課程 day 1 給予了我們一個極具操作性的框架：不要把 Harness 當成抽象的程式術語，而是要將它具體化為五個用來拷問系統的黃金問題。當 AI 表現不佳時，打開這份清單，依序檢查 Tools（工具）、Context（脈絡）、Memory（記憶）、Guardrails（護欄）與 Feedback Loop（回饋迴圈）這五個維度，你就能在幾分鐘內精準找出系統的漏風之處。
Harness 五大盤點
它做得到什麼？
它看得到什麼？
它記得什麼？
它不能做什麼？
它怎麼知道自己做對了？
實戰步驟一：盤點 AI 的行動與認知邊界（答好前三個問題：Can, See, Remember）
要讓 AI 從「只會聊天的腦袋」變成「能幹活的特種兵」，你必須先為它鋪平行動與獲取資訊的通道：
問題一：它做得到什麼 (Tools)？模型本身完全不具備與現實世界檔案或系統互動的能力，它是沒有手腳的。你必須在環境中顯式地授予它工具（如 Bash 執行、Browser 瀏覽器、File System 讀寫、MCP 協定等）。舉例來說，當你叫 AI 幫你修 Bug 時，如果它沒有 Bash 執行權限，它就只能在對話框裡一邊通靈、一邊給你「可能可行」的修改建議；但如果你在 Harness 中賦予它 Bash 權限，它就能自己去跑測試、看 Log、安裝依賴，然後真正把 Bug 修好並提交。
問題二：它看得到什麼 (Context)？模型在預訓練（Pre-training）結束的那一刻，它的世界就定格了，它絕對不知道你公司的內部文件、私有資料庫或昨天的財報。你必須在環境中為它串接 RAG 檢索增強生成、Live Web 搜尋 API，或者透過專案結構讓它看見最正確的上下文脈絡。如果 AI 分析你的產品競爭力時只能胡謅，代表你沒有把對的 Context 資料流接進它的視野裡。
問題三：它記得什麼 (Memory)？AI 的大腦容量（Context Window）是非常稀缺的注意力資源，如果你的環境沒有做記憶管理，每次對話都逼它讀完一整本百科全書，它很快就會陷入恍神與認知退化（Context Rot）。你必須在 Harness 中設計好短期記憶（Session 歷史紀錄）與長期記憶（歷史踩坑記錄與專案規範），確保重要資訊能被精準檢索，無用雜訊被及時過濾。
實戰步驟二：架設防暴走的安全鎖與自我驗證機制（答好後兩個問題：Guardrails, Feedback Loop）
當你讓 AI 具備了強大的工具執行力與廣闊的視野後，系統也會隨之變得極度危險。你必須架設起防禦性的安全網與反饋網：
問題四：它不能做什麼 (Guardrails)？一個擁有 Bash 執行與檔案讀寫權限的 AI，理論上完全有能力在出錯時，一氣之下把你的核心資料庫 Schema、甚至是整個專案目錄一鍵刪光。因此，你必須在 Harness 中架設硬性的 Guardrails：設定隔離的 Sandbox 沙盒環境、精細的權限管理系統（Permission System），以及在執行高風險操作（如刪除檔案、更改管理員權限、發送實體 Email 給外部客戶）時，強制暫停並彈出視窗等待人類確認的審核流（Human-in-the-loop Approval Flow）。
問題五：它怎麼知道自己做對了 (Feedback Loop)？這是區分 Vibe Coding 與 Agentic Engineering 最關鍵的分水嶺。一個好的 AI 絕對不能寫完代碼或文案就直接「交卷」。你必須在環境中建立自動化的 Feedback Loop：當 AI 寫完程式，系統會自動在背景跑測試；如果測試爆錯（Test Failed），Harness 系統必須能自動捕獲錯誤 Log，並把這段 Log 當成新的 Context 丟回給 AI 的腦袋，命令它：「測試沒過，這是報錯 Log，請立刻自我診斷、修改並重新嘗試，直到測試通過為止」。有了這種不需人類介入的自我修正迴圈，AI 才能在交付到你眼前時，就已經是經過好幾輪自我重修後的 85 分成熟版本。