LangGraph

一、LangGraph 的核心架构和工作原理是什么？

1. 基于状态图的执行模型

LangGraph 将 Agent 工作流建模为有向图，由节点（Node）、边（Edge）和状态（State）三个基本元素构成。与传统的有向无环图（DAG）不同，LangGraph 的图支持循环，这使得 Agent 可以在多个节点之间反复流转，实现迭代推理、工具调用循环等复杂行为。图的执行采用消息传递算法，受 Google Pregel 系统和 Apache Beam 启发，以离散的"超级步"（super-step）为单位推进：每个超级步中，所有收到消息的节点并行执行，执行完毕后向下游发送更新，下一超级步根据新的消息决定哪些节点继续运行，直到所有节点进入停滞状态。

2. 节点、边和状态的职责分工

节点是图中的计算单元，本质上是接收当前状态、执行操作并返回状态更新的 Python 函数。一个节点可以调用大语言模型、执行工具、查询数据库或运行任意业务逻辑。边定义节点之间的连接和执行顺序，分为无条件边和条件边两种：无条件边表示固定的执行路径，条件边则通过路由函数根据当前状态动态决定下一个节点。状态是一个共享的 typed 数据结构（通常用 TypedDict 或 Pydantic 模型定义），贯穿整个图的执行过程，所有节点都可以读取和写入状态。

3. 编译与执行

LangGraph 使用 StateGraph 类作为主要构建器，开发者依次添加节点、边和检查点配置后，调用 .compile() 方法将图编译为可执行对象。编译过程会进行结构校验（如检测孤立节点），并将运行时参数（如 checkpointer、断点配置）绑定到图中。编译后的图实现了 Runnable 接口，支持 invoke()、stream()、ainvoke()、astream() 等多种调用方式。

4. 与 LangChain 生态的关系

LangGraph 虽然可以与 LangChain 深度集成，利用其丰富的模型和工具组件，但它并不依赖 LangChain，可以独立使用。在 LangChain 的产品体系中，LangChain 提供模型和工具的抽象与集成，LangGraph 负责编排运行时（持久执行、流式输出、人机协同），LangSmith 提供追踪、评估和部署平台，三者各司其职又无缝协作。

二、LangGraph 的状态管理机制是如何工作的？

1. 状态 schema 定义

LangGraph 的状态通过类型化的数据结构定义，支持 TypedDict、Pydantic BaseModel 或 dataclass。TypedDict 是最常用的方式，性能最优；Pydantic 提供递归数据验证但性能略低。每个节点的输入和输出都遵循状态的 schema，确保类型安全。从 LangGraph 1.0 开始，官方推荐使用 Pydantic BaseModel 定义状态；Pydantic v3 的验证性能相比 v2 有显著提升，适合生产环境使用。

2. 通道与 Reducer

状态中的每个键对应一个通道（Channel），通道决定了当多个节点同时写入同一字段时如何进行合并。常见的 reducer 包括：add_messages（追加模式，用于消息历史累加）、last_value（覆盖模式，用于标量值）、merge（字典合并）和自定义 reducer。开发者可以通过 Annotated[..., reducer] 语法为每个状态键指定合并策略，避免并发写入时的数据冲突。

3. 子图和模块化状态

LangGraph 支持子图（Subgraph）机制，可以将复杂的 Agent 拆分为多个独立的子状态机。子图作为一个整体节点嵌入父图中，通过定义的输入/输出 schema 与父图通信。这种模块化设计允许不同团队各自开发子图模块，最后组装成完整系统，也便于单元测试和复用。

4. 上下文 Schema

除了状态之外，LangGraph 还支持 context schema，用于注入运行时不变的上下文数据（如 user_id、数据库连接等）。context 对所有节点可见但不可修改，适合传递只读的配置信息，避免了将这些数据放入可变状态中带来的复杂度。

三、LangGraph 如何实现循环和条件分支逻辑？

1. 条件边驱动的动态路由

