ReAct框架核心循环与消息格式设计：构建高效AI Agent的关键

1. 项目概述：从面试题到Agent核心原理的深度拆解

“ReAct框架的核心循环是什么？消息格式怎么设计？”——这不仅仅是一道面试题，更是打开现代智能体（Agent）开发大门的一把钥匙。最近在和一些同行交流，特别是那些在探索大模型应用落地的朋友，发现大家对ReAct这个框架既熟悉又陌生。熟悉的是名字，知道它很火，是构建AI Agent的经典范式；陌生的是其内部运作的肌理，比如那个驱动Agent思考与行动的“引擎”到底如何运转，以及支撑这个引擎的“燃料”——消息——该如何组织。这道题之所以被频繁问及，恰恰因为它触及了Agent能否稳定、可靠工作的根本。今天，我就结合自己的一些实践和思考，把这个话题掰开揉碎了讲清楚，希望能帮你不仅应付面试，更能真正理解并设计出高效的Agent系统。

简单来说，ReAct框架为大型语言模型（LLM）赋予了“思考-行动-观察”的循环能力，使其不再是简单的问答机器，而是能主动使用工具、与环境交互的智能体。核心循环定义了Agent的行为模式，而消息格式则是循环中信息传递的“协议”，两者共同决定了Agent的智商（推理能力）和情商（交互稳定性）。无论你是正在面试的开发者，还是已经在着手构建基于LLM的自动化流程、智能客服或数据分析助手，吃透这两点，都能让你在架构设计时心里更有底，避开很多初期容易踩的坑。

2. 核心循环解析：ReAct的“思考-行动-观察”引擎

要理解ReAct，首先得跳出将大模型视为“百科全书”或“文本生成器”的固有印象。ReAct（Reasoning + Acting）框架的提出，正是为了将大语言模型升级为一个具备自主交互能力的智能体。它的核心是一个高度结构化的循环流程，这个流程模拟了人类解决问题时的基本模式：先动脑想，再动手做，然后看看结果如何，接着再想下一步。

2.1 循环的三步分解与内在逻辑

这个核心循环可以精确地分解为三个步骤：推理、行动、观察。它们环环相扣，形成一个闭环。

第一步：推理这是循环的起点，也是智能的体现。在此阶段，LLM基于当前的任务目标、已有的历史信息（包括之前的观察结果）以及可用的工具列表，进行“思考”。思考的输出不是一个最终答案，而是一个明确的、可执行的下一步计划。这个计划通常包括两个关键决策：

1. 是否需要行动？如果根据已有信息已经能得出结论或回答问题，则直接生成最终答案（Final Answer），循环终止。
2. 如果需要行动，调用哪个工具？输入是什么？模型需要从工具集中选择最合适的一个，并为其构造准确的输入参数。

注意：推理步骤的质量直接决定了整个Agent的效率和准确性。一个常见的误区是让模型在推理时“天马行空”，这会导致行动步骤的混乱。因此，在提示工程中，必须用清晰的指令约束模型的推理输出格式，例如强制要求其以“Thought: ”开头，并且只能选择预设的工具。

第二步：行动根据推理步骤的决策，Agent将执行一个具体的动作。在代码实现中，这通常表现为调用一个预定义的函数或API。例如，如果任务是“查询北京今天的天气，并判断是否适合户外跑步”，在推理步骤模型可能决定调用“天气查询工具”。那么行动步骤就是执行这个工具调用，传入参数“北京”，并获取返回的原始数据，如{“city”: “北京”， “temperature”: “25°C”， “condition”: “晴”， “humidity”: “40%”}。

第三步：观察行动步骤产生了结果，但这个结果通常是结构化的数据或原始文本。观察步骤的核心工作是消化和理解这个结果。LLM会接收行动的输出，并将其提炼、总结成一段自然语言的描述，这段描述将被加入到后续推理步骤的上下文历史中。例如，将上面的天气JSON数据总结为：“观察：北京今天天气晴朗，气温25摄氏度，湿度40%。”

观察步骤至关重要，它完成了从“机器数据”到“模型可理解语言”的转换，为下一轮的推理提供了高质量的输入。没有良好的观察，历史上下文就会充斥杂乱数据，导致模型推理能力下降。

