智能体设计模式（二）反思-工具使用-规划
本文是"智能体设计模式"系列的第二部分，重点介绍了反思、工具使用和规划三种核心模式。反思模式通过让AI自我评估和改进输出质量，类比于人类写作时的反复修改过程；工具使用模式赋予AI调用外部API和资源的能力；规划模式则使AI能够分解复杂任务并制定执行策略。文章通过生活化比喻和代码示例，详细阐述了这些模式的实现原理和应用场景，为开发者构建更智能的AI系统提供了实用框架。
·
智能体设计模式（二）反思-工具使用-规划
本文是"智能体设计模式"系列的第二篇，涵盖第4-6章：反思、工具使用、规划。
系列文章：
- 智能体设计模式（一）提示链-路由-并行化
- 智能体设计模式（二）反思-工具使用-规划（本文）
- 智能体设计模式（三）多智能体协作-记忆管理-学习与适应
- …
第四章：反思（Reflection）
人贵有自知之明，AI 也是。会反思的智能体，才是真正聪明的智能体。
一、一句话定位
反思模式解决什么问题？
反思模式 = 让 AI 学会"三省吾身"
就像写作文：先写初稿，再自己检查，发现问题改一改，反复几次才交卷
适合谁学？
- 想提升 AI 输出质量的开发者
- 正在构建需要高准确性系统的工程师
- 对智能体自我改进机制感兴趣的技术人员
不适合谁？
- 对响应速度要求极高的实时场景（反思需要时间）
- 简单任务不需要这么"较真"
二、核心框架（知识骨架）
核心观点：
AI 的第一次输出往往不完美 = 学生的第一稿作文
反思模式 = 让 AI 自己当老师，批改自己的作业，然后重写
反复几轮 = 从 60 分提升到 90 分
关键概念速查表：
| 概念 | 大白话解释 | 生活比喻 | 一句话记忆 |
|---|---|---|---|
| 反思模式 | AI 评估并改进自己的输出 | 写完作文自己检查 | 自我纠错 |
| 生产者-评论者 | 一个生成，一个批评 | 作者和编辑 | 分工审查 |
| 反馈循环 | 生成→评估→改进→再评估 | 改稿→审稿→再改 | 迭代优化 |
| 停止条件 | 什么时候算"够好了" | 截稿日期 | 适可而止 |
知识地图：
初始输出 → 自我评估 → 发现问题 → 改进输出 → 再次评估 → ... → 满意输出
↓ ↓ ↓ ↓ ↓ ↓
第一稿 找茬儿 列问题 写二稿 再找茬 交终稿
三、深入浅出讲解
开场钩子 🎣
你有没有这样的经历？
写完一封重要邮件，点击发送前，你会：
- 再读一遍，检查有没有错别字
- 想想语气是否合适
- 确认附件有没有忘记
- 可能还会改几个词
这就是反思！
现在问题来了：AI 写完东西就直接输出，从不检查。就像那个总是"写完就交"的同学，作文里错别字连篇，逻辑混乱，但他自己浑然不觉。
反思模式就是教会 AI 这个"写完检查"的好习惯。
【概念1：为什么 AI 需要反思？】
一句话是什么：AI 的第一次输出往往不够好，需要自我检查和改进。
生活化比喻：
想象你是一个厨师，做了一道菜：
普通厨师：做完就端上去
优秀厨师：做完先尝一口，咸了加点糖，淡了加点盐，摆盘不好看再调整
AI 也是一样：
普通 AI：生成就输出
反思 AI：生成后自检，发现问题就改进
AI 第一次输出的常见问题：
| 问题类型 | 表现 | 例子 |
|---|---|---|
| 不准确 | 事实错误 | “地球是太阳系最大的行星” |
| 不完整 | 遗漏要点 | 让写5点，只写了3点 |
| 不连贯 | 前后矛盾 | 前面说A好，后面说A不好 |
| 不符合要求 | 忽视指令 | 让写JSON，输出了纯文本 |
| 幻觉 | 编造内容 | 引用不存在的论文 |
引经据典：
"吾日三省吾身" —— 曾子
翻译成 AI 语言：
我每天要多次反思自己的输出：
- 生成的内容准确吗？
- 有没有遗漏重要信息？
- 是否符合用户的要求？
【概念2：反思模式的核心流程】
一句话是什么：生成 → 评估 → 改进 → 再评估，循环往复直到满意。
生活化比喻：
反思模式就像健身教练指导你做动作：
第1轮：
- 你：做一个深蹲（生成）
- 教练：膝盖内扣了，背也弯了（评估）
- 你：好的，我调整一下（改进）
第2轮：
- 你：再做一个深蹲（生成）
- 教练：膝盖好多了，但下蹲不够深（评估）
- 你：明白，我再试试（改进）
第3轮：
- 你：这次呢？（生成）
- 教练：完美！（停止）
反思模式的四个步骤：
┌─────────────────────────────────────────────────────┐
│ 1. 执行（Execution） │
│ 智能体执行任务，生成初始输出 │
│ ↓ │
│ 2. 评估（Evaluation） │
│ 分析输出：准确性、完整性、风格、是否符合要求 │
│ ↓ │
│ 3. 反思/改进（Reflection/Refinement） │
│ 根据评估结果，确定改进方向，生成更好的版本 │
│ ↓ │
│ 4. 迭代（Iteration） │
│ 重复以上步骤，直到满意或达到最大次数 │
└─────────────────────────────────────────────────────┘
幽默包装：
反思模式就像程序员改 Bug：
第1版代码：能跑（大概）
Code Review：这里有问题，那里也有问题
第2版代码：改了一些
Code Review：好多了，但这个边界情况没处理
第3版代码：又改了
Code Review：LGTM（Looks Good To Me）！
区别是：反思模式里，程序员和 Reviewer 都是 AI 自己。
【概念3：生产者-评论者模型】
一句话是什么：让一个 AI 生成内容，另一个 AI 专门挑毛病。
生活化比喻：
想象一个出版社的工作流程：
作者（生产者）：写书稿
编辑（评论者）：审稿、挑错、提建议
作者：根据建议修改
编辑：再审
...
最终：出版
为什么要分开？
- 作者容易"当局者迷"，看不到自己的问题
- 编辑以"旁观者清"的视角，更容易发现问题
为什么分开比自己审自己更好？
| 方式 | 优点 | 缺点 |
|---|---|---|
| 自我反思 | 简单，成本低 | 容易"认知偏见"，对自己的错误视而不见 |
| 生产者-评论者 | 更客观，发现更多问题 | 需要两次 LLM 调用，成本更高 |
代码示例中的体现：
# 生产者：专注于生成内容
generator = LlmAgent(
name="DraftWriter",
instruction="Write a short, informative paragraph about the user's subject."
)
# 评论者：专注于挑毛病
reviewer = LlmAgent(
name="FactChecker",
instruction="""
You are a meticulous fact-checker.
Carefully verify the factual accuracy of all claims.
"""
)
引经据典：
"兼听则明，偏信则暗" —— 《资治通鉴》
一个人的视角有限，两个角色互相审视，才能发现更多问题。
【概念4：反思模式的实际应用场景】
场景1：创意写作和内容生成
用例：AI 写博客文章
流程：
1. 生成初稿
2. 评估：流畅性、语气、清晰度
3. 根据评估重写
4. 重复直到满意
好处：产出更精致、更有效的内容
场景2：代码生成和调试
用例：AI 写 Python 函数
流程：
1. 写初始代码
2. 运行测试或静态分析
3. 识别错误或低效之处
4. 根据发现优化代码
好处：生成更健壮、功能更完整的代码
场景3：复杂问题解决
用例：AI 解逻辑谜题
流程：
1. 提出一个解题步骤
2. 评估是否推进了问题解决
3. 如果引入矛盾，回退尝试其他步骤
好处：增强在复杂问题中的分析能力
场景4：摘要和信息综合
用例：AI 总结长文档
流程：
1. 生成初步摘要
2. 与原文要点对照
3. 补充遗漏，修正错误
好处：生成更准确、更全面的摘要
场景5：规划和策略
用例：AI 制定行动计划
流程：
1. 生成计划
2. 模拟执行或评估可行性
3. 根据评估调整计划
好处：制定更有效、更符合实际的计划
场景6：对话智能体
用例：客服聊天机器人
流程：
1. 生成回复
2. 回顾对话历史，检查连贯性
3. 确保准确回应用户最新输入
好处：实现更自然、更高效的沟通
四、实践示例（代码演示）
示例1：LangChain 实现反思循环
场景：迭代生成并优化一个计算阶乘的 Python 函数。
import os
from langchain_openai import ChatOpenAI
from langchain_core.messages import SystemMessage, HumanMessage
# 初始化模型
llm = ChatOpenAI(model="gpt-4o", temperature=0.1)
def run_reflection_loop():
"""
通过多步骤反思循环，逐步改进 Python 函数
"""
# 核心任务
task_prompt = """
创建一个名为 `calculate_factorial` 的 Python 函数：
1. 接受一个整数 n 作为输入
2. 计算其阶乘 (n!)
3. 包含清晰的文档字符串
4. 处理边界情况：0 的阶乘是 1
5. 处理无效输入：负数时抛出 ValueError
"""
max_iterations = 3
current_code = ""
message_history = [HumanMessage(content=task_prompt)]
for i in range(max_iterations):
print(f"\n{'='*25} 反思循环：第 {i + 1} 轮 {'='*25}")
# --- 1. 生成/改进阶段 ---
if i == 0:
print("\n>>> 阶段1：生成初始代码...")
response = llm.invoke(message_history)
current_code = response.content
else:
print("\n>>> 阶段1：根据反馈改进代码...")
message_history.append(HumanMessage(content="请根据上述反馈改进代码。"))
response = llm.invoke(message_history)
current_code = response.content
print(f"\n--- 生成的代码 (v{i + 1}) ---\n{current_code}")
message_history.append(response)
# --- 2. 反思阶段 ---
print("\n>>> 阶段2：评审代码...")
# 评论者的提示词
reflector_prompt = [
SystemMessage(content="""
你是一位高级软件工程师和 Python 专家。
你的职责是进行细致的代码审查。
根据原始任务要求，批判性地评估代码。
检查 bug、风格问题、遗漏的边界情况和改进空间。
如果代码完美符合所有要求，回复 'CODE_IS_PERFECT'。
否则，以列表形式提供你的改进建议。
"""),
HumanMessage(content=f"原始任务：\n{task_prompt}\n\n待审查代码：\n{current_code}")
]
critique_response = llm.invoke(reflector_prompt)
critique = critique_response.content
# --- 3. 停止条件 ---
if "CODE_IS_PERFECT" in critique:
print("\n--- 评审结果 ---\n代码已完美，无需进一步改进。")
break
print(f"\n--- 评审意见 ---\n{critique}")
message_history.append(HumanMessage(content=f"代码评审意见：\n{critique}"))
print(f"\n{'='*30} 最终结果 {'='*30}")
print(f"\n反思过程后的最终代码：\n{current_code}")
if __name__ == "__main__":
run_reflection_loop()
代码解读：
任务提示 → [生成初始代码] → [评论者审查] → 有问题？
↓
是 → [根据反馈改进] → 循环
否 → 输出最终代码
示例2：Google ADK 实现生产者-评论者模型
from google.adk.agents import SequentialAgent, LlmAgent
# 生产者：生成初始草稿
generator = LlmAgent(
name="DraftWriter",
description="根据给定主题生成初始草稿内容",
instruction="写一段关于用户主题的简短、信息丰富的段落。",
output_key="draft_text" # 输出保存到这个状态键
)
# 评论者：审查草稿
reviewer = LlmAgent(
name="FactChecker",
description="审查文本的事实准确性并提供结构化反馈",
instruction="""
你是一位细致的事实核查员。
1. 阅读状态键 'draft_text' 中的文本
2. 仔细核实所有声明的事实准确性
3. 输出必须是包含两个键的字典：
- "status": "ACCURATE" 或 "INACCURATE"
- "reasoning": 对状态判断的清晰解释
""",
output_key="review_output"
)
# 顺序执行：先生成，后审查
review_pipeline = SequentialAgent(
name="WriteAndReview_Pipeline",
sub_agents=[generator, reviewer]
)
# 执行流程：
# 1. generator 运行 → 保存段落到 state['draft_text']
# 2. reviewer 运行 → 读取 draft_text，保存审查结果到 state['review_output']
五、精华提炼（去废话版）
核心要点（只保留干货）：
- 自我纠错：AI 评估自己的输出，发现问题并改进 → 质量提升
- 生产者-评论者：分开生成和评审角色 → 更客观、发现更多问题
- 迭代优化：生成→评估→改进→再评估 → 逐步逼近最优
- 停止条件：设定"够好了"的标准 → 避免无限循环
必须记住的：
反思模式 = 写作文检查 = 自我批评 + 自我改进
权衡取舍：
质量 ↑ = 时间 ↑ + 成本 ↑
适用于：质量 > 速度 的场景
六、行动清单
立即可做（5分钟内）：
- 想一个你之前让 AI 生成但质量不满意的任务
- 尝试让 AI 先生成，再让它自己评估并改进
本周实践：
- 实现一个简单的反思循环（生成→评估→改进）
- 尝试分离生产者和评论者角色
进阶挑战：
- 设计合适的停止条件（迭代次数 or 质量阈值）
- 将反思模式与提示链结合使用
七、常见误区
误区1：所有任务都需要反思
❌ 错误：简单问答也要反思三轮
✅ 正确：反思适合需要高质量输出的复杂任务
误区2：反思次数越多越好
❌ 错误：反思10轮肯定比3轮好
✅ 正确：通常2-3轮就够了，过多反思收益递减，成本递增
误区3：自我反思就够了
❌ 错误：让同一个 AI 自己审自己
✅ 正确：分离生产者和评论者角色，用不同的提示词，更客观
误区4：忽视停止条件
❌ 错误：一直反思到"完美"
✅ 正确：设定明确的停止条件（次数上限 or 质量标准）
八、学习检查
基础理解：
- 能解释为什么 AI 需要反思模式
- 能说出反思模式的四个步骤
- 理解生产者-评论者模型的优势
实践能力：
- 能实现一个简单的反思循环
- 能设计评论者的提示词
- 能设定合理的停止条件
进阶理解：
- 理解反思模式与记忆管理的关系
- 理解反思模式与目标监控的协同
- 能权衡反思带来的质量提升和成本增加
九、金句收藏
原文金句：
"反思模式为智能体系统增加了一层元认知能力，
使其能从自己的处理过程和输出中学习，
从而产生更智能、更可靠、更高质量的结果。"
我的总结金句：
"AI 的第一稿是草稿，反思后的才是作品。"
"自己审自己容易'灯下黑'，让另一个角色来挑毛病更靠谱。"
"反思不是追求完美，而是追求更好。"
十、画龙点睛
总结升华：
反思模式的本质是"元认知"——让 AI 具备"思考自己思考过程"的能力。
这就像人类的成长：
- 小孩子做事不过脑子，做完就完了
- 成年人会反思：我做得对吗？有没有更好的方法？
- 高手会复盘：这次成功/失败的原因是什么？下次如何改进？
反思模式让 AI 从"小孩子"成长为"高手"。
与其他模式的联系：
反思 + 记忆 = 从历史中学习，避免重复犯错
反思 + 目标监控 = 有明确的评估标准
反思 + 提示链 = 每一步都可以反思优化
悬念预告：
反思模式让 AI 学会了"自我改进"，但如果 AI 需要与外部世界交互呢？
查数据库、调 API、执行代码——这些都需要"工具"。
下一章，我们将探索"工具使用模式"——让 AI 学会使用各种工具，
从"纸上谈兵"变成"实干家"。
一句话带走：
会反思的 AI 才是聪明的 AI，第一稿永远只是起点。
十一、延伸资源
想深入学习：
想教给别人：
- 用"写作文检查"比喻解释核心概念
- 用"作者和编辑"的例子说明生产者-评论者模型
- 用"健身教练指导动作"的例子说明迭代改进
第五章：工具使用（Tool Use / Function Calling）
光说不练假把式，会用工具的 AI 才是真本事。
一、一句话定位
工具使用模式解决什么问题？
工具使用 = 让 AI 从"纸上谈兵"变成"实干家"
就像给员工配电脑、给厨师配厨具——有了工具，才能干活
适合谁学？
- 想让 AI 与外部系统交互的开发者
- 需要 AI 获取实时数据的工程师
- 构建能"做事"而不只是"说话"的智能体
不适合谁？
- 只需要纯文本生成的简单场景
二、核心框架（知识骨架）
核心观点：
大语言模型的知识 = 训练时的数据 = 静态的、过时的
工具使用 = 给 AI 装上"手脚" = 能查、能算、能操作
AI + 工具 = 真正有用的智能体
关键概念速查表：
| 概念 | 大白话解释 | 生活比喻 | 一句话记忆 |
|---|---|---|---|
| 工具/函数 | AI 可以调用的外部能力 | 厨师的厨具 | 干活的家伙 |
| 函数调用 | AI 决定用哪个工具、传什么参数 | 点菜下单 | 选工具+填参数 |
| 工具定义 | 告诉 AI 有哪些工具可用 | 菜单 | 工具说明书 |
| 编排层 | 负责实际执行工具调用 | 后厨 | 真正干活的 |
知识地图：
用户请求 → AI 理解需求 → 决定是否用工具 → 生成调用请求 → 执行工具 → 获取结果 → 整合回复
↓ ↓ ↓ ↓ ↓ ↓ ↓
"伦敦天气" 需要实时数据 需要！ weather("London") 调API 15°C多云 "伦敦现在15°C"
三、深入浅出讲解
开场钩子 🎣
想象一下，你雇了一个"百科全书式"的助理：
- 他读过无数书籍，知识渊博
- 但他的知识停留在去年
- 他不会上网、不会打电话、不会发邮件
- 你问他"今天天气怎么样"，他只能说"我不知道"
这就是没有工具的大语言模型——满腹经纶，但与世隔绝。
工具使用模式就是给这个助理配上电脑、手机、各种软件，让他能真正帮你办事。
【概念1：为什么 AI 需要工具？】
一句话是什么：AI 的知识是静态的，工具让它能获取动态信息和执行操作。
生活化比喻：
大语言模型 = 一个博学的书呆子
他的问题：
1. 知识有截止日期（"2024年美国总统是谁？" → "我不确定"）
2. 不会算数（"123456 × 789012 = ?" → 可能算错）
3. 不能访问你的数据（"我的订单状态？" → "我不知道"）
4. 不能执行操作（"帮我发封邮件" → "我做不到"）
给他配上工具：
1. 搜索引擎 → 获取最新信息
2. 计算器 → 精确计算
3. 数据库接口 → 查询你的数据
4. 邮件API → 真的能发邮件
AI 的局限 vs 工具的能力：
| AI 的局限 | 工具的能力 | 例子 |
|---|---|---|
| 知识过时 | 获取实时数据 | 天气、股价、新闻 |
| 计算不准 | 精确计算 | 复杂数学运算 |
| 无法访问私有数据 | 查询数据库 | 订单状态、库存 |
| 不能执行操作 | 调用API | 发邮件、控制设备 |
| 不能运行代码 | 代码执行器 | 数据分析、脚本 |
引经据典：
"工欲善其事，必先利其器" —— 《论语》
AI 要想真正有用，必须有趁手的工具。
【概念2：工具使用的核心流程】
一句话是什么：定义工具 → AI 决策 → 生成调用 → 执行工具 → 返回结果。
生活化比喻：
工具使用就像在餐厅点餐：
1. 菜单（工具定义）
- 宫保鸡丁：需要辣度（参数）
- 红烧肉：需要份量（参数）
2. 顾客点餐（用户请求）
"我想吃辣的鸡肉菜"
3. 服务员理解（AI 决策）
"这位客人需要宫保鸡丁"
4. 下单（生成调用）
{菜名: "宫保鸡丁", 辣度: "中辣"}
5. 后厨做菜（执行工具）
厨师按订单做菜
6. 上菜（返回结果）
一盘宫保鸡丁端上来
7. 服务员介绍（整合回复）
"这是您点的宫保鸡丁，中辣口味"
工具使用的六个步骤：
┌─────────────────────────────────────────────────────┐
│ 1. 工具定义（Tool Definition） │
│ 向 AI 描述可用的工具：名称、用途、参数 │
│ ↓ │
│ 2. AI 决策（LLM Decision） │
│ AI 判断是否需要使用工具 │
│ ↓ │
│ 3. 生成调用（Function Call Generation） │
│ AI 生成结构化的调用请求（JSON） │
│ ↓ │
│ 4. 工具执行（Tool Execution） │
│ 编排层执行实际的函数调用 │
│ ↓ │
│ 5. 获取结果（Observation/Result） │
│ 工具返回执行结果 │
│ ↓ │
│ 6. 整合回复（LLM Processing） │
│ AI 将结果整合成用户友好的回复 │
└─────────────────────────────────────────────────────┘
幽默包装：
工具使用就像程序员的日常：
用户："帮我查一下这个 Bug 的原因"
没有工具的 AI：
"Bug 可能是因为空指针、数组越界、类型错误..."（一通理论）
有工具的 AI：
1. 调用日志查询工具 → 找到错误堆栈
2. 调用代码搜索工具 → 定位问题代码
3. 调用文档搜索工具 → 找到解决方案
"根据日志，问题出在第42行，这里数组越界了，建议加个边界检查"
区别：一个在"猜"，一个在"查"。
【概念3：工具定义的艺术】
一句话是什么：好的工具定义 = AI 能正确理解和使用工具。
生活化比喻：
工具定义就像写产品说明书：
差的说明书：
"这是个工具，能做很多事"
→ 用户不知道怎么用
好的说明书：
"这是电钻，用于在墙上打孔
- 参数1：孔径（6mm/8mm/10mm）
- 参数2：深度（厘米）
- 注意：使用前确认墙内无电线"
→ 用户一看就会
工具定义的关键要素：
@tool
def get_weather(location: str, unit: str = "celsius") -> str:
"""
获取指定地点的当前天气信息。
参数：
- location: 城市名称，如 "北京"、"London"
- unit: 温度单位，"celsius"（摄氏度）或 "fahrenheit"（华氏度）
返回：
- 包含温度、天气状况的字符串
使用场景：
- 用户询问天气时使用
- 如 "北京天气怎么样"、"伦敦现在多少度"
"""
# 实际实现...
好的工具定义要点：
| 要素 | 说明 | 例子 |
|---|---|---|
| 清晰的名称 | 一看就知道干什么 | get_weather 而非 func1 |
| 详细的描述 | 说明用途和使用场景 | “获取指定地点的当前天气” |
| 参数说明 | 每个参数的类型和含义 | location: str - 城市名称 |
| 返回值说明 | 返回什么格式的数据 | “返回包含温度的字符串” |
【概念4：工具使用的实际应用场景】
场景1：信息检索
用例：天气查询智能体
工具：天气 API
流程：
1. 用户："伦敦天气怎么样？"
2. AI 识别需要天气工具
3. 调用 weather_api("London")
4. 返回：15°C，多云
5. AI 回复："伦敦现在15°C，多云"
场景2：数据库交互
用例：电商客服智能体
工具：订单查询 API、库存 API
流程：
1. 用户："我的订单到哪了？"
2. AI 调用订单查询工具
3. 返回：已发货，预计明天到达
4. AI 回复："您的订单已发货，预计明天送达"
场景3：计算和数据分析
用例：金融分析智能体
工具：计算器、股票 API
流程：
1. 用户："苹果股票现价多少？如果我150美元买了100股，现在赚多少？"
2. AI 调用股票 API → 当前价 178.15
3. AI 调用计算器 → (178.15 - 150) × 100 = 2815
4. AI 回复："苹果当前股价178.15美元，您的100股盈利2815美元"
场景4：发送通信
用例：个人助理智能体
工具：邮件 API
流程：
1. 用户："给张三发邮件，提醒他明天开会"
2. AI 提取收件人、主题、内容
3. 调用邮件 API 发送
4. AI 回复："邮件已发送给张三"
场景5：代码执行
用例：编程助手智能体
工具：代码解释器
流程：
1. 用户："帮我算一下1到100的质数有哪些"
2. AI 编写 Python 代码
3. 调用代码执行器运行
4. 返回结果列表
5. AI 回复："1到100的质数有：2, 3, 5, 7, 11..."
场景6：智能家居控制
用例：智能家居智能体
工具：设备控制 API
流程：
1. 用户："关掉客厅的灯"
2. AI 识别设备和操作
3. 调用智能家居 API
4. AI 回复："客厅灯已关闭"
四、实践示例（代码演示）
示例1：LangChain 实现工具调用
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate
# 初始化模型
llm = ChatOpenAI(model="gpt-4o", temperature=0)
# --- 定义工具 ---
@tool
def search_information(query: str) -> str:
"""
提供关于特定主题的事实信息。
用于回答类似"法国首都是哪里"或"伦敦天气如何"的问题。
"""
print(f"\n--- 🛠️ 工具被调用: search_information, 查询: '{query}' ---")
# 模拟搜索结果
simulated_results = {
"weather in london": "伦敦当前天气：多云，温度15°C",
"capital of france": "法国的首都是巴黎",
"population of earth": "地球人口约80亿",
}
result = simulated_results.get(query.lower(), f"未找到关于'{query}'的具体信息")
print(f"--- 工具返回: {result} ---")
return result
tools = [search_information]
# --- 创建智能体 ---
agent_prompt = ChatPromptTemplate.from_messages([
("system", "你是一个有帮助的助手，可以使用工具来回答问题。"),
("human", "{input}"),
("placeholder", "{agent_scratchpad}"),
])
agent = create_tool_calling_agent(llm, tools, agent_prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
# --- 运行 ---
response = agent_executor.invoke({"input": "法国的首都是哪里？"})
print(f"\n最终回复: {response['output']}")
代码解读：
用户问题 → AI 判断需要工具 → 生成调用请求 → 执行工具 → 获取结果 → 整合回复
↓ ↓ ↓ ↓ ↓ ↓
"法国首都" 需要查询！ search("capital 执行函数 "巴黎" "法国首都是巴黎"
of france")
示例2：Google ADK 使用内置工具
from google.adk.agents import Agent
from google.adk.tools import google_search
# 定义使用 Google 搜索的智能体
search_agent = Agent(
name="search_agent",
model="gemini-2.0-flash-exp",
description="使用 Google 搜索回答问题的智能体",
instruction="我可以通过搜索互联网来回答你的问题，尽管问我任何事！",
tools=[google_search] # 内置的 Google 搜索工具
)
# 调用智能体
async def ask_agent(query):
# ... 会话和执行器设置 ...
response = await runner.run(query)
print(f"智能体回复: {response}")
# 示例调用
await ask_agent("最新的 AI 新闻是什么？")
示例3：代码执行工具
from google.adk.agents import LlmAgent
from google.adk.code_executors import BuiltInCodeExecutor
# 定义可以执行代码的智能体
code_agent = LlmAgent(
name="calculator_agent",
model="gemini-2.0-flash",
code_executor=BuiltInCodeExecutor(),
instruction="""你是一个计算器智能体。
当收到数学表达式时，编写并执行 Python 代码来计算结果。
只返回最终的数值结果。
""",
description="执行 Python 代码进行计算",
)
# 示例调用
await code_agent.run("计算 (5 + 7) * 3 的值")
# 输出: 36
await code_agent.run("10 的阶乘是多少？")
# 输出: 3628800
五、精华提炼（去废话版）
核心要点（只保留干货）：
- 突破局限：工具让 AI 能获取实时数据、执行操作 → 从"说"到"做"
- 标准流程：定义工具 → AI 决策 → 生成调用 → 执行 → 返回结果
- 好的工具定义：清晰的名称、详细的描述、明确的参数 → AI 才能正确使用
- 框架支持：LangChain、Google ADK、CrewAI 都提供工具集成能力
必须记住的：
工具使用 = AI 的"手脚" = 能查能算能操作
六、行动清单
立即可做（5分钟内）：
- 想一个你希望 AI 能做但目前做不到的事（如查实时数据）
- 思考需要什么工具才能实现
本周实践：
- 用 LangChain 的 @tool 装饰器定义一个简单工具
- 创建一个能使用该工具的智能体
进阶挑战：
- 让智能体同时使用多个工具
- 尝试使用 Google ADK 的内置工具（搜索、代码执行）
七、常见误区
误区1：工具定义太模糊
❌ 错误：description="这是一个工具"
✅ 正确：description="获取指定城市的实时天气，返回温度和天气状况"
误区2：参数说明不清
❌ 错误：def search(q): ...
✅ 正确：def search(query: str) -> str:
"""query: 搜索关键词，如'北京天气'"""
误区3：忽视错误处理
❌ 错误：工具调用失败就崩溃
✅ 正确：捕获异常，返回友好的错误信息
误区4：工具太多太杂
❌ 错误：给 AI 配100个工具
✅ 正确：只配必要的工具，太多会让 AI 困惑
八、学习检查
基础理解：
- 能解释为什么 AI 需要工具
- 能说出工具使用的六个步骤
- 理解工具定义的关键要素
实践能力：
- 能用 @tool 装饰器定义工具
- 能创建使用工具的智能体
- 能处理工具调用的错误情况
进阶理解：
- 理解函数调用与工具调用的区别
- 能设计多工具协作的智能体
- 理解工具使用与其他模式的结合
九、金句收藏
原文金句：
"工具使用模式将语言模型从文本生成器变成
能够在数字或现实世界中感知、推理和行动的智能体。"
我的总结金句：
"没有工具的 AI 是书呆子，有了工具的 AI 是实干家。"
"AI 的知识有保质期，工具让它永远保鲜。"
"定义好工具，就是给 AI 写好说明书。"
十、画龙点睛
总结升华：
工具使用模式的本质是"能力扩展"——
让 AI 从一个"只会说"的语言模型，
变成一个"能做事"的智能体。
这就像人类的进化：
- 原始人只有双手 → 能力有限
- 学会使用工具 → 能力倍增
- 发明各种机器 → 改变世界
AI 也在经历同样的进化：
- 纯语言模型 → 只能生成文本
- 加上工具 → 能查、能算、能操作
- 未来 → 真正的通用智能体
工具使用的哲学：
"工具是人类能力的延伸" —— 马歇尔·麦克卢汉
对 AI 来说也是如此：
- 搜索工具 = 延伸的记忆
- 计算工具 = 延伸的大脑
- API 工具 = 延伸的手脚
悬念预告：
工具使用让 AI 能"做事"了，但如果任务很复杂，需要制定计划呢？
先做什么、后做什么、遇到问题怎么调整？
下一章，我们将探索"规划模式"——让 AI 学会"运筹帷幄"，
像下棋一样思考几步之后的事情。
一句话带走：
给 AI 配上工具，它就能从"纸上谈兵"变成"实干家"。
十一、延伸资源
想深入学习：
想教给别人：
- 用"餐厅点餐"比喻解释工具使用流程
- 用"书呆子 vs 实干家"对比说明工具的价值
- 用"产品说明书"类比解释工具定义的重要性
第六章：规划（Planning）
不谋万世者，不足谋一时；不谋全局者，不足谋一域。会规划的 AI，才能运筹帷幄。
一、一句话定位
规划模式解决什么问题？
规划模式 = 让 AI 学会"先想后做"
就像下棋：不是走一步看一步，而是提前想好几步棋
适合谁学？
- 需要 AI 处理复杂多步骤任务的开发者
- 构建自动化工作流的工程师
- 想让 AI 更"聪明"地完成目标的技术人员
不适合谁？
- 简单的一问一答场景
- 解决方案已经明确固定的任务
二、核心框架（知识骨架）
核心观点：
复杂任务 ≠ 一步到位
规划模式 = 把大目标拆成小步骤 + 按顺序执行 + 遇到问题能调整
AI + 规划 = 从"执行者"变成"策略家"
关键概念速查表：
| 概念 | 大白话解释 | 生活比喻 | 一句话记忆 |
|---|---|---|---|
| 规划 | 制定达成目标的步骤序列 | 旅行攻略 | 先想后做 |
| 目标分解 | 把大目标拆成小任务 | 吃大象要一口一口 | 化整为零 |
| 动态调整 | 遇到问题能改计划 | 堵车换路线 | 随机应变 |
| 执行计划 | 按步骤一步步做 | 按攻略玩游戏 | 按图索骥 |
知识地图：
复杂目标 → 理解目标 → 分解任务 → 制定计划 → 执行步骤 → 检查结果 → 调整计划
↓ ↓ ↓ ↓ ↓ ↓ ↓
"组织团建" 明确需求 拆成子任务 排好顺序 一步步做 看效果 遇阻调整
三、深入浅出讲解
开场钩子 🎣
想象你要组织一次公司团建：
没有规划的做法：
- “先订酒店吧” → 发现没确定人数
- “那先统计人数” → 发现没确定日期
- “那先定日期” → 发现老板那天出差
- “那换个日期” → 发现酒店没房了
- ……一团乱麻
有规划的做法：
- 确定日期（先和老板确认）
- 统计人数
- 选择目的地
- 预订酒店和交通
- 安排活动
- 通知大家
这就是规划的力量——先想清楚再动手，事半功倍。
【概念1：为什么 AI 需要规划？】
一句话是什么：复杂任务需要多步骤协调，没有规划就会乱套。
生活化比喻：
没有规划的 AI = 无头苍蝇
你说："帮我写一份市场调研报告"
无头苍蝇式：
- 先写个标题？不对，还不知道调研什么
- 先搜索资料？不对，还不知道搜什么
- 先做个大纲？不对，还不知道要包含什么
- ……东一榔头西一棒子
有规划的 AI：
1. 明确调研主题和目标
2. 确定需要收集的信息类型
3. 搜索相关资料
4. 整理和分析数据
5. 撰写报告大纲
6. 填充各部分内容
7. 审阅和润色
规划的核心价值：
| 没有规划 | 有规划 |
|---|---|
| 走一步看一步 | 提前想好几步 |
| 遇到问题才发现 | 提前预见问题 |
| 步骤混乱 | 步骤有序 |
| 容易遗漏 | 覆盖全面 |
| 效率低下 | 高效执行 |
引经据典：
"凡事预则立，不预则废" —— 《礼记》
翻译成 AI 语言：
复杂任务先规划再执行，才能成功；
不规划就动手，大概率失败。
【概念2：规划模式的核心流程】
一句话是什么：理解目标 → 分解任务 → 制定计划 → 执行 → 检查 → 调整。
生活化比喻：
规划模式就像做菜：
1. 理解目标：今晚要做红烧肉
2. 分解任务：
- 买五花肉
- 准备调料（酱油、糖、料酒...）
- 切肉、焯水
- 炒糖色
- 炖煮
- 收汁
3. 制定计划：先买菜，再准备，最后烹饪
4. 执行：按步骤做
5. 检查：尝一下咸淡
6. 调整：太淡加盐，太咸加糖
规划模式的关键特征：
┌─────────────────────────────────────────────────────┐
│ 1. 目标理解（Goal Understanding） │
│ 明确要达成什么，有什么约束条件 │
│ ↓ │
│ 2. 任务分解（Task Decomposition） │
│ 把大目标拆成可执行的小任务 │
│ ↓ │
│ 3. 计划制定（Plan Formulation） │
│ 确定任务的执行顺序和依赖关系 │
│ ↓ │
│ 4. 计划执行（Plan Execution） │
│ 按计划一步步执行 │
│ ↓ │
│ 5. 监控调整（Monitor & Adapt） │
│ 检查执行结果，遇到问题调整计划 │
└─────────────────────────────────────────────────────┘
幽默包装：
规划模式就像程序员接需求：
产品经理："做一个电商网站"
没有规划的程序员：
"好的！" → 开始写代码 → 写了一半发现需求不清 → 推倒重来 →
又写了一半发现架构不对 → 再推倒重来 → 项目延期三个月
有规划的程序员：
1. 需求分析：用户能干什么？管理员能干什么？
2. 技术选型：用什么框架？什么数据库？
3. 架构设计：前后端怎么分？模块怎么划分？
4. 任务拆分：登录模块、商品模块、订单模块...
5. 排期计划：第一周做登录，第二周做商品...
6. 开始开发：按计划推进
7. 定期检查：进度如何？需要调整吗？
结果：按时交付，皆大欢喜
【概念3：动态规划 vs 固定流程】
一句话是什么：已知解决方案用固定流程，未知问题用动态规划。
生活化比喻：
固定流程 = 按菜谱做菜
- 步骤已知，照着做就行
- 适合：做过很多次的菜
动态规划 = 创意料理
- 根据现有食材即兴发挥
- 遇到问题随时调整
- 适合：第一次尝试的新菜
什么时候用哪种？
| 场景 | 选择 | 原因 |
|---|---|---|
| 新员工入职流程 | 固定流程 | 步骤已知且标准化 |
| 市场调研报告 | 动态规划 | 需要根据发现调整方向 |
| 数据备份 | 固定流程 | 步骤固定，不需要变化 |
| 竞品分析 | 动态规划 | 需要根据信息动态调整 |
权衡取舍：
动态规划：
✅ 灵活，能应对变化
❌ 不可预测，可能出错
固定流程：
✅ 可预测，结果稳定
❌ 不灵活，无法应对变化
选择原则：
- "如何做"已知 → 固定流程
- "如何做"需要探索 → 动态规划
【概念4：规划模式的实际应用场景】
场景1：流程自动化
用例：新员工入职
规划：
1. 创建系统账户
2. 分配培训课程
3. 安排导师
4. 协调各部门
5. 发送欢迎邮件
特点：步骤明确，按顺序执行
场景2：研究报告生成
用例：生成市场调研报告
规划：
1. 明确调研主题
2. 收集相关资料
3. 分析数据
4. 撰写大纲
5. 填充内容
6. 审阅润色
特点：需要根据发现动态调整
场景3：复杂问题解决
用例：客户投诉处理
规划：
1. 了解问题详情
2. 诊断问题原因
3. 制定解决方案
4. 执行解决方案
5. 确认客户满意
6. 必要时升级处理
特点：需要根据情况灵活调整
场景4：自主导航
用例：机器人路径规划
规划：
1. 确定起点和终点
2. 分析环境障碍
3. 计算最优路径
4. 执行移动
5. 遇到障碍重新规划
特点：需要实时感知和调整
四、实践示例（代码演示）
示例1：CrewAI 实现规划模式
from crewai import Agent, Task, Crew, Process
from langchain_openai import ChatOpenAI
# 初始化模型
llm = ChatOpenAI(model="gpt-4-turbo")
# 定义规划+执行智能体
planner_writer_agent = Agent(
role='文章规划师和作者',
goal='先制定计划，再撰写简洁、有吸引力的摘要',
backstory=(
'你是一位专业的技术作家和内容策略师。'
'你的优势在于先制定清晰、可执行的计划，'
'确保最终的摘要既有信息量又易于理解。'
),
verbose=True,
llm=llm
)
# 定义任务：先规划，再执行
topic = "强化学习在 AI 中的重要性"
planning_task = Task(
description=(
f"1. 为主题 '{topic}' 创建一个要点式的写作计划\n"
f"2. 根据计划撰写约200字的摘要"
),
expected_output=(
"包含两个部分的最终报告：\n\n"
"### 计划\n"
"- 摘要的主要要点列表\n\n"
"### 摘要\n"
"- 简洁、结构清晰的主题摘要"
),
agent=planner_writer_agent,
)
# 创建并执行 Crew
crew = Crew(
agents=[planner_writer_agent],
tasks=[planning_task],
process=Process.sequential,
)
result = crew.kickoff()
print(result)
代码解读：
任务输入 → 智能体理解目标 → 制定计划 → 按计划执行 → 输出结果
↓ ↓ ↓ ↓ ↓
"写强化学习" 明确要写什么 列出要点 逐点撰写 完整摘要
示例2：Google Deep Research 的规划流程
用户请求："研究司美格鲁肽对全球医疗系统的经济影响"
Deep Research 的规划过程：
1. 分解研究问题：
- 司美格鲁肽是什么？
- 主要应用领域？
- 对医疗成本的影响？
- 对保险系统的影响？
- 各国的政策反应？
2. 制定搜索计划：
- 搜索医学文献
- 搜索经济分析报告
- 搜索政策文件
- 搜索新闻报道
3. 执行搜索：
- 执行多轮搜索
- 根据发现调整搜索方向
- 识别知识空白，补充搜索
4. 整合结果：
- 评估信息可靠性
- 提炼主要发现
- 组织成结构化报告
- 添加引用来源
示例3：OpenAI Deep Research API
from openai import OpenAI
client = OpenAI(api_key="YOUR_API_KEY")
# 定义研究任务
system_message = """你是一位专业研究员，负责准备结构化、数据驱动的报告。
专注于数据丰富的洞察，使用可靠来源，并包含内联引用。"""
user_query = "研究司美格鲁肽对全球医疗系统的经济影响"
# 调用 Deep Research API
response = client.responses.create(
model="o3-deep-research-2025-06-26",
input=[
{"role": "developer", "content": [{"type": "input_text", "text": system_message}]},
{"role": "user", "content": [{"type": "input_text", "text": user_query}]}
],
reasoning={"summary": "auto"},
tools=[{"type": "web_search_preview"}]
)
# 获取最终报告
final_report = response.output[-1].content[0].text
print(final_report)
# 查看中间步骤（规划过程）
for item in response.output:
if item.type == "reasoning":
print("推理步骤:", item.summary)
elif item.type == "web_search_call":
print("搜索查询:", item.action['query'])
五、精华提炼（去废话版）
核心要点（只保留干货）：
- 先想后做：复杂任务先规划再执行 → 避免混乱
- 分解目标：大目标拆成小任务 → 可管理、可执行
- 动态调整：遇到问题能改计划 → 灵活应变
- 选择合适：已知方案用固定流程，未知问题用动态规划
必须记住的：
规划模式 = 运筹帷幄 = 先想清楚再动手
六、行动清单
立即可做（5分钟内）：
- 想一个你之前让 AI 做但效果不好的复杂任务
- 尝试把它拆解成 3-5 个步骤
本周实践：
- 用 CrewAI 实现一个简单的规划智能体
- 尝试 Google Deep Research 或类似工具
进阶挑战：
- 实现一个能动态调整计划的智能体
- 将规划模式与工具使用模式结合
七、常见误区
误区1：所有任务都需要规划
❌ 错误：简单问答也要先规划
✅ 正确：简单任务直接做，复杂任务才需要规划
误区2：计划一旦制定就不能改
❌ 错误：死守原计划，不管遇到什么问题
✅ 正确：计划是起点，遇到问题要灵活调整
误区3：规划越详细越好
❌ 错误：把每个细节都规划好
✅ 正确：规划到可执行的粒度即可，太细反而僵化
误区4：忽视执行监控
❌ 错误：规划完就不管了
✅ 正确：执行过程中要监控，发现问题及时调整
八、学习检查
基础理解：
- 能解释为什么复杂任务需要规划
- 能说出规划模式的核心流程
- 理解动态规划和固定流程的区别
实践能力：
- 能把复杂任务分解成可执行的步骤
- 能用代码实现简单的规划智能体
- 能根据执行情况调整计划
进阶理解：
- 理解规划模式与其他模式的结合
- 能设计适应性强的规划系统
- 理解规划的权衡（灵活性 vs 可预测性）
九、金句收藏
原文金句：
"规划模式使智能体不再局限于简单的被动反应，
而是能够以目标为导向地行动。"
我的总结金句：
"没有规划的执行是瞎忙，有规划的执行是高效。"
"计划赶不上变化，但没有计划更赶不上变化。"
"好的规划 = 想清楚 + 能调整"
十、画龙点睛
总结升华：
规划模式的本质是"战略思维"——
让 AI 从一个只会执行命令的"士兵"，
变成一个能运筹帷幄的"将军"。
这就像人类的成长：
- 小孩子：想到什么做什么
- 成年人：先想后做
- 高手：不仅想好怎么做，还想好遇到问题怎么办
规划模式让 AI 具备了这种"高手思维"。
规划的哲学：
"运筹帷幄之中，决胜千里之外" —— 《史记》
对 AI 来说：
- 运筹帷幄 = 制定计划
- 决胜千里 = 执行计划达成目标
悬念预告：
规划模式让单个 AI 变得更聪明了，
但如果任务太复杂，一个 AI 忙不过来怎么办？
下一章，我们将探索"多智能体协作模式"——
让多个 AI 像团队一样分工合作，各司其职。
一句话带走：
复杂任务先规划再执行，AI 也需要"三思而后行"。
十一、延伸资源
想深入学习：
想教给别人：
- 用"组织团建"比喻解释规划的必要性
- 用"做菜"类比解释规划的流程
- 用"下棋"说明规划的前瞻性
版本信息
- 文档版本：v1.0
- 创建日期：2026-01-16
- 基于材料：Agentic Design Patterns - Chapter 04-06
- 教学风格：教与学专家（30年教学经验 + 20年学习研究经验）
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
9
0- 0
已为社区贡献3条内容
所有评论(0)