帮一个朋友优化简历这件小事曾经把我逼到差点掀桌。他丢来一份 PDF说“帮我改成适合投高级前端岗的版本”。我最初的做法很朴素把 PDF 内容复制进对话框让大模型给建议。结果它给的建议全是正确的废话——“突出成果、量化数据、精简表达”。我盯着屏幕愣了几秒才意识到简历优化根本不是一次对话而是一条流水线——解析 PDF 里的乱格式、拆解目标 JD 里的硬性条件、逐条诊断经历描述的薄弱点、重写、压缩、排版、导出。这条流水线里任何一步都可能出错、需要回退、需要等用户确认。这正是 AI Agent 的典型场景不是单纯堆 prompt 能糊弄过去的。于是我决定用自己最熟悉的 JS/TS 技术栈把它完整落地Next.js 做应用壳和 API 层LangGraph.js 做 Agent 编排引擎。这篇文章就是这次完整落地后的复盘包括选型逻辑、状态图设计、四大功能模块的细节、并发调优过程、部署上线的坑。适合正在用 JS/TS 做 AI 应用或者准备把“聊天机器人”升级成“能干活 Agent”的工程师。1. 选型复盘为什么技术清单最后只剩 Next.js LangGraph.js1.1 我一开始根本不是这个方案诚实讲我的第一版是用 FastAPI LangChain 搭的。原因很现实——AI Agent 圈的教程、范例、踩坑贴八成以上都是 Python 生态资料丰富遇到问题随便搜就能找到答案。LangChain 的 LCEL 表达式、各种 Tool 封装、文档加载器我只是照着文档拼第一版就顺利跑通了。但做到第二版我放弃了不是因为跑不起来而是这个项目有个躲不掉的需求要给用户一个能上传简历、实时看进度、在线改稿的界面。用 FastAPI 写接口前端还得另起一个 React 项目中间要处理跨域、WebSocket 推送、两套部署管道。为了一个工具型产品维护两套技术栈不划算。这是个很实际的成本问题不是技术洁癖。第二条路是 Node 生态里手写“伪 Agent”先用 if/else 判断走哪个 prompt再靠队列或循环调度多轮调用。这个方案前期推进飞快但做到中后期非常痛苦。你会不断碰到这些需求某一轮 LLM 返回了格式错误要不要自动重试用户看完某段改写说“不行回到上一版”状态怎么回退整个流程跑到一半服务重启了进行到哪一步了想让用户在某个节点手动补充信息再继续怎么暂停这些需求本质上是“流程状态管理”。手写到最后就是在给自己造一个劣质的、充满 bug 的状态机框架而且可观测性极差——出了问题只能靠日志瞎猜。LangGraph.js 解决的就是这个问题。它把“Agent 是图而不是链”这个理念直接做成了框架节点是普通函数边决定下一步去哪共享状态在整张图里流动。该重试、该回退、该等人工输入都是图结构本身的能力不用自己维护循环和状态了。至于 Next.js 更是顺理成章API 路由天然支持流式响应文件上传、表单交互、打印样式这些前端活儿全包还能和前端同仓库部署。这套组合最终定下来只花了一个晚上做技术验证。1.2 三套方案的差距我整理成了一张表维度FastAPI LangChainNode 手写状态机Next.js LangGraph.js学习成本中高需要熟悉 Python 生态低但后期心智负担高中前端开发者友好流程控制链式为主循环/分支要绕全凭自己写容易失控原生支持条件边和循环断点恢复需要额外引入持久化方案基本没有重启丢状态checkpointer 原生能力人工介入需要自己设计回调机制靠自己设计接口interrupt 原生支持UI 衔接要单独搭前端、处理跨域全手写同仓库天然衔接维护成本两套技术栈、两套部署越高越接近重写框架单仓库、单语言、社区活跃选型这件事我的建议是先想清楚你这个应用是“一次性问答”还是“多步任务流”。前者用 LangChain 或直接裸调 API 都行后者值得认真评估 LangGraph。简历优化明显属于后者——多步骤、可回退、需要人机协作。1.3 链是单向的图是带环的我后来跟朋友解释为什么不用 LangChain 时用了这个比喻链像流水线传送带工件从一头进去从另一头出来走的是直线图像车间里的工作台工件可以在不同的工位之间来回流转哪个环节不合格就送回上一个工位返工。简历 Agent 的业务流天然是张图解析完简历要分析岗位需求分析完要做差距诊断诊断完要改写改写完要质量检查——检查不通过还得回到诊断环节重新来。这种“环”在链式框架里实现起来非常别扭但在 LangGraph 里只是加一条条件边的事。所以别被“框架”两个字吓到LangGraph 的抽象层次其实很贴近真实业务流程。2. 简历 Agent 的骨架设计把业务规则翻译成状态图2.1 State一张贯穿全流程的“白板”LangGraph 的核心概念是 State状态。它本质上就是一个可以被所有节点读写的共享对象。我刚接触时总忍不住按传统后端思维去想——“每个节点之间应该定义清晰的接口、传参、返回值”。但在 LangGraph 里节点之间不直接传参而是通过修改 State 通信。这个设计一开始让我很不适应后来才明白它的好处任何节点的中间结果都可以随时查看、落库、展示给用户调试时把 State 打出来看一眼整个流程走到哪一目了然。我定义的 State 大概长这样interface ResumeAgentState { // 输入 fileRawText: string; // 解析后的原始文本 targetJD: string; // 目标岗位 JD // 中间产物 structuredResume?: ResumeSection[]; // 结构化后的简历分块 jdAnalysis?: JDAnalysis; // JD 硬性/软性条件拆分 diagnosis?: GapDiagnosis[]; // 逐块差距诊断 rewrites?: Recordstring, string; // 重写后的内容 // 控制字段 revisionCount: number; // 当前回退轮次 maxRevisions: number; // 最大回退轮次 pendingUserInput?: string; // 等待用户补充的信息 }这里有一个容易忽略的设计点把revisionCount和maxRevisions这种控制字段放进 State而不是放在节点内部变量里。因为图可能被中断、持久化、恢复节点内部变量会丢但 State 会被 checkpointer 完整保存下来。所有需要跨步骤保留的计数都放 State。2.2 节点与条件边流程长什么样我把整个 Agent 编排成 6 个节点用文字描述大概是这样parse_resume接收上传的 PDF/Word抽取文本并结构化。analyze_jd解析目标岗位 JD拆出硬性条件和软性条件。diagnose_gaps把结构化简历和 JD 条件逐条对照产出差距清单。rewrite_sections针对差距清单逐块改写简历经历同时做 STAR 重构。quality_check对改写结果做质量检查判断是否达标。render_output把最终内容渲染成 Markdown/PDF。节点的连接关系是关键parse_resume → analyze_jd → diagnose_gaps → rewrite_sections → quality_check然后quality_check连了两条条件边——达标走render_output不达标且revisionCount maxRevisions则回到diagnose_gaps再来一轮。这是整个图最有价值的一条环。核心代码骨架长这样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; // 质量不达标回退重来 }) .addEdge(render_output, END) .compile();我实际开发时把maxRevisions设成了 1也就是最多回退一轮。原因很朴素回退是要重新调用 LLM 的每多一轮就多一笔 token 成本而且用户等着看结果不能无限循环。如果第一轮改写质量不行回退一次基本就能找到问题多半是诊断环节的输入不够精确再不行就直接出结果让用户手动改。2.3 为什么这种设计比“一个大 prompt 串全部”强很多人写完第一版会想为什么不把所有步骤塞进一个大 prompt让 LLM 一次全干完我试过效果很差。原因有三个第一上下文膨胀。一份完整简历加一段 JD 加一堆指令一次塞进去往往三四千 token 起步LLM 很容易顾此失彼——改了这段忘了那段。第二可观测性为零。大 prompt 是个黑盒用户问你“为什么这段被改掉了”你完全无法回答。拆成节点后每个节点的输入输出都是结构化数据你甚至可以把诊断结果直接展示给用户看体验完全不同。第三无法精细控制。简历里的“工作经历”和“项目经历”的改写策略其实不一样前者更看重职责描述和成果量化后者更看重技术难点和解决过程。用一个大 prompt 只能笼统处理拆成节点后我可以给不同 section 配置不同的改写指令。这也是我认为 LangGraph 真正价值的地方它不是帮你“生成”内容而是帮你“组织”内容的生产过程。3. 四大功能模块落地从“会聊天”到“能干活”的关键细节3.1 简历解析PDF 抽文本是第一个坑上传解析听起来简单实际做起来第一个坑就藏在 PDF 里。很多简历 PDF 是表格排版或者多栏布局直接抽出来的文本顺序是乱的——上一行还在“项目经历”下一行突然跳到“专业技能”再下一行又回到“教育背景”。如果直接把这种乱序文本丢给 LLM 做结构化诊断结果几乎必然不准。我的处理方案分三层用pdf-parse抽原始文本按行切分并保留大致坐标如果有的话。用正则和关键词做“章节边界识别”——比如找到“工作经历”“项目经历”“教育背景”这些常见标题把文本切成块。针对切不好的情况再让 LLM 做一次归一化给定原始文本输出结构化的 JSON用zod校验返回格式不合格就重试一次。第三层是关键兜底。现实中的简历格式千奇百怪完全靠规则不可能覆盖所有情况。让 LLM 做“最后一公里”的归一化比纯规则鲁棒得多。但必须用zod这类库做强校验不能让 LLM 的幻觉污染下游。解析失败时我的策略是重试一次换更详细的指令还失败就明确告诉用户“这份文件格式太复杂请手动填写基本信息”不硬撑。3.2 岗位匹配诊断把 JD 拆成可对比的条件这个节点负责把 JD“翻译”成可对比的条件清单并和简历逐条对照。我把条件分成两大类硬性条件技术栈名称、工作年限、学历、特定框架/工具。这些适合做关键词级对比。软性条件团队协作、沟通能力、架构设计经验。这些需要 LLM 做语义判断。输出的诊断结果我设计成一张差距表每一项包含JD 里的原始描述、拆出的条件、简历中的对应证据、达标状态达标/不足/缺失、改写建议。这张表我直接展示在用户界面上效果出奇地好——用户能直观看到“哪里不行”比一句“整体竞争力一般”可信得多。这里有个实操经验诊断节点输出的结构化数据是整个 Agent 里质量要求最高的我设置了temperature: 0并让模型严格按照 JSON 格式输出。改写节点则可以适当调高温度让表达更灵活。同一个 Agent 里不同节点用不同模型和参数是 LangGraph 这类框架才方便做到的优化。3.3 优化改写一个 Section 一个子图改写是整个流程里最耗 token、也最容易上下文爆炸的环节。最初我把所有工作经历一次性丢给 LLM让它全部重写。结果输出经常偏离原意而且某一条写得好另一条就敷衍。后来我改成“一个 Section 一个子任务”每个工作经历/项目经历单独走一次改写上下文只包含该段原文、JD 相关条件、诊断建议。每次改写的 prompt 骨架大概是你是资深技术招聘官。下面是我的一份工作经历原文和目标岗位要求。 请按 STAR 法则重写这段经历要求 1. 保留全部事实信息不得编造数据 2. 补充可量化的描述占比、规模、性能数字 3. 突出与目标岗位相关的技能关键词 4. 控制在 150 字以内 原文... 目标岗位要求...逐块改写的另一个好处是支持“局部重试”。比如某一段输出格式不对只需要重试那一段而不是让整个 Agent 从头跑。这在成本控制和错误恢复上是质的差别。3.4 渲染导出Markdown 到 PDF 并没有那么简单Agent 跑完的产物是 Markdown但用户要的是 PDF 或 Word。我最终选定的方案是Markdown 先转成 React 组件结构用 Tailwind 的打印样式渲染成 HTML再转 PDF。这里有两个必须处理的细节。一是“一页限制”问题——简历优化完内容变多了经常超出一页。我做的不是简单地通知用户“内容超了”而是在渲染节点里按预设排版模板计算内容长度自动压缩优先级较低的内容比如把某些点从两行压成一行尽量保持一页。二是中文字体问题——服务端缺 CJK 字体是必然的后面部署章节我会展开讲。总之这个模块看似不起眼其实是整个产品“专业感”的最直接体现值得花时间打磨。4. 并发重构让一个 40 秒的 Agent 任务扛住 20 路并发4.1 先定位问题串行调用一个请求占 40 秒第一版上线后我测了一次完整流程心里一凉环节耗时文件上传与解析3~5 s视文件大小JD 分析与差距诊断8~12 s2 次 LLM 调用分块改写18~30 s4~6 个 Section 串行渲染导出2~3 s合计31~50 s一个普通接口 100ms 就超时了我这个接口动辄半分钟。在线用户一多服务器线程池直接被打满。这就是热搜词里“AI Agent 怎么扛并发”的典型问题Agent 的本质是把多个 LLM 调用串起来单次请求耗时比普通接口高一个数量级你不能用传统的“快速响应”思路来设计。4.2 第一层优化SSE 流式输出让请求“活着”我做的第一个改动就是全面改流式。Next.js 的 Route Handler 原生支持ReadableStream我把 Agent 的每个节点完成事件实时推给前端。效果有两层第一层是用户体验——用户能看到“正在解析简历”“正在分析 JD”“正在改写第 2 段经历”焦虑感大幅下降第二层是技术价值——serverless 平台的超时机制通常看“是否有持续返回”流式输出能让长任务不容易被强杀。前端配合也简单用fetch读response.body就可以// 后端 Route Handler 简化版 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 第二层优化队列 状态落库把“等结果”变成“查结果”流式解决的是单个请求的体验但扛不住真正的并发高峰。尤其是当用户量上来之后大量 Agent 任务同时跑LLM 供应商的限流会先把你打趴。我的第二层方案是把任务改成“提交后异步执行”的模式用户提交简历和 JD立即创建一个任务返回任务 ID。后台从队列里取任务逐个执行 Agent 流程。前端轮询或通过 SSE 订阅任务状态。每个节点的中间状态都写入数据库任务中断后可以从最近检查点恢复。队列我用的是BullMQ Redis。任务量大时可以做并发上限控制比如同时最多跑 10 个 Agent 任务剩下的排队。这样虽然单个任务变慢了但系统整体不会被打垮用户体验是“排队中”而不是“请求失败”。这里有一个取舍要讲清楚对于实时交互型的 Agent用户在线等着结果流式响应是首选对于批量处理型的 Agent比如批量优化一批简历队列模式更合适。简历工具两者都要——单份优化用流式批量处理用队列。我实际是把两种模式并存通过一个mode参数切换。4.4 第三层优化限流、重试、模型分流LLM 供应商的限流是所有 AI 应用躲不开的墙。我的处理策略有三条第一指数退避 抖动重试。遇到 429/5xx 错误不能立即重试要按2^n秒递增等待并加上随机抖动避免所有请求在同一时刻重试造成“惊群效应”。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 内模型分流。诊断和结构化输出用便宜快速的小模型改写用更强的大模型。我把不同节点的模型配到 State 里方便随时切换。实测成本能降一半以上质量没有明显变化。第三结果缓存。简历优化是天然带缓存的场景——同一份简历投同一个岗位结果可以直接复用。我按文件哈希 JD 哈希 模型版本做缓存 key命中缓存直接秒出结果。这个优化把并发压力降了一个档次强烈建议做。4.5 优化后的实测数字指标优化前优化后单用户完整流程耗时约 40 s约 30 s流式感知更短支持同时在线执行数5 个就卡稳定 20 个失败率5%超时/限流1%每日 token 成本基准降约 50%这套组合拳打下来并发问题才算真正解决。核心思路总结成一句话能用流式就别用轮询能用缓存就别重复算能用队列就别让请求硬扛。5. 部署上线那些文档里不会写的坑与解法5.1 Serverless 执行时限和长任务的根本冲突我最初图省事把整个应用部署在 serverless 平台上。第一次压测就暴露了问题免费档位的单次执行时长限制只有 10 秒左右付费档位也就几十秒而我的 Agent 单次请求要 30 秒以上。解决路径有两条如果坚持 serverless必须把任务改成“边算边推”的模式保证响应流持续输出并且所有重活通过流式推给客户端。短任务可以这样糊弄过去但长任务仍有风险。更稳的方案是把 Agent 执行部分拆成独立的 Node 常驻服务部署在有固定资源的环境里Next.js 只负责前端页面和 API 入口内部转发给 Agent 服务。我最终选了第二条。在我看来Agent 这种长耗时、高 CPU/内存开销的任务和 serverless 的执行模型天然不对付。不要为了“托管省心”硬把一个不适合的场景塞进不适合的平台。5.2 checkpointer 状态存储内存模式重启就丢LangGraph 的 checkpointer 是断点恢复的关键但默认的内存模式只能在单进程里用。一旦服务重启所有进行中的 Agent 状态全丢。用户刷新页面发现“我的任务没了”体验极差。解决办法是把 checkpointer 换成持久化存储。LangGraph.js 官方支持对接 PostgreSQL 等存储我在 Postgres 里建了一张表存图状态快照。每次节点执行完写入一次重启后从最近检查点恢复。这里有个细节写入频率要控制。每个节点都写没问题因为 Agent 节点数量有限但如果你的图有大量细粒度步骤频繁写库会拖慢整体速度。我的经验是只在“关键节点完成后”做一次持久化而不是每一步都写。5.3 token 成本失控Agent 循环里的“内存泄漏”上线一周后我看账单差点没坐住。问题出在回退机制上每次从diagnose_gaps回到rewrite_sectionsState 里的诊断结果还在增长新的改写请求又把旧的诊断内容带上了。多轮循环后每条消息都带着完整历史成本呈指数上升。我的解法参考了 LangGraph 文档里的消息压缩思路在 State 里加一个“上下文裁剪”逻辑超过一定轮次后不再把全部历史传给 LLM而是只传“最新一轮诊断 最新改写结果 原始简历”前面的轮次只保留摘要。这相当于给 Agent 的历史消息做一次“压缩 GC”。同时我给maxRevisions设硬上限从根上防止无限循环。其他几个成本控制经验一并分享。所有结构化输出用temperature: 0避免无意义的多余输出。长时间运行的 Agent 启用供应商侧的 prompt 缓存。同一份简历的多轮用户操作之间复用已解析的结构化数据而不是每次都重新解析。5.4 最后一道坎PDF 中文字体乱码这是最让我意外的一个坑。本地开发跑得好好的 PDF 导出部署到服务器上后中文全变方块。原因很简单服务器环境没有安装 CJK 字体浏览器在渲染 PDF 时找不到中文字形。解决方案是把常用中文字体打包进应用资源目录渲染时通过 CSSfont-face显式引入。font-face { font-family: NotoSansSC; src: url(/fonts/NotoSansSC-Regular.otf) format(opentype); font-display: swap; }但字体文件通常以 MB 计直接全量打包会让部署包巨大。我最后做了字体子集化——只提取用到的几百个常用汉字生成精简字体文件体积直接压到几十 KB。这一步做完PDF 导出才算真正稳定。最后分享一点个人体会这个项目从第一版“大 prompt 串一切”到最终基于 LangGraph.js 的状态图 Agent我最大的感悟是Agent 应用的门槛不在写代码而在把业务规则翻译成状态图。简历优化的业务规则恰好适合用图表达——有分支、有循环、有人工介入点硬要用线性流程去套就会处处别扭。另一个体会是框架选型真的不用追新。LangGraph.js 在 JS 社区的生态还没有 Python 那边丰富但它的核心抽象足够稳文档也基本覆盖了关键场景。我踩过的坑大多是部署和成本层面的而非框架本身的。如果你正准备做一个多步骤的 AI 工具我的建议很直接先画出业务流程的状态图再从图里反推节点和边最后才轮到写代码。图画清楚了代码只是翻译工作。