AI大模型实战篇：AI Agent设计模式ReAct

来源：华体会官方网页登录入口    发布时间：2024-08-31 21:51:33

  中，风叔粗略地介绍了 AI Agent 的八种设计模式。对于这八种设计模式，风叔整理了一张图，来阐明它们之间的关系。

  ReAct 模式最早出现的 Agent 设计模式，目前也是应用最广泛的。从 ReAct 出发，有两条发展路线：

  在后续文章中，风叔将沿着上图的脉络，结合产品流程和源代码，详细的介绍这八种 AI Agent 设计模式。

  为什么选择结合源代码呢？因为在 AI 大模型时代，很多的概念和方法都太新了。只有结合源代码，产品经理才能真正理解背后的原理和逻辑，才能了解什么能做，什么不能做，AI 的边界在哪里，以及该如何与人类经验配合。

  ReAct 的概念来自论文《ReAct: Synergizing Reasoning and Acting in Language Models》，这篇论文提出了一种新的方法，通过结合语言模型中的推理（reasoning）和行动（acting）来解决多样化的语言推理和决策任务。ReAct 提供了一种更易于人类理解、诊断和控制的决策和推理过程。

  它的典型流程如下图所示，可以用一个有趣的循环来描述：思考（Thought）→ 行动（Action）→ 观察（Observation），简称 TAO 循环。

  思考（Thought）：面对一个问题，我们应该进行深入的思考。这个思考过程是关于如何定义问题、确定解决问题所需的关键信息和推理步骤。

  行动（Action）：确定了思考的方向后，接下来就是行动的时刻。根据我们的思考，采取相应的措施或执行特定的任务，以期望推动问题向解决的方向发展。

  观察（Observation）：行动之后，我们必须仔细观察结果。这一步是检验我们的行动是否有效，是否接近了问题的答案。

  如果观察到的结果并不匹配我们预期的答案，那么就需要回到思考阶段，重新审视问题和行动计划。这样，我们就开始了新一轮的 TAO 循环，直到找到问题的解决方案。

  和 ReAct 相对应的是 Reasoning-Only 和 Action-Only。在 Reasoning-Only 的模式下，大模型会基于任务进行逐步思考，并且不管有没有获得结果，都会把思考的每一步都执行一遍。在 Action-Only 的模式下，大模型就会处于完全没有规划的状态下，先进行行动再进行观察，基于观察再调整行动，导致最终结果不可控。

  在 reason-only 模式中，智能助手专注于分析和推理，但不直接采取行动。

  在 action-only 模式中，智能助手专注于执行任务，但不做深入的推理或分析。

  在 ReAct 模式中，智能助手结合推理和行动，形成一个循环的感知 - 动作循环。不仅分析了你的需求（推理），还实际修改了日程安排（行动）。

  然后，它更新你的日程安排，将会议时间改为上午 10 点（决策和动作执行阶段）。

  最后，智能助手确认修改，并提供额外的信息： 您的会议已成功改到明天上午 10 点。提醒您，会议地点不变。

  下面，风叔通过实际的源码，详细介绍 ReAct 模式的实现方法。大家可以私信风叔，或者在评论区留言 ReAct 源码 ，获取 ReAct 设计模式的示例源代码。

  在实现 ReAct 模式的时候，首先需要设计一个清晰的 Prompt 模板，主要包含以下几个元素：

  思考（Thought）：这是推理过程的文字展示，阐明我们想要 LLM 帮我们做什么，为了达成目标的前置条件是什么

  行动（Action）：根据思考的结果，生成与外部交互的指令文字，比如需要 LLM 进行外部搜索

  行动参数（Action Input）：用于展示 LLM 进行下一步行动的参数，比如 LLM 要进行外部搜索的话，行动参数就是搜索的关键词。主要是为了验证 LLM 是否能提取准确的行动参数

  观察（Observation）：和外部行动交互之后得到的结果，比如 LLM 进行外部搜索的话，那么观察就是搜索的结果。

  Name 就是函数名，description 是工具的自然语言描述，LLM 根据 description 来决定是否需要使用该工具。工具的描述应该非常明确，说明工具的功能、使用的时机以及不适用的情况。

  我们先简单地将两个描述信息拼接一下，为 Agent 提供 4 个算数工具：

  一个很有意思的事情是，这几个算数工具函数并不需要实际的代码，大模型可以仅靠自身的推理能力就完成实际的算数运算。当然，对于更复杂的工具函数，还是有必要进行详细的代码构建。

  executor 会始终进行如下事件循环直到目标被解决了或者思考迭代次数超过了最大次数：

  根据之前已完成的所有步骤（Thought、Action、Observation）和 目标（用户的问题），规划出接下来的 Action（使用什么工具以及工具的输入）

  检测是不是已经达成目标，即 Action 是不是 ActionFinish。是的话就返回结果，不是的话说明还有行动要完成

  根据 Action，执行具体的工具，等待工具返回结果。工具返回的结果就是这一轮步骤的 Observation

  我们提出一个问题，看看 Agent 怎么通过 ReAct 方式来进行解决。 一种减速机的价格是 750 元，一家公司需要购买 12 台。每台减速机运行一小时的电费是 0.5 元，企业每天运行这些减速机 8 小时。请计算企业购买及一周运行这些减速机的总花费。

  我们来看一下 Agent 的输出，以及 Agent 在这样的一个过程，是如何思考和行动的。能够正常的看到，通过 Thought、Action、Observation 的循环，AI Agent 很好地一步步完成最终答案的输出。

  在 AI Agent 的多种实现模式中，ReAct 模式是最早出现、也是目前使用最广泛的模式。ReAct 的核心思想就是模拟人思考和行动的过程，通过 Thought、Action、Observation 的循环，一步步解决目标问题。

  首先是 LLM 大模型的通病，即产出内容不稳定，不单单是输出内容存在波动，也体现在对复杂问题的分析，解决上存在一定的波动

  然后是成本，采用 ReAct 方式，我们是无法控制输入内容的。因为在任务提交给 LLM 后，LLM 对任务的拆解、循环次数是不可控的。因此存在一种可能性，过于复杂的任务导致 Token 过量消耗。

  最后是响应时间，比起大部分 API 接口毫秒级的响应，LLM 响应时间是秒级以上。在 ReAct 模式下，这一段时间变得更不可控。因为没有办法确定需要拆分多少步骤，需要访问多少次 LLM 模型。因此在在秒级接口响应的背景下，做成同步接口显然是不合适的，需要采用异步的方式。而异步方式，又会影响使用者真实的体验，对应用场景的选择又造成了限制。

  但是无论如何，ReAct 框架提出了一种非常好的思路，让现有的应用得到一次智能化的进化机会。现在很多场景已经有了非常成熟的 ReAct Agent 应用，比如智能客服、知识助手、个性化营销、智能销售助理等等。

  在下一篇文章中，风叔将介绍另一种 AI Agent 设计模式，REWOO。