AI Agent 的上下文工程，从检索开始

把一道开卷考题交给 Agent，它面临的处境和人类考生如出一辙：理论上所有答案都在手边，但正因如此，找到正确答案反而更难。Agent 的上下文窗口是有限资源，每一次检索都要消耗 token 和时间。如果 Agent 逐一打开文件查看内容，或者反复改写同一个查询，上下文很快就会被失败的搜索结果填满，真正有用的信息反而没有容身之处。这种低效搜索是 Agent 检索失效的第一个根源。

第二个问题是单次检索返回内容过多。一次拉取完整数据导出或十几份文档，足以在一个操作内耗尽整个上下文窗口，后续推理和写作几乎无法进行。第三个问题更隐蔽：过时或偏题的信息在模型眼中与正确答案同样可信。一旦这类信息进入上下文，Agent 就会基于错误前提继续推理，错误会在每一步之后持续累积放大。这三类问题共同构成了 Agent 检索设计必须正视的核心挑战。

LangChain 的 Deep Agents 框架通过内置文件系统工具直接应对低效搜索问题。glob 按文件名模式匹配，例如用 **/company-a*.md 快速定位上周的竞品笔记；grep 在不将文件加载进上下文的前提下搜索内部关键词，可返回匹配文件、匹配行或计数；read_file 则支持分页读取，避免一次性加载过大文件。这套工具的逻辑类似于先查书的索引再翻正文，而非从头到尾逐页阅读，从根本上减少了无效检索的次数。

当关键词匹配无法覆盖语义相近但措辞不同的内容时，需要引入向量存储支持的检索工具。以竞品分析 Agent 为例，若用 grep 搜索「Company A funding」，就会错过标题为「Company A closes $50M Series B」的文章。语义检索工具以查询意图而非精确文本为匹配依据，同样的接口也可以对接 SQL 数据库、搜索 API 或 MCP 服务器，适配不同类型的数据源。Deep Agents 默认让 Agent 在循环中自主决定何时检索、检索什么，而非仅在任务开始时执行一次固定查询，这种「主动检索」模式更适合需要动态发现信息的复杂研究任务。

针对检索结果过大的问题，Deep Agents 采用「结果卸载」策略：工具返回的完整内容被保存为文件，Agent 只收到文件路径和简短预览。对于自定义检索工具（如 RAG 流程），框架推荐「检索—卸载—委托」三步模式：将检索结果存入文件，向主 Agent 返回路径，再由子 Agent 按需读取具体内容。主 Agent 的上下文始终保持精简，只包含与当前推理步骤真正相关的信息，从而将有限的上下文窗口留给实际的分析和写作工作。

上下文工程的核心不在于给 Agent 塞入尽可能多的信息，而在于在正确的时机提供恰好足够的信息。检索策略的设计直接决定了 Agent 能否高效完成任务，而这一设计责任落在 Agent 框架（harness）的构建者身上。LangChain 通过 Deep Agents 将这些最佳实践内置为默认行为，开发者在构建自定义检索工具时，也可以将领域搜索经验封装为可复用的技能模块，让 Agent 在面对不同类型检索任务时都能做出合理决策。

要点

• Agent 检索失效的三大根源是低效搜索、单次上下文过载和引入过时或不相关信息，三者都会直接损耗有限的上下文窗口资源。
• Deep Agents 内置的 glob 和 grep 工具实现「先定位、再读取」的检索逻辑，避免逐文件加载造成的上下文浪费。
• 超大工具返回结果通过卸载为文件并仅向 Agent 返回路径和预览的方式，将完整内容与主 Agent 上下文隔离。
• 自定义检索工具（如 RAG）应遵循「检索—卸载—委托」模式，由子 Agent 负责读取完整内容，主 Agent 保持上下文精简。
• Agent 应具备主动检索能力，能在任务执行过程中动态决定何时搜索、搜索什么，而非依赖任务开始时的单次固定查询。