核心概念

這篇由 Hugging Face 發布的詞彙指南（2026 年 5 月 25 日）針對 AI Agent 領域中反覆被誤用、混淆的核心術語提供明確定義。作者的出發點是：當一個領域快速發展時，詞彙的演變往往比共識更快，同一個詞在不同框架中有截然不同的意涵，導致跨團隊溝通成本上升。

Model、Scaffold、Harness：三層分離

文章最核心的區分是將 Agent 系統拆解為三個可獨立優化的層次：

Model（模型） 是 LLM 本身（如 Claude、GPT、Qwen）。職責只有一個：接受文本輸入，輸出文本。單獨執行時，模型沒有記憶、沒有循環、也無法實際執行工具——它可以「表達」調用工具的意圖，但需要外部執行層才能讓意圖成真。

Scaffolding（腳手架） 是定義模型行為的層次，包括：

  • System prompt（系統提示）
  • Tool descriptions（工具描述）
  • 模型回應的解析規則
  • 上下文跨步驟的管理方式

Scaffold 決定模型「怎麼看世界」以及「怎麼行動」，是行為定義層，不是執行層。

Harness（控制框架） 是實際的執行層，負責：

  • 調用模型
  • 處理工具調用結果
  • 決定何時停止
  • 使 Agent 能在環境中持續循環運行

關鍵洞察：同一個模型加上不同的 harness，可以產生截然不同的產品體驗。Claude Code、Codex 等產品常將整個系統統稱為 "harness"，但在訓練流程中，分清 scaffold 和 harness 的邊界至關重要——訓練期錯誤的 scaffold 需要重新訓練，推理期錯誤的 prompt 只需重新部署，兩者成本天差地別。

Agent = Model + Harness

文章的定義源自強化學習的原始框架：Agent 是一個函數，接受觀察值（observation），輸出動作（action）；環境接收動作後返回新的觀察值，循環持續。

在 LLM 脈絡下，Agent = Model + Harness——這個公式強調兩個可分離的組件，模型本身不會「行動」，是 harness 讓模型在真實循環中運作。一個具體的編碼 Agent 結構：

  • System prompt + tool descriptions + 輸出格式 = scaffolding
  • 調用模型的循環 + 處理工具結果 + 決定何時停止 = harness

Context Engineering（上下文工程）

Agent 在每一步能看到什麼，決定了它能做什麼。上下文工程設計的對象包括：系統提示、工具描述、對話歷史、從外部知識庫檢索到的內容。隨著 Agent 運行，之前的步驟動態塑造後續調用的上下文——這使上下文管理成為獨立的工程學科。

記憶在此脈絡下分兩類：

  • 短期記憶：單次運行內保留在上下文窗口的內容（對話歷史、工具結果、推理過程）
  • 長期記憶：跨 session 持久化，存於外部儲存，按需注入上下文

Sub-agents 與 Orchestrator

Sub-agent 是「由另一個 Agent 調用來處理特定子任務的 Agent」，有自己的模型和 scaffold，可以獨立推理、使用工具、甚至再調用下一層 sub-agents。調用方不需要知道 sub-agent 的內部工作原理，只需取得返回結果。

三個容易混淆概念的區別：

  • Tool（工具）：函數調用，執行單一動作
  • Skill（技能）：完成目標所需的打包知識（例：「調查此錯誤、形成假設、寫修復」），可跨 agent 移植、按需加載
  • Sub-agent：有推理能力、可使用工具、可再調用下層 sub-agents 的完整 Agent

協調多個 Agent 的上層控制器稱為 Orchestrator（協調器）。