2.2 循环的终止条件与设计考量

这个循环不会无限进行下去，它需要有明确的终止条件，通常有两种：

1. 成功终止：在推理步骤，模型判断已有足够信息，直接输出了“Final Answer”。
2. 失败/安全终止：达到最大循环次数限制，或行动步骤出错且无法恢复。

在设计循环时，必须考虑以下几个关键点：

• 循环最大次数：必须设置一个上限（如10次），防止因模型“钻牛角尖”或陷入死循环而消耗过多资源。
• 错误处理：在行动或观察步骤可能出错（如工具API调用失败、返回格式异常）。循环机制需要能捕获这些错误，并将其作为特殊的“观察”反馈给模型，让模型有机会调整策略（例如，重试或选择其他工具）。
• 上下文管理：随着循环进行，历史消息（Thought, Action, Observation）会不断增长。需要设计有效的上下文窗口管理策略，例如只保留最近N轮交互，或对早期历史进行摘要，以防止超出模型的令牌限制。

从我实际构建Agent系统的经验来看，一个健壮的循环实现，其代码逻辑更像是一个状态机。它维护着当前的任务状态、历史记录和工具集，并根据每一步的输出决定下一个状态。很多初学者会把重点全放在提示词上，而忽略了循环控制逻辑的健壮性，结果就是Agent非常脆弱，容易“跑飞”。一个实用的技巧是，在开发初期，为循环的每一步都打上详细的日志，记录下模型完整的Thought、调用的Action和得到的Observation，这是调试Agent诡异行为的最有效手段。

3. 消息格式设计：Agent交互的“通信协议”

如果说核心循环是Agent的发动机，那么消息格式就是保证发动机各部件协同工作的润滑油和传动轴。设计不当的消息格式会导致信息传递失真、上下文混乱，最终让再聪明的模型也变得“痴呆”。消息格式的设计目标很明确：让LLM清晰地理解当前对话的完整状态、自己的角色以及下一步应该做什么。

3.1 结构化提示：消息格式的基石

ReAct框架通常不采用自由对话式的消息列表，而是使用高度结构化的提示模板。这个模板将系统指令、工具描述、历史对话和当前问题组合成一个整体。一个典型的结构如下：

你是一个智能助手，可以调用工具来解决问题。 你可以使用的工具有： {tool_descriptions} 请严格按照以下格式响应： Thought: 首先，我需要思考当前情况和目标。我可以使用上述工具。 Action: 要调用的工具名称，必须是[{tool_names}]中的一个。 Action Input: 调用该工具所需的输入参数。 Observation: 工具返回的结果会放在这里。 如果任务已经完成，请输出： Final Answer: 你的最终回答。 现在开始： 历史记录： {history} 当前问题：{question} Thought:

关键组件解析：

• 系统指令：定义Agent的角色和能力边界。指令必须清晰、无歧义，明确告诉模型要遵循ReAct格式。
• 工具描述：以模型能理解的方式描述每个工具的功能、输入和输出。描述应简洁准确，例如“search_web(query: str): 使用搜索引擎查询网络信息，返回相关摘要。”
• 格式约束：这是强制模型输出结构化内容的关键。明确要求以“Thought:”, “Action:”, “Action Input:”, “Observation:”, “Final Answer:”作为关键词。许多框架会使用正则表达式或解析器来提取这些关键词后的内容。
• 历史记录：这是动态部分，由之前所有循环的(Thought, Action, Observation)三元组拼接而成。它提供了完整的决策轨迹。
• 当前问题：初始的用户查询，或在多轮对话中最新的人类输入。

3.2 历史上下文的组织与优化

随着交互轮次增加，历史记录会越来越长。如何有效管理这段历史，是消息格式设计中的高级课题。

1. 完整历史拼接：最简单的方式是将每一轮的Thought, Action, Observation直接追加。这种方式信息最全，但消耗的Token增长最快，很快就会触达模型上下文长度上限。

2. 滑动窗口：只保留最近N轮（如最近3轮）的完整交互历史。这种方法能有效控制长度，但可能丢失关键的长期依赖信息。对于需要多步复杂规划的任务，这可能不是最佳选择。

