1. 多 Agent 編排到底在解決什么問題1.1 從單 Agent 到多 Agent 的必然演進(jìn)先說結(jié)論單 Agent 能做的事天花板比大多數(shù)人想象的要低得多。我去年幫一個團(tuán)隊(duì)做智能客服系統(tǒng)一開始就是單個 Agent 包打天下——理解用戶意圖、查知識庫、調(diào)工單接口、生成回復(fù)全塞在一個提示詞里。前兩周跑得挺好到第三周就開始出問題工具調(diào)用越來越不穩(wěn)定上下文越來越長模型開始“忘記”自己該干什么。最典型的一個 bug 是用戶問“幫我查一下上個月的訂單”Agent 居然去調(diào)了退款接口。這不是模型不行而是單 Agent 的認(rèn)知負(fù)荷過載了。一個 Agent 同時承擔(dān)意圖識別、任務(wù)規(guī)劃、工具選擇、結(jié)果校驗(yàn)、回復(fù)生成五個角色就像讓一個人同時當(dāng)產(chǎn)品經(jīng)理、程序員、測試和運(yùn)維短期能扛長期必崩。多 Agent 編排的核心思路就是分而治之把一個大任務(wù)拆成若干子任務(wù)每個子任務(wù)交給專門的 Agent 處理Agent 之間通過明確的協(xié)議傳遞信息和狀態(tài)。這跟微服務(wù)架構(gòu)的思路是一脈相承的——單體應(yīng)用拆成微服務(wù)每個服務(wù)只干一件事通過 API 通信。1.2 編排和“堆 Agent”是兩回事很多人一聽多 Agent第一反應(yīng)是“那我多開幾個 Agent 不就行了”。我見過一個項(xiàng)目開發(fā)者開了 8 個 Agent結(jié)果比單 Agent 還慢還亂。問題出在沒有編排。編排Orchestration這個詞來自工作流領(lǐng)域核心含義是定義誰在什么時候做什么、做完之后交給誰。沒有編排的多 Agent 就是一群無頭蒼蠅各自為戰(zhàn)互相等待甚至死鎖。一個合格的多 Agent 編排系統(tǒng)至少要解決四個問題任務(wù)分解大任務(wù)怎么拆成子任務(wù)拆到什么粒度角色分配每個子任務(wù)交給哪個 AgentAgent 的能力邊界在哪狀態(tài)傳遞Agent 之間怎么傳數(shù)據(jù)傳什么格式傳多少流程控制串行還是并行失敗了怎么重試超時了怎么降級這四個問題不解決Agent 越多越亂。下面這張表是我總結(jié)的單 Agent 和多 Agent 的適用邊界你可以對照自己的場景判斷維度單 Agent 適用多 Agent 適用任務(wù)復(fù)雜度單一意圖3 步以內(nèi)多意圖5 步以上工具數(shù)量少于 5 個10 個以上上下文長度單輪對話為主多輪、跨會話錯誤容忍度低錯了重來高可局部重試開發(fā)成本低一個提示詞搞定高需要編排框架調(diào)試難度低日志集中高需要鏈路追蹤1.3 為什么現(xiàn)在談多 Agent 編排正當(dāng)時兩年前談多 Agent 編排大家會覺得是屠龍之術(shù)——模型能力不夠工具生態(tài)不成熟編排框架幾乎沒有?，F(xiàn)在情況完全變了。模型側(cè)主流大模型在函數(shù)調(diào)用、結(jié)構(gòu)化輸出、長上下文上的能力已經(jīng)足夠支撐復(fù)雜編排。工具側(cè)各種 Agent 框架和編排庫層出不窮LangGraph 就是其中比較有代表性的一個。工程側(cè)可觀測性工具、鏈路追蹤、狀態(tài)管理這些配套也慢慢跟上了。更重要的是業(yè)務(wù)場景開始真正需要多 Agent。比如自動化代碼審查需要理解代碼、檢查規(guī)范、生成建議、驗(yàn)證建議四個環(huán)節(jié)每個環(huán)節(jié)的提示詞和工具集都不一樣硬塞進(jìn)一個 Agent 效果很差。再比如深度研究助手需要搜索、閱讀、總結(jié)、交叉驗(yàn)證、生成報告這本身就是一條流水線。所以現(xiàn)在學(xué)多 Agent 編排不是趕時髦而是場景倒逼。你遲早會遇到單 Agent 搞不定的任務(wù)到時候再學(xué)就晚了。2. 編排框架選型LangGraph 憑什么值得學(xué)2.1 主流編排方案的橫向?qū)Ρ仍趧邮种跋雀闱宄忻嫔嫌心男┚幣欧桨父髯赃m合什么場景。我把常見的幾類列出來方案類型代表核心思路適合場景坑點(diǎn)鏈?zhǔn)骄幣臠angChain LCEL線性管道A 的輸出給 B簡單流水線分支和循環(huán)支持弱圖編排LangGraph狀態(tài)圖節(jié)點(diǎn)邊復(fù)雜流程、循環(huán)、條件分支學(xué)習(xí)曲線陡角色編排AutoGen多 Agent 對話協(xié)作討論、辯論容易發(fā)散成本高事件編排自研事件總線發(fā)布訂閱大規(guī)模異步調(diào)試?yán)щy硬編碼純 Pythonif-else 調(diào)度流程固定的小項(xiàng)目擴(kuò)展性差我個人的建議是流程簡單用 LCEL流程復(fù)雜用 LangGraph需要多 Agent 討論用 AutoGen規(guī)模再大就自研。對于大多數(shù)想入門多 Agent 編排的開發(fā)者LangGraph 是最佳起點(diǎn)因?yàn)樗选皥D”這個抽象做得足夠通用既能表達(dá)簡單流水線也能表達(dá)復(fù)雜的狀態(tài)機(jī)。2.2 LangGraph 的核心抽象狀態(tài)、節(jié)點(diǎn)、邊LangGraph 的心智模型非常簡單就三個概念State狀態(tài)一個共享的數(shù)據(jù)結(jié)構(gòu)所有節(jié)點(diǎn)都能讀寫。通常是個字典或 TypedDict。Node節(jié)點(diǎn)一個函數(shù)接收 State返回 State 的更新。每個節(jié)點(diǎn)就是一個 Agent 或一個處理步驟。Edge邊定義節(jié)點(diǎn)之間的流轉(zhuǎn)關(guān)系?？梢允枪潭ǖ腁 之后必走 B也可以是條件的根據(jù) State 決定走 B 還是 C。這三樣?xùn)|西組合起來就能表達(dá)任意復(fù)雜的流程。我畫個簡單的類比State 是共享內(nèi)存Node 是函數(shù)Edge 是調(diào)用關(guān)系。如果你寫過狀態(tài)機(jī)或者工作流引擎這個概念一秒鐘就懂了。LangGraph 相比 LCEL 最大的優(yōu)勢是支持循環(huán)。LCEL 是 DAG有向無環(huán)圖不能回頭。但很多 Agent 場景需要循環(huán)比如“生成代碼 → 測試 → 失敗 → 重新生成”這就是一個環(huán)。LangGraph 天然支持這種結(jié)構(gòu)。2.3 環(huán)境準(zhǔn)備Python 安裝與依賴管理動手之前先把環(huán)境搞干凈。我見過太多人因?yàn)榄h(huán)境問題卡在第一步這里給一套我常用的流程。Python 版本建議 3.10 以上因?yàn)?LangGraph 用了一些新語法特性。安裝 Python 本身不復(fù)雜官網(wǎng)下載安裝包一路下一步就行Windows 記得勾選“Add Python to PATH”。裝完之后驗(yàn)證python --version pip --version依賴管理我強(qiáng)烈建議用虛擬環(huán)境不要往全局環(huán)境里裝。用 venv 就行python -m venv venv # Windows venv\Scripts\activate # macOS/Linux source venv/bin/activate激活之后裝依賴pip install langgraph langchain-openai langchain-core如果你需要用到 numpy 做數(shù)據(jù)處理或者 cv2 做圖像處理也一并裝上pip install numpy opencv-python注意opencv-python 在某些 Linux 環(huán)境下需要額外的系統(tǒng)依賴裝不上先看報錯信息通常是缺 libGL。Ubuntu 下apt install libgl1就能解決。2.4 一個最小可運(yùn)行示例光說不練假把式。下面是一個最小的 LangGraph 示例兩個節(jié)點(diǎn)串行執(zhí)行from typing import TypedDict from langgraph.graph import StateGraph, END class State(TypedDict): input: str step1_result: str step2_result: str def node_a(state: State) - State: return {step1_result: f處理了: {state[input]}} def node_b(state: State) - State: return {step2_result: f二次處理: {state[step1_result]}} graph StateGraph(State) graph.add_node(a, node_a) graph.add_node(b, node_b) graph.set_entry_point(a) graph.add_edge(a, b) graph.add_edge(b, END) app graph.compile() result app.invoke({input: hello}) print(result)跑通這個示例你就理解了 LangGraph 的基本套路定義 State、寫節(jié)點(diǎn)函數(shù)、連邊、編譯、調(diào)用。后面所有的復(fù)雜編排都是在這個骨架上加?xùn)|西。3. 多 Agent 編排的核心設(shè)計模式3.1 主管模式一個大腦指揮多個手腳這是最常用也最容易理解的模式。一個 Supervisor Agent 負(fù)責(zé)理解任務(wù)、分解任務(wù)、分派給 Worker AgentWorker 干完活把結(jié)果交回來Supervisor 決定下一步。這個模式的好處是控制流清晰所有決策集中在一個地方調(diào)試的時候只需要看 Supervisor 的日志。壞處是 Supervisor 容易成為瓶頸任務(wù)一多就忙不過來。適用場景任務(wù)分解邏輯明確、Worker 職責(zé)單一的場合。比如一個內(nèi)容生產(chǎn)流水線Supervisor 負(fù)責(zé)拆解“寫一篇技術(shù)文章”這個任務(wù)分給“資料搜集 Agent”“大綱 Agent”“正文 Agent”“校對 Agent”。實(shí)現(xiàn)上Supervisor 通常是一個帶函數(shù)調(diào)用能力的 LLM 節(jié)點(diǎn)它根據(jù)當(dāng)前 State 決定下一個該誰干。LangGraph 里用條件邊來實(shí)現(xiàn)def supervisor(state: State) - str: # 根據(jù) state 判斷下一步 if not state.get(research_done): return researcher elif not state.get(draft_done): return writer else: return reviewer graph.add_conditional_edges(supervisor, supervisor, { researcher: researcher, writer: writer, reviewer: reviewer, })3.2 流水線模式各司其職順序推進(jìn)流水線模式把任務(wù)拆成固定順序的幾個階段每個階段一個 Agent前一個的輸出是后一個的輸入。這是最接近傳統(tǒng)工作流的模式也最容易理解和實(shí)現(xiàn)。好處是可預(yù)測性強(qiáng)每個階段的輸入輸出格式固定測試起來方便。壞處是靈活性差中間某個階段出問題整個流程就卡住了。適用場景流程固定、階段邊界清晰的任務(wù)。比如文檔處理流水線解析 → 分塊 → 嵌入 → 檢索 → 生成。再比如代碼審查流水線拉取代碼 → 靜態(tài)檢查 → 邏輯審查 → 生成報告。流水線模式在 LangGraph 里就是簡單的 add_edge 串聯(lián)不需要條件邊。但要注意錯誤處理每個節(jié)點(diǎn)都要考慮失敗的情況不能讓異常直接冒泡把整個圖搞崩。3.3 辯論模式多個 Agent 互相挑戰(zhàn)這個模式比較有意思。多個 Agent 針對同一個問題給出各自的答案然后互相評論、挑戰(zhàn)、修正最后收斂到一個共識。適合需要多角度思考的場景比如方案評審、風(fēng)險評估。實(shí)現(xiàn)上通常是兩個或三個 Agent 輪流發(fā)言用一個“裁判”Agent 判斷是否達(dá)成共識。LangGraph 里用循環(huán)邊實(shí)現(xiàn)def should_continue(state: State) - str: if state[round] 3 or state[consensus]: return end return debate graph.add_conditional_edges(judge, should_continue, { debate: debater_a, end: END, })這個模式最大的坑是成本。每輪辯論都要調(diào)用多次 LLM輪數(shù)一多 token 消耗驚人。我的經(jīng)驗(yàn)是設(shè)置硬性輪數(shù)上限同時給裁判 Agent 一個明確的“達(dá)成共識”判斷標(biāo)準(zhǔn)避免無限循環(huán)。3.4 層級模式大團(tuán)隊(duì)套小團(tuán)隊(duì)當(dāng)任務(wù)規(guī)模大到一定程度扁平的結(jié)構(gòu)就不夠用了。層級模式把 Agent 組織成樹狀頂層 Supervisor 管幾個中層 Supervisor每個中層 Supervisor 管一組 Worker。這個模式適合超大規(guī)模任務(wù)比如“分析一家公司的財報”可以拆成“財務(wù)數(shù)據(jù)提取”“行業(yè)對比”“風(fēng)險分析”三個子團(tuán)隊(duì)每個子團(tuán)隊(duì)內(nèi)部再細(xì)分。代價是復(fù)雜度爆炸。層級越深狀態(tài)傳遞越麻煩調(diào)試越困難。我的建議是層級不要超過三層超過三層說明你的任務(wù)拆分有問題應(yīng)該考慮拆成多個獨(dú)立的圖。4. 狀態(tài)管理與 Agent 間通信的實(shí)操細(xì)節(jié)4.1 State 設(shè)計共享什么隔離什么State 設(shè)計是多 Agent 編排里最容易翻車的地方。設(shè)計得好Agent 之間配合流暢設(shè)計得差要么信息不夠用要么狀態(tài)污染。我的經(jīng)驗(yàn)法則是共享必要信息隔離中間過程。具體來說所有 Agent 都需要的全局信息放 State比如用戶原始輸入、任務(wù)目標(biāo)、全局配置單個 Agent 的中間產(chǎn)物不要直接塞進(jìn) State而是存到外部文件、數(shù)據(jù)庫State 里只放引用State 的字段要少而精超過 10 個字段就要考慮拆分了LangGraph 的 State 支持 reducer可以定義字段的合并策略。比如多個 Agent 同時往一個列表里追加內(nèi)容from typing import Annotated from operator import add class State(TypedDict): messages: Annotated[list, add] current_task: str這里的Annotated[list, add]表示這個字段的更新方式是追加而不是覆蓋。這個細(xì)節(jié)很關(guān)鍵不設(shè)置的話后一個 Agent 會把前一個的結(jié)果覆蓋掉。4.2 消息傳遞結(jié)構(gòu)化還是自然語言Agent 之間傳消息有兩種風(fēng)格結(jié)構(gòu)化JSON、字典和自然語言純文本。兩種我都用過各有優(yōu)劣。結(jié)構(gòu)化消息的好處是解析穩(wěn)定下游 Agent 不用猜格式。壞處是表達(dá)能力受限復(fù)雜信息塞不進(jìn)固定 schema。自然語言消息的好處是靈活壞處是下游解析容易出錯。我的實(shí)踐是混合使用控制信息用結(jié)構(gòu)化內(nèi)容信息用自然語言。比如{ task_id: t001, status: success, content: 這是 Agent A 生成的正文內(nèi)容可能很長..., metadata: {tokens: 1234, duration: 2.3} }這樣下游 Agent 既能穩(wěn)定拿到狀態(tài)又能靈活處理內(nèi)容。4.3 記憶管理短期、長期、共享Agent 的記憶分三層短期記憶當(dāng)前任務(wù)內(nèi)的上下文存在 State 里任務(wù)結(jié)束就丟長期記憶跨任務(wù)的知識存在向量數(shù)據(jù)庫或文件里共享記憶多個 Agent 都能訪問的公共區(qū)域比如一個共享的草稿文檔短期記憶最簡單State 里放就行。長期記憶需要接向量庫LangGraph 支持 checkpointer 機(jī)制可以把 State 持久化到 SQLite 或 Postgres。共享記憶比較麻煩需要處理并發(fā)讀寫我的做法是用一個專門的“記憶 Agent”來管理其他 Agent 通過它讀寫。注意長期記憶不是越多越好。我見過一個項(xiàng)目把所有歷史對話都塞進(jìn)向量庫結(jié)果檢索出來的全是噪音。記憶要有選擇地存只存那些對未來任務(wù)有價值的結(jié)論性信息。4.4 并發(fā)控制什么時候該并行多 Agent 不一定非要串行。有些任務(wù)可以并行比如“同時搜索三個不同的數(shù)據(jù)源”并行能大幅縮短總耗時。LangGraph 支持并行節(jié)點(diǎn)只要多個節(jié)點(diǎn)從同一個節(jié)點(diǎn)出發(fā)且沒有相互依賴就會自動并行執(zhí)行。但并行有幾個坑狀態(tài)沖突多個節(jié)點(diǎn)同時寫同一個 State 字段結(jié)果不確定。解決方法是給字段加 reducer或者讓并行節(jié)點(diǎn)寫不同的字段。資源競爭并行調(diào)用 LLM 會瞬間打滿 API 配額需要加限流。錯誤傳播一個并行分支失敗其他分支怎么辦要么全部回滾要么部分成功。這個要在設(shè)計階段就想清楚。我的建議是默認(rèn)串行確認(rèn)無依賴再并行。并行帶來的復(fù)雜度提升往往超過它節(jié)省的時間。5. 常見問題排查與避坑實(shí)錄5.1 Agent 陷入死循環(huán)怎么辦這是多 Agent 編排最常見的問題。兩個 Agent 互相等待或者一個 Agent 反復(fù)調(diào)用同一個工具流程永遠(yuǎn)走不到 END。排查思路分三步看日志確認(rèn)是哪個節(jié)點(diǎn)在重復(fù)執(zhí)行重復(fù)的觸發(fā)條件是什么查條件邊條件函數(shù)的判斷邏輯是不是有漏洞比如某個狀態(tài)永遠(yuǎn)為 False加護(hù)欄給循環(huán)加最大輪數(shù)限制超過就強(qiáng)制跳出LangGraph 里可以給 State 加一個計數(shù)器class State(TypedDict): loop_count: int def should_continue(state: State) - str: if state[loop_count] 10: return end return continue提示護(hù)欄不是萬能的它只是防止流程卡死真正的問題還是要從條件邏輯上解決。我踩過的坑是條件函數(shù)里用了!而不是導(dǎo)致判斷永遠(yuǎn)為真。5.2 狀態(tài)污染導(dǎo)致下游 Agent 行為異常狀態(tài)污染的表現(xiàn)是某個 Agent 突然開始做不屬于它職責(zé)的事或者輸出格式完全不對。原因通常是上游 Agent 往 State 里寫了不該寫的東西。比如上游 Agent 把“思考過程”也寫進(jìn)了 State下游 Agent 看到一堆無關(guān)內(nèi)容就被帶偏了。解決方法是嚴(yán)格定義每個字段的寫入者在代碼層面做約束。我的做法是給 State 字段加注釋標(biāo)明誰寫誰讀class State(TypedDict): # 寫入: supervisor, 讀取: all task_goal: str # 寫入: researcher, 讀取: writer research_result: str # 寫入: writer, 讀取: reviewer draft: str這樣團(tuán)隊(duì)協(xié)作的時候誰該寫哪個字段一目了然。5.3 Token 消耗失控的排查與優(yōu)化多 Agent 系統(tǒng)的 token 消耗通常是單 Agent 的 3 到 10 倍因?yàn)槊總€ Agent 都要帶上下文還要互相傳消息。失控的典型表現(xiàn)是賬單突然暴漲。優(yōu)化手段有幾個精簡 State只傳必要信息大文本存外部壓縮歷史老消息做摘要不要原樣傳遞緩存結(jié)果相同輸入直接返回緩存不重復(fù)調(diào)用選對模型簡單任務(wù)用小模型復(fù)雜任務(wù)才用大模型我做過一個對比測試同樣的任務(wù)優(yōu)化前消耗 12 萬 token優(yōu)化后降到 3 萬效果基本沒差別。關(guān)鍵就是別把整個對話歷史無腦傳給每個 Agent。5.4 常見問題速查表現(xiàn)象可能原因排查方向解決手段流程卡住不動條件邊判斷錯誤打印 State 看條件值修正條件邏輯加護(hù)欄Agent 輸出格式錯亂狀態(tài)污染檢查上游寫入約束字段寫入者Token 消耗暴漲上下文過長統(tǒng)計每次調(diào)用 token精簡 State壓縮歷史并行節(jié)點(diǎn)結(jié)果不一致狀態(tài)競爭檢查并發(fā)寫入加 reducer 或分離字段工具調(diào)用失敗率高參數(shù)格式不對看工具調(diào)用日志加參數(shù)校驗(yàn)用結(jié)構(gòu)化輸出整體響應(yīng)慢串行節(jié)點(diǎn)太多分析各節(jié)點(diǎn)耗時無依賴節(jié)點(diǎn)改并行5.5 調(diào)試技巧鏈路追蹤怎么做多 Agent 系統(tǒng)的調(diào)試比單 Agent 難得多因?yàn)橐淮握埱髸?jīng)過多個節(jié)點(diǎn)每個節(jié)點(diǎn)都可能出問題。沒有鏈路追蹤你根本不知道是哪一步出的錯。我的做法是給每個節(jié)點(diǎn)加統(tǒng)一的日志裝飾器記錄輸入、輸出、耗時、token 消耗import time import functools def trace_node(func): functools.wraps(func) def wrapper(state): start time.time() print(f[{func.__name__}] 輸入: {state}) result func(state) print(f[{func.__name__}] 輸出: {result}, 耗時: {time.time()-start:.2f}s) return result return wrapper生產(chǎn)環(huán)境建議接 LangSmith 或者自建追蹤系統(tǒng)把每次調(diào)用的鏈路可視化。這個投入是值得的能省下大量排查時間。6. 從 Demo 到生產(chǎn)多 Agent 系統(tǒng)的工程化6.1 安全邊界Agent 能做什么不能做什么Agent 一旦接入真實(shí)工具就有了實(shí)際操作能力。這時候安全邊界必須劃清楚。我見過一個 Agent 因?yàn)樘崾驹~注入把數(shù)據(jù)庫里的數(shù)據(jù)全刪了教訓(xùn)慘痛。幾條硬性規(guī)則工具白名單只給 Agent 開放必要的工具不要圖省事全開參數(shù)校驗(yàn)所有工具調(diào)用的參數(shù)都要校驗(yàn)不能直接透傳權(quán)限隔離不同 Agent 用不同的憑證最小權(quán)限原則操作審計所有工具調(diào)用都記日志可追溯注意提示詞注入是多 Agent 系統(tǒng)的高危風(fēng)險。用戶輸入的內(nèi)容如果直接進(jìn)了 Agent 的提示詞就可能被利用。防御方法是把用戶輸入和系統(tǒng)提示詞嚴(yán)格隔離用結(jié)構(gòu)化格式傳遞。6.2 性能優(yōu)化讓多 Agent 跑得更快多 Agent 系統(tǒng)的性能瓶頸通常在兩個地方LLM 調(diào)用和狀態(tài)傳遞。LLM 調(diào)用優(yōu)化能并行的并行能緩存的緩存能用小模型的不用大模型。我做過統(tǒng)計一個典型的多 Agent 流程里60% 的 LLM 調(diào)用是可以用小模型替代的成本能降一半以上。狀態(tài)傳遞優(yōu)化State 不要太大大對象存外部。LangGraph 的 checkpointer 會序列化整個 StateState 越大序列化越慢。我見過一個項(xiàng)目 State 里塞了幾十 MB 的文本每次節(jié)點(diǎn)切換都要序列化一遍慢得離譜。6.3 可觀測性生產(chǎn)環(huán)境必須有的監(jiān)控Demo 跑通和生產(chǎn)可用之間差的就是可觀測性。生產(chǎn)環(huán)境至少要監(jiān)控這幾個指標(biāo)成功率每次請求是否成功完成耗時分布P50、P95、P99 各是多少Token 消耗按任務(wù)、按 Agent 統(tǒng)計工具調(diào)用成功率哪個工具最容易失敗異常分布哪類錯誤最多這些指標(biāo)接上告警出問題第一時間知道。我吃過虧一個 Agent 靜默失敗了一周才發(fā)現(xiàn)用戶投訴了一堆。6.4 版本管理與灰度發(fā)布Agent 系統(tǒng)的提示詞、工具、編排邏輯都會變每次變更都可能影響效果。所以版本管理很重要。我的做法是提示詞單獨(dú)存文件用 git 管理編排邏輯用配置文件描述不改代碼就能調(diào)整新版本先灰度 10% 流量觀察指標(biāo)再全量這樣出問題能快速回滾不至于全量翻車。7. 一個完整的實(shí)戰(zhàn)案例技術(shù)文章生成流水線7.1 需求拆解與 Agent 劃分說了這么多理論來個完整的實(shí)戰(zhàn)案例。需求是輸入一個技術(shù)主題自動生成一篇 3000 字的技術(shù)文章。拆解一下這個任務(wù)可以分成四個階段資料搜集搜索相關(guān)資料提取關(guān)鍵信息大綱生成根據(jù)資料生成文章大綱正文撰寫按大綱逐節(jié)寫正文校對潤色檢查邏輯、修正錯誤、潤色語言對應(yīng)四個 AgentResearcher、Outliner、Writer、Reviewer。用流水線模式串聯(lián)Reviewer 發(fā)現(xiàn)問題可以打回 Writer 重寫形成一個帶循環(huán)的流水線。7.2 核心代碼骨架from typing import TypedDict, Annotated from operator import add from langgraph.graph import StateGraph, END class ArticleState(TypedDict): topic: str research: str outline: str draft: str review_feedback: str revision_count: int def researcher(state: ArticleState) - ArticleState: # 調(diào)用搜索工具整理資料 return {research: ...} def outliner(state: ArticleState) - ArticleState: # 根據(jù)資料生成大綱 return {outline: ...} def writer(state: ArticleState) - ArticleState: # 根據(jù)大綱寫正文如果有反饋則修訂 return {draft: ..., revision_count: state.get(revision_count, 0) 1} def reviewer(state: ArticleState) - ArticleState: # 審查正文給出反饋 return {review_feedback: ...} def should_revise(state: ArticleState) - str: if state[revision_count] 3: return end if 通過 in state[review_feedback]: return end return revise graph StateGraph(ArticleState) graph.add_node(researcher, researcher) graph.add_node(outliner, outliner) graph.add_node(writer, writer) graph.add_node(reviewer, reviewer) graph.set_entry_point(researcher) graph.add_edge(researcher, outliner) graph.add_edge(outliner, writer) graph.add_edge(writer, reviewer) graph.add_conditional_edges(reviewer, should_revise, { revise: writer, end: END, }) app graph.compile()這個骨架跑通之后每個節(jié)點(diǎn)的具體實(shí)現(xiàn)可以逐步替換成真實(shí)的 LLM 調(diào)用和工具調(diào)用。7.3 關(guān)鍵節(jié)點(diǎn)的提示詞設(shè)計多 Agent 系統(tǒng)里每個 Agent 的提示詞就是它的“崗位說明書”。寫得好Agent 各司其職寫得差A(yù)gent 越界亂來。Researcher 的提示詞要點(diǎn)明確搜索范圍、要求提取事實(shí)而非觀點(diǎn)、輸出結(jié)構(gòu)化。Outliner 的提示詞要點(diǎn)給定資料和主題輸出三級大綱每節(jié)標(biāo)注預(yù)計字?jǐn)?shù)。Writer 的提示詞要點(diǎn)嚴(yán)格按大綱寫不要自由發(fā)揮如果有修訂反饋要針對性修改。Reviewer 的提示詞要點(diǎn)從邏輯、事實(shí)、語言三個維度審查給出具體修改建議明確說“通過”或“不通過”。提示Reviewer 的提示詞里一定要有明確的通過標(biāo)準(zhǔn)否則它會一直挑毛病導(dǎo)致無限修訂。我的做法是列出三條硬性標(biāo)準(zhǔn)滿足即通過。7.4 效果評估與迭代系統(tǒng)跑起來之后怎么判斷好不好我通常從三個維度評估完成率多少比例的請求能正常走完全流程質(zhì)量分人工抽檢給生成的文章打分成本平均每篇文章消耗多少 token、多少時間第一版跑下來完成率大概 70%主要卡在 Reviewer 太嚴(yán)格。調(diào)整提示詞后升到 90%。質(zhì)量分從 3.2 升到 4.15 分制。成本方面平均每篇 8 萬 token還有優(yōu)化空間。迭代的方向很明確優(yōu)化 Reviewer 的判斷邏輯給 Writer 加緩存避免重復(fù)生成把 Researcher 的搜索并行化。8. 多 Agent 編排的學(xué)習(xí)路線與進(jìn)階方向8.1 從入門到熟練的三階段如果你剛開始學(xué)多 Agent 編排我建議按這個路線走第一階段跑通 Demo。把 LangGraph 官方示例跑一遍理解 State、Node、Edge 三個概念。這個階段不要追求復(fù)雜能跑通就行。第二階段復(fù)現(xiàn)經(jīng)典模式。把主管模式、流水線模式、辯論模式各實(shí)現(xiàn)一遍理解每種模式的適用場景和坑點(diǎn)。這個階段要多寫代碼光看沒用。第三階段做真實(shí)項(xiàng)目。找一個自己工作或生活里的真實(shí)需求用多 Agent 編排實(shí)現(xiàn)。真實(shí)項(xiàng)目的復(fù)雜度會讓你真正理解前面學(xué)的所有東西。8.2 值得深入的方向跑通基礎(chǔ)之后有幾個方向值得深入Agent 記憶怎么設(shè)計長期記憶怎么檢索怎么遺忘Agent 安全提示詞注入防御、權(quán)限控制、操作審計多模態(tài)編排Agent 處理圖像、音頻、視頻成本優(yōu)化模型路由、緩存策略、批處理可觀測性鏈路追蹤、指標(biāo)監(jiān)控、異常告警每個方向都夠研究很久。我的建議是先深挖一個方向再橫向擴(kuò)展不要什么都淺嘗輒止。8.3 一些個人體會最后分享幾點(diǎn)我在實(shí)際項(xiàng)目里的體會。第一不要為了多 Agent 而多 Agent。能用單 Agent 解決的別上多 Agent。多 Agent 帶來的復(fù)雜度是實(shí)打?qū)嵉氖找娌幻黠@就別上。第二編排邏輯比 Agent 本身更重要。我見過太多項(xiàng)目把精力花在調(diào)提示詞上結(jié)果編排邏輯一塌糊涂。提示詞是術(shù)編排是道。第三可觀測性要一開始就做。別等到出問題才想起來加日志那時候已經(jīng)晚了。鏈路追蹤、指標(biāo)監(jiān)控這些東西越早接入越好。第四成本意識要貫穿始終。多 Agent 系統(tǒng)的 token 消耗很容易失控每次設(shè)計都要問自己這一步真的需要調(diào)用 LLM 嗎能不能用規(guī)則替代能不能緩存第五保持簡單。我踩過的最大的坑就是過度設(shè)計。一開始就想著支持各種復(fù)雜場景結(jié)果代碼寫了一堆實(shí)際用到的沒幾個。先做最簡單的版本跑通了再逐步加功能。多 Agent 編排這個領(lǐng)域還在快速演進(jìn)今天的 best practice 明天可能就過時了。但底層的思路——分而治之、狀態(tài)管理、流程控制——這些是不變的。把這些搞扎實(shí)工具怎么變都不慌。