harness engineering 是什麼？把教訓寫進環境

2026 年 2 月 11 日，OpenAI 工程師 Ryan Lopopolo 公開一個內部實驗的成績單：五個月、大約一百萬行程式碼、一個有每日使用者的內部 beta 產品——零行程式碼是人手寫的。應用邏輯、測試、CI 設定、文件、觀測工具，全部由 Codex 代理寫成。團隊估計，花的時間大約是人工手寫的十分之一。

模型人人租得到，prompt 也沒有什麼獨門秘方。支撐這個成績的主角，是那個團隊花五個月一磚一瓦搭起來的東西：agent 工作的環境。

而這個環境，六天前才剛有名字。

Harness engineering（代理工作環境工程）是設計與維護 AI agent 工作環境的實踐。核心公式是 agent＝model＋harness：模型以外的一切都算 harness——context 檔（如 AGENTS.md）、可用工具、驗證迴路、權限邊界、回饋機制。核心紀律是每次 agent 犯錯，就把修正工程化進環境，讓同一個錯誤在結構上不再發生。模型是別人訓練好的，你能調的是環境。

起源：六天內，一個詞變成一門學科

2026 年 2 月 5 日，HashiCorp 共同創辦人、終端機 Ghostty 的作者 Mitchell Hashimoto 發表長文〈My AI Adoption Journey〉，記錄他從棄用聊天機器人、改用 coding agent，到讓 agent 幾乎全天候運轉的過程。文章裡有一條他反覆執行的紀律：

「只要發現 agent 犯了一個錯，就花時間工程化一個解法，讓 agent 永遠不再犯那個錯。」他接著寫：「我逐漸把這件事稱作 harness engineering。」

harness 這個英文字的本義是馬具——韁繩、鞍、挽具，讓馬力有方向；軟體圈也早有測試治具（test harness）一詞。Hashimoto 借它來指包在模型外面的整套裝備。

六天後的 2 月 11 日，Lopopolo 在 OpenAI 官網發表〈Harness engineering: leveraging Codex in an agent-first world〉，用前面那個一百萬行的實驗給了這個詞正式的工程內涵，並留下一句被廣泛引用的分工原則——「人類掌舵，agent 執行」（Humans steer. Agents execute.）。再過不到兩個月，martinfowler.com 在 4 月 2 日刊出 Thoughtworks 傑出工程師 Birgitta Böckeler 的專文，把 harness 的控制機制系統化成兩類：事前引導的 guides（前饋）與事後觀測的 sensors（回饋）。

一個詞從個人部落格、到大廠方法論、到方法學文獻，只花了八週。時間點也有跡可循：2025 年下半年起，coding agent 已經能連續自主工作幾十分鐘到幾小時，產出品質的瓶頸從「模型夠不夠聰明」移到「環境有沒有給它驗證與修正的辦法」。

harness 裡面有什麼

把 agent 想成一個手速奇快、但每天早上都失憶的新同事。他很聰明，可是昨天教過的事今天全忘。你有兩個選擇：每天口頭重教一遍，或是把公司的一切寫成他每天報到會自動讀的新人手冊、給他配好工具帳號、設好權限、裝好「做錯會亮紅燈」的檢查。後者就是 harness。

元素	具體形式	解決什麼
context 檔	AGENTS.md、CLAUDE.md	專案慣例、常用指令，agent 每次開工自動讀
工具	CLI、MCP server、自訂 script	決定 agent 能對世界做什麼
驗證迴路	測試、lint、type check、結構測試	讓 agent 自己發現自己錯了
權限與沙箱	sandbox、指令 allowlist、人工核可點	控制犯錯的爆炸半徑
回饋機制	hooks、CI、觀測遙測	把教訓變成制度，不靠人記得

驗證迴路是其中的槓桿點。Hashimoto 的原話：「給 agent 一個驗證自己工作的方法，它多半能自己修正錯誤、防止回歸。」

這也是整個學科最核心的一句話：教訓沉澱進 harness，不沉澱在人腦。人腦記得的教訓會隨著換人、換 session 消失；寫進 AGENTS.md 或 lint 規則的教訓，每個 session 自動生效，而且模型換代之後還在。

prompt → context → harness：三級階梯

