【AI面试八股文 Vol.1.1 | 专题3：State Schema 设计】State Schema设计：TypedDict / Pydantic类型约束

某场一线大厂 AI 后端岗的技术面进行到第 42 分钟，面试官突然在共享屏幕里敲下一行字："你项目里的 State Schema 用什么定义？为什么要这样选？

"坐在摄像头另一头的候选人愣了一下------这个问题没在任何 LeetCode 热题里出现过，手里的笔记也只记了寥寥两行。

但对 LangGraph 稍有研究的人来说，这道题几乎是 2026 年 Agent 开发岗面试的标配开场白了。

State Schema 的设计问题，正在从"你知道这回事吗"演进成"你是怎么判断的"。

面试官不只是在确认你会写代码，他们想看到的是：你在真实项目里有没有被类型约束坑过，有没有在 Schema 设计阶段就考虑过可观测性，有没有在简单场景和复杂协作之间做过取舍。

这些判断力，不是背几个 API 就能装出来的。

这篇文章的最终目的不是让你记住 TypedDict 和 Pydantic 的语法------那些官方文档里全都有。

我要做的是帮你把这两个工具放到 LangGraph 状态机的上下文里，让你在面试现场从"能跑"直接切换到"能讲"，而且讲出工程判断力。

一、为什么面试官开始问 State Schema 设计

岗位信号：Agent 开发岗从概念期进入招聘落地期

2026 年的 Agent 开发招聘市场有一个显著变化：岗位描述里不再只写"了解 LLM"或"有 RAG 项目经验"，而是开始出现"熟练掌握 LangGraph / LangChain 状态机设计""能设计多 Agent 协作的状态分片方案"这类具体要求。

这个转变背后有一个朴素的原因------企业招人不再是让人来"学" LangGraph，而是让人来"用" LangGraph 解决真实业务问题。

LangGraph 的核心抽象是状态和节点，State Schema 则是这两个抽象的粘合剂。一个设计糟糕的 State Schema，会让整个工作流的调试成本翻倍；

而一个好的 State Schema，应该让任何一个新加入的工程师在读完 schema 定义之后，立刻知道整个 Agent 系统在处理什么数据、节点之间传递什么信息。

这就是面试官开始在这道题上投入时间的经济学解释。

从 AI Engineering Field Guide 的面试题库更新频率也能看出这个趋势：2026 年第一季度新增的 Agent System Design 面试题中，State Schema 相关的追问路径从 1 条扩充到了 4 条，涵盖字段设计、类型选型、状态持久化和 human-in-the-loop 四个方向。

这道题在筛什么：不是语法，是类型约束边界的工程判断力

面试官在问 State Schema 设计时，通常不会直接问"TypedDict 怎么写"------那是文档能解决的事情。他们更常见的问法是：

• "你们项目里为什么选了 Pydantic 而不是 TypedDict？"

• "如果现在要给这个 State 加一个新字段，要注意什么？"

• "State 里字段越来越多，你们怎么保证可观测性？"

• "多 Agent 协作时，你们怎么拆分 State 的归属？"

这些问题有一个共同内核：它们没有标准答案。TypedDict 能跑，Pydantic 也能跑，但"什么时候用哪个、为什么这样用、用错了代价是什么"，才是一道好面试题真正的筛选维度。

面试官：这个设计选择背后，你是怎么思考的？

当前市场数据锚点

在正式开始之前，先给这道题一个市场定位：

维度	数据
AI Engineering Field Guide GitHub Stars	2764（2026年3月，2026-03-27 最后更新）
牛客网 2026年4月 Agent 岗位讨论热度	同比上涨约 25%（对比 2025年Q4）
LangGraph 官方文档 State Schema 章节	占据核心章节 14.2，篇幅超过 6000 词
OpenAI Careers Agent 相关岗位 JD 出现 Schema 关键词频率	2026年Q1 较 2025年Q4 增长约 20%

这些数字告诉你一件事：State Schema 不是 LangGraph 的边角知识，而是进入生产级 Agent 开发的门槛之一。不管你现在是学生还是工程师，这道题的准备优先级应该往前挪。

二、State Schema 的本质：LangGraph 状态机的数据中心

状态机架构视角：State = 数据中心，Node = 执行单元

LangGraph 的架构可以用一句话总结：节点（Node）负责执行，数据（State）在节点之间流动。

这和 React 里的 state management 有几分相似，但 LangGraph 的 State 承载的是整个工作流的中间结果，而不仅仅是 UI 状态。

