ReAct与CodeAct深度对比：Agent工具调用的两种核心方法

引言：为什么Agent需要工具调用

大语言模型虽然具备强大的推理能力，但如果没有外部工具的支持，它无法完成上网搜索、操作本地文件等实际任务。因此，如何让大模型"知道要调用什么工具"并"成功调用工具"，成为构建Agent的核心问题。

本文将深入解析两种主流的Agent工具调用架构——ReAct和CodeAct，从论文原理到代码实战，帮助你理解它们的设计思想、优劣对比以及实际应用场景。

ReAct：推理与行动的交替循环

核心思想：Reasoning + Acting

ReAct发表于2022年10月，名称来源于Reasoning（推理）和Acting（行动）的组合。它的核心洞察在于，单独的推理或单独的行动都存在明显短板：

• 纯推理模型（如Chain of Thought）：能思考但无法访问外部工具，可能因训练数据缺失而得出错误结论
• 纯行动模型（如早期WebGPT）：能调用工具但缺乏推理能力，无法将搜索结果串联起来
• ReAct的解法：将两者结合，模型先推理（Thought）→ 再执行动作（Action）→ 获取观察结果（Observation）→ 循环往复

这里提到的**Chain of Thought（CoT）**是Google在2022年1月提出的一种提示技术，通过在提示中加入"Let's think step by step"等引导语，让模型将复杂问题分解为中间推理步骤逐步求解。CoT显著提升了模型在数学推理、逻辑判断等任务上的表现，但其本质局限在于所有推理都发生在模型内部——它只能利用训练时见过的知识，无法获取实时信息或执行外部操作。ReAct正是在CoT的基础上，补上了"与外部世界交互"这一关键环节。

ReAct的工作流程

ReAct的每一轮调用包含三个部分：

1. Thought：模型的思考过程，决定需要什么工具
2. Action：实际调用的外部工具
3. Observation：工具返回的结果，作为下一轮的上下文输入

论文中的经典案例是查询"Apple Remote还能控制什么设备"。模型先搜索Apple Remote，发现它是为Front Row软件设计的，再搜索Front Row，最终找到答案是"keyboard function keys"。整个过程体现了推理与工具调用的交替进行。

关键技术细节：从Prompt工程到Function Calling

你可能没注意到，ReAct本质上是一种提示词工程技巧，不需要对模型进行微调。在2022年提出时，OpenAI的Function Calling尚未发布（Function Calling是2023年6月才推出的），因此原始实现完全依赖于：

• 通过Prompt约束模型输出格式
• 对输出字符串进行解析，分离Thought和Action
• 根据解析结果执行对应工具

这种方式的缺点是对模型的指令遵循能力要求较高，输出格式不稳定时解析成功率会降低。

现代ReAct实现：结合Function Calling

Function Calling是OpenAI在2023年6月随GPT-3.5/GPT-4 API一同推出的能力，它允许开发者在API请求中以JSON Schema的形式定义可用工具（函数名称、参数类型、描述等），模型在生成回复时会判断是否需要调用工具，如果需要则输出结构化的JSON参数而非自然语言文本。这从根本上解决了早期ReAct依赖字符串解析的不稳定性问题——模型的输出格式由API层面保证，开发者无需再用正则表达式去"猜测"模型想调用什么工具。目前几乎所有主流大模型API（Claude、Gemini、通义千问等）都已支持类似的工具调用机制。

在实战代码中，可以将ReAct与现代Function Calling结合：保留模型输出Thought的能力，但将Action部分交给Function Calling的结构化JSON输出来完成。核心实现逻辑如下：

1. 封装OpenAI API，传入工具定义（包含name、description、parameter）
2. 在Agent的主循环中调用大模型
3. 判断finish_reason：如果是stop则结束；如果是tool_calls则执行工具
4. 将工具执行结果作为Observation添加到上下文，进入下一轮循环

实测中，让模型计算复杂算式(48÷6) + (15-9)×5 + 12，Gemini 2.0会逐步调用加减乘除工具，最终得出正确答案65。但问题也很明显——调用次数过多，因为每一步都依赖上一步的结果。

CodeAct：用代码替代工具调用

设计动机：解决ReAct的三大痛点

CodeAct由苹果机器学习研究团队提出，其核心思想是：既然大模型擅长写代码，为什么不直接让它输出代码并在沙箱中执行？

