基于ReAct框架的AI智能体：如何让LLM通过Google搜索获取实时信息

1. 项目概述当AI学会“上网冲浪”最近在折腾一个挺有意思的东西我把它叫做“AI的浏览器”。听起来有点科幻但核心逻辑很简单我们如何让一个大型语言模型LLM不再仅仅依赖它训练时“记住”的知识库而是能像人一样打开浏览器输入关键词浏览网页然后从最新的、实时的信息中提取答案这就是web-agent-master/google-search这个项目标题背后所指向的核心领域——AI智能体AI Agent的网页交互与信息获取。具体来说它解决了一个非常实际的痛点LLM的知识存在“截止日期”。你问它今天某支股票的价格或者某个刚刚发布会的产品细节它很可能给不出准确答案或者干脆开始“胡言乱语”。这个项目的目标就是为LLM装上“眼睛”和“手”让它能自主执行“搜索 - 访问 - 解析 - 总结”这一系列操作从而获取实时信息。这不仅仅是做一个搜索引擎的API封装而是构建一个能理解任务、规划步骤、操作浏览器、并最终完成目标的自主智能体。它适合谁呢如果你是一名开发者想为你的AI应用增加实时信息查询能力或者你是一名研究者对AI智能体的规划与执行Planning and Acting感兴趣亦或是你单纯想体验一下让AI帮你自动完成一些网页调研工作那么这个项目及其背后的技术栈都值得你深入了解一下。接下来我将以一个实践者的角度拆解从零构建这样一个Web Agent的核心思路、技术选型、实操细节以及我踩过的那些坑。2. 核心架构与设计思路拆解要构建一个能使用Google搜索的Web Agent我们不能把它想成一个简单的脚本。它需要具备感知、决策、执行和学习的闭环能力。整个系统的设计可以抽象为以下几个核心层次。2.1 智能体范式ReAct框架的实践当前让AI智能体与工具交互最有效的范式之一是ReAct (Reasoning Acting)。这个框架的核心思想是让模型在“思考”和“行动”之间交替进行。思考Reason模型分析当前情况、历史记录和任务目标决定下一步该做什么。例如“用户想知道OpenAI最新模型的信息。我需要先搜索关键词‘OpenAI latest model 2024’。”行动Act模型调用一个具体的工具Tool来执行决策。例如调用google_search工具并传入上一步决定的关键词。观察Observe获取行动的结果如搜索结果的HTML页面并将其作为新的上下文输入。循环重复1-3步直到任务完成或达到步骤限制。在web-agent-master的上下文中google-search很可能就是其中一个最核心的“行动”工具。但一个完整的Agent远不止于此它还需要网页解析、点击、滚动、表单填写等更多工具。2.2 技术栈选型为什么是它们构建这样一个系统技术选型至关重要。以下是一个经过实战检验的搭配方案核心大脑LLMOpenAI GPT-4系列或Claude 3系列。这是智能体“思考”能力的来源。选择它们的理由很直接在复杂推理、长上下文理解和遵循指令方面它们目前是第一梯队。对于轻量级或对成本敏感的场景GPT-3.5-Turbo或开源的Llama 3 70B通过API也是不错的选择但复杂任务上的规划能力会打折扣。浏览器自动化手和眼Playwright或Selenium。这是智能体与网页交互的“肢体”。我更倾向于Playwright。原因如下它对现代Web应用单页应用SPA的支持更好API设计更现代、一致自动等待机制auto-waiting能极大减少“元素未加载”导致的错误而且它原生支持无头Headless模式适合服务器端部署。Selenium更老牌、生态庞大但在处理动态内容时有时需要更多显式等待代码。网页内容解析理解眼睛看到的东西BeautifulSoup4或lxml。从Playwright抓取到的HTML字符串中我们需要提取出干净的文本、链接、按钮文字等信息去除广告、导航栏等噪音再喂给LLM。BeautifulSoup4语法简单适合快速开发lxml解析速度更快适合处理大量页面。通常BeautifulSoup4的易用性使其成为首选。工具调用与编排框架LangChain或LlamaIndex。这两个框架极大地简化了将LLM、工具、记忆Memory组合成智能体的过程。它们提供了标准的Tool接口、智能体执行器Agent Executor以及记忆管理。LangChain的生态更庞大工具和链Chain的种类更多LlamaIndex在数据连接和检索方面有独特优势。对于Web Agent两者都能胜任LangChain的社区示例可能更丰富一些。外围支撑Python作为主语言Docker用于环境封装确保Playwright的浏览器依赖一致Redis或SQLite用于存储会话历史记忆。这个技术栈的组合形成了一个从“思考”到“操作”再到“反馈”的完整管道。2.3 系统工作流设计一个完整的“使用Google搜索并获取答案”的任务其内部工作流可能如下用户提问 - LLM规划 - 调用搜索工具 - 获取搜索结果列表 - LLM选择链接 - 调用浏览工具 - 获取页面内容 - 解析净化内容 - LLM总结答案 - 返回给用户这其中google-search模块主要负责的是“调用搜索工具 - 获取搜索结果列表”这一步。但它必须被无缝地集成到更大的工具调用循环中。3. 核心模块Google搜索工具的实现细节现在我们聚焦于标题中的google-search模块。实现一个稳定、可靠、且符合伦理的搜索工具需要注意以下几个层面。3.1 搜索API的选择与避坑直接让Playwright模拟人工打开google.com输入关键词技术上可行但存在巨大风险极易触发Google的反爬虫机制导致IP被临时封锁或要求进行验证码验证。这对于需要稳定服务的Agent来说是致命的。因此更可靠的做法是使用官方或第三方的搜索API。这里有几个选项Google Custom Search JSON API这是Google官方提供的。你需要去Google Cloud Console创建一个项目启用这个API并获取一个API密钥。同时你需要创建一个“可编程搜索引擎”并获取其搜索引擎IDCX。这个方法的优点是稳定、合规。缺点是免费额度有限每天100次搜索超出后需要付费并且需要配置CX有时搜索结果和直接访问google.com略有不同。SerpAPI / Serply等第三方服务这些服务商帮你处理了反爬虫等问题提供一个简单的HTTP API接口。你付费购买搜索次数。优点是省心不用处理IP轮换、验证码破解等脏活。缺点是会产生持续的费用。Bing Web Search API作为备选微软的API也是一个稳定可靠的选择。在web-agent-master这类项目中为了演示和原型开发可能会先使用模拟或简易方法。但对于生产环境强烈建议使用方案1或2。下面以Google Custom Search API为例展示核心代码片段import requests class GoogleSearchTool: def __init__(self, api_key, cse_id): self.api_key api_key self.cse_id cse_id self.base_url https://www.googleapis.com/customsearch/v1 def search(self, query, num_results5): 执行搜索返回格式化后的结果列表。 params { key: self.api_key, cx: self.cse_id, q: query, num: num_results } try: response requests.get(self.base_url, paramsparams) response.raise_for_status() # 检查HTTP错误 data response.json() except requests.exceptions.RequestException as e: return f搜索请求失败: {e} except ValueError as e: return f解析JSON响应失败: {e} # 格式化结果供LLM阅读 formatted_results [] if items in data: for item in data[items]: result { title: item.get(title, No Title), link: item.get(link, #), snippet: item.get(snippet, No Snippet) } formatted_results.append(result) else: return 未找到相关结果。 # 将结果格式化成清晰的文本 result_text 以下是搜索结果\n for i, res in enumerate(formatted_results, 1): result_text f{i}. [{res[title]}]({res[link]})\n result_text f 摘要: {res[snippet]}\n\n return result_text注意将API密钥和CX ID硬编码在代码中是极不安全的。务必使用环境变量如os.getenv(GOOGLE_API_KEY)或密钥管理服务来配置。3.2 与智能体框架的集成以LangChain为例我们需要将上面的搜索工具包装成LangChain的Tool对象这样智能体执行器才能识别和调用它。from langchain.tools import Tool from langchain.agents import AgentExecutor, create_react_agent from langchain.prompts import PromptTemplate # 假设我们已经有了一个初始化好的LLM叫做 llm # 1. 实例化我们的搜索工具类 search_tool_instance GoogleSearchTool(api_key“YOUR_API_KEY”, cse_id“YOUR_CX_ID”) # 2. 定义工具函数 def google_search_func(query: str) - str: 一个用于执行Google搜索的工具。输入应为具体的搜索查询字符串。 return search_tool_instance.search(query, num_results3) # 3. 包装成LangChain Tool对象 search_tool Tool( nameGoogleSearch, funcgoogle_search_func, description当您需要回答有关当前事件或获取最新信息的问题时非常有用。输入应该是一个具体的搜索查询。 ) # 4. 创建智能体 tools [search_tool] # 你可以在这里加入更多工具如 BrowserTool, CalculatorTool等 prompt PromptTemplate.from_template(...) # 这里需要定义ReAct风格的提示模板 agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 5. 运行智能体 result agent_executor.invoke({input: OpenAI最近发布了什么新模型有什么特点}) print(result[output])关键点在于description的描述它相当于给LLM的“工具说明书”。描述必须清晰准确告诉LLM这个工具是干什么的、什么时候用、输入应该是什么格式。这直接决定了智能体调用工具的准确性。3.3 结果后处理与上下文管理搜索工具返回的可能是10个结果但LLM的上下文窗口是有限的。我们不能把全部原始HTML或冗长的摘要都塞进去。需要做后处理结果精炼只提取标题、链接、核心摘要并严格控制返回文本的长度。相关性过滤可以尝试让LLM对初步结果进行一轮快速筛选只保留最相关的3-5条链接进行后续深入浏览。分页与记忆对于复杂查询智能体可能需要多轮搜索如“搜索A然后根据结果B再搜索C”。这就需要良好的记忆Memory机制记录之前的搜索历史和结果避免重复或陷入循环。4. 超越搜索构建完整网页交互能力一个只会搜索的Agent能力是有限的。真正的Web Agent需要能浏览网页、提取信息、甚至进行交互。这就需要引入更强大的“浏览工具”。4.1 使用Playwright实现网页浏览与解析我们可以创建一个BrowserTool它接收一个URL或一个动作指令如“点击登录按钮”然后使用Playwright执行。from playwright.sync_api import sync_playwright from bs4 import BeautifulSoup import json class BrowserTool: def __init__(self): self.playwright sync_playwright().start() # 使用Chromium可配置为无头模式 self.browser self.playwright.chromium.launch(headlessTrue) self.context self.browser.new_context() self.page self.context.new_page() def browse_page(self, url: str) - str: 访问给定URL并返回页面主要内容文本。 try: self.page.goto(url, wait_untilnetworkidle) # 等待页面加载完成 # 获取页面HTML html_content self.page.content() # 使用BeautifulSoup解析并提取正文文本 soup BeautifulSoup(html_content, html.parser) # 移除脚本、样式等标签 for script in soup([script, style, nav, header, footer]): script.decompose() text soup.get_text(separator\n, stripTrue) # 限制返回长度避免上下文爆炸 return text[:5000] # 只返回前5000个字符 except Exception as e: return f访问页面 {url} 时出错: {e} def close(self): self.browser.close() self.playwright.stop() # 同样需要将这个工具包装成LangChain Tool4.2 让智能体学会“点击”与“导航”更高级的Agent需要理解页面结构并执行交互。这可以通过以下方式实现增强观察不仅返回文本还返回页面上所有可交互元素按钮、链接、输入框的列表及其定位信息如button idsubmit登录/button。让LLM决策将页面摘要和元素列表一起交给LLM让它决定下一步点击哪个元素或输入什么文本。执行动作根据LLM的指令Playwright执行对应的click()或fill()操作。这部分实现起来复杂得多涉及到对页面结构的语义理解是当前Web Agent研究的前沿。一个简化版思路是让LLM根据元素文本描述来选择例如“请点击‘下一页’按钮”。5. 实操部署与性能优化心得将原型部署为可持续运行的服务会遇到一系列工程挑战。5.1 环境封装与依赖管理Playwright需要安装特定的浏览器驱动。使用Docker是保证环境一致性的最佳实践。# Dockerfile 示例 FROM python:3.11-slim RUN apt-get update apt-get install -y \ wget \ gnupg \ unzip \ rm -rf /var/lib/apt/lists/* # 安装Playwright及其依赖 RUN pip install playwright playwright install chromium --with-deps WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD [python, app.py]在requirements.txt中列明所有Python依赖langchain, openai, playwright, beautifulsoup4, requests等。5.2 错误处理与鲁棒性增强Web环境极不稳定必须做好全面的错误处理网络超时与重试对任何网络请求搜索API、页面访问添加超时和指数退避重试机制。反爬虫应对如果使用非API的直接爬取方式不推荐需要准备IP池、User-Agent轮换和验证码识别备用方案。使用官方API是避免此问题的最佳途径。页面加载不确定性Playwright的wait_until参数非常关键。“networkidle”网络空闲比“load”DOM加载更可靠但对于某些SPA可能需要结合wait_for_selector来等待特定元素出现。LLM输出解析错误LangChain的AgentExecutor设置了handle_parsing_errorsTrue但最好还能有fallback机制比如当LLM输出无法解析为工具调用时用更明确的提示让其重试。5.3 成本与性能优化LLM调用成本这是主要成本。优化方法包括缓存对相同的搜索查询和URL内容进行缓存避免重复调用LLM总结。压缩上下文在将网页内容喂给LLM前先用更小的模型或启发式规则进行摘要提取只保留核心段落。设定预算为每个会话或每个任务设定最大的LLM调用次数max_iterations和Token数限制。执行速度Playwright启动浏览器较慢。解决方案是使用浏览器上下文持久化或者使用Playwright的connect_over_cdp连接到一个已经运行在后台的浏览器实例而不是每次任务都启动关闭。6. 常见问题与排查实录在开发过程中我遇到了不少典型问题这里记录下排查思路。6.1 智能体陷入循环或重复搜索现象Agent不停地使用相同关键词搜索或者在不同工具间来回切换却不推进任务。原因通常是提示词Prompt中对于任务终止的条件描述不清晰或者LLM未能从观察结果中提取出足够的信息来做出新决策。解决在Prompt中明确写出“当你认为已经从结果中找到足够信息来回答用户问题时请直接给出最终答案并停止使用工具。”改进工具返回的观察结果格式使其更结构化、信息密度更高便于LLM理解。在AgentExecutor中设置较低的max_iterations如10强制终止可能出现的死循环。6.2 网页内容解析质量差干扰LLM判断现象从网页提取的文本包含大量无关内容导航菜单、广告、评论、页脚链接导致LLM总结出错或效率低下。原因简单的BeautifulSoup.get_text()会保留所有文本。解决使用专门的正文提取库如trafilatura、readability-lxml或newspaper3k。这些库经过训练能更好地识别新闻文章或博客的主体内容。基于DOM路径的启发式规则统计文本密度、链接密度或寻找包含特定标签如article、main的区域。让LLM辅助清洗先将粗略提取的文本交给LLM指令为“请从以下网页内容中提取出与‘[主题]’最相关的核心段落”。这虽然增加了一次LLM调用但能显著提升后续总结步骤的质量。6.3 Google Search API返回结果不理想现象搜索到的结果与直接在Google网页上搜索的结果相关性有差异。原因Custom Search Engine (CSE) 的配置会影响结果。新创建的CSE可能索引的网页范围有限。解决在Google CSE控制台将“搜索整个网络”选项打开。调整CSE的设置关闭“安全搜索”过滤器如果适用。在代码中尝试调整API参数如sort排序、dateRestrict时间限制等以优化结果。作为备选可以将SerpAPI作为后备搜索源当CSE结果不佳时切换使用。6.4 Playwright操作元素失败现象代码试图点击一个按钮或填写表单但报错“Element not found”或“Element is not visible”。原因页面动态加载元素尚未出现或元素位于iframe内或元素被其他元素遮挡。解决使用更稳健的选择器优先使用page.get_by_role()、page.get_by_text()或page.get_by_test_id()等语义化定位方式而非脆弱的XPath或CSS选择器。显式等待在操作前使用page.wait_for_selector()或page.wait_for_function()确保元素就绪。处理iframe使用page.frame_locator()来定位iframe内部的元素。增加超时和重试在操作外围包裹重试逻辑。构建一个成熟的Web Agent是一个系统工程从核心的搜索工具到完整的浏览、推理、规划能力每一步都需要精心设计和反复调试。web-agent-master/google-search这个标题为我们打开了一扇门门后是一个让AI真正连接实时世界的、充满挑战与乐趣的领域。从实现一个简单的搜索工具开始逐步扩展其能力你会发现让AI学会“上网”不仅仅是调用几个API更是在构建一个能够自主感知、思考和行动的智能伙伴的雏形。在这个过程中对LLM能力的理解、对Web技术的掌握以及对系统稳定性的追求缺一不可。