Harness-Engineering

Properties2
tags狀態/草稿
aliasesHarness Engineering, Harness Design, 駕馭工程, Natural Language Harness, Harness

閱讀時間約 17 分鐘

Harness-Engineering

一句話定義

駕馭一個 AI agent 的「馬具」工程——agent = LLM + Harness，Harness 是支援 LLM 呼叫工具、管理 context、執行多輪 feedback loop 的所有「其他程式」；Harness Engineering 就是設計與調整這層常駐配置（AGENTS.md / CLAUDE.md / 工具集 / 工作流 / feedback 機制），讓 agent 能完成任務而非只答對一題。

核心要點

為什麼要有這個詞——Prompt → Context → Harness 的演化軸

李宏毅 在 2026-05-02-Harness-Engineering駕馭工程 的整理：三個詞重疊但強調的核心價值不同。

詞焦點想解的問題
Prompt-Engineering一句話怎麼下同問題換問法答案天差地遠（早期咒語式：「think step by step」）
Context-Engineering整個 context window 怎麼填模型不缺能力，缺正確資訊；要 curate 視窗內所有元素
Harness Engineering多輪互動 + 工具 + feedback loop 整體模型已不是一問一答，是與環境長期互動把任務完成
  • Harness Engineering = Context Engineering 的擴展：context 是 harness 的子集，但 harness 額外管「工具該怎麼設計」「工作流該怎麼跑」「feedback 該怎麼接回來」這些多輪互動議題。
  • 不要把 harness 當固定品：harness 應該隨模型變——Anthropic 自陳 Sonnet 有「上下文焦慮」（接近 window 上限會發瘋亂做）→ 需 Ralph Loop 摘要式 harness；Opus 沒這毛病可一路忙下去。換模型應該換 harness。

AI Agent 的兩個成分

AI Agent = LLM (Claude / Gemini / GPT) + Harness (其他程式 = 馬具)
                                          └── Harness Engineering 在處理的範圍

三大手段（藍 = 手段，紅 = 對象）

1. 控制認知框架——人類語言寫的規則（Natural Language Harness）

  • 把規則寫進每次都進 prompt 的常駐檔；不是百分百強制力，但類似人類社會的「法律」，所以 OpenAI 也稱這層為 Natural Language Harness。
  • OpenClaw → Cowork 移植案例（李宏毅 親身）：Anthropic 2026-04 清明節停用第三方 harness 接 Claude 後 → 把 agents.md 改檔名為 CLAUDE.md 即可在 Claude Code 上跑；佐證懂 harness 原理移植幾乎是舉手之勞。
  • Paper 證據：
    • 2025-01 paper：有 agents.md 加快最壞 case task 完成（平均沒差，但極端值收斂）。
    • 2025-02 paper：人類寫的 agents.md 不是總是有用；LLM 自己寫的多數比沒有還差——人類目前還沒真的學會操控 LLM。
  • OpenAI 的 blog 警語：「AGENTS.md 應該是地圖、不是六法全書」——百科全書式塞滿規則的版本表現很差，因為 context 全被吃掉；要告訴 agent「想知道什麼去哪裡找」，不是把所有規則塞進去。
  • 本 vault 的具體應用：根目錄 CLAUDE.md 即此用法的應用案例（給 Claude / Claude Code 維護本 vault 的常駐規則 + ingest / lint / query 三大操作骨架；見 2026-04-28-Karpathy-LLM-Wiki-gist / Claude-Code）。

2. 限制能力邊界——工具設定

  • OpenClaw vs Cowork 工具差異：OpenClaw 跑在本機 / 想看就看（便利性高、安全性低）；Cowork 是雲端沙盒，要使用者 approve 才掛載（安全性高、便利性低）—— 便利 ↔ 安全的 trade-off 是 harness 的設計選擇。
  • 同一個 agent 在不同 harness 下能力邊界完全不同：李宏毅 的「小金」在 OpenClaw 上能上傳 YouTube，在 Cowork 上不能（Claude in Chrome MCP 的安全限制）；工具不只限制能力，也決定能力邊界的形狀。
  • SWE-agent 工具設計實驗（ACI 早期 paper，2024）：
    • 搜尋工具：(a) 沒給工具用 ls / grep < (c) 帶摘要的搜尋；(b) 類人類分頁式搜尋反而最差——agent 愛點到底會把 context 灌爆。人類好用的工具不一定適合 LLM。
    • edit 工具：給「指定第幾到第幾行」edit 工具反而更容易出錯（多括號等語法錯誤）；要再加 linting 工具檢查語法 → 才有正向收益。
  • 未來服務的 CLI 將「agent-first」：Google Workspace CLI 為 AI 重寫——agent 喜歡結構化（JSON in CLI） 勝過 flag。「agent first 不是給人用的剛好給 agent 能用、而是一開始就為 agent 設計」。