3. 摘要压缩：这是一种更智能的方式。在每一轮或每几轮之后，让另一个LLM（或同一个模型在特定指令下）对之前的历史进行摘要，用一段浓缩的文字替代大段原始交互记录。例如，将五轮关于天气查询、路线规划、餐厅推荐的交互，摘要为“用户计划今天下午在朝阳公园户外跑步，并希望在跑步后找到一家附近的轻食餐厅。”然后将这个摘要作为新的“压缩后历史”放入上下文。这能极大节省Token，同时保留核心意图。

4. 关键信息提取：另一种思路是不保留完整的对话文本，而是从中提取出结构化的关键事实（例如，日期、地点、用户偏好等），并将其存储在一个独立的“知识库”或“状态变量”中。在后续的推理中，模型可以参考这个结构化状态，而不是冗长的历史文本。

在实际项目中，我通常会采用混合策略。对于短任务，使用完整历史或滑动窗口；对于长周期、多会话的Agent（如客户服务机器人），则必须引入摘要压缩或关键信息提取机制。这里有一个踩坑经验：早期我们尝试让Agent自己生成历史摘要，但发现摘要质量不稳定，有时会丢失关键细节。后来改进为设计一个固定的摘要模板，引导模型填充关键实体和决策点，稳定性大大提升。

3.3 工具描述的编写艺术

工具描述看似简单，实则极大地影响模型调用工具的准确性。差的描述会导致模型不理解工具用途、传错参数。

优秀工具描述的特征：

• 功能清晰：用一句话说明这个工具是干什么的。例如，“计算两个数字的和”就比“进行数学运算”好。
• 输入明确：说明输入参数的名称、类型和含义。例如，“city: str，城市名称，例如‘北京’、‘Shanghai’”。
• 输出示例：给出一个典型的输出例子，让模型对返回结果有预期。例如，“返回格式：{“temperature”: 25, “unit”: “°C”}”。
• 使用场景：在描述中暗示何时使用该工具。例如，“当问题涉及实时信息或最新事件时，可使用此工具”。

你可以把工具描述看作是为模型提供的“API文档”。编写时，要站在模型的角度，想象它如何根据你的描述做选择。一个实用的技巧是，在开发阶段，可以故意让模型在少量测试用例上运行，然后分析它错误调用工具的原因，反过来优化工具描述。

4. 从理论到实践：构建一个简易ReAct Agent

理解了原理和设计，我们动手实现一个简化版的ReAct Agent核心部分。这里以Python伪代码为例，展示循环和消息构建的关键逻辑。我们假设有一个可以调用“计算器”和“网络搜索”工具的Agent。

4.1 定义工具与系统提示

首先，我们定义两个简单的工具函数和它们的描述：

import json import requests def calculator(expression: str) -> str: """计算一个数学表达式的结果。 输入：expression (str)，例如 "3 + 5 * 2" 输出：计算结果的字符串，例如 "13" """ try: # 警告：实际生产环境请使用更安全的评估方法，如ast.literal_eval或专用库 result = eval(expression) return str(result) except Exception as e: return f"计算错误：{e}" def search_web(query: str) -> str: """使用搜索引擎查询信息（此处简化为模拟）。 输入：query (str)，搜索关键词，例如 "Python最新版本" 输出：模拟返回的摘要信息字符串。 """ # 模拟网络请求和结果提取 mock_responses = { "Python最新版本": "Python的最新稳定版本是3.12。", "北京天气": "北京今天晴，气温20-28摄氏度。" } return mock_responses.get(query, f"未找到关于'{query}'的信息。") # 工具映射字典，方便通过名称调用函数 TOOLS = { "calculator": calculator, "search_web": search_web } # 工具描述字符串，用于构建系统提示 TOOL_DESCRIPTIONS = """ 1. calculator: 计算一个数学表达式的结果。输入是一个数学表达式字符串，如 "3 + 5 * 2"。 2. search_web: 查询网络信息。输入是一个搜索查询字符串，如 "Python最新版本"。 """

接下来，构建核心的系统提示模板。这个模板将指导模型的每一步输出：