在 LangGraph 的语境里，State Schema 是整个状态机的数据类型契约。它定义了：

• 有哪些数据字段：例如调研结果（research_data）、文章草稿（draft）、校对意见（review_comment）

• 每个字段的类型：字符串、布尔值、列表还是自定义对象

• 每个字段的默认值和校验规则：Pydantic 模式下 Field description 还会被 LangSmith 追踪

当一个节点执行完毕后，它必须返回修改后的 State 对象。这个返回值的结构必须与 Schema 一致，否则 LangGraph 在编译阶段就会报错。

换句话说，Schema 是节点之间的事实上的接口协议（Interface Contract）。

State 与节点的关系：节点修改状态，数据在节点间传递

来看一个最简化的交互模型：

正文图解 1

这个模型揭示了一个关键约束：节点不持有数据，只修改状态。

如果你在节点内部试图创建临时变量来"绕过" Schema 约束，这在工程上是可以的，但从可观测性角度来看，你的中间状态对 LangSmith 是不可见的，出了 bug 只能靠 print 大法。

为什么需要一个 Schema：类型安全、可观测性、团队协作

Schema 存在的理由有三层，分别对应三个工程问题：

第一层：类型安全。LangGraph 在编译时会对节点返回的 State 进行结构校验。

如果你在 schema 里定义了 is_approved: bool，但某个节点不小心返回了 is_approved: "yes"（字符串），编译阶段就会抛出 InvalidOutputError。

这个机制让类型错误从运行时提前到了编译时，大幅减少线上故障。

第二层：可观测性。使用 Pydantic 的 Field description 时，这个描述会通过 LangSmith 自动出现在追踪记录里。

你可以理解为给每个状态字段写了一行文档，而这行文档会在调试面板里直接显示。相比之下，TypedDict 的类型注解不会自带 human-readable description。

第三层：团队协作。在一个多人参与的项目里，Schema 就是团队成员之间的隐式协议。

当新成员想知道"这个工作流里有哪些数据在流动"，他只需要读一遍 State 定义，而不是去翻遍所有节点的源码。

新同事：所以这个 State 里的 draft 字段是谁负责填充的？

三、TypedDict 定义方式：灵活但无校验，适合原型和简单场景

语法结构与代码示例

TypedDict 是 Python 3.8 引入的标准库语法，用来定义结构化字典的类型注解。它本身不携带任何运行时行为，只是类型检查器（Pylance、mypy）的提示信息。

from typing import TypedDict

class WritingState(TypedDict):
    topic: str
    research_data: str
    draft: str
    review_comment: str
    is_approved: bool

这就是一个完整的 TypedDict State Schema。没有任何默认值，没有任何校验逻辑，Python 解释器在运行时会把它当成普通 dict 来处理。这意味着：

• WritingState(topic="LangGraph", research_data="...", draft="...") 语法上是合法的

• 但 WritingState(topic=123, is_approved="yes") 运行时也不会报错------类型检查器在 IDE 里会标红，但程序照跑不误

无参数校验的工程代价

这个"照跑不误"的特性，在原型阶段是优势，在生产环境里就是定时炸弹。

举一个真实的翻车场景：某个团队在开发一个多 Agent 协作的客服工作流时，用 TypedDict 定义了 State Schema，其中一个字段是 customer_tier: int（客户等级，1-5）。

在单 Agent 模式下，节点 A 总是正确地填充这个字段。

后来新增了一个节点 B 做降级处理，这个节点在某些条件下会把 customer_tier 设成 0------而这在业务逻辑里是一个非法值。

但因为 TypedDict 没有校验，程序跑了一个星期才发现：等级为 0 的客户拿到了不应该有的折扣。

线上故障：客户等级 0 是什么鬼？

适用场景判断

TypedDict 的最佳使用窗口是：原型验证阶段 ，或者状态字段数量 ≤ 5 且每个字段的取值完全由 LLM 输出决定、不涉及复杂的业务规则校验的场景。

在这个窗口里，TypedDict 的低学习成本和零迁移负担是真实优势。

一旦你的状态需要：

• 对取值范围做约束（例如等级必须在 1-5 之间）

• 对非空字段做强制校验

• 提供 human-readable 的 Field description 供 LangSmith 追踪

TypedDict 的局限就会逐一暴露。这种时候迁移到 Pydantic，代价通常在两小时以内，但省下的调试时间是十倍以上。

模板答案：TypedDict 面试复述版

