很多 Agent 項(xiàng)目跑不好不是模型不夠強(qiáng)而是流程沒有邊界。SOP 寫在文檔里模型執(zhí)行的時(shí)候經(jīng)常漏步驟、跳判斷、把不該并行的事并行掉把 SOP 畫成一張有向圖之后每一步是什么、下一步由誰決定、異常走哪條邊全部落成數(shù)據(jù)結(jié)構(gòu)。Agent 不再靠“臨場發(fā)揮”決定順序而是在圖上按規(guī)則前進(jìn)這就是 Graph Engineering 的核心思路。這篇文章不聊概念空轉(zhuǎn)直接拆解一套可以落地的做法把現(xiàn)有 SOP 拆成節(jié)點(diǎn)和條件邊用代碼構(gòu)建可執(zhí)行圖跑通之后封裝成 API 服務(wù)再接入批量任務(wù)。如果已經(jīng)在用 LangGraph、自研編排引擎或者準(zhǔn)備改造一個(gè)多步驟 Agent這篇文章可以直接收藏。1. Graph Engineering 是什么先解決流程失控問題Graph Engineering 用圖數(shù)據(jù)結(jié)構(gòu)來編排 Agent 的執(zhí)行流程。圖里常見的幾個(gè)要素是Node一個(gè)具體工作步驟比如“識(shí)別意圖”“檢索知識(shí)庫”“調(diào)用訂單接口”“生成回復(fù)”。Edge節(jié)點(diǎn)之間的連接關(guān)系表達(dá)“上一步完成后進(jìn)入下一步”。State所有節(jié)點(diǎn)共享的狀態(tài)對象保存用戶輸入、中間結(jié)果、最終輸出。Conditional Edge條件路由由規(guī)則或 LLM 判斷后選擇走哪條邊。Loop循環(huán)邊用來實(shí)現(xiàn)多輪修正、重試、繼續(xù)追問。Checkpoint檢查點(diǎn)把執(zhí)行到一半的狀態(tài)落盤異常后可以從斷點(diǎn)恢復(fù)。之所以說“把 SOP 畫成 Graph它就能自己跑”是因?yàn)閳D結(jié)構(gòu)把流程控制權(quán)從模型手里收回來了。模型只負(fù)責(zé)節(jié)點(diǎn)內(nèi)部的計(jì)算比如文本分類、內(nèi)容生成、信息抽取下一步去哪個(gè)節(jié)點(diǎn)由預(yù)先定義好的邊和條件路由決定。這樣既保留了 LLM 的語義判斷能力又不至于讓它把關(guān)鍵步驟帶偏。核心能力速覽能力項(xiàng)說明流程表達(dá)用節(jié)點(diǎn)和邊表達(dá)多步驟 SOP支持順序、分支、循環(huán)、并行狀態(tài)管理節(jié)點(diǎn)之間通過全局 State 共享數(shù)據(jù)避免口頭傳參條件路由支持規(guī)則路由和 LLM 路由模型判斷后進(jìn)入不同分支可觀測性每個(gè)節(jié)點(diǎn)執(zhí)行前、執(zhí)行后都能打日志定位問題到具體步驟可恢復(fù)性結(jié)合 Checkpoint 可在失敗后恢復(fù)不用整條流程重跑接口化編譯后的圖對象可以封裝成 HTTP API供外部系統(tǒng)調(diào)用批量支持同一張圖可并發(fā)處理多條任務(wù)配合限流和隊(duì)列使用從這里開始后面所有內(nèi)容都圍繞這個(gè)目標(biāo)展開把一個(gè)普通的客服處理流程變成一張可運(yùn)行、可測試、可上線的 Agent 圖。2. 適用場景與使用邊界Graph Engineering 最適合“步驟清晰但中間有判斷”的業(yè)務(wù)場景。比如客服工單處理先判斷用戶意圖再?zèng)Q定走訂單查詢分支、知識(shí)庫分支還是投訴升級分支。內(nèi)容審核先做基礎(chǔ)過濾再由 LLM 判斷風(fēng)險(xiǎn)等級高風(fēng)險(xiǎn)進(jìn)入人工復(fù)核。數(shù)據(jù)分析報(bào)告先取數(shù)再清洗再讓 LLM 生成結(jié)論最后交給審查節(jié)點(diǎn)。內(nèi)部工具編排把多個(gè)內(nèi)部系統(tǒng)的操作串成一條固定流程每一步都有權(quán)限校驗(yàn)。文檔處理先解析文件再分塊再檢索再生成摘要最后轉(zhuǎn)成 Markdown 輸出。這類場景有一個(gè)共同點(diǎn)流程主干是確定的只是中途存在若干需要判斷的分岔口。Graph 正好把“確定的部分”和“判斷的部分”分開管理。Graph Engineering 不適合的場景也要說清楚。如果任務(wù)是開放閑聊、開放式探索、完全不確定的自主行為圖的節(jié)點(diǎn)邊界反而會(huì)變成限制。比如“幫我在互聯(lián)網(wǎng)上找資料并自主決定下一步”很難預(yù)先畫出一張完整的圖更適合用自由式 Agent Loop 或 Plan-and-Execute 配合動(dòng)態(tài)規(guī)劃。還有一類場景是長時(shí)記憶高度依賴型任務(wù)對話系統(tǒng)依賴長期歷史記憶把狀態(tài)全部塞進(jìn)圖 State 會(huì)讓結(jié)構(gòu)非常臃腫。使用邊界方面需要特別注意圖編排本身不解決數(shù)據(jù)權(quán)限問題。節(jié)點(diǎn)里可能調(diào)用訂單接口、讀取用戶信息、訪問內(nèi)部資料庫這些操作必須提前做好角色權(quán)限控制。涉及個(gè)人信息時(shí)要脫敏涉及外部版權(quán)內(nèi)容時(shí)只能檢索和引用不能隨意生成和分發(fā)。上線前至少確認(rèn)三件事誰有權(quán)觸發(fā)這個(gè)流程、流程中間能不能插人工審批、輸出內(nèi)容是否需要復(fù)核。3. 環(huán)境準(zhǔn)備與前置條件Graph Engineering 依賴不復(fù)雜核心是 Python 環(huán)境和一個(gè)圖編排框架。這里以 LangGraph 生態(tài)為例因?yàn)樗?LangChain 生態(tài)銜接好社區(qū)資料也多。前置環(huán)境清單項(xiàng)目建議要求操作系統(tǒng)Windows 10/11、macOS、Linux 均可Python3.9 以上建議 3.10 或 3.11包管理工具pip建議配合 virtualenv 或 condaLLM 服務(wù)需要可訪問的 OpenAI 兼容 API或本地部署模型圖編排框架langgraph按實(shí)際項(xiàng)目版本安裝磁盤空間純代碼編排很小程序依賴通常 2-5GB 以內(nèi)顯存如果只調(diào)遠(yuǎn)程 LLM不強(qiáng)制獨(dú)顯如果用本地模型按模型要求準(zhǔn)備先創(chuàng)建虛擬環(huán)境并安裝依賴python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install langgraph langchain-core openai fastapi uvicorn說明一下LangGraph 的 API 在不同版本之間會(huì)有調(diào)整安裝之后如果遇到函數(shù)名不一致以當(dāng)前版本的官方文檔為準(zhǔn)。下面的代碼按常見寫法演示核心邏輯不變。還需要準(zhǔn)備 LLM 服務(wù)的訪問憑證。建議放到環(huán)境變量而不是直接寫死在代碼里export OPENAI_API_KEY你的密鑰 export OPENAI_BASE_URL你的接口地址如果不準(zhǔn)備用任何第三方圖編排框架也可以自研一個(gè)極簡圖引擎這個(gè)方案放在第 5 節(jié)單獨(dú)說明。自研的好處是零依賴缺點(diǎn)是可視化、斷點(diǎn)恢復(fù)、并發(fā)調(diào)度都要自己寫適合學(xué)習(xí)不建議直接上生產(chǎn)。4. 把 SOP 拆成 Graph 節(jié)點(diǎn)一套可直接套用的方法不要一上來就寫代碼先把 SOP 畫出來。拆解過程建議按下面六步走。第一步列出完整步驟清單。把現(xiàn)有 SOP 從開始到結(jié)束的每一步寫出來不要省略人覺得“理所當(dāng)然”的環(huán)節(jié)。判斷、記錄、重試都屬于步驟。第二步找出判斷點(diǎn)。每一步里只要出現(xiàn)“如果”“否則”“根據(jù) XX 決定”這就是一個(gè)條件路由。條件路由可以交給規(guī)則也可以交給 LLM。第三步找出可并行步驟。如果兩個(gè)節(jié)點(diǎn)互不依賴且執(zhí)行順序不影響結(jié)果就設(shè)計(jì)成并行分支。例如“檢索知識(shí)庫”和“查詢訂單狀態(tài)”互不依賴可以并行。第四步定義狀態(tài)字段。把每個(gè)節(jié)點(diǎn)的輸入輸出字段列出來。狀態(tài)字段越收斂越好不要把所有臨時(shí)變量都塞進(jìn)去。第五步為每個(gè)節(jié)點(diǎn)寫函數(shù)簽名。每個(gè)節(jié)點(diǎn)函數(shù)接收 State 類型返回一個(gè) dict更新 State 中需要變化的字段。第六步組裝圖。先用順序邊連接主干再用條件路由把分支接上最后編譯運(yùn)行。用一個(gè)實(shí)際的客服工單 SOP 舉例。假設(shè)原始流程是這樣的用戶發(fā)起咨詢 → 系統(tǒng)識(shí)別用戶意圖 → 如果用戶要查訂單調(diào)用訂單系統(tǒng)查詢?nèi)绻脩羰瞧胀ㄗ稍儥z索知識(shí)庫 → 根據(jù)查詢結(jié)果生成回復(fù) → 高風(fēng)險(xiǎn)內(nèi)容進(jìn)入人工復(fù)核否則直接回復(fù)。拆成圖節(jié)點(diǎn)后是這樣原流程步驟圖節(jié)點(diǎn)節(jié)點(diǎn)類型主要輸出字段識(shí)別用戶意圖classify_input普通節(jié)點(diǎn)或 LLM 節(jié)點(diǎn)intent檢索知識(shí)庫search_kb普通節(jié)點(diǎn)kb_result查詢訂單系統(tǒng)query_order工具節(jié)點(diǎn)order_result生成回復(fù)generate_answerLLM 節(jié)點(diǎn)final_answer是否進(jìn)入人工復(fù)核check_risk條件路由risk_level這個(gè)例子會(huì)在下一節(jié)直接用代碼實(shí)現(xiàn)。注意一個(gè)細(xì)節(jié)訂單查詢和知識(shí)庫檢索不是必然全部執(zhí)行它們由 classify_input 的條件路由決定走哪條邊這才是圖和順序代碼的核心區(qū)別。5. 實(shí)操最小可運(yùn)行的 Agent 圖這一節(jié)寫一個(gè)完整示例演示怎么把上面那張圖變成可執(zhí)行代碼。示例使用 LangGraph 的常見寫法。5.1 定義工作流狀態(tài)先定義一個(gè) TypedDict也就是所有節(jié)點(diǎn)共享的狀態(tài)結(jié)構(gòu)from typing import Literal, TypedDict from langgraph.graph import StateGraph, START, END class WorkflowState(TypedDict): user_input: str intent: str kb_result: str order_result: str final_answer: str字段含義很清楚user_input 是用戶原始輸入intent 是分類結(jié)果kb_result 和 order_result 分別是兩個(gè)分支產(chǎn)生的中間結(jié)果final_answer 是最終回復(fù)。5.2 寫節(jié)點(diǎn)函數(shù)每個(gè)節(jié)點(diǎn)函數(shù)只做一件事讀取需要的字段返回需要更新的字段。這里先用規(guī)則代替 LLM保證示例能脫離外部 API 運(yùn)行def classify_input(state: WorkflowState) - dict: text state[user_input] if 訂單 in text or 發(fā)貨 in text or 物流 in text: return {intent: order} return {intent: consult} def search_kb(state: WorkflowState) - dict: # 實(shí)際項(xiàng)目里這里可以調(diào)用檢索服務(wù)或向量數(shù)據(jù)庫 return {kb_result: 知識(shí)庫檢索結(jié)果用戶咨詢的是物流標(biāo)準(zhǔn)的常見問題解答。} def query_order(state: WorkflowState) - dict: # 實(shí)際項(xiàng)目里這里可以調(diào)用內(nèi)部訂單接口 return {order_result: 訂單 OD-2024-001 已發(fā)貨預(yù)計(jì) 2 天后到達(dá)。} def generate_answer(state: WorkflowState) - dict: if state[intent] order: answer f關(guān)于「{state[user_input]}」的查詢結(jié)果{state[order_result]} else: answer f關(guān)于「{state[user_input]}」的回復(fù){state[kb_result]} return {final_answer: answer}節(jié)點(diǎn)函數(shù)返回值會(huì)覆蓋 State 中對應(yīng)字段。這里故意把每個(gè)節(jié)點(diǎn)保持成純函數(shù)形態(tài)后續(xù)測試非常省事。5.3 建圖、加條件路由、編譯接下來構(gòu)建圖結(jié)構(gòu)graph StateGraph(WorkflowState) graph.add_node(classify, classify_input) graph.add_node(kb, search_kb) graph.add_node(order, query_order) graph.add_node(answer, generate_answer) graph.add_edge(START, classify) def route_by_intent(state: WorkflowState) - Literal[consult, order]: return state[intent] graph.add_conditional_edges( classify, route_by_intent, { consult: kb, order: order, }, ) graph.add_edge(kb, answer) graph.add_edge(order, answer) graph.add_edge(answer, END) app graph.compile()條件路由這一段是核心。classify 節(jié)點(diǎn)執(zhí)行完會(huì)調(diào)用 route_by_intent拿到返回字符串再根據(jù)映射字典決定邊走向。如果返回的字符串不在映射字典里L(fēng)angGraph 會(huì)報(bào)錯(cuò)所以路由函數(shù)必須保證返回值受控。現(xiàn)在跑一次result app.invoke({user_input: 我的訂單為什么還沒發(fā)貨}) print(result[final_answer])輸出符合預(yù)期關(guān)于「我的訂單為什么還沒發(fā)貨」的查詢結(jié)果訂單 OD-2024-001 已發(fā)貨預(yù)計(jì) 2 天后到達(dá)。再跑一個(gè)咨詢類輸入result app.invoke({user_input: 一般快遞多久能送到}) print(result[final_answer])會(huì)走知識(shí)庫分支。到這里一張最小 Agent 圖已經(jīng)跑通了。5.4 把節(jié)點(diǎn)換成真實(shí) LLM把 classify_input 換成 LLM 判斷核心思路是用 LLM 返回結(jié)構(gòu)化結(jié)果然后寫回 State。示例使用 OpenAI 兼容接口import json import os from openai import OpenAI client OpenAI( api_keyos.environ[OPENAI_API_KEY], base_urlos.environ.get(OPENAI_BASE_URL, https://api.openai.com/v1), ) def classify_input_with_llm(state: WorkflowState) - dict: response client.chat.completions.create( modelgpt-4o-mini, messages[ { role: system, content: ( 你是一個(gè)意圖識(shí)別模塊。只從下面兩個(gè)選項(xiàng)中選擇一個(gè)不要輸出其他內(nèi)容。 選項(xiàng)consult、order ), }, { role: user, content: state[user_input], }, ], temperature0, ) intent response.choices[0].message.content.strip() return {intent: intent}然后建圖時(shí)把節(jié)點(diǎn)替換成這個(gè)函數(shù)即可graph StateGraph(WorkflowState) graph.add_node(classify, classify_input_with_llm) # 其余邊和上面保持一致這里要注意如果 LLM 返回了預(yù)期之外的內(nèi)容條件路由會(huì)直接報(bào)錯(cuò)。更穩(wěn)妥的做法是在路由函數(shù)里加歸一化處理def route_by_intent(state: WorkflowState) - Literal[consult, order]: if state[intent].startswith(訂單) or order in state[intent]: return order return consult在這個(gè)階段把“模型判斷”和“流程控制”解耦開后續(xù)換模型、換提示詞都不用動(dòng)圖結(jié)構(gòu)。5.5 不引入框架的自研方案如果只是想先驗(yàn)證思路也可以不裝 LangGraph用普通 Python 函數(shù)和 if/else 模擬同樣的流程def run_workflow(user_input: str) - dict: state {user_input: user_input} state.update(classify_input(state)) if state[intent] order: state.update(query_order(state)) else: state.update(search_kb(state)) state.update(generate_answer(state)) return state這個(gè)方案更容易理解但可擴(kuò)展性差很多新增節(jié)點(diǎn)要改函數(shù)體并行和循環(huán)都要手寫斷點(diǎn)恢復(fù)也沒有現(xiàn)成機(jī)制。所以生產(chǎn)環(huán)境建議直接用圖編排框架自研版本只適合作為教學(xué)驗(yàn)證。6. 封裝 API 與批量任務(wù)圖跑通之后第一步是把編譯好的 app 對象封裝成 HTTP 接口方便前端、定時(shí)任務(wù)和其他后端系統(tǒng)調(diào)用。6.1 用 FastAPI 暴露接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TaskRequest(BaseModel): user_input: str class TaskResponse(BaseModel): final_answer: str app.post(/run, response_modelTaskResponse) def run_task(req: TaskRequest) - TaskResponse: result app.invoke({user_input: req.user_input}) return TaskResponse(final_answerresult[final_answer])啟動(dòng)服務(wù)uvicorn server:app --host 127.0.0.1 --port 8000調(diào)用測試curl -X POST http://127.0.0.1:8000/run \ -H Content-Type: application/json \ -d {user_input: 我的訂單為什么還沒發(fā)貨}返回結(jié)果也是 JSON直接把圖執(zhí)行能力暴露成標(biāo)準(zhǔn) API。需要注意這個(gè)示例沒有加鑒權(quán)生產(chǎn)環(huán)境要放在內(nèi)網(wǎng)或加 Token 校驗(yàn)不能裸奔到公網(wǎng)。6.2 批量任務(wù)與并發(fā)控制批量任務(wù)的核心是把每條輸入當(dāng)成獨(dú)立的一次 graph.invoke然后控制并發(fā)。并發(fā)過高會(huì)打滿上游接口所以建議用限流器from concurrent.futures import ThreadPoolExecutor, as_completed inputs [ {user_input: 訂單怎么還沒發(fā)貨}, {user_input: 一般快遞要多久}, ] with ThreadPoolExecutor(max_workers4) as pool: futures [pool.submit(app.invoke, item) for item in inputs] for future in as_completed(futures): result future.result() print(result[final_answer])批量任務(wù)要做好三件事事項(xiàng)建議失敗重試使用帶退避的重試機(jī)制避免瞬時(shí)故障直接丟任務(wù)日志記錄記錄輸入 ID、節(jié)點(diǎn)名、開始時(shí)間、結(jié)束時(shí)間、輸出摘要任務(wù)去重批量任務(wù)要有唯一任務(wù) ID避免重復(fù)提交造成重復(fù)處理如果單條任務(wù)運(yùn)行時(shí)間很長還要考慮把任務(wù)放進(jìn)隊(duì)列用 Worker 異步消費(fèi)而不是在請求線程里同步等待。7. 資源占用與運(yùn)行觀察先明確一個(gè)認(rèn)知圖編排引擎本身占用的算力極低。它主要做節(jié)點(diǎn)調(diào)度、狀態(tài)合并、邊判斷不承擔(dān)模型推理。真正消耗資源的是三個(gè)地方LLM 調(diào)用次數(shù)、外部接口響應(yīng)時(shí)間、State 體積。LLM 調(diào)用次數(shù)是第一個(gè)要盯的指標(biāo)。一條任務(wù)如果經(jīng)過 5 個(gè)節(jié)點(diǎn)每個(gè)節(jié)點(diǎn)都調(diào)一次 LLM那就是 5 次調(diào)用。批量 1000 條任務(wù)就是 5000 次。調(diào)整路由策略把不需要 LLM 的節(jié)點(diǎn)改成規(guī)則判斷能直接砍掉大半成本。外部接口響應(yīng)時(shí)間是第二個(gè)指標(biāo)。圖流程里如果查詢訂單接口耗時(shí) 3 秒那整條鏈路就被卡住 3 秒。建議優(yōu)先做并行分支把兩個(gè)不相干的接口調(diào)用放到同一批執(zhí)行。State 體積是第三個(gè)指標(biāo)。每次節(jié)點(diǎn)返回的 dict 都會(huì)被合并進(jìn) State。如果節(jié)點(diǎn)塞入大段文本、完整日志、全量 JSONState 會(huì)越來越臃腫傳輸和調(diào)試都會(huì)變慢。合理做法是只保留后續(xù)節(jié)點(diǎn)需要的字段中間大對象建議落到外部存儲(chǔ)只把引用 ID 放進(jìn) State。如果要系統(tǒng)化觀察建議在每條任務(wù)里記錄import time start time.time() result app.invoke(input_data) print(ftask complete, cost{time.time() - start:.2f}s)更細(xì)的節(jié)點(diǎn)級耗時(shí)可以給每個(gè)節(jié)點(diǎn)函數(shù)外層包一層帶日志的裝飾器把節(jié)點(diǎn)名、入?yún)⒄?、耗時(shí)和返回字段名打出來。這樣在線上一眼能看到瓶頸在哪個(gè)節(jié)點(diǎn)。顯存占用方面如果 LLM 走遠(yuǎn)程 API本機(jī)基本不需要顯存。如果節(jié)點(diǎn)里跑本地模型那就要按本地模型的要求準(zhǔn)備顯存。這部分?jǐn)?shù)字因模型而異實(shí)際占用需要以本機(jī)測試為準(zhǔn)。不要只看總量要看并發(fā)數(shù)4 條并發(fā)任務(wù)同時(shí)跑顯存占用可能接近單任務(wù)的 4 倍。8. 常見問題與排查方法圖編排看起來簡單實(shí)際踩坑點(diǎn)不少。下面按常見程度列一份排查清單。問題現(xiàn)象可能原因排查方式解決方案圖編譯后不執(zhí)行任何節(jié)點(diǎn)START 節(jié)點(diǎn)沒有連接打印 graph.get_graph() 看拓?fù)浣Y(jié)構(gòu)檢查 START 到首節(jié)點(diǎn)的邊條件路由報(bào)錯(cuò) KeyError返回字符串不在映射字典里打印路由函數(shù)的返回值在路由函數(shù)里做歸一化限制返回值集合輸出缺少某個(gè)字段節(jié)點(diǎn)函數(shù)返回 dict 拼寫錯(cuò)誤檢查節(jié)點(diǎn)返回的字段名給 State 所有字段補(bǔ)默認(rèn)值節(jié)點(diǎn)重復(fù)執(zhí)行給同一個(gè)節(jié)點(diǎn)加了多條進(jìn)入邊查看圖結(jié)構(gòu)明確關(guān)鍵節(jié)點(diǎn)只有一條入口多余分支被跳過條件邊和目標(biāo)節(jié)點(diǎn)沒連接檢查 add_conditional_edges 的映射補(bǔ)全分支映射并行分支結(jié)果互相覆蓋多個(gè)節(jié)點(diǎn)寫入同一字段檢查各節(jié)點(diǎn)返回字段使用不同的狀態(tài)字段API 調(diào)用超時(shí)外部接口響應(yīng)慢檢查節(jié)點(diǎn)日志耗時(shí)拆成異步節(jié)點(diǎn)或增加重試批量任務(wù)跑到一半崩潰單條任務(wù)異常導(dǎo)致整個(gè)進(jìn)程退出逐個(gè)任務(wù)捕獲異常用 future.exception 收集錯(cuò)誤單獨(dú)重試失敗任務(wù)LLM 返回內(nèi)容混亂沒有約束輸出格式打印原始返回值提示詞要求 JSON 輸出并做解析容錯(cuò)還有一個(gè)隱蔽問題反復(fù)出現(xiàn)批量并發(fā)時(shí)狀態(tài)字段互相污染。雖然每次 invoke 都是獨(dú)立狀態(tài)但如果節(jié)點(diǎn)函數(shù)內(nèi)部用了普通模塊級變量或類屬性保存臨時(shí)數(shù)據(jù)就可能串?dāng)?shù)據(jù)。節(jié)點(diǎn)函數(shù)要保持無狀態(tài)只從 state 讀取只往 state 寫入。9. 最佳實(shí)踐與使用建議把 SOP 工程化成 Graph 之后維護(hù)成本才是長期問題。下面這幾條建議來自工程經(jīng)驗(yàn)建議直接落到團(tuán)隊(duì)規(guī)范里。9.1 狀態(tài)字段要克制State 不是業(yè)務(wù)數(shù)據(jù)庫只保存節(jié)點(diǎn)之間需要傳遞的數(shù)據(jù)。字段越少越好寧可多拆幾個(gè)節(jié)點(diǎn)也不要把“順便可能用到的信息”全塞進(jìn)去。9.2 路由函數(shù)必須收斂所有條件路由的返回值最好集中在有限集合里。不要用自由文本作為跳轉(zhuǎn)標(biāo)記不要直接拿 LLM 的完整輸出做路由值。先解析、再映射、再跳轉(zhuǎn)三步拆開。9.3 每個(gè)節(jié)點(diǎn)都要有日志和失敗策略線上排查時(shí)最怕某個(gè)節(jié)點(diǎn)靜默失敗。給每個(gè)節(jié)點(diǎn)配上統(tǒng)一的運(yùn)行日志輸出節(jié)點(diǎn)名、輸入摘要、耗時(shí)和返回結(jié)果摘要。失敗時(shí)區(qū)分三種策略重試一次、跳到兜底節(jié)點(diǎn)、直接終止人工處理。9.4 把人工審批做成節(jié)點(diǎn)而不是事后補(bǔ)合規(guī)要求高的流程建議在圖中顯式加入 human_review 節(jié)點(diǎn)。這個(gè)節(jié)點(diǎn)不調(diào)用 LLM而是發(fā)送消息給審批人收到人工確認(rèn)后才進(jìn)入下一步。看到圖的時(shí)候誰在哪個(gè)環(huán)節(jié)審批、如果不通過走哪條邊一目了然。9.5 首次上線跑小流量不管本地測試多順利第一次上線都應(yīng)限制并發(fā)、控制流量。先讓少量真實(shí)任務(wù)跑一段時(shí)間觀察條件路由命中率、LLM 結(jié)果質(zhì)量和外部接口穩(wěn)定性再逐步放開。批量任務(wù)建議從幾十條開始跑完檢查輸出再放量。9.6 素材和數(shù)據(jù)合規(guī)必須前置如果流程涉及用戶個(gè)人數(shù)據(jù)、內(nèi)部業(yè)務(wù)數(shù)據(jù)、版權(quán)素材交付前必須確認(rèn)數(shù)據(jù)權(quán)限。生成類 Agent 的輸出在面向用戶前最好再過一個(gè)內(nèi)容合規(guī)檢查節(jié)點(diǎn)。10. 總結(jié)與下一步Graph Engineering 解決的核心問題不是“讓模型更聰明”而是“讓流程更可控”。Graph 讓 SOP 變成數(shù)據(jù)結(jié)構(gòu)Agent 按圖執(zhí)行每一步都知道自己在哪兒、要去哪兒、失敗了怎么處理。這個(gè)思路在客服工單、內(nèi)容審核、報(bào)告生成、批量數(shù)據(jù)處理這類強(qiáng)流程場景里落地速度非常快。最值得先做的事很簡單找一個(gè)現(xiàn)有 SOP挑出 3 到 5 個(gè)關(guān)鍵節(jié)點(diǎn)把步驟畫成圖再按第 5 節(jié)的代碼模板跑通一次。先不要追求復(fù)雜并行先把順序流程和條件路由跑起來這是所有復(fù)雜編排的地基。最大的坑已經(jīng)強(qiáng)調(diào)過幾次條件路由的返回值必須受控State 字段必須精簡節(jié)點(diǎn)函數(shù)必須無狀態(tài)。這三個(gè)問題如果還踩說明圖還沒真正工程化。下一步可以嘗試的方向加 Checkpoint 實(shí)現(xiàn)故障恢復(fù)把并行分支改成真正的異步執(zhí)行把路由判斷從規(guī)則升級成 LLM 決策再接一個(gè)任務(wù)隊(duì)列管理批量任務(wù)。SOP 畫成圖不是結(jié)束畫完之后有一種穩(wěn)穩(wěn)的掌控感。