条件边是 LangGraph 实现循环和分支的核心机制。通过 add_conditional_edges() 方法，开发者可以为某个节点指定一个路由函数，该函数接收当前状态并返回目标节点的名称。例如，在一个 RAG 流程中，可以根据检索结果的质量评分决定是直接输出答案还是重新搜索。条件边的路由逻辑是完全确定性的 Python 函数，不依赖 LLM 决策，保证了调试的可复现性。

2. 循环的实现模式

循环通过条件边指向已访问过的上游节点来实现。典型的 ReAct 循环包含两个节点（LLM 节点和工具节点）和一条条件边：LLM 节点生成响应后，条件边检查是否存在 tool_calls，如果有则路由到工具节点执行，执行完后再回到 LLM 节点；如果没有则路由到结束节点。这种循环机制使得 Agent 可以进行多轮"思考-行动-观察"的迭代推理。

3. 递归限制保护

为防止无限循环，LangGraph 提供了 recursion_limit 配置项，默认值为 25。当图的执行步数超过限制时，会自动终止并抛出 GraphRecursionError 异常。在生产环境中，开发者通常会在状态中显式维护计数器，或通过条件边检测连续若干步没有实质性进展时强制退出，实现对循环退出的精细控制。

4. 静态条件与动态跳转

LangGraph 支持两种实现条件分支的方式：静态方式使用 add_conditional_edges() 在编译期声明所有可能的路由目标，图可视化清晰；动态方式使用 Command(goto=...) 在节点内部直接返回下一步的目标节点，适合节点内部已掌握全部决策信息的场景。两种方式最终生成的图拓扑相同，选择取决于代码组织的偏好。

四、LangGraph 如何实现人机协同（Human-in-the-Loop）？

1. interrupt_before 中断机制

LangGraph 提供了原生的中断能力，通过 interrupt_before 参数可以在指定节点执行前暂停图的处理。配合 checkpointer 使用时，图会在中断点保存完整的状态快照，然后返回一个包含中断载荷（payload）的结果给调用方。这个载荷可以是任何可序列化的数据，如待审批的文档草稿、拟执行的交易详情等，供人类审查者查看。

2. interrupt() 函数的细粒度控制

除了编译期配置的中断，LangGraph 还支持在节点函数内部通过 interrupt(payload) 函数进行细粒度的运行时中断。interrupt() 会冻结执行、保存状态、返回 payload 给调用方，然后等待 resume。调用方通过 Command(resume=value) 传入人类的决策结果，图从断点恢复执行，interrupt() 的返回值即为人类输入的内容。这种模式适用于需要在特定逻辑判断点临时插入人工审核的场景。

3. 持久化暂停与长时间等待

由于中断机制建立在 checkpointer 之上，暂停可以持续任意时长——从几毫秒到数天。Agent 的状态在整个等待期间被持久化存储，不会占用运行时的连接资源。恢复时只需使用相同的 thread_id 调用 invoke()，LangGraph 会从检查点加载完整状态，包括所有中间变量和消息历史，人类决策被折叠进状态后继续执行后续节点。

4. 生产环境中的应用模式

在人机协同模式下，高风险操作（如金融转账、邮件发送、数据删除）前必须经过人工审批。典型实现是将 interrupt_before 配置在执行这些操作的节点之前，Agent 完成准备工作后暂停，通过 UI、Slack 或邮件通知人类审查者，审查者 approve 或 reject 后 Agent Resume 执行。对于合规要求严格的场景，还可以结合 tiered autonomy 模式：根据置信度自动分流——高置信度自动通过、中等置信度通知但不阻塞、低置信度暂停等待审批。

五、LangGraph 如何构建多 Agent 协作系统？

1. Supervisor-Worker 架构

