企业官网建设流程全解析

1. 项目概述：从“工具调用”到“自主思考”的范式跃迁

如果你最近在折腾大语言模型应用，尤其是想让它帮你完成一些稍微复杂点的任务，比如查查天气然后决定要不要带伞，或者分析一份财报数据再生成投资建议，那你大概率已经遇到了一个核心瓶颈：模型怎么才能“有逻辑地”去执行一系列动作？它不能只是被动地回答“今天天气如何”，而是需要主动地“思考”：“用户问我要不要带伞，所以我得先知道天气。好，我去调用天气API。哦，下雨概率80%，那我建议带伞，并且提醒用户下午有雨。” 这个“思考-行动-观察-再思考”的循环，就是ReAct工作模式的核心。它让AI Agent从一个简单的问答机，变成了一个能规划、能执行、能纠错的“智能体”。

我最初接触这个概念时，觉得它像给模型装上了一套“外置大脑”。传统的提示工程（Prompt Engineering）更像是给模型一本详细的说明书，告诉它第一步做什么、第二步做什么。但ReAct不同，它赋予模型的是元认知能力——让模型自己决定下一步该做什么，并在执行后根据结果调整策略。这不仅仅是技术上的优化，更是一种工作范式的根本性转变。从“我告诉你怎么做”变成了“你自己想想该怎么做”。在实际项目中，无论是构建一个能自动处理客服工单的Agent，还是一个能联网搜索、分析并撰写报告的研究助手，ReAct都是实现其“智能”的基石框架。接下来，我就结合多次实战踩坑的经验，为你彻底拆解ReAct模式，并提供一个从零到一、可直接复现的实战指南。

2. ReAct模式的核心原理与设计哲学

2.1 什么是ReAct？拆解“思考-行动”循环

ReAct， 全称是Reasoning + Acting。这个术语最早出自一篇著名的学术论文《ReAct: Synergizing Reasoning and Acting in Language Models》。它的设计灵感来源于人类解决问题的方式：我们很少能一步到位得到答案，而是会先思考（Reason），然后采取行动（Act），观察行动结果（Observe），再基于结果进行下一轮思考，如此循环。

在AI Agent的语境下，这三个步骤被形式化为：

1. 思考（Thought）: Agent分析当前的任务、已有的信息（包括历史记录和上一步的观察结果），并推理出下一步应该执行哪个动作（Action）。这是Agent的“内省”过程。
2. 行动（Action）: Agent根据思考的结论，调用一个外部工具（Tool）或执行一个具体操作。例如，调用搜索引擎API、查询数据库、运行一段代码等。行动通常会有一个明确的输入。
3. 观察（Observation）: Agent接收行动执行后返回的结果。这个结果可能是一段文本、一组数据、一个状态码，甚至是错误信息。这个观察结果会成为下一轮“思考”的输入。

这个循环会一直持续，直到Agent认为任务已经完成（例如，生成了最终答案），或者达到了预设的步骤限制。

2.2 为什么ReAct如此重要？对比传统提示工程的优劣

在没有ReAct之前，我们通常使用思维链（Chain-of-Thought, CoT）提示来让模型进行推理。CoT确实提升了模型的推理能力，但它有一个致命缺陷：推理是封闭的。模型的“思考”完全基于其训练时学到的知识，无法获取实时、动态的外部信息。它可能会编造一个不存在的API响应，或者给出一个过时的股票价格。

ReAct通过引入“行动”环节，完美地解决了这个问题：

• 动态信息获取：Agent可以通过工具与真实世界交互，获取最新的、模型训练数据中不存在的信息。
• 可验证性与纠错：每一步行动的结果都是可观察的。如果结果不符合预期（比如API返回错误），Agent可以在下一轮思考中识别这个错误，并尝试其他策略（比如重试、换一个工具或向用户求助）。
• 任务分解与规划：复杂任务被自动分解为一系列子任务。例如，“帮我策划一个周末旅行”会被分解为“查询目的地天气”、“查找热门景点”、“对比酒店价格”等一系列行动。
• 透明度与可解释性：整个“思考-行动-观察”的轨迹（Trace）被完整记录了下来。这就像一份审计日志，让我们可以清晰地看到Agent的决策过程，便于调试和优化。

简单来说，CoT让模型“想得更清楚”，而ReAct让模型“做得更正确”。后者是实现实用化AI Agent的必由之路。

