跳到主要內容
NTPU AI Learn

AI 302 · 模組 1

什麼是 Agent Harness？

Agent 已經會 Reason、Plan、Use Tools，為什麼還需要 Harness？

開始第一節
  • 時長50 分鐘
  • 難度架構
  • 先備知識建議先完成 AI 202（Agentic AI Planning & Reasoning）；建議完成 AI 301（Multi-Agent Collaboration & Orchestration）
已完成 0 / 5
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

加入後，你已完成的模組編號會連同「學員代碼」傳送給講師，講師可以看到你的進度。請使用講師提供的代碼，不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 說明什麼是 Agent Harness，以及它與 Agent logic 的差異
  • 描述 Harness 是位於 Trigger、Agent 與 Tools 之間的 Runtime 控制層
  • 區分 Agent reasoning、Workflow logic、Harness control、Tool responsibility 與 Human control
  • 說出 Harness 所執行的 Tool、Verification、Human 與 Failure boundary
  • 說明沒有 Harness 時可能出現的問題：執行不透明、State 遺失、動作重複、失敗連鎖擴散、Context 失控與無法 Resume
  • 為整門課選定一個真實、可用模擬資料描述的系統

問題與需求

8 分鐘

Demo 成功了，然後它連續跑了一週

在 AI 202 與 AI 301 中，你設計了會規劃、推理並能團隊合作的 Agent。這樣的設計在 Demo 中可能看起來很出色。本課程接著問：當工作要跑很長時間、需要保存 State、會呼叫可能失敗的 Tool，而且結果必須讓人信任時，會發生什麼事？核心問題是：Agent 已經會 Reason、Plan、Use Tools，為什麼還需要 Harness？

工作情境（模擬）

一個 Agent 在夜間處理進來的採購申請：讀取每一筆申請、對照預算規則檢查、起草核可說明並寄出通知。第二晚，網路錯誤在它寄出 40 封通知後中斷了執行。有人重新啟動，它從第一筆申請重新開始，於是 40 個人收到了第二封通知。早上沒有人能說出哪些申請已完成、哪些被跳過，也不知道為什麼有一筆申請被核可了兩次。這個 Agent 每一步的推理都不差，問題出在步驟之外的一切。

  • 沒有人看得見這次 Run 做了什麼、停在哪裡
  • 執行進度沒有被保存，所以重新啟動就從頭開始
  • 重跑同一次 Run 會重複只該發生一次的動作
  • 沒有人定義過什麼時候該問人，或什麼時候該讓 Run 停下來

注意

更好的 Prompt 或更強的模型無法解決這些問題。它們不是 Agent 想了什麼的問題，而是執行如何被控制的問題。這個負責控制的結構，就是本課程的主題。

重點: 有能力的 Agent 不等於可靠的系統。可靠性來自執行如何被控制，而不只是 Agent 推理得多好。

核心概念

10 分鐘

Agent logic 與 Agent Harness

每次 Agent 系統執行，都在回答兩個不同的問題。Agent logic 回答：接下來我該做什麼？Agent Harness 回答：我們如何安全地執行、追蹤、暫停、驗證、Resume、復原並控制接下來發生的事？Harness 是包在 Agent 外面的 Runtime 控制層。

Harness layer：從 Trigger 到 Tools
  1. Trigger：使用者請求、排程、事件或收到的文件啟動一次 Run
  2. Agent Harness：保存 State、執行 Control Loop、儲存 Checkpoint、套用 Verification 與 Human 控制、處理 Retry 與 Recovery，並記錄發生的事
  3. Agent / Model：在 Harness 設下的限制內決定下一步做什麼
  4. Tools / Data / Environment：Agent 所作用的外部系統，只能透過 Harness 接觸

文字版說明：這張圖是由上到下的垂直堆疊。Trigger 啟動一次 Run。Run 進入 Agent Harness，Harness 內含七個部分：State、Control Loop、Checkpoints、Verification、Human-in-the-Loop、Retry 與 Recovery，以及 Observability。Harness 接著呼叫 Agent 或 Model，Agent 再作用於 Tools、Data 與 Environment。控制與結果會沿同一條路徑經過 Harness 回傳，因此沒有任何東西不經過 Harness 就到達外部世界，也沒有任何東西不經過 Harness 就從外部返回。