Supervisor 模式是多 Agent 协作中最成熟的生产方案：一个 Supervisor 节点作为调度中枢，接收用户请求后分析任务并路由给专业的 Worker 节点执行。每个 Worker 拥有独立的系统提示词、工具和模型配置，执行完成后将结果写回共享状态，Supervisor 评估结果后决定继续路由给其他 Worker 或终止。所有通信通过 LangGraph 的共享 State 传递，无需 Agent 之间直接 API 调用。

2. 子图封装专业 Agent

复杂的 Worker 本身可以是独立的子图，包含多步处理逻辑。例如研究员 Worker 可以是一个包含"网络搜索 → 事实提取 → 摘要生成"三步的子图。子图作为单个节点嵌入父图中，父图不需要了解子图的内部结构，只需关注输入输出 schema。这种组合式设计使得大型多 Agent 系统可以分层构建、独立测试和复用。

3. 并行派发的 Send API

通过 Send 对象，Supervisor 可以在一个超级步中同时向多个 Worker 派发任务，实现真正的并行执行。返回 [Send("researcher", state), Send("coder", state)] 这样的列表会让 LangGraph 为每个 Send 创建独立的执行分支，各分支的结果通过 reducer 自动合并回主状态。这种 fan-out/fan-in 模式可以将串行执行的时间复杂度从 O(n) 降低到 O(1)。

4. 层级化多 Agent 架构

对于超大规模的系统，可以采用多层 Supervisor 架构：顶层 Supervisor 负责任务分解，中层 Supervisor 管理特定领域的 Worker 团队，底层 Worker 执行具体操作。每个层级的交互模式都是显式的图结构，确保了整个系统的可审计性。实践中，单个 Supervisor 管理的 Worker 数量建议不超过 8-10 个，超过此规模应引入层级拆分。

六、LangGraph 如何实现 Agent 的内存管理和上下文保持？

1. 短期工作记忆

Agent 的短期记忆通过状态中的消息通道自然实现。使用 add_messages reducer 的消息列表会累积所有 HumanMessage、AIMessage 和 ToolMessage，形成完整的对话历史。每个新节点执行时都能读取全部历史消息，确保推理的连贯性。这种方式比在高阶 prompt 中 hack 会话变量更加可靠和可追溯。

2. 持久化跨会话记忆

通过 Checkpointer 和 thread_id 的组合，LangGraph 实现了跨会话的持久化记忆。每次调用图时传入唯一的 thread_id，checkpointer 会以该 ID 为键保存每次执行的完整状态快照。当使用相同 thread_id 再次调用时，Agent 可以从之前的任何检查点恢复，包括未完成的长流程和之前的对话上下文。这天然支持多轮对话、长流程任务的断点续传等功能。

3. 长期记忆扩展

对于需要更长周期记忆的場景，可以在状态中维护专门的记忆通道，定期将重要信息持久化到外部存储（如向量数据库、关系型数据库）。在生产系统中，建议使用 PostgreSQLSaver 或 MongoDBSaver 等持久化后端替代默认的 MemorySaver，确保进程重启后记忆不丢失。

4. 上下文窗口管理

面对有限的上下文窗口，LangGraph 本身不自动压缩上下文，但提供了基础设施层面的支持：开发者可以通过自定义节点实现上下文压缩策略，如对历史消息进行摘要、移除已过期的中间结果、仅保留关键的工具调用结果等。Deep Agents 在此基础上进一步提供了规划、子代理和文件系统工具等高级能力。

七、LangGraph 的 ReAct 模式是如何实现的？

1. 最小 ReAct 图结构

在 LangGraph 中，ReAct（Reasoning + Acting）循环可以用最简化的两节点一图实现：一个 Agent 节点负责调用 LLM 生成回复或 tool_calls，一个 Tool 节点负责执行工具调用。两者之间通过一条条件边连接：如果 LLM 响应包含 tool_calls，路由到 Tool 节点；否则路由到 END 结束执行。Tool 节点执行完毕后通过普通边回到 Agent 节点，形成循环。

2. 从字符串解析到原生工具调用

