FuncReAct：基于OpenAI原生函数调用的ReAct范式工程实践

1. 项目概述：当ReAct范式撞上OpenAI的函数调用原生能力

FuncReAct不是某个新发布的开源库，也不是某家大厂刚推出的SaaS服务，它是一个 设计思想的具体落地形态 ——把ReAct（Reasoning + Acting）这个在2022年底由Google Research提出的、用于提升大语言模型推理与工具调用协同能力的经典范式，直接嫁接到OpenAI API v1.0之后全面支持的 原生函数调用（Function Calling）机制 上。我第一次在内部技术分享会上看到这个命名时，心里就咯噔一下：这名字太直白，但恰恰说明它踩中了当前Agent开发中最痛的一个点——我们不再需要自己手写JSON Schema解析、不靠正则去抠工具名和参数、也不用在prompt里反复强调“请严格按格式输出”，而是让模型在底层协议层面就理解“你该调哪个函数、传哪些参数、等什么返回”。核心关键词就是三个： ReAct范式、OpenAI函数调用、Agent行为编排 。它解决的不是“能不能调工具”的问题，而是“调得稳不稳、链路清不清、错误好不好追”的工程化瓶颈。适合正在从单次API调用向多步任务自动化演进的开发者，尤其是那些已经写过几版tool calling逻辑、却被JSON解析失败、参数类型错位、循环调用失控折磨过的同学。这不是一个教你从零搭建LLM应用的入门教程，而是一份给已经在泥地里趟过两轮的实战者准备的“如何让Agent少掉几次坑”的操作手册。

2. 设计思路拆解：为什么必须放弃“Prompt Engineering”式工具调用？

2.1 ReAct范式本身不是银弹，它的落地依赖底层协议支撑

ReAct的核心思想非常朴素：模型在生成答案前，先进行 推理（Thought） ，明确下一步该做什么；然后 行动（Action） ，调用某个工具获取外部信息；接着观察（Observation）工具返回结果；再基于新信息继续推理，形成闭环。这个循环在论文里看着很美，但早期实现几乎全靠“Prompt Engineering”硬扛。比如，你要让模型调用天气API，就得在system prompt里写死：“你是一个天气查询助手。当你需要查询天气时，请严格按以下JSON格式输出：{‘action’: ‘get_weather’, ‘action_input’: {‘city’: ‘北京’}}。不要输出任何其他内容。” 这种方式的问题是致命的：第一，模型输出不可控，哪怕加了temperature=0，它依然可能在JSON外多打一个句号、少一个引号，或者把 "city" 写成 "location" ；第二，错误无法结构化捕获，你得用正则或json.loads()去硬解析，一旦失败，整个链路就断了，连“它想调什么工具”都猜不出来；第三，调试成本极高，每次改工具定义，都要同步更新prompt，还要重新测试所有边界case。我去年带一个团队做客服工单自动分类+转交系统，光是为了解析那几个自定义工具的JSON，就写了三版正则+异常兜底逻辑，上线后每周都有因JSON格式错乱导致的工单漏处理。

2.2 OpenAI函数调用不是“又一个API功能”，它是Agent架构的分水岭

2023年7月OpenAI正式将function calling作为v1 API的标配能力推出，这绝非一次简单的功能叠加。它的本质是 在模型输出层和开发者代码层之间，插入了一个强类型的、可验证的协议层 。当你在请求中传入 functions 数组（包含name、description、parameters schema），OpenAI的模型（gpt-3.5-turbo-1106及之后版本）会直接在token生成阶段就“理解”这些函数是它可选的操作集。它不会输出自由文本，而是生成一个结构化的 tool_calls 数组，每个元素包含 function.name 和 function.arguments （字符串，但保证是合法JSON）。这个 arguments 字符串，你可以用 json.loads() 安全解析，因为模型已承诺它一定合法。更重要的是，这个过程是 可中断、可重入、可审计 的：你收到 tool_calls 后，可以并行执行多个函数，拿到结果再拼成 tool_responses ，原样塞回下一轮请求的 messages 里。整个链路像一条清晰的流水线，而不是一团缠绕的毛线。FuncReAct的设计起点，就是彻底拥抱这个协议——它不试图去“增强”prompt，而是把ReAct的Thought/Action/Observation三步，严格映射到OpenAI API的 assistant message （含tool_calls）、 function execution 、 user message （含tool_responses）这三个标准消息类型上。这种映射不是妥协，而是对工程确定性的主动追求。

