負責推理與語言能力
LLM 判斷下一步、產生文字、選擇工具，但它本身不保證長任務穩定，也不天然知道什麼時候該停止。
01｜核心觀念
Harness 不是 提示詞，而是 代理 的「作業系統」
裸 LLM 像一顆聰明 CPU，但缺少記憶體管理、設備驅動、權限邊界、錯誤恢復與驗證機制。
負責工程化與控制
包含上下文管理、工具註冊、狀態保存、錯誤處理、護欄、安全權限、觀測與驗證。
可追蹤、可恢復、可驗證
企業要的不是一次 示範 成功，而是多次執行後仍能保持一致、可除錯、可審核、可回復。
02｜全貌流程
Agent Harness 執行循環
一個穩定 代理 通常不是「問模型一次就結束」，而是 Observe → Think → Act → Verify → Recover 的閉環。
03｜十二大模組
把 代理 拆成工程可控的零件
以下整理成工程師教學版本：每個模組都對應一個真實問題，不只是名詞。
1
初始化 初始化
載入設定、模型、工具、權限、專案規則，避免每次啟動狀態不一致。
2
執行循環 執行協調
控制 代理 如何觀察、思考、行動、回收結果，避免無限迴圈。
3
上下文管理 上下文
決定哪些資訊要進模型，哪些要摘要、屏蔽或延後載入。
4
工具註冊 工具註冊
把 API、檔案、資料庫、瀏覽器操作包成清楚 schema，讓模型安全呼叫。
5
記憶 記憶
區分短期任務記憶、長期知識、使用者偏好與可重用工作流程。
6
計畫 規劃
把大任務拆解成步驟，並在中途依觀察結果調整。
7
狀態與檢查點 狀態
保存進度，失敗後可從中間恢復，不必整個任務重跑。
8
錯誤處理 恢復
分辨暫時錯誤、邏輯錯誤、權限錯誤，採取重試、修正或人工介入。
9
安全護欄 安全護欄
限制輸入、輸出與工具權限，避免越權、洩密或破壞性操作。
10
驗證 評估
用規則、測試、比對、審核來確認結果，不讓 代理 自己說成功就算成功。
11
可觀測性 可觀測性
記錄每一步輸入、輸出、工具調用、錯誤與 代元 成本，方便除錯。
12
多 代理 協作 任務分派
把研究、撰寫、測試、審核拆給不同子 代理，並控制它們的邊界。
04｜七大架構抉擇
設計 Harness 時，一開始就要選邊站
這些不是理論題，而是會直接影響成本、維護性、安全性與成功率的設計決策。
1. 單 代理 還是多 代理？
任務簡單可用單 代理；跨領域、多審核、多流程，適合拆成多 代理。
2. 工具權限要開多大？
越方便越危險。企業場景建議採最小權限與可審核工具。
3. 上下文 要一次塞滿還是動態檢索？
一次塞滿容易上下文腐爛；動態檢索比較穩，但需要更好的索引與摘要策略。
4. 記憶要存在本地、雲端還是混合？
本地安全但協作較弱；雲端方便但要處理資安與資料邊界。
5. 驗證由規則、AI Judge 還是人審？
高風險流程不能只靠 AI Judge。規則測試與人審仍是最後保險。
6. 失敗要自動重試還是停下來？
暫時性錯誤可重試；資料破壞、權限不足、規格衝突應停下通知人。
7. 要自建還是用現成框架？
PoC 可用 LangGraph、CrewAI、AutoGen 等；高度客製與資安需求可能要自建核心層。
判斷原則
不要先追最炫框架，先列出你的風險：資料、權限、可驗證性、可恢復性。
05｜實際案例
把概念放到你的 PM Excel Agent
以下用「Excel 掃描 Critical Issues → 通知 / HTML / 電子郵件 報告」當例子，讓工程師更容易連到實務。
| Harness 模組 | 在 PM Agent 中的落地方式 | 沒有做會發生什麼事 |
|---|---|---|
| 初始化 | 啟動時檢查 .env、通知服務 代元、SMTP、資料夾路徑、output 目錄。 | 機器人看起來有執行，但按鈕沒有反應或寄信失敗。 |
| 工具註冊 | 把 Excel Scanner、HTML Report、Mail Sender、Notification Reply 分成清楚函式。 | 程式碼混在一起，修一個功能壞三個功能。 |
| 上下文管理 | 只抽取 Critical xxx open、紅藍字、分類關鍵字與 Project Name，不把整份 Excel 全塞進報告。 | 輸出過長、通知訊息爆字數、分類不準。 |
| 驗證 | 確認搜尋欄位、字色、分類、Project Name 對應正確，再產生 HTML。 | 代理 說成功，但結果其實漏掉或重複。 |
| 錯誤恢復 | 檔案讀不到、Excel 格式異常、SMTP 失敗時，回傳清楚錯誤與 備援 HTML。 | 只看到 SyntaxError 或卡住，不知道問題在哪。 |
| 可觀測性 | 記錄掃描了幾個檔案、幾張 sheet、命中幾筆、寄信 messageId。 | 無法判斷 代理 到底有沒有真的工作。 |
06｜30 分鐘工作坊
教學流程建議
適合 SIE / ME / RF / Thermal / PM 一起上課，用共同案例理解 代理 不是聊天機器人，而是工程系統。
0–5 分鐘｜破題問大家：為什麼 AI 示範 很漂亮，但真正放到流程裡常常失敗？
5–12 分鐘｜解釋 Harness用「CPU + 作業系統」比喻說明模型與 Harness 的分工。
12–20 分鐘｜十二模組導覽挑 上下文、Tool、記憶、驗證、恢復 五個最關鍵模組深入講。
20–27 分鐘｜套用 PM Agent請學員討論：我們的 Excel 代理 現在哪些模組最弱？
27–30 分鐘｜收斂每組提出一個可以下週開始改善的 Harness 設計。
生產級 代理 上線前檢查
07｜常見誤區
不要把所有問題都丟給模型
誤區一：模型變強，Harness 就不重要
模型越強，能做的事越多，反而更需要邊界、驗證與觀測。企業流程中，成功率、可追蹤性與安全性通常比單次回答漂亮更重要。
誤區二：提示詞 寫好就等於 代理 寫好
提示詞 只是 Harness 的一小部分。真正的 代理 還需要工具、狀態、錯誤處理、資料檢索、權限與測試。
誤區三：代理 自己檢查自己就夠了
高風險任務要讓 代理 對照原始規格、測試案例、資料庫結果或人工審核，而不是只讓它說「我覺得 OK」。
誤區四：把全部資料塞進 上下文 最安全
資料越多不一定越好。太多雜訊會讓模型忽略中間資訊，也會增加成本與錯誤率。
08｜小測驗
確認大家真的理解
點選答案後會立即顯示結果，可在課堂最後使用。
1. Harness 最接近哪一種角色？
2. 企業 代理 最不能缺少什麼？
3. 上下文 管理的目標是？
09｜帶回工作的重點
一句話總結
代理 的真正競爭力，不只在模型，而在模型外圍那套可控、可追蹤、可驗證的工程系統。
列印版備註：建議搭配實際專案流程圖與現有 代理 紀錄 做課堂討論。