ReAct框架实战：如何让大语言模型学会使用搜索和计算工具？-CSDN博客

ReAct框架深度实战：构建能思考、会行动的智能体系统

最近和几个做AI应用的朋友聊天，大家不约而同地提到了同一个痛点：大语言模型虽然知识渊博，但总感觉像个“书呆子”——知道很多，却不会动手做事。问它“今天北京天气怎么样”，它能给你讲一遍气象学原理，却不会直接调用天气API查一下实时数据；让它“计算一下公司上季度的营收增长率”，它能写出完美的公式，却不会真的去数据库里拉出数字来算一算。

这种“知行分离”的困境，正是智能体（Agent）技术要解决的核心问题。而ReAct框架，就是让大模型从“知道分子”变成“行动派”的关键桥梁。今天我想结合自己最近在几个项目中落地ReAct的实践经验，和大家深入聊聊这个框架的实战应用——不只是理论，更是那些在代码里踩过的坑、调出来的最佳实践。

1. 重新理解ReAct：不只是“推理+行动”的缩写

很多人第一次接触ReAct时，会把它简单理解为“Reasoning + Acting”的组合——先推理，再行动。这种理解没错，但太浅了。在我实际构建智能体系统的过程中，发现ReAct真正的价值在于它建立了一个可解释、可控制、可迭代的决策循环。

1.1 从单次问答到持续交互的范式转变

传统的大模型交互是什么样的？用户提问，模型回答，对话结束。这种“一问一答”的模式在处理复杂任务时显得力不从心。比如这样一个问题：

“帮我查一下OpenAI最新发布的模型参数规模，然后计算如果我用A100显卡训练，大概需要多少张卡？”

如果直接问ChatGPT，它可能会：

告诉你它不知道最新数据（知识截止问题）
即使知道数据，计算部分也可能出错
整个过程像个黑箱，你不知道它怎么想的

而ReAct框架下的智能体会这样处理：

Thought: 用户需要两个信息：1) OpenAI最新模型的参数规模 2) A100显卡的训练需求计算。我需要先搜索最新信息。
Action: search: OpenAI最新模型参数规模 2024
Observation: OpenAI在2024年发布了o1系列模型，其中o1-preview据传参数量约1.8万亿...
Thought: 找到了参数规模，现在需要计算A100的需求。A100的显存是80GB，训练时通常...
Action: calculate: 1800000000000 * 4 / (80 * 1024 * 1024 * 1024 * 0.7)  # 参数*4字节 / (单卡显存*利用率)
Observation: 计算结果约为125.3
Thought: 这意味着大约需要126张A100显卡。现在可以给出完整答案了。
Answer: OpenAI最新发布的o1-preview模型参数量约为1.8万亿。按照每个参数4字节计算，需要约7.2TB显存。考虑到A100 80GB显卡的实际利用率约70%，大约需要126张卡。

看到区别了吗？ReAct让模型的思考过程透明化了。每一步的“Thought”都像程序员的调试日志，让你知道模型在想什么、为什么这么想。这种可解释性在商业应用中至关重要——当智能体给出一个建议时，你能追溯它的推理链条，判断是否可靠。

1.2 ReAct循环的四个关键阶段

让我们拆解一下这个循环的每个环节：

Thought（思考）

作用：分析当前状态，规划下一步行动
输出内容：自然语言描述的推理过程
关键点：这里不是简单的“我该做什么”，而是“我为什么这么想”

Action（行动）

作用：从可用工具中选择并执行
格式：工具名: 参数
示例：search: 特斯拉2024年第一季度财报
注意：行动必须是具体、可执行的指令

Observation（观察）

作用：接收行动结果，作为下一步思考的输入
来源：工具调用的返回结果
特点：通常是结构化或半结构化数据

Answer（回答）

作用：当任务完成时输出最终结果
触发条件：模型判断已获得足够信息
格式：自然语言总结

