从 0 到 1 搭建一个会“上网”的 Agent：Searching Tool 的实现原理

Java大师兄学大数据AI应用开发

233人浏览 · 2026-06-08 02:23:04

Java大师兄学大数据AI应用开发 · 2026-06-08 02:23:04 发布

从 0 到 1 搭建一个会“上网”的 Agent：Searching Tool 的实现原理

1. 引入与连接：你有没有被大模型的「知识 cutoff」坑过？

相信你一定有过这样的经历：拿着2024年巴黎奥运会的奖牌榜问题问ChatGPT，它却一本正经告诉你「我的知识截止到2023年10月，无法回答2024年的事件」；或者你问最近新上线的AI框架性能如何，它给你的还是2年前的过时信息；甚至你问某款刚发布的手机参数，它能凭空编出一堆不存在的配置——这就是大模型的天生缺陷：静态知识 cutoff + 幻觉。

而当你用New Bing、Perplexity AI这类产品时，却发现它们总能给出最新的信息，还会附上信息来源的链接，出错概率大大降低。这背后的核心能力，就是Agent的「联网工具」（Searching Tool）：它就像给大模型装了一双能实时浏览互联网的眼睛，不知道的信息随时搜索，彻底打破知识截止时间的限制，还能通过溯源降低幻觉。

读完这篇文章，你不仅能彻底搞懂Searching Tool的底层实现原理，还能亲手从0到1搭建一个完全属于自己的联网Agent：不需要依赖OpenAI的付费插件，甚至可以对接企业内部知识库、私有爬虫系统，实现专属的信息检索能力。我们的学习路径如下：

先搞懂所有核心概念的关联，建立整体认知框架
逐层拆解Searching Tool的每一个环节的技术原理
动手写代码实现完整的Searching Tool Pipeline
了解行业最佳实践和未来发展方向

2. 概念地图：Searching Tool 相关知识体系

2.1 核心术语定义

术语	通俗解释	专业定义
Agent	会自己调用工具完成任务的AI助理	具备感知、决策、行动能力的自主智能体，可通过调用外部工具拓展能力边界
Tool Calling	AI助理的「用工具能力」	大模型经过微调后可输出符合固定格式的工具调用指令，自动触发外部工具执行
Searching Tool	AI助理的「浏览器」	Agent体系中专门负责信息检索的工具，可获取公网/私有域的实时信息
SERP	搜索结果页	Search Engine Results Page，搜索引擎返回的搜索结果列表
RAG	检索增强生成	将检索到的外部知识注入大模型上下文，提升回答准确性的技术方案
BM25	传统全文检索的核心排序算法	基于词频和逆文档频率计算文档与查询相关性的概率排序算法
向量检索	语义级搜索方案	将文本转化为向量后通过计算语义相似度匹配相关内容的检索方式

2.2 概念关系架构图

2.3 Searching Tool 核心边界

我们首先要明确Searching Tool的适用和不适用场景，避免不必要的性能浪费：
✅ 适用场景：

需要实时/最新信息的查询（如赛事结果、新品发布、政策更新）
大模型知识 cutoff 之后的事件查询
专属领域/私有域信息查询（如企业内部文档、垂直行业数据）
需要溯源验证的高可信度需求（如医疗咨询、法律条文查询）
❌ 不适用场景：
纯逻辑推理/数学计算类问题（大模型自身即可完成，搜索反而会引入干扰）
已经在大模型知识范围内的常识性问题（搜索会增加响应时间）
涉及敏感隐私的查询（公网搜索会造成数据泄露）

3. 基础理解：Searching Tool 不是「调用搜索API」这么简单

很多人对Searching Tool的第一印象就是：给大模型接个百度/Google API，把搜索结果喂给大模型就完事了。但如果你真的这么做，会发现效果差得离谱：要么搜索结果全是广告，要么是不相关的垃圾信息，要么内容太长把大模型的上下文窗口撑爆，最终输出的答案还是错漏百出。

我们可以用「助理查资料」的生活化类比来理解Searching Tool的完整工作流：

你让助理帮你查「2024年国内大模型公司的营收排名」，合格的助理会怎么做？

