【学习笔记】AI Agent 设计模式入门教程
基于《Agentic Design Patterns》中文翻译项目 项目地址:https://github.com/xindoo/agentic-design-patterns 在线阅读:https://adp.xindoo.xyz/
第一章:什么是 AI Agent 与设计模式
1.1 AI Agent 是什么?
AI Agent(人工智能智能体) 是一种能够自主感知环境、做出决策并执行行动的系统。与传统的大语言模型(LLM)“一问一答”的交互方式不同,Agent 具备了更接近人类的问题解决能力:
| 能力 | 说明 | 示例 |
|---|---|---|
| 使用工具 | 调用外部 API、数据库、计算器等 | 查询天气、搜索新闻、执行代码 |
| 制定计划 | 将复杂目标分解为可执行的步骤 | 规划一次旅行、完成研究报告 |
| 记忆信息 | 记住用户偏好和历史交互 | 记住用户喜欢川菜、上次聊到的话题 |
| 协作能力 | 与其他 Agent 配合完成任务 | 研究员 Agent + 写作 Agent + 编辑 Agent |
| 请求协助 | 在不确定时向人类求助 | 需要确认时暂停并询问用户 |
简单理解:如果把 LLM 比作一个”会说话的百科全书”,那么 Agent 就是一个”能办事的助手”——不仅能回答你的问题,还能帮你把事情办了。
1.2 什么是设计模式?
设计模式(Design Patterns) 是软件工程领域中经过长期实践验证的解决方案模板。它不是在教你写具体的代码,而是在告诉你”遇到这类问题,应该采用什么样的结构来解决”。
在 AI Agent 领域,设计模式回答的是这样的问题:
- 如何让 Agent 更可靠地完成多步骤任务?
- 如何让 Agent 在复杂场景中做出正确决策?
- 如何让多个 Agent 高效协作?
- 如何确保 Agent 的行为安全可控?
1.3 《Agentic Design Patterns》简介
《Agentic Design Patterns》是由 Google 发布的系统性书籍,全面介绍了构建 AI Agent 的 21 个核心设计模式,涵盖从基础到高级的完整知识体系:
- 基础模式:提示词链、路由、并行化
- 进阶模式:反思、工具使用、规划
- 高级模式:多智能体协作、记忆管理、知识检索
- 实践模式:安全防护、评估监控、人机协同
- 前沿模式:MCP、A2A、资源感知优化
本书的中文翻译项目由开源社区维护,所有 32 个文件(21 章 + 7 附录 + 4 其他内容)已完成翻译,可在线免费阅读。
1.4 为什么需要设计模式?
直接使用 LLM 处理复杂任务时,常常会遇到以下问题:
| 问题 | 表现 | 解决方案 |
|---|---|---|
| 指令忽略 | 部分提示内容被模型忽视 | 使用提示词链分解任务 |
| 上下文偏离 | 模型失去对初始上下文的追踪 | 使用记忆管理保持上下文 |
| 错误传播 | 早期错误在后续步骤中被放大 | 使用反思模式自我纠错 |
| 上下文窗口不足 | 输入信息太长,模型处理不过来 | 使用 RAG 检索关键信息 |
| 幻觉 | 模型生成看似合理但实际错误的信息 | 使用工具使用获取真实数据 |
设计模式通过结构化的方法解决这些问题,让 Agent 系统更可靠、更可管理、更可扩展。
第二章:基础模式——提示词链 Prompt Chaining
2.1 概念理解
提示词链(Prompt Chaining) 是最基础、最常用的 Agent 设计模式。它将一个复杂任务分解为一系列较小的、聚焦的步骤,每个步骤都是一个 LLM 调用,前一步的输出作为后一步的输入。
生活类比:就像工厂的生产流水线——原材料经过一道道工序(切割、打磨、组装、质检),最终变成成品。每一道工序只专注于自己的任务,不需要关心全局。
2.2 为什么使用提示词链?
假设你想让 AI 完成”分析市场报告并撰写邮件”的任务:
❌ 错误做法(一次性完成):
"请阅读这份市场报告,分析趋势,然后给营销团队写一封邮件。"可能的问题:
- 遗漏报告中的关键数据
- 邮件结构混乱
- 趋势分析不准确
- 整体质量难以保证
✅ 正确做法(提示词链):
步骤1:"请总结以下市场报告的主要发现:[报告内容]"
步骤2:"基于以上摘要,识别前三个新兴趋势并提取支持数据:[步骤1输出]"
步骤3:"向营销团队起草一封邮件,概述以下趋势及其数据:[步骤2输出]"优势:
- 每一步都有明确的单一目标
- 每一步的输出都经过验证
- 错误被限制在单个步骤内,不会扩散
- 便于调试和优化每个环节
2.3 典型应用场景
场景一:文档处理流水线
步骤1:从URL或文档中提取文本内容
步骤2:清理和总结文本
步骤3:提取特定实体(姓名、日期、位置)
步骤4:搜索内部知识库获取相关信息
步骤5:生成包含摘要、实体和搜索结果的最终报告场景二:内容创作流水线
步骤1:根据用户兴趣生成5个主题想法
步骤2:用户选择后,生成详细大纲
步骤3:逐节撰写内容(每节都基于前文的上下文)
步骤4:审查和完善完整草稿的连贯性、语气和语法场景三:对话系统
步骤1:处理用户话语,识别意图和关键实体
步骤2:更新对话状态
步骤3:基于当前状态生成响应
→ 循环执行,累积对话历史2.4 代码示例(LangChain)
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(
"从以下文本中提取技术规格:\n\n{text_input}"
)
# 步骤2:转换为 JSON
prompt_transform = ChatPromptTemplate.from_template(
"将以下规格转换为 JSON 对象,使用 'cpu'、'memory' 和 'storage' 作为键:\n\n{specifications}"
)
# 构建链:提取 → LLM → 字符串解析
extraction_chain = prompt_extract | llm | StrOutputParser()
# 完整链:将提取结果传入转换提示词
full_chain = (
{"specifications": extraction_chain}
| prompt_transform
| llm
| StrOutputParser()
)
# 执行
result = full_chain.invoke({"text_input": "这台服务器配备了 Intel i7 处理器,32GB 内存和 1TB SSD 存储。"})
print(result)2.5 关键要点
- 提示词链将复杂任务分解为一系列较小的、聚焦的步骤,有时也被称为管道模式(Pipeline Pattern)
- 链中的每一步都涉及 LLM 调用或处理逻辑,使用前一步的输出作为输入
- 这种模式提高了与语言模型进行复杂交互的可靠性和可管理性
- LangChain/LangGraph 和 Google ADK 等框架提供了定义、管理和执行这些多步序列的健壮工具
第三章:基础模式——路由 Routing
3.1 概念理解
路由(Routing) 模式就像一个智能分拣系统——根据输入的特征,将请求分发到不同的处理路径。它的核心思想是”对症下药”:不同的输入由不同的专家来处理。
生活类比:就像拨打客服电话时的语音导航——“按1查询订单,按2了解产品,按3技术支持,按0转人工”。系统根据你的选择,把你转接到对应的部门。
3.2 路由的实现方式
方式一:基于 LLM 的路由
让 LLM 自己分析输入并输出分类结果:
"分析以下用户查询,仅输出类别:'订单状态'、'产品信息'、'技术支持' 或 '其他'。"
用户输入:"我昨天买的手机什么时候到?"
LLM 输出:"订单状态"优点:灵活,能理解语义
缺点:有延迟,需要一次 LLM 调用
方式二:基于嵌入(Embedding)的路由
将输入转换为向量,与代表不同路由的向量比较相似度:
用户查询 → 向量化 → 与各类别向量比较 → 选择最相似的类别优点:语义理解能力强
缺点:需要预先准备类别向量
方式三:基于规则的路由
使用关键词匹配或正则表达式:
if "订单" in query or "快递" in query:
route_to = "order_system"
elif "价格" in query or "功能" in query:
route_to = "product_catalog"
elif "怎么" in query or "故障" in query:
route_to = "tech_support"
else:
route_to = "human_agent"优点:快速、确定性强、无需 LLM 调用
缺点:灵活性差,难以处理新颖输入
方式四:基于机器学习模型的路由
训练专门的分类器来执行路由决策:
标注数据 → 训练分类器 → 实时预测路由优点:精准、高效
缺点:需要标注数据和训练成本
3.3 典型应用场景
智能客服系统
用户:"我的订单到哪了?"
→ 意图识别:订单查询
→ 路由到:订单查询 Agent
→ 调用订单数据库 API
→ 返回:"您的订单 #12345 预计明天送达"
用户:"这款手机支持5G吗?"
→ 意图识别:产品咨询
→ 路由到:产品信息 Agent
→ 查询产品数据库
→ 返回:"是的,支持5G网络..."
用户:"手机开不了机怎么办?"
→ 意图识别:技术支持
→ 路由到:故障排除 Agent
→ 返回故障排查步骤多领域问答系统
科学问题 → 科学专家 Agent
历史问题 → 历史专家 Agent
编程问题 → 代码专家 Agent
医学问题 → 医学专家 Agent(需额外安全审核)3.4 关键要点
- 路由模式的核心是分类决策——将输入分发到最合适的处理路径
- 选择路由方式时需要权衡灵活性和效率
- 对于简单场景,规则路由可能足够;对于复杂语义,LLM 或嵌入路由更合适
- 路由可以嵌套使用——先粗分大类,再细分小类
第四章:基础模式——并行化 Parallelization
4.1 概念理解
并行化(Parallelization) 模式通过同时执行多个独立任务来提高效率。当任务的各个部分互不依赖时,与其一个一个顺序做,不如同时开工,最后合并结果。
生活类比:就像餐厅厨房——有多个厨师同时准备不同的菜品,而不是一个厨师做完一道再做下一道。或者像搬家时,几个人同时打包不同房间。
4.2 与提示词链的区别
| 维度 | 提示词链 | 并行化 |
|---|---|---|
| 执行方式 | 串行(Sequential) | 并行(Parallel) |
| 步骤关系 | 后一步依赖前一步 | 各步骤相互独立 |
| 适用场景 | 有明确先后顺序的任务 | 可独立执行的子任务 |
| 总耗时 | 各步骤耗时之和 | 最长步骤的耗时 |
| 复杂度 | 相对简单 | 需要协调和合并 |
示例对比:
研究一家公司(串行 vs 并行):
串行方式:
步骤1:搜索新闻(2秒)
步骤2:查股票数据(2秒)
步骤3:看社交媒体(2秒)
步骤4:查公司数据库(2秒)
总耗时:8秒
并行方式:
同时执行:搜索新闻 + 查股票 + 看社交媒体 + 查数据库(各2秒)
合并结果(1秒)
总耗时:3秒4.3 典型应用场景
公司调研 Agent
# 并行任务
任务1:搜索新闻文章
任务2:获取股票数据
任务3:监控社交媒体提及
任务4:查询公司数据库
# 所有任务完成后
合并:综合分析生成报告旅行规划 Agent
# 并行任务
任务1:查询航班价格
任务2:查询酒店可用性
任务3:查询当地活动
任务4:查询餐厅推荐
# 所有任务完成后
合并:生成完整旅行方案客户反馈分析 Agent
# 并行任务
任务1:情感分析
任务2:关键词提取
任务3:反馈分类
任务4:紧急问题识别
# 所有任务完成后
合并:生成多维度分析报告4.4 代码示例(LangChain)
from langchain_core.runnables import RunnableParallel, RunnablePassthrough
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.7)
# 定义并行的多个处理链
chain1 = ChatPromptTemplate.from_template("总结以下文本的主要观点:{input}") | llm
chain2 = ChatPromptTemplate.from_template("提取以下文本的关键词:{input}") | llm
chain3 = ChatPromptTemplate.from_template("分析以下文本的情感倾向:{input}") | llm
# 并行执行
parallel_chain = RunnableParallel(
summary=chain1,
keywords=chain2,
sentiment=chain3
)
# 输入相同的内容,三个链同时处理
result = parallel_chain.invoke({"input": "这家餐厅的食物非常美味,服务也很周到!"})
print(result["summary"]) # 摘要
print(result["keywords"]) # 关键词
print(result["sentiment"]) # 情感分析4.5 关键要点
- 并行化通过并发执行独立任务来提高效率
- 在涉及等待外部资源(如 API 调用)的任务中特别有效
- 采用并发架构会引入显著复杂性,影响设计、调试和日志等关键环节
- LangChain 的
RunnableParallel和 Google ADK 的ParallelAgent提供了并行执行支持 - 并行化有助于减少整体延迟,使 Agent 系统更具响应性
第五章:进阶模式——反思 Reflection
5.1 概念理解
反思(Reflection) 模式让 Agent 能够批判性地评估自己的输出,并根据评估结果进行改进。这类似于人类写作时的”自我审校”过程——写完一段内容后,回头看看有没有问题,然后修改完善。
生活类比:就像学生写完作文后,先自己检查一遍(有没有错别字?逻辑通不通?),然后再请老师批改,根据反馈修改。
5.2 核心流程
反思模式通常包含以下四个步骤:
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 执行 │ → │ 评估 │ → │ 反思 │ → │ 优化 │
│ 生成初稿│ │ 检查质量│ │ 确定改进│ │ 生成改进稿│
└─────────┘ └─────────┘ └─────────┘ └─────────┘
↑ │
└────────────── 循环迭代 ←─────────────────────┘- 执行:Agent 生成初始输出(代码、文章、计划等)
- 评估:分析输出的准确性、连贯性、完整性、风格等
- 反思:确定具体的改进方向
- 优化:生成改进后的输出
- 迭代(可选):重复上述过程,直到满足质量标准
5.3 两种实现形式
形式一:“工作自查”式反思
同一个 Agent 检查并修正自己的输出:
# 第一轮:生成草稿
draft = llm.invoke("写一篇关于人工智能的文章")
# 第二轮:自我审查
review = llm.invoke(f"请检查以下文章的问题(语法、逻辑、事实错误):\n{draft}")
# 第三轮:基于审查修改
final = llm.invoke(f"根据以下审查意见修改文章:\n原文:{draft}\n审查意见:{review}")适用场景:简单错误检查、语法修正、格式调整
形式二:“内部评审”式反思
使用独立的”评审者”Agent 评估”执行者”Agent 的输出:
# 执行者 Agent:专注于生成内容
writer = Agent(
role="技术作家",
goal="撰写高质量的技术文章"
)
# 评审者 Agent:专注于发现问题
reviewer = Agent(
role="资深编辑",
goal="检查文章的事实准确性、逻辑性和可读性"
)
# 工作流程
draft = writer.write("AI Agent 设计模式")
feedback = reviewer.review(draft)
final = writer.revise(draft, feedback)适用场景:需要严格质量控制的场景(代码审查、事实核查、合规检查)
5.4 典型应用场景
代码生成与调试
步骤1:编写初始代码
步骤2:运行测试或静态分析
步骤3:识别错误或低效之处
步骤4:基于发现修改代码
步骤5:重复直到通过所有测试内容创作
步骤1:生成草稿
步骤2:评审流畅性、语气和清晰度
步骤3:基于评审重写
步骤4:重复直到满足质量标准复杂问题解决
步骤1:提出一个解题步骤
步骤2:评估是否更接近解决方案
步骤3:必要时回溯或选择不同步骤
步骤4:重复直到问题解决5.5 关键要点
- 反思模式是 Agent 自我提升的核心机制
- “评审者”Agent 应该被赋予不同的角色和指令,以提供多元化的视角
- 反思可以迭代进行,设置停止条件(如最大迭代次数、质量阈值)
- 反思模式与提示词链结合使用效果更佳——先链式执行,再反思优化
第六章:进阶模式——工具使用 Tool Use
6.1 概念理解
工具使用(Tool Use) 模式让 Agent 能够调用外部功能来扩展自身能力。LLM 本身只能处理文本,但通过工具,它可以与整个数字世界交互。
生活类比:就像人类使用工具一样——我们不会用牙齿咬开罐头,而是使用开罐器。Agent 也不会试图”计算”复杂的数学问题,而是调用计算器。
6.2 为什么工具使用如此重要?
LLM 有两个根本局限:
- 知识有截止日期:无法获取训练数据之后发生的事件
- 无法与外部世界交互:不能查天气、不能发邮件、不能查数据库
工具使用解决了这两个问题:
| 局限 | 解决方案 | 示例工具 |
|---|---|---|
| 知识过时 | 实时信息检索 | 搜索引擎、新闻 API |
| 无法计算 | 外部计算能力 | 计算器、代码解释器 |
| 无法存储 | 数据库操作 | SQL 查询、知识库检索 |
| 无法通信 | 消息发送 | 邮件 API、短信 API |
| 无法感知 | 设备控制 | 智能家居 API、传感器 |
6.3 工作流程
用户提问
↓
LLM 分析:是否需要工具?
↓
是 → 生成工具调用请求(JSON格式)
↓
框架执行工具调用
↓
获取工具返回结果
↓
LLM 基于结果生成最终回答
↓
返回给用户6.4 典型应用场景
天气查询 Agent
用户:"伦敦的天气如何?"
LLM 思考:用户问天气,我需要调用天气工具。
工具调用:
{
"tool": "weather_api",
"parameters": {
"location": "伦敦"
}
}
工具返回:
{
"temperature": 15,
"condition": "多云",
"humidity": 72
}
LLM 生成回答:"伦敦当前多云,温度15°C,湿度72%。"金融分析 Agent
用户:"AAPL 的当前价格是多少?如果我以150美元买入100股,计算潜在收益。"
步骤1:调用股票 API 获取 AAPL 当前价格($178.15)
步骤2:调用计算器工具计算收益:(178.15 - 150) × 100 = $2,815
步骤3:格式化输出完整分析报告智能家居控制
用户:"关闭客厅的灯,把空调调到26度。"
步骤1:调用智能家居 API 关闭客厅灯
步骤2:调用智能家居 API 设置空调温度
步骤3:确认执行结果6.5 代码示例(LangChain)
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
# 定义工具
@tool
def get_weather(location: str) -> str:
"""获取指定位置的当前天气。"""
# 实际实现会调用天气 API
weather_data = {
"北京": "晴朗,25°C",
"上海": "小雨,22°C",
"伦敦": "多云,15°C"
}
return weather_data.get(location, "未知位置")
@tool
def calculator(expression: str) -> str:
"""计算数学表达式。"""
try:
result = eval(expression)
return str(result)
except:
return "计算错误"
# 创建 Agent
llm = ChatOpenAI(model="gpt-4o")
tools = [get_weather, calculator]
prompt = ChatPromptTemplate.from_messages([
("system", "你是一个有用的助手,可以使用工具来帮助用户。"),
("human", "{input}"),
("placeholder", "{agent_scratchpad}"),
])
agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools)
# 执行
result = agent_executor.invoke({"input": "北京天气怎么样?然后计算 15 * 23 + 8"})
print(result["output"])6.6 关键要点
- 工具使用是 Agent 连接外部世界的桥梁
- 工具定义需要包含清晰的描述和参数说明,让 LLM 知道何时使用、如何使用
- 工具返回的结果应该结构化(如 JSON),便于 LLM 理解和使用
- 注意安全风险——给 Agent 的工具权限应该遵循最小权限原则
第七章:进阶模式——规划 Planning
7.1 概念理解
规划(Planning) 模式让 Agent 能够将复杂目标分解为可管理的步骤序列。与提示词链不同,规划模式中的步骤不是预先定义好的,而是根据任务动态生成的。
生活类比:就像旅行前的行程规划——不是固定路线,而是根据目的地、时间、预算动态制定计划。如果途中遇到天气变化,还能灵活调整。
7.2 规划 vs 提示词链
| 维度 | 提示词链 | 规划 |
|---|---|---|
| 步骤来源 | 预先定义 | 动态生成 |
| 灵活性 | 低,固定流程 | 高,可自适应调整 |
| 适用任务 | 结构化、重复性任务 | 开放式、复杂任务 |
| 执行方式 | 按固定顺序执行 | 根据情况选择下一步 |
| 示例 | 文档处理流水线 | 研究一个陌生主题 |
7.3 规划的核心能力
一个具备规划能力的 Agent 能够:
- 目标理解:理解用户想要达成的最终目标
- 任务分解:将大目标拆分为小任务
- 依赖分析:识别任务之间的先后依赖关系
- 动态调整:根据执行过程中的反馈调整计划
- 错误恢复:当某步失败时,重新规划替代方案
7.4 典型应用场景
深度研究任务
用户:"研究司美格鲁肽对全球医疗保健系统的经济影响"
Agent 规划:
1. 搜索司美格鲁肽的基本信息和用途
2. 查找全球医疗保健支出数据
3. 分析司美格鲁肽在不同国家的定价
4. 研究其对糖尿病治疗成本的影响
5. 评估对医疗系统预算的长期影响
6. 综合所有信息生成结构化报告
执行过程中:
- 发现某国数据缺失 → 调整计划,寻找替代数据源
- 发现新的相关政策 → 增加分析维度软件开发任务
用户:"帮我开发一个待办事项应用"
Agent 规划:
1. 需求分析:确定功能列表(添加、删除、标记完成、筛选)
2. 技术选型:选择技术栈(React + Node.js + MongoDB)
3. 数据库设计:设计数据模型
4. 后端开发:实现 API 接口
5. 前端开发:实现用户界面
6. 集成测试:验证功能完整性
7. 部署:发布到服务器7.5 关键要点
- 规划模式是 Agent 自主解决复杂问题的核心能力
- 规划可以是一次性的(开始前制定完整计划)或迭代式的(走一步看一步)
- Google DeepResearch 和 OpenAI Deep Research API 是规划模式的典型商业应用
- CrewAI 提供了内置的任务规划能力,适合快速上手
第八章:高级模式——多智能体协作 Multi-Agent Collaboration
8.1 概念理解
多智能体协作(Multi-Agent Collaboration) 模式涉及多个专业化的 Agent 协同工作,每个 Agent 负责不同的任务或领域。这模拟了人类团队协作的方式——没有人是全才,但一个团队可以完成复杂的大事。
生活类比:就像一个电影制作团队——有导演、编剧、摄影师、演员、剪辑师,每个人负责自己的专业领域,共同完成一部电影。
8.2 协作形式
形式一:顺序交接
一个 Agent 处理完任务后,将输出传递给下一个 Agent:
研究员 Agent → 作家 Agent → 编辑 Agent → 发布 Agent形式二:并行处理
多个 Agent 同时处理问题的不同部分:
┌→ 市场分析 Agent ─┐
用户请求 → ┼→ 技术分析 Agent ─┼→ 汇总 Agent → 最终报告
└→ 竞品分析 Agent ─┘形式三:辩论与共识
多个 Agent 持有不同观点,通过讨论达成共识:
正方 Agent:"应该投资A项目"
反方 Agent:"不应该投资A项目"
评判 Agent:"综合双方观点,结论是..."形式四:层次结构
管理者 Agent 分配任务给工作者 Agent:
项目经理 Agent
/ | \
开发Agent 测试Agent 文档Agent形式五:专家团队
不同领域的专家 Agent 协作:
医疗诊断团队:
- 症状分析 Agent
- 检查报告解读 Agent
- 诊断建议 Agent
- 治疗方案 Agent形式六:批评者-审查者
一个 Agent 生成,另一个 Agent 审查:
写作者 Agent 生成文章
↓
审查者 Agent 检查(事实、安全、合规)
↓
写作者 Agent 根据反馈修改
↓
循环直到通过审查8.3 典型应用场景
软件开发团队
# 定义角色
requirement_analyst = Agent(role="需求分析师", goal="理解并澄清用户需求")
coder = Agent(role="代码工程师", goal="编写高质量代码")
tester = Agent(role="测试工程师", goal="发现并报告问题")
document_writer = Agent(role="技术文档工程师", goal="编写使用文档")
# 协作流程
requirements = requirement_analyst.analyze("用户想要一个在线商城")
code = coder.implement(requirements)
test_results = tester.test(code)
if test_results.has_issues:
code = coder.fix(code, test_results.issues)
documentation = document_writer.write(code)营销活动创建
market_researcher = Agent(role="市场研究员", goal="分析目标受众")
copywriter = Agent(role="文案撰写", goal="创作吸引人的文案")
designer = Agent(role="设计师", goal="生成视觉素材")
social_media_manager = Agent(role="社媒运营", goal="制定发布计划")
# 并行启动研究
audience = market_researcher.research("新产品发布")
# 基于研究结果并行创作
copy = copywriter.write(audience)
design = designer.create(audience)
schedule = social_media_manager.plan(audience)
# 汇总为完整营销方案
campaign = merge(copy, design, schedule)8.4 关键要点
- 多智能体协作的核心优势是专业化——每个 Agent 专注于自己擅长的领域
- 设计多智能体系统时,需要明确通信协议和状态共享机制
- CrewAI 和 Google ADK 提供了强大的多智能体编排能力
- 注意协调开销——Agent 之间的通信会增加延迟和成本
第九章:记忆管理 Memory Management
9.1 概念理解
记忆管理(Memory Management) 模式让 Agent 能够记住之前的交互信息。没有记忆的 Agent 就像一个金鱼——每次对话都从头开始,无法理解上下文。
生活类比:就像你去理发店,有记忆的理发师记得你上次剪的发型、你的偏好(“两边短一点”);没记忆的理发师每次都要重新问一遍。
9.2 记忆的类型
短期记忆(Short-term Memory)
- 范围:当前对话会话
- 内容:对话历史、最近的用户输入、Agent 的响应
- 用途:保持对话连贯性
- 实现:将对话历史作为上下文传递给 LLM
长期记忆(Long-term Memory)
- 范围:跨会话持久化
- 内容:用户偏好、用户画像、历史事实
- 用途:个性化服务、避免重复询问
- 实现:数据库存储、向量数据库
工作记忆(Working Memory)
- 范围:当前任务执行过程中
- 内容:中间结果、临时变量、执行状态
- 用途:支持多步骤任务的上下文保持
- 实现:状态变量、会话状态
9.3 记忆管理的技术实现
# 短期记忆:对话历史
conversation_history = [
{"role": "user", "content": "你好"},
{"role": "assistant", "content": "你好!有什么可以帮助你的?"},
{"role": "user", "content": "我想订披萨"},
# ...
]
# 长期记忆:用户画像(存储在数据库)
user_profile = {
"user_id": "12345",
"preferences": {
"food": ["川菜", "意大利菜"],
"language": "中文",
"notification": True
},
"history_facts": {
"last_order": "2024-01-15 麻辣香锅",
"favorite_restaurant": "川味轩"
}
}
# 工作记忆:任务执行状态
task_state = {
"current_step": 3,
"intermediate_results": {
"step1": "完成用户认证",
"step2": "获取用户位置"
},
"pending_actions": ["搜索附近餐厅", "展示推荐列表"]
}9.4 关键要点
- 记忆是 Agent 个性化和连贯性的基础
- 短期记忆受限于 LLM 的上下文窗口,需要策略性地管理(如摘要、截断)
- 长期记忆通常使用向量数据库(如 Pinecone、Chroma、Milvus)实现语义检索
- 需要注意隐私和安全——用户记忆数据需要妥善保护
第十章:知识检索 RAG
10.1 概念理解
RAG(Retrieval-Augmented Generation,检索增强生成) 是一种让 LLM 能够访问外部知识库的技术。它解决了 LLM “不知道最新信息”和”不知道私有信息”的问题。
生活类比:就像开卷考试——学生(LLM)可以查阅教材(知识库)来回答问题,而不是只凭记忆。
10.2 RAG 工作流程
用户提问
↓
查询向量化 → 在向量数据库中搜索相似内容
↓
获取相关知识片段(Top-K)
↓
将知识片段 + 用户问题 组合成提示词
↓
LLM 基于检索到的知识生成回答
↓
返回答案(可附带引用来源)10.3 RAG 的核心组件
| 组件 | 功能 | 常用技术 |
|---|---|---|
| 文档加载 | 从各种来源加载文档 | LangChain Document Loaders |
| 文本分割 | 将长文档切分为小块 | RecursiveCharacterTextSplitter |
| 嵌入模型 | 将文本转换为向量 | OpenAI Embedding、BGE、M3E |
| 向量数据库 | 存储和检索向量 | Pinecone、Chroma、Milvus、Qdrant |
| 重排序 | 对检索结果精排序 | Cohere Rerank、Cross-Encoder |
| 生成模型 | 基于检索内容生成回答 | GPT-4、Claude、Gemini |
10.4 典型应用场景
企业知识库问答
用户:"公司的年假政策是什么?"
RAG 流程:
1. 将问题转换为向量
2. 在员工手册向量库中检索相关内容
3. 获取 "年假政策" 章节的内容
4. LLM 基于检索内容回答:"根据员工手册第3章,入职满1年可享受10天年假..."客服助手
用户:"怎么重置密码?"
RAG 流程:
1. 检索帮助文档中关于"密码重置"的内容
2. 获取操作步骤
3. 生成清晰的指导回答10.5 关键要点
- RAG 让 LLM 从”闭卷考试”变成”开卷考试”
- 向量数据库的选择对检索质量影响很大
- 文本分割策略很关键——块太大影响精度,块太小丢失上下文
- 可以结合重排序进一步提升检索质量
第十一章:模型上下文协议 MCP
11.1 概念理解
MCP(Model Context Protocol,模型上下文协议) 是一种标准化协议,定义了 Agent 与外部工具、数据源之间的通信方式。它让不同的 Agent 框架和工具能够无缝协作。
生活类比:就像 USB 接口——无论是什么品牌的电脑、手机、U盘,只要支持 USB 协议,就能互相连接。
11.2 为什么需要 MCP?
在没有标准协议之前:
- LangChain 的工具只能在 LangChain 中使用
- Google ADK 的工具只能在 Google ADK 中使用
- 每个框架都有自己的工具定义格式
MCP 解决的是”互操作性”问题:
- 工具开发者只需按 MCP 标准实现一次
- 任何支持 MCP 的 Agent 框架都可以使用
- 降低了生态系统的碎片化
11.3 MCP 的核心概念
┌─────────────┐ MCP 协议 ┌─────────────┐
│ Agent │ ◄──────────────────────► │ Tool │
│ (Client) │ 标准化请求/响应格式 │ (Server) │
└─────────────┘ └─────────────┘MCP 定义了:
- 工具发现:Agent 如何发现可用的工具
- 调用格式:标准化的请求和响应格式
- 认证机制:安全的身份验证方式
- 错误处理:统一的错误码和异常处理
11.4 关键要点
- MCP 是 Agent 生态系统的**“通用语言”**
- 它降低了工具开发和集成的门槛
- 未来更多的 Agent 框架和工具将支持 MCP
- 对于开发者来说,理解 MCP 有助于构建更通用的 Agent 系统
第十二章:Agent 间通信 A2A
12.1 概念理解
A2A(Agent-to-Agent,Agent 间通信) 是一种让不同 Agent 能够互相通信和协作的标准。如果说 MCP 是 Agent 与工具的协议,那么 A2A 就是 Agent 与 Agent 的协议。
生活类比:就像电子邮件协议(SMTP)——无论使用什么邮件客户端(Gmail、Outlook、QQ邮箱),都能互相发送邮件。
12.2 A2A 解决的问题
在多智能体系统中:
- Agent A(用 LangChain 构建)需要与 Agent B(用 Google ADK 构建)协作
- 没有标准协议时,需要写大量的”适配器”代码
- A2A 提供了统一的通信标准
12.3 A2A 的核心能力
- 发现:Agent 如何发现网络中的其他 Agent
- 身份:Agent 的身份认证和授权
- 消息:标准化的消息格式(请求、响应、事件)
- 协商:Agent 之间协商任务分配和能力匹配
- 安全:加密通信和访问控制
12.4 关键要点
- A2A 是实现大规模多智能体系统的基础设施
- 它让不同团队、不同公司开发的 Agent 能够协作
- A2A 与 MCP 互补——MCP 连接 Agent 与工具,A2A 连接 Agent 与 Agent
第十三章:人机协同 Human-in-the-Loop
13.1 概念理解
人机协同(Human-in-the-Loop,HITL) 模式在 Agent 的决策过程中引入人类监督。Agent 不是完全自主的,在关键节点会暂停并请求人类确认。
生活类比:就像自动驾驶汽车——大部分时间自动行驶,但在复杂路况或紧急情况下,会提醒司机接管。
13.2 为什么需要人机协同?
| 场景 | 风险 | HITL 作用 |
|---|---|---|
| 金融交易 | 资金损失 | 执行前人工确认 |
| 医疗诊断 | 健康风险 | 医生最终审核 |
| 法律文件 | 法律责任 | 律师审查后签署 |
| 内容发布 | 品牌风险 | 编辑审核后发布 |
| 数据删除 | 数据丢失 | 管理员确认 |
13.3 人机协同的介入点
Agent 工作流程
↓
计划审批环节 ──→ 人类确认计划是否可行
↓
工具使用授权 ──→ 人类确认是否允许调用敏感工具
↓
歧义消解节点 ──→ 人类澄清模糊的需求
↓
最终输出审核 ──→ 人类审核最终成果
↓
交付给用户13.4 关键要点
- HITL 是 Agent 系统的安全网
- 不是所有任务都需要 HITL——低风险任务可以全自动化
- HITL 的设计要考虑用户体验——审批流程不能太繁琐
- HITL 也是信任构建的重要手段——用户更愿意使用可监督的 AI
第十四章:安全防护 Guardrails
14.1 概念理解
安全防护(Guardrails) 模式确保 Agent 的行为在安全范围内。它防止 Agent 生成有害内容、执行危险操作或泄露敏感信息。
生活类比:就像汽车的保险杠和安全气囊——平时感觉不到,但在危险时刻保护你不受伤害。
14.2 安全防护的层次
┌─────────────────────────────────────────┐
│ 输入层防护 │
│ - 检测恶意输入(注入攻击、提示词攻击) │
│ - 过滤敏感信息(身份证号、密码) │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ 处理层防护 │
│ - 限制工具调用权限(最小权限原则) │
│ - 监控异常行为模式 │
│ - 设置资源使用上限(防止无限循环) │
└─────────────────────────────────────────┘
↓
┌─────────────────────────────────────────┐
│ 输出层防护 │
│ - 内容安全过滤(暴力、仇恨、色情) │
│ - 事实准确性检查 │
│ - 敏感信息脱敏 │
└─────────────────────────────────────────┘14.3 典型安全机制
| 机制 | 说明 | 示例 |
|---|---|---|
| 输入过滤 | 检查用户输入是否包含攻击 | 防止提示词注入 |
| 输出审核 | 检查 Agent 输出是否安全 | 过滤有害内容 |
| 权限控制 | 限制 Agent 能做什么 | 禁止删除数据库 |
| 速率限制 | 防止过度使用 | 限制 API 调用频率 |
| 审计日志 | 记录所有操作 | 追踪问题来源 |
| 人工审核 | 高风险操作人工确认 | 转账前确认 |
14.4 关键要点
- 安全防护是 Agent 系统的底线,不能妥协
- 安全应该是多层的——单点防护容易被突破
- 需要在安全性和可用性之间找平衡——过度防护会降低效率
- 定期审计和更新安全策略,应对新出现的威胁
第十五章:评估与监控 Evaluation & Monitoring
15.1 概念理解
评估与监控(Evaluation and Monitoring) 模式确保 Agent 系统持续按预期工作。没有评估,你就不知道 Agent 做得好不好;没有监控,问题发生时你无法及时发现。
生活类比:就像汽车的仪表盘——速度表、油量表、故障灯,让你随时了解车辆状态。
15.2 评估的维度
结果导向评估
Agent 是否成功达成了目标?
任务:预订从北京到上海的航班
评估:
- ✅ 是否成功预订?
- ✅ 航班时间是否正确?
- ✅ 价格是否在预算内?
- ✅ 乘客信息是否准确?过程质量评估
Agent 的执行流程是否合理?
评估:
- 是否选择了合适的工具?
- 是否遵循了正确的步骤?
- 是否在合理时间内完成?
- 是否有不必要的重复操作?用户体验评估
用户对 Agent 的满意度如何?
评估:
- 回答是否有帮助?(1-5分)
- 回答是否准确?(1-5分)
- 交互是否自然?(1-5分)
- 用户是否愿意再次使用?15.3 监控指标
| 指标类型 | 具体指标 | 说明 |
|---|---|---|
| 性能 | 响应时间、吞吐量 | Agent 有多快 |
| 质量 | 准确率、完成率 | Agent 做得多好 |
| 成本 | Token 消耗、API 调用次数 | Agent 花多少钱 |
| 错误 | 错误率、异常类型 | 哪里出了问题 |
| 安全 | 违规次数、拦截率 | 是否遵守规则 |
15.4 关键要点
- 评估驱动改进——没有评估就没有优化方向
- 建立基准测试(Benchmark),持续对比 Agent 的表现
- 监控应该是实时的——及时发现问题
- 保留详细的日志,便于事后分析问题
第十六章:其他重要模式速览
16.1 学习与适应 Learning and Adaptation
让 Agent 能够从经验中学习,不断优化自己的行为。包括:
- 从反馈学习:根据用户的正面/负面反馈调整
- 从示例学习:通过少量示例(Few-shot)掌握新任务
- 持续学习:不断吸收新知识,更新能力
16.2 目标设定与监控 Goal Setting and Monitoring
Agent 能够:
- 理解用户的高层目标
- 将目标分解为可衡量的子目标
- 持续监控进度
- 在偏离目标时主动调整
16.3 异常处理与恢复 Exception Handling and Recovery
Agent 能够优雅地处理错误:
- 识别异常:工具调用失败、返回异常数据、超时
- 决策恢复:重试、切换替代工具、寻求人类帮助
- 状态回滚:失败时恢复到安全状态
16.4 资源感知优化 Resource-Aware Optimization
Agent 在决策时考虑资源限制:
- 成本意识:选择更经济的工具或模型
- 时间意识:在时限内完成任务
- 能耗意识:优化计算资源使用
16.5 推理技术 Reasoning Techniques
提升 Agent 的思考能力:
- 链式思考(Chain-of-Thought):让 LLM “一步一步想”
- 思维树(Tree of Thoughts):探索多种可能的推理路径
- 自我一致性(Self-Consistency):多次采样,选择最一致的答案
16.6 优先级排序 Prioritization
Agent 能够管理多个任务:
- 紧急重要矩阵:区分任务的优先级
- 动态调整:根据新信息重新排序
- 资源分配:将有限资源投入到最重要的任务
16.7 探索与发现 Exploration and Discovery
Agent 能够主动探索未知:
- 信息收集:主动搜索缺失的信息
- 假设验证:提出假设并验证
- 知识扩展:发现新的知识领域
第十七章:主流框架对比与选择
17.1 框架概览
| 框架 | 开发方 | 核心特点 | 适用场景 |
|---|---|---|---|
| LangChain | 社区/公司 | 组件丰富、生态完善 | 通用 Agent 开发 |
| LangGraph | LangChain 团队 | 图结构、状态管理 | 复杂工作流 |
| Google ADK | 与 Gemini 深度集成 | Google 生态项目 | |
| CrewAI | 社区 | 角色扮演、易上手 | 多智能体协作 |
| AutoGen | Microsoft | 对话驱动、代码生成 | 编程辅助 |
| Semantic Kernel | Microsoft | 企业级、多语言 | 企业应用 |
17.2 详细对比
LangChain
优点:
- 最成熟的生态,文档丰富
- 大量预置组件和集成
- 社区活跃,问题容易找到答案
缺点:
- 版本迭代快,有时有破坏性变更
- 抽象层次多,学习曲线较陡
适合:大多数 Agent 项目,特别是需要快速原型开发LangGraph
优点:
- 基于图的工作流定义,灵活强大
- 内置状态管理
- 支持循环和条件分支
缺点:
- 比 LangChain 更复杂
- 需要理解图的概念
适合:复杂的多步骤工作流、需要状态持久化的场景Google ADK
优点:
- 与 Gemini 模型深度集成
- 强大的多智能体编排能力
- Google 官方支持
缺点:
- 与 Google 生态绑定较深
- 社区相对较小
适合:使用 Google Cloud、Gemini 的项目CrewAI
优点:
- 角色扮演概念直观易懂
- 多智能体协作非常简单
- 代码简洁,上手快
缺点:
- 相对较新,生态不如 LangChain
- 复杂定制可能受限
适合:多智能体协作项目、快速原型17.3 选择建议
初学者入门 → CrewAI(简单直观)
通用项目 → LangChain(生态完善)
复杂工作流 → LangGraph(图结构强大)
Google 生态 → Google ADK(深度集成)
编程辅助 → AutoGen(Microsoft 出品)
企业应用 → Semantic Kernel(企业级特性)第十八章:学习路径与实践建议
18.1 学习路径
第一阶段:理解基础(1-2 周)
- 阅读本教程,理解各设计模式的核心概念
- 了解 LLM 的基本原理和能力边界
- 尝试用简单的提示词链完成一个任务
- 了解至少一个框架(LangChain 或 CrewAI)的基本用法
第二阶段:动手实践(2-4 周)
- 实现一个带工具使用的 Agent(如天气查询)
- 尝试路由模式,构建简单的分类系统
- 实践并行化,同时调用多个 API
- 为 Agent 添加记忆功能
第三阶段:进阶探索(1-2 个月)
- 构建多智能体系统(如内容创作团队)
- 集成 RAG,让 Agent 能访问私有知识库
- 添加评估和监控机制
- 部署 Agent 到生产环境
第四阶段:深入精通(持续)
- 阅读《Agentic Design Patterns》原书全部章节
- 贡献开源项目
- 探索前沿研究和新技术
- 构建自己的 Agent 产品
18.2 实践建议
从一个简单的用例开始
- 不要试图一次性构建完美的系统
- 先让 Agent 做好一件事
逐步增加复杂度
- 先单 Agent,再多 Agent
- 先固定流程,再动态规划
- 先无记忆,再加记忆
多参考开源项目
- GitHub 上有大量示例代码
- 学习他人的实现方式
关注安全性
- 给 Agent 的权限遵循最小权限原则
- 敏感操作加人工确认
- 做好输入输出过滤
持续评估优化
- 建立评估基准
- 收集用户反馈
- 迭代改进
加入社区
- LangChain Discord
- CrewAI 社区
- 中文 AI 社区
18.3 推荐资源
| 资源 | 链接 | 说明 |
|---|---|---|
| 《Agentic Design Patterns》中文翻译 | https://adp.xindoo.xyz/ | 本书完整中文翻译 |
| GitHub 仓库 | https://github.com/xindoo/agentic-design-patterns | 源代码和翻译 |
| LangChain 文档 | https://python.langchain.com/ | 最全面的框架文档 |
| Google ADK 文档 | https://google.github.io/adk-docs/ | Google 官方文档 |
| CrewAI 文档 | https://docs.crewai.com/ | 多智能体框架文档 |
| OpenAI API 文档 | https://platform.openai.com/docs | API 使用指南 |
附录:术语表与资源
术语表
| 术语 | 英文 | 说明 |
|---|---|---|
| Agent | Agent | 能够自主感知环境、做出决策并执行行动的系统 |
| LLM | Large Language Model | 大语言模型,如 GPT、Gemini、Claude |
| 提示词 | Prompt | 给 LLM 的输入指令 |
| 提示词链 | Prompt Chaining | 将任务分解为多个顺序步骤的模式 |
| RAG | Retrieval-Augmented Generation | 检索增强生成,结合外部知识库的技术 |
| MCP | Model Context Protocol | 模型上下文协议,标准化 Agent 与工具的通信 |
| A2A | Agent-to-Agent | Agent 间通信标准 |
| HITL | Human-in-the-Loop | 人机协同,在关键节点引入人类监督 |
| Guardrails | Guardrails | 安全防护机制,确保 Agent 行为安全 |
| Embedding | Embedding | 嵌入,将文本转换为向量的技术 |
| 向量数据库 | Vector Database | 存储和检索向量的数据库 |
| Token | Token | LLM 处理文本的最小单位 |
| 上下文窗口 | Context Window | LLM 能处理的最大输入长度 |
| 工具 | Tool | Agent 可调用的外部功能 |
| 多智能体 | Multi-Agent | 多个 Agent 协同工作的系统 |
快速参考卡片
🚀 基础模式
├── 提示词链 → 分解复杂任务
├── 路由 → 分发到不同处理路径
└── 并行化 → 同时执行独立任务
🧠 进阶模式
├── 反思 → 自我评估和改进
├── 工具使用 → 连接外部世界
└── 规划 → 动态分解目标
🤝 高级模式
├── 多智能体协作 → 团队化工作
├── 记忆管理 → 记住上下文
└── 知识检索 → 访问外部知识
🛡️ 实践模式
├── 人机协同 → 人类监督
├── 安全防护 → 行为约束
└── 评估监控 → 质量保证
🔗 协议标准
├── MCP → Agent 与工具的标准
└── A2A → Agent 与 Agent 的标准结语
AI Agent 正在从概念走向应用,从实验室走向生产环境。掌握这些设计模式,将帮助你构建更可靠、更智能、更实用的 Agent 系统。
记住:最好的学习方式是动手实践。选择一个你感兴趣的项目,从今天开始构建你的第一个 Agent 吧!
祝你学习愉快,构建出强大的 AI Agent!🚀