智能体设计模式（一）：提示链、路由与并行化

智能体设计模式（一）：提示链、路由与并行化

🎯 本系列文章基于《Agentic Design Patterns》一书，用"教与学专家"风格带你掌握21种智能体设计模式。本篇涵盖第1-3章核心模式。

---

第一章：提示链（Prompt Chaining）

把大象装进冰箱需要几步？三步。AI 处理复杂任务也是一样的道理。

---

一、一句话定位

提示链解决什么问题？

提示链 = 把复杂任务拆成多个简单步骤，让 AI 一步一步来
就像流水线作业：每个工人只做一件事，最后组装成完整产品

适合谁学？

• 想让 AI 处理复杂任务的开发者
• 正在构建智能体（Agent）系统的工程师
• 对提示工程感兴趣的技术人员

不适合谁？

• 只需要简单问答的场景（杀鸡焉用牛刀）

---

二、核心框架（知识骨架）

核心观点：

单一提示处理复杂任务 = 让一个人同时做十件事 = 手忙脚乱、顾此失彼
提示链 = 分工合作 = 每步专注一件事 = 稳定可靠

关键概念速查表：

概念	大白话解释	生活比喻	一句话记忆
提示链	把任务拆成多步，前一步输出给下一步	流水线生产	分而治之
上下文传递	前一步的结果传给下一步	接力赛传棒	承上启下
结构化输出	用 JSON 等格式规范输出	标准化零件	规范接口
模块化	每步独立，可单独调试	乐高积木	拆开好修

知识地图：

复杂任务 → 拆解子任务 → 设计提示链 → 结构化输出 → 组装结果
    ↓           ↓            ↓            ↓           ↓
  识别问题    分而治之     逐步执行      规范传递    最终答案

---

三、深入浅出讲解

开场钩子 🎣

想象一下，你让一个实习生同时做这些事：

1. 分析一份 50 页的市场报告
2. 总结核心发现
3. 识别三大趋势并找出数据支撑
4. 给市场团队写一封邮件

结果会怎样？大概率是：报告总结得还行，但数据提取乱七八糟，邮件写得像机器人。

这就是单一提示的困境 ------ 认知负荷过重，顾此失彼。

---

【概念1：为什么单一提示会失败？】

一句话是什么：让 AI 一次做太多事，它会"精神分裂"。

生活化比喻：

想象你在餐厅点餐，对服务员说：
"我要一份牛排，五分熟，配黑椒汁，不要洋葱，
 再来一份沙拉，换成油醋汁，加双份鸡肉，
 甜点要提拉米苏，咖啡要美式，少冰，
 对了，帮我问问厨师今天有没有特价菜，
 还有，能不能把账单分成三份..."

服务员：😵‍💫（大概率漏掉几项）

单一提示的五大"翻车"场景：

问题类型	表现	后果
指令忽视	漏掉部分要求	输出不完整
上下文漂移	忘了前面说的	前后矛盾
错误放大	早期小错滚雪球	结果全错
窗口超限	信息太多装不下	信息丢失
幻觉增加	认知负担重	胡编乱造

幽默包装：

让 AI 一次做十件事，就像让程序员同时：
- 写代码
- 开会
- 回邮件
- 改 Bug
- 写文档
- 做 Code Review
- 面试候选人
- 学习新技术
- 汇报工作
- 思考人生

结果？代码里写着"亲爱的面试官，这个 Bug 已在会议中修复，详见人生文档"。

---

【概念2：提示链的核心思想】

一句话是什么：把大任务拆成小任务，一步一步来。

生活化比喻：

把大象装进冰箱需要几步？

步骤1：打开冰箱门
步骤2：把大象放进去
步骤3：关上冰箱门

提示链的思路完全一样！

引经据典：

"治大国如烹小鲜" ------ 老子

翻译成技术语言：
处理复杂任务如同做菜，要一步一步来，火候、调料、时间，各有讲究。

实际案例：市场报告分析

❌ 错误做法（单一提示）：

请分析这份市场报告，总结核心发现，识别三大趋势并提取数据，
然后写一封邮件给市场团队。

✅ 正确做法（提示链）：

提示1（总结）："请总结以下市场报告的核心发现：[报告文本]"
    ↓ 输出传递给下一步
提示2（趋势）："基于以上总结，识别三大趋势并提取支持数据：[上一步输出]"
    ↓ 输出传递给下一步
提示3（邮件）："根据以下趋势和数据，给市场团队写一封邮件：[上一步输出]"

为什么这样更好？

