2026/10/30 · Weekly Radar
LangChain 以競品分析 agent 為例，把 agent 檢索的三種失敗（亂搜、一次塞太多、過時或無關）對應到 Deep Agents 的解法：先 glob/grep 再分頁讀檔、超過約 20k token 的結果自動落地成檔案，自訂 RAG 則走「retrieve, offload, delegate」，讓 subagent 讀完只回結論。
這篇是 LangChain 的 Jess Weng 撰寫的技術文章，主張 context engineering 從檢索開始，並以 Deep Agents harness 為例說明如何讓 agent 在有限的 context window 中取得正確資訊。作者把它比喻成開書考：答案都在，反而更難找。
一是搜尋效率差：每次搜尋都花 token 與時間，笨拙的 agent 會打開每個檔案看內容，或反覆改寫同一查詢，在找到有用東西前就塞滿 context。二是一次塞太多：一次搜尋丟回整份資料匯出或十幾份文件，直接吃光 context，沒空間做事。三是無關或過時的內容：對模型來說，過時或離題的資訊和正確答案一樣有說服力，一旦進入 context 就可能被當成基礎，錯誤延續到之後每一步。harness 的工作就是策略性地運用技巧，在對的時間給模型對的 context。
一個每週一研究數百家競品、依團隊範本寫報告的 agent，需要找上週對 A 公司的筆記、在巨大的市場資料匯出中查一個營收數字、在新聞資料庫搜尋新消息，三者分屬不同類型的檢索。
先用內建檔案系統工具，先查名稱與關鍵字再讀：glob 依檔名模式找檔，grep 在不載入檔案的情況下搜尋內容。每個 deep agent 內建 ls、read_file、write_file、edit_file、glob、grep，且無論檔案在 agent state、本機、持久儲存或 sandbox，都透過同一個 backend 運作。關鍵字不夠時加一個檢索工具：grep 只做字面比對，搜「Company A funding」會漏掉「Company A closes $50M Series B」，因此需要以向量資料庫做語意搜尋；檢索工具也可以架在 SQL 資料庫、搜尋 API 或 MCP server 上。研究型 agent 需要 agentic retrieval 而非兩步驟 RAG：由 agent 決定何時搜、搜什麼、是否還需要更多，例如研究到一半發現新產品才需要查它的定價；Deep Agents 預設就是迴圈式呼叫工具。也可以把搜尋知識包成 skill，只在需要時載入完整指令（漸進式揭露）。
read_file 預設一次讀 100 行，可設定 offset 與 limit，所以查 B 公司營收時先 grep 再讀附近幾行，而不是載入四萬行。當工具結果太大（約超過 20,000 token），harness 會把完整結果存到 /large_tool_results/，只給 agent 路徑與頭尾預覽，之後再分段讀取。自訂檢索工具也可主動套用這個做法：把每筆結果寫成檔案、只回傳路徑，這是「retrieve, offload, delegate」模式的第一步，文中附上一個把向量搜尋前四筆結果上傳到 backend 並回傳路徑清單的範例工具。
主 agent 仍得讀檔才知道哪些有用，而每打開一篇離題文章就會進入 context，因此第二步是委派：定義一個 chunk-analyst subagent，每次處理一個檔案、回傳關鍵事實與來源網址，並與檢索工具共用同一個 backend。流程變成：搜尋取得四個路徑，平行委派給分析 subagent，最後主 agent 彙整摘要，不足再搜。原始結果在檔案裡，雜訊閱讀在各自獨立的 subagent context，主 agent 只看到結論。至於過時問題，過濾無法解決，需改接搜尋 API 或 MCP server 取得即時資訊，或在檢索工具中依日期過濾。
好的檢索靠 harness 的策略：用對工具、只回傳最少必要內容、把雜訊隔離在 subagent 中，讓主 agent 的 context 保持乾淨。
把「別讓主 agent 自己讀原文」包裝成新 pattern，其實就是把 context window 當 RAM、檔案系統當 swap。方向沒錯，但全文對「subagent 摘錯了怎麼辦」只字未提，髒資料只是被藏到看不見的地方。