深入：把 Harness 當平台能力
這一層你已經不是在做「某個 agent」，而是在設計 agent 運行基礎設施。工作性質最接近平台工程（Platform Engineering）、SaaS Infra、內部開發者平台（IDP）。
情境：你從一個 agent 變成要支撐十個 agent 的平台
過去半年，你靠進階層的 middleware + state + observability 把一個 agent 打磨得很穩。現在你的同事看到成效，通通跑來問：
「你能不能幫我的團隊也做一個？我們有不同的任務、不同的權限、不同的風險。」
你本來想直接 fork 三份，結果發現三份都要維護、三份都要升級、三份的 solve rate 越來越難比較。更糟的是，三份都用不同的 log schema，你想統一評估根本辦不到。
這就是深入層的起點：你要做的不是第四個 agent，而是「能產出第 4、5、6 個 agent」的平台。
InfoQ 對 OpenAI 這波方法論的整理很精準：Harness engineering 讓人類工程師的角色，從直接寫 code，轉成設計環境、指定意圖、提供結構化 feedback，並用 telemetry 監看與修復整個流程。
一、深入層要回答的四個問題
問題 1：你的 Harness 是不是可版本化？
一個成熟的 harness 不該只有「現在這版規則」，而應該能有：
- harness v1 / v2 / v3（像軟體版本一樣 diff 與 rollback）
- 不同模型對應的策略組（Claude / GPT / Gemini / 本地模型）
- 不同任務類型對應的工具集
- 可 rollback 的規則更新
- A/B 比較 solve rate 與成本
沒做到這件事，你的 agent 優化就沒辦法系統化。你永遠是「憑感覺覺得變好」，不是「數據證明變好」。
問題 2：你的 Harness 是不是把 repo 當作 control plane？
OpenAI 的實戰顯示：architecture doc、execution plan、decision log、tech debt 都與 code co-located。因為 agent 需要的是：可讀、可改、可驗證、可版本追蹤的工作環境。
這意味著深入層的 repo 不只是 code storage，而是 agent control plane 的一部分。
你可以用這個問題自我檢查：如果你把 agent 的 prompt、rule、middleware 全部拿掉，只留下 repo 裡的文字檔，新來的人能不能重建整個 agent 系統？ 如果不能，你的 control plane 還不夠完整。
問題 3：你的 Harness 有沒有成本治理？
深入層不只問「能不能做」，還要問：
- 這個任務平均要幾輪？
- 哪個模型成本最低但成功率足夠？
- 哪些工具最浪費 token？
- 哪些任務應由 cheaper model 處理，哪些要 frontier model？
這是典型的 FinOps 思維應用到 agent 領域。LangChain 明確把 token efficiency 與 latency 列為 harness 設計目標的一部分 — 因為 production 級 harness 必須把成本納入設計變數。
問題 4：你的 Harness 能不能支援多 agent 與 delegation？
PuppyGraph 2025 對 architecture 的總結提到 sub-agent delegation：複雜任務可拆成隔離子代理，各自有自己的 context 與 tool access，再把結果拼回父流程。
到了深入層，這件事通常不是「能不能做」，而是「怎麼防止 delegation 讓狀態更亂、責任更模糊、成本更高」。所以你需要：
- 子代理任務邊界 — 每個 sub-agent 的職責明確。
- Context inheritance 規則 — 哪些上下文要傳、哪些要隔離。
- 統一 trace id — 跨 agent 仍能追同一個任務。
- 可合併的 artifact 格式 — 子任務結果能被父流程消化。
- Escalation ownership — 誰出事誰負責，不能互相踢皮球。
二、深入層的四種成熟能力
能力 1：Harness evaluation
你不能只 benchmark 模型，還要 benchmark 整個 harness：
| 指標 | 用途 |
|---|---|
| 任務成功率 | 最核心的 KPI |
| 首次成功率 | 衡量 retry 損耗 |
| 平均 retry 次數 | 看哪些 pattern 有優化空間 |
| 平均 token 成本 | 成本治理 |
| 人工介入率 | 衡量自主性 |
| 完成時間 | 衡量效率 |
這組指標會讓你從「覺得變好」變成「證明變好」。
能力 2：Failure-to-rule pipeline
HumanLayer 最值得抄的思路：把錯誤直接轉化成未來的防呆規則。
成熟團隊會把這件事制度化：
1. 收集失敗 trace
2. 做 failure taxonomy（分型）
3. 找可工程化的修正點
4. 更新 prompt / context pack / middleware / permission
5. 重跑評估集
6. 比較 solve rate 與副作用
注意最後一步：比較副作用。每次為了修 A 而加規則，都可能讓 B、C、D 的成功率下降。沒有評估集，你永遠不知道自己是不是在東牆補西牆。
能力 3：Human-in-the-loop design
深入層不追求「沒有人」，而是追求「人只出現在高價值判斷點」。OpenAI 的案例就明顯是這樣：agent 盡量自己做，遇到需要判斷的地方才拉人。
所以你要明確定義四種 gate：
| Gate 類型 | 觸發情境 | 典型例子 |
|---|---|---|
| Approval gate | 不可逆或高風險操作 | deploy 到 production、drop table |
| Review gate | 變更影響外部合約 | 改 API schema、改金流邏輯 |
| Risk gate | 觸發黑名單條件 | 動到 secrets、動到 audit log |
| Budget gate | 超過成本上限 | 單任務 token > X、總成本 > Y |
這四個 gate 的共通點：它們不是靠「agent 自己判斷」，而是靠 middleware 強制攔截。
能力 4：Harness as product capability
當你的產品本身開始依賴 agent，Harness 就不只是內部工程工具，而會變成產品核心能力的一部分：可靠性、安全性、可審計性、可觀測性、成本控制，全部都會回到產品體驗上。
這時你要思考的問題會變成：
- 客戶能不能審計 agent 做過什麼？
- 如果 agent 做錯，誰賠誰？
- 不同客戶的資料怎麼隔離？
- 你的 SLA 是什麼？（任務完成率？延遲？成本上限？）
這些問題不解決，你的 agent 永遠只能當 demo，不能當產品。
三、深入層的三條反直覺原則
原則 1：越成熟的 Harness，越知道什麼「不要做」
2026 的社群討論有一條很關鍵的反直覺：不要把所有控制邏輯都塞進系統。因為模型能力上升後，你今天寫的複雜控制流，明天可能就成了束縛。
這也是為什麼 Anthropic、OpenAI 新的 agent skill 都在往「更少 scaffolding、更多 tool-use」的方向走。
原則 2：最佳 Harness 不一定最聰明，而是最好刪
如果你的平台沒辦法快速換模型、換工具、換驗證流程，那就不是面向未來的 harness。
一個成熟平台的標誌，不是它有多少功能，而是它刪掉一個功能時，有多少其他地方會連帶壞掉（越少越好）。
原則 3：真正的護城河是軌跡資料與失敗學習
Prompt 很容易被複製，工具也會同質化；但你透過真實任務蒐集的 trace、失敗模式、評估資料與優化迭代，才是難以複製的資產。
這也是為什麼 2026 的頂尖團隊幾乎都在做同一件事：把 agent 的 trace 結構化、版本化、留下來。不是為了監控，是為了建立別人學不走的 know-how 資料庫。
AI 協作：學了這個，跟 AI 怎麼配合？
深入層的工作大多是設計決策：評估集怎麼設計、gate 放在哪、如何把 failure 變成 rule。這些決策適合跟 AI 一起「辯論」，而不是請它直接給答案。
你的人類優勢：
- 只有你知道公司的風險胃納、SLA 承諾、合規紅線。
- 只有你能判斷「這個優化值不值得引入複雜度」。
可以這樣跟 AI 說：
我正在為一個 [產品場景] 的 agent 平台設計 human-in-the-loop gate。我已有以下操作清單：[貼上清單]。請你扮演「保守的 SRE」角色，針對每個操作挑戰我：(1) 這屬於 Approval / Review / Risk / Budget 哪一種 gate？ (2) 如果不放 gate，最糟情況是什麼？ (3) 放了 gate 會拖慢多少？最後給我一份建議清單，並標註哪幾條你覺得我最可能想跳過但其實不該跳。
練習題
本堂重點回顧
- Harness 可版本化 — 像軟體一樣 diff、rollback、A/B 比較。
- Repo = control plane — 把 agent 系統的所有知識寫回 repo。
- 成本治理 + 多代理 — 深入層的 harness 必須同時處理 FinOps 與 delegation。
- 反直覺原則：模型越強、harness 越簡；最佳 harness 是最好刪；真正的護城河是 trace 與失敗學習。
下堂課：實戰總結 — 把四層能力濃縮成一份「最小可運行 Harness 檢查表」，讓你下禮拜就能開始動手。
挑戰任務
為你的 agent 設計一組最小可行的評估集：(1) 至少 5 個代表任務，(2) 每個任務的成功定義是什麼，(3) 你要追蹤的 6 個指標（成功率、首次成功率、retry 次數、token 成本、人工介入率、完成時間）目前大概落在哪個數量級。
為你的 agent 設計一份 gate 清單，至少涵蓋 Approval / Review / Risk / Budget 四種。每個 gate 寫清楚：(1) 觸發條件、(2) 需要誰介入、(3) 介入時要看到什麼資訊才能決策。
把 HumanLayer 的 failure-to-rule 六步驟（收集 → 分型 → 修正點 → 更新 → 重跑 → 比較）應用到你自己的專案。針對其中一個已經發生過的 failure，完整走一遍這六步，寫出每一步你會做什麼、產出什麼。