• 每步只做一件事 → 专注度高
• 前一步验证后再进行下一步 → 错误不累积
• 每步可以单独调试 → 问题好定位

---

【概念3：结构化输出的重要性】

一句话是什么：用 JSON 等格式规范输出，让数据传递不出错。

生活化比喻：

想象两个工厂对接：

工厂A（生产螺丝）→ 工厂B（组装产品）

如果工厂A的螺丝：
- 有的是公制，有的是英制
- 有的带包装，有的散装
- 有的标了规格，有的没标

工厂B会疯掉！

解决方案：制定标准
- 统一公制
- 统一包装
- 统一标签格式

这就是结构化输出的意义！

代码示例：

趋势识别步骤的输出，应该格式化为 JSON：

{
  "trends": [
    {
      "trend_name": "AI 个性化推荐",
      "supporting_data": "73% 的消费者更喜欢使用个人信息提供相关购物体验的品牌"
    },
    {
      "trend_name": "可持续品牌",
      "supporting_data": "ESG 相关产品销售额五年增长 28%，而普通产品仅增长 20%"
    }
  ]
}

好处：

• 机器可读，精确解析
• 无歧义，不会理解错误
• 下一步可以直接使用

---

【概念4：提示链的实际应用场景】

场景1：信息处理工作流

提取文本 → 清洗数据 → 总结内容 → 提取实体 → 查询知识库 → 生成报告

场景2：复杂问答

问题："1929年股市崩盘的原因是什么？政府如何应对？"

提示1：识别子问题（崩盘原因、政府对策）
提示2：研究崩盘原因
提示3：研究政府对策
提示4：整合成完整答案

场景3：数据提取与转换

OCR识别 → 文本提取 → 数据规范化 → 数学计算（外部工具）→ 结果整合

场景4：内容生成

生成主题 → 用户选择 → 生成大纲 → 逐段撰写 → 审阅润色

场景5：代码生成

理解需求 → 生成伪代码 → 编写初稿 → 识别问题 → 优化代码 → 添加测试

---

四、实践示例（代码演示）

场景：从产品描述中提取技术规格，并转换为 JSON 格式。

import os
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

# 初始化语言模型
llm = ChatOpenAI(temperature=0)

# --- 提示 1: 提取信息 ---
prompt_extract = ChatPromptTemplate.from_template(
    "Extract the technical specifications from the following text:\n\n{text_input}"
)

# --- 提示 2: 转换为 JSON ---
prompt_transform = ChatPromptTemplate.from_template(
    "Transform the following specifications into a JSON object with 'cpu', 'memory', and 'storage' as keys:\n\n{specifications}"
)

# --- 构建提示链 ---
# 第一步：提取规格
extraction_chain = prompt_extract | llm | StrOutputParser()

# 完整链：提取 → 转换
full_chain = (
    {"specifications": extraction_chain}
    | prompt_transform
    | llm
    | StrOutputParser()
)

# --- 运行 ---
input_text = "The new laptop model features a 3.5 GHz octa-core processor, 16GB of RAM, and a 1TB NVMe SSD."

final_result = full_chain.invoke({"text_input": input_text})
print(final_result)

输出结果：

{
    "cpu": "3.5 GHz octa-core",
    "memory": "16GB",
    "storage": "1TB NVMe SSD"
}

代码解读：

输入文本 → [提示1: 提取规格] → 规格文本 → [提示2: 转JSON] → JSON输出
              ↑                    ↓
           专注提取              专注格式化

---

五、精华提炼（去废话版）

核心要点（只保留干货）：

1. 分而治之：复杂任务拆成简单步骤 → 每步专注一件事
2. 链式传递：前一步输出 = 下一步输入 → 信息不丢失
3. 结构化输出：用 JSON 规范格式 → 传递不出错
4. 模块化设计：每步独立 → 调试方便

必须记住的：

提示链 = 流水线 = 分工合作 = 稳定可靠

---

六、行动清单

立即可做（5分钟内）：

• 找一个你之前用单一提示失败的任务
• 尝试把它拆成 2-3 个步骤

本周实践：

• 用 LangChain 实现一个简单的两步提示链
• 尝试在步骤间使用 JSON 格式传递数据

进阶挑战：

• 在提示链中加入外部工具调用
• 实现一个带条件分支的提示链

---

七、常见误区

误区1：所有任务都要用提示链

❌ 错误：简单问答也拆成三步
✅ 正确：简单任务用简单方法，复杂任务才需要提示链

误区2：步骤越多越好

