一、一句話定義
Harness Engineering = 圍繞 AI Agent 構建的「生產級基礎設施層」。
它不改善模型本身的推理，而是設計護欄、回饋、可觀測性與工具編排，讓 Agent 從「Demo 能跑」進化為「上線不翻車」。
二、三代演進：從提示詞到架構工程
AI 工程方法論的核心焦點，已經歷了三次重心遷移：
2022-2024 2025 2026
┌──────────┐ ┌──────────────┐ ┌────────────────┐
│ Prompt │ → │ Context │ → │ Harness │
│Engineering│ │ Engineering │ │ Engineering │
└──────────┘ └──────────────┘ └────────────────┘
「怎麼問？」 「模型知道什麼？」 「怎麼管、怎麼活？」
| 世代 | 核心問題 | 焦點 | 典型技術 |
|---|---|---|---|
| Prompt Engineering (2022-24) | 「我該怎麼問？」 | 單輪指令的措辭優化 | Few-shot、CoT、Persona |
| Context Engineering (2025) | 「模型知道什麼？」 | 動態組裝上下文窗口 | RAG、記憶管理、工具定義 |
| Harness Engineering (2026) | 「它怎麼被管理與保護？」 | 完整的代理運行環境設計 | 護欄、回饋迴路、可觀測性、沙盒 |
關鍵洞察
「Agent 不難，Harness 才難。」
模型越來越強，但 Agent 在生產環境中依然頻繁翻車。問題不在模型的「智力」，而在缺乏一套成熟的「操作系統」來約束與引導它。
三、Harness 的核心構成（四大支柱）
🛡️ 支柱一：護欄 (Guardrails & Safety Constraints)
用確定性規則限制 Agent 的行為邊界，確保它不會越權或造成損害。
| 機制 | 說明 | 實例 |
|---|---|---|
| 權限邊界 | 嚴格定義可訪問的資料與 API | 禁止 rm -rf /、禁止修改 ~/.ssh/ |
| 輸出驗證 | 在 Agent 輸出生效前用傳統工具檢查 | Linter、單元測試、安全過濾 |
| 人機協作 (HITL) | 高風險決策前強制人工確認 | 刪除資料庫前彈出確認 |
| 成本上限 | 防止 Token 消耗失控 | 每日預算熔斷器 |
🔄 支柱二：反饋迴路 (Feedback Loops)
讓 Agent 具備自我糾錯與隨時間進化的能力。
- 自我驗證：Agent 完成任務後，自動執行測試套件驗證結果
- 錯誤修復循環：失敗時記錄軌跡 (Trace)，將負面樣本回饋知識庫
- 持續改進：每次失敗 = 一次優化提示詞或工具定義的機會
- 跨代理審查：用另一個 Agent 檢查輸出品質（「雙重驗證」）
👁️ 支柱三：可觀測性 (Observability)
Agent 的決策過程極度複雜，必須具備透明度，否則出了問題無法定位。
- 全程追蹤 (Tracing)：記錄每一個思考步驟、工具調用、中間狀態
- 成本監控：Token 用量、任務時間、失敗率的即時儀表板
- 異常告警：超標自動推播（Telegram / Slack）
- 回放與審計：精確重現「Agent 在哪一步偏離了預期」
🔧 支柱四：工具編排與狀態管理
- 工具編排 (Tool Orchestration)：連接外部 API、文件系統、終端命令，確保安全隔離
- 狀態持久化 (Memory & State)：解決 LLM 在長時任務中的上下文遺忘
- 規劃與分解 (Planning)：將複雜任務拆解為可驗證的原子步驟
四、業界實踐案例
OpenAI 的做法
- 在 Codex 等代理產品中引入「沙盒執行環境」，所有 Agent 生成的程式碼先在隔離容器中執行驗證，通過後才寫入正式環境
- 多層 Guardrail：語法檢查 → 安全掃描 → 測試通過 → 人工審核
Anthropic 的做法
- Claude 的「Constitutional AI」本質就是 Harness 的一部分——用一套內建的價值觀規則約束模型輸出
- Claude Code 引入
CLAUDE.md作為專案級 Harness 配置，定義 Agent 的行為規範
我們的 Personal AI OS（教練的系統）
教練，您的系統其實已經在實踐 Harness Engineering！ 只是之前沒有用這個術語來描述：
| Harness 構成 | 我們的對應實作 |
|---|---|
| 🛡️ 護欄 (Guardrails) | AGENTS.md 第 2、3、9 條（高危指令阻斷、零信任、成本鐵律） |
| 🔄 反饋迴路 (Feedback) | autoDream 記憶重組 + KAIROS 異常偵測 + Telegram 推播 |
| 👁️ 可觀測性 (Observability) | usage_tracker.py + watchdog.py + heartbeat.log |
| 🔧 工具編排 (Tools) | ModelSelector 統一路由 + OpenClaw Gateway 工具調度 |
| 📋 狀態管理 (State) | openclaw.db SSOT 資料庫 + GEMINI.md 戰情室 |
| 🧠 記憶 (Memory) | OpenClaw MEMORY.md + 11 年日記護城河 |
| 🏗️ 規劃分解 (Planning) | Swarms 多代理派工 + 龍蝦確定性 SOP |
五、核心公式
生產級 AI Agent = 強模型 (Model) + 成熟的 Harness
其中 Harness = 護欄 + 反饋迴路 + 可觀測性 + 工具鏈 + 狀態管理
「如果 Agent 犯了一個錯誤，Harness 工程師不是去修改 Agent 的 Prompt——而是修改環境或約束，讓它『不可能再犯』同樣的錯。」
這就是為什麼我們剛才在 AGENTS.md 寫入成本鐵律、在 model_selector.py 植入熔斷器——這些正是 Harness Engineering 的實踐。
六、CTO 戰略建議
基於這份研究，我們 Personal AI OS 已經走在 Harness Engineering 的正確軌道上。建議下一步強化：
- 強化可觀測性：建立一個輕量級的「Agent 執行軌跡回放」功能，讓教練可以看到大阿爪每一步做了什麼決策
- 制度化反饋迴路：每次 Agent 犯錯時，不只修 Bug，而是在
AGENTS.md新增一條「禁止行為」規則（我們剛剛做的成本鐵律就是最佳範例） - 擴展護欄清單：將所有高危操作（WordPress 發布、CRM 資料修改）加入 HITL 確認流程
本報告由 Personal AI OS CRO (研究長) 產出。2026-04-02 21:34 TPE
想要為您的企業打造不翻車的 AI Agent 系統？
漫遊數位提供專業的 Harness Engineering 顧問服務，助您從「Demo 實驗」進化到「生產級系統」。