2.3 FuncReAct的“轻量级”哲学：不做框架，只做模式

市面上已有LangChain、LlamaIndex等成熟框架，它们提供了完整的Agent抽象、记忆管理、工具注册中心。FuncReAct刻意避开这些，选择了一条更“原始”的路：它就是一个 基于OpenAI原生API调用的、遵循ReAct循环的Python函数模板 。没有 AgentExecutor 类，没有 Tool 基类，没有复杂的回调系统。你只需要定义一个 tools 列表（每个tool是一个dict，含name、description、parameters），写一个 execute_tool 函数来实际调用你的业务逻辑（比如查数据库、调第三方API），然后把 run_react_loop 这个核心函数抄过去，填上你的system prompt和初始user message，就能跑起来。它的价值不在于封装了多少功能，而在于 用最少的代码，暴露最核心的交互契约 。当你发现Agent行为异常时，你不需要去翻LangChain的17层继承链，而是直接看 run_react_loop 里那几十行代码——哪一步 tool_calls 没生成？哪次 execute_tool 抛了异常没被捕获？ tool_responses 的格式是否和模型期望的 parameters schema完全匹配？这种透明性，是复杂框架永远无法提供的。我见过太多团队，在LangChain的 AgentExecutor.run() 里卡住三天，最后发现只是某个tool的 parameters schema里把 type: "integer" 写成了 type: "int" ，而框架的schema校验没开，错误被静默吞掉了。

3. 核心细节解析：ReAct循环的每一步，都在和OpenAI协议打交道

3.1 System Prompt：不是“角色设定”，而是“协议说明书”

在FuncReAct里，system prompt的作用被彻底重构。它不再是“你是一个乐于助人的AI助手”这种泛泛而谈的描述，而是一份 精确到字段级别的协议说明书 。我常用的模板长这样：

你是一个遵循ReAct（Reasoning-Acting）范式的智能助手。请严格按以下规则工作：
1. 每次响应必须且仅包含一个<reasoning>标签，内为你对当前问题的思考过程，解释为何需要下一步行动或可直接作答。
2. 若需调用外部工具，请在<reasoning>后立即输出一个<action>标签，格式为：<action>{"name": "tool_name", "parameters": {"param1": "value1", ...}}</action>。name必须是以下可用工具之一：[tool1, tool2, tool3]。parameters必须是合法JSON，且字段名、类型、必填项必须与工具定义完全一致。
3. 若无需调用工具，可在<reasoning>后直接给出最终答案，不使用<action>标签。
4. 你不会在<reasoning>或<action>外输出任何其他内容，包括解释性文字、问候语、道歉语。

注意几个关键点：第一，用 <reasoning> 和 <action> 这种自定义标签，是为了 强制模型输出结构化片段 ，方便后续用简单字符串分割提取，避免依赖脆弱的JSON解析；第二，明确列出可用工具名 [tool1, tool2, tool3] ，这是对模型的硬约束，防止它“发明”不存在的工具；第三，强调 parameters 必须是“合法JSON”且“字段名、类型、必填项完全一致”，这是在提前堵死最常见的参数错位漏洞。这个prompt不是为了让模型“更聪明”，而是为了把它变成一个 可预测、可验证的状态机 。实测下来，用这个prompt配合gpt-4-turbo， tool_calls 生成失败率从早期的12%降到0.8%，大部分失败都集中在极少数边缘case（比如用户输入全是乱码时）。

3.2 Tool Definition：Schema即契约，一个字符都不能错

OpenAI的 functions 参数，本质是一份JSON Schema。FuncReAct要求你定义的每个tool，其 parameters 字段必须是一个 严格符合JSON Schema Draft 07规范的dict 。这不是可选项，而是协议的基石。比如，你要定义一个查订单状态的tool：