先理清楚你要的是什么：是不是要上市企业的公开财报数据？要不要包含非上市公司的预估数据？排名维度是营收还是利润？（Query理解）

选择合适的信息来源：是去查公司财报、券商研报，还是去搜新闻报道？（数据源选择）

筛选搜索结果：把广告、旧闻、明显造假的信息过滤掉，只留权威来源的内容（结果预处理）

提炼核心信息：把每个公司的营收数据从长文中摘出来，整理成清晰的列表（内容摘要）

交叉验证：如果不同来源的数据不一致，要标记差异，优先选择可信度高的来源（结果校验）

整理成报告：把整理好的数据附上来源链接，交给你做决策（结果整合）

Searching Tool的工作逻辑和这个过程完全一致，它是一套包含「Query理解→搜索触发→结果预处理→相关性排序→内容摘要→结果整合」的完整Pipeline，核心目标是给大模型提供高相关、高可信、轻量化的外部信息，从源头上降低幻觉。

3.1 常见误解澄清

误解	真相
搜索结果越多越好	大模型的上下文窗口有限，太多无关内容会稀释有效信息，反而降低回答质量，一般只需返回Top3-5条最相关的结果即可
向量检索比传统检索好	两种方式各有优劣：关键词检索适合匹配精确信息，向量检索适合匹配语义相关信息，混合检索的效果远好于单一方式
必须用Google/Bing的API	你完全可以对接自己的Elasticsearch、私有爬虫系统、内部知识库，实现完全可控的搜索能力
Searching Tool就是RAG	RAG是静态检索（提前把知识库索引好存在本地），Searching Tool是动态检索（实时搜索互联网/动态数据源），两者是互补关系

4. 层层深入：Searching Tool 核心原理拆解

4.1 第一层：基础工作流与运作机制

我们先看Searching Tool的完整工作流程图：

整个流程的每一个环节都直接影响最终效果，我们逐个拆解：

4.1.1 Query理解与搜索触发

这是整个Pipeline的第一个关口，核心要解决两个问题：要不要搜？搜什么？

搜索触发判断：我们可以通过Prompt引导大模型判断用户的问题是否需要搜索，Prompt示例如下：

你是一个智能搜索判断助手，判断用户的问题是否需要搜索外部信息才能回答：
1. 如果问题是常识性问题、逻辑推理问题、知识截止时间2023年10月之前的问题，不需要搜索，返回{"need_search": false}
2. 如果问题需要实时信息、最新事件、专属领域信息，需要搜索，返回{"need_search": true, "query": "优化后的搜索关键词"}
注意：搜索关键词要符合搜索引擎的规则，去掉疑问词，提取核心关键词，不要太长。
用户问题：{{user_question}}

多Query生成：对于复杂问题，单个搜索Query无法覆盖所有信息，需要生成多个Query分别搜索。比如用户问「2024年AI框架的性能对比」，可以拆成「2024年热门AI框架」、「PyTorch 2.1性能数据」、「TensorFlow 2.15性能数据」、「JAX性能对比」多个Query分别搜索。

4.1.2 搜索源对接

常见的搜索源有三类：

公网搜索引擎：DuckDuckGo（免费无API密钥）、Google Custom Search、Bing Search API，适合通用信息查询
垂直搜索引擎：知乎API、ArXiv API、电商平台搜索API，适合垂直领域查询
私有检索系统：Elasticsearch、Milvus向量数据库、企业内部知识库，适合私有数据查询

对于个人开发者来说，优先选择DuckDuckGo，不需要申请API密钥，直接调用即可，非常方便。

4.1.3 结果预处理

搜索引擎返回的SERP往往包含大量低质内容，必须经过预处理才能使用：

去重：去掉重复的链接和内容
去广告：过滤掉明显是广告的结果（比如URL包含ad、promotion等关键词，或者标题带「广告」标识）
正文提取：用Trafilatura、BeautifulSoup等工具提取网页的纯正文内容，去掉导航栏、侧边栏、评论区等无关内容
过滤低质内容：去掉内容长度小于100字的页面、死链、404页面

4.2 第二层：核心排序算法原理

预处理后的内容需要经过相关性排序，把最相关的内容放在前面，过滤掉相关性低于阈值的内容，这一步直接决定了给大模型的信息质量。常用的排序算法有三类，我们可以对比它们的核心属性：

