【学习笔记】AI Agent 设计模式入门教程

59 min

基于《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/LangGraphGoogle 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 调用)的任务中特别有效
  • 采用并发架构会引入显著复杂性,影响设计、调试和日志等关键环节
  • LangChainRunnableParallelGoogle ADKParallelAgent 提供了并行执行支持
  • 并行化有助于减少整体延迟,使 Agent 系统更具响应性

第五章:进阶模式——反思 Reflection

5.1 概念理解

反思(Reflection) 模式让 Agent 能够批判性地评估自己的输出,并根据评估结果进行改进。这类似于人类写作时的”自我审校”过程——写完一段内容后,回头看看有没有问题,然后修改完善。

生活类比:就像学生写完作文后,先自己检查一遍(有没有错别字?逻辑通不通?),然后再请老师批改,根据反馈修改。

5.2 核心流程

反思模式通常包含以下四个步骤:

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│  执行   │ → │  评估   │ → │  反思   │ → │  优化   │
│ 生成初稿│    │ 检查质量│    │ 确定改进│    │ 生成改进稿│
└─────────┘    └─────────┘    └─────────┘    └─────────┘
      ↑                                              │
      └────────────── 循环迭代 ←─────────────────────┘
  1. 执行:Agent 生成初始输出(代码、文章、计划等)
  2. 评估:分析输出的准确性、连贯性、完整性、风格等
  3. 反思:确定具体的改进方向
  4. 优化:生成改进后的输出
  5. 迭代(可选):重复上述过程,直到满足质量标准

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 有两个根本局限:

  1. 知识有截止日期:无法获取训练数据之后发生的事件
  2. 无法与外部世界交互:不能查天气、不能发邮件、不能查数据库

工具使用解决了这两个问题

局限解决方案示例工具
知识过时实时信息检索搜索引擎、新闻 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 能够:

  1. 目标理解:理解用户想要达成的最终目标
  2. 任务分解:将大目标拆分为小任务
  3. 依赖分析:识别任务之间的先后依赖关系
  4. 动态调整:根据执行过程中的反馈调整计划
  5. 错误恢复:当某步失败时,重新规划替代方案

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 DeepResearchOpenAI 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 专注于自己擅长的领域
  • 设计多智能体系统时,需要明确通信协议状态共享机制
  • CrewAIGoogle 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 开发
LangGraphLangChain 团队图结构、状态管理复杂工作流
Google ADKGoogle与 Gemini 深度集成Google 生态项目
CrewAI社区角色扮演、易上手多智能体协作
AutoGenMicrosoft对话驱动、代码生成编程辅助
Semantic KernelMicrosoft企业级、多语言企业应用

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 实践建议

  1. 从一个简单的用例开始

    • 不要试图一次性构建完美的系统
    • 先让 Agent 做好一件事
  2. 逐步增加复杂度

    • 先单 Agent,再多 Agent
    • 先固定流程,再动态规划
    • 先无记忆,再加记忆
  3. 多参考开源项目

    • GitHub 上有大量示例代码
    • 学习他人的实现方式
  4. 关注安全性

    • 给 Agent 的权限遵循最小权限原则
    • 敏感操作加人工确认
    • 做好输入输出过滤
  5. 持续评估优化

    • 建立评估基准
    • 收集用户反馈
    • 迭代改进
  6. 加入社区

    • 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/docsAPI 使用指南

附录:术语表与资源

术语表

术语英文说明
AgentAgent能够自主感知环境、做出决策并执行行动的系统
LLMLarge Language Model大语言模型,如 GPT、Gemini、Claude
提示词Prompt给 LLM 的输入指令
提示词链Prompt Chaining将任务分解为多个顺序步骤的模式
RAGRetrieval-Augmented Generation检索增强生成,结合外部知识库的技术
MCPModel Context Protocol模型上下文协议,标准化 Agent 与工具的通信
A2AAgent-to-AgentAgent 间通信标准
HITLHuman-in-the-Loop人机协同,在关键节点引入人类监督
GuardrailsGuardrails安全防护机制,确保 Agent 行为安全
EmbeddingEmbedding嵌入,将文本转换为向量的技术
向量数据库Vector Database存储和检索向量的数据库
TokenTokenLLM 处理文本的最小单位
上下文窗口Context WindowLLM 能处理的最大输入长度
工具ToolAgent 可调用的外部功能
多智能体Multi-Agent多个 Agent 协同工作的系统

快速参考卡片

🚀 基础模式
   ├── 提示词链 → 分解复杂任务
   ├── 路由     → 分发到不同处理路径
   └── 并行化   → 同时执行独立任务

🧠 进阶模式
   ├── 反思     → 自我评估和改进
   ├── 工具使用 → 连接外部世界
   └── 规划     → 动态分解目标

🤝 高级模式
   ├── 多智能体协作 → 团队化工作
   ├── 记忆管理     → 记住上下文
   └── 知识检索     → 访问外部知识

🛡️ 实践模式
   ├── 人机协同     → 人类监督
   ├── 安全防护     → 行为约束
   └── 评估监控     → 质量保证

🔗 协议标准
   ├── MCP → Agent 与工具的标准
   └── A2A → Agent 与 Agent 的标准

结语

AI Agent 正在从概念走向应用,从实验室走向生产环境。掌握这些设计模式,将帮助你构建更可靠、更智能、更实用的 Agent 系统。

记住:最好的学习方式是动手实践。选择一个你感兴趣的项目,从今天开始构建你的第一个 Agent 吧!

祝你学习愉快,构建出强大的 AI Agent!🚀