AI Agent 从"一个 LLM 循环调用工具"发展到"多个专业 Agent 协作完成复杂任务"，工作流编排成了关键问题。这篇整理当前主流的编排模式和实践经验。
单 Agent 的局限
最简单的 Agent 架构是 ReAct 循环：LLM 接收任务 -> 思考 -> 选择工具 -> 执行 -> 观察结果 -> 继续思考或返回答案。
这种架构在简单任务上表现不错，但面对复杂任务会遇到问题：
上下文膨胀：每次工具调用的输入输出都会累积到上下文中，几轮交互后 token 数爆炸，模型性能下降。
角色混乱：一个 Agent 同时扮演"规划者"、"执行者"、"审查者"等多个角色，系统提示变得臃肿，LLM 难以始终保持一致的行为。
错误累积：单 Agent 在长链条推理中犯错的概率随步骤数增长。一旦中间步骤出错，后续推理很可能在错误基础上继续。
多 Agent 系统将复杂任务分解给多个专业化的 Agent，每个 Agent 有明确的职责范围、独立的系统提示和工具集，通过编排层协调工作。
编排模式
Sequential（顺序链）
最简单的多 Agent 模式：Agent 按固定顺序依次执行，前一个的输出是后一个的输入。
典型场景是内容生产流水线：Research Agent 搜索资料 -> Writer Agent 撰写初稿 -> Editor Agent 润色修改 -> Reviewer Agent 做最终审查。
优点是实现简单、流程可预测、易于调试。缺点是灵活性差，不适合需要动态决策的场景。
Parallel（并行扇出）
将任务分发给多个 Agent 并行处理，最后汇总结果。
典型场景：多维度分析。比如要评估一个创业项目，同时让 Market Agent 分析市场、Tech Agent 评估技术可行性、Finance Agent 做财务预测，最后由 Summary Agent 综合三方结论。
优点是速度快（并行执行）、各 Agent 独立不互相干扰。缺点是 Agent 之间缺乏交互，可能产生矛盾的结论。
Hierarchical（层级管理）
一个 Manager Agent 负责任务规划和分配，多个 Worker Agent 负责执行。Manager 根据 Worker 的反馈动态调整计划。
这是目前最常用的复杂任务编排模式。Manager 的职责包括：
- 将用户需求分解为子任务
- 为每个子任务选择合适的 Worker Agent
- 监控执行进度，处理异常
- 综合各 Worker 的结果，生成最终输出
Manager 本身通常不直接调用工具，它的"工具"就是各个 Worker Agent。这种设计让 Manager 可以专注于高层规划，不被具体执行细节干扰。
Debate（辩论对抗）
多个 Agent 就同一问题提出不同观点，通过多轮辩论达成共识或提供多视角分析。
这种模式在需要批判性思考的场景中有效。比如代码审查：Developer Agent 写代码，Reviewer Agent 提出问题，Developer Agent 回应或修改，迭代直到 Reviewer 通过。
更激进的做法是设置 Red Team Agent 专门寻找漏洞，Blue Team Agent 负责防御。这在安全评估、策略制定等场景有应用价值。
状态管理
多 Agent 系统需要一个共享的状态层来协调各 Agent 的数据交换。
State Graph 模式：将工作流建模为有向图，节点是 Agent 或操作，边是状态转移条件。每个节点可以读写全局状态。LangGraph 就是基于这种模式设计的。
状态对象的设计很关键。一个常见的做法是定义一个结构化的状态 schema，包含任务描述、当前步骤、中间结果、错误信息等字段。每个 Agent 只能修改自己负责的字段。
状态持久化也很重要。复杂工作流可能运行很长时间（分钟到小时），需要把状态存到数据库，支持断点恢复。如果中间某个步骤失败，可以从上一个检查点重新开始，而不是从头来过。
Human-in-the-Loop
纯自动化的多 Agent 工作流在高风险场景中不可靠。Human-in-the-Loop 机制让人类在关键节点进行审查和干预。
常见的介入点：
- 任务规划确认：Manager Agent 分解完任务后，先让人类确认计划是否合理
- 关键决策审批：涉及资金、数据删除等不可逆操作时暂停等待审批
- 中间结果审查：长流程中定期展示中间结果，人类可以修正方向
- 异常升级：Agent 遇到无法处理的情况时主动请求人类帮助
实现上，就是在状态图的特定节点插入一个"人类节点"，这个节点会暂停工作流、发送通知、等待人类输入，然后根据输入继续或调整后续流程。
设计时需要注意超时处理：如果人类长时间不响应，工作流应该有默认行为（比如取消任务或走安全路径）。
错误恢复
多 Agent 系统的错误处理比单 Agent 复杂得多。
重试策略：对于临时性错误（网络超时、API 限流），在 Agent 级别做指数退避重试。
Fallback：主 Agent 失败时切换到备用 Agent。比如主 Agent 用的是 GPT-4，fallback 到 Claude 或本地模型。
回滚：如果某个步骤的执行结果被后续验证为不正确，需要能够回退状态到之前的检查点。这要求状态管理层支持版本化。
优雅降级：当部分 Agent 不可用时，系统应该能以降低功能但不崩溃的方式继续运行。比如分析报告中的某个维度生成失败，不应影响其他维度的输出。
实际案例：自动化代码审查
一个跑在实际项目中的多 Agent 代码审查系统：
Diff Analyzer Agent：解析 PR 的代码变更，提取修改的文件、函数、逻辑变化，生成结构化的变更摘要。
Logic Reviewer Agent：审查业务逻辑正确性。关注条件分支、边界情况、数据流。
Security Reviewer Agent：检查常见安全问题——SQL 注入、XSS、敏感信息泄露、权限检查缺失。
Style Reviewer Agent：代码风格、命名规范、注释质量。这个 Agent 的工具集包含 linter 和 formatter。
Summary Agent：汇总所有 Reviewer 的反馈，按严重程度分类，生成统一的审查报告。
编排流程是：Diff Analyzer 先执行（Sequential），然后三个 Reviewer 并行执行（Parallel），最后 Summary Agent 汇总（Sequential）。整个流程在 CI/CD pipeline 中自动触发。
效果上，这个系统能发现约 40% 的人类审查者会提出的问题，尤其在安全和风格方面命中率较高。逻辑审查的准确率还有待提升，目前作为辅助工具而非替代。
几点经验
- Agent 职责要清晰。一个 Agent 做好一件事，比一个 Agent 做很多事效果好。
- 先用简单编排。不要上来就设计复杂的多 Agent 系统，先试试单 Agent + 好的提示词能不能解决问题。
- 可观测性很重要。每个 Agent 的输入、输出、决策过程都要有日志，否则出了问题无法定位。
- 成本控制。多 Agent 意味着多倍的 LLM 调用量。要权衡效果提升和成本增加。
- 测试困难但必须做。准备一组标准测试用例，每次修改编排逻辑后跑一遍回归测试。