2.3 ReAct模式的关键组件与架构设计

要实现一个ReAct工作流的Agent，我们需要设计和整合以下几个核心组件：

1. 智能体核心（LLM Core）：通常是一个大语言模型（如GPT-4、Claude 3、或开源的Llama 3、Qwen等）。它的核心职责是进行“思考”，即根据当前对话历史和观察，生成包含下一步“行动”的文本。模型需要被精心提示（Prompt），以遵循ReAct的格式输出。

2. 工具集（Tools）：这是Agent的“手脚”。每个工具都是一个具有明确定义功能的函数，例如：

   • search_web(query: str) -> str: 执行网络搜索。
   • get_weather(city: str) -> str: 获取城市天气。
   • calculator(expression: str) -> str: 执行数学计算。
   • read_file(path: str) -> str: 读取本地文件。 工具的定义必须清晰，包括名称、描述、参数格式，这样LLM才能知道在什么情况下调用哪个工具。

3. 解析器（Parser）：负责解析LLM输出的文本。LLM的输出是一段自然语言，我们需要从中精确地提取出“行动”的名称和参数。通常，我们会要求LLM以特定格式（如Action: 工具名\nAction Input: 参数）输出，然后用正则表达式或专用解析库来提取。

4. 执行器（Executor）：负责调用解析出的工具，并获取“观察”结果。执行器需要处理工具调用可能出现的异常（如网络超时、参数错误），并将结果格式化为字符串，反馈给LLM进行下一轮思考。

5. 记忆与状态管理（Memory & State）：负责维护整个对话和任务执行的历史（即所有的Thought-Action-Observation序列）。这是LLM进行下一轮思考的上下文。如何高效地管理长上下文，避免无关历史干扰核心决策，是一个重要的工程问题。

6. 停止条件（Stopping Condition）：定义Agent何时结束循环。最常见的是当LLM的输出中包含如Final Answer:这样的特定标记时。此外，还需要设置最大迭代次数，防止陷入死循环。

将这些组件串联起来，就构成了一个典型的ReAct Agent运行架构：Prompt（初始化任务） -> LLM（生成Thought和Action） -> Parser（解析Action） -> Executor（执行Tool） -> 更新Memory -> 判断是否停止 -> 下一轮循环。

3. 从零搭建一个ReAct智能体：实战步骤详解

理论讲得再多，不如亲手搭一个。下面我将以构建一个“旅行规划助手”Agent为例，带你走通全流程。我们将使用Python和流行的LangChain框架来简化开发，但原理是通用的。

3.1 环境准备与工具定义

首先，安装核心依赖。我们选择LangChain是因为它提供了高度封装的ReAct实现，让我们能更专注于逻辑而非底层循环。

pip install langchain langchain-openai langchain-community

假设我们为旅行助手定义了三个核心工具：

1. 搜索工具：获取景点、美食等实时信息。
2. 天气工具：查询目的地未来几天的天气。
3. 计算工具：进行简单的预算计算。

在LangChain中，工具可以用@tool装饰器轻松定义。

from langchain.tools import tool from langchain_openai import ChatOpenAI import requests import json # 工具1: 模拟网络搜索（实际项目中可接入SerpAPI等） @tool def search_web(query: str) -> str: """执行一次网络搜索，获取关于旅行目的地、景点、美食等的实时信息。""" # 这里为演示，我们模拟返回固定结果。真实情况应调用搜索引擎API。 mock_data = { "上海迪士尼": "上海迪士尼乐园是中国内地首座迪士尼主题乐园，拥有七大主题园区。门票平日价约399元，周末及节假日约599元。", "外滩": "外滩是上海的历史文化街区，以52幢风格迥异的古典复兴大楼群闻名，是观赏黄浦江景和陆家嘴天际线的绝佳地点。免费开放。", "豫园": "豫园是位于上海老城厢的江南古典园林，始建于明代。园内亭台楼阁、假山水榭布局精巧。门票约40元。" } for key, value in mock_data.items(): if key in query: return f"搜索 '{query}' 的结果：{value}" return f"未找到关于 '{query}' 的详细信息。" # 工具2: 获取天气（模拟） @tool def get_weather(city: str, date: str = "today") -> str: """获取指定城市在特定日期的天气预报。date可以是'today', 'tomorrow'或具体的日期字符串。""" weather_mock = { "上海": {"today": "晴转多云，气温15-22°C，东南风2-3级。", "tomorrow": "多云，气温16-24°C，微风。"}, "北京": {"today": "晴，气温5-18°C，西北风3-4级。", "tomorrow": "晴，气温7-20°C，微风。"} } city_data = weather_mock.get(city, {}) forecast = city_data.get(date, "暂无该日期的天气预报信息。") return f"{city}{date}的天气：{forecast}" # 工具3: 简单计算器 @tool def calculator(expression: str) -> str: """执行一个数学计算表达式并返回结果。例如：'300 * 2 + 500'""" try: # 警告：实际使用中，直接eval有安全风险，此处仅作演示。 # 生产环境应使用更安全的计算库，如`numexpr`或`ast.literal_eval`处理简单算术。 result = eval(expression) return f"计算结果：{expression} = {result}" except Exception as e: return f"计算表达式 '{expression}' 时出错：{e}" # 将工具包装成列表 tools = [search_web, get_weather, calculator]

