LangChain博客：Deep Agents用检索工具与子代理管理上下文窗口
LangChain在一篇技术博客中介绍其Deep Agents框架默认内置的检索与上下文管理做法：先用glob、grep按文件名和关键词查找，再用向量检索做语义匹配；超大工具结果自动写入文件，由子代理读取后只回传结论。这些均为LangChain对自家框架能力的说明。
AI解读：LangChain博客把代理检索的问题归为三类：搜索低效（反复打开文件或改写查询，结果先占满上下文）、单次返回过多内容、以及返回不相关或过时信息。
博客称Deep Agents默认内置glob、grep、ls、read_file、write_file、edit_file等文件系统工具，可按文件名模式和文件内文本查找，无需先把文件读进上下文。
博客给出的具体数字：read_file默认每次读 100 行并支持offset、limit；工具结果超过约 20,000 token时，框架会存到 /large_tool_results/并只返回路径和首尾预览。
博客建议让检索工具把每条结果写成文件、只返回路径，再由子代理各自读取并回传关键事实和来源URL，主代理只看到结论。
博客同时提示：语义检索只在需要按含义匹配时使用；检索文本属于不可信数据，可能含提示注入，应校验答案是否引用了预期来源。
博客以每周一运行、研究数百家竞争对手的竞争分析代理为例，属于演示性案例，未给出该代理的实际运行效果数据。
LangChain在 11 月 9 日线上分享前发布技术博客，说明其Deep Agents框架如何通过检索工具和子代理控制代理的上下文窗口。文中列出的能力均为LangChain对自家框架的描述，并以一个每周一运行的竞争分析代理作为演示。
博客称，代理和人一样只有有限的上下文窗口，搜索时容易遇到三类问题：反复打开文件或换个说法重搜，把上下文耗在失败尝试上；一次搜索返回整个数据导出或十几份文档；以及把过时或跑题的内容当作可靠信息继续使用。
Deep Agents内置的查找方式
博客称，Deep Agents默认带有文件系统工具glob、grep、ls、read_file、write_file、edit_file，且无论文件存放在代理状态、本地磁盘、持久存储还是沙箱，都通过同一后端访问。
其中glob按文件名模式查找，例如用 **/company-a*.md找到上周关于A公司的笔记；grep在文件内部匹配字面文本，可以返回匹配文件、匹配行或计数，而不把整个文件载入上下文。博客认为，在知道关键词的情况下，这比向量检索更省。
语义检索与按需搜索
博客指出grep只匹配字面文本：搜“Company A funding”会漏掉标题为“Company A closes $50M Series B”的文章。要按含义搜索，需要接入以向量库为后端的检索工具，也可以接SQL数据库、搜索API或MCP服务器。
博客称Deep Agents默认以循环方式运行，代理自行决定何时搜、搜什么、是否继续搜，而不是在开始时只检索一次的“两步RAG”。
压缩返回内容与子代理分工
博客给出两项具体机制：read_file默认每次读 100 行，代理可用offset和limit跳到所需位置；工具结果超过约 20,000 token时，框架把它保存到 /large_tool_results/，只返回路径和首尾几行的预览。
博客还建议自定义检索工具时直接把每条结果写成文件、返回路径列表。随后主代理把每个路径交给一个chunk-analyst子代理并行读取，子代理返回关键事实和来源URL；跑题内容留在子代理的上下文里。
博客提示的限制
博客称，过滤子代理能挡掉跑题内容，但挡不住过时结果，例如每周一运行的代理无法靠一个月前的索引拿到本周新闻；可用搜索API、MCP服务器或在检索工具中按日期过滤。
博客同时提醒，检索到的文本是数据而非指令，可能含提示注入，没有提示词或分隔符策略能完全防住，因此需要校验答案引用了预期来源、表述与来源一致。