LangChain 提出智能体检索三步法：先存文件、再交子代理阅读
LangChain（美国人工智能应用开发框架公司）在官方博客中提出，面向智能体的检索应采用“检索、转存、委派”三步：把检索结果写成文件、只回传文件路径，再由多个子代理并行阅读并回传要点，主智能体只看到结论。
文章以每周一运行的竞品分析智能体为例，列出搜索低效、单次塞入过多上下文、结果无关或过时三类失败，并提醒检索文本属于数据而非指令、可能含提示注入。 原文为工程设计经验，未给出效果基准测试。
LangChain 工程师 Jess Weng 于 2026 年 10 月 23 日在该公司官方博客发表文章，指智能体上下文窗口有限，检索有三类失败：搜索低效、单次塞入过多上下文、结果无关或过时。 文中以每周一运行的竞品分析智能体为例：该智能体需查上周某公司记录、在市场数据导出中找某项营收数字、检索新闻库。
其方案包括：用 glob（按文件名匹配的工具）匹配文件名、用 grep（文件内文本匹配工具）在文件内匹配而不加载全文、read_file（分页读取工具）默认每次读 100 行并可设偏移与行数上限；
当工具结果过大（约 2 万个 token，即文本处理单元）时，由 Deep Agents（LangChain 的智能体框架）存入 /large_tool_results/ 并只回传路径和首尾预览； 自定义检索工具把每条结果写成文件并返回路径； 主智能体把路径交给 chunk-analyst 子代理，子代理阅读后只回传要点与来源网址。
文章还提醒检索到的文本属于数据而非指令，可能含提示注入，需核对答案引用并视为不可信内容。
这篇文章把智能体工作流中的一个具体工程约束讲清楚了：检索成本不只体现在搜索次数，还会体现为失败搜索占用上下文、无关或过时文档污染推理链路。 其提出的“主智能体只看结论、子代理承担噪声”结构，指向多智能体分工的一个重要理由——上下文隔离，而不是简单地增加代理数量。
文中对语义检索与 grep 的取舍判断（关键词可预测时优先 grep）也说明，智能体能力的提升未必来自更复杂的模型，而来自工具边界和结果粒度设计。 需注意文章未披露 token 节省比例、任务成功率或错误率等量化数据，所述模式更接近设计建议。
后续观察信号
- 检索结果外置为文件后，如何保证子代理回传要点不丢失关键数字与引用来源
- grep 与语义检索的取舍在实际业务中如何量化评估
- 提示注入防护是否有可复用的评测方法