AI提示词工程（高阶）第15课：ReAct模式与工具调用

📚前言

系统学习提示词，内容大纲如下：

【预告】AI提示词工程从入门到精通教程大纲-CSDN博客

前导课程：

AI提示词工程：初阶6课合集-CSDN博客

AI提示词工程（进阶）第7课：角色设定与身份模拟-CSDN博客

AI提示词工程（进阶）第8课：少样本学习-CSDN博客

AI提示词工程（进阶）第9课：思维链提示（Chain of Thought）-CSDN博客

AI提示词工程（进阶）第10课：思维树与元提示（ToT & Meta Prompting）-CSDN博客

AI提示词工程（进阶）第11课：结构化输出与格式化控制

AI提示词工程（进阶）第12课：多轮对话与上下文管理-CSDN博客

AI提示词工程（进阶）第13课：提示词安全与边界-CSDN博客

AI提示词工程（进阶）第14课：主流模型特性差异与工具选型（进阶阶段总结）-CSDN博客

第15课：ReAct模式与工具调用

📌 一句话目标：掌握让AI具备"思考-行动-观察"循环能力的ReAct框架，学会设计工具调用系统，让AI从"会说话"升级到"会干活"。

💬 恭喜你进入高级应用阶段！从这节课开始，咱要学"让AI干活"了。前面学的都是"让AI说话"，这节课学的ReAct模式，是让AI自己决定"该查什么、该调什么工具、该怎么验证结果"------这是做Agent（智能体）的基础。有点硬核，但别慌，咱拆开讲，一步步来。

🖥️ 开场：从"会说话"到"会干活"

到目前为止，咱学的所有技巧，本质都是"让AI说得更好"。

但AI有个"天生缺陷"------它只会说，不会查。

你问它"北京今天天气怎么样"，它只能凭训练数据"猜"一个答案------可能是昨天的，可能是错的。

但如果AI能"查一下实时天气"，答案就准了。

怎么让AI"查"？ 这就是这节课的核心------ReAct模式。

ReAct = Re asoning（思考）+ Acting（行动）。

它让AI进入一个循环：

复制代码

思考 → 行动 → 观察 → 再思考 → 再行动 → ...... → 最终回答

💬 一句话先记住：ReAct就是让AI"边想边干"------想一步、干一步、看结果、再想下一步。 就像你做饭：看看冰箱（观察）→ 决定做什么（思考）→ 拿食材（行动）→ 看看够不够（再观察）→ 调整菜谱（再思考）。

一、ReAct原理：AI怎么"自主决定"用不用工具？

💬 这节讲原理，有点抽象，但理解了它，你就懂了Agent的"灵魂"。别急，咱用"侦探破案"打个比方。

📌 一个完整的ReAct循环

大纲里有个经典例子，咱来拆解一下：

复制代码

思考：用户问的是北京今天的天气，我需要查询实时数据。
行动：调用 get_weather 工具，参数 location="北京"
观察：工具返回 {"temperature": 25, "condition": "晴"}
思考：已获得数据，可以组织回答。
最终回答：北京今天天气晴朗，气温25摄氏度。

拆开看，就是四步循环：

步骤	英文	干什么
思考	Reasoning	AI判断"我现在需要什么信息"
行动	Acting	AI决定"调用哪个工具"
观察	Observation	AI读取工具返回的结果
循环	Loop	根据观察结果，决定下一步

💡 打个比方：侦探破案

ReAct就像侦探破案：

思考：嫌疑人是谁？我需要什么证据？
行动：去调监控、查通话记录、走访目击者
观察：监控显示案发时嫌疑人在现场
再思考：那他的不在场证明是假的？
再行动：去查他的不在场证明是怎么来的......

侦探不会"一口气"破案，而是"查一步、想一步、再查一步"。 ReAct也是这个逻辑。

✅ 一句话总结

ReAct的本质，是让AI在"思考"和"行动"之间循环------需要信息就调工具，拿到结果就再思考，直到能给出可靠答案。 它把AI从"凭记忆回答"升级为"按需查证回答"。

二、工具设计的核心要素：AI的"工具箱"怎么造？