排序算法	准确率	速度	算力要求	适用场景	核心优势	核心劣势
BM25	中	极快	极低	关键词匹配场景、短文本检索	不需要训练、速度快、对精确匹配友好	无法理解语义，同义词匹配效果差
向量相似度	中	快	中	语义匹配场景、长文本检索	能理解语义，同义词/相似表述匹配效果好	对精确关键词匹配效果差，容易出现语义漂移
CrossEncoder重排序	极高	慢	高	最终结果的精排	相关性判断准确率最高	速度慢，算力要求高，不适合大量文本排序

工业界的最佳实践是混合排序：先用BM25和向量相似度做粗排，从成千上万的结果中选出Top100，再用CrossEncoder做精排，选出Top5，兼顾速度和准确率。

4.2.1 BM25算法数学原理

BM25是传统全文检索的核心算法，它的核心思想是：一个词在文档中出现的频率越高，在所有文档中出现的频率越低，这个文档和查询的相关性就越高。公式如下：
$\sum_{i=1}^{n} IDF(q_i) \cdot \frac{f(q_i,D) \cdot (k_1+1)}{f(q_i,D) + k_1 \cdot (1-b + b \cdot \frac{|D|}{avgdl})}$
其中：

$IDF(q_i)$ 是查询词 $q_i$ 的逆文档频率，衡量这个词的稀有程度
$f(q_i,D)$ 是查询词 $q_i$ 在文档 $D$ 中的出现频率
$k_1$ 和 $b$ 是可调参数，一般 $k_1$ 取1.2~2.0， $b$ 取0.75
$∣ D ∣$ 是文档 $D$ 的长度， $a v g d l$ 是所有文档的平均长度

4.2.2 向量相似度排序原理

向量相似度排序是把查询和文档都转化为768维/1024维的向量，然后计算两个向量的余弦相似度，相似度越高相关性越高。余弦相似度公式如下：
$cos(\vec{q}, \vec{d}) = \frac{\vec{q} \cdot \vec{d}}{||\vec{q}|| \cdot ||\vec{d}||}$
其中 $\vec{q}$ 是查询的向量， $\vec{d}$ 是文档的向量，取值范围是[-1,1]，越接近1说明语义越相关。我们常用的Embedding模型有OpenAI的text-embedding-ada-002，或者开源的bge-small-zh、m3e等，效果都很不错。

4.3 第三层：底层逻辑与优化技巧

4.3.1 上下文长度控制

大模型的上下文窗口是有限的，比如GPT-3.5是16K，GPT-4是128K，如果搜索结果太长，会占用大量的token，还会稀释有效信息。我们常用的优化技巧有：

结果摘要：对每个搜索结果的正文做摘要，提炼出和Query相关的核心信息，把每篇文章压缩到300~500字
滑动窗口切片：对于长文档，用200字的滑动窗口切片，步长100字，然后计算每个切片和Query的相似度，只取最相关的Top3切片
动态调整返回结果数量：如果Query比较简单，返回3条结果即可；如果Query比较复杂，最多返回5条结果，总长度控制在大模型上下文窗口的1/3以内。

4.3.2 结果溯源与可信度评估

为了降低幻觉，我们可以给每个搜索结果加上可信度评分和来源链接：

可信度评分：根据来源的权威性打分，比如政府网站、权威媒体、官方网站的可信度打10分，普通新闻网站打7分，论坛博客打5分，未知来源打3分，排序时可信度高的结果优先
引用标记：生成回答时，在对应的内容后面加上[1][2]的上标，最后附上对应的来源链接，方便用户溯源验证。

4.4 第四层：高级应用与拓展

4.4.1 联邦搜索

同时对接多个数据源，比如同时搜公网、企业内部知识库、业务数据库，把所有结果合并排序后返回给大模型，实现内外网信息的统一检索。

4.4.2 多轮搜索

对于复杂问题，一轮搜索无法获得足够信息，可以触发多轮搜索：比如第一轮搜索到2024年热门AI框架有5个，第二轮再分别搜索每个框架的性能数据，第三轮搜索用户对这些框架的评价，最后整合所有信息生成答案。