❌ 错误：把任务拆成 10 个步骤
✅ 正确：步骤数量适中，每步有明确目的

误区3：忽视结构化输出

❌ 错误：让 AI 自由发挥输出格式
✅ 正确：明确指定输出格式（JSON/XML），确保下一步能正确解析

---

八、学习检查

基础理解：

• 能解释为什么单一提示处理复杂任务会失败
• 能说出提示链的核心思想（分而治之）
• 理解结构化输出的重要性

实践能力：

• 能把一个复杂任务拆解成多个步骤
• 能用代码实现一个简单的提示链
• 能设计步骤间的数据传递格式

进阶理解：

• 理解提示链与并行处理的结合使用
• 能在提示链中集成外部工具
• 理解上下文工程的概念

---

九、金句收藏

原文金句：

"即便是最先进的模型，如果提供给它的运行环境视图是有限或结构不良的，
其表现也会大打折扣。"

我的总结金句：

"让 AI 一次做十件事，不如让它做十次一件事。"

"提示链的精髓：专注产生质量，分工带来效率。"

---

十、画龙点睛

总结升华：

提示链不仅是一种技术模式，更是一种思维方式：
- 面对复杂问题，先拆解
- 每步专注一件事
- 用标准化接口连接各步骤
- 逐步逼近最终答案

这种"分而治之"的智慧，从古至今，从人类到 AI，都是解决复杂问题的不二法门。

悬念预告：

提示链解决了"顺序执行"的问题，但如果任务可以并行处理呢？
如果需要根据不同情况走不同路径呢？

下一章，我们将探索"路由模式"------ 让 AI 学会"因地制宜"。

一句话带走：

复杂任务别硬刚，拆成小步一步步来，这就是提示链的全部秘密。

---

十一、延伸资源

想深入学习：

• LangChain LCEL 文档
• LangGraph 文档
• 提示工程指南 - 链式提示

想教给别人：

• 用"流水线"比喻解释核心概念
• 用"把大象装进冰箱"的例子说明分步思想
• 用餐厅点餐的例子说明单一提示的问题

---

第二章：路由（Routing）

人生就是不断做选择，AI 也一样。路由就是教 AI 学会"因地制宜"。

---

一、一句话定位

路由解决什么问题？

路由 = 智能分诊台
就像医院的导诊护士：感冒去内科，骨折去骨科，心脏不舒服去心内科
AI 也需要根据用户的问题，把请求分发到最合适的处理模块

适合谁学？

• 需要处理多种类型请求的开发者
• 构建客服机器人、智能助手的工程师
• 想让 AI 系统更"聪明"的技术人员

不适合谁？

• 只有单一功能的简单应用（杀鸡焉用牛刀）

---

二、核心框架（知识骨架）

核心观点：

提示链 = 流水线（固定路线）
路由 = 十字路口（动态选择）

提示链解决"怎么做"，路由解决"做什么"

关键概念速查表：

概念	大白话解释	生活比喻	一句话记忆
路由	根据输入选择不同处理路径	导诊台分诊	因地制宜
意图识别	判断用户想干什么	听懂弦外之音	知其所求
分支逻辑	不同情况走不同路	岔路口选方向	条件分发
协调器	负责分配任务的中枢	调度中心	总指挥

知识地图：

用户请求 → 意图识别 → 路由决策 → 分发到对应处理器 → 返回结果
    ↓           ↓           ↓              ↓
  输入分析    判断类型    选择路径      专业处理

---

三、深入浅出讲解

开场钩子 🎣

想象你打电话给银行客服：

"您好，请按1查询余额，按2转账汇款，按3挂失，按0转人工..."

这就是最原始的"路由"！根据你按的键，把你转到不同的服务。

但问题来了：如果你说"我想看看卡里还有多少钱，顺便转500给我妈"，按哪个键？

这就是为什么我们需要智能路由 ------ 让 AI 听懂你的话，自动帮你分配到正确的服务。

---

【概念1：为什么需要路由？】

一句话是什么：让 AI 学会"看人下菜碟"，不同问题用不同方式处理。

生活化比喻：

想象你是一家公司的前台：

来访者A："我来面试的" → 带去HR部门
来访者B："我来送快递" → 带去收发室
来访者C："我找张总谈合作" → 带去会议室
来访者D："洗手间在哪？" → 直接指路

你不会把所有人都带到同一个地方，对吧？
这就是路由的本质：根据需求，分配到合适的地方。

提示链 vs 路由：

