中文译本。原文见同目录 README.md

第 18 课：Orchestrators（编排器）—— 管理 Agent 控制流

简介

前几课我们讲了 Agent 是什么、如何使用 tools，以及多个 Agent 如何协作。但还没有仔细看让这一切运转起来的那一层——orchestration layer（编排层）。

Orchestrator（编排器）是控制系统，它决定：接下来做什么？哪个 Agent 运行？什么进入 context？何时停止？它夹在用户目标与实际执行之间，协调一切。

若 Agents 是执行者，orchestrator 就是项目经理。

ELI5：把 orchestrator 想成电影导演

电影导演不演戏、不掌机、不打光。相反，他们协调各路专家：「摄影师，给特写。演员，把这句台词说出来。音效师，加上音乐。」他们决定顺序，场景不顺时处理问题，并推动一切走向成品影片。

Agent orchestrator 也一样——协调哪些 Agent 运行、以什么顺序、带什么输入，以及出错时怎么办。

核心要点： Orchestrator 管理你的 Agent 系统的控制流。选择合适的编排模式，是最重要的架构决策之一。

---

Orchestrator 实际做什么？

Orchestrator 管理四大核心关切：

1. Control flow（控制流）

决定接下来发生什么。Agent 应该调用 tool？交给另一个 Agent？向用户澄清？还是目标已达成可以停止？

2. Context assembly（上下文组装）

为每一步构建合适的 context。即选择哪些信息进入 LLM 的 context window——系统说明、相关 memory、tool 结果、对话历史——并避免窗口溢出。

3. State management（状态管理）

跟踪已完成什么、还要做什么、什么成功、什么失败。在多 Agent 系统中，还意味着管理 Agent 之间的共享状态。

4. Error handling（错误处理）

出错时决定怎么办。重试？换一种方法？回退到更简单的方式？升级给人类？

Orchestrator 运行核心的 Agent 循环：

               +----> Assemble Context
               |            |
               |            v
  Receive Goal |      Invoke LLM (Reason)
               |            |
               |            v
               |      Execute Action (Act)
               |            |
               |            v
               +---- Observe Result
                            |
                   Goal met? ---> Return Result

每绕这个循环一圈就是一步（step）。Orchestrator 决定何时继续循环、何时停止。

---

两类编排

最根本的设计决策是：你的 orchestrator 落在确定性控制与动态控制这一谱系的何处。

Deterministic（确定性 / 基于工作流）

控制流预先定义。Orchestrator 遵循固定蓝图——不咨询 LLM 来决定下一步。步骤按预定顺序、预定条件执行。

优势：

• 行为可预测——你确切知道会发生什么
• 易调试——像普通代码一样逐步走工作流
• 快——编排决策无需 LLM 调用
• 可靠——orchestrator 不会跑偏

局限：

• 无法处理工作流未设计的新情况
• 需要预先知道所有可能路径
• 改工作流就要改代码

示例： 始终按此运行的文档处理流水线：提取文本、分类文档类型、抽取实体、校验、存储。

Dynamic（动态 / LLM 驱动）

Orchestrator 用 LLM 决定下一步。每一步都会根据当前状态推理并选择下一动作。这就是经典的 ReAct 循环。

优势：

• 能处理新颖、开放式任务
• 计划失败时能适应
• 能处理开发者未预料的任务

局限：

• 较不可预测——相同输入可能走出不同执行路径
• 更难调试——「Agent 为什么那样做？」
• 更贵——编排用的 LLM 调用会叠加
• 可能卡在循环里或做出糟糕的路由决策

示例： 研究助手根据目前学到的内容，动态决定是搜网页、查数据库、读文档，还是向用户澄清。

Hybrid（混合，实务上的选择）

多数生产系统两者结合：整体结构用确定性编排，单个步骤内允许 LLM 驱动的灵活性。

示例： 客服系统有确定性外层流程（收工单、分类、路由到专家、核实解决、关闭），每一步内部是可自由推理如何处理具体任务的 LLM Agent。

---

核心编排模式

以下是最常用的模式，以及各自适用场景：

Sequential（顺序 / 流水线）

Agents 按定义好的顺序一个接一个执行。每个 Agent 的输出成为下一个的输入。

