AI Agent 工作流编排：从任务分解到多智能体协调
大多数 Agent 失败不是因为模型不够聪明，而是因为任务结构不对。
给一个 Agent 一个模糊的长任务，它会开始推理、执行、出错、自我修正，然后在某个节点彻底偏离轨道。这个现象在复杂任务里几乎是必然的，不是 Agent 能力的问题，是任务组织方式的问题。
工作流编排解决的就是这个问题：如何把一个复杂任务拆解成 Agent 可以可靠执行的结构，并在多个 Agent 之间协调执行。
先说清楚”工作流”是什么
Agent 工作流不是传统的 RPA 流程，也不是 Airflow 那种数据管道。
传统工作流的节点是确定性的函数：输入固定，输出固定，失败了按规则重试或走备用路径。Agent 工作流的节点是不确定性的推理过程：同样的输入可能产生不同的输出，执行路径可能动态调整，”完成”本身有时也需要模型来判断。
这个差异意味着 Agent 工作流的设计重点和传统工作流不一样：
- 传统工作流重点在流程定义：节点、边、触发条件，把逻辑画清楚就基本完成了
- Agent 工作流重点在状态管理和协调协议：每个节点执行完之后状态是什么，下一个 Agent 拿到的上下文是什么，如何判断一个步骤”完成了”
四种基础拓扑
复杂的 Agent 工作流都是以下四种基础拓扑的组合：
顺序链（Sequential Chain）
最简单的形式：Agent A 完成任务，输出传给 Agent B，B 完成后传给 C，依次执行。
适用场景：任务有明确的先后依赖，前一步的输出是后一步的必要输入。代码生成 → 代码审查 → 测试执行，是一个典型的顺序链。
核心问题：任意一节点的失败会阻断整个链路，且错误会在链中累积。A 产出了有问题的代码，B 在有问题的代码上做审查，C 在有问题的代码上跑测试——错误不会被自动放大，但也不会被自动过滤。
设计要点：顺序链里每个节点都需要明确的输出规范，和对上游输出质量的验证逻辑。不要假设上游一定是对的。
并行扇出（Parallel Fan-out）
把一个任务拆分成多个独立子任务，分发给多个 Agent 并行执行，最后由一个 Aggregator 汇总结果。
适用场景：子任务之间没有依赖，可以同时执行。对一个代码库的多个模块分别做安全扫描，是并行扇出的典型应用。
核心问题：Aggregator 的设计通常被低估。多个 Agent 各自返回结果，Aggregator 需要：合并结果、处理冲突（两个 Agent 对同一个问题给出了不同结论）、处理部分失败（三个 Agent 中一个超时了，另外两个的结果是否仍然有效）。
设计要点：在设计并行扇出时，先把 Aggregator 的逻辑想清楚，再决定要不要并行。一个糟糕的 Aggregator 会把并行带来的效率收益全部吃掉。
评审循环（Critic Loop）
一个 Generator Agent 产出结果，一个 Critic Agent 评估结果并给出反馈，Generator 根据反馈修改，循环直到达到质量标准或者超过最大迭代次数。
这是目前在代码生成、文档创作类任务里效果最显著的模式之一。
核心问题：循环终止条件。如果 Critic 的标准和 Generator 的能力上限之间有 gap，循环可能会在低质量的来回里转，永远收敛不到满足标准的结果。这不是逻辑错误，而是一个会悄悄消耗资源的工程问题。
设计要点：最大迭代次数是强制性的，不是可选的。同时要在每次迭代后记录 Critic 的评估理由，当迭代超过阈值时，把这些理由透出来给人工判断，而不是静默失败。
层级委派（Hierarchical Delegation）
Orchestrator Agent 负责任务规划和分解，把子任务委派给 Executor Agent，Executor 完成后汇报结果，Orchestrator 根据结果调整后续计划。
这是复杂任务中最接近”真实工作流”的模式，也是最难设计的一种。
核心问题：Orchestrator 和 Executor 之间的上下文传递。Orchestrator 知道全局目标，Executor 只知道被委派的子任务。当 Executor 遇到预期外的情况时，它是自行处理、还是上报给 Orchestrator？上报什么、怎么上报？这些协议如果没有显式设计，会成为 bug 的温床。
设计要点：委派不是甩手。Orchestrator 在委派任务时需要给 Executor 足够的上下文——不是全部上下文（那会把 context 撑爆），而是”完成这个子任务所需要知道的最小上下文集合”。这个最小集合的界定，是 Orchestrator 设计的核心挑战。
状态管理：被低估的核心
工作流里有一个问题很少被单独拿出来讨论：步骤与步骤之间，状态住在哪里？
一个简单的顺序链，A 的输出直接传给 B，状态只是一个变量。但稍微复杂一点的工作流，状态就变得复杂：当前完成了哪些步骤、哪些步骤失败了、哪些正在进行、整体进度是多少、如果某个步骤需要重跑从哪里恢复。
这些状态如果住在 Agent 的上下文里，就面临上下文窗口的限制，且工作流不可恢复——进程重启之后状态丢失。
成熟的做法是把工作流状态外化到独立的状态存储里，和 Agent 的执行过程解耦。每个步骤开始前从状态存储读取当前状态，结束后把新状态写回去。这样工作流就变得可恢复、可审计，也便于监控和调试。
这不是新想法——Temporal、Airflow 这些传统工作流引擎做的就是这件事。Agent 工作流面临的新挑战是：状态里不只有结构化数据，还有非结构化的 Agent 输出和推理过程。这部分的存储、检索、注入方式，和 Agentic Memory 的设计高度重合。两个问题不是独立的。
编排器的位置问题
一个反复出现的架构争议：Orchestrator Agent 应该是一个 LLM，还是一段确定性的代码？
两个极端都有问题。
纯 LLM Orchestrator 的问题是：任务规划本身也是不确定性推理，如果规划出了问题，你很难调试。而且规划阶段会消耗大量 token，成本高、延迟大。
纯代码 Orchestrator 的问题是：预先把所有可能的任务拆解路径都写成代码，要么不可能（复杂任务的分支太多），要么变成了一个过度设计的状态机，维护成本极高。
实践中更有效的方案是混合式：用确定性代码处理结构确定的部分（任务注册、状态管理、步骤调度、错误重试），用 LLM 处理需要推理的部分（理解任务意图、动态调整计划、判断子任务是否完成）。
这个混合的边界在哪里，没有通用答案，和具体任务的结构化程度直接相关。结构越清晰的任务，代码能承担的比例越高；越开放的任务，LLM 介入的比例越高。
失败处理：不是 try-catch
Agent 工作流的失败处理不能套用传统的异常处理思路。
传统程序里，异常有明确的类型，catch 里有明确的处理逻辑。Agent 的失败往往是模糊的：没有语法错误，但输出质量不达标；没有超时，但推理绕进了死循环；没有崩溃，但 Agent 产出了一个”看起来合理但实际有问题”的结果。
这类失败需要专门的检测机制，而不是等 Exception 出现：
- 输出验证：每个步骤的输出在进入下一步之前，经过结构化验证或者专门的验证 Agent 评估
- 进度监控：超过预期时间但未完成的步骤，主动触发检查，而不是等待超时
- 置信度阈值：对于需要判断”完成了吗”的步骤，Agent 给出置信度评分，低于阈值时升级到人工判断
失败处理的核心原则：失败应该尽早被发现，不要让错误在工作流里蔓延到最后一步才暴露。
可观测性是前提，不是附加项
一个工作流跑完了，你能看到什么？
最低限度：每个步骤的输入、输出、耗时、成功/失败状态。这些是调试的基础。
更重要的：步骤之间的上下文传递。A 传给 B 的究竟是什么？B 拿到之后做了什么决策？这个信息比步骤的输入输出更有价值，但也更难采集——它住在 Agent 的推理过程里，不是结构化的。
在我们内部的实践里，每个 Agent 步骤在执行结束后，会输出一个标准化的”执行摘要”：完成了什么、遇到了什么问题、做了哪些决策、对下游步骤有什么建议。这个摘要既作为工作流状态的一部分写入状态存储，也在监控系统里可查。
这不是完美的可观测性，但是够用的。够用的标准是：当工作流结果不符合预期时，你能在合理时间内定位到是哪个步骤、哪个决策出了问题。
工作流编排是 Agent 系统从单点能力到可靠生产的关键路径。
它不需要任何新的模型能力。现有的 LLM 已经足够聪明来执行编排好的子任务。缺的是把任务组织得足够清晰，让 Agent 的不确定性在有限的范围内发挥，而不是在开放空间里无控制地扩散。
这是一个工程问题，不是一个模型问题。