对比项	提示链	路由
执行方式	固定顺序	动态选择
适用场景	步骤明确的任务	类型多样的请求
比喻	流水线	十字路口
关键词	顺序、分步	判断、分发

幽默包装：

提示链像坐地铁：上车 → 换乘 → 到站，路线固定
路由像打车：告诉司机目的地，他帮你选最优路线

如果你坐地铁非要去没有地铁站的地方...那就尴尬了
所以，固定流程解决不了的问题，就需要路由来"随机应变"

---

【概念2：路由的四种实现方式】

一句话是什么：路由有多种实现方法，各有优劣。

四种路由方式对比：

方式	原理	优点	缺点	适用场景
LLM路由	让大模型判断意图	灵活、理解语义	慢、贵	复杂意图识别
向量路由	计算语义相似度	快、准	需要预设类别	语义匹配
规则路由	if-else 关键词匹配	最快、确定性	不灵活	简单分类
ML模型路由	训练专门的分类器	快、可定制	需要标注数据	大规模分类

生活化比喻：

LLM路由 = 请一个聪明人帮你判断
  "这封信是投诉还是咨询？" → 他读完告诉你

向量路由 = 用"相似度"匹配
  "帮我退款" 和 "我要取消订单" 虽然措辞不同，但意思相近 → 都去退款流程

规则路由 = 关键词触发
  包含"退款" → 退款流程
  包含"查询" → 查询流程

ML模型路由 = 训练一个专门的"分诊员"
  看过10万个案例后，一眼就能判断类型

---

【概念3：路由的实际应用场景】

场景1：智能客服

用户："我的订单怎么还没到？"
  ↓ 路由判断：物流查询
  ↓ 分发到：物流查询子系统

用户："这个产品有红色的吗？"
  ↓ 路由判断：产品咨询
  ↓ 分发到：产品信息子系统

用户："我要投诉！"
  ↓ 路由判断：投诉处理
  ↓ 分发到：人工客服

场景2：AI 编程助手

用户：提交一段 Python 代码
  ↓ 路由判断：
    - 意图是"调试" → 调用调试工具
    - 意图是"解释" → 调用代码解释器
    - 意图是"翻译成Java" → 调用代码转换器

场景3：多智能体协作

研究任务："分析特斯拉2024年财报"
  ↓ 协调器路由：
    - 数据收集 → 搜索智能体
    - 数据分析 → 分析智能体
    - 报告撰写 → 写作智能体

---

【概念4：协调器模式】

一句话是什么：设置一个"总指挥"，负责分配任务给各个专业"小弟"。

生活化比喻：

想象一个餐厅的运作：

顾客点单 → 前台（协调器）
  ↓
前台判断：
  - 牛排 → 交给西餐厨师
  - 炒饭 → 交给中餐厨师
  - 甜点 → 交给甜点师
  - 饮料 → 交给调酒师
  ↓
各厨师完成后 → 前台汇总 → 上菜

前台不需要会做菜，只需要知道"谁擅长什么"

代码结构：

协调器（Coordinator）
  ├── 指令：分析请求，分配给合适的子智能体
  ├── 子智能体1：预订专家（处理预订相关）
  ├── 子智能体2：信息专家（处理查询相关）
  └── 子智能体3：...（其他专业领域）

---

四、实践示例

示例1：LangChain 实现路由

from langchain_google_genai import ChatGoogleGenerativeAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough, RunnableBranch

# 初始化模型
llm = ChatGoogleGenerativeAI(model="gemini-2.5-flash", temperature=0)

# 定义三个处理器（模拟子智能体）
def booking_handler(request: str) -> str:
    """处理预订请求"""
    return f"预订处理器：已处理 '{request}'"

def info_handler(request: str) -> str:
    """处理信息查询"""
    return f"信息处理器：已处理 '{request}'"

def unclear_handler(request: str) -> str:
    """处理不明确的请求"""
    return f"无法识别请求：'{request}'，请提供更多信息"

# 定义路由提示词（让LLM判断意图）
router_prompt = ChatPromptTemplate.from_messages([
    ("system", """分析用户请求，判断应该交给哪个处理器：
     - 预订航班或酒店 → 输出 'booker'
     - 查询信息 → 输出 'info'
     - 不明确 → 输出 'unclear'
     只输出一个词！"""),
    ("user", "{request}")
])

# 构建路由链
router_chain = router_prompt | llm | StrOutputParser()

