上下文工程的搜索工具 - Elasticsearch Labs

智能体最重要的工具是那些它可以用来构建自身上下文的搜索工具。最近 LlamaIndex 和 LangChain 的帖子引发了一场讨论：shell 工具和文件系统是否就是智能体进行上下文工程所需的一切？不幸的是，讨论很快偏离了焦点，转向了文件系统与数据库之争。

本文重新聚焦于这个问题：智能体构建自身上下文需要哪些正确的搜索接口？它首先讨论了 shell 工具与专用数据库工具之间的取舍。在此基础上，它提供了一个实用的框架，用于为您的智能体需求找到正确的接口。

对智能体而言，“构建上下文”到底意味着什么？

在早期的 Retrieval-Augmented Generation (RAG) 管道中，开发人员设计了一个固定的检索管道，而大型语言模型（LLM）只是上下文的被动接收者。这是一个根本性的限制：无论是否需要，每次查询都要检索上下文，而且不检查上下文是否真的有帮助。

随着向智能体式 RAG 的转变，智能体现在可以访问一组搜索工具来构建自己的上下文。例如，Claude Code [1] 和 Cursor [2] 都允许智能体根据任务的实际需求，在不同的搜索工具之间进行选择，甚至将它们组合起来用于链式查询。

有哪些用于上下文工程的搜索接口？

上下文可以存在于不同的位置，例如网络上、本地文件系统中或数据库中。智能体可以通过不同的工具与这些脱离上下文的每个数据源进行交互：

shell 工具 可以执行 shell 命令并访问本地文件系统。一些内置 shell 工具的例子包括 Claude API 的 bash 工具、OpenClaw 的 exec 工具以及 LangChain 的 shell 工具。
专用数据库工具，例如来自模型上下文协议（MCP）服务器（例如，Elastic Agent Builder MCP 服务器）的工具或自定义工具（例如，run_esql(query) 或 db_list_index()），可以查询数据库。
专用文件搜索工具可以搜索和读取本地（或上传）文件（无需完整的 shell 访问权限）。一些内置文件搜索工具的例子是 Gemini API 的文件搜索工具或 OpenAI 的文件搜索工具。
网络搜索工具可以从网络上检索信息。
记忆工具会存储和回忆长期记忆中的内容（无论存储方式如何）。

示意图展示了智能体如何使用不同的上下文检索工具访问本地文件、专有数据、网络和长期记忆。

如图所示，shell 工具功能强大，可用于从不同数据源检索上下文，包括：

文件系统：智能体会探索目录结构（ls、find），搜索相关内容（grep、cat），并不断重复，直到构建足够的上下文。
数据库：智能体可以使用数据库命令行接口（CLI）工具（例如，elasticsearch-sql-cli），通过 curl 调用 HTTP API 或运行脚本，这在与 Agent Skills 结合使用时特别有用。Agent Skills 是注入到智能体上下文中用于指导正确工具使用的可复用、带示例的文档（例如 Elastic Agent Skills for Elasticsearch）。
网络：智能体可以通过搜索提供商的 API，使用 curl 命令执行网络搜索。

然而，shell 工具提供直接的系统访问权限，因此需要采取安全措施，例如在隔离的沙盒环境中运行，并记录所有执行的命令。

何时使用哪种搜索接口

正确的搜索接口取决于您的数据、查询模式以及用例场景。本节将作为实用的入门起点。

文件系统并不会让数据库过时

文件系统与数据库的讨论并非关于存储层。例如，LangChain 解释说，其记忆系统实际上并不将记忆存储在真实的文件系统中。相反，它将记忆存储在数据库中，并以文件集合的形式呈现给智能体 [3]。

文件系统天然适用于以文件为中心的用例，例如编码智能体。它们也可以很好地用作临时暂存区或工作记忆，以及适用于无需考虑并发问题的单用户或单智能体场景。在这些情况下，在投入构建专用接口之前，使用物理文件系统或将数据表示为文件系统可以为您提供灵活性。

但是，文件系统存储确实存在缺点，例如并发性弱、需要手动执行模式约束、原子事务支持差。当您的应用程序需要扩展或迁移到多智能体场景时，这些缺点会更加明显。任何忽视这些缺点的人都注定要痛苦地重新发明更糟糕的数据库，却缺乏生产数据库已经提供的、经过数十年工程实践的事务安全或访问控制机制。此外，在大多数企业环境中，您并非选择是否使用数据库——因为数据库已经存在，并存储着业务关键数据。

Shell 工具 + 文件系统

对于文件系统搜索，shell 工具是自然的起点。当前，编码智能体正在推动该领域取得巨大进展。由于它们处理本地文件中的代码，因此自然是以文件为主的用例。因此，LLM 在后训练阶段会针对编码任务进行微调。这就是为什么许多 LLM 不仅擅长编写代码，还擅长使用 shell 命令和操作文件系统的原因。

使用带有内置 CLI（如 ls 和 grep）的 shell 工具来查找文件是有效的。使用 grep，像“Find all files that import matplotlib”这样的查询既快速、精确又廉价。但是，当智能体需要处理概念性查询（例如“How does our app handle failed authentication?”）时，使用 grep 进行模式匹配很快就会触及天花板。为了填补这一空白，出现了一些将语义搜索能力带到命令行的替代方案，包括 jina-grep。

