在 AI Agent 开发中，流程控制正在从固定分支走向更灵活的运行时调度。LangGraph 作为围绕状态图组织 Agent 的框架，其早期使用通常依赖静态条件分支；而当任务需要按输入内容动态派发、并行处理多个子任务时，Command 与 Send 成为关键机制。相比静态图结构，这类能力更接近真实业务中的任务编排：系统需要根据中间结果决定下一步，甚至同时启动多个互相独立的工作流。
从静态分支到 Command：节点可以动态决定下一步
LangGraph 初学者最先接触到的通常是 add_conditional_edges。这种方式在编译期定义图的分支规则，适合结构明确的场景，例如 ReAct Agent 循环。它的优势是图结构清晰，Mermaid 可视化也更友好。
但更复杂的 Agent 场景并不总是能在编译阶段确定走向。例如，一个节点需要根据当前状态决定跳转到哪一个后续节点；或者一次处理多个任务分片；又或者在执行过程中同时更新状态并改变流程。此时，Command 提供了更动态的控制方式。
Command 是 LangGraph 提供的特殊返回对象，可以在 Node 函数返回时使用。它能够在一次返回中完成两件事：指定后续跳转目标，同时携带状态更新。素材中给出的示例是，根据数字是否为偶数，动态跳转到 even_node 或 odd_node，并同时更新状态中的提示信息。
Command 的跳转目标可以分为几种情况：
- 单个节点名：表示串行跳转到某个节点。
- 多个节点名组成的数组：表示并行执行不同节点，这些节点共享同一份 State。
- Send 对象组成的数组：表示并行执行同一个节点的多个实例，每个实例拥有独立的 State 副本。
这一差异是理解 LangGraph 动态控制流的关键。多个节点名数组适合“同一份上下文交给不同处理模块”的场景；Send 数组则适合“把任务拆成多个独立片段分别处理”的 Map 场景。
Send 的价值：面向 Map-Reduce 的并行派发
Send 是 LangGraph 中用于并行派发任务的调度指令。它的形式是 Send(node, arg)，但需要强调的是，Send 返回的是一个调度指令对象，而不是直接调用节点。它告诉底层调度器：创建一份新的 State 副本，将 arg 字典合并进该副本，然后在这个副本上执行目标节点。
这种机制非常适合 Map-Reduce 类任务。素材中的示例是：先将一组文档拆分为多个片段，再通过 Command(goto=sends) 将每个片段派发给 summarize_chunk 节点，最后由 merge_summary 节点汇总所有摘要。
在这个过程中，每个 summarize_chunk 实例处理的都是独立的 State 副本。它们不会互相覆盖输入内容，而是各自完成摘要生成，并将结果写入汇总字段。这正是 Send 与普通多节点并行的核心区别。
- Command(goto=[“nodeA”, “nodeB”])：多个不同节点并行执行，共享同一份 State。
- Command(goto=[Send(…), Send(…)])：同一个节点被多次调用，每个调用拥有独立 State 副本。
从应用角度看，后者更接近批量处理：例如长文档分块摘要、多资料并行检索、多工具调用结果汇总，或者将复杂任务拆解为多个同质子任务。
并行写状态的主要坑：InvalidUpdateError
素材中特别提到，并行执行时最常见的报错是 InvalidUpdateError。典型错误信息为：At key ‘summaries’: Can receive only one value per step. Use an Annotated key to handle multiple values.
原因在于，LangGraph 的 State 默认字段合并策略是覆盖。如果同一个 superstep 中，多个并行节点同时更新同一个 state key，引擎无法判断应保留哪个值，因此直接报错。
解决方式是使用 Annotated 为状态字段指定 reducer。例如，在 summaries 字段上使用 Annotated[list[str], operator.add]，多个并行节点返回的列表会自动拼接。
素材还给出了自定义 reducer 的示例：将旧列表与新列表合并后去重。这说明开发者可以根据业务需要定义状态合并逻辑，而不是只依赖默认覆盖行为。
另一个容易忽略的问题是返回值格式。若状态字段使用 operator.add 做列表拼接，并行节点必须返回列表格式。例如：
- 正确写法：return {“summaries”: [“摘要文本”]}
- 错误写法：return {“summaries”: “摘要文本”}
这类问题看似细节，但在并行 Map-Reduce 中会直接影响流程能否顺利汇总。
动态调度不是万能：可视化与调试仍需权衡
Command 和 Send 提升了 LangGraph 的表达能力，但素材也提醒了一个现实问题：Command 的动态跳转不会体现在 Mermaid 图中。这意味着可视化调试存在短板。如果分支逻辑简单，优先使用 add_conditional_edges 仍然更稳妥；只有在需要运行时动态决定路径、并行派发任务或进行 Map-Reduce 处理时，才更适合引入 Command 与 Send。
从 Agent 工程实践看，这种取舍很典型。静态图结构便于理解、展示和维护；动态调度则更贴近复杂任务的真实运行方式。开发者需要在可读性与灵活性之间做平衡。
对于正在构建多步骤 Agent 系统的团队来说，LangGraph 的 Command 与 Send 提供了一种从“流程固定”走向“任务动态分发”的路径。尤其是在长文本处理、并行检索、多工具调用和结果汇总等场景中，这种机制能够减少手工编排成本，让状态流转更贴近实际业务逻辑。但同时，状态合并规则、并行写入冲突和可视化缺失，仍然是开发过程中需要提前考虑的问题。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/agent-bian-pai-jin-ru-dong-tai-diao-du-jie-duan-langgraph