注意：上面的工具实现是高度简化的模拟。在生产环境中，search_web应接入可靠的搜索引擎API（如SerpAPI、Google Custom Search），get_weather应接入气象服务API，而calculator应避免使用eval，改用安全的数学表达式解析库。这里为了演示的清晰和可运行性，使用了模拟数据。

3.2 构建ReAct智能体与提示工程

接下来，我们需要初始化LLM，并利用LangChain的create_react_agent函数来构建Agent。这个函数的核心是为LLM准备一个特殊的“系统提示词”（System Prompt），这个提示词会指导LLM按照ReAct的格式进行输出。

from langchain import hub from langchain.agents import create_react_agent, AgentExecutor # 1. 初始化LLM。这里使用OpenAI的GPT-3.5-turbo，你需要设置自己的OPENAI_API_KEY。 # 你也可以替换为其他LangChain支持的模型，如ChatAnthropic（Claude）、ChatGroq（Llama）等。 llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0) # 2. 获取ReAct提示模板。LangChain Hub上维护了一个标准的ReAct提示词。 # 这个提示词详细规定了LLM的输出格式，例如以“Thought:”、“Action:”、“Action Input:”为前缀。 prompt = hub.pull("hwchase17/react") # 3. 创建ReAct Agent。它将LLM、工具和提示词绑定在一起。 agent = create_react_agent(llm, tools, prompt) # 4. 创建代理执行器（Agent Executor）。它负责运行循环：解析LLM输出 -> 执行工具 -> 返回观察 -> 继续。 agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True, max_iterations=5)

关键点解析：

• temperature=0：设置为0可以使模型的输出更确定、更稳定，这对于需要精确解析“Action”的Agent任务非常重要。
• verbose=True：开启后，执行器会打印出每一步的“Thought”、“Action”、“Observation”，方便我们调试和观察Agent的思考过程。
• handle_parsing_errors=True：当LLM的输出不符合预期格式，无法解析出Action时，这个选项可以让执行器尝试修复或给出友好错误，而不是直接崩溃。
• max_iterations=5：设置安全阀，防止Agent在某些问题上陷入无限循环。根据任务复杂度调整。

3.3 运行与调试：观察智能体的思考轨迹

现在，让我们运行这个旅行规划助手，并向它提出一个稍微复杂的请求。

# 向Agent提问 question = "我计划周末去上海玩两天，预算大概1500元。请帮我看看有什么推荐景点，并考虑一下天气因素。" result = agent_executor.invoke({"input": question}) print("\n--- 最终答案 ---") print(result["output"])

当verbose=True时，你会在控制台看到类似下面的输出。这正是ReAct模式的精髓所在，让我们能窥见AI的“思考”过程：