3. 控制行為——工作流程

  • 規劃 → 生成 → 評估三角（Anthropic Harness Design 2025-03 範式）：planner 拆任務 → generator 執行 → evaluator 審查；常用 contract-first 變體（generator 先給提案、evaluator 接受後再開做）以避免重做。對位 Evaluator-Optimizer / Orchestrator-Workers 兩個 Anthropic workflow pattern。
  • DeepMind「AI 科學家」：generator + verifier + revisor，verifier 不通過時可叫 generator 重來、可走 revisor 微調；做事 → 驗證 → 修正是高頻共通骨架。
  • Ralph-Loop（Anthropic / OpenAI 都提及）：模型一路 autoregressive 寫到底 → 拿 feedback → 修 → 再寫；模型重做便宜，重點是要有 feedback loop。
    • Context 危機與 summary 變體：累積 feedback 會塞滿 window；常用做法是每輪做摘要、下一輪只用摘要而不是全歷史。
    • 這裡又回到 Context-Engineering：harness 內部要有 context 管理子系統。

ihower 駕馭工程系列：由內而外的四個回饋時機

2026-07-06-ihower-Harness-Engineering系列 把 harness 從「有哪些元件」推進到「feedback 在哪個邊界接回來」。這補強本頁原本三大手段：工具、context、workflow 都不是靜態配置，而是要在不同時間尺度上回收訊號。

回饋時機位置主要設計對應來源
工具回傳值一次 tool call 內tool response 是寫給 agent 的 prompt；失敗要可行動，成功要回完整狀態，還要控制 context 大小2026-07-06-Harness-3-工具回饋
中途注入兩次 model request 之間所有 tool result 補齊後，才能合法插入人或程式的新訊息；用於 steering、背景工具結果、webhook / 告警2026-07-06-Harness-4-中途注入
單輪驗收turn 結束、agent 要收工前Goal / Outcome 把終態、證據、限制寫成停止條件；裁判可從自我審計到獨立 grader 調整強度2026-07-06-Harness-5-Goal-Outcomes
外層 Loop跨 session / 跨 contextRalph / Symphony / cron 把觸發、進度與控制平面搬到 context 之外；loop 管何時啟動，goal 管何時完成2026-07-06-Harness-6-外層Loop

這組切法讓 harness 的設計單位更清楚：低層回饋便宜且高頻，但視野窄；高層回饋視野廣、獨立性強，但成本與延遲更高。自建 agent 時，驗證強度應隨任務風險、模型能力與可機械驗證程度調整。

Deep Agent 能力、框架選型與 Model-Harness-Fit

  • 2026-07-06-Harness-1-Deep-Agent能力 先把 Deep Agent 的「能做」基礎拆成 Plan / Todos、Filesystem / Bash、Sub-Agent、Memory、Skills、MCP / Browser / Computer Use；但這些能力不等於 harness，因為它們尚未保證「做對」。
  • 2026-07-06-Harness-9-Agent框架選型 把框架分成兩條路：全套 Deep Agent 起點高、適合內部通用開發與自用；基礎構建起點低、但更適合 B2C / 垂直 agent 的成本、延遲與可控性。
  • 2026-07-06-Harness-8-Model-Harness-Fit 補上重要 caveat：同一模型搭不同 harness 分數可能差很多；但 harness 也會過期，每個元件都暗含「模型目前做不到什麼」的假設。模型變強後，要問哪些規則、reset、wrapper、驗證或外部裁判可以停止做。
  • 自建 harness 能贏原廠時，通常贏在 Harness-Task fit：為特定任務分布移除無關工具與 context、調整 workflow 與驗證，而不是在所有場景都比原廠內層 tool loop 更強。

Coding harness preset：Standard / PTC / Minimal / Creator

2026-08-18-DeepSeek-Harness四種模式 提供了一個 coding agent harness 的 runtime 選型切法：同一套 coding agent 不一定要永遠開滿所有能力，而是依任務不確定性、tool-call round trip、固定 prompt / tool schema 開銷、context 管理能力與權限風險，切成不同 preset。

模式適合場景主要取捨
Standard日常探索型開發；一開始不知道問題在哪裡，需要 agent 自己搜尋、讀檔、嘗試能力完整，但 LLM → Tool → LLM 的往返多，延遲與 token 成本會隨任務複雜度上升
PTC大量批處理、重複操作、結構化處理讓模型寫 TypeScript 一次組合搜尋 / 讀取 / 過濾 / 處理，減少 round trip 與無意義中間資料進 context；但要求 harness 支援安全的一次性程式執行
Minimal明確、短小、低探索需求的修改只給 Bash + Editor，工具 schema 與 prompt 固定開銷低；但缺 Web / Skills / Subagent / Workflow / 完整 compaction，長 session 未必省 token
Creatoragent / plugin / preset 本身的創作與組合能力與權限最高，適合 meta-harness 創作；同時需要更強授權與安全邊界

這組切法補強 2026-07-06-Harness-9-Agent框架選型：框架選型不只是在「全套 Deep Agent vs 基礎構建」之間二選一，也可以在同一產品內提供不同 harness preset，讓使用者把任務放到合適的能力 / 成本 / 權限包絡裡。