{
    "name": "get_order_status",
    "description": "根据订单ID查询当前物流状态和预计送达时间",
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {
                "type": "string",
                "description": "16位纯数字订单号，例如'2023101512345678'"
            },
            "include_history": {
                "type": "boolean",
                "description": "是否包含完整的物流轨迹历史，默认为false",
                "default": False
            }
        },
        "required": ["order_id"]
    }
}

这里有几个魔鬼细节：第一， "type": "string" 不能写成 "type": "str" ，OpenAI只认标准JSON Schema类型；第二， "default": False 必须是Python的 False （对应JSON的 false ），如果写成字符串 "False" ，模型会忽略默认值；第三， "required" 数组里的字段名，必须和 properties 里的key 完全一致，包括大小写和下划线 。我曾在一个电商项目里，把 "order_id" 在required里写成 "orderId" ，结果模型在 order_id 有值时依然报“missing required parameter”，debug了整整一个下午才定位到这个拼写差异。FuncReAct的实践心得是：把tool definition当成API接口文档来写，每次修改，都用 jsonschema.validate() 在本地跑一遍校验，确保它100%合法。这比在生产环境抓包看 tool_calls 失败日志要高效十倍。

3.3 Execution Loop：三步走，每一步都是状态快照

FuncReAct的核心函数 run_react_loop ，其逻辑极其简单，却蕴含了对Agent状态的精准把控。它不是一个无限while True，而是 一个有明确退出条件、每轮都记录完整上下文的有限状态机 。伪代码如下：

def run_react_loop(messages, tools, max_steps=10):
    for step in range(max_steps):
        # Step 1: 调用OpenAI API，获取assistant的响应（含tool_calls）
        response = client.chat.completions.create(
            model="gpt-4-turbo",
            messages=messages,
            tools=tools,
            tool_choice="auto"  # 让模型自主决定是否调用
        )
        
        # Step 2: 提取并执行tool_calls
        tool_calls = response.choices[0].message.tool_calls
        if not tool_calls:
            # 模型认为无需调用工具，直接返回最终答案
            return response.choices[0].message.content
        
        # Step 3: 对每个tool_call，执行实际业务逻辑，并将结果追加到messages
        for tool_call in tool_calls:
            try:
                result = execute_tool(tool_call.function.name, json.loads(tool_call.function.arguments))
                # 将tool call和result作为一对消息追加
                messages.append({
                    "role": "tool",
                    "tool_call_id": tool_call.id,
                    "name": tool_call.function.name,
                    "content": json.dumps(result)
                })
            except Exception as e:
                # 关键！必须捕获所有异常，并返回结构化错误
                error_msg = f"执行工具{tool_call.function.name}失败：{str(e)}"
                messages.append({
                    "role": "tool",
                    "tool_call_id": tool_call.id,
                    "name": tool_call.function.name,
                    "content": json.dumps({"error": error_msg})
                })
    
    # 超出最大步数，强制返回
    return "任务执行超时，请简化问题重试"

这个循环的精妙之处在于 Step 3的异常处理 。很多初学者会在这里直接 raise e ，导致整个loop崩溃。FuncReAct要求你必须把异常捕获，并以 {"error": "xxx"} 的格式返回给模型。这样做的意义是：模型能看到“这个工具调用失败了”，它可以在下一轮的 <reasoning> 里分析失败原因，比如判断是参数错误（尝试换参数重试）还是服务不可用（切换备用工具或告知用户）。这是一种 面向失败的设计 。我在一个金融风控场景中，就利用这个机制实现了“降级策略”：当主风控API超时时， execute_tool 返回 {"error": "timeout"} ，模型在下一轮自动调用一个轻量级规则引擎作为备选，准确率只下降3%，但可用性从92%提升到99.9%。

4. 实操过程详解：从零开始跑通一个订单查询Agent

4.1 环境准备与依赖安装：极简主义的胜利

FuncReAct对环境的要求低到令人发指。你不需要Docker，不需要Conda环境，甚至不需要额外的Python包（除了OpenAI官方SDK）。我的标准配置就是：

# 创建一个干净的venv
python -m venv funcreact_env
source funcreact_env/bin/activate  # Linux/Mac
# funcreact_env\Scripts\activate  # Windows

# 只装一个包
pip install openai==1.35.0  # 锁定一个稳定版本，避免API变更

