步骤二：明确每个步骤需要做什么
对于图中的每个节点，确定它代表什么类型的操作以及它需要什么上下文才能正常工作。
1、LLM处理：需要理解、分析、生成文本或做出推理决策
2、数据流向：需要从外部来源检索的信息
3、执行流程：需要执行外部的操作
4、人工干涉：需要人工干预的步骤
步骤三：设计状态
状态是智能体中所有节点均可访问的共享记忆
1、它是否需要在多个步骤之间持久存在？如果是，就放进状态字典中
2、它是否可以从其他数据推导出来？如果是，则在需要时计算它，而不是将其存储在 状态中
状态仅包含原始数据——不包含提示模板、格式化字符串或任何指令。分类输出直接来自 LLM，并以单个字典的形式存储。（根据实用主义来看，这个是全图共享但是使用还是相关节点或边）
步骤 4：构建节点
将每个步骤实现为一个函数。LangGraph 中的一个节点就是一个 Python 函数，它接收当前状态并返回更新后的状态。
| 错误类型 | 谁来修复 | 策略 | 适用场景 |
|---|---|---|---|
| 临时性错误（网络问题、速率限制） | 系统（自动） | 重试策略 | 通常重试即可解决的临时故障 |
| LLM 可恢复的错误（工具调用失败、解析问题） | LLM | 将错误信息存入 State 并循环返回 | LLM 能够看到错误并调整自己的处理方式 |
| 用户可修复的错误（信息缺失、指令不清晰） | 人类 | 使用 interrupt() 暂停执行 | 需要用户提供额外信息才能继续 |
| 重试用尽后的可恢复失败 | 开发者 | error_handler | 在重试全部失败后，执行补偿/恢复分支逻辑 |
| 意外错误 | 开发者 | 冒泡 | 未知问题，需要调试介入 |
1、临时性错误：可通过添加重试策略，自动重试网络问题和速率限制问题。
2、LLM可恢复错误：将错误存储在状态中并循环返回，以便 LLM 可以查看哪里出了问题并重试
3、用户可介入错误：必要时暂停并从用户处收集信息
4、重试用尽错误：运行恢复功能，更新状态并路由到补偿分支
5、意外错误：冒泡调试
步骤五：将他们组合在一起
构建graph
需注意节点颗粒度权衡
1、考虑隔离外部服务
2、中间节点可见
3、不同的故障模型
4、可用性、测试性，要注意重用性