> Entering new AgentExecutor chain... Thought: 用户想规划一个上海周末游，预算1500元。我需要考虑景点推荐和天气。首先，我应该搜索上海周末值得去的景点。 Action: search_web Action Input: 上海周末推荐景点 Observation: 搜索 '上海周末推荐景点' 的结果：上海迪士尼乐园是中国内地首座迪士尼主题乐园，拥有七大主题园区。门票平日价约399元，周末及节假日约599元。外滩是上海的历史文化街区，以52幢风格迥异的古典复兴大楼群闻名，是观赏黄浦江景和陆家嘴天际线的绝佳地点。免费开放。豫园是位于上海老城厢的江南古典园林，始建于明代。园内亭台楼阁、假山水榭布局精巧。门票约40元。 Thought: 我得到了几个景点：迪士尼、外滩、豫园。迪士尼门票较贵（周末约599元），外滩免费，豫园便宜（40元）。用户预算1500元，需要玩两天，所以得考虑住宿、交通和餐饮。天气也很重要，需要查询上海周末的天气来决定穿什么和是否适合户外活动。 Action: get_weather Action Input: {"city": "上海", "date": "tomorrow"} Observation: 上海tomorrow的天气：多云，气温16-24°C，微风。 Thought: 明天天气不错，多云，温度适宜。那么后天呢？用户说是周末玩两天。 Action: get_weather Action Input: {"city": "上海", "date": "today"} # 注意：这里模型可能对“后天”的日期处理有误，它错误地查询了“today”。实际项目中需要更智能的日期解析工具。 Observation: 上海today的天气：晴转多云，气温15-22°C，东南风2-3级。 Thought: 看起来周末两天天气都挺好。现在来规划行程和预算。假设第一天去迪士尼（599元），第二天上午去豫园（40元），下午去外滩（免费）。需要估算住宿和餐饮。让我计算一下大致花费。 Action: calculator Action Input: 599 + 40 + 200*2 + 150*2 # 景点门票 + 两晚住宿（假设200/晚） + 两天餐饮（假设150/天） Observation: 计算结果：599 + 40 + 200*2 + 150*2 = 1339 Thought: 总花费大约1339元，在1500元预算内。我可以给出建议了。 Final Answer: 根据您的1500元预算和上海周末的天气情况，为您规划一个两日游方案： **第一天（周六，天气多云，16-24°C）：** * **上午/全天：上海迪士尼乐园**。周末门票约599元。天气舒适，适合户外游乐。建议早点出发。 * **晚上：** 选择迪士尼附近或市区的经济型酒店，约200元/晚。 **第二天（周日，天气晴转多云，15-22°C）：** * **上午：豫园**。体验江南古典园林，门票约40元。 * **下午：外滩**。欣赏历史建筑群和陆家嘴天际线，免费。天气晴朗，非常适合散步和拍照。 * **晚上：** 返回，住宿约200元。 **预算估算：** * 门票：迪士尼599 + 豫园40 = 639元 * 住宿：200元/晚 * 2晚 = 400元 * 餐饮：150元/天 * 2天 = 300元 * **总计：约1339元**，在您的1500元预算内。 **温馨提示：** 以上为大致估算，实际费用可能因具体选择浮动。周末迪士尼人流较多，建议提前购票。根据天气，穿着轻便衣物并备一件外套即可。

通过这个详细的输出，我们可以清晰地看到Agent的完整推理链：

1. 思考1：识别任务核心（景点、天气、预算），决定先搜索景点。
2. 行动1：调用search_web工具。
3. 观察1：获得景点信息。
4. 思考2：根据景点信息，意识到需要天气和预算规划，决定先查天气。
5. 行动2：调用get_weather工具（这里出现了一次对日期理解的小偏差，查询了“明天”和“今天”，而非“后天”）。
6. 观察2/3：获得天气信息。
7. 思考3：综合信息，开始进行预算计算。
8. 行动3：调用calculator工具。
9. 观察4：获得计算结果。
10. 思考4：判断信息已齐全，可以生成最终答案。

这个轨迹不仅证明了ReAct的有效性，也为我们后续的调试和优化提供了宝贵的依据。

4. 实战中的核心挑战与优化策略

搭建一个能跑的ReAct Agent只是第一步。要让它在生产环境中稳定、可靠、高效地工作，会遇到一系列挑战。下面是我在多个项目中总结出的核心问题和解决方案。

4.1 工具设计的艺术：如何让LLM“用好”工具

工具是Agent的手脚，设计不当会导致Agent无法有效工作。

• 挑战1：工具描述模糊。如果工具的描述（description）太简略，LLM可能无法准确理解何时该调用它。
  • 优化策略：为每个工具编写清晰、具体的描述，最好包含使用场景示例。例如，get_weather的描述可以写成：“获取指定城市未来三天的天气预报。输入应为包含‘city’（城市名，如‘北京’）和‘date’（可选，默认为‘today’，可以是‘tomorrow’或‘2024-05-20’格式）的JSON字符串或自然语言。”