传统 ReAct 实现依赖 prompt 模板中的格式约定（如 "Thought: ... Action: ... Action Input: ..."），通过正则表达式解析 LLM 的文本输出。2026 年的实现已全面转向原生工具调用：模型根据工具定义的 JSON Schema 直接生成结构化的 tool_calls 字段，由框架层面进行严格验证，彻底消除了格式幻觉导致的崩溃问题。

3. 静态与动态两种实现方式

静态实现使用独立的 router 函数配合 add_conditional_edges() 判断是否继续循环，图结构清晰可视；动态实现则将跳转逻辑内聚在 LLM 节点内部，通过 Command[Literal["tool_node", "output_node"]](update=..., goto=...) 直接在返回值中决定下一步去向。前者适合路由规则简单且被多个节点共享的场景，后者适合节点内部已掌握全部决策信息的场景。

4. 循环终止与安全控制

ReAct 循环的出口始终在 LLM 手中——模型决定是否发出 tool_calls。为防止模型陷入无限循环或过度消耗 token，必须在代码层面设置防护：使用 recursion_limit 配置最大步数、在状态中维护 retry_count 或 stagnant_turns 计数器、对工具调用结果做去重检测等。生产环境还应加入 token 用量监控和断路器机制。

八、LangGraph 的学习曲线如何，适合什么样的开发者？

1. 学习曲线特点

LangGraph 的学习曲线相对陡峭，核心原因在于它要求开发者理解图论基础概念（节点、边、状态、循环）并用代码精确描述控制流。与 Dify 等可视化拖拽框架不同，LangGraph 不提供低代码界面，所有逻辑都需要通过 Python 代码编写。这意味着开发者需要自己定义状态 schema、编写节点函数、配置路由逻辑，代码量明显多于高阶框架。

2. 适合的开发者群体

LangGraph 最适合具备以下特征的开发者：已经熟悉 LangChain 生态、需要精细控制 Agent 行为的企业级开发者、正在处理复杂条件分支和循环的工作流、需要生产级别的持久化和调试能力。对于只做简单 RAG 问答或线性聊天机器人的场景，使用 LangChain 的链式 API 就足够了，套 LangGraph 属于过度工程。

3. 入门路径建议

推荐的入门路径是：先理解 LangChain 的基础组件（模型、工具、prompt），再用最简单的线性图（START → Node → END）跑通第一个示例，接着逐步增加条件边实现循环，然后引入 checkpointer 实现持久化，最后尝试多 Agent 子图编排。LangGraph Studio（浏览器端的可视化调试器）能显著降低学习难度，通过图形化展示图的拓扑结构和状态变化，帮助开发者直观理解控制流。

4. 与同类框架的对比定位

相比 CrewAI 的角色基抽象和 AutoGen 的群组聊天模式，LangGraph 提供更底层的图控制，适合需要将精确业务规则编码到 Agent 行为中的场景。CrewAI 更适合快速原型和演示，AutoGen 在群组对话场景中有优势。

九、LangGraph 适用于哪些典型应用场景？

1. 自修正 RAG 系统

经典的自修正 RAG 模式中，Agent 先检索文档、生成答案草稿，然后通过质量评估节点判断证据是否充分。如果质量不达标，条件边会将执行路由回检索节点，使用优化后的查询词重新搜索。这个过程循环执行直到答案质量达标或重试次数耗尽，有效解决了传统 RAG 一次检索不足的问题。

2. 多 Agent 团队协作

企业级应用场景中，一个 Supervisor 协调多个专业 Worker 完成端到端任务。例如客服场景中，Researcher Agent 查询知识库、Billing Agent 处理账单查询、Resolution Agent 提供解决方案，Supervisor 根据用户意图分发任务并汇总最终答复。这种多 Agent 协作模式在企业 AI 助手系统中得到广泛应用。

3. 代码编写与测试循环