# 定义分支逻辑
delegation_branch = RunnableBranch(
    (lambda x: x['decision'].strip() == 'booker', 
     lambda x: booking_handler(x['request'])),
    (lambda x: x['decision'].strip() == 'info', 
     lambda x: info_handler(x['request'])),
    lambda x: unclear_handler(x['request'])  # 默认分支
)

# 组合成完整的路由系统
router_system = {
    "decision": router_chain,
    "request": RunnablePassthrough()
} | delegation_branch

运行示例：

# 测试预订请求
result = router_system.invoke({"request": "帮我订一张去伦敦的机票"})
# 输出：预订处理器：已处理 '帮我订一张去伦敦的机票'

# 测试信息查询
result = router_system.invoke({"request": "意大利的首都是哪里？"})
# 输出：信息处理器：已处理 '意大利的首都是哪里？'

示例2：Google ADK 实现路由

from google.adk.agents import Agent
from google.adk.tools import FunctionTool

# 定义工具函数
def booking_handler(request: str) -> str:
    return f"预订操作已模拟执行：'{request}'"

def info_handler(request: str) -> str:
    return f"信息查询已模拟执行：'{request}'"

# 创建专业子智能体
booking_agent = Agent(
    name="Booker",
    model="gemini-2.0-flash",
    description="处理航班和酒店预订",
    tools=[FunctionTool(booking_handler)]
)

info_agent = Agent(
    name="Info",
    model="gemini-2.0-flash",
    description="提供通用信息查询",
    tools=[FunctionTool(info_handler)]
)

# 创建协调器（自动路由）
coordinator = Agent(
    name="Coordinator",
    model="gemini-2.0-flash",
    instruction="""你是主协调员，负责分析请求并分配给合适的子智能体：
    - 预订相关 → 交给 Booker
    - 信息查询 → 交给 Info""",
    sub_agents=[booking_agent, info_agent]  # 定义子智能体后自动启用路由
)

ADK 的优势 ：定义了 sub_agents 后，框架会自动根据描述进行路由，无需手写分支逻辑。

---

五、精华提炼（去废话版）

核心要点：

1. 路由 = 动态选择：根据输入决定走哪条路
2. 四种实现：LLM路由（灵活）、向量路由（语义）、规则路由（快速）、ML路由（定制）
3. 协调器模式：一个总指挥 + 多个专业子智能体
4. 与提示链的区别：提示链是"顺序执行"，路由是"条件分发"

必须记住的：

路由的本质：让 AI 学会"因地制宜"
不同问题，不同处理方式

---

六、行动清单

立即可做（5分钟内）：

• 想一个你的应用中需要"分类处理"的场景
• 列出可能的请求类型（3-5种）

本周实践：

• 用 LangChain 实现一个简单的两路路由
• 尝试用 LLM 做意图识别

进阶挑战：

• 实现向量路由（基于语义相似度）
• 构建一个多级路由系统（先粗分，再细分）

---

七、常见误区

误区1：路由越复杂越好

❌ 错误：设计10层路由，每层5个分支
✅ 正确：路由层级尽量扁平，2-3层足够

误区2：所有判断都用 LLM

❌ 错误：简单的关键词匹配也调用大模型
✅ 正确：简单场景用规则，复杂场景用 LLM

误区3：忽视默认分支

❌ 错误：只处理预期的情况，没有兜底
✅ 正确：永远要有 "unclear" 或 "other" 分支

---

八、学习检查

基础理解：

• 能解释路由和提示链的区别
• 能说出四种路由实现方式
• 理解协调器模式的工作原理

实践能力：

• 能用 LangChain 实现简单路由
• 能设计一个客服场景的路由逻辑
• 能选择合适的路由方式

进阶理解：

• 理解向量路由的原理
• 能设计多级路由系统
• 理解路由与多智能体协作的关系

---

九、金句收藏

原文金句：

"路由将静态的预定执行路径转变为能够选择最佳可能操作的灵活且具上下文感知的工作流。"

我的总结金句：

"提示链教 AI 怎么做，路由教 AI 做什么。"

"好的路由就像好的导诊护士：快速判断，精准分配，不让病人跑冤枉路。"

---

十、画龙点睛

总结升华：

路由是智能体从"执行者"进化为"决策者"的关键一步。

没有路由的 AI 就像只会走直线的机器人，
有了路由的 AI 才能在复杂环境中"见招拆招"。

掌握路由，你的 AI 系统就有了"因地制宜"的智慧。

悬念预告：

路由解决了"选择走哪条路"的问题，
但如果多条路可以同时走呢？

下一章，我们将探索"并行化"------
让 AI 学会"一心多用"，效率翻倍！

一句话带走：