4.4.3 多模态搜索

除了文本搜索，还可以调用图片、视频搜索接口，把相关的图片、视频内容的描述注入大模型上下文，生成多模态的回答。

5. 多维透视：Searching Tool 的过去、现在与未来

5.1 历史视角：搜索技术的演进历程

年份	里程碑事件	代表产品	核心技术突破
1990	第一个互联网搜索引擎诞生	Archie	人工索引FTP站点的文件列表
1998	现代搜索引擎诞生	Google	PageRank算法，基于链接权威度排序
2010	分布式全文检索普及	Elasticsearch	分布式架构，支持TB级数据的全文检索
2018	语义检索时代开启	BERT	预训练语言模型大幅提升语义理解能力
2022	大模型时代到来	ChatGPT	大模型的自然语言理解能力实现突破
2023	搜索工具成为Agent标配	OpenAI Plugins、New Bing	大模型支持Tool Calling，可自动调用搜索工具
2024	搜索Agent爆发	Perplexity AI、秘塔AI搜索	端到端的搜索Agent产品成熟，月活突破千万

5.2 实践视角：行业典型应用案例

5.2.1 Perplexity AI

Perplexity是当前最火的搜索Agent产品，它的Searching Tool核心逻辑是：

对用户的问题做Query改写，生成多个相关Query
同时调用多个搜索引擎获取结果，提取正文
用混合排序选出最相关的Top5结果
大模型整合结果生成带引用的回答，支持追问和多轮搜索
对于专业领域的问题，还可以对接垂直数据源比如ArXiv、Stack Overflow等。

5.2.2 企业内部知识Agent

很多企业都在搭建内部的知识Agent，对接企业的OA系统、文档库、业务数据库，员工问问题时，Searching Tool优先搜索内部知识库，如果没有结果再搜公网，既提升了效率，又避免了内部数据泄露。

5.3 批判视角：Searching Tool的局限性

响应时延高：一次搜索需要经过调用API、爬取页面、预处理、排序等多个环节，耗时一般在3~10秒，比纯大模型回答慢很多
信息质量不可控：公网搜索结果可能包含虚假信息、广告、SEO污染的内容，即使排序也无法完全过滤
隐私风险：用户的查询内容会发送给第三方搜索引擎，可能造成敏感信息泄露
成本高：调用搜索引擎API、Embedding模型、大模型都需要成本，高频使用的话成本不低

5.4 未来视角：发展趋势

端侧搜索工具：把轻量级的检索模型部署在端侧，不需要调用第三方API，保护隐私，降低延迟
记忆化搜索：Agent具备记忆能力，之前搜索过的内容会存在记忆库中，不需要重复搜索，大幅提升响应速度
主动搜索：Agent会主动判断用户的潜在需求，提前搜索相关信息，比如用户问「去北京旅游的攻略」，Agent会主动搜索最近的天气、机票酒店价格、景点开放时间等信息
多语言跨域搜索：自动把用户的Query翻译成多种语言，搜索全球不同语言的内容，整合后返回给用户

6. 实践转化：从0到1搭建你的Searching Tool

6.1 环境安装

我们用Python实现，需要安装以下依赖：

pip install openai langchain duckduckgo-search trafilatura sentence-transformers rank_bm25

openai：调用大模型做Query理解和回答生成
langchain：简化Tool Calling的实现
duckduckgo-search：免费的公网搜索接口
trafilatura：网页正文提取
sentence-transformers：生成Embedding做向量相似度排序
rank_bm25：BM25排序的实现

6.2 系统架构设计

我们实现的Searching Tool包含以下模块：

Query理解模块：判断是否需要搜索，生成搜索Query
搜索模块：调用DuckDuckGo获取SERP
预处理模块：爬取网页正文，去重去广告
混合排序模块：BM25+向量相似度排序
结果整合模块：把排序后的结果注入大模型上下文，生成带引用的回答

6.3 核心实现代码

6.3.1 工具类初始化

import os
import trafilatura
from duckduckgo_search import DDGS
from sentence_transformers import SentenceTransformer, util
from rank_bm25 import BM25Okapi
import openai
from typing import List, Dict

