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