ReAct框架有致命缺陷，与LLM温度有何关联？

美的

其凭借每步执行思考行动观察响应的循环来解决用户问题。不过，这一貌似完美的流程其实存在致命缺陷，若应用于实际生产环境，必然会失败。要深入理解ReAct的这一弱点，得从LLM的温度参数开始。模型运行时根据用户输入陆续输出文字。温度是影响LLM输出的一个重要参数。温度低时输出较固定，温度高时则创造性较强。

例如输入我爱，输出的词可能是中国吃股票苹果等。温度高时，输出内容的可选范围就大，像设定范围为1时，LLM会在中国吃股票苹果之中随机选取。温度低时，输出内容的选择范围就小，在极端情形下，即温度设为0时，输出的范围就只有一个词：中国。这便是温度起到的作用。知道温度之后就会明白，大语言模型（LLM）实际上是个概率模型，它会计算给定输入时输出结果的概率。要是想让模型每次输出的结果更固定，那就可以把温度设为0。简单来说，假设温度都设为0，那模型输出就全由输入决定了。不同输入有不同输出，由于温度为0，相同输入也会有相同的输出。不管LLM到底学到了什么，它说到底仍然是个概率模型。这就引出了我们今天的话题：智能体受此有何影响？在我那篇从0实现function call的文章里，提到过如下的ReAct提示词：ReAct的流程为思考、行动、观察、响应的循环，例如：ReAct最大的问题在于，每轮对话都得让LLM先进行一次路由。此路由功能涵盖思考用户意图、选择工具等（路由即下图中的LLM - ReAct节点）。这里最大的问题是路由，它判断与思考的负载过重，流程如下：

大部分的判断与思考逻辑都被LLM - ReAct这一环节卡住了。那它会带来哪些问题？若用户提出一个问题，我期望LLM在调用工具后，能给用户更具创造性的答复。不过这很可能无法达成，要是把工具和输出文字都置于概率模型上，其结构图如下：

中国

我们想把温度调得低些，这样LLM选择时就能调用正确工具而非输出文字。但温度调低后，输出文字就没那么有创造性了。上面提到的ReAct，我们之前只给它一个工具用于调用。设想一下，如果给ReAct 50个工具甚至100个工具。这时的输入内容就会包含100个工具的描述以及用户的提问。这里存在的挑战是：尤其第二点，你不能要求用户提问时表述清晰。提问不清晰会造成工具选择错误，甚至可能让LLM陷入不断的错误循环。ReAct最初的设计目的是构建一个高度抽象的结构，打造一个具备思考、调用工具、与用户交互等功能的全能智能体框架。不过，结构越抽象，离实际应用就越远，毕竟它想以一个框架来满足所有智能体的需求。就像很多SaaS平台，它们抽象出许多通用功能，使用起来很方便，但在具体场景应用时，就得开发一些特定功能。所以企业会和不少SaaS平台合作，优化其功能并补充企业特需内容，以对接具体场景。于是我们经过思考后认为：使用ReAct做些演示或者简单智能体是可行的，但要让它更契合业务、满足复杂业务需求，还得靠其他方式。首先要思考的是：构建的业务场景能否细分。将其拆为不同场景，每个场景聚焦一个最小业务。我们之前做过一个RAG应用，打算把所有数据存入向量库，再经向量检索搜索全库数据，给用户最详尽的答复，实现无搜索盲区。但这个应用失败了，TB级的数据靠向量检索根本无法完全解决，会出现很多语义相似但实际不相关的数据块。后来我们增加了复杂的意图识别，按数据类别分类，可这些方法都行不通。原因是，你应按场景细分应用，而非按数据细分。例如，同样是医学类数据，科研人员和药店柜员对其准确性与深度的要求有很大差异。构建智能体也是如此，并非把所有可能用到的工具都丢给智能体（ReAct）就能解决问题。需思考：构建的场景是什么？目标人群是哪些？场景细分后需考虑流程能否拆分，别全让智能体判定流程走向。我做过一个场景应用，患者前来问诊，智能体先采集患者信息，再依据信息下单购药。我借助ReAct完成这两个流程，主要是让它智能判断是否已完整收集患者信息，若已收集就总结内容并调用function call下单。它的智能判断令人惊讶，有时患者话没说完就下单，有时患者表述得很明确了却还不下单。这样的情况如果部署到生产环境，肯定是不合格的。若把流程拆分，不让智能体React判断，我按固定编码流程处理患者信息，经用户确认后下单，如此改造后的流程就毫无问题了。

有没有思考过这样的问题：coze、dify这些智能体工作流框架已经相当不错了，为何还需要进行代码开发？特别是在越来越多智能体框架涌现，且OpenAI也开源了其多智能体swarm框架的情况下。原因在于，场景细分、流程拆分后，需将其拼凑起来才能完成更复杂的业务场景。仅有工作流的话，简单场景可行，复杂场景开发灵活度就较差。如同乐高积木那样，先划分好各大部分并分别搭建，再把大块部分组合，如此乐高就会有更复杂的功能或构造了。

ReAct存在缺点，它让LLM承担过多事务，在意图识别时易产生不少偏差。解决方案如下：其一，不按数据拆分，而是按场景拆分，先处理最细微的场景。其二，细致拆分小场景中的流程节点，把固定流程先标准化，以减少大模型选择时的不稳定状况。其三，逐步累加小场景，借助多智能体协同合作，最终构建出完整的大场景。深入理解Agent：如何从0实现function call：乐高ev3：">https://mp.weixin.qq.com/s?__biz=MzUxNDg0NTEzOA==&mid=2247483694&idx=1&sn=43c1bce5edbe311b5cd3d568c7a1c53c&chksm=f9bef193cec9788580c24204eae5692545190853c5c164ed9936c9e18a0193a775d39ebf2970&token=1619594190&lang=zh_CNrd乐高ev3：https://www.lego.com/zh - tw/themes/mindstorms/ev3。