编程辅助产品广泛采用 LangGraph 实现"编写代码 → 沙箱执行 → 读取错误信息 → 修复 Bug → 重新测试"的循环。Code Agent 在隔离环境中运行代码，根据测试结果自动调整实现，直到所有测试用例通过。这种闭环自动化大幅提升了代码生成的可靠性。

4. 需要人工审批的合规工作流

金融、医疗等监管严格行业中，Agent 完成准备工作后暂停等待人工审批的模式是刚需。例如大额转账前 Agent 收集信息并生成交易草稿，暂停等待用户确认金额和收款方，审批通过后才执行支付操作。LangGraph 的原生中断机制使这种"暂停-审批-恢复"成为一等公民的工作流模式。

十、LangGraph 与 LangChain 有什么关系和区别？

1. 产品定位差异

LangChain 是 Agent 框架，提供模型、工具、prompt 等组件的抽象和集成，专注于"用什么做"；LangGraph 是编排运行时，提供持久执行、流式输出、人机协同等基础设施，专注于"怎么组织这些组件协同工作"。两者不是替代关系，而是互补关系。

2. 功能重叠与分工

LangChain 内置了 AgentExecutor 等高层抽象，适合快速搭建简单的 Agent。但当需要更精细的控制——如循环、条件分支、状态持久化——时，LangChain 的高层抽象会隐藏太多细节，此时 LangGraph 的低层 API 成为更合适的选择。简单来说，LangChain 解决"接入模型和工具"的问题，LangGraph 解决"编排复杂工作流"的问题。

3. 技术依赖关系

使用 LangGraph 不需要必须使用 LangChain，两者的核心 API 是独立的。但在实际使用中，绝大多数 LangGraph 项目都会搭配 LangChain 的模型集成和工具组件，享受最大的生态红利。LangGraph 1.0 之后，部分原本位于 langgraph.prebuilt 的功能已迁移到 langchain.agents，进一步模糊了两者的边界。

4. 版本演进趋势

随着 LangChain 产品的不断迭代，三者的分工更加明确：LangChain 持续丰富模型和工具集成，LangGraph 强化编排能力和生产特性（如 Deep Agents 框架和 Functional API），LangSmith 统一提供可观测性和部署平台。开发者应根据需求层次选择合适的产品组合。

十一、LangGraph 在生产环境中如何部署？

1. 本地开发模式

开发阶段可以使用 langgraph dev 命令启动本地服务器，配合 LangGraph Studio 进行可视化调试。本地模式使用 InMemorySaver 作为 checkpointer，适合快速迭代和原型验证。这种方式零配置即可运行，但状态不持久化，进程重启后数据丢失。

2. LangSmith Deployment 托管部署

LangSmith Deployment（原 LangGraph Platform，2025 年 10 月更名）提供一键部署能力，将图打包为可部署的 API 服务。托管服务提供自动扩缩容、任务队列、持久化存储和 Cron 调度，无需 Kubernetes 专业知识即可将 Agent 投入生产。2026 年 5 月 14 日，LangChain 宣布 LangGraph Platform 达到 GA 版本，Beta 期间已有约 400 家企业参与测试。

3. 自托管部署选项

对于有数据驻留要求的团队，可以选择自托管方案：使用 Docker Compose 在单服务器上快速部署 Agent Server，或在 Kubernetes 上部署以获得生产级高可用。Enterprise 版本支持完全自托管，控制平面和数据平面都在用户自己的 VPC 内，满足金融、医疗等行业的最严格合规要求。

4. 混合部署模式

混合部署是目前大型企业最常用的方案：控制平面（UI、评估、提示词管理）运行在 LangChain 云端，数据平面（Agent 运行时）部署在用户自己的基础设施中。这样既享受云端的运维效率，又确保原始数据不出内网。

十二、LangGraph 如何与 LangSmith 集成实现可观测性？

1. 自动追踪机制

启用 LangSmith 追踪非常简单，只需设置三个环境变量：LANGSMITH_TRACING=true、LANGSMITH_API_KEY 和 LANGSMITH_PROJECT。此后图中每一次 LLM 调用、工具执行和节点转换都会被自动记录为结构化 trace。每个节点对应一个 span，包含输入输出状态、延迟、token 消耗等详细信息。