Input --> [Agent A] --> [Agent B] --> [Agent C] --> Output

何时使用：

• 有清晰、彼此递进的阶段的任务
• 精炼类工作流（起草、审查、编辑）
• 数据处理流水线（抽取、转换、校验）

何时避免：

• 各阶段彼此独立、本可并行时
• 需要回溯时（Agent C 失败要重跑 Agent A）

示例： 代码生成流水线：需求分析 Agent 产出规格，编码 Agent 写实现，测试 Agent 写测试，审查 Agent 查问题。

在 ADK 中，这是 SequentialAgent：

pipeline = SequentialAgent(
    name="code_pipeline",
    sub_agents=[analyzer, coder, tester, reviewer]
)

实现细节见 ADK SequentialAgent documentation。

Parallel（并行 / fan-out / gather）

多个 Agents 同时对同一输入执行。结果被收集并合并。

            +--> [Agent A] --+
            |                |
Input ------+--> [Agent B] --+--> Combine --> Output
            |                |
            +--> [Agent C] --+

何时使用：

• 需要多视角的独立分析
• 对延迟敏感、并行能省时间的任务
• 希望对同一输入获得多样观点

何时避免：

• Agents 需要彼此输出才能工作时
• 结果可能冲突且没有消解策略时

示例： Code review 中安全 Agent、性能 Agent、风格 Agent 同时审查同一 PR，结果合并成一份审查。

在 ADK 中，这是 ParallelAgent：

review = ParallelAgent(
    name="code_review",
    sub_agents=[security_reviewer, performance_reviewer, style_reviewer]
)

实现细节见 ADK ParallelAgent documentation。

Loop（循环 / 迭代精炼）

Agent 反复执行直到满足条件。包含两个重要子模式：

Generator-Critic（Maker-Checker）： 一个 Agent 产出，另一个评估，循环直到评估者通过。

+--> [Generator Agent] --> [Critic Agent] --+
|                              |            |
|         Not good enough -----+            |
|                                           |
+-------------------------------------------+
                    |
              Good enough --> Output

Progressive Refinement（渐进精炼）： 单个 Agent 多轮改进输出，像作者改草稿。

何时使用：

• 对质量敏感、第一次很少够好的任务
• 有清晰验收标准的任务
• 迭代改进类工作流

何时避免：

• 无法定义清晰停止条件时（有无限循环风险）
• 第一次通常就够好时

重要： 务必设置最大迭代次数。否则若 critic 永不通过，循环可能永远跑下去。

在 ADK 中，这是 LoopAgent：

refiner = LoopAgent(
    name="content_refiner",
    sub_agents=[writer, editor],
    max_iterations=5
)

实现细节见 ADK LoopAgent documentation。

Routing（路由 / handoff / dispatch）

输入被分类并导向专门 Agent。每个请求只由一个 Agent 处理。

            +--> [Billing Agent]
            |
Input --> [Router] +--> [Technical Support Agent]
            |
            +--> [General Inquiry Agent]

路由可以是：

• Deterministic： 基于规则的分类（消息含 "invoice" 就路由到 billing）
• LLM-driven： Router Agent 用推理挑选最合适的专家

何时使用：

• 有专门部门的客服
• 不同输入需要不同专长的多领域系统
• 希望完全移交控制权（同一时间只有一个活跃 Agent）

何时避免：

• 请求无法干净落入类别时
• 多个 Agents 需就同一请求协作时

Hierarchical（层级 / Coordinator-Worker）

主导 Agent 协调过程，同时把任务委派给专门的子 Agent。

                +---> [Research Agent]
                |
[Coordinator] --+---> [Analysis Agent]
                |
                +---> [Writing Agent]

Coordinator 会：

1. 把总目标拆成子任务
2. 把子任务分给合适的专家
3. 监控进度并处理依赖
4. 把结果合成最终输出

何时使用：

• 需要多种专长的复杂任务
• 计划事先未知、必须边做边形成时
• 研究类工作，一个领域的发现会影响接下来探索什么

何时避免：

• 简单任务不值得协调开销时
• 顺序流水线同样够用时

在 ADK 中，可用 AgentTool 把子 Agent 包装成 tools，让 coordinator 像调用函数一样调用它们。

Group chat（群聊 / 圆桌）

