作者来自 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 ProtocolMCP服务器的工具例如 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。Webagent 可以通过 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 是否足够(2026)。Anthropic. 在 Claude 开发者平台上引入高级工具使用 (2025)。Cursor. 动态上下文发现 (2026)。Agent Builder 现已全面上线。可通过 Elastic Cloud 试用开始并查看 Agent Builder 文档。原文https://www.elastic.co/search-labs/blog/search-tools-context-engineering