面试题 · Agent
搜索「AI Agent 设计」匹配到追问内容，相关段落已展开。查看匹配内容 ↓
LangGraph相比传统顺序执行的Agent框架，在哪些典型应用场景中更具优势？请结合其基于有向图的状态机特性进行说明。
LangGraph的本质是将Agent执行建模为有向状态图，节点是计算单元（LLM调用/工具执行），边控制流转逻辑。相比只实现顺序调用的编排示例，关键差异在于下表。ReAct是交替推理与行动的迭代方法，不是线性框架；可在LangGraph或其它执行循环中实现：
| 特性 | 简单顺序编排示例 | LangGraph |
|---|---|---|
| 执行流 | 线性或简单分支 | 任意有向图，支持循环 |
| 状态管理 |
学习内容与项目面试，在同一条路上。
| 需自行选型/实现 |
| 显式state；配置checkpointer与存储后可持久化恢复 |
| 人机交互 | 取决于实现 | 支持interrupt；恢复需处理节点重执行与副作用 |
场景：代码生成-测试-修复的闭环
[生成代码] → [运行测试] → {通过?}
↓否
[分析错误] → [修复代码] → [生成代码]...传统框架难以表达"失败则回到上游节点"，LangGraph的循环边天然支持这种迭代优化模式。
场景：智能客服升级策略
[意图识别] → [简单问题]→[直接回答]
↘ [投诉] → [情感分析] → {严重?}
↓是
[人工介入] ← 人工节点可暂停、恢复
↓否
[自动处理]条件边（conditional edges）允许基于状态动态路由，且interrupt机制实现人机协同。
场景：研报生成Agent（耗时数分钟，涉及20+工具调用）
LangGraph适合"需要循环、需要等待、需要人参与、需要容错"的复杂Agent系统，将控制流从"写死"变为"可编程"。
建议系统学习该知识点
场景切入
假设你在做一个智能客服升级流程，用户投诉后，如果情绪检测到愤怒，需要转人工，人工处理完后可能还要回到自动流程。传统的顺序Agent框架写这种分支和循环会很别扭，你经验里觉得LangGraph这种图结构是不是更合适？
层层追问
你觉得Agent框架用顺序执行够用吗？……那如果任务需要根据结果反复重试某个步骤呢？……再比如要支持人工在中间介入，然后继续自动执行，这怎么设计？……好，其实LangGraph的图模型正好解决这些，你能具体说说它比传统框架强在哪吗？
直球架构
直接说说LangGraph相比传统顺序框架的核心优势，结合有向图状态机，举几个典型场景，比如循环迭代、多路径决策、状态持久化这些。
我觉得这道题问得挺核心的，LangGraph相比传统顺序框架，优势在哪，本质就是问什么时候需要把[[Agent]]执行从一条直线变成一张图。嗯，我理解LangGraph的核心是把Agent的每一步都建模成有向图里的节点，节点是LLM调用或者工具执行，边控制怎么流转。ReAct是交替推理和行动的迭代方法，并不等于线性框架；LCEL组合Runnable。这里应与只实现顺序调用、未加状态恢复的编排示例比较。那区别在哪呢，我直接说场景。
先看一个最典型的场景，需要循环迭代的任务。举个例子，代码生成、测试、修复这个闭环。传统框架你写一段代码，跑测试，失败了，你想让它回去改代码，重新生成再测，这个循环很难表达，你得在外面套个循环逻辑。但LangGraph天然支持循环边，你可以在图上画一条从测试节点失败出口指回生成节点的边，状态机自己就知道失败了就回去重来。这个在自动化代码修复、内容审核反复修改这些场景特别有用，循环不是异常，是核心流程。
再看另一个场景，需要人介入的审批工作流。比如智能客服，用户进来先意图识别，简单问题直接回答，投诉就要走情感分析，如果情绪严重就转人工。这里有个关键点，人工节点不是调个API就完事，它可能需要等人工处理完再继续，中间可能暂停几小时甚至几天。LangGraph的interrupt结合checkpointer、thread_id和存储可以暂停等待并恢复；节点起点可能重执行，暂停前副作用要幂等/独立记录，不能仅据框架名保证状态永不丢。传统框架要么不支持暂停，要么你得自己写状态持久化。所以像客服升级、合同审批、风控人工复核这种，LangGraph就合适。
还有一类场景，长周期多步骤任务的状态恢复。我举个例子，生成一份行业研报，可能要调用二十多个工具，查数据、做分析、写报告，整个过程可能跑几分钟。没有实现状态持久化的链可能从头重跑；其他框架也能设计恢复机制。LangGraph配置持久化后按superstep存state，可复用已保存任务写入，但当前未完成节点可能重执行，仍需核对副作用。而且你还能回头看每一步的执行轨迹，调试起来方便很多。这个对线上服务特别重要，容错和可观测性是生产环境必须的。
不过我得说清楚边界，不是所有场景都适合用图。如果任务就是简单的顺序执行，比如用户问天气，调个API返回，你用LangGraph反而重了，线性框架比如LCEL更轻量，调试也更直观。真正落地时往往是混着用的，简单任务用线性，复杂任务用图，或者把图嵌在线性框架里作为子流程。
这里有个前提，LangGraph的优势要发挥出来，你的状态管理得设计好，节点之间的数据传递要清晰，不然图一复杂，状态流就乱。常见失败场景就是节点之间传了太多无用数据，或者状态更新逻辑写错了，导致恢复时数据不一致。所以我上线会特别关注checkpoint的完整性，以及每个节点只读写它需要的状态，避免全局状态污染。
另外我补充一个点，LangGraph的图结构虽然灵活，但图的拓扑复杂度本身也是风险。如果图里有环，要小心死循环，比如代码修复场景如果一直修复不好，得加一个最大迭代次数来终止。这个在传统线性框架里反而不容易遇到，因为线性执行天然有结束。
所以我会把LangGraph看成复杂Agent的控制层，它负责编排流程、管理状态、处理异常，而每个节点里具体干什么，还是用传统的LLM调用和工具执行。我更倾向在需要循环、需要人工介入、需要容错的地方用图，其他地方保持线性，这样既灵活又不至于过度设计。