ReAct 还是 CodeAct，这是问题所在

大家好，不知道大家怎么看，但在我看来，AI 工程领域最大的争论之一就是这个话题：**ReAct vs. CodeAct**。这是两种截然不同的编排方式（实际上两者都是函数调用，但方法不同）。 **ReAct：** 使用 JSON 来执行操作（每个动作对应一个 ReAct 循环）。这种方法确实有效，也是目前的主流，**但是**存在三个主要问题： * **在多工具和大型多步骤任务中速度慢：** 任务越复杂，迭代次数越多。 * **数据管理和分析非常困难：** 例如，如果 API 或 MCP 返回**非常大**的结果，可能会导致整个上下文窗口爆炸，而且没有简单的方法来筛选哪些数据可以通过。 * **无法处理复杂流程（IF、FOR、WHILE）：** 虽然可以处理，但每个动作都需要一个 JSON 和另一次迭代，导致上下文成本呈指数级增长（$$$）。当然，并非一无是处，ReAct 在原生处理聊天方面表现良好，且对环境相当适应。 **CodeAct：** 编排器 LLM 返回代码，然后在沙箱中执行以调用工具。目前这种方法在某些特定领域（如 ETL 任务、数据密集型任务或定义明确的工作流）中已成为主流。在这些场景下，CodeAct 在许多方面（如 Token 消耗或延迟）都彻底击败了 ReAct，因为它可以通过生成单个脚本一次性完成整个任务（即使是大型多工具任务）。它不需要为每次函数调用生成单独的 JSON。 目前有一些框架如 **smolAgents**（由于它没有充分利用这一优势，而是像 ReAct 中的 JSON 一样为每个函数调用生成非常小的代码片段），因此它结合了两种方法的缺点。 我对此进行了深入思考，开始为自己开发一个框架，并将其发布为开源项目（如果有人感兴趣，我会在评论中留下链接）。 **CodeAct 的优势：** * 可以在一次 LLM 调用中一次性完成复杂任务（效率极高）。 * 拥有 Python 的全部功能，可以使用 Pandas、NumPy 或其他实用库，使其非常有用且灵活。 * 可以使用 Python 本身轻松管理流程和错误。 当然，CodeAct 也有一些挑战：你需要一个良好的沙箱环境，否则就无法正常运行，此外还需要一个完善的追踪系统。 大家对这场讨论怎么看？老实说，这可能是史上最极客的一篇文章了。