"TypedDict 是 Python 标准库提供的结构化类型注解方式，本身不携带运行时校验。在 LangGraph 里它适合原型阶段和简单场景，优点是零依赖、学习成本低，缺点是类型错误只能在 IDE 里看到，运行时不保真。如果我们在面试题里选 TypedDict，我会优先用于单 Agent、字段不超过五个、且所有字段取值完全由 LLM 决定、不涉及业务规则校验的场景。一旦状态里有需要约束的取值范围或者需要给后续调试留可观测性，我建议直接上 Pydantic。"

四、Pydantic 定义方式：结构化带校验，适合生产环境和复杂 Agent

BaseModel + Field 语法结构

Pydantic 是 Python 生态里最流行的数据验证库之一，它通过 BaseModel 和 Field 装饰器提供了完整的运行时校验能力。

在 LangGraph 的 State Schema 场景下，Pydantic 的优势体现在三个方面：字段级描述、运行时校验、以及与 LangSmith 的天然集成。

from pydantic import BaseModel, Field

class WritingState(BaseModel):
    """写作 Agent 的状态定义"""
    topic: str = Field(description="写作主题，用户提供")
    research_data: str = Field(default="", description="调研 Agent 输出的核心资料")
    draft: str = Field(default="", description="写作 Agent 输出的文章草稿")
    review_comment: str = Field(default="", description="校对 Agent 输出的修改意见")
    is_approved: bool = Field(default=False, description="校对是否通过，布尔值")
    revision_count: int = Field(default=0, ge=0, le=10, description="修改轮次，最多10轮")

这个定义里，每一行 Field 都在做三件事：

1. 提供默认值 ：default="" 或 default=False 让你在初始化状态时不用逐字段填充

2. 约束取值范围 ：ge=0, le=10 对 revision_count 做了上下界约束，传入 -1 或 11 会在运行时立刻抛出 ValidationError

3. 写入 human-readable description：这个 description 会自动出现在 LangSmith 的追踪面板里，让你在调试时一眼就知道每个字段的业务含义

Field description 的可观测性价值

这里值得单独展开一下，因为 Field description 的价值在面试里经常被低估。

LangSmith 是 LangChain/LangGraph 官方提供的调试和追踪平台。

当你在 Pydantic Field 里写了 description 之后，LangSmith 会把这个描述作为该字段的 label 在追踪面板里显示。这意味着：

• 你不需要打开源码就知道 revision_count 是"修改轮次"

• 你不需要查文档就知道 is_approved 是"校对是否通过的布尔值"

• 当状态在节点之间传递时，你看到的不是裸字段名，而是带业务语义的描述

对比一下：如果用 TypedDict，LangSmith 里看到的字段全是裸 key（research_data、draft），调试时你需要不断在源码和面板之间来回跳转。

这在单 Agent 简单场景里问题不大，但在多 Agent 协作的复杂工作流里，这种认知负担会显著拖慢排障速度。

参数校验与异常处理

Pydantic 的校验在节点执行前就会触发。

来看一个实际场景：假设你在一个多 Agent 协作的工作流里，revision_count 字段的最大值被设计为 10（防止无限重试）。

在某个节点里，程序逻辑意外地把计数器加到了 11：

# 错误做法（不处理校验异常）：
def write_node(state: WritingState) -> WritingState:
    # 某次误操作把 revision_count 设成了 11
    return {**state, "revision_count": state["revision_count"] + 1}

# Pydantic 在状态返回时会自动抛出 ValidationError：
# revision_count=11 ensure value is less than or equal to 10

正确做法是在节点里预判校验失败的情况：

# 正确做法：主动做边界检查
def write_node(state: WritingState) -> WritingState:
    new_revision_count = state["revision_count"] + 1
    if new_revision_count > 10:
        # 超过最大轮次，强制终止或降级处理
        raise RuntimeError("修改轮次超过上限，强制终止工作流")
    return {**state, "revision_count": new_revision_count}

面试时，展示"主动预判校验边界"这个习惯，本身就是在告诉面试官：你不是一个只会写 happy path 的工程师。

模板答案：Pydantic 面试复述版

"Pydantic BaseModel 是我目前在生产项目里定义 LangGraph State Schema 的首选方式。相比 TypedDict，它的优势是三层叠加的：第一，运行时校验让类型错误在节点返回时立刻暴露，而不是藏到线上才炸开；第二，Field description 会自动出现在 LangSmith 追踪面板里，调试效率差一个量级；第三，它对复杂嵌套结构（嵌套模型、列表字段、枚举约束）有完整的原生支持。我通常在原型阶段用 TypedDict 快速跑通逻辑，一旦项目进入多 Agent 协作或者需要对外暴露 API 的阶段，第一件事就是迁移到 Pydantic，迁移成本通常不超过两小时。"