然而，grep 及其许多语义搜索替代方案在语料库上的运行速度为 O(n)。对于代码库相关的使用场景，这可能没问题。但是，如果数据量增加，延迟就会变得很明显。在这种情况下，为了保持性能，需要使用索引数据存储。

shell 工具 + 数据库

另一种为数据添加更多搜索能力（例如语义搜索或混合搜索）的方法是将数据存储在数据库中，就像 Cursor 所做的那样。此外，当数据需要复杂的关系连接或聚合时，数据库接口是不可或缺的。

数据存储在数据库中而非文件系统上时，shell 工具可以在某些用例中充当轻量级的数据库接口。如果您的查询足够简单，只需 CLI 或 curl 调用即可完成，那么专用的数据库工具可能会带来不必要的复杂性。

这种方法也适用于早期的探索阶段，此时您还不知道智能体最终会发展出什么样的查询模式。在这种情况下，Agent Skills 可以为智能体提供足够的结构来正确执行查询，而无需投入构建专用工具。但是，当智能体需要大量迭代才能找出针对重复任务查询数据库的正确方式时，使用 shell 工具作为接口所带来的词元开销，就不再能抵消避免使用额外工具的简单性优势了。

专用数据库工具

特别是当重复的查询模式是结构化的或分析性的时，专用的数据库工具就变得必要了。Vercel 和 Braintrust 的一篇博客文章比较了拥有不同搜索工具集的智能体，在半结构化数据（如客户支持工单和销售通话记录）上执行真实世界的检索任务（例如，“How many open issues mention 'security'?”或“Find issues where someone reported a bug and later someone submitted a PR claiming to fix it?”）[4]。

拥有专用数据库工具的智能体，与仅拥有 shell 工具和文件系统的智能体相比，使用的词元更少，速度更快，犯的错误也更少。经验表明，当查询需要对半结构化数据进行分析推理时，直接使用数据库工具才是正确的选择。

组合使用搜索接口

没有哪一个搜索接口能完美处理所有查询。例如，Cursor 将 shell 工具（用于通过 grep 搜索）和语义搜索工具组合起来，让智能体根据用户提示选择正确的工具。智能体会选择 grep 来匹配特定的符号或字符串，选择语义搜索来处理概念性或行为性问题，并在探索性任务中同时使用两者。

Vercel 的实验报告了相同的结果：其混合型智能体可同时访问 shell 工具和专用数据库工具，通过首先使用专用数据库工具，然后通过文档系统 grepping 验证结果，在所有测试的智能体中取得了最佳性能。这种方法在工具选择和验证的推理上消耗了更多的词元和时间。

这两个示例中的模式是相同的：组合优于任何单一接口，但组合的代价是增加成本和延迟。

寻找合适工具的实用建议

合适的搜索接口应该简洁、目标明确，并且能够满足您的智能体的实际查询模式。当前的最佳实践是让智能体拥有尽可能少的工具，而不是让它拥有数百个 MCP 工具。这是因为，预先公开所有可能的工具会带来弊端：它会使上下文窗口臃肿，并使智能体困惑于到底该使用哪个工具。例如，据报道 Claude Code 只有大约 20 种工具。

相反，渐进式公开的理念是从一套最基本的工具开始，让智能体在需要时才发现额外的功能。Anthropic [5] 和 Cursor [6] 的研究表明，这种方法可以节省 47%–85% 的词元。例如，Claude Code 直接实现了这一点，允许智能体逐步发现如何查询 API 或数据库，而无需在每次 LLM 调用时都将这些知识消耗在上下文中。

一旦您熟悉了智能体的查询模式，就可以重新审视智能体默认可以访问的搜索工具集。一种思考这种取舍的有用方式是使用”低门槛，高上限“原则，用于决定哪些工具值得被纳入。高上限工具不会限制智能体的潜力。例如，一个通用的 shell 工具允许智能体编写完整的数据库查询（包括模糊查询），但代价是推理开销、更高的延迟和更低的可靠性。

“低门槛”工具则相反。它们是封装了特定查询的专用工具，智能体可以以最少的推理开销直接使用，从而产生更低的成本和更高的可靠性。但它们需要前期工程投入，无法覆盖所有可能的查询，并且可能使智能体更难选择正确的工具。

可将每个工具视为处在一条连续谱上：低门槛工具更容易被代理正确使用，但覆盖范围较窄。高上限工具用途广泛，但要用得好需要更多推理。

图示：比较三种智能体设计方法（高门槛/高上限、低门槛/低上限、低门槛/高上限），展示不同的工具策略如何影响智能体处理模糊、通用和可预测查询的能力。

多数智能体需要混合使用不同的搜索工具。但每个工具都需要“凭实力”加入。我们建议从一个通用的搜索工具（例如 search_database() 工具或 shell 工具）开始。然后，复用您出于安全目的已经保留的命令日志，来跟踪智能体的实际行为，包括工具调用、重试次数以及每个用户查询的调用次数。并且，当您看到某个查询模式重复出现或执行失败时，这就是为该模式构建专用工具的信号。