多个 Agents 参与共享对话，由 chat manager 协调。

[Chat Manager]
      |
      +---> [Agent A]: "I think we should..."
      |
      +---> [Agent B]: "Building on that..."
      |
      +---> [Agent C]: "I disagree because..."
      |
      +---> [Agent A]: "Good point, let me revise..."

何时使用：

• 建立共识
• 头脑风暴，多样视角能改善结果
• 迭代校验（多位专家审查并精炼）

何时避免：

• 效率比彻底性更重要时（群聊 token 成本高）
• 超过三个 Agents 参与时（对话易混乱）

---

如何选择合适模式

模式	可预测性	灵活性	Token 成本	最适合
Sequential	高	低	低	清晰的分步流程
Parallel	高	低	中（并发）	独立分析任务
Loop	中	中	可变	质量精炼
Routing	高	中	低	多领域分类
Hierarchical	中	高	较高	复杂多步研究
Group Chat	低	高	最高	共识与头脑风暴

决策流程图：

Is the task a clear step-by-step process?
  Yes --> Sequential

Are there independent subtasks that can run simultaneously?
  Yes --> Parallel

Does the output need iterative improvement?
  Yes --> Loop

Does the task type determine which specialist handles it?
  Yes --> Routing

Is the task complex and requires planning and delegation?
  Yes --> Hierarchical

Does the task benefit from multiple perspectives and debate?
  Yes --> Group Chat

---

组合模式

真实系统常嵌套多种模式。下面是内容创作系统的例子：

SequentialAgent("content_pipeline")
  |
  +-- ParallelAgent("research")
  |     +-- web_search_agent
  |     +-- database_query_agent
  |     +-- document_review_agent
  |
  +-- LlmAgent("writer")
  |     (uses research results to draft content)
  |
  +-- LoopAgent("refinement")
        +-- editor_agent
        +-- fact_checker_agent
        (loops until both approve)

这把并行研究、顺序推进和迭代精炼合成一个系统。在 ADK 中，每个 workflow agent 可以包含 LLM agents、其他 workflow agents 或自定义 agents。

---

在 Google Cloud 上用 ADK 做编排

Google 的 Agent Development Kit 提供三种内置 workflow agent 类型做确定性编排，另加 LLM 驱动的协调用于动态场景。

内置 workflow agents

Agent 类型	控制流	ADK 类
Sequential	按序运行 Agents	SequentialAgent
Parallel	同时运行 Agents	ParallelAgent
Loop	重复直到满足条件	LoopAgent

这些是确定性的——编排决策不涉及 LLM。LLM 只用在各个子 Agent 内部处理其具体任务。

LLM 驱动的协调

动态路由时，用带有子 Agents 的父级 LlmAgent（也称 Agent）。父 Agent 用其 LLM，根据对话与当前状态决定委派给哪个子 Agent。路由与层级模式就是这样实现的。

自定义 Agents

编排逻辑套不进内置类型时，可扩展 BaseAgent，用任意控制流创建自定义 Agents。

Agent-as-tool

ADK 可用 AgentTool 把任意 Agent 包装成 tool。这样 coordinator Agent 就能像函数调用一样调用子 Agents，并拿到结构化结果。

完整实现细节见：

• ADK Workflow Agents
• ADK Multi-Agent Systems
• Multi-Agent Patterns in ADK - Google Developers Blog

---

框架对比

ADK 只是提供编排能力的框架之一。主要选项对比如下：

框架	方式	优势	注意点
Google ADK	三种确定性原语（Sequential、Parallel、Loop）+ LLM 驱动协调	工作流与推理清晰分离；可部署到 Vertex AI Agent Engine	较新，社区小于 LangChain
LangGraph	基于图的工作流（节点与边）	对复杂分支与条件逻辑支持最强；可观测性成熟	学习曲线更陡
CrewAI	角色模型，Agents 像团队成员一样定义	最快产生价值；直观的 YAML 驱动配置	复杂企业场景可能不够深入
AutoGen (Microsoft)	对话式架构，动态角色扮演	适合 human-in-the-loop 与多方对话	生产环境搭建复杂度高
Claude Agent SDK	Orchestrator-worker，隔离的 context windows	子 Agents 用隔离 context，只回传相关信息	Anthropic 专用

