Ryan Lopopolo 的 Harness Engineering：模型不是整個 Agent，外殼才是槓桿

Agent Systems / Context Engineering

真正決定 agent 表現的，是模型外面的 harness

Threads 貼文指出：同一顆模型丟進不同框架、餵不同 context，表現可能像兩個不同產品。Ryan Lopopolo 開源的 harness-engineering 把這件事整理成 field guide：把模型固定成黑盒，改善外部兩個槓桿——context 與 tools。

一句話：Prompt engineering 不是消失，而是被降級；agent 的競爭點變成「它能看到什麼、能用什麼工具、怎麼證明做完、錯誤如何回灌」。

Harness 元件	它解決什麼	Allen / Hermes 對應
Context	讓 agent 找回意圖、限制、domain ontology、既有決策與品質標準。	SOUL.md、AGENTS.md、skills、KB、project notes、session_search。
Tools	讓 agent 操作真實系統，而不是只輸出文字建議。	terminal、browser、GitHub、Google Workspace、Apple / email / cron tools。
Authority	界定什麼可自動做、什麼要人審、什麼不可碰。	外部發送、付款、公開發文需更高門檻；內部整理與驗證可高自主。
Proof	要求 agent 留下可驗證結果：測試、diff、URL、API 回應、artifact。	Allen 偏好「實測導向 execution」，不是只交計畫。
Feedback loop	把失敗、修正、accepted work 變成下次可取用的 context / tests / examples。	把踩坑寫進 skills；把 durable preference 寫 memory；用 regression case 防退化。

GitHub reality check

lopopolo/harness-engineering 是 Ryan Lopopolo 的 anthology、field guide 與 agent context bundle；GitHub API 顯示 repo 於 2026-07-18 建立、約 2.1k stars、CC BY 4.0 授權，主要語言標示 Python。README 明確把 harness engineering 定義為：在保持模型與 coding agent 黑盒不變的情況下，透過 context、tools 與環境設計改善 agent output。

不要只換模型

如果 agent 換三個模型還是一樣笨，問題常在任務被餵得不對、工具不可用、驗證缺失、權限邊界混亂，而不是模型 IQ 不夠。

把組織判斷做成可累積資產

accepted work、user corrections、incident postmortems、code review decisions 應變成 examples、checks、skills 或 tests。

Agent-first repo 應會教 agent