• 挑战2：工具过多导致混淆。当工具数量超过10个时，LLM可能难以准确选择。
  • 优化策略：
    1. 工具分类：将功能相近的工具分组，在提示词中说明类别。
    2. 动态工具选择：并非每次都将所有工具暴露给Agent。可以根据用户问题的意图，先通过一个分类器（另一个LLM调用或规则）筛选出最相关的3-5个工具，再进行ReAct循环。
    3. 使用更强大的模型：GPT-4在工具选择上的准确性通常远高于GPT-3.5。
• 挑战3：工具输出格式混乱。工具返回的观察结果如果过于冗长或包含无关信息，会干扰LLM的后续思考。
  • 优化策略：对工具的返回结果进行“后处理”。提取关键信息，过滤掉广告、错误代码等噪音，并以简洁、结构化的文本格式返回给LLM。

4.2 解析与错误处理：构建鲁棒的执行循环

LLM的输出是非结构化的自然语言，解析失败是家常便饭。

• 挑战1：输出格式偏离。LLM可能不严格按照“Action: tool_name\nAction Input: args”的格式输出，可能会添加额外解释。
  • 解决方案：
    1. 强化提示（Prompt Reinforcement）：在系统提示词中多次强调输出格式，并使用“你必须严格按照以下格式输出”等强约束语句。在few-shot示例中提供完美的格式样板。
    2. 使用更鲁棒的解析器：除了简单的正则表达式，可以使用基于语法（如自定义的Pydantic模型）的解析器，或者利用LLM本身进行二次解析（输出解析）。LangChain的OutputFixingParser和RetryOutputParser就是干这个的，它们能在解析失败时，自动尝试让LLM修正自己的输出。
• 挑战2：工具执行异常。工具调用可能因为网络、参数错误等原因失败。
  • 解决方案：在执行器层进行完善的异常捕获。当工具调用失败时，不要直接抛出错误导致Agent崩溃，而是将友好的错误信息（如“网络请求超时，请稍后再试”或“参数‘city’不能为空”）作为“Observation”返回给LLM。LLM在下一轮思考中，可能会尝试重试或调整参数。

4.3 记忆与上下文管理：应对长对话与复杂任务

ReAct的每一步都会在对话历史中追加Thought、Action、Observation，上下文长度会快速增长。

• 挑战：上下文窗口限制与信息冗余。当任务步骤很多时，可能会超过LLM的上下文长度。同时，早期的、不相关的步骤会干扰后续决策。
  • 优化策略：
    1. 摘要式记忆（Summarization Memory）：定期（例如每5步）或当上下文达到一定长度时，用一个单独的LLM调用对之前的对话历史进行摘要，然后用摘要替换掉冗长的原始历史，再继续后续步骤。这能显著节省token。
    2. 向量存储记忆（VectorStore Memory）：将每一步的Observation等关键信息存入向量数据库（如Chroma、Pinecone）。当Agent需要回忆某个信息时，通过语义搜索从向量库中检索最相关的片段，而不是把所有历史都塞进上下文。这非常适合需要长期记忆和知识回溯的Agent。
    3. 对话窗口记忆（ConversationBufferWindowMemory）：只保留最近K轮（比如最近10轮）的对话历史，丢弃更早的。这对于短期、聚焦的任务很有效。

4.4 停止策略与防死循环：为智能体装上安全阀

Agent可能会在某些问题上陷入无意义的循环，或者迟迟不输出最终答案。

• 挑战：无限循环与无效动作。例如，Agent可能反复查询同一个天气而无法推进。
  • 解决方案：实施多层停止策略。
    1. 最大迭代次数（Max Iterations）：这是最基本的防线，如我们之前设置的max_iterations=5。
    2. 早期停止（Early Stopping）：监控Agent的行为。如果连续多次Action相同或相似，且Observation没有带来新的信息，可以主动中断循环，并让Agent总结当前已知信息给出一个“尽力而为”的答案。
    3. 超时控制（Timeout）：为整个Agent运行或单个工具调用设置时间限制。

5. 高级模式与框架选型指南

基础的ReAct循环已经能解决很多问题，但对于更复杂的场景，我们需要更高级的模式或直接选用成熟的框架。

5.1 规划-执行-反思（Plan-and-Execute）模式

这是ReAct的一种进阶模式。在真正的“思考-行动”循环开始前，先让LLM做一个高层级的任务分解规划。

