LangGraph
Agent、Tool Calling 与自定义工作流
一个工具调用 Agent 通常只做三件事： 这就是经典的 ReAct 式循环在工程上的核心。模型负责决策，运行时负责执行与记录；模型本身并不会直接运行 Python 函数。
返回分类
LangGraph
12 篇文章，按发布时间排列。
LangGraph
Functional API：entrypoint 与 task
Graph API 要显式声明 State、节点和边，适合控制流复杂、需要可视化的系统。但有些现有 Python 程序已经用 if、for、函数调用表达得很清楚，只想增加： Functional API 就是为这种情况准备的。它保留普通
LangGraph
Interrupt：Human-in-the-loop
interrupt() 会让图在节点内部暂停，将一份 JSON 可序列化的请求暴露给外部，并通过 Checkpointer 保存当前位置。外部可以几秒、几小时甚至几天后再提交决定，图使用同一 threadid 恢复。 它适用于外部世界需
LangGraph
LangGraph 实战：GIS 数据处理 Agent
构建一个“GIS 数据质检与发布 Agent”。用户给出一个数据集 URI，系统需要： 这个案例的重点不是具体 GIS 库，而是如何划分确定性代码、模型判断、并行任务、人工决策与外部副作用。
LangGraph
LangGraph 概览与学习路线
LangGraph 是一个用来编排有状态、可循环、可暂停、可恢复任务的运行时。 它并不负责让模型“更聪明”，而是负责让模型与普通代码在一个可控流程里协作：哪一步调用模型、哪一步查数据库、失败后从哪里重试、何时等待人工审批、恢复时沿用哪份
LangGraph
Persistence：Checkpoint、Thread 与时间旅行
没有持久化时，图只存在于当前进程内：程序崩溃、部署重启或等待人工输入，执行上下文都可能丢失。 LangGraph 通过 Checkpointer 在执行过程中保存 State 快照，从而支持：
LangGraph
Reducer、消息状态与并行更新
节点返回的不是完整新状态，而是对某些字段的更新。Reducer 决定一条更新如何与旧值合并： 如果一个字段没有声明 Reducer，默认行为通常是覆盖：
LangGraph
StateGraph：状态、节点与边
StateGraph 可以理解为一个围绕共享状态运行的状态机： 图不是静态的数据处理管道。它可以分支、汇合、循环、暂停并恢复，因此比传统 DAG 更适合 Agent。
LangGraph
Streaming、Subgraph 与多 Agent
Agent 的一次运行可能持续很久。若前端只等待最终字符串，用户无法区分“系统正在工作”和“系统已经卡死”。 LangGraph 可以流式暴露多个层面的信息：
LangGraph
条件路由、Command 与 Send
控制流应选择最简单、最能表达业务意图的方式。能用固定边时，不必使用 Command；只有动态任务数量不确定时，才需要 Send。 给路由函数写 Literal[...] 返回类型，不仅改善类型检查，也能帮助图可视化推断可能目的地。