选择取决于优先级：要 Vertex AI 集成与清晰工作流原语选 ADK；要复杂图流程选 LangGraph；要快速用角色化团队起步选 CrewAI。

---

最佳实践

从简单开始，需要时再加复杂度

带好工具的单个 Agent，往往优于编排糟糕的多 Agent 系统。从最简单能工作的方案开始：

1. 带 tools 的单个 Agent
2. Sequential 流水线（若需要分阶段）
3. Parallel 执行（若需要速度）
4. 完整多 Agent 协调（若需要专业化）

不要因为 hierarchical 多 Agent 听起来厉害就直接上。只有当单个 Agent 明显搞不定时，再增加 Agents。

让模型匹配任务

编排里不是每个 Agent 都需要同一模型。分类 router 可用又快又便宜的模型（Gemini Flash-Lite）；复杂推理 Agent 应用更强模型（Gemini Pro）。这能显著省成本。

设置迭代上限

任何循环或递归编排都必须有最大迭代次数。否则永远达不到自身标准的 Agent 会一直跑。精炼循环的合理默认是 3–5 次。

在步骤之间校验

顺序流水线中，把 Agent 输出交给下一个之前先校验。Agent A 的畸形或跑题结果会级联到 B、C，浪费 tokens 并产出垃圾。

跨 Agent 管理 context

多 Agent 系统中，context windows 涨得很快。控制手段包括：

• 在 Agents 之间传递前先总结输出
• 用外部状态存储承载大型共享数据
• 只给每个 Agent 它需要的 context，而不是全部
• 对长任务使用 context compaction（滑动窗口、摘要）

为可观测性做埋点

按 Agent、按编排运行跟踪表现：

• 每步延迟
• 每个 Agent 的 token 用量
• 每步成功/失败率
• 端到端任务完成率

用分布式追踪（如 OpenTelemetry）跟随请求穿过多个 Agents。出错时调试必不可少。

实现指引见 ADK Tracing documentation 与 Google Cloud Trace。

为失败而设计

Agents 会失败。Tools 会返回错误。LLMs 会幻觉。你的 orchestrator 需要优雅处理：

• 带退避的重试，应对瞬时错误（API 超时、限流）
• 回退策略，应对持续失败（换 tool、用更简单模型）
• 断路器，防止级联失败
• 升级给人类，作为关键任务的最后手段

---

常见反模式

反模式	问题	修复
编排过度	单 Agent 就能做的事却上多 Agent	从单个 Agent 开始，需要再加
Agents 无专长	多个 Agents 做的事大致相同	给每个 Agent 清晰不同的角色与专长
共享可变状态	并发 Agents 写同一状态，导致竞态	用不可变消息或适当的状态锁
无迭代上限	退出条件永不满足时循环永远跑	始终设置 max_iterations
Context window 膨胀	把完整对话历史传给流水线中每个 Agent	步骤间总结与裁剪
该动态却用确定性	需要自适应推理的任务却用固定流水线	对不可预测任务类型用 LLM 驱动路由
该确定性却用动态	序列清晰已知的任务却用 LLM 路由	用 workflow agents 省成本并提高可靠性

---

关键要点

• Orchestrator 管理控制流、上下文组装、状态与错误处理
• 两类根本类型：确定性（可预测、便宜、有限）与 LLM 驱动（灵活、昂贵、较不可预测）
• 多数生产系统用混合——确定性结构，步骤内保留 LLM 灵活性
• 核心模式：sequential、parallel、loop、routing、hierarchical、group chat
• 模式可组合——嵌套简单部件构建复杂系统
• ADK 提供 SequentialAgent、ParallelAgent、LoopAgent 做确定性编排，另加 LLM 驱动协调做动态路由
• 从简单开始。装备良好的单个 Agent 胜过编排糟糕的团队
• 设迭代上限、步骤间校验、积极管理 context，并为失败而设计

---

延伸阅读

• ADK Workflow Agents
• Multi-Agent Patterns in ADK
• Anthropic - Building Effective AI Agents
• Microsoft Azure - AI Agent Orchestration Patterns
• LangGraph Documentation
• CrewAI Documentation

---

上一课：Agent Skills | 下一课：Where to Go From Here ->