ReAct vs Tool Calling：为什么你的 LLM 应该做决定——但绝不执行

Source: Dev.to

引言

在学习 LangChain 或构建 AI 代理时，常会遇到这样的问题：

如果 LLM 能决定使用哪个工具，为什么我们仍然要在代码中自行执行该工具？

乍看之下这似乎是多余的，但弄清 决定 与 执行 的区别对生产级代理系统至关重要。

ReAct 模式

ReAct（Reason + Act）模式让 LLM 生成纯文本推理，例如：

Thought: I need the length of the word "LangChain"

ReAct 中开发者的职责

1. 解析文本输出。
2. 判断建议的操作是否有效。
3. 执行工具（例如调用函数或 API）。
4. 将结果反馈给模型以继续推理。

ReAct 的问题

• 脆弱的文本解析 —— 从自由形式文本中提取结构化意图容易出错。
• 难以验证或审计 —— 操作未显式声明。
• 幻觉操作 —— 模型可能会建议不存在的工具。
• 可扩展性问题 —— 不可靠的解析使大规模部署变得脆弱。

ReAct 对原型开发非常有用，但在生产环境中缺乏所需的安全性和结构化。

工具调用

工具调用在 ReAct 基础上改进，要求 LLM 返回 结构化意图 而非原始文本。典型响应可能是：

{
  "tool": "get_word_length",
  "arguments": {
    "word": "LangChain"
  }
}

关键转变

• LLM 决定 做什么，但它 不 执行工具。
• 执行由你的代码（代理运行时）负责。

这 不是限制——而是有意的设计选择。

为什么执行要留在 LLM 之外

LLM 不应直接执行代码或进行不可逆的操作，因为：

• 安全性 —— 不能保证任意代码的安全执行。
• 安全风险 —— 直接访问数据库、外部 API 或支付系统风险极大。
• 合规性 —— 审计日志和监管要求需要明确的职责划分。
• 可靠性 —— 你可以在工具调用周围添加重试、超时和沙箱机制。
• 可观测性 —— 像 LangSmith 这样的平台可以独立于模型追踪执行。
• 确定性行为 —— 运行时可以强制一致的结果。

正确的执行模型

❌ 错误模型：LLM 决定 **并且** 执行工具
✅ 正确模型：LLM 决定 → 系统执行 → LLM 推理

该模式已在以下场景中使用：

• LangGraph
• 多代理工作流
• 生产 AI 系统
• 实际的代理平台

何时保持执行在模型之外

如果你正在构建以下任意系统，请保持这种分离：

• AI 代理（聊天机器人、助理）
• 检索增强生成（RAG）流水线
• 带外部操作的对话机器人
• 主动呼叫代理
• 工作流自动化系统

核心结论： LLM 负责 推理；周边系统负责 执行。

结束语

ReAct 教会我们代理是如何思考的。一旦内化了决定‑执行的划分，代理架构就会变得更加清晰。

---

讨论提示： 如果你正在学习 LangChain 或构建代理系统，最初让你困惑的部分是什么？