LangChain 在 2026 年 10 月 23 日的博客中提出，智能體的上下文工程應從檢索開始。智能體的上下文窗口有限，無法把所有資料都記住，因此必須像參加開卷考試的人一樣，先找到真正相關的信息。但檢索本身容易出問題，文章將其歸納為三類：搜索效率低、一次放入過多上下文、以及上下文不相關或過期。每次笨拙搜索都會消耗 token 和時間，若打開每個文件或反覆改寫同一查詢，還沒找到答案上下文就被失敗結果填滿；一次返回整份數據導出或十幾份文檔，也會擠佔完成任務的 space；而過時或跑題的信息對模型看起來同樣可信，一旦進入上下文，後續步驟可能一直建立在錯誤之上。
文章以“競品分析智能體”為例：它每週一研究數百個競爭對手，並按團隊模板寫報告，需要找到上週關於 A 公司的筆記、從巨大的市場數據導出中查一個具體營收數字，並在新聞檔案中搜索新消息。這三類檢索各有不同難點。Deep Agents 框架內置文件系統工具，強調先搜索再讀取：glob 按文件名模式查找，grep 在不把整個文件載入上下文的情況下搜索匹配文本，read_file 默認每次讀取一頁（約 100 行），並支持 offset 和 limit 跳到所需位置。這樣智能體不必為了“看看裏面有什麼”而打開每個文件。框架還內置 ls、write_file、edit_file 等工具，它們都通過智能體後端工作，因此無論文件位於智能體狀態、本地磁盤、持久存儲還是沙箱中，用法都一致。
當關鍵詞不夠時，可以加入檢索工具。grep 只匹配字面文本，可能漏掉標題不同但語義相關的文章，例如搜“A 公司融資”會錯過“A 公司完成 5000 萬美元 B 輪融資”。基於向量庫的語義檢索能按含義匹配；檢索工具也可以架在 SQL 數據庫、搜索 API 或 MCP 服務器之上。文章強調，研究型智能體需要“智能體式檢索”，而不是隻在開頭搜一次的兩步 RAG：智能體應自行決定何時搜索、搜什麼、是否需要繼續搜索。Deep Agents 默認以循環方式運行，可按需多次調用工具。
為了幫助智能體更好地搜索，還可以把搜索經驗封裝為技能：即針對特定任務的一組指令，例如使用哪個索引、如何組織查詢、如何格式化引用。智能體平時只看到技能名稱和簡短描述，任務需要時才加載完整説明。這種“漸進式披露”讓細分知識在需要時可用，又不會一直佔用上下文。
為減少上下文佔用，Deep Agents 對過大的工具結果進行卸載：當結果超過約 2 萬 token 時，框架把完整結果保存到 /large_tool_results/ 下，只給智能體文件路徑和首尾幾行預覽，隨後可用 read_file 的 offset 和 limit 只讀所需部分。對於自定義檢索工具，文章建議採用“檢索、卸載、委派”模式：把每條檢索結果寫入文件，只返回路徑；主智能體再把路徑交給子智能體閲讀。示例中，search_news 工具把四條結果保存為 /retrieved/result_i.md 並返回路徑列表，主智能體因此只看到四個短路徑而不是四篇全文。
不相關或過期的結果仍需處理。即使結果很小，如果它來自名稱相似的另一家公司或兩年前的舊聞，也會誤導模型。文章建議讓子智能體負責過濾：定義一個 chunk-analyst 子智能體，每次讀取一個檢索文件並只返回關鍵事實和來源 URL；主智能體先搜索得到路徑，再並行委派給多個分析子智能體，最後彙總結論，必要時再次搜索。這樣原始材料和嘈雜閲讀留在子智能體自己的上下文中，主智能體只看到結論。
為應對過期信息，可使用搜索 API 或 MCP 服務器獲取最新內容，或在檢索工具中按日期過濾。文章最後提醒，對檢索回來的文本要保持謹慎，避免把不可靠內容直接當作事實。