SYSTEM_PROMPT_TEMPLATE = f"""你是一个智能助手，可以通过调用工具来解决问题。 你可以使用的工具有： {TOOL_DESCRIPTIONS} 你必须严格按照以下格式响应： Thought: 首先，我需要思考当前情况和目标。分析我是否需要使用工具，以及使用哪个工具。 Action: 要调用的工具名称，必须是[calculator, search_web]中的一个。 Action Input: 调用该工具所需的输入参数。 Observation: 工具返回的结果会放在这里。 当你拥有足够的信息来回答用户问题时，请输出： Final Answer: 你的最终回答。 现在开始： """

4.2 实现核心ReAct循环逻辑

核心的Agent类需要维护对话历史，并能够执行循环：

class SimpleReActAgent: def __init__(self, llm_client, max_steps=5): """ 初始化Agent。 :param llm_client: 一个能够调用大语言模型的客户端对象，需要有 `generate` 方法。 :param max_steps: 最大循环步数，防止无限循环。 """ self.llm = llm_client self.max_steps = max_steps self.history = [] # 存储 (Thought, Action, Action Input, Observation) 元组 def run(self, query: str) -> str: """执行ReAct循环处理用户查询。""" full_prompt = SYSTEM_PROMPT_TEMPLATE step = 0 while step < self.max_steps: step += 1 print(f"\n--- 步骤 {step} ---") # 1. 构建当前轮次的完整提示（包含历史） current_prompt = full_prompt if self.history: history_text = "\n".join([f"Thought: {t}\nAction: {a}\nAction Input: {ai}\nObservation: {o}" for t, a, ai, o in self.history]) current_prompt += f"历史记录：\n{history_text}\n\n" current_prompt += f"当前问题：{query}\nThought:" # 2. 调用LLM进行推理 response = self.llm.generate(current_prompt) print(f"模型原始响应：\n{response}") # 3. 解析模型的响应 lines = response.strip().split('\n') thought, action, action_input, final_answer = "", "", "", "" for i, line in enumerate(lines): if line.startswith('Thought:'): thought = line.replace('Thought:', '').strip() elif line.startswith('Action:'): action = line.replace('Action:', '').strip() elif line.startswith('Action Input:'): # Action Input可能包含换行，需要小心处理（简化处理，取下一行或剩余部分） action_input = line.replace('Action Input:', '').strip() # 简单处理：如果下一行不是新的关键词，则追加 if i+1 < len(lines) and not any(lines[i+1].startswith(kw) for kw in ['Thought:', 'Action:', 'Observation:', 'Final Answer:']): action_input += " " + lines[i+1].strip() elif line.startswith('Final Answer:'): final_answer = line.replace('Final Answer:', '').strip() # 如果Final Answer有多行，可以继续追加（此处简化） for j in range(i+1, len(lines)): if lines[j].strip() and not lines[j].startswith(('Thought:', 'Action:', 'Observation:')): final_answer += "\n" + lines[j].strip() # 4. 判断并执行 if final_answer: print(f"\n任务完成！最终答案：{final_answer}") return final_answer if action and action in TOOLS: print(f"思考：{thought}") print(f"执行动作：{action}, 输入：{action_input}") # 执行工具调用 try: observation = TOOLS[action](action_input) except Exception as e: observation = f"工具调用失败：{e}" print(f"观察结果：{observation}") # 将本轮信息存入历史 self.history.append((thought, action, action_input, observation)) # 在提示中，Observation是由我们后续添加的，所以本轮循环结束，下一轮会包含它 else: # 如果解析不出有效的Action，可能是模型格式错误，将其作为Observation反馈，让模型调整 error_obs = f"无法解析出有效的Action。请确保严格按照指定格式响应。你上次的响应是：{response[:100]}..." print(f"解析错误：{error_obs}") self.history.append((thought, "Parse Error", "", error_obs)) # 安全措施：如果连续出错，可以终止循环 if step > 2: return "Agent在解析步骤上出现多次错误，已终止。" # 循环达到最大步数仍未得出最终答案 return f"已达到最大步数（{self.max_steps}），未能解决问题。最后的历史记录：{self.history[-1] if self.history else '无'}" # 模拟一个LLM客户端（实际中替换为OpenAI、Anthropic等API调用） class MockLLMClient: def generate(self, prompt): # 这是一个极其简化的模拟，实际应用需要调用真实的LLM API # 这里根据提示内容硬编码一些响应来模拟流程 if "3的平方是多少" in prompt: return "Thought: 用户问3的平方是多少，这是一个数学计算问题，我可以使用计算器工具。\nAction: calculator\nAction Input: 3**2" elif "计算" in prompt and "搜索" not in prompt: # 假设历史中已经有了一次计算，现在需要最终回答 return "Thought: 我已经通过计算器得到了3的平方等于9，现在可以给出最终答案了。\nFinal Answer: 3的平方等于9。" elif "Python最新版本" in prompt: return "Thought: 用户想了解Python的最新版本，这是一个需要最新信息的问题，我应该使用网络搜索工具。\nAction: search_web\nAction Input: Python最新版本" elif "搜索" in prompt: return "Thought: 我已经搜索到Python的最新稳定版本是3.12，现在可以回答用户了。\nFinal Answer: Python的最新稳定版本是3.12。" else: return "Thought: 我需要更多信息来理解这个问题。\nAction: search_web\nAction Input: 请澄清你的问题" # 使用示例 if __name__ == "__main__": llm_client = MockLLMClient() agent = SimpleReActAgent(llm_client, max_steps=5) # 测试用例1：数学计算 print("测试1：计算3的平方") result1 = agent.run("3的平方是多少？") print(f"测试1结果：{result1}\n") # 重置Agent历史 agent.history = [] # 测试用例2：事实查询 print("测试2：查询Python最新版本") result2 = agent.run("Python的最新版本是什么？") print(f"测试2结果：{result2}")

