从LLM到Agent：ReAct推理模式的底层原理

从LLM到AgentReAct推理模式的底层原理你用过ChatGPT但你有没有想过为什么它能回答今天天气怎么样却没法真的帮你查天气这篇文章从零开始带你理解聊天机器人和智能助手之间的那道坎——ReAct推理循环——到底是怎么回事。一、LLM到底是什么为什么它四肢瘫痪先从最基本的概念说起。LLM大语言模型本质上是一个数学函数输入文本 → 预测下一个字 → 拼回去 → 输出文本它做的事就是根据前面的文字猜下一个字。训练了海量数据后这个猜变得极其精准精准到看起来像是理解了问题、思考出了答案。但它实际上一次都没有离开过文字的世界。所以LLM有个致命缺陷它只能输出文字不能和外界交互。你问它今天天气怎么样它能输出一段看起来很合理的文字但那不是今天的天气是它训练数据里见过的天气预报示例。要解决这个问题需要给LLM装上手和脚——让它能够调用外部的工具。比如一个查天气的工具一个发邮件的工具一个搜索文件的工具LLM需要自己决定什么时候调用哪个工具。这就引出了ReAct。二、ReActLLM的思考-行动循环2.1 问题很简单LLM怎么知道自己该调工具直觉上我们可以写一个规则引擎如果用户说天气就调天气工具如果用户说计算就调计算器。但实际用户说的话千变万化。“这两天出门要不要带伞”——你看到伞会想到天气但关键词匹配很难枚举所有可能。我们需要LLM自己理解用户意图自己决定调哪个工具。这就是ReAct要解决的问题。2.2 ReAct的核心思想ReAct这个名字来自两个词的组合Reasoning推理分析当前情况想清楚该做什么Acting行动真正去执行它不是一步到位而是一个循环第1步看用户问题 → 思考 → 判断需要查天气 → 调用天气工具 第2步拿到天气结果 → 思考 → 判断信息够了 → 输出回答这个循环看似简单但它实现了一个很关键的能力LLM不需要第一次就答对它可以一步步来先获取信息再基于信息回答。2.3 用大白话解释ReAct的每一步假设用户问“明天北京天气怎么样适合户外运动吗”没有ReAct的LLM纯文字模式→ 直接回答明天北京晴转多云气温15-25度适合户外运动。 问题是这个答案是编的LLM根本不知道明天什么天气它只是根据训练数据猜了一个合理的回答。有ReAct的Agent第1轮 用户明天北京天气怎么样适合户外运动吗 LLM思考我不知道明天天气需要查一下。 LLM输出{调用工具: getWeather, 参数: city北京, date明天} 第2轮 工具返回{天气: 晴, 温度: 18-26度, 风力: 2级} LLM思考天气晴朗温度舒适风力小。 LLM输出明天北京晴天18到26度风力2级非常适合户外运动LLM不再需要编造答案因为它拿到了真实数据。三、Function CallingReAct的工程落地3.1 这不是回调函数这是消息拼接很多初学者以为工具调用就是LLM回调一个Java方法。不是的。底层发生的事情更简单也更精妙LLM的输入是一串消息。输出也是一串消息。工具的加入不过是在这串消息中插入了新的消息。整个对话的消息序列是这样的消息1 [system角色]: 你是智能助手以下工具可用{天气查询, 计算器, 文件搜索...} 消息2 [user角色]: 明天北京天气怎么样 消息3 [assistant角色]: {我想调天气工具} {工具名: getWeather, 参数: city北京} ← LLM输出 消息4 [tool角色]: {天气: 晴, 18-26度, 风力2级} ← 工具执行结果插入到消息序列中 消息5 [assistant角色]: 明天北京晴天18-26度适合户外运动 ← LLM基于消息1-4重新推理关键点工具调用结果不是回调给LLM的是追加到消息历史里的。LLM看到上下文里多了一条消息消息4自然地基于此继续推理。3.2 这为什么精妙因为LLM根本不需要任何架构改造。它还是做它最擅长的事——给定一串消息预测下一条消息。多出来的工具结果只是消息序列中的一个新条目对LLM来说和用户发的消息没有本质区别。这个设计让ReAct的实现极其简单不需要修改LLM只需要在被调用的工具返回后把结果塞进消息序列然后让LLM再跑一次。3.3 那LLM怎么知道有哪些工具可用每个工具都有一个说明书JSON Schema描述了它的名字、作用、参数。比如天气工具的说明书{name:get_weather,description:查询指定城市明天的天气,parameters:{type:object,properties:{city:{type:string,description:城市名称}}}}所有工具的说明书都放在System Prompt消息1里。LLM读取后就知道有哪些工具、每个工具要什么参数。当它判断需要使用某个工具时它输出的不是文字而是一个结构化的JSON对象指出了工具名和参数值。四、System PromptAgent行为的控制面板4.1 同样的工具不同的行为假设Agent有三个工具查天气、计算器、搜索文件。用户说“帮我算3.14 × 256”。LLM可以选项A直接心算大概是800左右选项B调用计算器返回准确的803.84选A还是选B取决于概率。而System Prompt的作用就是改变这个概率——让正确的选项变得更可能。4.2 一个具体的例子对比两种System PromptPrompt A模糊版你是智能助手可以使用以下工具get_weather, calculate, search_file。Prompt B精确版你是智能助手严格遵守以下规则 1. 任何数学计算必须调用calculate工具禁止心算 2. 任何天气查询必须调用get_weather工具禁止猜测 3. 任何文件操作必须调用search_file工具 4. 调用了工具后只回复工具返回的精确结果不要补充或修改面对同样的用户输入3.14 × 256Prompt A下LLM有约40%概率心算因为心算更方便Prompt B下LLM几乎100%调用计算器因为被明确禁止心算这就是为什么写Prompt不是锦上添花而是Agent开发的核心工作。代码搭建了工具手脚Prompt决定了Agent怎么选择使用这些工具。五、Single Agent vs Multi Agent架构的分岔路口理解了ReAct和Function Calling后你会面临一个选择所有工具放一个Agent还是拆成多个专业Agent5.1 Single Agent一个Agent看到所有工具自己决定调哪个。优势是简单直接。只要工具数量不超过10个这个方案工作得很好。问题是工具多了之后LLM会选择困难。就像你面前摆了30个工具箱每次要花很长时间才能找到对的——有时还会找错。5.2 Multi Agent一个调度员 多个专家 调度员分析用户问题 → 决定派哪个专家 → 专家出结果 → 调度员汇总回答每个专家只看到自己领域内的工具选择准确率高。而且职责隔离——搜索专家根本不知道有删除文件这个工具绝不可能误删文件。5.3 如何选择一个经验法则工具10个用Single Agent工具15个、或者需要职责隔离比如有些操作很危险用Multi Agent。我们的项目支持两种模式通过一个配置项切换方便你对比不同模式下的Agent行为。六、总结让我们串联一下今天学到的内容LLM的局限只能输出文字不能和外界交互ReAct循环思考→行动→观察→再思考让LLM逐步逼近正确答案Function Calling通过把工具结果追加到消息序列中让LLM自然地基于真实数据推理System Prompt控制Agent行为的概率调节器改变工具选择的准确性架构选择工具少用Single Agent工具多用Multi Agent理解了这些你就理解了所有Agent框架的基石。后面几天的Skill系统、MCP协议、多Agent编排都是在这个地基上搭建的更高层建筑——它们的本质都是给LLM装更好的手和脚让它更精确地判断什么时候用哪个。项目链接项目代码day6-agent