💬 这节是"造工具"的环节。AI要"干活"，得先有"工具"。怎么设计一个AI能"看懂、会用"的工具？三个要素。

📌 工具的三要素

一个能被AI正确调用的工具，必须包含三个要素：

要素1：名称（Name）

工具的名字，AI靠它识别"该调哪个工具"。

复制代码

get_weather

要素2：描述（Description）

用一句话说明"这个工具是干什么的、什么时候该用"。AI靠它判断"这个工具适不适合当前任务"。

复制代码

get_weather：查询指定城市的实时天气，当用户询问天气时使用。参数location为城市名。

要素3：参数Schema（Parameter Schema）

定义工具需要哪些参数、每个参数什么格式。AI靠它知道"该传什么参数"。

复制代码

{
  "location": { "type": "string", "description": "城市名，如'北京'" },
  "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius" }
}

💡 一个完整的工具定义示例

复制代码

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气信息。当用户询问天气、气温、降水时使用。",
  "parameters": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "城市名，如'北京'" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius" }
    },
    "required": ["location"]
  }
}

💬 一句话记住工具设计三要素：名称（叫什么）、描述（干什么的）、参数Schema（要什么参数）。 描述写得越清楚，AI越不会"用错工具"。

三、Function Calling机制：AI怎么"喊"工具？

💬 这节是"机制"环节。AI不是"真的"去调用工具，而是"输出一个调用请求"，由程序去执行。搞懂这个，你就知道Agent的"幕后"了。

📌 模型输出"结构化工具调用"

当AI决定调用工具时，它不会直接执行，而是输出一个结构化的调用请求：

复制代码

{
  "name": "get_weather",
  "arguments": {
    "location": "北京",
    "unit": "celsius"
  }
}

这个请求会被程序"接住"，然后由程序真正去调用 get_weather 工具，拿到结果后再"喂"回给AI。

📌 完整的工作流程

复制代码

用户：北京今天天气怎么样？
  ↓
AI：判断需要天气数据，输出工具调用请求
  ↓
程序：执行 get_weather("北京")，拿到 {"temperature": 25, "condition": "晴"}
  ↓
程序：把结果"喂"回给AI
  ↓
AI：基于结果，组织最终回答
  ↓
用户：北京今天天气晴朗，气温25摄氏度。

💬 打个比方：AI就像一个"点菜的人"，它不会自己做饭，而是"喊出菜名"（输出调用请求），后厨（程序）做好端上来（返回结果），它再"上菜"（组织回答）。Function Calling，就是AI"喊菜名"的机制。

✅ 一句话总结

Function Calling是AI与工具之间的"接口"------AI输出结构化的调用请求，程序执行工具并返回结果，AI再基于结果回答。 它让AI具备了"动手干活"的能力。

四、工具链编排：多个工具怎么配合？

💬 这节是"编排"环节。一个Agent往往不止一个工具，多个工具怎么配合？三种模式。

📌 三种编排模式

模式1：串行调用（一个接一个）

复制代码

思考：用户要查"北京到上海的机票"，我需要先查航班，再查天气。
行动：调用 search_flights(北京, 上海)
观察：返回航班列表
行动：调用 get_weather(上海)
观察：返回上海天气
思考：可以组织回答了。

模式2：并行调用（同时查多个）

复制代码

思考：用户要比较"北京和上海"的房价，我需要同时查两个城市。
行动：并行调用 get_house_price(北京) 和 get_house_price(上海)
观察：同时返回两个城市的数据
思考：可以对比了。

模式3：条件调用（根据情况决定）

复制代码

思考：用户问"明天适合出门吗"，我需要先查天气。
行动：调用 get_weather(北京)
观察：返回"明天有暴雨"
思考：有暴雨，需要再查一下交通预警。
行动：调用 get_traffic_alert(北京)
观察：返回"暴雨红色预警"
思考：可以给出建议了。

💡 三种模式对比

模式	适用场景	特点
串行	后一步依赖前一步的结果	逻辑清晰，但慢
并行	多个信息互不依赖	快，但需要AI会"同时调"
条件	根据中间结果决定下一步	灵活，最像人类思维

