LangGraph（智能体状态图框架）
先用一句话说清楚
LangGraph（智能体状态图框架）是用状态图方式组织复杂 AI Agent（人工智能体）流程、循环、条件分支和多智能体协作的框架。
新手通俗解释
简单 Agent（智能体）可以是一条直线：用户提问、模型回答、结束。但真实任务经常不是直线：先判断类型，再检索资料，可能调用工具，可能失败重试，可能转人工，可能进入另一个 Agent（智能体），最后还要汇总结果。
LangGraph（智能体状态图框架）更像一张流程地图。每个节点负责一件事，比如“理解任务”“检索资料”“调用工具”“检查风险”“生成答案”。边负责决定下一步，比如“资料不足就追问”“高风险就转人工”“工具失败就降级”。
为什么智能体工程师岗位会问它
岗位提 LangGraph（智能体状态图框架），通常是在考察你是否能处理多步骤、多分支、有状态的 Agent（智能体）系统，而不是只会写单轮问答。
常见考察点：
| 考察点 | 应该怎么讲 |
|---|---|
| 状态图思维 | 把复杂流程拆成节点、边和状态 |
| 状态管理 | 每一步要读写哪些事实 |
| 循环控制 | 防止模型无限循环或重复调用工具 |
| 人工介入 | 高风险或低置信任务如何暂停和转交 |
| 多智能体 | 多个 Agent（智能体）如何协作、汇总和仲裁 |
它在项目里到底怎么用
以“多智能体任务协作系统”为例，可以设计这样的节点：
| 节点 | 职责 |
|---|---|
| 任务入口 | 接收用户目标，生成初步任务说明 |
| 任务拆解 | 判断需要哪些子任务 |
| Supervisor（监督者） | 决定由哪个 Agent（智能体）处理 |
| RAG（检索增强生成）节点 | 检索资料和引用来源 |
| Tool Calling（工具调用）节点 | 调用受控业务工具 |
| 风险检查 | 判断是否需要人工确认 |
| 汇总生成 | 把各节点结果合成最终输出 |
| 失败兜底 | 处理超时、无证据、工具失败和权限不足 |
状态里要保存任务目标、当前步骤、已获得证据、工具结果、失败次数、风险等级和 Trace ID（追踪编号）。没有状态，流程就会变成一堆散乱调用。
和普通工作流的区别
普通 Workflow（工作流）通常规则更固定；LangGraph（智能体状态图框架）适合把模型判断、工具调用、循环和条件分支放进一个可控图结构里。它不等于“让模型自由发挥”，而是把模型能力限制在明确节点和边里。
面试时可以说：我用状态图不是为了炫框架，而是为了让复杂 Agent（智能体）流程可读、可测试、可恢复。
常见误解
| 误解 | 为什么不对 | 正确理解 |
|---|---|---|
| 用了 LangGraph（智能体状态图框架）就高级 | 框架不能代替流程设计 | 关键是节点、状态和边界 |
| 所有 Agent（智能体）都要用状态图 | 简单问答不一定需要 | 复杂流程再引入 |
| 图越复杂越强 | 复杂会增加维护和调试成本 | 节点要围绕业务闭环设计 |
| 循环越多越智能 | 循环可能失控和耗费成本 | 要有停止条件和失败次数限制 |
面试官可能怎么追问
1. 什么时候需要 LangGraph（智能体状态图框架）？
考察点： 是否懂适用场景。
参考回答： 当任务包含多步骤、条件分支、工具调用、失败重试、人工确认、多 Agent（智能体）协作或需要持久状态时，我会考虑 LangGraph（智能体状态图框架）。如果只是简单问答，用普通流程就够了。
容易扣分： 说“现在 Agent（智能体）项目都必须用 LangGraph（智能体状态图框架）”。
2. 状态图里状态应该保存什么？
考察点： 是否理解可恢复流程。
参考回答： 我会保存任务目标、当前节点、用户已确认信息、检索证据、工具结果、风险等级、失败次数、待人工确认动作和 Trace ID（追踪编号）。状态要保存事实，不保存一大堆无关对话。
容易扣分： 把完整聊天记录当状态。
3. 怎么防止 Agent（智能体）无限循环？
考察点： 是否有生产环境意识。
参考回答： 我会设置最大步骤数、最大重试次数、工具调用上限、成本上限、明确停止条件和失败兜底。循环必须有退出边界，不能让模型一直“再试一次”。
容易扣分： 只相信模型自己会停。
作品集里怎么展示它
作品集可以展示一张状态图：
- 每个节点的职责。
- 节点之间的条件跳转。
- 状态里保存哪些字段含义。
- 哪些节点可能调用工具或检索资料。
- 哪些情况转人工或终止。
这比只写“使用 LangGraph（智能体状态图框架）实现多智能体”更能体现架构能力。