Agentic Search实战：Agent上下文搜索工具选择与组合指南

在AI Agent时代，上下文工程（Context Engineering）已成为决定Agent输出质量的核心因素。上下文工程是指系统性地设计、管理和优化输入给大语言模型的上下文信息的工程实践——与提示词工程（Prompt Engineering）侧重于单次交互的措辞优化不同，上下文工程关注的是在整个Agent运行周期中，如何动态地从多个来源收集、过滤、压缩和组织信息，使其适配模型的上下文窗口限制，同时最大化信息的相关性和有效性。随着主流模型上下文窗口从4K扩展到100K甚至更长，上下文工程的重心已从"如何塞进更多信息"转变为"如何确保正确的信息出现在正确的位置"。

Elastic工程师Leonie在AI Engineer大会上分享了一套关于Agentic Search的完整实战方法论——从传统RAG的局限性出发，逐步演示如何构建更强大的搜索工具组合，帮助Agent从多种上下文源中精准获取信息。

她提出了一个大胆的观点：上下文工程80%的工作就是Agentic Search。这不仅仅是检索，而是关于如何让Agent自主决定搜索什么、用什么工具搜索、以及如何处理搜索结果。

从RAG到Agentic RAG：搜索范式的演进

传统RAG的固有缺陷

检索增强生成（Retrieval-Augmented Generation，RAG）由Meta AI在2020年提出，核心思想是将参数化知识（模型权重中存储的知识）与非参数化知识（外部文档库）结合。传统RAG流程包括：离线阶段将文档切片并通过嵌入模型转化为向量存储在向量数据库中；在线阶段将用户查询同样向量化，通过近似最近邻（ANN）算法检索相似文档片段，拼接后送入LLM生成答案。

最初的RAG方案采用固定检索流水线：用户消息几乎原封不动地作为向量搜索查询，从数据库中拉取文档片段，然后与用户消息一起送入LLM。这种方式有效缓解了LLM的知识截止问题和幻觉问题，但其固定流水线架构天然不适合需要多步推理、动态决策的复杂任务场景，具体表现为两个明显问题：

1. 无论是否需要额外上下文，系统都会执行检索，在最坏情况下反而会干扰LLM的判断
2. 只检索一次无法处理多跳推理，当第一轮检索结果揭示了新的搜索线索时，系统无法进行第二轮搜索

什么是多跳推理？ 多跳推理是指需要跨越多个中间步骤或多个知识来源才能得出最终答案的推理过程。例如，回答"特斯拉CEO毕业的大学的创始人是谁"需要先检索"特斯拉CEO是埃隆·马斯克"，再检索"马斯克毕业于宾夕法尼亚大学"，最后检索"宾夕法尼亚大学的创始人是本杰明·富兰克林"。传统单次RAG检索无法处理这类问题，因为第一轮检索的结果往往揭示了新的搜索线索，需要动态调整后续查询策略。

Agentic RAG的突破

Agentic RAG用搜索工具替代了固定流水线，让Agent自主决定是否调用搜索、何时重写查询、是否需要多轮检索。但这仍然只有一个上下文源。

在真实的上下文工程场景中，上下文散布在多个地方：本地文件系统（代码文件、计划文档、Agent技能文件）、数据库、Web、长期记忆等。每种上下文源都需要对应的搜索工具——文件搜索工具、技能加载工具、语义搜索工具、通用查询工具、Web搜索工具、记忆工具，甚至还有Shell工具。

构建好搜索工具的三大基础原则

Agentic Search表面上看很简单：用户发请求，Agent调用正确工具并传入正确参数，返回结果。但现实中，它会以多种方式失败。

失败模式一：Agent不调用任何工具

Agent可能认为自己凭参数化知识就能回答问题，完全跳过上下文检索。这在需要实时数据或私有知识的场景下尤其危险。

失败模式二：Agent调用了错误的工具

Leonie提到一位同事的经历——项目中最大的挑战竟然是让Agent不去调用Web搜索工具，而是调用数据库搜索工具。当工具数量增多时，这种"选错工具