作者：来自 Elastic Leonie Monigatti
了解上下文工程中有哪些 context-retrieval 工具，它们如何工作，以及它们的权衡取舍。
一个 agent 最重要的工具是它可以用来构建自身上下文的搜索工具。近期 LlamaIndex 和 LangChain 的文章引发了一场讨论：对于上下文工程来说，一个 shell 工具和文件系统是否已经足够？不幸的是，讨论很快偏离了重点：文件系统 versus 数据库。
本文将焦点重新放回问题本身：agent 需要哪些合适的搜索接口来构建自己的上下文？首先会介绍 shell 工具与专用数据库工具之间的权衡。接着，提供一个实用框架，帮助你为 agent 的需求找到合适的接口。
对于一个 agent 来说，“构建上下文” 究竟意味着什么？
在早期的检索增强生成（RAG）流程中，开发者需要设计一个固定的检索管道，而大语言模型（LLM）只是上下文的被动接收者。这是一个根本性的限制：每次查询都会进行上下文检索，无论是否真的需要，而且也不会检查这些上下文是否有帮助。
随着向 agentic RAG 的转变，agent 现在可以访问一组搜索工具来自主构建上下文。例如，Claude Code 和 Cursor 都允许 agent 在不同搜索工具之间进行选择，甚至根据任务需要将它们组合成链式查询。
上下文工程中有哪些搜索接口？
上下文可以存在于不同位置，例如 web、本地文件系统或数据库。agent 可以通过不同工具与这些“上下文之外”的数据源交互：
- Shell 工具可以执行 shell 命令，并访问本地文件系统。一些内置 shell 工具的例子包括 Claude API 的 bash 工具、OpenClaw 的 exec 工具，以及 LangChain 的 shell 工具。
- 专用数据库工具，例如来自 Model Context Protocol（MCP）服务器的工具（例如 Elastic Agent Builder MCP server）或自定义工具（例如 run_esql(query) 或 db_list_index()），可以查询数据库。
- 专用文件搜索工具可以搜索并读取本地（或上传的）文件（无需完整的 shell 访问权限）。一些内置文件搜索工具的例子包括 Gemini API 的 File Search Tool 或 OpenAI 的 File Search Tool。
- Web 搜索工具可以从 web 检索信息。
- Memory 工具用于存储和从长期记忆中检索信息（无论其存储方式如何）。
如你所见，shell 工具非常通用，可用于从不同数据源检索上下文，包括：
- 文件系统：agent 探索目录结构（ls、find），搜索相关内容（grep、cat），并不断重复，直到构建出足够的上下文。
- 数据库：agent 可以使用数据库命令行界面（CLI）工具（例如 elasticsearch-sql-cli）、通过 curl 调用 HTTP API，或运行脚本。这在结合 agent skills 时尤其有用——agent skills 是可复用、文档化的示例，会注入到 agent 的上下文中以指导正确的工具使用（例如用于 Elasticsearch 的 Elastic Agent Skills）。
- Web：agent 可以通过 curl 命令调用搜索提供商的 API 来执行 web 搜索。
然而，shell 工具提供了对系统的直接访问，因此需要安全措施，例如在隔离的 sandbox 环境中运行，并记录所有执行的命令。
何时使用哪种搜索接口
合适的搜索接口取决于你的数据、查询模式以及使用场景。本节提供一个实用的起点。
文件系统并不会让数据库过时
文件系统 versus 数据库的讨论并不在于存储层本身。例如，LangChain 解释说，其 memory 系统实际上并不是将数据存储在真实的文件系统中。相反，它将数据存储在数据库中，并以一组文件的形式呈现给 agent [3]。
文件系统非常适合以文件为中心的使用场景，例如 coding agents。它们也非常适合作为临时的 scratch pad 或工作内存，以及在单用户或单 agent 场景中（此时无需考虑并发）。在这些情况下，物理文件系统或将数据表示为文件系统，可以在你决定采用专用接口之前提供灵活性。
但文件系统存储也有明显的缺点，例如并发能力弱、需要手动进行 schema 约束以及缺乏原子事务支持。当你的应用需要扩展或进入多 agent 场景时，这些问题会变得更加明显。任何忽视这些缺点的人，最终都会痛苦地重新发明一个更差的数据库，而缺少生产级数据库在事务安全或访问控制方面数十年的工程积累。此外，在大多数企业场景中，你通常无法选择是否使用数据库，因为数据库已经存在，并存储着关键的业务数据。
Shell 工具 + 文件系统
对于文件系统搜索来说，shell 工具是一个自然的起点。目前，coding agents 正在推动该领域的诸多进展。由于它们处理的是本地文件中的代码，因此天然属于以文件为主的使用场景。因此，LLM 在后训练阶段会针对编码任务进行微调。这也是为什么许多 LLM 不仅擅长编写代码，也擅长使用 shell 命令和导航文件系统。
使用带有内置 CLI（如 ls 和 grep）的 shell 工具来查找文件是高效的。使用 grep 时，像 “Find all files that import matplotlib” 这样的查询既快速又精确且成本低。但当 agent 需要处理概念性查询时，例如 “我们的应用如何处理认证失败？”，基于 grep 的模式匹配很快就会遇到瓶颈。为填补这一空白，一些将语义搜索能力引入命令行的替代方案已经出现，例如 jina-grep。
然而，grep 以及许多语义搜索替代方案在语料上运行的复杂度是 O(n)。对于代码库场景来说，这通常可以接受。但如果你的数据规模增长，延迟会变得明显。在这种情况下，就需要使用带索引的数据存储来保持性能。
Shell 工具 + 数据库
为你的数据添加更多搜索能力（例如语义搜索或混合搜索）的另一种方式，是将数据存储在数据库中，例如 Cursor 所做的那样。此外，当数据需要复杂的关系连接或聚合时，数据库接口是不可或缺的。
当数据存储在数据库中而不是文件系统中时，shell 工具可以在某些场景下作为一个轻量级的数据库接口。如果你的查询足够简单，可以通过 CLI 或 curl 调用完成，那么专用数据库工具可能会引入不必要的复杂性。
这种方式也适用于早期探索阶段，此时你还不清楚 agent 实际会形成怎样的查询模式。在这种情况下，Agent Skills 可以为 agent 提供足够的结构，使其能够正确查询，而无需立即采用专用工具。然而，当 agent 在重复任务中需要多次尝试才能找到正确的数据库查询方式时，使用 shell 工具作为接口所带来的 token 开销，就不再值得用来换取避免增加新工具的简化优势。
专用数据库工具
当重复查询模式具有结构性或分析性时，专用数据库工具尤为必要。来自 Vercel 和 Braintrust 的一篇博客，对比了在半结构化数据（例如客户支持工单和销售通话记录）上执行真实检索任务的 agent，这些 agent 使用了不同的搜索工具组合（例如：“有多少未关闭的问题提到了 'security'？” 或 “找出有人报告 bug 后，后来又有人提交 PR 声称修复了该 bug 的问题？”）[4]。
使用专用数据库工具的 agent 比仅使用 shell 工具和文件系统的 agent 消耗更少的 token、速度更快且错误更少。结论是：当查询需要对半结构化数据进行分析推理时，直接使用数据库工具是正确选择。
组合搜索接口
没有任何单一搜索接口能够很好地处理所有查询。例如，Cursor 同时结合了 shell 工具（通过 grep 搜索）和语义搜索工具，并允许 agent 根据用户提示选择合适的工具。他们报告称：对于匹配特定符号或字符串，agent 会选择 grep；对于概念或行为类问题，会选择语义搜索；而对于探索性任务，则会组合使用两者。
Vercel 的实验也得出了相同结论：其混合 agent 同时具备 shell 工具和专用数据库工具的访问能力，在所有测试 agent 中表现最佳。它通常先使用专用数据库工具获取结果，然后再通过在文件系统中使用 grep 进行验证。不过，这种方法在工具选择和结果验证上会消耗更多 token 和时间。
两个例子呈现出相同的模式：组合优于任何单一接口，但组合也带来了成本和延迟增加的权衡。
寻找合适工具集合的实践建议
合适的搜索接口集合应当是精简、有针对性，并且与 agent 的实际查询模式相匹配。当前最佳实践是为 agent 提供尽可能少的工具，而不是暴露数百个 MCP 工具。这是因为一开始就暴露所有可能工具的缺点在于会膨胀上下文窗口，并让 agent 在选择工具时产生困惑。例如，Claude Code 据称只提供大约 20 个工具。
相反，“渐进式披露” 的理念是从最小工具集开始，仅在需要时让 agent 发现额外能力。来自 Anthropic 和 Cursor 的研究表明，这种方法可以节省 47%–85% 的 token。例如，Claude Code 就直接采用了这一方式，使 agent 能逐步学习如何查询 API 或数据库，而无需在每次 LLM 调用中都占用上下文。
当你熟悉了 agent 的查询模式后，可以重新评估其默认可用的搜索工具集合。一个有用的思考方式是 “低门槛，高上限”（low floor, high ceiling）原则，用来决定哪些工具应该被保留。高上限工具不会限制 agent 的潜力。例如，一个通用的 shell 工具允许 agent 编写完整的数据库查询（包括模糊查询），但代价是更高的推理开销、更高的延迟以及更低的可靠性。
低门槛工具则相反。它们是针对特定查询封装的专用工具，agent 可以以极低的推理成本直接使用，从而带来更低成本和更高可靠性。但它们需要前期工程投入，无法覆盖所有可能的查询，并且可能让 agent 更难选择正确的工具。
可以将每个工具看作一个光谱：低门槛工具易于正确使用但范围有限；高上限工具更灵活，但需要更多推理才能用好。
大多数 agent 需要混合使用不同的搜索工具，但每个工具都需要证明其价值。我们建议从一个通用搜索工具开始（例如 search_database() 工具或 shell 工具）。然后，重用你已经为安全目的记录的命令日志，跟踪 agent 的实际行为，包括工具调用、重试次数以及每个用户查询的调用次数。当你发现某个查询模式重复出现或失败时，这就是构建专用工具的信号。
总结
文件系统 vs 数据库的争论让工程师忽视了真正需要问的问题：agent 需要哪些搜索接口来构建自己的上下文？答案很可能是：不是单一的一个。
shell 工具是一个通用工具，可与不同的上下文外数据源交互，因此是一个很好的起点。但对于结构化分析查询的使用场景，它的效率和准确性不如专用数据库工具。
目标是找到能够很好处理 agent 实际查询模式的最小搜索工具集合。先从 shell 工具开始，并记录 agent 的实际行为。当发现某个查询模式重复且失败时，就需要开发专用工具。
参考文献
- Thariq. 构建 Claude Code 的经验教训：像 agent 一样观察 (2026)。
- Cursor. 文档。语义与 agent 搜索 (2026)。
- Harrison Chase. 我们如何构建 Agent Builder 的记忆系统 (2026)。
- Ankur Goyal 和 Andrew Qu. [测试 "bash 是否足够"](vercel.com/blog/testin… "测试 "bash 是否足够" ")(2026)。
- Anthropic. 在 Claude 开发者平台上引入高级工具使用 (2025)。
- Cursor. 动态上下文发现 (2026)。
Agent Builder 现已全面上线。可通过 Elastic Cloud 试用开始，并查看 Agent Builder 文档。
