上一篇给了 StateGraph 五要素全景。这一篇深入第一个——State。
State 是图的血液。一个 Agent 跑起来，它的对话历史、当前任务、中间结果，全装在 state 里。节点们通过读写同一个 state 来协作。理解 state 怎么定义、怎么流转，是理解一切 LangGraph 应用的前提。
State 是什么：一个跨节点的共享数据结构
最直白的理解：State 是一张图里所有节点共享的数据结构。每个节点能读它、能改它，改完传给下一个节点。
你可以把 state 想象成一次「对话的上下文对象」——它记录着这次交互从头到现在的所有信息。节点不需要互相传参，都从 state 取数据、往 state 存结果。
State 的典型字段
一个 Agent 的 state 通常包含两类字段：
第一类：消息列表（messages）——这是 state 的核心。对话历史就装在这里，每个节点（调模型、执行工具）都会往里加消息。模型每次被调用，看到的就是这个列表。
第二类：业务字段——和具体任务相关。比如：
| 字段 | 装什么 | 谁来读写 |
|---|---|---|
messages |
对话历史 | 几乎所有节点 |
task |
当前任务描述 | 入口设置，各节点读 |
docs |
已检索到的资料 | 检索节点写，模型节点读 |
tool_results |
工具执行结果 | 工具节点写，模型节点读 |
iteration |
当前循环次数 | 用于控制最大轮次 |
消息列表是通用的（任何对话型 Agent 都有），业务字段是因任务而异的。设计 state 时，先想清这次任务有哪些信息要在节点间传递，就是 state 该有的字段。
为什么消息列表是核心
为什么 messages 这么重要，几乎是每个 state 的标配？
因为模型是无状态的。模型本身不记得上一轮说了什么——它每次被调用，只看你这次传给它的消息列表。所以「Agent 的记忆」，本质上就是维护并不断追加这个 messages 列表，每次调模型时把它整个传过去。
这就是为什么 state 把 messages 放在最中心：它是模型「看到世界」的唯一窗口。第 35-37 篇讲记忆时会展开——所谓记忆，归根到底就是对 messages 这个字段的增删改。
State 怎么流转
一个节点执行时，state 的流转是这样的：
- 节点读当前 state（拿到 messages、task 等）
- 节点做事（调模型、检索、执行工具）
- 节点返回更新（比如往 messages 加一条新消息）
- 框架按 reducer 规则，把更新合并进 state
- 下一个节点拿到更新后的 state
注意第 4 步——节点返回的不是「新 state」，而是「更新」。合并成什么样由 reducer 决定（下一篇 Node 会细讲，第 13 篇专讲 reducer）。这种「返回更新而非全量」的设计，让节点只关心自己改了什么，不用管整个 state。
State 设计的一个原则：少即是多
设计 state 时容易犯的错是「什么都往里塞」。但 state 字段越多，节点间的耦合越紧——每个字段都可能被多个节点读写，字段一多，谁改了什么、影响哪里，就难追踪。
一个原则：state 只放「确实需要在节点间传递」的信息。一个信息如果只在一个节点内部用，做成节点内的局部变量，不要进 state。state 是「公共黑板」，不是「垃圾桶」。
收束：State 是协作的媒介
这一篇讲了 State：
- 它是所有节点共享的数据结构，是图的血液
- 核心字段是消息列表（messages），业务字段因任务而异
- 模型无状态，记忆本质是维护 messages
- 节点返回更新，框架按 reducer 合并
- 设计原则：只放真正需要跨节点传递的信息
下一篇讲 Node 和 Edge——state 的「读写者」和它们之间的「路」。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
