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