2. 结构化调试能力

与简单的日志不同，LangSmith 提供的 trace 是高度结构化的：可以看到 Agent 的完整执行路径、每个节点的 state 快照、模型的中间推理步骤。排查问题时，可以通过 thread_id 重现失败的运行，逐节点检查 state 何时偏离预期，将故障定位时间从小时级缩短到分钟级。

3. LangSmith Studio 可视化调试

Studio 是 LangGraph 的可视化开发环境，以交互式图表渲染图的结构，支持单步执行、状态检查和 checkpoint 回放。开发者可以在 Studio 中查看条件边的实际路由决策、编辑 prompt 后即时 replay、对比不同版本的执行轨迹。对于包含循环和分支的复杂图，Studio 的可视化能力显著降低了调试难度。

4. 评估与持续改进

LangSmith 还提供数据集管理、自动化评估和 A/B 实验功能。可以将生产 trace 转化为测试用例，使用 LLM-as-judge 自动评分，量化不同版本 Agent 的性能差异。2026 年新增的多轮评估（Multi-turn evals）可以衡量端到端的对话质量，包括语义意图、语义结果和 Agent 轨迹。

十三、LangGraph 如何保障生产环境的安全性和权限控制？

1. 认证集成

LangGraph 支持自定义认证处理器，通过 langgraph_sdk.Auth 类实现 JWT 验证。在 API 网关层拦截请求、验证令牌有效性后，将用户身份注入到图的初始状态中。企业环境可对接 Keycloak 等 OIDC 提供商，实现统一的身份管理。LangSmith Deployment 还支持 SSO 集成（如 Okta），满足企业级单点登录需求。

2. 基于角色的权限控制

安全的最佳实践是将 user_id、role、permissions 等身份信息显式放入 State Schema，让每个节点在执行前主动校验权限。对于敏感工具（如数据库删除、邮件发送），可以在工具节点内部实施 RBAC 检查，确保只有授权角色才能执行相应操作。细粒度的权限策略还可以通过 OPA（Open Policy Agent）等策略引擎实现。

3. 线程隔离与数据保护

每个用户的会话通过独立的 thread_id 隔离，LangGraph 保证不同 thread_id 之间的状态互不可见。在生产部署中，应防止用户通过篡改 thread_id 访问他人数据——需要在入口层验证 thread_id 的所有权。状态中的敏感字段（如 access_token）应采用字段级加密（AES-GCM）存储，密钥由 KMS 管理。

4. 审计与合规

LangSmith 的追踪记录天然构成了审计日志：每条 trace 包含完整的操作链路、主体标识和资源标识。对于合规要求严格的行业，可以额外启用 LangSmith 的企业级审计功能，包括服务账号管理、操作日志保留策略和用户行为告警。

十四、LangGraph 与 CrewAI、AutoGen 等框架有何区别？

1. 与 CrewAI 的对比

CrewAI 采用角色基抽象，通过定义 Agent 角色和任务流程快速搭建多 Agent 系统，学习成本低但控制粒度较粗。LangGraph 则以图为核心，提供对控制流的精确掌控，支持循环、条件分支和状态持久化等生产级特性。CrewAI 适合快速原型和演示，LangGraph 适合需要精确业务规则编码的企业级应用。

2. 与 AutoGen 的对比

AutoGen 的核心模式是群组聊天（Group Chat），Agent 之间通过 LLM 驱动的发言选择进行协作。这种模式灵活但难以预测和控制，调试复杂度高。LangGraph 的 Supervisor 模式通过显式的图结构和确定性路由实现同样的多 Agent 协作，交互模式始终可审计、可复现。

3. 与 Mastra 的对比

Mastra 是另一款新兴的多 Agent 框架，强调 TypeScript 原生支持和开箱即用的 Agent 模板。LangGraph 则在 Python 生态中积累了更长的时间，拥有更大的社区和生产案例基础。

