# LLM 多步调用想收成一张图，LangGraph 官方入门现在落在哪？

**URL:** <https://www.shiqidu.com/t/topic/2002>\
**Category:** 人工智能\
**Tags:** 问与答, Python, 开源软件, API, AICoding\
**Created:** [2026 年11 月 9 日 12:46 UTC](https://www.shiqidu.com/t/topic/2002 "2026-11-09T12:46:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年11 月 9 日 12:46 UTC](https://www.shiqidu.com/t/topic/2002/1 "2026-11-09T12:46:32Z")

</div>

Agent 流程一旦超过「问一句、调一次工具」，代码里就容易散成一串 `if` 和嵌套 `await`：要不要再问模型、失败了回哪一步、状态塞在哪个字典里，全靠约定。想把控制流画成图再跑时，会碰到 [LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)。旧书签若还停在 `langchain-ai.github.io/langgraph/tutorials/introduction/`，打开后会跳到现在的文档域。入口落在 `docs.langchain.com` 的 overview，动手示例则在同站的 [quickstart](https://docs.langchain.com/oss/python/langgraph/quickstart)。

## 官方把它放在哪一层

overview 给自己的定位是：面向长时间、带状态的 Agent 的底层编排框架与运行时。工作流用 **共享状态、节点、边** 组成的图来描述，同一张图里可以混确定性步骤和由模型驱动的步骤。它强调持久执行、流式输出、人机回环这类编排能力， **不** 规定提示词写法，也 **不** 强推某一种 Agent 架构。文档举例常借用 LangChain 的模型 / 工具集成，但写明 LangGraph 并不强制依赖 LangChain。

若只想先要一个更高层的 Agent 循环，官方会指向 Deep Agents 或 LangChain agents。需要显式控制状态与控制流时，再落到 LangGraph。产品关系上，LangGraph 是编排运行时，LangSmith 负责追踪、评估与部署观测。入门阶段先分清「图怎么跑」和「调用怎么观测」即可。

## 最小图长什么样

overview 里的最小示例用 `StateGraph`、`MessagesState`、`START` / `END`：加一个节点、两条边，`compile()` 之后 `invoke`。心里模型可以记成：状态进图 → 节点改状态 → 边决定下一步。quickstart 则把同一套 Graph API 做成计算器 Agent：先声明工具并 `bind_tools`，再定义状态（消息列表 + 调用计数），然后分别实现「调模型」节点和「执行工具」节点，用条件边决定是继续进工具节点还是结束。

安装侧 overview / quickstart 都给了 `pip install -U langgraph`（以及 `uv add`）一类入口。quickstart 示例还会装 `langchain`、`langchain-anthropic` 以便接聊天模型。模型字符串、默认提供商回文档页核对，正文不写死某一个会过期的快照号。跑通之后，文档指向持久化（checkpointer）、人机回环（interrupt）、流式输出等下一层能力，不必第一天全接。

## 节点、边、条件边分别干什么

对照 quickstart 的计算器例子，心智可以拆成三块：节点是「干一件事」（调模型、跑工具、写死一段校验）。普通边是「做完 A 一定去 B」。条件边根据状态里的字段（例如最后一条消息有没有 `tool_calls`）在「再进工具节点」和「结束」之间选路。状态用 TypedDict 一类结构声明后，节点返回的是对状态的增量更新。消息列表常用注解做成追加而不是整表覆盖，避免后一步把前序对话抹掉。

第一张图不必上多 Agent。把现有「模型 → 工具 → 再模型」收成两个节点加一条条件边，往往就比继续堆嵌套 `await` 好维护。持久化、人机审批、跨会话记忆都是图能跑通之后的加项，overview 把它们列在 capabilities 里，按需点进去即可。

## 密钥和数据边界先于「图好不好看」

quickstart 前提是：你已经有某个模型提供商的 API key，写在环境变量或本地 `.env`， **不要** 写进仓库、更不要硬编码进节点函数。工具节点会执行模型选中的调用。若工具能碰文件、数据库或内网接口，权限应和普通后端任务同一套闸门，而不是「图编译成功了就等于安全」。站内此前写过工程侧两篇，可对照一句、不复述正文：循环与费用要用进程内熔断，而不是只写在 Prompt 里（见 [Agent 熔断与次数上限](https://www.shiqidu.com/t/topic/1966)）。外部模型进业务仓要先谈代码边界与审批（见 [外部模型与代码边界](https://www.shiqidu.com/t/topic/1967)）。

LangGraph 帮你把控制流收干净，不替你决定「工具能不能删库」「密钥放哪」。灰产爬取、打穿沙箱、绕过鉴权之类不在本文范围。合法业务里，把工具做成最小权限、把密钥留在运行环境，比先追求复杂多 Agent 拓扑更要紧。

若你们已经有一堆散落的 `await llm` + `await tool`，可以先在纸上画出「状态里有什么、有哪些节点、条件边怎么走」，再对照 overview 的最小图和 quickstart 的工具循环，看差的是编排还是业务规则本身。

你们现在卡在「状态该怎么建模」，还是「条件边不知道何时结束」？