提示：在实际实现中，很多开发者会忽略“Observation”阶段的格式化处理。工具返回的原始数据（比如JSON）需要适当转换为自然语言描述，否则模型可能无法正确解析。

2. 工具生态构建：让智能体真正“有手可用”

ReAct框架的核心假设是：大模型负责思考，工具负责执行。但“工欲善其事，必先利其器”——工具的设计质量直接决定了智能体的能力上限。

2.1 工具设计的五大原则

从我踩过的坑里总结出这些经验：

1. 原子性原则 每个工具应该只做一件事，并且做好。不要设计“万能工具”，比如一个data_processor工具既能查询数据库又能计算统计量。应该拆分成：

query_database(sql)
calculate_statistics(data, method)

2. 接口一致性原则 所有工具应该有统一的调用和返回格式。我推荐这样的结构：

def tool_function(input_str: str) -> str:
    """
    工具描述：清晰说明工具的功能、输入格式、输出格式
    
    参数：
    input_str: 输入字符串，格式为...
    
    返回：
    str: 工具执行结果，格式为...
    
    示例：
    >>> tool_function("参数示例")
    "返回结果示例"
    """
    # 工具实现
    pass

3. 错误处理原则 工具必须优雅地处理异常，并返回机器可读的错误信息：

def search_web(query: str) -> str:
    try:
        # 执行搜索
        result = perform_search(query)
        if not result:
            return "ERROR: No results found for query"
        return result
    except TimeoutError:
        return "ERROR: Search timeout"
    except Exception as e:
        return f"ERROR: {str(e)}"

4. 上下文感知原则 工具应该能访问必要的上下文信息。比如时间相关的工具：

def get_current_time(timezone: str = "UTC") -> str:
    """获取指定时区的当前时间"""
    from datetime import datetime
    import pytz
    
    try:
        tz = pytz.timezone(timezone)
        current_time = datetime.now(tz)
        return f"Current time in {timezone}: {current_time.strftime('%Y-%m-%d %H:%M:%S')}"
    except pytz.exceptions.UnknownTimeZoneError:
        return f"ERROR: Unknown timezone {timezone}"

5. 安全性原则 特别是执行类工具（如文件操作、系统命令），必须有严格的权限控制和输入验证：

def execute_calculation(expression: str) -> str:
    """安全计算数学表达式"""
    # 输入验证：只允许数学表达式
    import re
    if not re.match(r'^[0-9+\-*/().\s]+$', expression):
        return "ERROR: Invalid expression - only numbers and basic operators allowed"
    
    # 禁止危险操作
    banned_keywords = ['import', 'exec', 'eval', '__']
    for keyword in banned_keywords:
        if keyword in expression:
            return f"ERROR: Expression contains banned keyword '{keyword}'"
    
    try:
        # 使用安全的方式计算
        result = eval(expression, {"__builtins__": {}}, {})
        return str(result)
    except Exception as e:
        return f"ERROR: Calculation failed: {str(e)}"

2.2 实战工具库示例

下面是我在一个电商数据分析Agent中实际使用的工具集，供大家参考：

工具类别	工具名称	功能描述	输入示例	输出示例
数据查询	`query_sales`	查询销售数据	"2024-01-01 to 2024-03-31, product_id=123"	"销售额: $150,000, 订单数: 1,200"
计算分析	`calculate_growth`	计算增长率	"current=150000, previous=120000"	"增长率: 25.0%"
外部API	`get_weather`	获取天气信息	"北京"	"北京今天晴, 15-25°C, 湿度45%"
文件操作	`read_file`	读取文件内容	"/reports/q1_summary.md"	"文件内容..."
系统状态	`check_service`	检查服务状态	"payment_service"	"payment_service: UP (响应时间: 45ms)"

这些工具通过统一的注册机制提供给智能体：

