Méně promptu, lepší nástroje: agenti potřebují štíhlejší kontext

TL;DR:

• Praktický signál pro agentské systémy je jasný: další instrukce v promptu nejsou automaticky lepší výkon.
• Nová verze Deep Agents v0.7 snížila vstupní tokeny základního promptu, nástrojů a middleware o 65 procent při srovnatelném výkonu.
• Důležitější než dlouhé vysvětlování agentovi začínají být přesná schémata nástrojů, jasně složený kontext a měření výsledků.
• Plánovací middleware nemusí být výchozí volba pro každého agenta; u některých úloh přidává cenu a složitost bez viditelného přínosu.
• Při úpravě agenta porovnávej výsledek proti evaluační sadě, ne jen proti několika povedeným ukázkám.

Představ si interního agenta, který má zpracovat požadavky od zákazníků, dohledat údaje v dokumentaci a připravit odpověď pro člověka. Původní zadání má dlouhý systémový prompt, několik příkladů, pravidla pro práci s nástroji a ještě automatický seznam úkolů. Agent funguje, ale každé spuštění je dražší, pomalejší a hůř se ladí. Když přidáš další instrukci, nevíš, jestli jsi pomohl přesnosti, nebo jen zvětšil šum.

Tohle je čím dál běžnější problém. První vlna práce s agenty často stála na vrstvení instrukcí: když model udělal chybu, připsalo se další pravidlo. Jenže agent není lepší jen proto, že dostane delší text. U složitější práce rozhoduje, jaký kontext skutečně potřebuje, jak přesně jsou popsané nástroje a jestli změny měříš na úlohách, které se podobají reálnému provozu.

Dlouhý prompt se snadno stane technickým dluhem

LangChain vydal 29. července 2026 Deep Agents v0.7 a zajímavý není jen samotný release. Zajímavé je, co z něj mizí. Nová verze zjednodušuje základní agentní harness, tedy základní obsluhu agenta, která skládá prompt, nástroje a middleware před voláním modelu. Podle zdroje tím klesly vstupní tokeny základního promptu, nástrojů a middleware o 65 procent při srovnatelném výkonu.

To je dobrý pracovní signál i mimo konkrétní framework. Když agentovi přidáváš další obecné rady, bezpečnostní formulace, příklady a opakované instrukce, roste cena každého běhu. Zároveň se zhoršuje čitelnost systému pro tým. Po několika měsících už často nikdo přesně neví, která věta je nutná, která je historická oprava jedné chyby a která jen opakuje pravidlo, které už je zapsané u nástroje.

U malého týmu to vypadá nenápadně. Freelancer si vytvoří agenta pro rešerši zakázek, konzultant agenta pro přípravu podkladů k jednání, zakladatel agenta pro třídění zpětné vazby od zákazníků. Všude se rychle objeví pokušení připsat do promptu další odstavce: buď pečlivý, ověřuj zdroje, nejdřív plánuj, potom jednej, nepřeskakuj kroky. Část z toho je užitečná. Část ale patří spíš do návrhu nástroje, vstupního formuláře nebo následné lidské kontroly.

Rozhraní nástroje učí agenta lépe než omáčka okolo

Jedna z hlavních změn v popsané verzi je zkrácení vestavěných popisů nástrojů o 43 procent. To neznamená, že popisy nástrojů nejsou důležité. Znamená to spíš opak: mají být přesné, ne dlouhé.

Schéma nástroje říká agentovi, co může udělat, jaké parametry má vyplnit a jaký výsledek může čekat. Když je schéma jasné, agent nepotřebuje tolik obecných příkladů v systémovém promptu. Když je nejasné, ani dlouhý prompt to často nezachrání. Model pak hádá, kdy nástroj použít, jak poskládat vstupy a co znamená úspěšný výsledek.