CodeAct针对性地解决了ReAct的三个痛点：

• 工具集受限：ReAct要求所有工具必须提前定义，即使是简单的数学计算也需要封装成工具。而编程语言本身就自带丰富的标准库
• 组合灵活性差：ReAct无法在一次调用中嵌套多个工具，必须逐步执行。代码可以自由嵌套函数调用
• 表达能力有限：代码可以写循环、条件判断等复杂逻辑，远超固定的函数调用模式

CodeAct与Manus的关系

CodeAct论文的推动者是Manus（全球知名AI Agent产品）的联合创始人。在MCP协议出现之前，Manus采用的正是CodeAct方法来调用工具，这也说明了CodeAct在工业界的实际价值。

CodeAct的工作原理

CodeAct的架构将ReAct中的"工具调用"替换为"沙箱代码执行"：

1. System Prompt要求模型输出JavaScript/Python代码块
2. 模型通过console.log（或Python的print）输出结果
3. 代码在沙箱环境中执行，输出作为Observation返回
4. 如果代码报错，错误信息也会作为上下文传回，模型会自行修复

沙箱环境的实现要点

代码执行的安全性是CodeAct在生产环境中面临的核心挑战。所谓沙箱（Sandbox），是指一个与宿主系统隔离的受限执行环境，防止恶意或错误代码对系统造成损害。在实际部署中，常见的沙箱方案包括：Docker容器隔离（如E2B、Modal等云服务）、WebAssembly运行时（如Wasmer）、以及受限的解释器环境（如Python的RestrictedPython）。生产级Agent通常会设置执行超时、内存限制、网络访问白名单、文件系统隔离等多层防护，确保模型生成的代码即使存在漏洞也不会影响主系统安全。

代码实现中，沙箱环境的核心设计包括：

1. 将工具函数注入全局作用域，使模型生成的代码可以直接调用
2. 重写console.log以捕获所有输出作为返回值
3. 使用eval执行代码（演示用，生产环境需要安全沙箱）
4. 执行完毕后恢复原始console.log

ReAct与CodeAct实战效果对比

同样计算(48÷6) + (15-9)×5 + 12，两种方法的差异非常直观：

• ReAct方式：需要多次工具调用（先除法、再减法、再乘法、再加法...），逐步推进
• CodeAct方式：模型一次性输出嵌套的代码sum(divide(48,6), multiply(subtract(15,9),5), 12)，一次执行即得结果

论文中还展示了更复杂的场景：查找多个国家的商品价格并比较。ReAct需要逐个国家查询、逐个计算汇率；CodeAct则直接写一个for循环遍历所有国家，一次Action完成全部工作。实验数据显示CodeAct的成功率显著高于JSON-based Action（即ReAct模式）。

两种方法的选型建议

维度	ReAct	CodeAct
工具定义	需要预定义所有工具	可直接使用语言标准库
调用次数	多次循环调用	可一次完成复杂逻辑
输出稳定性	Function Calling保证JSON格式	需要解析Markdown代码块
错误处理	工具层面处理	代码报错可自动修复
模型要求	较低	需要较强的代码生成能力
安全性	工具调用可控	需要安全沙箱环境

简单来说，如果你的场景工具数量有限、对安全性要求高，ReAct + Function Calling是更稳妥的选择；如果任务涉及复杂的数据处理、多步骤组合逻辑，CodeAct的效率优势会非常明显。

从工具调用到完整Agent架构

将ReAct或CodeAct作为基础，加上记忆（Memory）、RAG、长上下文等能力，就能构建出类似AutoGPT的强大Agent架构。而MCP（Model Context Protocol）协议则为Agent提供了统一的工具生态。MCP是Anthropic在2024年底推出的开放协议，旨在标准化大模型与外部工具/数据源的连接方式——类似于USB-C为硬件设备提供统一接口，MCP为AI Agent提供了统一的工具发现、调用和认证机制。通过MCP，开发者可以将任何服务（数据库查询、API调用、文件操作等）封装为标准化的MCP Server，任何支持MCP的Agent都能即插即用地调用这些工具，无需为每个工具单独编写适配代码。无论是ReAct还是CodeAct中的工具实现，都可以接入MCP来获取更丰富的外部能力。

各种Agent工具调用方法和架构仍在快速演进，ReAct和CodeAct作为两种基础范式，理解它们的原理和取舍，是深入Agent开发的必经之路。