# 初始化配置
openai.api_key = "你的OpenAI API Key"
embedding_model = SentenceTransformer('moka-ai/m3e-base') # 开源中文Embedding模型

class SearchingTool:
    def __init__(self, top_k: int = 5, max_content_length: int = 3000):
        self.top_k = top_k
        self.max_content_length = max_content_length
    
    # 1. Query理解：判断是否需要搜索，生成搜索Query
    def query_understanding(self, user_question: str) -> Dict:
        prompt = f"""
        你是一个智能搜索判断助手，请判断以下用户问题是否需要搜索外部信息才能回答：
        1. 不需要搜索的场景：常识性问题、逻辑推理问题、2023年10月之前的已知事件
        2. 需要搜索的场景：实时信息、最新事件、2023年10月之后的事件、专属领域信息
        如果不需要搜索，返回：{{"need_search": false, "query": ""}}
        如果需要搜索，返回：{{"need_search": true, "query": "优化后的搜索关键词，去掉疑问词，提取核心，不超过10个字"}}
        用户问题：{user_question}
        只返回JSON，不要其他内容。
        """
        response = openai.ChatCompletion.create(
            model="gpt-3.5-turbo",
            messages=[{"role": "user", "content": prompt}],
            temperature=0
        )
        import json
        return json.loads(response.choices[0].message.content)
    
    # 2. 搜索获取SERP
    def search_serp(self, query: str, num_results: int = 10) -> List[Dict]:
        results = []
        with DDGS() as ddgs:
            for r in ddgs.text(query, max_results=num_results):
                results.append({
                    "title": r["title"],
                    "url": r["href"],
                    "snippet": r["body"]
                })
        return results
    
    # 3. 提取网页正文
    def extract_content(self, url: str) -> str:
        try:
            downloaded = trafilatura.fetch_url(url)
            content = trafilatura.extract(downloaded, include_links=False, include_images=False)
            return content if content else ""
        except Exception as e:
            print(f"提取网页失败：{e}")
            return ""
    
    # 4. 混合排序：BM25 + 向量相似度
    def hybrid_ranking(self, query: str, documents: List[Dict]) -> List[Dict]:
        # 过滤空内容
        documents = [doc for doc in documents if doc.get("content", "")]
        if not documents:
            return []
        
        # BM25排序
        tokenized_docs = [doc["content"].split() for doc in documents]
        bm25 = BM25Okapi(tokenized_docs)
        bm25_scores = bm25.get_scores(query.split())
        
        # 向量相似度排序
        query_embedding = embedding_model.encode(query, convert_to_tensor=True)
        doc_embeddings = embedding_model.encode([doc["content"] for doc in documents], convert_to_tensor=True)
        cos_scores = util.cos_sim(query_embedding, doc_embeddings)[0].cpu().numpy()
        
        # 融合分数：BM25归一化 + 相似度归一化，各占50%权重
        norm_bm25 = (bm25_scores - bm25_scores.min()) / (bm25_scores.max() - bm25_scores.min() + 1e-8)
        norm_cos = (cos_scores - cos_scores.min()) / (cos_scores.max() - cos_scores.min() + 1e-8)
        final_scores = 0.5 * norm_bm25 + 0.5 * norm_cos
        
        # 按分数排序，取TopK
        for i, doc in enumerate(documents):
            doc["score"] = final_scores[i]
        documents.sort(key=lambda x: x["score"], reverse=True)
        return documents[:self.top_k]
    
    # 5. 生成带引用的回答
    def generate_answer(self, user_question: str, search_results: List[Dict]) -> str:
        # 拼接搜索结果
        context = ""
        references = []
        for i, res in enumerate(search_results):
            context += f"[{i+1}] {res['title']}\n内容：{res['content'][:500]}\n来源：{res['url']}\n\n"
            references.append(f"[{i+1}] {res['title']}：{res['url']}")
        
        prompt = f"""
        请根据以下搜索结果回答用户的问题，回答要准确客观，引用内容要标注对应的[1][2]上标，最后附上来源链接。
        如果搜索结果没有相关信息，请回答「没有找到相关信息」。
        用户问题：{user_question}
        搜索结果：{context}
        """
        response = openai.ChatCompletion.create(
            model="gpt-3.5-turbo",
            messages=[{"role": "user", "content": prompt}],
            temperature=0.3
        )
        answer = response.choices[0].message.content
        answer += "\n\n### 引用来源\n" + "\n".join(references)
        return answer
    
    # 主流程
    def run(self, user_question: str) -> str:
        # 第一步：判断是否需要搜索
        query_res = self.query_understanding(user_question)
        if not query_res["need_search"]:
            response = openai.ChatCompletion.create(
                model="gpt-3.5-turbo",
                messages=[{"role": "user", "content": user_question}],
                temperature=0.3
            )
            return response.choices[0].message.content
        
        # 第二步：搜索+提取正文
        query = query_res["query"]
        print(f"正在搜索：{query}")
        serp = self.search_serp(query)
        for res in serp:
            res["content"] = self.extract_content(res["url"])
        
        # 第三步：排序
        ranked_results = self.hybrid_ranking(query, serp)
        if not ranked_results:
            return "没有找到相关信息"
        
        # 第四步：生成回答
        return self.generate_answer(user_question, ranked_results)