4. 选型建议

选择框架时应考虑：如果需要精细控制、复杂循环、持久化等人机协同能力，LangGraph 是更合适的选择；如果追求快速原型开发和低代码体验，CrewAI 或 Mastra 可能更合适；如果需要群组对话模式而非 supervisor 模式，AutoGen 值得考虑。

十五、LangGraph 如何实现流式输出和实时响应？

1. 三种流式模式

LangGraph 提供三种不同粒度的流式输出：stream(mode="values") 在每个节点完成后返回完整的状态快照，适合调试和后端编排；stream(mode="updates") 只返回变化的键值对，开销最小，适合进度指示器；astream_events() 暴露最细粒度的事件流，包括每个 LLM token、工具调用生命周期和自定义事件，是前端实时渲染的首选。

2. Token 级流式传输

通过 astream_events() 配合 version="v2" 参数，可以捕获 on_chat_model_stream 事件，逐个获取 LLM 生成的 token。结合 FastAPI 的 StreamingResponse 和 Server-Sent Events（SSE），可以将 token 实时推送到前端浏览器，实现类似 ChatGPT 的打字机效果。关键是要在 LLM 初始化时设置 streaming=True，并在反向代理层禁用缓冲（如 Nginx 的 X-Accel-Buffering: no）。

3. 多通道事件订阅

astream_events() 不仅支持消息流，还可以订阅节点开始/结束、工具调用、自定义事件等多种事件类型。开发者可以通过 StreamWriter 向自定义通道推送领域特定的事件（如引用来源、进度指标、UI 描述），前端根据不同通道渲染不同的 UI 元素——主聊天面板显示回答文本，侧边栏显示子 Agent 活动，顶部进度条显示执行进度。

4. 生产环境的流式部署

LangGraph Cloud 原生支持流式端点，客户端 SDK 提供方法来消费这些流。对于自托管场景，可以通过 WebSocket 或 SSE 封装 LangGraph 的异步接口，实现生产级的实时响应。流式和检查点机制是正交的——无论是否流式输出，状态都会在每个节点完成后被持久化。

十六、LangGraph 如何处理并发和并行执行？

1. Send API 动态并发

Send 对象是 LangGraph 实现并行的核心 API。当一个节点返回 [Send("node_a", state_a), Send("node_b", state_b)] 这样的 Send 列表时，LangGraph 会在同一个超级步中为每个 Send 创建独立的执行分支，所有分支并发执行。执行完毕后，各分支的结果通过 reducer 自动合并回主状态。这种模式非常适合 fan-out/fan-in 场景，如同时查询多个数据源或并行处理多个文档。

2. 静态扇出模式

对于并发数量在编译期就固定的场景，可以使用多条 add_edge() 声明静态扇出。例如一个评估节点同时连接到三个并行评估 Worker，所有 Worker 完成后汇聚到一个聚合节点。这种方式实现简单但并发数量固定，不如 Send API 灵活。

3. 并发执行的关键注意事项

并发执行时有几个常见陷阱需要注意：首先，并发节点同时写入同一状态字段时会触发 InvalidUpdateError，必须为对应的状态键声明合适的 reducer（如 operator.add）；其次，Send 调度的是并行执行但并非真正的异步并发——如果节点函数中包含阻塞 I/O（如同步 HTTP 请求），仍然会串行执行，需要使用 async/await 实现真正的并发；最后，并发数过高可能触发 LLM API 的限流，建议通过 asyncio.Semaphore 限制最大并发数。

4. 错误传播与容错

默认情况下，如果任何一个 Send 目标抛出异常，整个步骤都会失败。生产环境中应在路由节点中使用 try-except 包装，或将错误路由到专门的容错节点，将失败分支的结果聚合到状态中而不是让整个流程崩溃。对于关键任务，还可以在每个 Worker 节点内部实现重试逻辑。