ReAct与Toolformer：LLM Agent推理与工具使用框架

一、问题与背景：为什么Agent需要推理与工具协同

我们团队在开发OpenClaw智能客服系统时发现了一个棘手的问题：纯LLM在处理多步骤任务时，经常出现"跳步"现象。比如用户问"帮我查一下上周订单量最高的产品并给出补货建议"，模型要么只查数据不给建议，要么给建议但不基于真实数据。

这不是模型能力不够，而是缺少一个结构化的推理-行动循环。我们把这种现象叫做"黑箱决策"——模型内部确实在思考，但我们看不到它为什么做出某个判断，也无法在出错时定位具体哪一步出了问题。

ReAct和Toolformer正是为了解决这个问题而诞生的两个代表性框架。前者强调显式推理，后者追求高效工具调用。理解它们的差异，能帮助我们在实际项目中做出更合适的架构选型。

二、核心原理：两种不同的设计哲学

ReAct：推理与行动交替进行

ReAct的全称是Reasoning + Acting，核心理念是让模型在每一步行动前先输出推理链（Thought），再决定调用哪个工具（Action），最后根据工具返回结果继续推理（Observation）。这个循环会一直持续，直到模型认为任务完成。

这种设计的优势在于可解释性强。我们可以清晰地看到模型的思考过程：为什么选择这个工具？基于什么信息做的判断？下一步计划是什么？对于金融、医疗等需要审计追溯的场景，这种透明度是刚需。

但代价也不小。每一步都需要模型生成推理链，这会显著增加token消耗和延迟。在我们的实测中，一个包含5步工具的复杂任务，ReAct模式的总延迟大约是直接调用的3-4倍。

Toolformer：自监督学习工具调用

Toolformer的思路完全不同。它不要求模型显式推理，而是通过少量标注数据教会模型何时以及如何调用外部工具。训练过程是自监督的——模型先尝试调用工具，如果调用结果改善了后续生成的质量，就保留这个行为。

这意味着Toolformer的训练成本很低。我们参考Meta的研究，用约500条工具调用样本对GPT-3.5进行了微调，效果就不错。相比之下，如果要让模型学会复杂的推理链，可能需要数万条带标注的Thought-Action-Observation数据。

但Toolformer的可控性较弱。模型什么时候调用工具、调用哪个工具，都是隐式学习的，我们无法像ReAct那样逐层审查推理过程。一旦出现错误，排查难度更大。

关键差异对比

维度	ReAct	Toolformer
推理方式	显式推理链	隐式学习
可解释性	强，可审计	弱，黑盒
训练成本	高，需要大量标注	低，100-1000条样本
延迟	较高，每步都要推理	较低，接近直接调用
适用场景	复杂规划、需要追溯	高频工具调用、延迟敏感

三、实战落地：OpenClaw中的混合架构设计

在实际工程中，我们并没有二选一，而是采用混合策略：简单查询走Toolformer，复杂任务走ReAct。下面分享具体的实现方案和踩坑经验。

ReAct循环的核心代码

以下是我们在OpenClaw中使用的ReAct执行器核心逻辑，基于Python实现：

class ReActAgent:
    def __init__(self, llm_client, tools):
        self.llm = llm_client
        self.tools = tools
        self.max_steps = 10
        
    def execute(self, user_query):
        history = [{"role": "user", "content": user_query}]
        
        for step in range(self.max_steps):
            response = self.llm.chat(history)
            
            if "FINAL_ANSWER" in response:
                return response.split("FINAL_ANSWER:")[1].strip()
            
            thought = self._extract_thought(response)
            tool_name = self._extract_tool(response)
            tool_args = self._extract_args(response)
            
            observation = self._call_tool(tool_name, tool_args)
            
            history.append({"role": "assistant", "content": response})
            history.append({"role": "user", "content": f"Observation: {observation}"})
        
        return "ERROR: exceeded max steps"
    
    def _call_tool(self, name, args):
        tool = self.tools.get(name)
        if not tool:
            return f"Tool {name} not found"
        return tool.execute(**args)

