LangChain vysvetlil retrieval pre Deep Agents: veľké výsledky majú ísť do súborov a čítanie na subagentov

LangChain v texte „Context Engineering for AI Agents Starts with Retrieval“ z 23. októbra 2026 neposúva Deep Agents ako nový benchmark, ale ako konkrétny návrhový vzor pre dlhobežných agentov. Hlavná téza je jednoduchá: agent s obmedzeným kontextovým oknom zlyháva najmä tromi spôsobmi — hľadá neefektívne, naraz načíta priveľa textu alebo pracuje s irelevantným či zastaraným obsahom. Praktická zmena je v tom, že retrieval už nie je len „nájdi dokumenty“, ale samostatná disciplína context engineeringu: najprv vyhľadať čo najlacnejšie, potom neprenášať veľké payloady priamo modelu a hlučné čítanie izolovať mimo hlavného kontextu.

Deep Agents podľa oficiálnej stránky slúži ako open-source agent harness pre dlhšie úlohy, s plánovaním, správou kontextu a orchestráciou viacerých agentov. Nový blog tak zapadá do už skôr opísanej architektúry, kde sa kontext neriadi iba promptom, ale aj middleware vrstvou, offloadingom a subagentmi.

Primárny dokument odporúča začínať najlacnejším vhodným nástrojom. Vo filesysteme má agent najprv použiť glob na názvy súborov a grep na hľadanie riadkov či kľúčových slov; až keď presné slová nestačia, má prísť sémantické vyhľadávanie nad retrieval nástrojom, napríklad s vektorovým úložiskom. Dôležitý rozdiel oproti bežnému dvojkrokovému RAG je v tom, že výskumný agent nemá hľadať iba raz na začiatku, ale priebežne sa rozhodovať, kedy a čo ešte potrebuje dohľadať.

Druhá časť mechanizmu rieši objem dát. Deep Agents podľa blogu číta súbory po stranách: read_file štandardne po 100 riadkoch a s parametrami offset a limit. Keď výsledok nástroja prerastie približne 20 000 tokenov, harness ho uloží do /large_tool_results/ a model dostane len cestu a krátky náhľad. LangChain rovnaký vzor odporúča aj pre vlastné retrieval nástroje: vyhľadané texty uložiť do súborov a hlavnému agentovi vrátiť iba ich cesty.

Samotné odkladanie veľkých výsledkov ešte nerieši kvalitu. Aj krátky zoznam ciest môže viesť k tomu, že hlavný agent začne otvárať nerelevantné alebo staré texty a zanesie si nimi kontext. Preto blog navrhuje vzor „retrieve, offload, delegate“: hlavný agent spustí vyhľadanie, výsledky sa odložia do súborov a jednotlivé súbory čítajú subagenti. Tí vrátia len kľúčové fakty a zdroj, pričom hlučná časť práce zostane v ich oddelených kontextových oknách.

Pre tím, ktorý stavia firemného výskumného alebo dokumentačného agenta, je to podstatné najmä pri archívoch, exportoch a interných znalostných bázach. Mechanizmus nemá doložený nezávislý benchmark, ale opisuje konkrétne integračné miesto: retrieval nástroj nemá byť len ďalší „tool call“, ale filter, ktorý znižuje, čo všetko sa dostane k hlavnému modelu.

Dôležité je, že všetky podklady pochádzajú od LangChainu. Máme preto dobrý opis zamýšľaného mechanizmu, nie nezávisle overený dôkaz o zlepšení presnosti, ceny alebo latencie. Starší článok o „How Deep Agents Remember“ však potvrdzuje, že retrieval blog nie je izolovaná rada: sedí do širšej schémy Deep Agents, kde sa veľké výsledky offloadujú, starší kontext sumarizuje, špecializované inštrukcie sa načítajú až na požiadanie a subagenti oddeľujú hlučné medzikroky.

Pre vývojára je teda najdôležitejší prenositeľný princíp: ak agent pracuje nad veľkým korpusom, nemal by dostať všetko naraz ani priamo. Má najprv lacno zúžiť priestor hľadania, veľké výsledky odložiť mimo hlavného promptu a samotné čítanie delegovať tam, kde nepoškodí kontext hlavného rozhodovania.