4.3 关键实现细节与避坑指南

上面的代码展示了一个最简骨架，但在实际开发中，以下几个地方的实现决定了系统的稳定性：

1. 响应解析的鲁棒性：我们用了简单的字符串匹配来解析Thought、Action等，这非常脆弱。真实环境中，模型的输出可能会有多余的空格、换行、甚至轻微的格式偏差。更健壮的做法是使用正则表达式。例如，用re.search(r'Action:\s*(.+)', response)来提取Action内容，它能容忍格式上的微小变化。

2. 工具调用的安全与隔离：示例中直接用eval()执行计算，这在生产环境是极度危险的，因为它允许执行任意代码。必须替换为安全的表达式求值库（如ast.literal_eval配合自定义操作符，或使用numexpr、pandas.eval等受限环境）。对于网络搜索等工具，要做好超时、重试和异常处理。

3. LLM调用与上下文管理：我们的模拟客户端是硬编码的。真实情况下，你需要集成LLM API（如OpenAI, Anthropic, 本地部署的模型等）。需要注意：

• Token计数与截断：在构建current_prompt时，需要实时计算Token数，如果超过模型上限，就要触发历史压缩或截断策略。
• 温度参数：在推理步骤，通常使用较低的温度（如0.1），以确保输出的格式稳定、可解析。在最终生成答案时，可以适当调高温度使语言更自然。

4. 观察步骤的智能化：示例中直接将工具返回的字符串作为Observation。有时工具返回的是复杂的JSON或HTML，直接塞给模型会干扰其推理。更好的做法是设计一个“观察生成器”，可能是一个轻量级的LLM调用或一套规则，用于将原始结果总结或格式化成一段简洁、信息丰富的自然语言文本。

在我经历的一个电商客服Agent项目中，我们最初直接把商品数据库的JSON记录扔给模型做Observation，结果模型经常抓错字段。后来我们写了一个简单的模板，把关键信息（名称、价格、库存状态）提取出来，格式化成“商品A当前售价XX元，库存充足”，模型的工具调用准确率立刻提升了30%以上。这个“观察生成器”往往是被忽视但性价比极高的优化点。

5. 高级话题与常见问题排查

当你搭建起基础的ReAct Agent后，可能会遇到一些典型问题。下面是一些常见陷阱及其解决方案。

5.1 模型不遵循指定格式

这是初期最常见的问题。模型输出乱七八糟的文字，不按你设定的Thought/Action格式来。