class ToolRegistry:
    def __init__(self):
        self.tools = {}
    
    def register(self, name: str, func: callable, description: str):
        """注册工具"""
        self.tools[name] = {
            'function': func,
            'description': description
        }
    
    def get_tool(self, name: str) -> callable:
        """获取工具函数"""
        return self.tools.get(name, {}).get('function')
    
    def list_tools(self) -> str:
        """列出所有可用工具的描述"""
        descriptions = []
        for name, info in self.tools.items():
            descriptions.append(f"{name}: {info['description']}")
        return "\n".join(descriptions)

# 初始化工具注册表
registry = ToolRegistry()
registry.register("search", search_web, "搜索网络信息，输入为搜索关键词")
registry.register("calculate", execute_calculation, "计算数学表达式，如'calculate: 2+3*4'")
registry.register("get_time", get_current_time, "获取当前时间，可选时区参数")

3. Prompt工程：让模型理解“游戏规则”

ReAct的成功很大程度上取决于Prompt的质量。一个好的ReAct Prompt不仅仅是告诉模型“要思考再行动”，而是建立一套完整的交互协议。

3.1 核心Prompt结构解析

这是我经过多次迭代后总结出的Prompt模板：

你是一个ReAct智能体，按照以下规则运行：

## 运行循环
你始终运行在 Thought -> Action -> Observation -> (循环) -> Answer 的循环中。

## 阶段说明
1. Thought（思考）：
   - 分析当前问题和已有信息
   - 规划下一步需要执行的动作
   - 用自然语言清晰描述你的推理过程

2. Action（行动）：
   - 从可用工具中选择一个工具
   - 格式必须为：Action: 工具名: 参数
   - 示例：Action: search: OpenAI最新模型

3. Observation（观察）：
   - 这是工具执行后返回的结果
   - 你需要基于这个结果继续思考

4. Answer（回答）：
   - 当你认为已经获得足够信息时
   - 直接输出最终答案
   - 格式：Answer: 你的回答内容

## 可用工具
{工具列表描述}

## 重要规则
- 每次只能执行一个Action
- 如果工具返回ERROR，尝试其他方法或报告失败
- 保持思考的连贯性，引用之前的Observation
- 当问题解决时，必须输出Answer

## 示例会话
Question: 珠穆朗玛峰的高度是多少米？
Thought: 用户想知道珠穆朗玛峰的具体高度。我没有这个数据，需要搜索。
Action: search: 珠穆朗玛峰高度 米
Observation: 珠穆朗玛峰的高度是8848.86米。
Thought: 我已经获得了准确的高度信息，可以回答问题了。
Answer: 珠穆朗玛峰的高度是8848.86米。

现在开始：
Question: {用户问题}

这个Prompt的几个关键设计点：

1. 明确的阶段划分 每个阶段都有清晰的职责描述，避免模型混淆。特别是“Thought”阶段，强调要“清晰描述推理过程”，这有助于生成可解释的思考链。

2. 严格的格式要求 Action必须遵循Action: 工具名: 参数的格式，这种结构化输出更容易用正则表达式解析。

3. 工具描述的规范化 工具描述应该包括：

工具名称
功能说明
输入格式
输出示例

4. 示例的质量 示例不是随便写的，要覆盖常见场景：

需要搜索的场景
需要计算的场景
需要多步协作的场景

3.2 高级Prompt技巧

动态工具描述 在实际系统中，可用工具可能会变化。我通常这样处理：

def build_react_prompt(tool_descriptions: str) -> str:
    base_prompt = """你是一个ReAct智能体...（基础部分不变）"""
    
    tools_section = f"""
## 可用工具
{tool_descriptions}
"""
    
    # 根据工具特性添加特定提示
    if "search" in tool_descriptions:
        tools_section += "\n- 优先使用search工具获取最新信息"
    if "calculate" in tool_descriptions:
        tools_section += "\n- 计算时确保使用正确的数学表达式"
    
    return base_prompt + to