为什么不用LangChain？因为LangChain的 ChatOpenAI 封装，会在底层偷偷做很多事：自动重试、自动处理stream、自动注入system message。这些“便利”在FuncReAct里全是干扰项。我们要的是 对每一次HTTP请求、每一个返回字段的完全掌控 。 openai==1.35.0 是经过我线上压测验证的最稳定版本，它对 tool_calls 的解析逻辑最健壮，不会出现某些版本里 tool_call.id 为空字符串的bug。另外，强烈建议设置环境变量 OPENAI_API_KEY ，而不是在代码里硬编码，这是最基本的安全实践。

4.2 定义你的第一个Tool：一个真实的电商订单查询

我们以一个真实的电商场景为例：用户问“我的订单2023101512345678现在到哪了？”。我们需要一个能查订单状态的tool。首先，定义tool schema：

# tools.py
import json
import requests
from typing import Dict, Any

ORDER_TOOL = {
    "name": "get_order_status",
    "description": "根据16位数字订单号查询订单当前物流状态、预计送达时间及最新物流节点",
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {
                "type": "string",
                "description": "16位纯数字订单号，例如'2023101512345678'",
                "pattern": r"^\d{16}$"  # 正则校验，确保是16位数字
            }
        },
        "required": ["order_id"]
    }
}

def execute_get_order_status(order_id: str) -> Dict[str, Any]:
    """
    真实执行订单查询的函数
    注意：这里模拟了生产环境的典型处理逻辑
    """
    # 1. 参数预校验（在调用外部服务前）
    if not isinstance(order_id, str) or len(order_id) != 16 or not order_id.isdigit():
        raise ValueError(f"订单号格式错误：'{order_id}'，必须是16位纯数字")
    
    # 2. 调用内部订单服务API（模拟）
    try:
        # 生产中这里是requests.post(...)
        # 为演示，我们mock一个响应
        mock_response = {
            "order_id": order_id,
            "status": "shipped",
            "estimated_delivery": "2023-10-25T18:00:00Z",
            "latest_tracking": {
                "location": "上海市浦东新区",
                "status": "已发出",
                "timestamp": "2023-10-22T14:30:00Z"
            }
        }
        return mock_response
    except requests.exceptions.Timeout:
        raise TimeoutError("订单服务响应超时，请稍后重试")
    except requests.exceptions.ConnectionError:
        raise ConnectionError("无法连接到订单服务，请检查网络")
    except Exception as e:
        raise RuntimeError(f"查询订单时发生未知错误：{str(e)}")

这个 execute_get_order_status 函数体现了FuncReAct的另一个核心原则： 业务逻辑与协议逻辑分离 。 ORDER_TOOL 只负责告诉OpenAI“我能接受什么参数”，而 execute_get_order_status 则专注处理“怎么查、查错了怎么办”。这种分离让单元测试变得极其简单——你可以单独对 execute_get_order_status 写test case，覆盖各种异常分支，而不用每次都启动一个OpenAI API调用。

4.3 编写核心ReAct Loop：抄作业也要抄明白

现在，把前面定义的tool和execution函数，组装进 run_react_loop 。这是你真正需要“抄”的部分，但请务必理解每一行：

# main.py
import os
import json
from openai import OpenAI
from tools import ORDER_TOOL, execute_get_order_status

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

def execute_tool(tool_name: str, arguments: dict) -> dict:
    """统一的tool dispatcher"""
    if tool_name == "get_order_status":
        return execute_get_order_status(**arguments)
    else:
        raise ValueError(f"未知工具：{tool_name}")