路由的精髓：不同问题，不同对待。让 AI 学会"看人下菜碟"。

---

十一、延伸资源

想深入学习：

• LangGraph 文档
• Google ADK 文档

想教给别人：

• 用"医院导诊台"比喻解释路由概念
• 用"餐厅前台分配订单"解释协调器模式
• 对比"地铁（固定路线）vs 打车（动态选择）"说明路由与提示链的区别

---

第三章：并行化（Parallelization）

一个人干活慢？那就多叫几个人一起干！AI 也是一样。

---

一、一句话定位

并行化解决什么问题？

并行化 = 多线程作战
就像餐厅后厨：一个厨师做菜太慢，那就让多个厨师同时做不同的菜
AI 也可以同时执行多个独立任务，大幅缩短总耗时

适合谁学？

• 需要处理多个独立任务的开发者
• 想提升 AI 系统响应速度的工程师
• 构建复杂智能体系统的技术人员

不适合谁？

• 任务之间有强依赖关系的场景（必须按顺序来）

---

二、核心框架（知识骨架）

核心观点：

顺序执行：任务A完成 → 任务B开始 → 任务C开始
并行执行：任务A、B、C 同时开始 → 全部完成后汇总

总耗时：顺序 = A + B + C，并行 ≈ max(A, B, C)

关键概念速查表：

概念	大白话解释	生活比喻	一句话记忆
并行化	多个任务同时执行	多个厨师同时做菜	一心多用
独立任务	互不依赖的任务	各做各的菜	互不干扰
汇总节点	等所有并行任务完成后合并	传菜窗口	统一出餐
异步执行	不等结果就继续做其他事	下单后不用站着等	先干别的

知识地图：

识别独立任务 → 并行执行 → 等待全部完成 → 汇总结果
     ↓              ↓            ↓           ↓
  任务拆分      同时启动      同步等待     合并输出

---

三、深入浅出讲解

开场钩子 🎣

想象你要做一顿大餐：红烧肉、清蒸鱼、炒青菜、煲汤。

方案A（顺序执行）：

红烧肉（40分钟）→ 清蒸鱼（20分钟）→ 炒青菜（10分钟）→ 煲汤（60分钟）
总耗时：130分钟 😱

方案B（并行执行）：

同时开始：
- 灶台1：煲汤（60分钟）
- 灶台2：红烧肉（40分钟）
- 灶台3：清蒸鱼（20分钟）
- 灶台4：炒青菜（10分钟）

总耗时：60分钟（取决于最慢的那个）✅

这就是并行化的威力 ------ 同样的任务，时间缩短一半以上！

---

【概念1：什么时候可以并行？】

一句话是什么：任务之间互不依赖时，就可以并行。

生活化比喻：

可以并行的情况：
- 洗衣机洗衣服 + 电饭煲煮饭 + 你看电视
  （三件事互不影响）

不能并行的情况：
- 先洗菜 → 再切菜 → 再炒菜
  （必须按顺序来，切菜依赖洗菜的结果）

判断标准：

问自己：任务B需要任务A的结果吗？
- 不需要 → 可以并行
- 需要 → 必须顺序执行

实际案例：

研究一个公司的智能体：

❌ 顺序执行：
1. 搜索新闻（5秒）
2. 查股票数据（3秒）
3. 看社交媒体（4秒）
4. 查公司数据库（2秒）
总耗时：14秒

✅ 并行执行：
同时启动：新闻搜索 + 股票查询 + 社媒监测 + 数据库查询
总耗时：5秒（最慢的那个）

效率提升：近3倍！

---

【概念2：并行化的七大应用场景】

场景1：信息收集

任务：研究某个话题
并行：同时搜索多个信息源（新闻、论文、社交媒体）
好处：快速获得全面信息

场景2：数据分析

任务：分析客户反馈
并行：同时进行情感分析、关键词提取、分类、紧急度判断
好处：多角度分析一步到位

场景3：多API调用

任务：旅行规划
并行：同时查机票、酒店、景点、餐厅
好处：快速生成完整行程

场景4：内容生成

任务：写营销邮件
并行：同时生成标题、正文、图片、按钮文案
好处：高效组装完整内容

场景5：多重验证

任务：验证用户输入
并行：同时检查邮箱格式、手机号、地址、敏感词
好处：快速反馈验证结果

场景6：多模态处理

任务：分析社交媒体帖子
并行：同时分析文字情感 + 图片内容
好处：快速整合多维度信息

场景7：A/B测试

