单 agent 循环上手简单，长大也简单。第一次看着一个 agent 想要在一次对话里调研话题、写报告、自我事实核查、产出最终结果——然后看着它跑偏、丢上下文、烧 200K tokens——你就理解了为什么人们开始把工作拆到多个 agent。
多 agent 编排不是一个模式，是四个。顺序、并行、分层、人工介入解决不同问题、有不同失败模式。这篇文章讲什么时候用哪种、生产中该盯什么、以及编排框架（持有 Run/Step 状态、重试、预算、trace 的那一层）怎么把它们粘起来。Router One 不做编排运行时——它是每步模型调用的网关层，运行 Run/Step 状态机的是你的框架，不是 Router One。
为什么要拆
讲模式之前先讲驱动约束。把工作拆到多个 agent 划算，需要满足下列至少一条：
- 不同角色想要不同 prompt。"研究"agent 的 system prompt 跟"写作"agent 不一样。两个塞进一个 prompt 让它翻倍变大，两个都变弱。
- **不同角色想用不同模型。**便宜快的模型做分流，贵且深的模型做硬步骤。每步有自己的模型身份后，路由决策更干净。
- **步骤想并行。**三个独立搜索不该顺序跑。
- **步骤想要不同工具权限。**代码 review agent 不该有 web search；研究 agent 不该有 shell 权限。
- **你想 checkpoint。**做完第 1 步停下来检查，再继续第 2 步——步骤是显式 agent 边界时容易得多。
都不沾的话，单 agent 循环就够。多数生产系统最终至少会落到其中一条。
模式 1：顺序
单 agent 最简单的扩展。Agent A 的输出是 Agent B 的输入。
[输入] → 研究员 → 提纲 → 写手 → 草稿 → 评审 → 终稿
什么时候用：
- 写作类任务，研究、起草、评审确实是不同技能。
- 每步输出小、形态明确（JSON 对象、列表、段落）的流水线。
- 任何想把中间产出拿出来调试的场景。
失败模式：
- agent 之间的信息丢失——研究员的语气在写手那里消失了。缓解：传给下游的上下文比你以为的需要的还要多；让下个 agent 自己决定忽略什么。
- 错误累积——第 1 步的错误事实在后面传播。缓解：高代价产出在研究和写作之间加一个验证步骤。
- 成本叠加——三个 agent 每个 $X 就是每任务 $3X。窄角色用便宜模型。
Router One 内部用顺序模式跑内容流水线：研究员用 Gemini 3.1 Pro（长上下文、便宜），写手用 Claude Sonnet 4.6（散文好），评审用 Claude Opus 4.7（判断力强）。三种模型、三个 prompt、一个组合任务。
模式 2：并行（Fan-out / Fan-in）
任务有独立子任务时，同时跑、合并结果。
┌── 搜索 A ─┐
[输入] → ─────┼── 搜索 B ─┼─→ 合成 → 终稿
└── 搜索 C ─┘
什么时候用：
- 多源研究（搜索 A、搜索 B、内部文档等）。
- 多视角分析（同一段代码以安全专家、性能专家、可靠性专家身份分别 review）。
- 同一份数据的独立变换。
失败模式：
- 浪费的并发——一个搜索就能解答的问题跑了 10 路并行。缓解：让一个 triage 步骤决定要不要 fan-out。
- 组合爆炸——合成器收到太多输入失焦。缓解：让每个并行 agent 返回结构化、紧凑的结果，不是大段文字。
- 成本——并行把固定开销（system prompt、schema）乘上去。缓解：把共享的 system prompt 压短，并在所选模型 API 支持时用它自带的 prompt 缓存；每个并行分支单独预算。
并行模式让 prompt 缓存变得重要。如果三个 agent 共享同一段长 system prompt，缓存一次后每个分支只为发散部分付费。可能比朴素版本便宜 5-10 倍。
模式 3：分层（管理者 + 工人）
管理者 agent 拆分任务、把子任务派给专家工人。工人回报；管理者决定继续派、重新规划，还是收尾。
[输入] → 管理者
├─→ 工人 1（返回）
├─→ 工人 2（返回）
└─→ 管理者重新规划
└─→ 工人 3（返回）→ 终稿
什么时候用：
- 结构在管理者思考之前未知的任务。
- 长程工作，顶层计划要根据中间发现调整。
- 跨多文件做 feature 的代码 agent：管理者决定哪些文件，工人去改。
失败模式：
- 管理者瓶颈——所有工人输出经过管理者，上下文堆积、变慢。缓解：管理者 prompt 保持短，让工人产出结构化总结而不是完整对话。
- 循环不收敛——管理者一直派工人不收敛。缓解：强制最大步数和预算；要求每个工人产出进展，不只是活动。
- 来源丢失——到第 14 步，你不记得第 7 步为什么发生。缓解：每次派遣记一条结构化 trace，带上管理者的推理。
在这里挣钱的是你的编排框架。每次管理者派遣应当是一个一等公民步骤，有自己的 token、延迟、成本；可以重放、暂停、预算到顶时杀掉。LangGraph、Inngest、Mastra 持有这套 Run/Step 状态机；Router One 跑在它们下面，提供每次调用面向客户的最终结果字段（最终模型与 provider、token、成本、延迟、状态和 API Key），你的框架再把这条调用记录关联到对应的 run step。生产环境下的封装见 生产环境 AI Agent 完整指南。
模式 4：人工介入
特定点上 agent 暂停、等人决策再继续。
[输入] → Agent → [提议方案] → 人审批 → Agent → ...
什么时候用：
- 高代价决策（发邮件、部署代码、扣客户钱）。
- 模型解决不了的非确定性（用什么语气？先做哪个 feature？）。
- 内部工具，人就是真正的用户。
- 任何受监管的场景。
失败模式：
- 永远阻塞——agent 等一个永远不来的审批。缓解：超时 + 升级策略。
- 走过场审批——人不读直接盖章。缓解：只在有意义的关卡上要审批。
- 上下文丢失——人几小时后回来时 agent 缓存状态没了。缓解：持久化 run 加显式暂停/恢复支持；预算窗口跨暂停存活。
暂停/恢复是较难做好的事情之一。把 agent 状态放内存里就脆；让你的编排框架持久化 Run/Step 状态、恢复时重读才稳。Router One 不替你跑状态机——挑一个会做这件事的框架（LangGraph、Inngest、Mastra，或自己写）。Router One 提供每次模型调用的最终结果字段；prompt、输出、状态变化、失败步骤以及 pause/resume 之间的完整审计，都应由你的编排框架持久化。
选哪个模式
粗略决策流：
| 问题 | 模式 |
|---|---|
| 是纯流水线？每步输入→输出清晰？ | 顺序 |
| 子任务真正独立、可并发？ | 并行 |
| 不思考就不知道结构、要中途调整？ | 分层 |
| 有需要人决定的步骤？ | 人工介入（与上配合） |
实践中，多数生产系统组合两到三个模式。一个代码 review agent 可能是：分层（顶层 agent 按文件派遣 review）、并行（每个文件三个 review 同时跑）、加上"准备合并"处的人工介入。
多 Agent 系统里的成本和延迟
规模化多 agent 系统时反复咬人的两件事：
**隐藏的成本累积。**单 agent 成本大致是对话长度的线性。多 agent 成本是所有 agent 输入输出之和，包括跨调用重复的 system prompt。朴素的 3 步顺序流水线可能是单 agent 等价物的 3-5 倍成本。
缓解：
- prompt 缓存——前提是你调用的模型 API 提供这个能力。缓存是模型层的特性：能不能用上、对账单有多大影响，取决于具体模型和请求怎么组织。别预设，去模型目录和自己的逐请求 trace 里核实；用不上缓存时，压短 system prompt 是永远有效的杠杆。
- 先便宜后贵的路由。Haiku/Flash 做分流和结构化；硬步骤保留给 Opus/Pro。
- 边走边截断。传过去的是需要的，不是完整对话。
**延迟堆叠。**顺序 agent 延迟相加；3 步流水线每步 5 秒就是端到端 15 秒。用户感受得到。
缓解：
- 数据依赖允许的地方都并行。
- 从最后一个 agent 流式输出，让用户看到进展。
- 知道顺序步骤要来时预热缓存。
每步模型选择见 AI 模型路由详解。网关层成本杠杆见 2026 年降低 LLM API 成本的 5 种方法。
可观测性：trace，不要 print
单 agent 调试是"读对话"。多 agent 调试没有结构化 trace 不可能做到。你的编排层应该给你：
- 每步的模型、prompt、输出、token、延迟、成本。
- 派遣之间的父子关系。
- 一步发生的原因（管理者的计划、错误重试、人工审批）。
- 重放能力——给一条 trace，能复现路径吗？
Router One 开箱提供每次网关调用面向客户的最终结果——最终模型与 provider、prompt-token / completion-token、延迟、成本、状态和 API Key。失败的上游尝试与 fallback 链不展示在这条 usage trace 中；需要排查事故时，支持人员可用 request_id 在运维日志中追查。把每次调用结果拼成多步 trace 是你编排框架的事；Router One 提供调用级的点，你的框架画线。Agent 规模下可观测性是什么意思见 生产环境 AI Agent 完整指南。
故障恢复
多 agent 系统失败方式和单 agent 不一样：
- 部分失败：10 个并行分支 9 个成功，1 个超时。提前决定：聚合手头有的，还是整个 run 失败？生产中带告警的部分聚合通常是对的。
- 流水线中段失败：7 步里第 4 步失败。只重试那一步，别重启整个 run。要求 Run/Step 持久化。
- 级联失败：上游 agent 的坏输出污染下游。便宜的缓解：步骤之间做 schema 校验。下个 agent 拒绝畸形输入而不是对垃圾推理。
一条有用的运营规则：每步派遣前必须声明什么算"成功"。编排器再去强制。
常见问题
该用 LangGraph、Mastra、Inngest，还是自己写？ 多数团队从其中一个框架起步。LangGraph 走图形流，Inngest 走事件驱动，Mastra 走类型化 agent 定义。框架选哪个比把编排概念想清楚没那么重要；以后能换。
编排必须用 Router One 吗？ 不必须——编排由框架处理。Router One 处理网关关心：模型调用路由、自动 provider fallback、每请求可观测，以及按 Key 的消费和限流控制。两者搭配：编排框架持有 Run/Step 状态机，每个 agent 步骤里调 Router One。
几个 agent 算多？ 超过 ~10 个不同 agent 角色后，系统就难以推理。接近时找合并机会——两个描述重叠的专家通常能合成一个。
像 AutoGPT 那种 agent 框架呢？ 那些是分层模式的早期原型。它们普及了想法，但默认循环动力学在生产中倾向发散。上面那些模式才是经得起的。
多 agent 流式输出？ 多数团队只对最后一个 agent 流式输出。中间 agent 产出结构化输出，不需要 stream。例外是非常长的顺序流水线，让用户看到进展时受益；那种情况下，步骤之间 stream 短的进度消息。
结论
多 agent 系统不是魔法；它是一种把不同角色、不同模型、不同访问边界显式编码的方法。顺序、并行、分层、人工介入是经得起的四个形态。成本和延迟会复合；可观测性和框架里的持久化 run 状态不再是可选项。
让多 agent 系统在生产中可负担的网关层支持，看 Router One 的 模型路由 怎么把每步留在对的模型上、skills 和 MCP 怎么让系统里单个 agent 实质性更有用。