def run_react_loop(user_query: str, max_steps: int = 5) -> str:
    # 初始化消息历史
    messages = [
        {
            "role": "system",
            "content": "你是一个遵循ReAct（Reasoning-Acting）范式的智能助手。请严格按以下规则工作：1. 每次响应必须且仅包含一个<reasoning>标签...（此处省略，用前面3.1节的完整prompt）"
        },
        {
            "role": "user",
            "content": user_query
        }
    ]
    
    tools = [ORDER_TOOL]
    
    for step in range(max_steps):
        print(f"\n--- 第{step+1}步 ---")
        print(f"当前消息历史长度：{len(messages)}")
        
        # 调用API
        response = client.chat.completions.create(
            model="gpt-4-turbo",
            messages=messages,
            tools=tools,
            tool_choice="auto",  # 关键：让模型自主决策
            temperature=0.0,   # ReAct需要确定性，设为0
        )
        
        assistant_message = response.choices[0].message
        print(f"模型返回：{assistant_message.content[:100]}...")
        
        # 检查是否有tool_calls
        if assistant_message.tool_calls:
            print(f"检测到{len(assistant_message.tool_calls)}个tool call")
            for tool_call in assistant_message.tool_calls:
                print(f"  调用工具：{tool_call.function.name}")
                print(f"  参数：{tool_call.function.arguments}")
                
                try:
                    # 执行工具
                    result = execute_tool(
                        tool_call.function.name,
                        json.loads(tool_call.function.arguments)
                    )
                    print(f"  工具执行成功，返回：{json.dumps(result, ensure_ascii=False)[:100]}...")
                    
                    # 将tool call和result作为一对消息追加
                    messages.append({
                        "role": "tool",
                        "tool_call_id": tool_call.id,
                        "name": tool_call.function.name,
                        "content": json.dumps(result, ensure_ascii=False)
                    })
                except Exception as e:
                    error_result = {"error": str(e)}
                    print(f"  工具执行失败：{e}")
                    messages.append({
                        "role": "tool",
                        "tool_call_id": tool_call.id,
                        "name": tool_call.function.name,
                        "content": json.dumps(error_result, ensure_ascii=False)
                    })
        else:
            # 没有tool call，模型直接给出答案
            print("模型认为无需调用工具，返回最终答案")
            return assistant_message.content
    
    return "任务执行超时"

# 测试
if __name__ == "__main__":
    result = run_react_loop("我的订单2023101512345678现在到哪了？")
    print(f"\n最终结果：{result}")

运行这段代码，你会看到控制台清晰地打印出每一步的输入、模型输出、工具调用、执行结果。这种 透明的执行流 ，是调试Agent的黄金标准。如果你看到某一步 tool_calls 为空，但你明明期望它调用，那就立刻检查system prompt里是否漏写了工具名，或者 user_query 是否太模糊。如果看到 execute_tool 报错，那错误堆栈会直接指向你的业务代码，而不是某个框架的黑盒。

4.4 参数调优与性能权衡：温度、步数、模型选择的实战经验

FuncReAct不是设好就完事的，它有三个关键参数需要根据场景精细调整：

还有一个隐藏参数： tool_choice 。 "auto" 是默认，模型自主决定； "none" 强制不调用； {"type": "function", "function": {"name": "xxx"}} 强制调用指定函数。在FuncReAct中，我们始终用 "auto" ，因为ReAct的灵魂就在于“推理后行动”，强制调用违背了范式本意。只有在极少数需要引导模型首次调用的场景（比如新手引导），才会临时用 {"function": {"name": "help"}} 。

5. 常见问题与排查技巧实录：那些让你半夜爬起来的Bug

5.1 “Model didn't return any tool calls” —— 最常见的幻觉

现象 ：你给了清晰的user query，也定义了匹配的tool，但模型response里 tool_calls 为空， content 字段却是一段看似合理的自由文本回答，比如“我帮你查到了，订单已发货”。

根本原因 ：这不是模型“不想调”，而是它 没理解这是个需要调用工具的问题 。ReAct的 <reasoning> 环节失败了。

排查四步法 ：

1. 检查system prompt ：确认你是否在prompt里明确列出了该tool的名字。我遇到过最蠢的一次，是把 "get_order_status" 写成了 "get_order_info" ，差一个词，模型就当它不存在。
2. 检查user query的歧义性 ：用户问“订单2023101512345678怎么样？”，太模糊。改成“请查询订单2023101512345678的当前物流状态和预计送达时间”，加上动词“查询”和明确字段，成功率立升40%。
3. 检查tool description是否足够“诱人” ：description是模型决定调用的关键依据。 "查询订单状态" 太弱，改成 "根据16位数字订单号，实时查询订单的物流轨迹、当前状态（如已发货、派送中、已签收）及精确到小时的预计送达时间" ，模型一眼就懂“这正是我要的”。
4. 临时开启 tool_choice="required" ：在debug时，强制模型必须调用，看它会选哪个tool。如果它选了错误的tool，说明你的tool definition或prompt需要重写。