任务：生成创意文案
并行：同时用不同提示词生成3个版本
好处：快速比较选择最优

---

【概念3：并行 vs 并发】

一句话区分：

并行（Parallelism）= 真的同时做（多个CPU核心）
并发（Concurrency）= 看起来同时做（单核心快速切换）

生活化比喻：

并行 = 三个厨师同时做三道菜（真的同时）
并发 = 一个厨师在三道菜之间快速切换（看起来同时）

Python的asyncio是并发，不是真正的并行
但对于等待外部API的场景，并发已经足够高效

为什么并发也很有用？

场景：调用3个API，每个需要等待2秒

顺序执行：
调用API1 → 等2秒 → 调用API2 → 等2秒 → 调用API3 → 等2秒
总耗时：6秒

并发执行：
同时发起3个请求 → 等待（期间CPU可以做其他事）
总耗时：约2秒

虽然不是真正的并行，但等待时间重叠了！

---

【概念4：并行化的代价】

幽默包装：

并行化就像开会：
- 1个人决策：快，但可能考虑不周
- 10个人开会：考虑周全，但协调成本高

并行化的隐藏成本：
- 设计复杂度 ↑
- 调试难度 ↑
- 日志混乱 ↑
- 资源消耗 ↑

什么时候不该用并行？

❌ 任务本身很快（并行的开销可能比任务本身还大）
❌ 任务之间有依赖（必须顺序执行）
❌ 资源有限（同时开太多任务会卡死）
❌ 调试阶段（先让顺序版本跑通）

---

四、实践示例

示例1：LangChain 并行执行

import asyncio
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnableParallel, RunnablePassthrough

# 初始化模型
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.7)

# 定义三个独立的处理链
summarize_chain = (
    ChatPromptTemplate.from_messages([
        ("system", "简洁总结以下主题："),
        ("user", "{topic}")
    ]) | llm | StrOutputParser()
)

questions_chain = (
    ChatPromptTemplate.from_messages([
        ("system", "针对以下主题生成3个有趣的问题："),
        ("user", "{topic}")
    ]) | llm | StrOutputParser()
)

terms_chain = (
    ChatPromptTemplate.from_messages([
        ("system", "从以下主题中提取5-10个关键术语，用逗号分隔："),
        ("user", "{topic}")
    ]) | llm | StrOutputParser()
)

# 构建并行执行块
parallel_block = RunnableParallel({
    "summary": summarize_chain,      # 并行任务1：总结
    "questions": questions_chain,    # 并行任务2：提问
    "key_terms": terms_chain,        # 并行任务3：提取术语
    "topic": RunnablePassthrough()   # 保留原始输入
})

# 定义汇总提示词
synthesis_prompt = ChatPromptTemplate.from_messages([
    ("system", """基于以下信息生成综合报告：
     摘要：{summary}
     相关问题：{questions}
     关键术语：{key_terms}"""),
    ("user", "原始主题：{topic}")
])

# 完整链：并行执行 → 汇总
full_chain = parallel_block | synthesis_prompt | llm | StrOutputParser()

# 运行
async def run_example():
    result = await full_chain.ainvoke("人工智能的发展历史")
    print(result)

asyncio.run(run_example())

执行流程：

输入主题
    ↓
┌───────────────────────────────────┐
│  并行执行（RunnableParallel）      │
│  ├── 总结链 ──────→ 摘要          │
│  ├── 提问链 ──────→ 问题列表      │
│  └── 术语链 ──────→ 关键术语      │
└───────────────────────────────────┘
    ↓
汇总提示词（整合三个结果）
    ↓
最终报告

示例2：Google ADK 并行智能体

from google.adk.agents import Agent, ParallelAgent, SequentialAgent
from google.adk.tools import FunctionTool

# 定义三个研究员子智能体
researcher_1 = Agent(
    name="可再生能源研究员",
    instruction="研究可再生能源的最新进展，用1-2句话总结",
    tools=[google_search],
    output_key="renewable_result"
)

researcher_2 = Agent(
    name="电动汽车研究员", 
    instruction="研究电动汽车技术的最新发展，用1-2句话总结",
    tools=[google_search],
    output_key="ev_result"
)

researcher_3 = Agent(
    name="碳捕获研究员",
    instruction="研究碳捕获技术的现状，用1-2句话总结",
    tools=[google_search],
    output_key="carbon_result"
)

# 创建并行智能体（同时运行三个研究员）
parallel_research = ParallelAgent(
    name="并行研究团队",
    sub_agents=[researcher_1, researcher_2, researcher_3]
)

