幫一個(gè)朋友優(yōu)化簡(jiǎn)歷這件小事曾經(jīng)把我逼到差點(diǎn)掀桌。他丟來(lái)一份 PDF說(shuō)“幫我改成適合投高級(jí)前端崗的版本”。我最初的做法很樸素把 PDF 內(nèi)容復(fù)制進(jìn)對(duì)話框讓大模型給建議。結(jié)果它給的建議全是正確的廢話——“突出成果、量化數(shù)據(jù)、精簡(jiǎn)表達(dá)”。我盯著屏幕愣了幾秒才意識(shí)到簡(jiǎn)歷優(yōu)化根本不是一次對(duì)話而是一條流水線——解析 PDF 里的亂格式、拆解目標(biāo) JD 里的硬性條件、逐條診斷經(jīng)歷描述的薄弱點(diǎn)、重寫、壓縮、排版、導(dǎo)出。這條流水線里任何一步都可能出錯(cuò)、需要回退、需要等用戶確認(rèn)。這正是 AI Agent 的典型場(chǎng)景不是單純堆 prompt 能糊弄過(guò)去的。于是我決定用自己最熟悉的 JS/TS 技術(shù)棧把它完整落地Next.js 做應(yīng)用殼和 API 層LangGraph.js 做 Agent 編排引擎。這篇文章就是這次完整落地后的復(fù)盤包括選型邏輯、狀態(tài)圖設(shè)計(jì)、四大功能模塊的細(xì)節(jié)、并發(fā)調(diào)優(yōu)過(guò)程、部署上線的坑。適合正在用 JS/TS 做 AI 應(yīng)用或者準(zhǔn)備把“聊天機(jī)器人”升級(jí)成“能干活 Agent”的工程師。1. 選型復(fù)盤為什么技術(shù)清單最后只剩 Next.js LangGraph.js1.1 我一開(kāi)始根本不是這個(gè)方案誠(chéng)實(shí)講我的第一版是用 FastAPI LangChain 搭的。原因很現(xiàn)實(shí)——AI Agent 圈的教程、范例、踩坑貼八成以上都是 Python 生態(tài)資料豐富遇到問(wèn)題隨便搜就能找到答案。LangChain 的 LCEL 表達(dá)式、各種 Tool 封裝、文檔加載器我只是照著文檔拼第一版就順利跑通了。但做到第二版我放棄了不是因?yàn)榕懿黄饋?lái)而是這個(gè)項(xiàng)目有個(gè)躲不掉的需求要給用戶一個(gè)能上傳簡(jiǎn)歷、實(shí)時(shí)看進(jìn)度、在線改稿的界面。用 FastAPI 寫接口前端還得另起一個(gè) React 項(xiàng)目中間要處理跨域、WebSocket 推送、兩套部署管道。為了一個(gè)工具型產(chǎn)品維護(hù)兩套技術(shù)棧不劃算。這是個(gè)很實(shí)際的成本問(wèn)題不是技術(shù)潔癖。第二條路是 Node 生態(tài)里手寫“偽 Agent”先用 if/else 判斷走哪個(gè) prompt再靠隊(duì)列或循環(huán)調(diào)度多輪調(diào)用。這個(gè)方案前期推進(jìn)飛快但做到中后期非常痛苦。你會(huì)不斷碰到這些需求某一輪 LLM 返回了格式錯(cuò)誤要不要自動(dòng)重試用戶看完某段改寫說(shuō)“不行回到上一版”狀態(tài)怎么回退整個(gè)流程跑到一半服務(wù)重啟了進(jìn)行到哪一步了想讓用戶在某個(gè)節(jié)點(diǎn)手動(dòng)補(bǔ)充信息再繼續(xù)怎么暫停這些需求本質(zhì)上是“流程狀態(tài)管理”。手寫到最后就是在給自己造一個(gè)劣質(zhì)的、充滿 bug 的狀態(tài)機(jī)框架而且可觀測(cè)性極差——出了問(wèn)題只能靠日志瞎猜。LangGraph.js 解決的就是這個(gè)問(wèn)題。它把“Agent 是圖而不是鏈”這個(gè)理念直接做成了框架節(jié)點(diǎn)是普通函數(shù)邊決定下一步去哪共享狀態(tài)在整張圖里流動(dòng)。該重試、該回退、該等人工輸入都是圖結(jié)構(gòu)本身的能力不用自己維護(hù)循環(huán)和狀態(tài)了。至于 Next.js 更是順理成章API 路由天然支持流式響應(yīng)文件上傳、表單交互、打印樣式這些前端活兒全包還能和前端同倉(cāng)庫(kù)部署。這套組合最終定下來(lái)只花了一個(gè)晚上做技術(shù)驗(yàn)證。1.2 三套方案的差距我整理成了一張表維度FastAPI LangChainNode 手寫狀態(tài)機(jī)Next.js LangGraph.js學(xué)習(xí)成本中高需要熟悉 Python 生態(tài)低但后期心智負(fù)擔(dān)高中前端開(kāi)發(fā)者友好流程控制鏈?zhǔn)綖橹餮h(huán)/分支要繞全憑自己寫容易失控原生支持條件邊和循環(huán)斷點(diǎn)恢復(fù)需要額外引入持久化方案基本沒(méi)有重啟丟狀態(tài)checkpointer 原生能力人工介入需要自己設(shè)計(jì)回調(diào)機(jī)制靠自己設(shè)計(jì)接口interrupt 原生支持UI 銜接要單獨(dú)搭前端、處理跨域全手寫同倉(cāng)庫(kù)天然銜接維護(hù)成本兩套技術(shù)棧、兩套部署越高越接近重寫框架單倉(cāng)庫(kù)、單語(yǔ)言、社區(qū)活躍選型這件事我的建議是先想清楚你這個(gè)應(yīng)用是“一次性問(wèn)答”還是“多步任務(wù)流”。前者用 LangChain 或直接裸調(diào) API 都行后者值得認(rèn)真評(píng)估 LangGraph。簡(jiǎn)歷優(yōu)化明顯屬于后者——多步驟、可回退、需要人機(jī)協(xié)作。1.3 鏈?zhǔn)菃蜗虻膱D是帶環(huán)的我后來(lái)跟朋友解釋為什么不用 LangChain 時(shí)用了這個(gè)比喻鏈像流水線傳送帶工件從一頭進(jìn)去從另一頭出來(lái)走的是直線圖像車間里的工作臺(tái)工件可以在不同的工位之間來(lái)回流轉(zhuǎn)哪個(gè)環(huán)節(jié)不合格就送回上一個(gè)工位返工。簡(jiǎn)歷 Agent 的業(yè)務(wù)流天然是張圖解析完簡(jiǎn)歷要分析崗位需求分析完要做差距診斷診斷完要改寫改寫完要質(zhì)量檢查——檢查不通過(guò)還得回到診斷環(huán)節(jié)重新來(lái)。這種“環(huán)”在鏈?zhǔn)娇蚣芾飳?shí)現(xiàn)起來(lái)非常別扭但在 LangGraph 里只是加一條條件邊的事。所以別被“框架”兩個(gè)字嚇到LangGraph 的抽象層次其實(shí)很貼近真實(shí)業(yè)務(wù)流程。2. 簡(jiǎn)歷 Agent 的骨架設(shè)計(jì)把業(yè)務(wù)規(guī)則翻譯成狀態(tài)圖2.1 State一張貫穿全流程的“白板”LangGraph 的核心概念是 State狀態(tài)。它本質(zhì)上就是一個(gè)可以被所有節(jié)點(diǎn)讀寫的共享對(duì)象。我剛接觸時(shí)總?cè)滩蛔“磦鹘y(tǒng)后端思維去想——“每個(gè)節(jié)點(diǎn)之間應(yīng)該定義清晰的接口、傳參、返回值”。但在 LangGraph 里節(jié)點(diǎn)之間不直接傳參而是通過(guò)修改 State 通信。這個(gè)設(shè)計(jì)一開(kāi)始讓我很不適應(yīng)后來(lái)才明白它的好處任何節(jié)點(diǎn)的中間結(jié)果都可以隨時(shí)查看、落庫(kù)、展示給用戶調(diào)試時(shí)把 State 打出來(lái)看一眼整個(gè)流程走到哪一目了然。我定義的 State 大概長(zhǎng)這樣interface ResumeAgentState { // 輸入 fileRawText: string; // 解析后的原始文本 targetJD: string; // 目標(biāo)崗位 JD // 中間產(chǎn)物 structuredResume?: ResumeSection[]; // 結(jié)構(gòu)化后的簡(jiǎn)歷分塊 jdAnalysis?: JDAnalysis; // JD 硬性/軟性條件拆分 diagnosis?: GapDiagnosis[]; // 逐塊差距診斷 rewrites?: Recordstring, string; // 重寫后的內(nèi)容 // 控制字段 revisionCount: number; // 當(dāng)前回退輪次 maxRevisions: number; // 最大回退輪次 pendingUserInput?: string; // 等待用戶補(bǔ)充的信息 }這里有一個(gè)容易忽略的設(shè)計(jì)點(diǎn)把revisionCount和maxRevisions這種控制字段放進(jìn) State而不是放在節(jié)點(diǎn)內(nèi)部變量里。因?yàn)閳D可能被中斷、持久化、恢復(fù)節(jié)點(diǎn)內(nèi)部變量會(huì)丟但 State 會(huì)被 checkpointer 完整保存下來(lái)。所有需要跨步驟保留的計(jì)數(shù)都放 State。2.2 節(jié)點(diǎn)與條件邊流程長(zhǎng)什么樣我把整個(gè) Agent 編排成 6 個(gè)節(jié)點(diǎn)用文字描述大概是這樣parse_resume接收上傳的 PDF/Word抽取文本并結(jié)構(gòu)化。analyze_jd解析目標(biāo)崗位 JD拆出硬性條件和軟性條件。diagnose_gaps把結(jié)構(gòu)化簡(jiǎn)歷和 JD 條件逐條對(duì)照產(chǎn)出差距清單。rewrite_sections針對(duì)差距清單逐塊改寫簡(jiǎn)歷經(jīng)歷同時(shí)做 STAR 重構(gòu)。quality_check對(duì)改寫結(jié)果做質(zhì)量檢查判斷是否達(dá)標(biāo)。render_output把最終內(nèi)容渲染成 Markdown/PDF。節(jié)點(diǎn)的連接關(guān)系是關(guān)鍵parse_resume → analyze_jd → diagnose_gaps → rewrite_sections → quality_check然后quality_check連了兩條條件邊——達(dá)標(biāo)走render_output不達(dá)標(biāo)且revisionCount maxRevisions則回到diagnose_gaps再來(lái)一輪。這是整個(gè)圖最有價(jià)值的一條環(huán)。核心代碼骨架長(zhǎng)這樣import { StateGraph, END } from langchain/langgraph; const graph new StateGraphResumeAgentState() .addNode(parse_resume, parseResumeNode) .addNode(analyze_jd, analyzeJDNode) .addNode(diagnose_gaps, diagnoseGapsNode) .addNode(rewrite_sections, rewriteSectionsNode) .addNode(quality_check, qualityCheckNode) .addNode(render_output, renderOutputNode) .addEdge(parse_resume, analyze_jd) .addEdge(analyze_jd, diagnose_gaps) .addEdge(diagnose_gaps, rewrite_sections) .addEdge(rewrite_sections, quality_check) .addConditionalEdges(quality_check, (state) { if (state.revisionCount state.maxRevisions) return render_output; return diagnose_gaps; // 質(zhì)量不達(dá)標(biāo)回退重來(lái) }) .addEdge(render_output, END) .compile();我實(shí)際開(kāi)發(fā)時(shí)把maxRevisions設(shè)成了 1也就是最多回退一輪。原因很樸素回退是要重新調(diào)用 LLM 的每多一輪就多一筆 token 成本而且用戶等著看結(jié)果不能無(wú)限循環(huán)。如果第一輪改寫質(zhì)量不行回退一次基本就能找到問(wèn)題多半是診斷環(huán)節(jié)的輸入不夠精確再不行就直接出結(jié)果讓用戶手動(dòng)改。2.3 為什么這種設(shè)計(jì)比“一個(gè)大 prompt 串全部”強(qiáng)很多人寫完第一版會(huì)想為什么不把所有步驟塞進(jìn)一個(gè)大 prompt讓 LLM 一次全干完我試過(guò)效果很差。原因有三個(gè)第一上下文膨脹。一份完整簡(jiǎn)歷加一段 JD 加一堆指令一次塞進(jìn)去往往三四千 token 起步LLM 很容易顧此失彼——改了這段忘了那段。第二可觀測(cè)性為零。大 prompt 是個(gè)黑盒用戶問(wèn)你“為什么這段被改掉了”你完全無(wú)法回答。拆成節(jié)點(diǎn)后每個(gè)節(jié)點(diǎn)的輸入輸出都是結(jié)構(gòu)化數(shù)據(jù)你甚至可以把診斷結(jié)果直接展示給用戶看體驗(yàn)完全不同。第三無(wú)法精細(xì)控制。簡(jiǎn)歷里的“工作經(jīng)歷”和“項(xiàng)目經(jīng)歷”的改寫策略其實(shí)不一樣前者更看重職責(zé)描述和成果量化后者更看重技術(shù)難點(diǎn)和解決過(guò)程。用一個(gè)大 prompt 只能籠統(tǒng)處理拆成節(jié)點(diǎn)后我可以給不同 section 配置不同的改寫指令。這也是我認(rèn)為 LangGraph 真正價(jià)值的地方它不是幫你“生成”內(nèi)容而是幫你“組織”內(nèi)容的生產(chǎn)過(guò)程。3. 四大功能模塊落地從“會(huì)聊天”到“能干活”的關(guān)鍵細(xì)節(jié)3.1 簡(jiǎn)歷解析PDF 抽文本是第一個(gè)坑上傳解析聽(tīng)起來(lái)簡(jiǎn)單實(shí)際做起來(lái)第一個(gè)坑就藏在 PDF 里。很多簡(jiǎn)歷 PDF 是表格排版或者多欄布局直接抽出來(lái)的文本順序是亂的——上一行還在“項(xiàng)目經(jīng)歷”下一行突然跳到“專業(yè)技能”再下一行又回到“教育背景”。如果直接把這種亂序文本丟給 LLM 做結(jié)構(gòu)化診斷結(jié)果幾乎必然不準(zhǔn)。我的處理方案分三層用pdf-parse抽原始文本按行切分并保留大致坐標(biāo)如果有的話。用正則和關(guān)鍵詞做“章節(jié)邊界識(shí)別”——比如找到“工作經(jīng)歷”“項(xiàng)目經(jīng)歷”“教育背景”這些常見(jiàn)標(biāo)題把文本切成塊。針對(duì)切不好的情況再讓 LLM 做一次歸一化給定原始文本輸出結(jié)構(gòu)化的 JSON用zod校驗(yàn)返回格式不合格就重試一次。第三層是關(guān)鍵兜底?，F(xiàn)實(shí)中的簡(jiǎn)歷格式千奇百怪完全靠規(guī)則不可能覆蓋所有情況。讓 LLM 做“最后一公里”的歸一化比純規(guī)則魯棒得多。但必須用zod這類庫(kù)做強(qiáng)校驗(yàn)不能讓 LLM 的幻覺(jué)污染下游。解析失敗時(shí)我的策略是重試一次換更詳細(xì)的指令還失敗就明確告訴用戶“這份文件格式太復(fù)雜請(qǐng)手動(dòng)填寫基本信息”不硬撐。3.2 崗位匹配診斷把 JD 拆成可對(duì)比的條件這個(gè)節(jié)點(diǎn)負(fù)責(zé)把 JD“翻譯”成可對(duì)比的條件清單并和簡(jiǎn)歷逐條對(duì)照。我把條件分成兩大類硬性條件技術(shù)棧名稱、工作年限、學(xué)歷、特定框架/工具。這些適合做關(guān)鍵詞級(jí)對(duì)比。軟性條件團(tuán)隊(duì)協(xié)作、溝通能力、架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)。這些需要 LLM 做語(yǔ)義判斷。輸出的診斷結(jié)果我設(shè)計(jì)成一張差距表每一項(xiàng)包含JD 里的原始描述、拆出的條件、簡(jiǎn)歷中的對(duì)應(yīng)證據(jù)、達(dá)標(biāo)狀態(tài)達(dá)標(biāo)/不足/缺失、改寫建議。這張表我直接展示在用戶界面上效果出奇地好——用戶能直觀看到“哪里不行”比一句“整體競(jìng)爭(zhēng)力一般”可信得多。這里有個(gè)實(shí)操經(jīng)驗(yàn)診斷節(jié)點(diǎn)輸出的結(jié)構(gòu)化數(shù)據(jù)是整個(gè) Agent 里質(zhì)量要求最高的我設(shè)置了temperature: 0并讓模型嚴(yán)格按照 JSON 格式輸出。改寫節(jié)點(diǎn)則可以適當(dāng)調(diào)高溫度讓表達(dá)更靈活。同一個(gè) Agent 里不同節(jié)點(diǎn)用不同模型和參數(shù)是 LangGraph 這類框架才方便做到的優(yōu)化。3.3 優(yōu)化改寫一個(gè) Section 一個(gè)子圖改寫是整個(gè)流程里最耗 token、也最容易上下文爆炸的環(huán)節(jié)。最初我把所有工作經(jīng)歷一次性丟給 LLM讓它全部重寫。結(jié)果輸出經(jīng)常偏離原意而且某一條寫得好另一條就敷衍。后來(lái)我改成“一個(gè) Section 一個(gè)子任務(wù)”每個(gè)工作經(jīng)歷/項(xiàng)目經(jīng)歷單獨(dú)走一次改寫上下文只包含該段原文、JD 相關(guān)條件、診斷建議。每次改寫的 prompt 骨架大概是你是資深技術(shù)招聘官。下面是我的一份工作經(jīng)歷原文和目標(biāo)崗位要求。 請(qǐng)按 STAR 法則重寫這段經(jīng)歷要求 1. 保留全部事實(shí)信息不得編造數(shù)據(jù) 2. 補(bǔ)充可量化的描述占比、規(guī)模、性能數(shù)字 3. 突出與目標(biāo)崗位相關(guān)的技能關(guān)鍵詞 4. 控制在 150 字以內(nèi) 原文... 目標(biāo)崗位要求...逐塊改寫的另一個(gè)好處是支持“局部重試”。比如某一段輸出格式不對(duì)只需要重試那一段而不是讓整個(gè) Agent 從頭跑。這在成本控制和錯(cuò)誤恢復(fù)上是質(zhì)的差別。3.4 渲染導(dǎo)出Markdown 到 PDF 并沒(méi)有那么簡(jiǎn)單Agent 跑完的產(chǎn)物是 Markdown但用戶要的是 PDF 或 Word。我最終選定的方案是Markdown 先轉(zhuǎn)成 React 組件結(jié)構(gòu)用 Tailwind 的打印樣式渲染成 HTML再轉(zhuǎn) PDF。這里有兩個(gè)必須處理的細(xì)節(jié)。一是“一頁(yè)限制”問(wèn)題——簡(jiǎn)歷優(yōu)化完內(nèi)容變多了經(jīng)常超出一頁(yè)。我做的不是簡(jiǎn)單地通知用戶“內(nèi)容超了”而是在渲染節(jié)點(diǎn)里按預(yù)設(shè)排版模板計(jì)算內(nèi)容長(zhǎng)度自動(dòng)壓縮優(yōu)先級(jí)較低的內(nèi)容比如把某些點(diǎn)從兩行壓成一行盡量保持一頁(yè)。二是中文字體問(wèn)題——服務(wù)端缺 CJK 字體是必然的后面部署章節(jié)我會(huì)展開(kāi)講。總之這個(gè)模塊看似不起眼其實(shí)是整個(gè)產(chǎn)品“專業(yè)感”的最直接體現(xiàn)值得花時(shí)間打磨。4. 并發(fā)重構(gòu)讓一個(gè) 40 秒的 Agent 任務(wù)扛住 20 路并發(fā)4.1 先定位問(wèn)題串行調(diào)用一個(gè)請(qǐng)求占 40 秒第一版上線后我測(cè)了一次完整流程心里一涼環(huán)節(jié)耗時(shí)文件上傳與解析3~5 s視文件大小JD 分析與差距診斷8~12 s2 次 LLM 調(diào)用分塊改寫18~30 s4~6 個(gè) Section 串行渲染導(dǎo)出2~3 s合計(jì)31~50 s一個(gè)普通接口 100ms 就超時(shí)了我這個(gè)接口動(dòng)輒半分鐘。在線用戶一多服務(wù)器線程池直接被打滿。這就是熱搜詞里“AI Agent 怎么扛并發(fā)”的典型問(wèn)題Agent 的本質(zhì)是把多個(gè) LLM 調(diào)用串起來(lái)單次請(qǐng)求耗時(shí)比普通接口高一個(gè)數(shù)量級(jí)你不能用傳統(tǒng)的“快速響應(yīng)”思路來(lái)設(shè)計(jì)。4.2 第一層優(yōu)化SSE 流式輸出讓請(qǐng)求“活著”我做的第一個(gè)改動(dòng)就是全面改流式。Next.js 的 Route Handler 原生支持ReadableStream我把 Agent 的每個(gè)節(jié)點(diǎn)完成事件實(shí)時(shí)推給前端。效果有兩層第一層是用戶體驗(yàn)——用戶能看到“正在解析簡(jiǎn)歷”“正在分析 JD”“正在改寫第 2 段經(jīng)歷”焦慮感大幅下降第二層是技術(shù)價(jià)值——serverless 平臺(tái)的超時(shí)機(jī)制通?？础笆欠裼谐掷m(xù)返回”流式輸出能讓長(zhǎng)任務(wù)不容易被強(qiáng)殺。前端配合也簡(jiǎn)單用fetch讀response.body就可以// 后端 Route Handler 簡(jiǎn)化版 export async function POST(req: Request) { const encoder new TextEncoder(); const stream new ReadableStream({ async start(controller) { for await (const step of runAgent()) { controller.enqueue(encoder.encode(data: ${JSON.stringify(step)}\n\n)); } controller.close(); }, }); return new Response(stream, { headers: { Content-Type: text/event-stream, Cache-Control: no-cache, }, }); }4.3 第二層優(yōu)化隊(duì)列 狀態(tài)落庫(kù)把“等結(jié)果”變成“查結(jié)果”流式解決的是單個(gè)請(qǐng)求的體驗(yàn)但扛不住真正的并發(fā)高峰。尤其是當(dāng)用戶量上來(lái)之后大量 Agent 任務(wù)同時(shí)跑LLM 供應(yīng)商的限流會(huì)先把你打趴。我的第二層方案是把任務(wù)改成“提交后異步執(zhí)行”的模式用戶提交簡(jiǎn)歷和 JD立即創(chuàng)建一個(gè)任務(wù)返回任務(wù) ID。后臺(tái)從隊(duì)列里取任務(wù)逐個(gè)執(zhí)行 Agent 流程。前端輪詢或通過(guò) SSE 訂閱任務(wù)狀態(tài)。每個(gè)節(jié)點(diǎn)的中間狀態(tài)都寫入數(shù)據(jù)庫(kù)任務(wù)中斷后可以從最近檢查點(diǎn)恢復(fù)。隊(duì)列我用的是BullMQ Redis。任務(wù)量大時(shí)可以做并發(fā)上限控制比如同時(shí)最多跑 10 個(gè) Agent 任務(wù)剩下的排隊(duì)。這樣雖然單個(gè)任務(wù)變慢了但系統(tǒng)整體不會(huì)被打垮用戶體驗(yàn)是“排隊(duì)中”而不是“請(qǐng)求失敗”。這里有一個(gè)取舍要講清楚對(duì)于實(shí)時(shí)交互型的 Agent用戶在線等著結(jié)果流式響應(yīng)是首選對(duì)于批量處理型的 Agent比如批量?jī)?yōu)化一批簡(jiǎn)歷隊(duì)列模式更合適。簡(jiǎn)歷工具兩者都要——單份優(yōu)化用流式批量處理用隊(duì)列。我實(shí)際是把兩種模式并存通過(guò)一個(gè)mode參數(shù)切換。4.4 第三層優(yōu)化限流、重試、模型分流LLM 供應(yīng)商的限流是所有 AI 應(yīng)用躲不開(kāi)的墻。我的處理策略有三條第一指數(shù)退避 抖動(dòng)重試。遇到 429/5xx 錯(cuò)誤不能立即重試要按2^n秒遞增等待并加上隨機(jī)抖動(dòng)避免所有請(qǐng)求在同一時(shí)刻重試造成“驚群效應(yīng)”。async function callLLMWithRetry(fn: () Promiseany, maxRetries 3) { for (let i 0; i maxRetries; i) { try { return await fn(); } catch (e: any) { if (e.status ! 429 e.status 500) throw e; const delay Math.min(2 ** i * 1000, 8000) Math.random() * 500; await new Promise((r) setTimeout(r, delay)); } } }第二同一 Agent 內(nèi)模型分流。診斷和結(jié)構(gòu)化輸出用便宜快速的小模型改寫用更強(qiáng)的大模型。我把不同節(jié)點(diǎn)的模型配到 State 里方便隨時(shí)切換。實(shí)測(cè)成本能降一半以上質(zhì)量沒(méi)有明顯變化。第三結(jié)果緩存。簡(jiǎn)歷優(yōu)化是天然帶緩存的場(chǎng)景——同一份簡(jiǎn)歷投同一個(gè)崗位結(jié)果可以直接復(fù)用。我按文件哈希 JD 哈希 模型版本做緩存 key命中緩存直接秒出結(jié)果。這個(gè)優(yōu)化把并發(fā)壓力降了一個(gè)檔次強(qiáng)烈建議做。4.5 優(yōu)化后的實(shí)測(cè)數(shù)字指標(biāo)優(yōu)化前優(yōu)化后單用戶完整流程耗時(shí)約 40 s約 30 s流式感知更短支持同時(shí)在線執(zhí)行數(shù)5 個(gè)就卡穩(wěn)定 20 個(gè)失敗率5%超時(shí)/限流1%每日 token 成本基準(zhǔn)降約 50%這套組合拳打下來(lái)并發(fā)問(wèn)題才算真正解決。核心思路總結(jié)成一句話能用流式就別用輪詢能用緩存就別重復(fù)算能用隊(duì)列就別讓請(qǐng)求硬扛。5. 部署上線那些文檔里不會(huì)寫的坑與解法5.1 Serverless 執(zhí)行時(shí)限和長(zhǎng)任務(wù)的根本沖突我最初圖省事把整個(gè)應(yīng)用部署在 serverless 平臺(tái)上。第一次壓測(cè)就暴露了問(wèn)題免費(fèi)檔位的單次執(zhí)行時(shí)長(zhǎng)限制只有 10 秒左右付費(fèi)檔位也就幾十秒而我的 Agent 單次請(qǐng)求要 30 秒以上。解決路徑有兩條如果堅(jiān)持 serverless必須把任務(wù)改成“邊算邊推”的模式保證響應(yīng)流持續(xù)輸出并且所有重活通過(guò)流式推給客戶端。短任務(wù)可以這樣糊弄過(guò)去但長(zhǎng)任務(wù)仍有風(fēng)險(xiǎn)。更穩(wěn)的方案是把 Agent 執(zhí)行部分拆成獨(dú)立的 Node 常駐服務(wù)部署在有固定資源的環(huán)境里Next.js 只負(fù)責(zé)前端頁(yè)面和 API 入口內(nèi)部轉(zhuǎn)發(fā)給 Agent 服務(wù)。我最終選了第二條。在我看來(lái)Agent 這種長(zhǎng)耗時(shí)、高 CPU/內(nèi)存開(kāi)銷的任務(wù)和 serverless 的執(zhí)行模型天然不對(duì)付。不要為了“托管省心”硬把一個(gè)不適合的場(chǎng)景塞進(jìn)不適合的平臺(tái)。5.2 checkpointer 狀態(tài)存儲(chǔ)內(nèi)存模式重啟就丟LangGraph 的 checkpointer 是斷點(diǎn)恢復(fù)的關(guān)鍵但默認(rèn)的內(nèi)存模式只能在單進(jìn)程里用。一旦服務(wù)重啟所有進(jìn)行中的 Agent 狀態(tài)全丟。用戶刷新頁(yè)面發(fā)現(xiàn)“我的任務(wù)沒(méi)了”體驗(yàn)極差。解決辦法是把 checkpointer 換成持久化存儲(chǔ)。LangGraph.js 官方支持對(duì)接 PostgreSQL 等存儲(chǔ)我在 Postgres 里建了一張表存圖狀態(tài)快照。每次節(jié)點(diǎn)執(zhí)行完寫入一次重啟后從最近檢查點(diǎn)恢復(fù)。這里有個(gè)細(xì)節(jié)寫入頻率要控制。每個(gè)節(jié)點(diǎn)都寫沒(méi)問(wèn)題因?yàn)?Agent 節(jié)點(diǎn)數(shù)量有限但如果你的圖有大量細(xì)粒度步驟頻繁寫庫(kù)會(huì)拖慢整體速度。我的經(jīng)驗(yàn)是只在“關(guān)鍵節(jié)點(diǎn)完成后”做一次持久化而不是每一步都寫。5.3 token 成本失控Agent 循環(huán)里的“內(nèi)存泄漏”上線一周后我看賬單差點(diǎn)沒(méi)坐住。問(wèn)題出在回退機(jī)制上每次從diagnose_gaps回到rewrite_sectionsState 里的診斷結(jié)果還在增長(zhǎng)新的改寫請(qǐng)求又把舊的診斷內(nèi)容帶上了。多輪循環(huán)后每條消息都帶著完整歷史成本呈指數(shù)上升。我的解法參考了 LangGraph 文檔里的消息壓縮思路在 State 里加一個(gè)“上下文裁剪”邏輯超過(guò)一定輪次后不再把全部歷史傳給 LLM而是只傳“最新一輪診斷 最新改寫結(jié)果 原始簡(jiǎn)歷”前面的輪次只保留摘要。這相當(dāng)于給 Agent 的歷史消息做一次“壓縮 GC”。同時(shí)我給maxRevisions設(shè)硬上限從根上防止無(wú)限循環(huán)。其他幾個(gè)成本控制經(jīng)驗(yàn)一并分享。所有結(jié)構(gòu)化輸出用temperature: 0避免無(wú)意義的多余輸出。長(zhǎng)時(shí)間運(yùn)行的 Agent 啟用供應(yīng)商側(cè)的 prompt 緩存。同一份簡(jiǎn)歷的多輪用戶操作之間復(fù)用已解析的結(jié)構(gòu)化數(shù)據(jù)而不是每次都重新解析。5.4 最后一道坎PDF 中文字體亂碼這是最讓我意外的一個(gè)坑。本地開(kāi)發(fā)跑得好好的 PDF 導(dǎo)出部署到服務(wù)器上后中文全變方塊。原因很簡(jiǎn)單服務(wù)器環(huán)境沒(méi)有安裝 CJK 字體瀏覽器在渲染 PDF 時(shí)找不到中文字形。解決方案是把常用中文字體打包進(jìn)應(yīng)用資源目錄渲染時(shí)通過(guò) CSSfont-face顯式引入。font-face { font-family: NotoSansSC; src: url(/fonts/NotoSansSC-Regular.otf) format(opentype); font-display: swap; }但字體文件通常以 MB 計(jì)直接全量打包會(huì)讓部署包巨大。我最后做了字體子集化——只提取用到的幾百個(gè)常用漢字生成精簡(jiǎn)字體文件體積直接壓到幾十 KB。這一步做完P(guān)DF 導(dǎo)出才算真正穩(wěn)定。最后分享一點(diǎn)個(gè)人體會(huì)這個(gè)項(xiàng)目從第一版“大 prompt 串一切”到最終基于 LangGraph.js 的狀態(tài)圖 Agent我最大的感悟是Agent 應(yīng)用的門檻不在寫代碼而在把業(yè)務(wù)規(guī)則翻譯成狀態(tài)圖。簡(jiǎn)歷優(yōu)化的業(yè)務(wù)規(guī)則恰好適合用圖表達(dá)——有分支、有循環(huán)、有人工介入點(diǎn)硬要用線性流程去套就會(huì)處處別扭。另一個(gè)體會(huì)是框架選型真的不用追新。LangGraph.js 在 JS 社區(qū)的生態(tài)還沒(méi)有 Python 那邊豐富但它的核心抽象足夠穩(wěn)文檔也基本覆蓋了關(guān)鍵場(chǎng)景。我踩過(guò)的坑大多是部署和成本層面的而非框架本身的。如果你正準(zhǔn)備做一個(gè)多步驟的 AI 工具我的建議很直接先畫出業(yè)務(wù)流程的狀態(tài)圖再?gòu)膱D里反推節(jié)點(diǎn)和邊最后才輪到寫代碼。圖畫清楚了代碼只是翻譯工作。