第7章 流程控制模式：链式调用、路由与并行化

本章来源：综合自 Agentic Design Patterns 第1-3章（链式调用、路由、并行化的模式设计与实现）、Practical Guide to Context Engineering（上下文工程视角）

核心问题 -- 本章要解答什么

当我们让一个智能体完成复杂任务时，一个不可回避的问题是：如何编排多个 LLM 调用之间的控制流？ 这不是单纯的"写好 prompt"能解决的问题。一个市场分析任务可能需要先总结报告、再提取趋势、再撰写邮件；一个客服系统需要先判断意图、再路由到对应的专家模块；一个研究智能体需要同时搜索多个数据源、再汇总结果。

这三种场景分别对应三种基础的流程控制模式：链式调用（Prompt Chaining）、路由（Routing） 和 并行化（Parallelization）。它们构成了所有复杂 Agentic 系统的控制流骨架。理解这三种模式的设计空间、适用场景和工程取舍，是构建可靠智能体系统的前提。

设计空间 -- 可选方案与取舍

7.1 为什么需要流程控制模式

单一 prompt 处理复杂任务面临几个根本性限制：

• 指令忽略（Instruction Neglect）：当 prompt 中包含过多约束和步骤时，LLM 容易遗漏部分指令
• 上下文偏移（Contextual Drift）：在长文本生成过程中，模型逐渐偏离初始目标
• 错误传播（Error Propagation）：早期步骤的微小错误在后续生成中被放大
• 认知负荷过载：过多的并发要求增加模型产生幻觉的概率

流程控制模式的核心思想是将"一个复杂的大任务"分解为"多个简单的小任务"，每个小任务由一个聚焦的 prompt 处理，任务之间通过明确的数据流连接。这种分而治之的策略降低了单次调用的认知负荷，同时引入了中间验证和纠错的机会。

7.2 三种模式的设计空间对比

维度	链式调用	路由	并行化
控制流结构	线性序列	条件分支	扇出-汇聚
数据依赖	强顺序依赖	分类后独立	无依赖（并行段）
延迟特征	累加（各步骤之和）	分类 + 单路径	取决于最慢分支
典型用例	多阶段文本处理	意图分发	多源信息收集
复杂度代价	低	中（需维护路由逻辑）	高（并发管理）
可观测性	好（逐步追踪）	好（路由决策可审计）	中（需聚合日志）

这三种模式并非互斥，实际系统通常将它们组合使用。例如，一个文档分析系统可能先通过路由判断文档类型，再通过并行化同时提取不同维度的信息，最后通过链式调用将提取结果综合成最终报告。

架构解析 -- 深入分析主流架构

7.3 链式调用（Prompt Chaining）

7.3.1 核心机制

链式调用是最基础的流程控制模式，其核心是将复杂任务分解为顺序执行的子任务链：

输入 → [Prompt 1] → 中间结果1 → [Prompt 2] → 中间结果2 → [Prompt 3] → 最终输出

每个步骤的输出作为下一个步骤的输入，形成数据依赖链。这种模式的关键优势在于：

1. 每步聚焦单一任务：降低模型的认知负荷，提升单步输出质量
2. 中间结果可验证：可以在步骤之间插入确定性校验逻辑
3. 角色分配：每个步骤可以赋予模型不同的角色（如"市场分析师"→"趋势研究员"→"报告撰写者"），利用角色设定提升输出质量
4. 结构化中间输出：通过要求中间步骤输出 JSON 或 XML 等结构化格式，确保数据在步骤之间无歧义传递

7.3.2 典型应用场景

信息处理管道：从文档中提取文本 → 生成摘要 → 抽取关键实体 → 查询知识库 → 生成综合报告。每步处理一个明确的子任务。

代码生成与精炼：理解需求生成伪代码 → 编写初始代码 → 静态分析发现问题 → 修正代码 → 添加测试。迭代式的质量提升。

多模态推理：从图像中提取文字 → 将文字与标签关联 → 结合表格数据生成解读。跨模态信息逐步整合。

7.3.3 结构化输出的关键作用

链式调用的可靠性高度依赖步骤之间的数据完整性。如果某步的输出是自由文本，下一步可能因解析失败而崩溃。因此，指定结构化输出格式（JSON、XML）是工程实践中的关键决策：

{
  "trends": [
    {
      "trend_name": "AI-Powered Personalization",
      "supporting_data": "73% of consumers prefer brands using personal information..."
    }
  ]
}

结构化输出确保数据机器可读、无歧义解析，是构建健壮多步 LLM 系统的基石。

7.3.4 与上下文工程的关系