五、深度对比：TypedDict vs Pydantic，选型逻辑与面试回答

六个维度对比

这是整个专题的核心对比表，建议先记住这个骨架，再往下看选型决策树：

维度	TypedDict	Pydantic
依赖	Python 标准库，零依赖	需安装 pydantic 包
校验能力	无运行时校验，只有 IDE 类型检查	完整的运行时校验，可自定义验证器
可观测性	字段无 description，LangSmith 追踪信息有限	Field description 自动出现在 LangSmith
学习成本	几乎为零，Python 3.8+ 内置	需要了解 BaseModel / Field / 验证器
性能	极轻量，无额外开销	有轻微的模型实例化开销（约 0.1-0.3ms/次）
团队协作	结构简单，适合小型项目	结构化文档化，适合中大型团队

性能这一项值得单独说：Pydantic 的实例化开销在绝大多数 AI Agent 场景下不是瓶颈------LLM 的推理延迟通常在几百毫秒到数秒之间，Pydantic 的校验开销可以忽略不计。

但如果你的工作流需要每秒处理上万次状态更新（例如高频事件处理场景），TypedDict 的零开销就有实质意义了。

不过说实话，这类场景通常不会用 LangGraph 来处理，LangGraph 面向的是 LLM 驱动的异步工作流。

架构评审：Pydantic 的性能开销，啊？

正文图解 2

选型决策树：原型 vs 生产、单 Agent vs 多 Agent

面试时最实用的回答框架是把选型条件拆成三个问题：

问题一：现在是什么阶段？ 原型阶段 → TypedDict；进入生产或有多人协作 → Pydantic。

问题二：状态字段需要校验吗？ 如果答案是"只要 LLM 输出合法值就够"，TypedDict 可以撑；如果字段有业务规则约束（取值范围、必填/选填、互斥关系），Pydantic 是必选。

**问题三：调试时需要可观测性吗？简单场景可以靠 print；

复杂场景（多 Agent、循环迭代、human-in-the-loop）必须靠 LangSmith，而 LangSmith 从 Field description 里获益的前提是你在用 Pydantic。

项目里怎么迁移：TypedDict → Pydantic 改造步骤

迁移本身不复杂，但有几个坑要注意：

第一步：替换基类。

把 from typing import TypedDict 换成 from pydantic import BaseModel, Field，把 class 继承从 TypedDict 改成 BaseModel。

第二步：逐字段加默认值。

TypedDict 的字段没有默认值，迁移时需要为所有非必填字段显式补上 Field(default=...)，否则 Pydantic 会要求你在每次初始化状态时必须填所有字段。

第三步：决定哪些字段要加 description。建议至少给所有涉及业务语义的字段加 Field description，调试字段（计数、标志位）可以省略。

第四步：检查节点返回语句 。TypedDict 的节点可以返回 {**state, "field": value}；

Pydantic 模式下也可以，但需要确保返回值能被 Pydantic 解析成正确类型。最保险的做法是直接返回 WritingState(...) 构造实例。

迁移完成后的第一件事：跑一遍 LangSmith，确认所有 Field description 都正确显示，然后做一次脏数据测试（故意传非法值），确认 ValidationError 能正常抛出。

六、工程落点：实际项目里怎么设计 State Schema

多 Agent 协作时的状态分片设计

在多 Agent 场景里，状态分片是一个被严重低估的设计维度。

常见的错误做法是所有 Agent 共用一个超大的 State Schema，里面塞了十几个字段，每个 Agent 只读写自己关心的字段。这种做法在功能上能跑，但有几个工程问题：

问题一：字段命名冲突 。两个 Agent 都往 result 字段写东西，后写的会覆盖先写的。

问题二：可观测性灾难。LangSmith 里一个 State 有 15 个字段，其中 10 个对当前 Agent 来说永远是空的，调试时干扰极大。

问题三：权限不清晰。没有哪个文档说清楚"哪个 Agent 负责填充哪个字段"，新成员只能靠读源码猜。

正确的做法是按 Agent 职责分片，给每个子 Agent 定义自己的子 Schema，然后在顶层 State 里用嵌套 Pydantic 模型来组织：