提示：永远不要相信模型的自由文本回答。FuncReAct的哲学是： 所有事实性信息，必须来自tool call的observation 。如果 tool_calls 为空，那这个回答就是不可信的幻觉，应该直接返回“我需要更多信息才能帮您查询”。

5.2 JSON解析失败： json.loads() 报 Expecting property name enclosed in double quotes

现象 ： tool_call.function.arguments 是一个字符串，但 json.loads() 直接抛异常，错误信息指向第一个字符不是 " 。

真相 ：模型返回的 arguments 字符串， 不是纯JSON，而是JSON嵌在一段自然语言里 。比如它返回： "Here is the JSON: {\"order_id\": \"2023101512345678\"}" 。

解决方案 ：FuncReAct必须内置一个鲁棒的JSON提取器。我用的是一个极简正则：

import re
import json

def extract_json_from_string(s: str) -> dict:
    """从任意字符串中提取第一个合法JSON对象"""
    # 先找最外层的{...}或[...]
    match = re.search(r'(\{.*?\}|\[.*?\])', s, re.DOTALL)
    if not match:
        raise ValueError("未在字符串中找到JSON对象")
    
    json_str = match.group(1)
    try:
        return json.loads(json_str)
    except json.JSONDecodeError:
        # 如果直接解析失败，尝试去掉首尾空白和常见前缀
        cleaned = json_str.strip().strip('```json').strip('```').strip()
        return json.loads(cleaned)

# 在execute_tool前调用
arguments_dict = extract_json_from_string(tool_call.function.arguments)

这个函数能处理99%的“混杂”情况。但最好的办法，还是回到system prompt，用更严厉的措辞约束模型，比如加上：“ <action> 标签内的JSON必须是纯净的，不包含任何解释性文字、代码块标记或额外空格。”

5.3 工具执行成功，但模型在下一轮“装傻”：不理解observation

现象 ： tool_call 执行成功， content 字段里是完美的JSON结果，但下一轮模型的 <reasoning> 里，却说“我没有收到订单信息”，仿佛没看到上一轮的 tool 消息。

根因 ： 消息历史（messages）拼接错误 。这是FuncReAct里最高频的硬伤。OpenAI的API要求， tool 角色的消息，必须和它对应的 assistant 消息里的 tool_call 有 完全一致的 tool_call_id 。如果你在拼接时，把 tool_call.id 写错了，或者用了不同的id，模型就会认为这是个全新的、无关的工具调用，直接忽略。

Debug技巧 ：在每次 messages.append(...) 后，立刻打印 messages[-1] ，确认 "tool_call_id" 的值，和上一轮 assistant_message.tool_calls[0].id 是否 逐字符相等 。我曾经因为Python的 copy.deepcopy() 在处理 tool_call 对象时，意外创建了新的id对象，导致所有 tool_call_id 都不匹配，花了两天才揪出来。

注意： tool 消息的 role 必须是 "tool" ， name 必须和 tool_call.function.name 一致， content 必须是字符串（即使是JSON，也要 json.dumps() 成字符串）。任何一项不匹配，协议就失效。

5.4 循环失控：模型在两个工具间反复横跳

现象 ：用户问“比较iPhone 15和Samsung S24的价格”，模型先调 get_product_price("iPhone 15") ，拿到结果后，不总结，反而又调 get_product_price("Samsung S24") ，拿到后又调 get_product_price("iPhone 15") ，无限循环。

破局点 ：ReAct的 <reasoning> 必须包含 状态记忆 。你的system prompt里，要明确要求模型在 <reasoning> 中总结已获得的信息。比如：“在 <reasoning> 中，请先复述你已通过工具获得的信息，再说明下一步计划。”

进阶方案 ：在 run_react_loop 里加入 状态缓存 。维护一个 tool_results_cache = {} ，key是 (tool_name, frozenset(arguments.items())) 。每次执行前先查缓存，如果存在，直接复用，避免重复调用。这不仅能防循环，还能显著降本。

6. 进阶扩展：FuncReAct不是终点，而是Agent工程化的起点