链式调用天然与上下文工程（Context Engineering） 形成互补。上下文工程关注的是在 token 生成之前为 AI 构建完整的信息环境，包括系统提示、检索文档、工具输出和隐式数据（用户身份、交互历史等）。链式调用提供了逐步构建这一信息环境的机制——每个步骤都可以通过工具调用或检索获取新的上下文信息，逐步丰富后续步骤的输入。

7.4 路由（Routing）

7.4.1 核心机制

路由模式在智能体的操作框架中引入条件逻辑，使系统从固定执行路径转变为动态决策：

输入 → [路由器] → 分析意图/类型
                    ├── 路径A → [专家模块A]
                    ├── 路径B → [专家模块B]
                    └── 路径C → [专家模块C]

路由的本质是将分类决策与执行逻辑解耦。路由器只负责判断"该走哪条路"，不负责执行具体任务。这种关注点分离使系统更易于扩展和维护。

7.4.2 四种路由实现策略

基于 LLM 的路由：直接提示 LLM 分析输入并输出分类标识符。优点是灵活性最高，能处理语义模糊的输入；缺点是引入额外的 LLM 调用延迟和成本。适合需要理解自然语言意图的场景。

基于嵌入的路由：将输入转换为向量嵌入，与预定义路由的嵌入进行相似度比较。基于语义相似性做决策，适合输入空间可以预先定义的场景。

基于规则的路由：使用关键词匹配、正则表达式或 if-else 逻辑进行分类。速度最快、最确定，但灵活性最差，无法处理新颖或模糊的输入。

基于训练模型的路由：使用专门训练的分类器进行路由决策。与 LLM 路由的区别在于路由逻辑编码在模型权重中，不依赖推理时的 prompt。训练数据可以用 LLM 合成，但推理时不使用 LLM。

这四种策略形成一个灵活性-确定性谱系：规则路由最确定但最不灵活，LLM 路由最灵活但最不确定。实际系统通常采用混合策略——先用规则过滤明确的模式，对剩余的模糊输入再使用 LLM 判断。

7.4.3 路由的多层应用

路由机制可以在智能体操作周期的多个节点部署：

• 入口路由：对主任务进行分类，决定整体处理策略
• 中间路由：在处理链的中间节点根据中间结果选择后续路径
• 工具选择路由：在工具集合中选择最合适的工具执行当前子任务

这种多层路由使系统能够在不同粒度上做出自适应决策。

7.5 并行化（Parallelization）

7.5.1 核心机制

并行化模式通过同时执行多个独立任务来缩短总执行时间：

                    ┌→ [任务A] → 结果A ─┐
输入 → [分发器] ──→ [任务B] → 结果B ──→ [聚合器] → 最终输出
                    └→ [任务C] → 结果C ─┘

核心思想是识别工作流中不依赖彼此输出的环节并同时执行。这在涉及外部 API 调用（有网络延迟）的场景中尤其有效。

7.5.2 并发与并行的区别

工程实践中需要区分两个概念：

• 并发（Concurrency）：通过事件循环在单线程上交替执行多个任务。Python 的 asyncio 提供的是并发——当一个任务等待网络响应时切换到另一个任务。受 GIL 限制，同一时刻仍只有一个线程执行 Python 代码。
• 并行（Parallelism）：真正在多个 CPU 核心上同时执行计算。需要多进程或多线程（对 I/O 密集任务）。

对于 LLM 智能体的典型场景（大量 API 调用，I/O 密集），并发通常已经足够。真正的瓶颈在等待 API 响应的网络延迟上，而非 CPU 计算。

7.5.3 典型应用场景

场景	并行任务	聚合方式
公司调研	新闻搜索 / 股票数据 / 社交媒体 / 数据库查询	综合报告
客户反馈分析	情感分析 / 关键词提取 / 分类 / 紧急识别	多维度仪表盘
旅行规划	航班查询 / 酒店搜索 / 活动推荐 / 餐厅评分	完整行程方案
内容生成	标题生成 / 正文起草 / 图片搜索 / CTA 文案	组装完整邮件
A/B 测试	用不同 prompt/模型生成多个变体	选择最优方案

7.5.4 并行化的工程复杂度

采用并行架构引入了显著的复杂度成本：

• 错误处理：某个并行分支失败时如何处理？是等待所有分支完成还是快速失败？
• 超时管理：不同分支可能有不同的响应时间，需要合理的超时策略
• 结果聚合：多个分支的结果格式可能不同，需要统一的聚合逻辑
• 调试困难：并发执行使日志交错，问题定位更困难
• 资源竞争：并行的 API 调用可能触发速率限制

这些复杂度需要在"性能提升"和"系统可维护性"之间做权衡。