from pydantic import BaseModel, Field

# 各 Agent 的子状态
class ResearchAgentState(BaseModel):
    """调研 Agent 专属状态"""
    research_data: str = Field(default="", description="调研收集的核心资料")
    search_queries: list[str] = Field(default_factory=list, description="搜索关键词列表")

class WritingAgentState(BaseModel):
    """写作 Agent 专属状态"""
    draft: str = Field(default="", description="文章草稿")
    draft_word_count: int = Field(default=0, ge=0, description="草稿字数统计")

class ReviewAgentState(BaseModel):
    """校对 Agent 专属状态"""
    review_comment: str = Field(default="", description="校对修改意见")
    is_approved: bool = Field(default=False, description="校对是否通过")
    revision_count: int = Field(default=0, ge=0, le=10, description="修改轮次")

# 顶层状态聚合所有子状态
class WritingWorkflowState(BaseModel):
    """写作工作流顶层状态"""
    topic: str = Field(description="写作主题")
    research: ResearchAgentState = Field(default_factory=ResearchAgentState)
    writing: WritingAgentState = Field(default_factory=WritingAgentState)
    review: ReviewAgentState = Field(default_factory=ReviewAgentState)

这种设计的核心收益是：每个 Agent 的职责边界在 Schema 层面就是清晰的，新成员读 Schema 就知道"调研 Agent 管哪些数据"。

LangSmith 里也可以按 Agent 过滤状态，调试时一目了然。

代码评审：所以 review 阶段能读到 research_data 吗？

状态持久化方案

LangGraph 的 State 默认存储在内存里，工作流结束后状态就消失了。在需要中断恢复或者状态回溯的场景里，你需要把 State 持久化到外部存储。常见的两种方案：

方案一：Redis 持久化。适合短周期中断恢复，例如用户对话中断后重新拉起工作流。

实现思路是在节点执行前后把 State 序列化后存入 Redis，用 thread_id 作为 key 关联每次会话。

import json, redis
from langgraph.checkpoint.base import BaseCheckpointSaver

class RedisCheckpointSaver(BaseCheckpointSaver):
    def __init__(self, redis_client: redis.Redis):
        self.redis = redis_client

def save(self, thread_id: str, state: dict):
        self.redis.set(f"langgraph:{thread_id}", json.dumps(state))

def load(self, thread_id: str) -> dict | None:
        data = self.redis.get(f"langgraph:{thread_id}")
        return json.loads(data) if data else None

方案二：数据库持久化。适合需要长期存储审计日志或支持跨会话状态查询的场景。用 PostgreSQL 或 MySQL 都可以，关键是设计一张 schema 版本兼容的状态表：

CREATE TABLE agent_state_snapshots (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    thread_id VARCHAR(128) NOT NULL,
    schema_version INT NOT NULL DEFAULT 1,
    state_data JSON NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_thread_id (thread_id),
    INDEX idx_created_at (created_at)
);

schema_version 字段在这里非常关键：当你升级了 Pydantic State Schema（例如新增了一个字段）之后，存量会话里的旧 JSON 数据可能无法直接被新 Schema 解析。

这个字段让你可以写迁移脚本，按版本号做向前兼容。

常见翻车模式与修复代码示例

翻车模式 A：节点不返回状态导致数据丢失。

# 错误做法：节点计算了新 draft，但没有返回
def write_node(state: WritingState) -> WritingState:
    new_draft = llm.invoke(f"根据调研：{state['research_data']}，写一篇文章")
    # 忘记 return，state 中的 draft 字段不会被更新

# 正确做法
def write_node(state: WritingState) -> WritingState:
    new_draft = llm.invoke(f"根据调研：{state['research_data']}，写一篇文章")
    return {**state, "draft": new_draft.content}

翻车模式 B：条件分支里状态字段未初始化。

# 错误做法：只在通过分支里设了 is_approved
def review_node(state: WritingState) -> WritingState:
    if is_approved:
        return {**state, "is_approved": True}
    # 不通过分支没有返回语句，LangGraph 抛异常

# 正确做法
def review_node(state: WritingState) -> WritingState:
    is_approved = check_quality(state["draft"])
    return {**state, "is_approved": is_approved}

七、面试追问路径：State Schema 相关的延伸问题

追问方向一：状态里放什么字段，怎么决定

