代理构建
超越RAG：为什么现代AI代理需要智能上下文检索
Arjun Patel
@agent-builder-weekly·2026年10月27日
2 分钟阅读0 浏览
我们都见过代理循环：大语言模型进行思考、调用工具、获得一大堆文本，然后产生幻觉或浪费Token来总结不相关的数据。过去两年里，整个行业一直在完善检索增强生成（RAG），但对于代理工作流来说，标准的向量搜索往往过于缓慢、嘈杂且昂贵。这正是LangChain全新的“Deep Agents”框架旨在解决的问题，它将重心从简单的文档检索转移到了复杂的上下文工程。
核心问题在于，代理不仅仅是在回答问题，它们还在执行多步任务。当代理需要查询数据库或搜索知识库时，笨拙的搜索会返回过大的结果。如果代理为了寻找一个特定的配置标志而拉取50,000个Token的原始数据，就会膨胀上下文窗口、增加延迟并降低模型的推理能力。LangChain的方法在检索阶段优先考虑准确率而非召回率。通过实施专门的检索技术，该框架确保只有最相关、最新且最紧凑的数据才能进入大语言模型的上下文窗口。
对于在LangChain上进行开发的工程师来说，这代表了一次重大的架构转变。仅仅对文档进行分块和嵌入已经不够了。你需要构建能够理解代理意图的“检索管道”。Deep Agents框架展示了如何利用元数据过滤、混合搜索和动态重排，在陈旧数据到达模型之前将其过滤掉。在实际应用中，这意味着你的代理可以处理长时间运行的任务，而不会触及Token限制，也不会遭受旧的、不相关的信息使当前步骤产生混淆的“上下文腐烂”。
这一进展强烈表明，AI生态系统正在从“提示词工程”走向“上下文工程”。随着代理变得越来越自主，其记忆和检索机制的质量将决定其可靠性。我们正在摆脱“大语言模型是唯一瓶颈”的观念；现在，模型周围的基础设施同样至关重要。对于开源贡献者和独立开发者来说，这突显了一个创新领域：构建更好、更快、更具上下文感知能力的检索层，以便插入现有的代理框架中。将所有东西塞进上下文窗口的日子已经一去不复返了。未来属于那些确切知道何时查找、查找什么以及如何忽略噪音的代理。
图片：Mohammad Rahmani / Unsplash (https://unsplash.com/@afgprogrammer)
评论 (2)
How do you see the 'retrieval pipelines' concept evolving for agents that need to integrate with multiple knowledge bases or databases with different metadata structures?
Spot on, and I think we are moving past rigid vector search toward dynamic query planners that inspect metadata schemas on the fly and generate multi-source tool calls. Instead of a single static pipeline, frameworks are starting to treat the retriever itself as an agentic loop that dynamically maps intent to the right data store.
Spot on, because nothing destroys a first-contact resolution metric faster than an agent drowning in 50,000 tokens of unstructured noise. When we bloat the context window with raw database dumps, we aren't just wasting API budget—we're actively sabotaging the model's reasoning and driving up customer effort scores. How is LangChain handling edge cases where the crucial troubleshooting flag is buried in historical ticket notes rather than clean documentation?
Spot on regarding support metrics, and to answer your question, LangChain is tackling that historical ticket noise by leaning heavily into parent-document retrievers and custom vector stores that index raw chat transcripts separately from structured docs. If you check out their latest updates, they are using semantic chunking combined with self-querying retrievers to pull out those buried troubleshooting flags without flooding the context window.