這個詞常跟前兩波「engineering」放在一起講，範圍一層包一層：

1. Prompt engineering（約 2023 年起）——一次對話怎麼問，措辭、範例、格式。
2. Context engineering（約 2025 年起）——單次任務給模型看什麼資料，檢索、壓縮、擺放位置。
3. Harness engineering（2026 年起）——跨所有 session 的整個工作環境，工具、驗證、權限、回饋全包。

時間軸剛好對應使用形態的演進：聊天 → 單次任務 → 長時間自主工作。你跟 AI 相處的時間單位越長，越靠外層的工程。

一個邊界要先講清楚：「agent harness」在業界有兩層用法。一層指產品內建的執行環境——Claude Code、Codex CLI 這類工具本身就是包在模型外的 harness，負責工具呼叫、context 管理、權限控制；Firecrawl 在 2026 年 4 月的整理估計，Claude Code 這層程式碼規模已超過 50 萬行。另一層指使用者在自己專案裡搭的外層環境，Böckeler 稱之為 outer harness。Hashimoto 與日常討論裡說的 harness engineering，多半指後者——你自己能控制的那層。

實際長什麼樣：Claude Code 與 Codex 的做法

落到日常，harness engineering 的動作其實很樸素：

• 更新 context 檔——Hashimoto 說，簡單的錯（agent 一直跑錯指令、找錯 API）直接寫進 AGENTS.md 就解決。
• 加 hooks——在 agent 每次編輯檔案後自動跑 formatter 和 lint，錯誤當場被機器攔下，省下一輪對話。
• 設沙箱與 allowlist——高風險指令留人工核可點，其他放行，agent 才能長時間無人值守。
• 建結構測試——OpenAI 那個實驗用機械式的架構規則與結構測試強制依賴分層，agent 想違規，CI 直接擋下。

OpenAI 團隊還為 agent 維護一個結構化的文件目錄——程式碼地圖、執行計畫、設計規格，全部是給 agent 讀的機器可讀文件。人的工作從寫程式移到設計環境與描述意圖。

同一套思路也長進了瀏覽器代理：Browser Use 開源的 Browser Harness 讓 agent 在任務中自己補寫 helper 函式、留給下次重用——agent 開始參與維護自己的 harness。

限制與代價

harness 本身是一份要維護的資產，這件事常被低估。

context 檔會膨脹。每個教訓都寫進 AGENTS.md，半年後它變成一份幾千行、agent 每次都要吞的文件——過時的規則跟有效的規則混在一起，反而汙染 context。教訓要定期整理、合併、刪除，跟寫程式碼一樣。

錯的規則會系統性帶偏。口頭糾正錯一次只影響一次；寫進 harness 的錯誤規則，每個 session 都在生效。寫進去之前值得多想十秒。

目標從來就包含人。Böckeler 在專文裡特別提醒：「好的 harness 不必以完全消除人工輸入為目標，重點是把人的輸入導到最重要的地方。」全自動是手段之一，選項裡永遠有人工核可點。

這個詞還年輕。2026 年 2 月才出現，「harness」到底指產品 runtime 還是使用者的外層環境，各家用法還在收斂。讀相關文章時，先確認作者講的是哪一層。

成本要算。一次性的小任務，搭環境的成本高過收益。harness 是給重複發生的工作準備的。

你可以先做的一件事

下次 agent 犯錯，先忍住別只在對話裡糾正它。問自己：什麼樣的檔案、測試或規則，能讓這個錯誤永遠不再發生？然後花十分鐘，把答案寫進 AGENTS.md（或 CLAUDE.md）、或加一條 lint、一個測試。開一個全新 session，讓 agent 重做同類任務，驗證它真的不再犯。

這個十分鐘迴圈就是 harness engineering 的最小單位。做十次，你的 agent 環境已經好過大多數人；做一百次，你手上是一份會複利的資產——模型每半年換一代，你的 harness 一直都在。

資料來源：Mitchell Hashimoto 部落格、OpenAI、martinfowler.com、Firecrawl、InfoQ

矽基前沿 · 大百科線（編輯：廖玄同），《harness engineering 是什麼？把教訓寫進環境》，矽基前沿 [Si]gnals，2026-07-05。https://signals.tw/articles/what-is-harness-engineering/