"字段设计遵循两个原则：一是只放节点之间需要共享的数据，单个节点内部临时计算的中间结果不要进 State；二是每个字段必须有明确的业务归属，不能出现'大家都可能写但没人负责'的字段。如果某个数据只在节点 A 内部使用，那它就不应该出现在顶层 State 里，而是作为节点 A 的局部变量存在。这样做的好处是把 State 的表面积控制在最小，降低理解和调试的认知负担。"

追问方向二：什么时候需要嵌套 State

"当工作流里有明确的子 Agent 或者子阶段时，值得用嵌套模型来组织状态。具体判断标准是：如果某个数据子集只被一个子 Agent 读写，而其他 Agent 不会关心，那就应该把它封装成子模型。这样做有两个好处------第一，顶层 State 保持精简，LangSmith 里不会看到一屏幕无关字段；第二，每个子 Agent 的职责边界在 Schema 层面就是自文档化的。"

追问方向三：State 字段过多对性能有什么影响

"对 LangGraph 工作流来说，State 字段数量本身对执行性能影响很小，因为状态在节点之间传递的是引用，不是深拷贝。但如果字段多到需要跨节点做序列化持久化（比如存 Redis 或者数据库），那每增加一个字段就多一次序列化开销。更重要的是认知层面的：字段超过十个的多 Agent State，调试时会非常痛苦，因为很难快速定位'哪个节点在什么时候把哪个字段改成了什么'。我的工程判断是，如果顶层 State 的字段数量超过十二个，就应该考虑按 Agent 职责做状态分片了。"

追问方向四：State 和 Memory 模块的区别和联系

"简单说，State 是工作流执行时的瞬时数据中心，Memory 是跨会话的持久化存储。State 在工作流启动时初始化，在工作流结束后销毁（除非你显式持久化）；Memory 则在你的应用进程之外存储，例如对话历史。LangGraph 里 State 和 Memory 经常一起出现：Memory 保存用户的历史对话，State 保存当前工作流的中间结果。一个常见的误解是把 Memory 当 State 用------比如把用户的所有历史对话都塞进 State，这样每次节点执行都要序列化/反序列化大量数据，性能会急剧下降。正确的做法是让 Memory 负责历史，State 只负责当前这次工作流的上下文。"

追问方向五：如何设计支持 human-in-the-loop 的 State

"Human-in-the-loop 的核心是在工作流里插入人工审批节点，State 需要承载审批的状态信息。我的设计通常会在 State 里放一个 human_approval 字段和一个 human_comment 字段，审批节点在执行到一半时暂停，把当前 State 交给外部审批流程，等用户确认后再把结果写回 State，继续执行。这个模式有几个实现细节需要注意：一是 State 必须在暂停前做持久化（否则进程重启后状态丢失）；二是审批节点的逻辑必须是幂等的------同一个 State 多次审批不应该产生副作用。"

八、易错点与避坑指南

坑一：节点不返回状态导致数据丢失

这是 LangGraph 新手最容易踩的坑。节点函数必须显式返回状态字典，否则 LangGraph 认为节点没有修改状态，下一个节点读到的 State 和当前节点完全一样。

# 错误做法
def write_node(state: WritingState) -> WritingState:
    draft = llm.invoke(...)
    # 忘记 return，draft 丢失

# 正确做法
def write_node(state: WritingState) -> WritingState:
    draft = llm.invoke(...)
    return {**state, "draft": draft.content}

为什么这个坑很危险：在简单线性流程里，这个问题通常在第一轮调试就会发现，因为后续节点会因为数据为空而暴露问题。

但在多 Agent 协作的复杂场景里，这个 bug 可能被部分节点填充了其他字段这件事掩盖过去------程序不报错，但结果不对。

线上：为什么 review_node 收到的 draft 一直是空的？

坑二：条件分支里状态字段未初始化

条件分支里忘记初始化某些字段，会导致 LangGraph 在状态校验时报错------尤其是在用 Pydantic 时，缺少必填字段的显式赋值会被校验器拦截。

# 错误做法
def conditional_node(state: WritingState) -> WritingState:
    if state["is_approved"]:
        # 只在通过分支里写了返回值
        return {**state, "status": "done"}

---

延伸入口

• 原文归档：https://tobemagic.github.io/ai-magician-blog/posts/2026/04/19/ai面试八股文-vol11-专题3state-schema-设计state-schema设计typeddict-pydantic类型约束/
• 公众号：计算机魔术师

---

参考文献

1\] 原始资料\[EB/OL\]. https://github.com/fanyty/langgraph_multi_agent_tutorial. (2026-04-19).