6.3.2 测试运行

if __name__ == "__main__":
    tool = SearchingTool()
    question = "2024年巴黎奥运会中国代表团获得了多少枚金牌？"
    answer = tool.run(question)
    print(answer)

运行后你会看到类似以下的输出：

2024年巴黎奥运会中国代表团共获得了40枚金牌，位列金牌榜第二位[1]。

### 引用来源
[1] 2024巴黎奥运会奖牌榜_央视网：https://sports.cctv.com/paris2024/medal/

6.4 最佳实践Tips

搜索触发优化：可以给大模型喂入当前的时间，让它更准确的判断是否需要搜索，比如在Prompt中加入「当前时间是2024年8月15日」
Query优化：对于中文搜索，可以在Query后面加上「官方」、「最新」等关键词，提升结果质量
重试机制：如果第一次搜索没有结果，让大模型改写Query再重试一次，最多重试2次
缓存机制：相同的Query搜索结果可以缓存24小时，避免重复搜索，降低成本，提升速度
敏感词过滤：搜索前对Query做敏感词过滤，避免搜索违规内容

7. 整合提升：知识内化与进阶路径

7.1 核心观点回顾

Searching Tool不是简单的搜索API调用，是包含「Query理解→搜索→预处理→排序→整合」的完整Pipeline，核心是给大模型提供高相关、高可信的外部信息
混合排序的效果远好于单一排序方式，工业界一般用BM25+向量相似度做粗排，CrossEncoder做精排
控制上下文长度是提升效果的关键，返回Top3-5条最相关的结果即可，太多无关内容反而会降低回答质量
溯源机制可以大幅降低幻觉，给每个结果加上来源链接，方便用户验证

7.2 拓展思考任务

尝试给你的Searching Tool对接知乎和B站的搜索接口，实现垂直领域的搜索
尝试对接你公司内部的Elasticsearch，实现内部知识库的检索
尝试加入CrossEncoder重排序，提升排序准确率
尝试实现多轮搜索功能，对于复杂问题自动拆分成多个Query搜索

7.3 进阶学习资源

《信息检索导论》：经典的信息检索教材，深入讲解排序算法原理
LangChain官方文档：https://python.langchain.com/docs/modules/tools/ ，了解更多Tool Calling的实现方式
Sentence-Transformers文档：https://www.sbert.net/ ，学习Embedding和向量检索的相关知识
Perplexity AI技术博客：https://blog.perplexity.ai/ ，了解行业领先的搜索Agent实现方案

本章小结

Searching Tool是Agent能力拓展的核心工具，它彻底打破了大模型的知识 cutoff 限制，让大模型可以获取实时、动态的外部信息，大幅降低幻觉。从本质上来说，Searching Tool就是大模型和外部信息世界的「接口」，它把杂乱无章的互联网信息转化为大模型可以理解和使用的结构化知识。

当你掌握了Searching Tool的原理和实现方法后，你可以基于它搭建各种各样的专属Agent：比如专属科研助手，自动搜最新的论文；专属电商助手，自动搜商品的最低价格；专属客服助手，自动搜产品的最新参数。想象空间无限，核心就在于你怎么去组合和优化这套Pipeline。