核心概念

AI Agent 領域在過去兩年快速膨脹，帶來的副作用之一是術語混用：「Agent」、「Scaffolding」、「Harness」在不同文章裡可能指向完全不同的東西。Hugging Face 於 2026 年 5 月發表這篇詞彙表，試圖為最常被混淆的概念建立可操作的精確定義。

Model（模型）

模型是 LLM 本身——Claude、GPT、Qwen 等等。它接受文字輸入、產出文字輸出。單獨存在時，模型沒有跨呼叫的記憶，也沒有執行迴圈。 把模型誤認為 Agent，是許多系統設計失誤的起點。

Scaffolding（鷹架）

Scaffolding 是圍繞在模型外側、定義其行為的那一層，包含：

  • System prompt（指令模板）
  • Tool descriptions（工具描述與 schema）
  • Response parsing（輸出解析規則）
  • Context management（決定模型能看到什麼歷史）

Scaffolding 的本質是「告訴模型如何扮演它的角色」，它是靜態的定義層，在 Agent 真正執行之前就已建構完成。

Harness（執行框架）

Harness 是讓 Agent 實際運行的執行層，負責：

  • 呼叫模型
  • 執行工具呼叫（Tool Use）
  • 決定何時停止
  • 管理 Agent 的迴圈邏輯

Harness 是動態的執行層，在 runtime 驅動整個 Agent 的生命週期。一個重要的區分：Scaffolding 說「模型應該做什麼」，Harness 說「現在執行它」。

Agent（代理）

完整定義：Agent = Model + Harness（+ Scaffolding）

這個組合體能夠接收觀察（observation）、決定行動（action）、在迴圈中持續執行——把原本只輸出文字的語言模型，轉化為能在真實環境中採取行動的系統。缺少其中任何一層，就不是 Agent，只是被呼叫的 LLM。

Context Engineering（上下文工程）

Context Engineering 是設計「什麼資訊進入 Agent 的 context window」的工程學科，管轄範圍包含：

  • System prompt 的結構
  • Tool descriptions 的精簡程度
  • 對話歷史的保留策略
  • 從外部知識庫檢索（RAG）帶入的內容

它貫穿整個 Agent 執行過程，而非一次性設定。

Tool Use（工具使用）

Agent 透過 Tool Use 與外部系統互動——API、程式碼直譯器、資料庫、網頁搜尋等。其機制是：Agent 表達結構化的執行意圖（intent），由 Harness 實際呼叫並回傳結果。模型本身不直接操作工具，它只是「說」想用什麼工具。

Skills 與 Sub-agents

  • Skills：可重用的結構化能力包，把多步驟任務的知識打包，比單一工具更完整，但不具備自己的推理能力。
  • Sub-agents：被其他 Agent 呼叫來處理子任務的完整 Agent，擁有自己的模型、Scaffolding 與推理能力。

兩者的分界在於 Sub-agent 能自主推理，Skills 只是執行範本。

訓練專用術語

術語 定義
RL Environment 接受 action 輸入、回傳 observation 的有狀態物件
Trainer 執行 episodes、評分、更新模型權重的訓練驅動器
Rollout 一次完整的 Agent 執行（從開始到結束），亦稱 trajectory 或 trace
Reward 評估模型是否進步的分數（可驗證 / 學習型 / 稀疏 / 稠密）

關鍵要點

  • Model ≠ Agent：模型只是組件之一，缺乏 Harness 就無法自主行動
  • Scaffolding 是靜態定義，Harness 是動態執行：兩者常被混用，但職責完全不同；關於這個差異的詳細工程實踐見 Harness Engineering
  • Context Engineering 是一等公民：設計進入 context window 的資訊，是決定 Agent 品質的核心變數，不亞於模型本身的能力
  • Skills 不是 Sub-agents：Skills 無自主推理能力，Sub-agents 有自己完整的 Agent 堆疊
  • 術語不統一是現實：作者明確指出這份詞彙表的目標是建立「可操作的心智模型」，而非強制標準化——理解概念比對齊用詞更重要

實務應用

設計 Agent 系統時，可用這個框架做架構檢查：

  1. Model 選型：依任務複雜度選 LLM，不要把模型能力與系統能力混為一談
  2. Scaffolding 先行：清楚定義 system prompt、tool schema，再設計 Harness 的執行邏輯；參考 Thin Harness, Fat Skills — Garry Tan AI 效能架構 的精簡 Harness 原則
  3. Harness 邊界：Harness 負責執行，不應混入業務邏輯；業務邏輯應包裝成 Tool 或 Skill
  4. Context budget：把 context window 視為有限資源，主動管理而非填滿；詳細落地障礙見 Agentic AI 企業落地現實：基礎建設障礙與突破策略
  5. Sub-agent 判斷標準：子任務需要獨立推理 → Sub-agent；子任務是固定步驟 → Skill；避免過度分解

延伸觀點

結合 Hugging Face 另一篇《Dynamic Context Engineering for AI Agents》以及 arXiv 論文《Building AI Coding Agents for the Terminal》的交叉驗證，三個觀點在兩篇以上來源重複出現：

1. Harness / Scaffolding 的靜動分界已成共識

優先來源的 arXiv 論文明確指出：Scaffolding 在第一個 prompt 發出前組裝完成（system prompt、tool schema、subagent registry），Harness 在 runtime 負責 tool dispatch、context 管理、安全執法與跨輪次狀態持久化。這與 Hugging Face 詞彙表的定義高度一致，說明這個分界正在成為行業共識，而非單一視角。

2. Context Engineering 是架構問題，不是提示詞問題

《Dynamic Context Engineering》提出「五個認知層次」框架：記憶分層（短期/長期）、context window 管理（reactive vs. deliberative）、推理棧容量（非線性退化）、現實世界約束、符號知識表徵。核心論點是：context 管理需要不同的工程策略對應不同的認知層次，不能用一個靜態 system prompt 解決所有問題。這強化了「Context Engineering 是一等公民」的結論。

3. Agent Loop 的六相模型正在取代簡單 ReAct

arXiv 論文提出 extended ReAct 的六個階段：pre-check/compaction → thinking → self-critique → action → tool execution → post-processing，在傳統觀察-思考-行動之外，加入了預壓縮與自我批判兩個環節，以應對有限 context window 的現實限制。與 Hugging Face 詞彙表的 observation → action → execution 基本迴圈相比，這是一個更貼近生產環境的具體實作。

延伸資料：AI Agent 設計模式、多 Agent 系統協作架構：MCP 與 A2A 協議

反向連結

以下頁面引用了本頁：