💬 一句话记住：串行是"一步步来"，并行是"一起查"，条件是"看情况办"。 实际Agent里，三种模式常常混着用。

五、实操：三大场景实战

💬 这节是动手环节，三个场景从简单到复杂。前两个是"造工具"，第三个是"完整Agent"。建议都试一遍。

🖥️ 场景1：构建天气查询Agent

结合地理位置API和天气API：

复制代码

你是一个天气助手。你有两个工具可用：

工具1：get_location
- 描述：根据城市名获取经纬度坐标
- 参数：{"city": {"type": "string", "description": "城市名"}}
- 返回：{"lat": 纬度, "lng": 经度}

工具2：get_weather_by_coord
- 描述：根据经纬度获取实时天气
- 参数：{"lat": {"type": "number"}, "lng": {"type": "number"}}
- 返回：{"temperature": 气温, "condition": "天气状况", "humidity": "湿度"}

用户：帮我查一下成都今天的天气，还有湿度。

请按"思考→行动→观察→回答"的流程处理。

试一下，看AI能不能"先查位置、再查天气"两步走。

💡 观察重点： AI会不会"一步到位"直接编造天气？还是老老实实"先调get_location，再调get_weather_by_coord"？如果AI跳过工具直接回答，说明工具描述还不够清楚，或者需要你明确"必须使用工具"。

🖥️ 场景2：设计计算器工具

让AI在数学任务中自主决定何时调用工具：

复制代码

你是一个数学助手。你有一个工具：

工具：calculate
- 描述：执行数学计算。当用户提出需要精确计算的数学问题时使用。
- 参数：{"expression": {"type": "string", "description": "数学表达式，如'25*4+100'"}}
- 返回：{"result": 计算结果}

用户：帮我算一下，如果每月存2000元，年利率3%，存10年，复利后是多少？

请按"思考→行动→观察→回答"的流程处理。

试一下，看AI会不会主动调用计算器，而不是"心算"。

💡 观察重点： 复利计算容易出错，AI"心算"很可能算错。如果AI主动调用calculate工具，说明它理解了"该用工具就用工具"。 如果AI直接"心算"，你可以提示："请使用calculate工具进行精确计算。"

🖥️ 场景3：搜索增强（先搜索后回答）

集成搜索引擎，实现"先搜索后回答"的工作流：

复制代码

你是一个知识助手。你有一个工具：

工具：web_search
- 描述：搜索互联网获取最新信息。当用户询问需要最新数据、时效性信息、或你不确定的问题时使用。
- 参数：{"query": {"type": "string", "description": "搜索关键词"}}
- 返回：{"results": [{"title": 标题, "snippet": 摘要, "url": 链接}]}

用户：2025年国内AI编程工具市场份额排名是怎样的？

请按"思考→行动→观察→回答"的流程处理。回答时请标注信息来源。

试一下，看AI会不会"先搜索再回答"，而不是"凭记忆编"。

💡 观察重点： 这类时效性问题，AI"凭记忆"很容易答错或过时。如果AI主动调用web_search，说明它"知道什么时候该查"。 回答时标注信息来源，是"搜索增强"的关键------让用户能追溯。

💡 三个场景的关键差异

场景	核心技能	观察重点
天气查询	多工具串行调用	会不会"先查位置再查天气"
计算器	自主决定用工具	会不会"用工具而不是心算"
搜索增强	先搜索后回答	会不会"查证而不是凭记忆"

六、错误处理：工具调用失败怎么办？

💬 这节是"救场指南"。工具不是每次都成功------网络超时、参数错误、返回异常。AI怎么"自我修复"？

📌 三种常见失败及应对

失败1：工具返回错误

复制代码

观察：工具返回 {"error": "城市不存在"}
思考：城市名可能拼写错误，尝试用别名或拼音。
行动：调用 get_weather("成都")

失败2：工具超时

复制代码

观察：工具调用超时
思考：重试一次，如果还失败，就告知用户稍后再试。
行动：重试调用

失败3：参数不完整

复制代码

思考：用户没给城市名，我需要询问。
行动：向用户提问："请问您想查询哪个城市的天气？"

