LangChain 系列：为什么复杂 Agent 最后都要走向 LangGraph？ - 今日头条.md9.0 KBit/ai/LangChain 系列：为什么复杂 Agent 最后都要走向 LangGraph？ - 今日头条.md
--- title: "LangChain 系列：为什么复杂 Agent 最后都要走向 LangGraph？ - 今日头条" source_url: "https://www.toutiao.com/article/7651573205274051110/?log_from=15bec9fb2deec_1782979442930&wid=1782979451563" source_site: "www.toutiao.com" clipped_at: "2026-07-02T08:04:28.120408+00:00" clipper: "aiwiki-url-ingest" extractor: "toutiao_rendered" --- # LangChain 系列：为什么复杂 Agent 最后都要走向 LangGraph？ - 今日头条 # 一、LangGraph 不是更花哨，而是更可控 简单 Agent，靠一个模型循环调用工具就够。 复杂 Agent，不能只靠模型自由发挥。 因为真实业务不是聊天。真实业务有流程、有状态、有分支、有审批、有失败恢复。 **LangGraph 的本质：把 Agent 从“黑盒循环”拆成“可控状态机”。** 你可以把它理解成：Spring 负责业务工程，LangChain 负责模型组件，LangGraph 负责复杂 Agent 编排。 # 二、普通 Agent 的天花板在哪里？ 普通 Agent 的核心模式很简单：模型判断下一步，模型决定调哪个工具，工具结果再塞回模型。 这个模式适合 Demo。也适合标准工具调用。 但一旦业务复杂，问题就来了。 普通 Agent Loop 的问题不是不能跑，而是跑复杂了难控制 第一个问题：流程不可控。模型可能多查、漏查、乱跳。 第二个问题：状态不清楚。上一步结果散落在 messages 里，业务字段很难治理。 第三个问题：失败难恢复。任务跑到一半崩了，普通 Agent 很难从中间继续。 第四个问题：人工介入困难。审批、驳回、修改、继续执行，都不是一个 Prompt 能优雅解决的。 所以复杂 Agent 最终要走向图。 # 三、LangGraph 一句话讲明白 **LangGraph \= State \+ Node \+ Edge \+ Runtime。** State：当前任务的状态。 Node：每一步要做的事。可以是 LLM，可以是 RAG，可以是 Tool，也可以是人工审批。 Edge：下一步往哪里走。可以固定跳转，也可以条件判断。 Runtime：把整个图运行起来，并支持流式、持久化、中断、恢复。 LangGraph 的四个核心抓手：State、Node、Edge、Runtime 普通 Agent 是“模型自己决定怎么走”。 LangGraph 是“开发者把路画出来，模型只在该决策的地方决策”。 这就是工程化差异。 # 四、StateGraph 到底在干什么？ 先抓主线，不看细枝末节。 StateGraph 不是运行器。 StateGraph 是 builder。 它负责收集节点、边、状态 schema、条件分支、通道和 reducer。 真正能运行的是 compile() 之后的 CompiledStateGraph。 # 1\. StateGraph 初始化 创建 builder。 内部会准备几个核心容器：nodes 存节点，edges 存固定边，branches 存条件分支，channels 存状态通道。 同时会解析 State schema。哪些字段能更新，怎么合并，都会在这个阶段准备好。 # 2\. add\_node 注册节点 节点本质就是函数或 Runnable。 LangGraph 不关心这个节点里面是 LLM、数据库、搜索、人工审批还是普通 Python 逻辑。 它只关心一件事：这个节点读入 State，返回 Partial State。 # 3\. add\_edge / add\_conditional\_edges 注册路线 固定边：A 执行完就去 B。 条件边：A 执行完，根据状态判断去 B、C，还是 END。 这一步就是把“业务流程”从 Prompt 里拿出来，变成真正的程序结构。 # 4\. compile 变成可执行图 compile 会做结构校验。 比如有没有孤立节点，入口和出口是否合理，分支目标是否存在。 然后把 builder 变成 CompiledStateGraph。 这一步之后，才有 invoke、stream、ainvoke 这些执行能力。 # 五、运行时逻辑：为什么它能处理复杂流程？ LangGraph 的执行不是一条死链。 它更像消息传递。 节点被激活，读取当前状态，执行自己的逻辑，写回状态更新，再通过边把控制权交给下一个节点。 每个节点不要返回整份 State。 只返回自己改动的部分。 然后 LangGraph 根据 reducer 合并。 这很关键。 因为复杂 Agent 经常会出现并行节点、多个结果、列表追加、消息合并。没有 reducer，状态会互相覆盖。 # 六、复杂 Agent 为什么最后会走向 LangGraph？ # 原因 1：业务流程需要显式化 企业系统不接受“模型觉得应该这么做”。 企业系统需要知道：当前在哪一步，下一步是谁，失败后怎么办。 LangGraph 把这些流程显式画出来。 # 原因 2：状态需要结构化 复杂任务不能只靠聊天记录。 订单号、用户 ID、风险级别、审批结果、召回文档、工具返回值，都应该进入 State。 消息是上下文。State 才是业务状态。 # 原因 3：失败需要恢复 真实系统会超时，会报错，会中断。 LangGraph 可以通过 checkpointer 保存线程状态。 任务跑一半失败，下次能从 checkpoint 继续。 # 原因 4：人工需要介入 退款、转账、删除数据、修改合同、下单交易，这些都不能让模型直接执行。 LangGraph 的 interrupt 可以暂停图，等待人工审批，再继续执行。 # 原因 5：排查需要可观测 复杂 Agent 出错时，必须定位是哪一步错了。 是路由错？检索错？工具参数错？模型生成错？ 图结构让每一步都能追踪。 # 七、用智能客服看一眼：LangGraph 怎么落地？ 智能客服不是“用户问，模型答”。 它至少要做意图识别、知识库检索、业务查询、风险判断、人工审批、答案质检。 一个节点只做一件事。 意图识别节点只负责分类。 RAG 节点只负责查资料。 工具节点只负责调业务接口。 人工节点只负责审批。 质检节点只负责拦截风险答案。 这样系统才可控。 # 八、什么时候该用 LangGraph？ 不要为了用 LangGraph 而用 LangGraph。 简单任务，上图反而增加复杂度。 判断标准如下。 **只要你的 Agent 出现分支、循环、状态恢复、人工审批、多 Agent 协作，就应该考虑 LangGraph。** # 九、企业级架构：Java 管业务，LangGraph 管流程 对 Java 后端来说，最稳的方式不是把所有 AI 逻辑塞进 Java。 更推荐：Spring Boot 做业务主服务，Python FastAPI 做 AI 服务，LangGraph 放在 AI 服务内部。 Java 负责用户、权限、订单、资金、配置、审计。 Python 负责模型、RAG、工具封装、Agent 编排。 LangGraph 负责复杂流程。 LangSmith 或自建 Trace 负责观测和评测。 # 十、总结 **1\. 定义 State：明确任务过程中要保存哪些字段。** **2\. 创建 StateGraph：拿到一个图 builder。** **3\. add\_node：把每一步业务逻辑注册成节点。** **4\. add\_edge：把确定流程连起来。** **5\. add\_conditional\_edges：把分支、循环、路由连起来。** **6\. compile：检查结构，生成可执行图。** **7\. invoke / stream：运行图，逐步更新状态。** **8\. checkpoint / interrupt：让长任务能保存、暂停、恢复。** **LangGraph 不是替你写业务逻辑。它是让复杂 Agent 的业务逻辑有结构、有状态、有边界。** --- 下一章，我们正式进入 LangGraph 基础：Node、Edge、State 到底是什么。