DMBot onepage/ Agent systems
Lunar / X Article · 2026-07-28
Agent Harness、Loop 與 Graph Engineering：三個常被混在一起的層次
這篇文章的價值在於把 agent 系統拆回三個可討論的設計問題：模型在什麼環境裡運行、工作如何靠回饋反覆改善、以及多步流程如何分支、匯流與受控。
Published: 2026-07-28Author: LunarSource: X Article
01 / Environment
Harness 管的是操作條件
把工具、上下文、記憶、權限、持久化與可觀測性放到模型周圍，讓一次回答變成可運行的工作系統。
02 / Feedback
Loop 管的是改進節奏
定義嘗試、觀察、驗證、重試與停止條件。它不保證正確，而是讓失敗有回路可循、有證據可檢查。
03 / Topology
Graph 管的是流程結構
明確描述哪些步驟能平行、哪些必須依賴、何處要人工核准，以及出錯後從哪裡恢復。
Mental model
先分清「環境 → 回饋 → 流程」
Harness
能運作
工具與資料是否乾淨？狀態能否保留？權限是否最小化？這些屬於環境設計。
Loop
能改善
成功證據是什麼？失敗後回傳什麼？能試幾次、何時停下？這些屬於回饋設計。
Graph
能受控
哪些路徑要固定？哪些可平行？共享什麼狀態？人工關卡在哪？這些屬於拓撲設計。
Three layers
每一層的工作，不能拿另一層代替
H
Harness：替模型準備可工作的場域
嚴謹的 harness 會管理輸入上下文與工具表面，也會處理檔案、checkpoint、session 狀態、預算、隔離、審批與 trace。相同模型在不同 harness 裡，可靠性可以相差極大。
L
Loop：把一次嘗試變成有界的學習迴圈
核心不是無限重跑，而是把成功標準、回饋訊號、重試上限、升級規則與停止條件寫清楚。這讓失敗可被定位，成本與延遲也能被約束。
G
Graph：把隱藏的工作流決策攤開來
當任務出現分支、平行工作、依賴、合併與人工門檻，圖狀表示能讓流程成為可檢視的設計，而不是散落在 prompt 或程式分支中的偶然行為。
Failure diagnosis
先修擁有故障的那一層
Agent 看不到正確資料或工具先檢查 harness：context 是否噪音太多、工具 schema 是否含糊、權限或持久狀態是否缺失；不要只換更大的模型。
Agent 一直重試卻沒有變好先檢查 loop：是否真的回傳了可操作的驗證結果？是否有 retry limit、預算與明確 exit rule？
多人／多 agent 任務變得難以預測先檢查 graph：依賴、共享狀態、平行區段與人工核准是否顯式化，是否能從失敗節點恢復。
「多塞工具」反而更不穩工具越多會提高選擇錯誤、上下文雜訊與風險面。好的 harness 追求精準的能力表面，不是工具抽屜。
Practical checklist
把文章轉成設計審查問題
Harness：能暫停、檢查、恢復嗎？確認工具有邊界、狀態能保存、權限最小化，並能看到 inputs、outputs、trace、成本與延遲。
Loop：有沒有可被驗證的完成定義？指定成功證據與失敗回饋，設好重試次數、升級與停止規則，避免把「再試一次」當成流程。
Graph：哪些路徑必須確定、哪些可平行？將依賴、核准點、共享狀態與 recovery path 畫出來；複雜度上升時，這比增加 prompt 規則更可控。
評估：改善能回放與歸因嗎？用真實 trace 比對版本，確認變好來自哪一項改動，而不是一次剛好成功的示範。
Reading path
如何把 toy agent 推向 production
先穩定 operating conditions讓 agent 有需要的上下文與窄而清楚的行動能力，並把持久化、權限、觀測補齊。
再設計可驗證的工作迴圈以驗證訊號驅動下一次嘗試，設定成本、時間與重試界限，避免執行失控。
最後讓複雜流程顯式化需求出現多專家、分支與人工介入時，用 graph 表示路徑與責任邊界，讓系統可以檢視與治理。
References