比較 Agent logic 與 Agent Harness（模擬的採購申請範例）
Agent logicAgent Harness
主要問題接下來我該做什麼？我們如何安全地執行、追蹤、暫停、驗證、Resume 與復原？
關注的是推理、規劃與選擇行動State、控制、限制、證據與人的參與
範例判斷這筆申請在核可前需要做預算檢查記錄這筆申請正處於預算檢查步驟，連續失敗三次後停止，金額超過上限時詢問人
如果薄弱Agent 做出不好的選擇好的選擇仍然會被遺失、重複、隱藏，或缺少監督

資訊

Harness 不是 Agent 的替代品，也不是某個特定產品。它是一個設計層，無論你自己建置或使用框架，本課程的概念都適用。
自我檢測

哪一個敘述最能說明 Agent logic 與 Agent Harness 的差異？

哪一個敘述最能說明 Agent logic 與 Agent Harness 的差異？

重點: Agent logic 問接下來做什麼。Harness 控制執行如何被進行、追蹤與復原，它位於 Trigger、Agent 與 Tools 之間。

12 分鐘

誰控制什麼：五種責任

檢視一個真實系統時，每一項行為都屬於五種責任之一。能夠分類它們是第一項 Harness 技能，因為把控制放在錯誤的層次，不是無效，就是只靠運氣有效。

五種責任（模擬的採購申請範例）
種類它是什麼範例
Agent reasoning模型在判斷、解讀或生成判斷一筆申請描述的是軟體訂閱，而不是硬體採購
Workflow logic為任務設計的步驟順序先檢查預算，再起草說明，最後通知
Harness control關於執行本身的 Runtime 規則每處理完一筆就保存進度；連續失敗三次後停止；不重複寄出同一則通知
Tool responsibility外部系統會做或會拒絕做的事預算系統拒絕一筆成本中心不存在的申請
Human control由人決定、核可或推翻主管核可任何超過約定金額的申請

屬於 Agent

  • 解讀申請內容
  • 在 Workflow 內選擇下一個行動
  • 撰寫草稿文字

屬於 Harness

  • 知道這次 Run 正處於哪一個步驟
  • 決定要 Retry、停止或詢問人
  • 記錄發生的事，讓它可以 Resume 與被檢視
  • Workflow logic 說明步驟是什麼；Harness control 說明這些步驟的執行如何被管理
  • Tool 可以執行自己的規則，但 Tool 拒絕或失敗時會發生什麼，仍須由 Harness 處理
  • Human control 是刻意的設計元素，不是自動化放棄後剩下的東西
  • 如果一條規則即使模型出錯也必須成立，它應該放在 Harness 或 Tool，而不能只放在 Prompt

資訊

有些行為可以在兩個層次都有防護。重要的是你能說出由哪一層負責，以及那一層失效時會發生什麼。
自我檢測

團隊在 Agent 的 Prompt 中寫了：「絕對不要寄出相同的通知兩次。」哪一種設計最可靠？

團隊在 Agent 的 Prompt 中寫了：「絕對不要寄出相同的通知兩次。」哪一種設計最可靠？

重點: 把行為分類為 Agent reasoning、Workflow logic、Harness control、Tool responsibility 或 Human control。必須恆常成立的規則要放在 Harness 或 Tool，不能只放在 Prompt。

為什麼需要 Harness 與其邊界

10 分鐘

為什麼需要 Harness：沒有它會壞掉什麼

Harness 之所以重要，是因為它缺席時會發生的事。請比較同一次模擬的夜間 Run，有無 Harness 的差別。

沒有 Harness

  • 執行不透明：沒有人知道發生了什麼、停在哪裡
  • State 可能遺失，所以一次中斷就得重來
  • Retry 可能重複只該發生一次的動作
  • 一個步驟的失敗可能連鎖影響下一步
  • Context 可能失控地增長
  • 人不知道何時該介入
  • 長時間的任務無法 Resume