關鍵要點

  • Policy（策略） 定義 Agent 在任何情境下的行為概率分佈，一部分存在模型權重中，一部分由 scaffold 和 harness 決定。Policy 是行為的「規格」，Agent 是在環境中執行的「系統」，兩者不同。

  • Eval Harness（評估控制框架）：在評估時執行固定場景集合並記錄指標，不更新模型權重，用來測量 Agent 能力而非訓練能力。

  • 訓練術語三組：

    • Rollout / Trajectory / Trace：從開始到結束的一次完整 Agent 運行記錄（含 Agent 看到的、做到的、每步獲得的獎勵）
    • Reward：告訴訓練算法模型是否變更好的評分。可驗證的（測試通過/失敗）、學習的（人類偏好）、稀疏的（episode 末尾）、密集的（每步一個）
    • Rubrics（評分標準）：將獎勵拆解為帶權重的明確維度，而非單一數字

  • RL Environment（RL 環境）：接收動作、更新狀態、返回觀察值的任何可交互對象。以檔案系統為例：執行 touch foo.txt（動作）→ 文件創建（狀態更新）→ 返回更新後的文件列表（觀察值）。

  • 詞彙混淆的根源有三：領域快速發展、同一詞在不同框架有不同用法、許多術語至今無普遍接受的定義。

實務應用

這份詞彙表的最直接應用是跨團隊溝通精確化：當有人說「改一下 harness 的邏輯」時，需要釐清他們指的是執行循環（harness），還是系統提示與工具描述（scaffold）。混淆這兩層會導致優化方向錯誤。

對構建多 Agent 系統的工程師，最重要的實務區分：

  1. Sub-agent vs Tool：前者有推理能力和內部狀態，後者是純函數。選錯層次會帶來不必要的 latency（過度使用 sub-agent）或能力不足（把需要推理的任務做成工具）
  2. Scaffold 的修改成本遠低於模型權重的修改成本——推理期的 prompt 錯誤只需重新部署，訓練期的 scaffold 錯誤需要重新訓練

多代理網絡的湧現風險：Microsoft Research 紅隊測試報告 深入探討多 Agent 協調場景下的系統性風險，與本文 Orchestrator 和 Sub-agent 概念直接相關。MagenticLite：為小型模型優化的代理系統三層架構 是這套術語的實際架構落地案例。AI Eval 成本危機：評估比訓練更貴 討論 Eval Harness 的成本問題，可與本文 Eval Harness 定義對照閱讀。

延伸觀點

來自 SWE-bench 基準測試的具體數據讓 Harness 的重要性有了量化佐證：同一個模型在不同 agent harness 上的得分，從 46% 跳升至 80%（Cursor 內部研究）。這 34 個百分點的差異完全來自 harness 層的設計決策——上下文檢索策略、任務拆解方式、錯誤重試邏輯、記憶持久化方案——沒有任何模型層的改動。這個數字比大多數模型世代升級帶來的提升還要大，直接證明了 HF 詞彙指南的核心論點：harness 工程是值得獨立投入的技術學科，不只是「把模型包起來」的膠水代碼。

arXiv 的終端機原生編碼 Agent 論文（2603.05344）進一步具體化了 harness 設計的工程要素。上下文管理被定為首要瓶頸：論文提出雙記憶架構，將對話記憶（episodic）和當前推理記憶（working）分離，以限制 token 增長；並引入「事件驅動系統提醒」機制來對抗長 session 中指令遺忘的問題——這對應到 HF 詞彙指南的 Context Engineering，但更具體地指出了 scaffold 失效的時機與對策。

Harness 的安全設計方面，論文提出五層獨立防禦（prompt 護欄 → schema 限制 → 運行時審批 → 工具驗證 → 生命週期鉤子），強調每一層獨立應對一類風險，避免單點失效。這呼應了 Sub-agent 設計的隔離原則：上層 Orchestrator 不需了解 sub-agent 的內部實作，就像每一層 harness 防禦不依賴前一層一樣。

綜合兩個來源的共識：Scaffold 寫的是「規格」，Harness 決定的是「能力上限」。選擇哪個模型是第二位的問題；如何設計圍繞模型的執行層，才是現階段 AI Agent 工程的核心競爭力。

反向連結

以下頁面引用了本頁：