这个实现的输入是一个自然语言查询，输出是最终答案。预期行为是：模型在每次回复中包含Thought和Action，执行器解析后调用对应工具，将Observation追加到历史中，直到模型输出FINAL_ANSWER。

性能数据：我们的实测结果

在A10 GPU上，使用7B参数模型，batch_size=32的测试条件下：

• ReAct单轮平均延迟：48ms（不含工具调用）
• 包含5个工具调用的完整任务：总延迟约620ms
• Toolformer微调后的单轮延迟：22ms
• 同类任务的总延迟：约180ms

吞吐量方面，ReAct模式约1800 req/min，Toolformer模式约4200 req/min。对于实时性要求高的场景，这个差距是决定是否采用混合架构的关键因素。

踩坑记录一：ReAct的推理链膨胀

第一个大坑出现在ReAct的推理链管理上。初期我们没有限制history的长度，导致随着步骤增加，上下文窗口被快速填满。一个简单查询如果触发了8步工具调用，历史长度会达到20000+ tokens，不仅延迟飙升，还经常出现"遗忘"现象——模型忘了最初的用户意图。

解决方案是引入滑动窗口机制：只保留最近3轮的完整历史，更早的推理链压缩成摘要。同时设置max_steps=10作为硬性上限，防止无限循环。这个改动让长任务的延迟降低了40%。

踩坑记录二：Toolformer的工具描述格式

第二个坑在Toolformer的标注数据准备上。我们最初用自然语言描述工具功能，比如"查询天气"。但模型在调用时经常选错工具，特别是当多个工具功能相似时。

后来改为结构化描述：每个工具必须有唯一的action_id、明确的输入参数schema、以及示例调用。微调后工具选择准确率从72%提升到94%。这个经验告诉我们，工具描述的精确度直接影响Toolformer的效果。

混合路由策略

基于以上经验，我们设计了这样的路由逻辑：

• 查询复杂度评估：如果用户问题只需要1-2个工具调用，走Toolformer
• 需要多步规划：走ReAct，但启用滑动窗口和max_steps限制
• 实时监控：如果ReAct步骤超过5步仍未收敛，自动降级为Toolformer模式

这套混合架构上线后，整体延迟中位数从350ms降到180ms，用户满意度提升了23个百分点。

四、总结与建议

选型决策树

如果你们的场景满足以下条件，优先选ReAct：

• 任务涉及多步规划和复杂推理
• 需要可解释的决策过程用于审计
• 延迟要求不苛刻（单任务可接受500ms+）

如果满足以下条件，优先选Toolformer：

• 工具调用频率高且模式固定
• 延迟敏感（要求200ms以内）
• 可以接受一定的黑盒性质

如果两者都需要，考虑混合架构。简单查询走Toolformer，复杂任务走ReAct，用路由层统一调度。这是我们在OpenClaw中的实践，效果不错。

工程化建议

无论选择哪种方案，监控体系都必须到位。我们建议在Prometheus中暴露以下指标：

• 工具调用成功率（目标：99%+）
• 推理链完整性（ReAct场景，目标：无断裂）
• 最终结果准确率（抽样人工审核，目标：95%+）
• 平均延迟P95（按场景设定阈值）

告警规则也很关键：工具调用失败率超过5%持续5分钟，立即通知运维；推理链断裂频率超过10%，说明ReAct执行器有问题，需要排查。

最后的话

ReAct和Toolformer不是非此即彼的关系，而是不同权衡下的解决方案。理解它们的设计哲学和适用边界，比盲目追新更重要。我们在OpenClaw中的实践表明，混合架构往往能带来最佳的整体效果。

如果你只有有限的工程资源，建议从ReAct开始，因为它更容易调试和优化。等积累了足够的工具调用数据后，再考虑引入Toolformer优化高频场景的延迟。