关键实现决策 -- 工程实践中的关键选择点

7.6 框架支持

主流 Agentic 框架为这三种模式提供了不同层次的抽象：

LangChain/LCEL 通过管道运算符 | 实现链式调用，RunnableBranch 实现路由，RunnableParallel 实现并行化。其表达式语言（LCEL）使组合直观：

# 并行执行 + 链式综合
map_chain = RunnableParallel({
    "summary": summarize_chain,
    "questions": questions_chain,
    "key_terms": terms_chain,
    "topic": RunnablePassthrough(),
})
full_chain = map_chain | synthesis_prompt | llm | StrOutputParser()

LangGraph 基于状态图架构，通过节点（Node）和边（Edge）定义计算图。状态在节点之间流转，条件边实现路由，多个无依赖节点可从同一状态节点启动实现并行。特别适合需要状态管理和循环控制的复杂场景。

Google ADK 提供了 SequentialAgent（链式）、ParallelAgent（并行）等原语，以及通过 sub_agents 和 instruction 实现的自动路由（Auto-Flow）。模型通过分析子智能体的 description 自动决定委托目标。

7.7 模式组合策略

实际系统中三种模式通常组合使用。常见的组合策略包括：

路由 + 链式：先分类再按对应路径执行多步处理。适用于不同类型输入有不同处理流程的场景。

并行 + 链式：先并行收集信息，再顺序综合。适用于需要多源数据融合的场景。这是最常见的组合——并行阶段负责独立的数据收集，链式阶段负责有依赖的数据整合和精炼。

路由 + 并行：路由后的多个路径并行执行。适用于同一输入需要多种处理方式的场景。

7.8 设计决策清单

构建流程控制时需要回答以下问题：

1. 分解粒度：任务应分解为多少步？粒度过细增加延迟和成本，粒度过粗损失可靠性
2. 中间格式：步骤之间传递自由文本还是结构化数据？结构化数据更可靠但限制了灵活性
3. 失败策略：某步失败时重试、跳过还是中止？是否需要回退机制？
4. 路由粒度：使用粗粒度路由（少量大类）还是细粒度路由（多个专门路径）？
5. 并行上限：同时发起多少并行调用？需要考虑 API 速率限制和成本

前沿动态 -- 学术界/工业界最新进展

7.9 动态工作流编排

传统的流程控制模式使用预定义的静态拓扑。前沿研究方向是让 LLM 自身决定工作流的拓扑结构——模型不仅执行任务，还负责规划任务之间的编排方式。HuggingGPT [Shen et al., 2023] 即是这一方向的早期探索，由LLM规划任务拓扑并自动调度Hugging Face上的专家模型。这种"元编排"能力使系统能够根据输入的特性动态选择最优的处理流程，而非依赖预先设计的固定管道。

7.10 自适应路由与成本优化

路由模式正在与资源感知优化深度融合。不再是简单的"意图→路径"映射，而是综合考虑查询复杂度、响应延迟要求、API 成本预算等因素，动态选择处理策略。例如，简单查询路由到轻量模型（如 Gemini Flash），复杂推理路由到重量模型（如 Gemini Pro），API 不可用时自动回退到备选模型。

7.11 编译时优化

DSPy [Khattab et al., 2023] 等框架探索将 prompt 链"编译"为优化后的执行图，通过自动搜索每步的最优 prompt 和参数，系统性地提升链式调用的整体质量。这种方法将手动的 prompt 工程转变为自动化的优化过程。

本章小结

链式调用、路由和并行化是 Agentic 系统控制流的三个基本构件。链式调用通过顺序分解降低单步复杂度；路由通过条件分支实现自适应行为；并行化通过并发执行缩短总延迟。三者的组合构成了从简单对话机器人到复杂自主系统的控制流骨架。

⚠️ 已知局限：流程控制模式的核心假设是任务可以被清晰地分解为独立子任务，但在实际场景中这一假设经常不成立。链式调用中，前一步的输出格式偏差会级联放大，导致后续所有步骤失败（错误雪崩效应）。路由模式在输入语义模糊时（如"帮我处理这个"）准确率显著下降。并行化中，当某个分支返回与其他分支矛盾的结果时，聚合器缺乏可靠的冲突解决机制。在生产实践中，约15-20%的复杂查询会触发流程控制的边缘情况。

核心设计原则是：每个 LLM 调用应该足够简单和聚焦。当你发现一个 prompt 在试图同时完成多件事时，就是引入流程控制模式的信号。将复杂问题分解为聚焦的子问题，通过明确的数据流将它们连接起来，在步骤之间插入验证和纠错逻辑——这是构建可靠 Agentic 系统的基础方法论。