• 原因：系统指令不够强硬，或示例不够清晰。
• 解决方案：
  1. 强化指令：在系统提示中明确强调“你必须”、“严格遵循”、“只能使用以下格式”。
  2. 提供少样本示例：在提示中直接给出一到两个完整的(Thought, Action, Observation, Final Answer)示例。Few-shot learning对于引导模型格式非常有效。
  3. 使用结构化输出模式：如果使用的LLM支持（如OpenAI的JSON模式、Anthropic的XML工具调用），可以要求模型直接输出JSON对象，然后在代码中映射到Thought、Action等字段。这是最可靠的方法。
  4. 后处理与重试：当解析失败时，不要直接崩溃。可以将错误信息（如“你的响应格式不正确”）和原始问题一起，作为新的输入再次发送给模型，要求其纠正。通常模型第二次会遵守规则。

5.2 工具选择错误或参数错误

模型理解了要调用工具，但选错了工具，或传入的参数格式不对。

• 原因：工具描述不清晰，或者任务本身模糊，导致模型难以决策。
• 解决方案：
  1. 优化工具描述：如前所述，提供清晰的功能说明、输入输出示例。甚至可以加入“使用场景”或“何时不适用”的说明。
  2. 工具分类与路由：如果工具很多，可以尝试分层设计。先让模型判断问题类型（如“计算”、“查询”、“创作”），再在子类别中选择具体工具。
  3. 参数验证与提示：在调用工具前，对输入参数进行基本验证（如非空、类型）。如果验证失败，可以将错误信息作为Observation反馈给模型，让它重新生成Action Input。
  4. 增加反思步骤：在复杂的多步任务中，可以在每轮结束后，让模型简短地“反思”一下当前进展和下一步计划是否正确，这有助于其进行自我纠正。

5.3 陷入循环或无法终止

Agent不停地调用工具，却始终得不出最终答案，或者在一个无关紧要的细节上打转。

• 原因：任务目标不明确，或者模型缺乏判断“何时信息已足够”的能力。
• 解决方案：
  1. 明确终止条件：在系统指令中，除了说“当你拥有足够信息时输出Final Answer”，最好给出更具体的指导。例如，“当你从可靠工具中获得了直接回答用户问题的信息时，即可终止。”
  2. 设置步数限制：这是必须的安全网。通常5-10步对于大多数任务足够了。
  3. 设计“超时”或“求助”机制：当循环达到一定步数或陷入重复模式时（例如，连续三次调用同一个工具且参数相似），可以强制插入一个Observation，告诉模型“似乎未能取得进展，请重新评估你的计划或直接尝试给出当前已知的最佳答案”。
  4. 任务分解：对于非常复杂的任务，不要指望一个ReAct循环搞定。可以设计一个上层“规划器”，先将大任务分解成明确的子任务序列，然后为每个子任务启动一个ReAct循环。

5.4 上下文长度爆炸

历史对话越来越长，导致提示词超出模型限制，响应速度变慢，成本增加。

• 原因：历史记录无限制增长。
• 解决方案（结合第3.2节）：
  1. 滑动窗口：实现最简单，适用于短期记忆任务。
  2. 自动摘要：这是应对长上下文的最佳实践。可以每3-5轮，或当Token数接近阈值时，触发一个摘要任务。用一个简短的提示让模型（可以是同一个，也可以是一个更小、更快的模型）将之前的关键决策和事实总结成一段话。
  3. 向量检索：将历史交互中的关键信息（如工具返回的具体数据、用户明确提出的要求）存入向量数据库。在每一轮，不仅提供最近的原始历史，还从向量库中检索相关的历史信息作为补充。这实现了类似“长期记忆”的功能。
  4. 状态变量：对于会话型Agent，显式地维护一些状态变量（如用户姓名、当前讨论的产品、已确认的偏好等），而不是把所有信息都塞在对话历史里。

在实际运维中，为Agent建立完善的日志和监控系统至关重要。记录下每一轮的完整提示、响应、工具调用结果和耗时。当Agent行为异常时，这些日志是唯一的“黑匣子”数据，能帮你快速定位问题是出在提示词、工具、还是模型本身。我曾通过分析日志发现，某个工具API偶尔返回一个罕见的错误码，导致Observation格式异常，进而使后续所有轮次混乱。没有详细日志，这种问题就像大海捞针。