用户请求： “帮我写一份关于新能源汽车行业的研究报告，并做成PPT。”

1. 规划阶段：LLM先输出一个高层计划。

   计划： 1. 搜索并收集近三年中国新能源汽车的销量数据、政策动态、主要厂商信息。 2. 分析行业发展趋势、技术瓶颈（如电池）和市场机遇。 3. 整理关键数据和观点，设计PPT大纲。 4. 根据大纲，分章节撰写报告内容。 5. 将报告内容转换为PPT幻灯片格式。

2. 执行阶段：Agent再根据这个计划，逐步调用工具（搜索、数据分析、文档生成等）去完成每一个子任务。

这种模式让Agent在面对宏大、模糊的任务时，能有更清晰的“路线图”，避免在细节中迷失方向。LangChain的PlanAndExecute执行器就实现了这一模式。

5.2 主流Agent开发框架对比

除了LangChain，市面上还有其他优秀的Agent框架，各有侧重。

选型建议：

• 新手入门或全栈项目：首选LangChain。它的通用性最强，社区支持最好，遇到问题容易找到解决方案。
• 核心是处理公司内部文档/数据：重点考察LlamaIndex。
• 需要模拟团队协作或复杂对话流程：深入研究AutoGen。
• 技术栈以微软生态为主：考虑Semantic Kernel。

5.3 性能优化与成本控制

Agent应用可能会频繁调用LLM和外部API，成本和延迟是需要严肃考虑的问题。

• 优化策略1：缓存（Caching）。对LLM的相同提示词调用结果进行缓存。例如，使用LangChain的InMemoryCache或SQLiteCache。对于工具调用，如果结果不要求绝对实时（如某些百科知识），也可以实施缓存。
• 优化策略2：小模型协同。并非每一步都需要最强的GPT-4。可以用GPT-3.5-turbo或更小的开源模型（如Qwen-7B）来处理简单的工具选择、格式解析等任务，只在关键推理步骤使用大模型。这种“大小模型混合”的策略能显著降低成本。
• 优化策略3：异步与流式处理。如果Agent的多个步骤之间没有强依赖，可以考虑异步执行。对于需要长时间运行的任务，向用户提供流式（Streaming）的中间思考过程，可以极大提升用户体验。

6. 避坑指南与最佳实践

结合我过去一年多的Agent开发经验，以下是一些“血泪教训”总结出的最佳实践：

1. 从简单开始，逐步复杂化：不要一开始就设计一个拥有20个工具的万能Agent。从一个明确的任务（如“查询天气并建议穿衣”）和2-3个核心工具开始。验证ReAct循环能跑通后，再逐步添加工具和复杂度。
2. 精心设计工具的“人机接口”：把工具想象成给LLM使用的API。它的名称要直观（如calculate_budget优于tool_3），描述要像产品说明书一样准确，参数要简单明了。好的工具设计能极大降低提示工程的难度。
3. 实施全面的日志记录：务必记录下每一次Agent运行的完整轨迹（Trace），包括每一轮的Thought、Action、Observation。这是你调试Agent、理解其失败原因、优化提示词的最宝贵资料。可以考虑使用像LangSmith这样的可视化平台来监控和分析。
4. 为不确定性设计：LLM是概率模型，输出具有不确定性。你的Agent系统必须能处理这种不确定性。这意味着要有完善的错误处理、重试机制和降级方案（例如，当Agent连续失败时，转接到人工客服或提供一个简化的备选方案）。
5. 安全与合规前置：Agent能自主调用工具，这带来了新的风险。
   • 工具权限控制：严格限制每个工具能访问的数据和能执行的操作。例如，一个处理用户邮件的Agent，不应该有删除所有邮件的权限。
   • 输入输出过滤：对用户输入和工具返回的内容进行安全检查，防止提示词注入（Prompt Injection）或返回有害内容。
   • 人工审核环节：对于高风险操作（如发送邮件、执行支付），设计“人工确认”环节，让Agent在执行前先征求用户或管理员的明确同意。

ReAct模式为AI Agent注入了真正的“行动力”，使其从理论走向实践。它不再是一个停留在对话界面的聊天机器人，而是一个可以主动调研、分析、执行并完成复杂工作流的智能助手。掌握ReAct，你就拿到了构建下一代AI应用的关键钥匙。