有 Harness

  • 每個步驟與結果都被記錄，可以被檢視
  • 進度被保存，Run 可以從已知的點繼續
  • Retry 依照 Policy 進行，並避免重複不可逆的動作
  • 失敗被限制範圍，並導向 Recovery 或人
  • Working context 維持在預算之內
  • 在定義好的點請人審閱或核可
  • Run 可以暫停、Resume 或安全地停止
Harness 所執行的四種邊界（模擬範例）
邊界它回答的問題範例
Tool boundary這次 Run 可以使用哪些 Tool 與動作？Agent 可以讀取預算表，但不能修改它
Verification boundary結果被接受之前必須檢查什麼？起草的說明在寄出前必須寫明成本中心與金額
Human boundary什麼時候必須由人審閱、核可或接手？任何超過約定金額的申請都要等主管
Failure boundary出錯時會發生什麼，以及能擴散多遠？連續失敗三次後 Run 停止並回報，不會碰到後面的申請

資訊

實作範例（不是唯一的模型）：像 LangGraph 這類有 State 的框架，可以把 Harness 表達成一張圖。在那裡，Harness 的 State 是 Graph state，每個步驟是 Node，決定下一步的控制是 Edge。這只是其中一種建置方式。無論使用哪種工具，本課程的概念都成立，後續模組會再加入更多明確標示為範例的實作範例。

Human-AI-Human：由人定義任務、限制與會被詢問的點，Agent 在這些限制內工作，由人審閱結果並對結果負責。

自我檢測

一次 Run 在中途被中斷，系統從頭重新啟動，重複了已經生效的動作。最明顯缺少的是哪一項 Harness 能力？

一次 Run 在中途被中斷，系統從頭重新啟動，重複了已經生效的動作。最明顯缺少的是哪一項 Harness 能力？

重點: 沒有 Harness，執行不透明、State 遺失、動作重複。Harness 執行 Tool、Verification、Human 與 Failure boundary，而人仍然負責。

實作與應用

10 分鐘

實作：Agent Logic 還是 Harness？

活動 1 提供 8 個模擬的設計決定。針對每一個，選擇其一：Agent reasoning、Workflow logic、Harness control、Tool responsibility 或 Human control，並說明理由。有些案例可以合理地有兩種解讀；重點是你能說明自己的推理。請不要在這個練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。

8 個設計決定（請自行判斷）
案例設計決定思考重點
1判斷一封來信是客訴還是提問誰或什麼在解讀語意？
2在起草核可說明之前，一律先做預算檢查這是設計好的順序，還是 Runtime 控制？
3每處理完一筆申請就保存目前步驟，讓重新啟動不必從頭開始什麼必須撐過一次中斷？
4拒絕成本中心不存在的採購申請這條規則由哪個系統負責？
5主管核可任何超過約定金額的申請誰握有決定權？
6同一個步驟連續失敗三次後停止 Run誰來限制 Run 本身？
7選擇友善或正式的語氣來回覆這是推理還是控制？
8記錄每一次 Tool call 與其結果，讓 Run 事後可以被檢視什麼讓 Run 事後仍可被理解？
  • Agent reasoning：模型在解讀、判斷或生成
  • Workflow logic：設計好的步驟順序與內容
  • Harness control：關於 State、限制、檢查、Recovery 與記錄的 Runtime 規則
  • Tool responsibility：外部系統所做或所執行的事
  • Human control：由人決定、核可或推翻
  1. 應用：為整門課選一個真實系統
    挑選一個可能長時間執行、需要保存 State、會呼叫可能失敗的 Tool，或需要審閱的 Agent 系統或 Agentic workflow。之後每個模組都用它來練習，它最終會放進你的 Agent Harness & Reliability Canvas。
  2. 用模擬資料描述它
    只寫系統的用途與運作方式，不要出現真實姓名、客戶個人資料或公司機密。如果涉及敏感內容，請改用模擬版本。
  3. 寫下 Goal 與第一個 Harness 問題
    用一句話寫出 Goal，再回答：如果這個系統的一次 Run 在中途被中斷，我們最需要知道、控制或復原什麼？
自我檢測

你需要為整門課選一個系統。哪一個最適合？

你需要為整門課選一個系統。哪一個最適合？

重點: Human-AI-Human：由人定義任務與控制方式，Agent 在其中工作，由人審閱結果並對結果負責。

另存 PDF

接下來做什麼？