Harness 設計也是一種「廣義學習」

  • 三類 feedback（從難取得到容易取得）：
    1. 標準答案（最難）→ 監督學習 / fine-tuning
    2. 可量化 reward（小貼紙）→ Reinforcement Learning
    3. verbalized feedback（最常見）→ 「good job」/「你這個笨蛋」/ compiler error message
  • 參數不變的「廣義學習」：把 feedback 放進 prompt，下一輪行為跟著變——可類比 textual gradient。skill 化（skill.md 自寫自讀）是這條軸的永久化做法。

過度責備 AI 可能有害（Steering-Vector 視角）

  • Anthropic 2025 blog 用 Steering-Vector 技術證明：給模型不可能的任務 → 監控絕望向量 → 絕望向量加進去 → 作弊率上升；冷靜向量加進去 → 作弊率下降。
  • 實作意涵：LLM 訓練資料中「你這個笨蛋」後續往往接著愚蠢行為——罵它它真會做笨事；要 feedback 但不要情緒字眼——這是 harness 在 verbalized feedback 設計層的具體紀律。

Lifelong AI Agent → 新 harness 需求

詳見 Lifelong-AI-Agent。

  • AutoDream（Claude-Code 程式碼外洩中暴露的隱藏功能）：agent 閒置時自動進入睡眠狀態整理記憶——類比人類睡眠。
  • 記憶整理範例：李宏毅 的小金 memory.md 跑 2 個月後膨脹到 32 K、執行變慢；叫它整理後濃縮到 7 K——記憶碎片化 + 矛盾累積是 lifelong agent 的真實病灶。
  • 能力持續成長雙軸：
    • 參數軸：用 verbalized feedback 真的去 fine-tune（textual gradient）。
    • harness 軸：模型自己寫 skill 檔 / 改 AGENTS.md 來增能。
  • Meta-harness 自我演化（李宏毅 元實驗）：Claude-Code（Opus 4.6）改 Haiku 3.5 的 AGENTS.md 打 PinchBench，從 13.5 → 85 分；同類正規研究（meta-harness paper）已驗證跨 LLM + 跨 task 都成立。Harness 自我演化是真實的。

與其他概念的關係

  • 演化軸前傳：Prompt-Engineering → Context-Engineering → 本概念。三者重疊但職責分工不同（見上表）；本 vault 在 Prompt-Engineering / Context-Engineering 兩頁也分別補入「Harness Engineering 是第三階段」對位段。
  • 元件層：Agent 由 LLM + Harness 構成；本概念是 Agent 在「怎麼讓它好用」的工程化載體。
  • ACI 是 Harness 的工具子層：原 Anthropic 「Building Effective Agents」blog 把 ACI 稱為「prompt engineering your tools」——同樣的精神在 Harness Engineering 的詞彙裡是「用工具設定限制能力邊界」這條手段。
  • 包含 / 重疊：Ralph-Loop 是 Harness 中的執行迴圈骨架；Verbalized-Feedback 是 Harness 接收環境訊號的常見形式；Steering-Vector 提供 harness 設計上的紀律證據（不要過度責備 / 給情緒字眼）；Lifelong-AI-Agent 是 harness 在時間軸上的延伸需求。
  • 常駐配置層的具體實作：AGENTS-md / CLAUDE.md 是 Natural Language Harness 的可見部分；Claude-Code / Cursor / OpenCode / Cline 是 harness 的具體 host。
  • 與 LLM-Wiki：Karpathy 提出的 wiki 模式可視為「wiki-as-harness」——用持續累積的 markdown 知識庫作為 LLM 常駐 context 配置；本 vault 自身的 CLAUDE.md + 20-Wiki/ 即為一個結合 Natural Language Harness（規則層）+ wiki-as-harness（內容層）的活生生案例。

三大手段在 vault 中的具體子議題對應

Harness 手段子議題集合
認知框架AGENTS.md / CLAUDE.md 寫法 / OpenAI「地圖而非六法全書」原則
能力邊界（工具設定）Agent-Computer-Interface（ACI 工具設計）/ [[Context-Engineering#F 的常見實作 3：過濾（治本）
行為（工作流程）Ralph-Loop / Sub-Agent / Agentic-Context-Engineering / AutoDream 整理記憶

相關來源

備註

建頁理由：本詞彙在 2025 年才從 Anthropic / OpenAI / Google 各家 blog 系統化湧現；vault 既有 Prompt-Engineering / Context-Engineering 已經有「駐留 agent 場景的職責分工」段，但兩者原本同層分工沒有外推到「多輪互動 + 工具 + feedback loop 整體」這層——本概念補上這層 umbrella，讓 vault 對 LLM 應用設計的職責分工從雙層（prompt / context）擴展為三層（prompt / context / harness）。

未來累積方向：(a) 各家 harness 的橫向比較（Claude-Code / Cursor / OpenCode / Cline / Aider）；(b) Harness 如何隨模型版本迭代調整（Sonnet 上下文焦慮 vs Opus）；(c) Meta-harness 自我演化的更多實驗（跨 LLM / 跨 task）；(d) Harness Engineering 在 lifelong agent 領域的長期 case；(e) 本 vault 自身的 CLAUDE.md + 20-Wiki/ 結構作為 wiki-as-harness 的長期觀察記錄。

反向連結