Praktická kontrola je jednoduchá. Vezmi jeden nástroj, který agent používá často, a přečti si jeho popis bez zbytku promptu. Je z něj jasné, kdy se má použít? Jsou vstupy pojmenované podle práce, kterou člověk opravdu dělá? Neopakuje popis jen obecné instrukce typu piš stručně, buď přesný, postupuj systematicky? Pokud ano, problém není v tom, že agent má málo pravidel. Problém je, že pravidla nejsou na správném místě.

Plánování má být volba, ne reflex

Další změna je přesunutí TodoListMiddleware mimo výchozí nastavení. Jde o middleware pro plánování úkolů, který agentovi přidává možnost vést si seznam kroků. Zdroj výslovně neříká, že plánování je zbytečné pro všechny agenty. Říká praktičtější věc: v jejich ověření plánovací prompt a nástroj pro zápis úkolů významně nezlepšily výkon u výchozího nastavení.

Pro práci v týmu je to důležitý rozdíl. Plánování se hodí u dlouhých úloh, kde agent musí rozdělit práci, vracet se k mezivýsledkům a hlídat si závislosti. Může dávat smysl u analýzy většího dokumentu, přípravy datového výstupu nebo složitějšího zásahu do kódu. U krátké klasifikace, vyplnění šablony nebo jednoduchého vyhledání údaje může být plánovací vrstva jen režie navíc.

Dobré pravidlo zní: nepouštěj plánování všude jen proto, že působí zodpovědně. U každého typu agenta si napiš, kde má plán změnit výsledek. Pokud neumíš říct, co přesně se díky němu zlepší, nastav ho jako volitelný režim pro složitější úlohy. Tím snížíš náklady a zároveň neztratíš možnost použít plán tam, kde opravdu pomáhá.

Bez evaluační sady jen hádáš, co se zlepšilo

Největší praktická lekce není samotné osekání promptu. Je to způsob ověření. Výkon nové verze byl podle zdroje porovnán pomocí evaluační sady ve třech kategoriích: autonomní úlohy, konverzace s více koly a úlohy s dlouhým kontextem. Evaluační sada tady znamená sada testů, na kterých porovnáváš chování agenta po změně proti dřívějšímu stavu.

Tohle je přesně místo, kde se agentské systémy lámou mezi pokusem a provozem. Když prompt upravíš a zkusíš tři příklady ručně, většinou najdeš potvrzení toho, co chceš vidět. Jeden výstup je hezčí, druhý je rychlejší, třetí náhodou vyjde. Jenže reálný agent bude narážet na neúplná zadání, dlouhé vstupy, nejasné konverzace a nástroje, které občas vrátí nečekaný výsledek.

Nemusíš hned budovat velkou testovací infrastrukturu. Pro menší tým stačí začít sadou reprezentativních případů. Dej dohromady deset až dvacet úloh, které agent skutečně řeší: snadné, hraniční i nepříjemné. U každé si napiš, co znamená přijatelný výsledek. Při změně promptu, modelu, nástroje nebo middleware pak nehodnoť jen dojem. Porovnej přesnost, počet zbytečných kroků, cenu, rychlost a míru zásahu člověka.

Co udělat při příští úpravě agenta

Příští změnu agenta nezačínej otázkou, co dalšího mu napsat do systémového promptu. Začni inventurou kontextu. Označ duplicitní instrukce, obecné rady, zastaralé opravy a pravidla, která by měla být součástí schématu nástroje. Potom vyber jednu vrstvu, kterou změníš, a porovnej výsledek proti původní verzi.

U každého agenta si polož tři otázky. Co musí model vědět předem, aby úlohu vůbec pochopil? Co má být popsáno přímo u nástroje, protože to souvisí s jeho použitím? Co nemá rozhodovat model, ale člověk nebo pevné pravidlo v systému?

Tahle disciplína je méně efektní než další dlouhý prompt, ale v provozu je užitečnější. Agent má dostat právě tolik kontextu, kolik potřebuje pro dobré rozhodnutí. Zbytek patří do rozhraní nástrojů, měření a lidské kontroly.

Zdroj

LangChain Blog: Deep Agents v0.7 https://www.langchain.com/blog/deep-agents-v0-7