📌 给AI的"错误处理"提示词

复制代码

你是一个可靠的助手。当工具调用失败时，请按以下策略处理：
1. 如果是参数问题，尝试修正参数后重试
2. 如果是网络问题，重试一次，仍失败则告知用户
3. 如果信息不足，向用户询问补充信息
4. 永远不要编造工具返回的数据

💬 一句话记住：工具失败不可怕，可怕的是AI"编造"工具结果。 一定要在提示词里明确"永远不要编造工具返回的数据"------这是Agent可靠性的底线。

七、当下趋势：Function Calling 与 MCP

💬 这块是"行业前沿"，信息量大，但不用全记住。重点理解"Function Calling已成标配"和"MCP是什么"。

📌 趋势1：Function Calling成为标准能力

国内主流模型（通义千问Qwen3、DeepSeek、智谱GLM-4.6、文心一言、豆包、Kimi）已全面支持Function Calling。其中GLM-4.6V首次将Function Call原生融入视觉模型，打通"视觉感知→可执行行动"链路。

📌 趋势2：MCP标准化工具接口

MCP（Model Context Protocol，模型上下文协议），是让"工具与模型的交互接口"标准化的协议。以前每个工具要单独对接，有了MCP，一次对接、到处复用。腾讯CodeBuddy已率先支持MCP协议。

📌 趋势3：Agent开发框架

类型	代表	特点
国际框架	LangChain/LangGraph、CrewAI、Microsoft Agent Framework	功能强大，生态成熟
国内平台	扣子Coze（字节）、Dify（开源）	零代码/低代码，上手快

💬 一句话记住趋势：Function Calling是"标配"，MCP是"标准"，扣子Coze和Dify是"国内上手最快的平台"。 想动手做Agent，先从扣子Coze或Dify开始，别一上来就啃LangChain。

本课小结

📌 今天学了啥

知识点	一句话回顾
ReAct原理	思考→行动→观察→循环，让AI"边想边干"
工具三要素	名称 + 描述 + 参数Schema
Function Calling	AI输出结构化调用请求，程序执行并返回结果
工具链编排	串行、并行、条件三种模式
错误处理	修正重试、询问补充、绝不编造工具数据
当下趋势	Function Calling成标配，MCP标准化，Coze/Dify上手快

📌 三个核心认知

ReAct让AI从"会说话"升级到"会干活"------这是Agent的基石
工具描述决定AI会不会用------描述写得越清楚，AI越不会用错
"绝不编造工具数据"是可靠性底线------Agent可以出错，但不能撒谎

课后练习

💬 练习都动手做一遍，尤其第一个------它是理解ReAct循环的关键。

📌 练习1：ReAct循环拆解

用本课"天气查询"的例子，把AI的完整"思考→行动→观察→回答"过程记录下来，画出循环图。

观察重点： AI是不是真的"一步步来"？有没有跳过思考直接回答？

📌 练习2：设计一个工具

选一个你日常会用到的功能（查汇率、算BMI、翻译、查快递都行），设计它的三要素（名称、描述、参数Schema）。

要求： 描述要写得让AI"一看就知道什么时候该用"。

📌 练习3：工具链编排

设计一个"旅游规划Agent"的工具链，至少包含3个工具（查航班、查酒店、查景点），并说明它们之间是串行、并行还是条件调用。

观察重点： 你的编排逻辑是否合理？有没有"后一步依赖前一步"的情况？

下节预告

🖥️ 第16课：自主Agent设计原理

第15课咱学会了"让AI调用工具"。第16课来看一个更宏大的话题------自主Agent设计。

单个工具调用是"点技能"，自主Agent是"组队打副本"------它要自己规划任务、管理记忆、调用工具、甚至自我反思纠错。这节课咱会讲Agent的三要素（规划、记忆、工具）、反思机制、多Agent协作，还会带你在扣子Coze上零代码搭一个智能客服Agent。

这是从"提示词工程师"迈向"AI应用开发者"的关键一课。跟着咱，一步步来。

🎯 高级应用阶段第1课完成，还剩8课。硬核内容正式开始，稳住节奏。