# 创建汇总智能体
merger = Agent(
    name="报告撰写员",
    instruction="""基于以下研究结果撰写结构化报告：
    - 可再生能源：{renewable_result}
    - 电动汽车：{ev_result}
    - 碳捕获：{carbon_result}"""
)

# 创建顺序流程：先并行研究，再汇总
pipeline = SequentialAgent(
    name="研究与汇总流程",
    sub_agents=[parallel_research, merger]  # 先并行，后汇总
)

执行流程：

用户请求
    ↓
┌─────────────────────────────────────┐
│  ParallelAgent（并行研究）           │
│  ├── 研究员1 → 可再生能源结果       │
│  ├── 研究员2 → 电动汽车结果         │
│  └── 研究员3 → 碳捕获结果           │
└─────────────────────────────────────┘
    ↓（等待全部完成）
┌─────────────────────────────────────┐
│  MergerAgent（汇总）                 │
│  整合三个研究结果 → 结构化报告       │
└─────────────────────────────────────┘
    ↓
最终报告

---

五、精华提炼（去废话版）

核心要点：

1. 并行 = 同时执行：多个独立任务一起跑，总耗时取决于最慢的那个
2. 前提是独立：任务之间不能有依赖关系
3. 汇总是关键：并行完成后需要一个节点来合并结果
4. 有代价：设计复杂、调试困难、资源消耗增加

必须记住的：

并行化的本质：用空间换时间
多开几个"工位"，让任务同时进行

---

六、行动清单

立即可做（5分钟内）：

• 找出你的应用中可以并行的任务
• 画出任务依赖图，标记哪些可以并行

本周实践：

• 用 LangChain 的 RunnableParallel 实现一个简单的并行流程
• 对比顺序执行和并行执行的耗时差异

进阶挑战：

• 实现一个"并行研究 + 顺序汇总"的混合流程
• 处理并行任务中的错误（一个失败不影响其他）

---

七、常见误区

误区1：所有任务都要并行

❌ 错误：不管三七二十一，全部并行
✅ 正确：只有独立任务才能并行，有依赖的必须顺序

误区2：并行一定更快

❌ 错误：并行肯定比顺序快
✅ 正确：任务太小时，并行的开销可能比收益还大

误区3：忽视汇总步骤

❌ 错误：并行完就结束了
✅ 正确：并行结果需要汇总，这一步通常是顺序的

误区4：混淆并行和并发

❌ 错误：Python asyncio 是真正的并行
✅ 正确：asyncio 是并发（单线程），但对IO密集型任务已经够用

---

八、学习检查

基础理解：

• 能解释什么情况下可以并行
• 能区分并行和并发的概念
• 理解并行化的代价

实践能力：

• 能用 LangChain 实现并行执行
• 能设计"并行 + 汇总"的混合流程
• 能判断一个任务是否适合并行

进阶理解：

• 理解 asyncio 的工作原理
• 能处理并行任务中的异常
• 能优化并行任务的资源使用

---

九、金句收藏

原文金句：

"并行模式的核心在于找出工作流中互不依赖的环节，并将它们并行执行。"

我的总结金句：

"顺序执行是排队买票，并行执行是多窗口同时服务。"

"并行化的精髓：能同时做的事，绝不排队等。"

---

十、画龙点睛

总结升华：

并行化是效率优化的利器，但不是万能药。

它的威力在于：
- 把"等待时间"变成"工作时间"
- 把"串行瓶颈"变成"并行加速"

它的代价在于：
- 设计更复杂
- 调试更困难
- 需要更多资源

掌握并行化，你的 AI 系统就能"一心多用"，效率翻倍。

悬念预告：

并行化让 AI 学会了"一心多用"，
但如果 AI 做完一件事后，能自己检查、自己改进呢？

下一章，我们将探索"反思模式"------
让 AI 学会"三省吾身"，自我迭代提升！

一句话带走：

并行化的精髓：独立的任务同时做，依赖的任务排队做。

---

十一、延伸资源

想深入学习：

• LangChain LCEL 文档
• Google ADK 多智能体文档
• Python asyncio 文档

想教给别人：

• 用"餐厅后厨多个厨师同时做菜"比喻并行
• 用"洗衣机+电饭煲+看电视"说明独立任务
• 对比"排队买票 vs 多窗口服务"说明效率提升

---

本文基于《Agentic Design Patterns》一书整理，采用"教与学专家"风格编写。

标签建议 ：AI 智能体 LLM 提示工程 LangChain 设计模式 Agent