6.1 加入记忆：让Agent记住“我们刚才聊了什么”

FuncReAct默认是无状态的，每次调用都是全新开始。但在真实对话中，用户会说“那这个订单的支付方式是什么？”，这里的“这个订单”指的就是上一轮查到的订单。要支持这种指代，你需要在 run_react_loop 里加入 上下文摘要 。

我的做法是：在每次 tool call 执行成功后，不直接把原始 content 追加到 messages ，而是先用一个轻量模型（比如 gpt-3.5-turbo ）做一个摘要：

def summarize_observation(tool_name: str, observation: str) -> str:
    """用小模型对大模型的observation做摘要，提炼关键事实"""
    summary_prompt = f"""你是一个信息提炼助手。请从以下{tool_name}工具的返回结果中，提取出最核心的1-3个事实，用简洁的中文短句列出，不要任何解释。
    返回结果：{observation}
    提炼："""
    
    summary_resp = client.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[{"role": "user", "content": summary_prompt}],
        temperature=0.0
    )
    return summary_resp.choices[0].message.content

# 在messages.append前调用
summary = summarize_observation(tool_call.function.name, json.dumps(result))
messages.append({
    "role": "tool",
    "tool_call_id": tool_call.id,
    "name": tool_call.function.name,
    "content": summary  # 追加的是摘要，不是原始JSON
})

这样，模型看到的就不是一长串JSON，而是“订单2023101512345678状态：已发货；预计送达：10月25日；最新位置：上海浦东”。指代关系自然就清晰了。

6.2 多工具并行：把串行变并行，速度提升200%

ReAct默认是串行的：调A工具->等结果->调B工具。但很多场景下，A和B是独立的，完全可以并行。FuncReAct的 tool_calls 数组天然支持并行。你只需要修改 run_react_loop 里的执行逻辑：

from concurrent.futures import ThreadPoolExecutor, as_completed

# 替换原来的for tool_call in tool_calls循环
with ThreadPoolExecutor(max_workers=3) as executor:
    # 提交所有tool call
    future_to_call = {
        executor.submit(execute_tool, tc.function.name, json.loads(tc.function.arguments)): tc 
        for tc in tool_calls
    }
    
    # 收集结果
    for future in as_completed(future_to_call):
        tool_call = future_to_call[future]
        try:
            result = future.result()
            # ... 追加messages
        except Exception as e:
            # ... 处理异常

实测在一个需要同时查订单、查用户积分、查优惠券的场景中，并行让平均响应时间从3.2秒降到1.1秒。当然，要注意并发数别设太高，避免压垮你的后端服务。

6.3 自动化测试：为你的Agent写单元测试

FuncReAct的极简架构，让它天生适合单元测试。你可以用 unittest.mock 完全mock掉OpenAI API调用，只测试你的 execute_tool 和 run_react_loop 逻辑：

# test_funcreact.py
import unittest
from unittest.mock import patch, MagicMock
from main import run_react_loop
from tools import execute_get_order_status

class TestFuncReAct(unittest.TestCase):
    
    @patch('main.client.chat.completions.create')
    def test_order_query_success(self, mock_create):
        # Mock模型返回一个tool call
        mock_response = MagicMock()
        mock_response.choices[0].message.tool_calls = [
            MagicMock(
                function=MagicMock(name="get_order_status", arguments='{"order_id": "2023101512345678"}'),
                id="call_abc123"
            )
        ]
        mock_create.return_value = mock_response
        
        # Mock工具执行返回成功结果
        with patch('tools.execute_get_order_status') as mock_execute:
            mock_execute.return_value = {
                "order_id": "2023101512345678",
                "status": "shipped"
            }
            
            result = run_react_loop("查订单2023101512345678", max_steps=2)
            self.assertIn("shipped", result)
    
    @patch('main.client.chat.completions.create')
    def test_order_query_failure(self, mock_create):
        # Mock模型返回tool call，但工具执行抛异常
        mock_response = MagicMock()
        mock_response.choices[0].message.tool_calls = [
            MagicMock(
                function=MagicMock(name="get_order_status", arguments='{"order_id": "invalid"}'),
                id="call_def456"
            )
        ]
        mock_create.return_value =