想像你考開書考：答案明明喺書入面，但你照樣揾唔到。唔知從邊度揾起、邊個來源算對、點樣先至唔使重複翻。將呢個問題畀個 AI agent（即能自己調用工具、多步執行任務嘅大模型），情況一樣。
佢有一個有限嘅 context window（上下文窗口，模型一次可以處理嘅資訊量上限），所以唔可以乜都記住，要即時間即地「揾」資料。而揾嘢呢件事，agent 有三大死穴。
第一，搜得冇效率。 每次搜尋都要花 token 同時間。一個唔識搜嘅 agent 會開晒成個資料夾，或者同一句 query 換十個寫法，未揾到乜嘢，context window 已經被搜尋結果塞爆。
第二，一次塞太多。 一次搜尋倒出一個完整 data export 或者十幾份文件，context window 當即冇位畀真正嘅工作。
第三，揾到嘅嘢唔關事或者過時。 舊嘅、離題嘅資訊對模型嚟都「睇落好似」正確答案，入咗 context window，agent 會照住繼續落去做，錯就錯入每一步。
呢三件嘢嘅解方，要由 harness（agent 底層執行架構）層面處理。LangChain 佢哋嘅 Deep Agents harness 喺今個博客（2026 年 10 月 23 日）寫晒佢哋點做：
- 內建檔案系統工具「先搜先讀」。 glob 匹配檔名、grep 揾符合嘅行、read_file 一次只讀一頁。唔係開晒個文件睇到邊算邊。
- 過載結果卸載（offload）。 太大嘅工具輸出，完整內容寫去檔案，agent 只收到路徑同一個 preview。
- 自訂搜尋工具（例如 RAG，即以檢索增強生成，先搜尋再餵資料畀模型）用「retrieve、offload、delegate」三步驟： 結果存檔、回傳路徑、交給子代理（subagent）去讀。主 agent 只見到同任務相關嘅部分。
佢哋用一個具體例子示範：一個每週一要研究幾百家競品、寫報告嘅 competitive analysis agent，要揾上一週筆記、喺大型市場數據導出揾某個 revenue 數字、喺新聞檔案庫揾最新新聞。三種不同類型嘅 retrieval，面對嘅困難唔同，呢套技術就對症下藥。
阿調搞兩下。 呢篇係廠商嘅技術博客，講自己產品嘅設計哲學，冇獨立測試。但佢指出嘅呢三個失敗模式，同我哋日常見識到嘅 agent 行為（開晒個文件夾先讀、一次塞成個 PDF、照住舊數據入面嘅錯數繼續落去）完全吻合。點改善、用乜框架，呢個係 harness 設計者要答嘅問題，唔係 model 自己可以解決嘅。
