寫這篇文章時配圖連續出了兩次錯。第一張 Harness 信息圖把「執行控制」畫了兩遍。第二張 Graph State 圖四個主標簽都對卻擅自補了一段看起來專業、實際不嚴謹的小字。有意思的是兩次調用都返回成功。文件存在尺寸正確畫面也挺漂亮。只看 API 狀態任務已經結束真的把圖打開才知道事情還沒做完。我后來重寫提示詞、保留正確版本再生成、再檢查。折騰完這兩輪我突然發現最近社區里那句「我們還在做 Loops還是已經該轉向 Graphs 了」其實問錯了。圖片模型、參考圖、文件系統和權限決定 Agent 有沒有條件完成任務這是 Harness。發現重復標簽把證據退回去再生成一版這是 Loop。研究、寫作、事實核查、配圖、驗收、同步到 Obsidian 的先后關系則是一條執行 Graph。它們從來不是三選一。最近 Graph Engineering 這個詞開始變熱看上去像是 Agent 工程的下一代范式。但我把 OpenAI、Anthropic、LangGraph 和 AutoGen 的官方資料重新翻了一遍判斷反而越來越明確Graph 沒有取代 LoopLoop 也沒有取代 Harness。它們分別處理工作條件、反饋閉環和執行關系。環境、反饋、流程。先記住這六個字后面的新名詞就不容易把人帶跑。這里說的 Graph特指組織 Agent、工具、代碼和人工節點的執行圖不是知識圖譜。Graph Engineering 目前也更像社區對一類實踐的概括還沒有被行業共同接受的標準定義。三個概念先用 30 秒分開裸模型的一次推理可以生成文本、結構化輸出甚至提出工具調用意圖。但它不會替應用真正執行工具也不會天然擁有項目文件、打開瀏覽器、保存跨會話進度。測試失敗后應該重試、回滾還是停下來找人同樣要由模型外部的運行時決定。Agent 能真正做事靠的是模型外面的系統。問題就在這里。模型外面的東西很多大家又喜歡統一叫「Agent 編排」于是工具、權限、反饋、狀態機、多 Agent 協作全被塞進同一個詞里。我更愿意把它們拆成三種工程抓手。工程切面它回答的問題典型組成Harness EngineeringAgent 在什么工作條件里運行工具、文件系統、上下文、記憶、權限、沙箱、日志、模型路由Loop Engineering一輪做完以后怎么辦觀察、證據、反饋、重試、預算、停止條件、人工復核Graph Engineering當前步驟結束后下一步誰能運行節點、邊、分支、并行、匯合、狀態遷移、檢查點、受控回環這張表是一個排障口訣不是一堵物理隔離墻。不同團隊對 Harness 的邊界會畫得不一樣。LangChain 甚至直接用「Agent Model Harness」來定義 Agent把模型之外的代碼、配置和執行邏輯都放進 Harness。按這個寬口徑Loop runtime 和 Graph scheduler 也可以算 Harness 的一部分。所以這三個詞不是三個互斥的盒子。更像三個觀察系統的角度。Harness先給模型一個能工作的世界2026 年 2 月OpenAI 發了一篇很有代表性的文章標題就叫《Harness engineering: leveraging Codex in an agent-first world》。文章里有一句話很準確當工程團隊不再把主要精力放在親手寫每一行代碼而是讓 Agent 執行時人類的工作會轉向設計環境、表達意圖并建立讓 Agent 可靠工作的反饋回路。注意這里的重點。不是再寫一個更長的 Prompt。而是把 Agent 周圍的世界搭好。OpenAI 那個團隊把短小的AGENTS.md當作地圖把倉庫里的結構化文檔當作事實源再用自定義 lint、結構測試和 CI 約束架構方向。Agent 能看到什么、能修改什么、如何判斷自己有沒有破壞系統都被做成了倉庫里可讀取、可執行、可驗證的東西。Anthropic 在長任務 Harness 的實踐里也遇到了類似問題。僅靠上下文壓縮并不能讓 Agent 跨越多個會話穩定推進。他們增加了初始化 Agent、進度文件、功能清單、測試和干凈的工作狀態讓下一輪執行知道前一輪做過什么、還有什么沒有完成。這些東西看起來不神秘。文件、腳本、權限、測試、日志。但它們組合起來決定了模型是在一個秩序清楚的工程現場工作還是被扔進一間堆滿雜物的倉庫里自己找扳手。一個比較完整的 Harness通常會覆蓋六類能力。上下文入口。系統指令、項目地圖、檢索結果、任務狀態、Skills 和歷史決策。行動入口。API、Shell、瀏覽器、數據庫、代碼解釋器、MCP 工具和外部服務。持久化。文件、會話、檢查點、Git 歷史、進度記錄和長期記憶。執行控制。超時、預算、模型路由、并發、審批門和重試上限。安全邊界。沙箱、白名單、密鑰隔離、只讀模式和人工授權。可觀測性。工具輸入輸出、狀態變化、Trace、延遲、成本和評測結果。有一個很好用的判斷方法。把架構圖里的模型暫時拿掉。剩下的工作區、工具、狀態、規則、沙箱、評測器和 UI大多都屬于 Harness。這里還要補一個邊界。Harness 不只是擺在模型周圍的一張靜態資源清單它通常還包含驅動一次 Run 的主動運行時。誰把工具結果追加回上下文誰處理 handoff誰控制并發和最大輪次誰在審批點暫停再從保存的狀態恢復這些都不是模型自己完成的。Session、RunState、Checkpoint 和 Trace 也不能統一塞進「記憶」Session 主要保存會話歷史RunState 記錄一次被暫停的運行Checkpoint 保存圖執行進度Trace 負責觀察調用鏈。記得聊天、能從斷點繼續、外部動作不會重復、結果真的正確是四件不同的事。這也解釋了為什么同一個基礎模型放進兩套 Agent 產品里表現會差很多。差距未必來自模型智力更可能來自工具契約是否清楚、狀態是否可靠、權限是否克制以及失敗信息能不能回到下一輪。Harness 解決的是「它有沒有條件把事情做好」。但 Harness 也不是越厚越好。Anthropic 在 2026 年的長任務實驗里專門復盤了這個問題每一個 Planner、Evaluator、進度文件和上下文重置機制都隱含著一個假設——模型自己還做不好這件事。模型能力提升以后有些原本必要的腳手架會變成額外成本甚至干擾模型工作。所以 Harness Engineering 還包含一項經常被忽略的工作定期刪除已經失去價值的腳手架。一個組件該不該保留可以問三個問題? 拿掉以后哪一類可觀測指標會明顯變差? 它是在彌補穩定缺陷還是只是在安撫我們的不安全感? 新模型上線后這個假設是否還成立真正成熟的 Harness不是組件最多而是每個組件都能解釋自己在防什么故障。Loop重點不是多跑幾輪是把結果送回系統只要一個 Agent 會調用工具它內部就已經有一個小循環。模型決定下一步。工具執行。結果返回上下文。模型再決定下一步。Anthropic 對 Agent 的描述也是這個方向模型自主決定如何使用工具和推進過程在計劃、行動、觀察、調整之間反復直到任務完成或者需要人類介入。但工程里常說的 Loop往往還多了一層。我會把它分成兩種。第一種是Agent 內部的執行 Loop。它解決的是「下一步做什么」。讀文件、搜索、調用工具、更新計劃都發生在這里。第二種是系統外層的驗證 Loop。它解決的是「這一輪結果夠不夠好」。測試有沒有通過鏈接能不能訪問JSON 是否符合 Schema引用能不能回到原文風險操作有沒有得到批準。這兩層經常被混在一起于是 Loop Engineering 容易被誤解成寫一個while true讓 Agent 一直干。真這樣做得到的通常不是自治。是空轉。一個能上線的 Loop至少要寫清楚這些事情? 什么事件觸發下一輪? 當前目標狀態是什么? 哪些狀態必須帶到下一輪? 允許調用哪些工具、修改哪些資源? 用什么證據證明成功? 失敗信息如何壓縮成下一輪可以執行的反饋? 什么時候因為成功而退出什么時候因為預算、超時或不可恢復錯誤而退出。這里最重要的不是循環次數。是證據。「Agent 覺得已經完成」不是停止條件。「測試通過、Schema 校驗成功、引用可訪問、審核人批準」才是。這也是 Loop Engineering 和 Prompt Engineering 真正拉開距離的地方。Prompt 主要影響一次模型調用怎么做Loop 負責調用結束后系統如何觀察結果、生成反饋、保存進度并決定要不要繼續。不過 Loop 也不是越多越好。每增加一次評估、一次復核、一次重試都會增加延遲和成本。只有失敗代價高于驗證代價時這個閉環才值得加。Loop 解決的是「它做完以后系統怎么知道對不對」。一個完整的 Loop至少要有三種出口很多 Loop 設計只寫了成功條件卻沒有認真設計失敗。這很危險。OpenAI Agents SDK 的 Runner 就展示了一個最小但完整的執行邊界模型返回最終輸出循環結束模型發起 handoff切換當前 Agent 后繼續模型調用工具執行工具并把結果放回上下文如果超過max_turns則拋出明確的超限錯誤。生產系統在這個基礎上還應該把出口分成三類。成功退出。驗收證據滿足要求例如測試全部通過、引用存在且與原文一致、數據滿足 Schema、人工批準已經寫入狀態。受控失敗。達到最大輪次、預算或超時或者連續出現同一類錯誤。系統停止繼續消耗資源保存現場并返回機器可讀的失敗原因。人工升級。遇到高風險副作用、需求沖突或判斷置信不足時不是假裝完成也不是無限重試而是暫停運行把當前狀態、已嘗試方案和待決問題交給人。這里還有一個容易被忽略的細節失敗反饋必須可行動。「結果不夠好」幾乎沒有價值。好的反饋應該像這樣第 4 條引用鏈接可訪問但原文沒有支持“性能提升 3 倍”這個數字請刪除該數字或補充一手來源。它指出失敗對象、失敗證據和允許的修復方向。下一輪不需要重新猜測評分器到底不滿意什么。如果驗證器本身也是另一個大模型也不要把它當成客觀真理。Anthropic 在 Generator–Evaluator 實驗里發現讓獨立 Evaluator 更挑剔通常比讓生成者自我批評更容易但評估器仍然需要校準而且依舊會漏掉深層問題。確定性檢查、獨立模型復核和人工審批應該按風險組合使用。Graph它管的不是更聰明而是下一步誰能運行Graph Engineering 問的是另一個問題。當前步驟結束以后誰可以拿到狀態誰可以繼續執行在一張執行圖里節點可以是一次模型調用、一個專業 Agent、一段確定性函數、一個工具調用也可以是人工審批。邊負責規定順序、條件分支、并行展開、結果匯合、回退和退出。LangGraph 的官方文檔把一張圖拆成三個核心對象。State當前系統狀態。Nodes讀取狀態并產生更新的執行單元。Edges根據狀態決定下一個節點。微軟 AutoGen 的 GraphFlow 也是類似思路。它用有向圖控制 Agent 之間的執行支持順序、并行、條件分支和帶安全退出條件的循環。官方給出的使用邊界很克制只有當任務需要嚴格控制順序、根據不同結果走不同路徑或者包含復雜的多步驟循環時才值得使用 GraphFlow。普通對話式協作夠用時先用更簡單的 Team。截至本文寫作時AutoGen 文檔仍把 GraphFlow 標為實驗性能力API 和行為可能繼續變化。用它理解設計邊界沒問題拿去做長期生產依賴則需要額外評估版本風險。這里有兩個很容易踩的坑。一個是把 Graph 等同于多 Agent。不是。一張圖完全可以只有一個 Agent其余節點都是代碼、測試和人工審批。反過來一個 Agent 也可以在自己的 Loop 里動態創建多個子 Agent并不一定要提前畫成固定圖。另一個是把 Graph 等同于確定性。也不準確。顯式的邊可以讓控制流更可預測但只要節點里還有模型節點輸出就仍然帶有概率性。Graph 真正買到的是把一部分「接下來怎么辦」從長對話里的隱式判斷搬到了可觀察、可檢查、可限制的結構里。這已經很值錢了。尤其是長任務。LangGraph 的檢查點會在執行步驟之間保存圖狀態由此支持人在回路、狀態恢復、歷史回放和故障續跑。同一個 super-step 里如果并行節點有的成功、有的失敗已經成功的 pending writes 還能被保留下來恢復時不必把成功節點全部重跑。這些能力不是畫幾條箭頭自動得到的。你仍然要設計狀態結構、冪等性、合并規則、失敗語義和退出條件。圖不難畫。難的是讓圖真的能跑。Graph 解決的是「事情復雜以后執行關系怎么保持清楚」。Graph 真正難的不是箭頭而是 State一張流程圖可以在白板上五分鐘畫完。一張可以斷點恢復、并行執行、不會重復扣款或重復發消息的執行圖難度完全不同。至少要把下面四件事說清楚。第一狀態的 Schema 是什么。不要讓所有節點共享一坨無限增長的聊天記錄。研究節點需要的是問題、候選信源和證據寫作節點需要的是已核驗事實與結構審批節點只需要變更摘要、風險等級和待批準動作。狀態越清楚節點的權限和上下文越容易收緊。第二并行結果怎樣合并。LangGraph 用 reducer 定義同一個狀態字段的多個更新如何組合。這個細節在并行分支里尤其重要同一 super-step 的更新順序可能不穩定。如果業務要求固定順序就不能依賴“誰先返回”而要讓分支輸出攜帶排序鍵在匯合節點顯式排序。第三恢復以后會不會重復產生副作用。檢查點能讓任務繼續但“能恢復”不等于“恢復一定安全”。一個已經開始、尚未記錄完成的任務可能在恢復時再次執行。發送郵件、創建訂單、扣款、發布文章這類動作必須使用冪等鍵或者先查詢目標系統是否已經存在對應結果。第四失敗的事務邊界在哪里。某個并行分支失敗是整批回滾還是保留成功結果只重試失敗分支LangGraph 的 super-step 有自己的事務與檢查點語義但你的外部數據庫、第三方 API 并不會自動加入這筆事務。圖運行時的狀態一致不代表現實世界的副作用也一致。所以 Graph Engineering 的核心產物不應該只有一張圖。還應該包括狀態 Schema、節點讀寫契約、reducer、檢查點策略、冪等規則、重試預算和人工升級路徑。還有一對經常混淆的圖。執行拓撲決定哪個節點能運行上下文拓撲決定每個節點能看到什么消息。兩者不是一回事。一張 Graph 可以把 Reviewer 放在 Writer 之后但如果 Reviewer 仍然收到 Writer 的全部思考過程、舊結論和自我評價它就可能繼續沿著同一條路徑走。要獲得更獨立的復核還需要單獨做消息過濾、最小狀態投影或干凈上下文。反過來上下文隔離也不自動帶來正確性。Reviewer 依舊可能誤判因此最終還要回到測試、Schema、原始引用和人工審批這些證據。Graph 沒有殺死 Loop它只是把關系畫了出來Loops 還是 Graphs這個二選一從一開始就不成立。在圖論里Loop 本來就可以表現為一條回環邊審查不通過Reviewer 回到 Writer測試失敗Test 回到 Implement。反過來一個 Agent Loop 也可以把「執行一張子圖」當作自己的某一步。子圖跑完再把結果交回主循環繼續判斷。開頭那兩張錯誤配圖就是一個很小的嵌套案例。瀏覽器、官方資料、Obsidian、圖片模型、文件權限和日志組成 Harness研究、寫作、事實核查、配圖、驗收、同步構成執行路徑而配圖節點內部又跑著「生成 → 打開檢查 → 給出具體錯誤 → 重做」的 Loop。第一次 Harness 圖出現重復標簽時問題不在 Graph。執行順序沒亂是圖片驗證沒有通過。第二次 State 圖出現錯誤小字時也沒必要把整篇文章從頭再跑只要回到配圖節點局部修正。這正是 Graph 的價值它不消滅 Loop而是讓系統知道哪一段需要回退。同樣的變化也會發生在代碼 Agent 上。最初只有修改、測試、讀取報錯、再修改一個 Loop 足夠。等任務加入截圖檢查、數據庫遷移和安全掃描開始出現穩定的并行、匯合、審批與回退路徑再把這些關系固化成 Graph。順序別反了。不是先畫十個節點再逼工作適應圖而是先觀察 Loop 怎樣運行再把已經穩定的關系畫出來。審批門也應該放在付款、刪除、發布這些動作之前因為最終的 Output guardrail 撤銷不了已經發生的副作用。出了什么故障就改哪一層我覺得這三個詞最有價值的地方不是讓架構圖看起來更高級。是拿來排障。你看到的故障優先檢查哪一層典型修法Agent 拿不到數據、不會用工具、跨會話丟狀態Harness修工具契約、上下文入口、持久化和權限第一版經常差一點失敗后不會修完成標準模糊Loop增加可執行反饋、證據、預算和退出條件多角色的先后順序、分支、并行和匯合越來越難追蹤Graph顯式建模節點、邊、狀態和檢查點圖畫得很漂亮但每個節點都在重復猜Harness 節點設計給節點更好的工具、上下文和確定性檢查Agent 反復重試同一種錯誤Loop改善失敗分類設置上限和人工升級路徑并行節點互相覆蓋結果恢復后重復產生副作用Graph Harness設計 reducer、冪等鍵、事務邊界和權限隔離這張表還有一個隱藏用法。它能阻止團隊過早買框架。如果 Agent 連正確的文件都找不到上 Graph 沒用。如果完成標準還是一句「看起來不錯」多加三個 Reviewer 也沒用。如果任務只有一條穩定路徑單 Agent 加一個可靠驗證 Loop 已經能做好強行拆成十個節點只會增加延遲和調試成本。先找到故障屬于哪一類再決定改哪一層。Graph 最大的誘惑是把復雜當成能力Graph Engineering 火起來以后最容易發生的事就是大家開始數節點。五個 Agent 好像比一個 Agent 高級。二十個節點好像比五個節點專業。一張鋪滿屏幕的圖看上去也確實比一個簡單 Loop 更像「系統」。但節點數量從來不是可靠性的代理指標。Anthropic 的多 Agent Research 系統在它自己的內部研究評測里相比單 Agent 方案提升了 90.2%。這是一個很亮眼的結果。但同一篇文章也給出了成本普通 Agent 大約使用聊天模式 4 倍的 token多 Agent 系統大約是聊天模式的 15 倍。這組數據只能說明一件事。對于可以廣度并行、價值足夠高、單個上下文裝不下的研究任務多 Agent 可能值得。它不能推出「多 Agent 普遍比單 Agent 好」更不能推出「Graph 天然比 Loop 正確」。Anthropic 自己也強調復雜系統會用延遲和成本換取更好的任務表現。簡單調用能解決的不要急著上 Agent清楚的 Agent Loop 能解決的也不要急著畫大圖。說真的我現在看到一張 Agent Graph最先看的不是有多少節點。我看四件事。狀態在哪里。證據從哪里來。失敗退回哪里。副作用由誰批準。這四個問題答不出來圖越大事故半徑可能越大。一個更穩妥的建設順序如果從零搭 Agent我會先做一件不那么「酷」的事讓工作現場可觀察。先修 Harness。給 Agent 清楚的項目地圖、少而明確的工具、受限權限、可恢復狀態和完整日志讓失敗能夠被定位。然后挑一個失敗代價高、又容易驗證的環節做 Loop代碼任務跑測試數據任務校驗 Schema研究任務檢查引用外部操作等待人工批準。只有當穩定的分支、并行、匯合與回退反復出現才把它們固化成 Graph。圖應該是已觀察工作的地圖不是未來組織結構的想象。因為圖會固化你對系統的理解。理解錯了它只會讓錯誤跑得更穩定。寫在最后回到開頭那兩張錯誤配圖。API 返回成功不代表圖是對的文件已經存在也不代表任務完成。沒有 Harness模型甚至拿不到參考圖和正確文件沒有 Loop重復標簽和錯誤小字會直接進入文章沒有 Graph返工時就很難判斷應該只重跑配圖節點還是把整條流程推倒重來。Agent 工程并不是不斷發明新名詞。軟件工程幾十年來都在處理環境、反饋和控制流只是現在執行者里多了一個會推理、會調用工具、也會犯錯的概率模型。先看你的 Agent 為什么失敗。缺工具、狀態、權限和可觀測性修 Harness。缺證據、重試和停止條件修 Loop。缺分支、并行、匯合和恢復路徑再上 Graph。Harness 管工作條件。Loop 管反饋閉環。Graph 管執行拓撲。它們不是三代技術而是三個問題。把問題分對工程才真正開始。學AI大模型的正確順序千萬不要搞錯了2026年AI風口已來各行各業的AI滲透肉眼可見超多公司要么轉型做AI相關產品要么高薪挖AI技術人才機遇直接擺在眼前有往AI方向發展或者本身有后端編程基礎的朋友直接沖AI大模型應用開發轉崗超合適就算暫時不打算轉崗了解大模型、RAG、Prompt、Agent這些熱門概念能上手做簡單項目也絕對是求職加分王給大家整理了超全最新的AI大模型應用開發學習清單和資料手把手幫你快速入門學習路線:?大模型基礎認知—大模型核心原理、發展歷程、主流模型GPT、文心一言等特點解析?核心技術模塊—RAG檢索增強生成、Prompt工程實戰、Agent智能體開發邏輯?開發基礎能力—Python進階、API接口調用、大模型開發框架LangChain等實操?應用場景開發—智能問答系統、企業知識庫、AIGC內容生成工具、行業定制化大模型應用?項目落地流程—需求拆解、技術選型、模型調優、測試上線、運維迭代?面試求職沖刺—崗位JD解析、簡歷AI項目包裝、高頻面試題匯總、模擬面經以上6大模塊看似清晰好上手實則每個部分都有扎實的核心內容需要吃透我把大模型的學習全流程已經整理好了抓住AI時代風口輕松解鎖職業新可能希望大家都能把握機遇實現薪資/職業躍遷這份完整版的大模型 AI 學習資料已經上傳CSDN朋友們如果需要可以微信掃描下方CSDN官方認證二維碼免費領取【保證100%免費】