LongHorizon-Harness
Vytvořeno: 25.8.2026 | Aktualizováno: 25.08.2026 15:59
LongHorizon-Harness je open-source harness pro dlouhé agentní úlohy. Nestaví nový model ani nenahrazuje Claude Code nebo Codex; obaluje je řídicí smyčkou, která rozděluje práci na malé kroky, uchovává jen ověřený stav a nenechá agenta hodnotit vlastní práci bez nezávislé kontroly.
Proč je potřeba
Agent při dlouhé práci naráží hlavně na tři problémy: roste mu historie, hromadí se chyby a ztrácí přehled o skutečném stavu projektu.
- METR měří 50% časový horizont: délku práce vyjádřenou časem zkušeného člověka, kterou agent dokončí alespoň v polovině případů. Ve studované sadě převážně softwarových a výzkumných úloh se tento horizont od roku 2019 zdvojnásoboval přibližně každých 7 měsíců. Není to tvrzení, že agent spolehlivě dokončí libovolně dlouhou práci.
- Context Rot testoval 18 modelů při postupně delším vstupu, až k milionu tokenů. Při stejné obtížnosti úloh se výkon s délkou vstupu zhoršoval; milion tokenů tedy neznamená milion stejně spolehlivých tokenů.
- Studie The Self-Correction Illusion zjistila statisticky významné zlepšení explicitního rozpoznání chyby v 10 z 12 kombinací modelu a domény. Při předložení stejného chybného tvrzení jako externího vstupu byl nárůst 23,3 až 93,3 procentního bodu. To vysvětluje, proč má oddělený auditor praktický smysl.
Smyčka Manage–Execute–Audit
Základ frameworku popisuje článek LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks. Práce není jedna dlouhá relace, ale opakování tří rolí:
- Manager drží původní cíl, ověřený stav a auditní důkazy. Vybere jeden omezený další krok včetně akceptačních kritérií. Nemá přímý přístup k souborům, terminálu ani GUI.
- Executor dostane čerstvý kontext, kontrakt pro konkrétní krok a potřebné ověřené informace. Je jediná role, která záměrně mění pracovní prostředí.
- Auditor dostane výsledek Executora jako cizí tvrzení a nezávisle zkontroluje skutečné soubory, testy, logy nebo stav aplikace. Má pracovat pouze pro čtení.
Jen závěr Auditora může změnit trvalý stav úlohy. Pokud audit neprojde, Manager vidí důkazy o selhání a připraví opravu nebo jiný další krok. Hrubá historie práce Executora se po kole nezachovává; mezi koly zůstává kompaktní stav a auditní reporty.
Příklad: místo zadání „vytvoř celou aplikaci“ Manager připraví krok „přidej přihlášení s e-mailovým heslem; test musí ověřit úspěšné přihlášení i odmítnutí špatného hesla“. Executor jej implementuje. Auditor pak nespokojí s tvrzením „hotovo“, ale spustí testy a podle potřeby provede end-to-end kontrolu v prohlížeči.
Metriky z paperu
Následující tabulka porovnává běžný Claude Code a LongHorizon-Harness se stejným backbone tam, kde to autoři měřili přímo. PassRate znamená podíl zcela splněných úloh, Binary vyžaduje finální skóre 1 a Partial je průměrné dílčí skóre.
| Benchmark | Model a backend | Claude Code bez LHH | LongHorizon-Harness |
|---|---|---|---|
| WeaveBench (114 GUI+CLI úloh) | Qwen 3.7-Plus, Claude Code | PassRate 51,8 %; Overall 0,702 | PassRate 80,7 %; Overall 0,835 |
| OSWorld 2.0 (108 desktopových úloh) | Qwen 3.7-Plus | Binary 2,8 %; Partial 21,5 % | Binary 8,3 %; Partial 35,2 % |
| Terminal-Bench 2.1 | Qwen 3.7-Plus, Claude Code | Success rate 69,7 % | Success rate 77,2 % |
| OSWorld 2.0, podmnožina 34 úloh | Claude Opus 4.7 | Binary 20,6 %; Partial 55,8 % | Binary 35,3 %; Partial 66,9 % |
Nejvýraznější je trojnásobný nárůst binárního dokončení na OSWorld 2.0: 2,8 % na 8,3 %. Znamená to ale jen to, že úloha splnila všechna benchmarková kritéria; neznamená to trojnásobnou obecnou schopnost modelu.
Autoři uvádějí i prakticky důležitou cenu za vyšší spolehlivost:
- Na OSWorld 2.0 stoupla průměrná spotřeba výstupních tokenů z 28,9 tisíce na 104 tisíc na úlohu, tedy zhruba 3,6×.
- Na WeaveBench spotřeboval framework 2,3× více tokenů než baseline.
- Na Terminal-Bench 2.1 naopak spotřeboval o 24 % méně tokenů a současně dosáhl vyšší úspěšnosti.
- Samotný Auditor tvořil 19,4 % tokenů na WeaveBench, 24,8 % na OSWorld a 38,1 % na Terminal-Bench. Kontrola není levný doplněk, ale podstatná část celého přístupu.
Závěr není „tři role vždy stojí trojnásobek“. Náklady závisí na úloze, schopnosti Executora a počtu kol nutných pro opravy.
Případové studie: proč nestačí výsledek, který vypadá dobře
Paper obsahuje konkrétní trajektorie, které video používá jako názorné příklady. Jde o skóre jednotlivých benchmarkových úloh, ne o obecnou míru úspěšnosti frameworku.
- Wireshark / WebRTC simulcast audit: základní Claude Code se stejným Qwen 3.7-Plus zůstal více než 400 kroků ve smyčce kolem nereagujícího dialogu a skončil na skóre 0,59. LHH zapsal selhání jako nevyřešený stav, další kolo dohledalo chybějící grafy a paketové důkazy a výsledné skóre bylo 0,92.
- LibreOffice: úkolem bylo naformátovat 15 nadpisů. Baseline přepsal XML přímo, takže dokument na pohled vypadal dobře, ale nedodržel povinnost provést změnu přes LibreOffice; skóre bylo 0,00. LHH provedl GUI workflow a Auditor ověřil podkladový styl všech 15 nadpisů; skóre bylo 0,89.
- LibreOffice Calc: pro opravu vzorců a zachování důkazů před opravou i po ní se skóre zvedlo z 0,45 na 0,87. Auditor zde kontroloval celou posloupnost devíti screenshotů.
- Chrome DevTools: při sběru výkonového důkazu se skóre zvedlo z 0,53 na 0,85, protože dokončená optimalizace zůstala ve stavu a další Executor se soustředil jen na chybějící důkazy.
Toto je hlavní hodnota frameworku: neudělá model lepším v matematice, vidění nebo algoritmizaci. Může ale zabránit tomu, aby už ověřený pokrok zanikl v dlouhé historii nebo aby vizuálně věrohodný výsledek prošel bez kontroly postupu.
Video: tři dny autonomního vývoje
Ve videu Nechal jsem AI 3 dny bez dozoru. Tohle postavila. Marek Bartoš vysvětluje princip na vlastním projektu Skippy Workouts.
Je potřeba oddělit čísla z osobní demonstrace od benchmarků v paperu. Následující hodnoty jsou tvrzení autora videa, nikoli nezávisle replikovaný benchmark:
- autonomní vývoj trval 3 dny;
- před vznikem produkčního kódu vzniklo přes 3 000 řádků přípravy, rozboru zadání a definic hotového stavu;
- specifikace se rozdělila do 8 fázových kontraktů a záměr do 7 oddělitelných systémů;
- AI před během opravila 3 autorovy technické předpoklady;
- vznikly stovky automatizovaných testů;
- během třídenního běhu se systém 4× zastavil nad neúplnými nebo vadnými pravidly a podle autora je dokázal bez zásahu opravit, případně upravit zadání.
Video také správně upozorňuje, že běžný agent může opakovat neúspěšný krok velmi dlouho: v ukázce Wiresharku šlo o více než 400 kroků. Důležitější než vytrvalost je proto schopnost převést selhání do ověřeného stavu, na který další krok skutečně reaguje.
Rozpor v počtu kol
Video mluví o maximálně 40 iteracích. Tuto hodnotu nelze bez kontextu brát jako aktuální výchozí nastavení. Paper použil pro své experimenty maximum 25 kol. Ve zdrojovém kódu verze 0.1.7 je výchozí hodnota také 25, zatímco README v témže repozitáři uvádí 30. Jde tedy o nekonzistenci dokumentace nebo o změnu mezi konfiguracemi.
Pro vlastní běh je bezpečnější nastavit limit explicitně, například:
lh-harness run --task @task.md --agent claude_code --max-rounds 5 --no-dashboard
Co framework přidává nad Claude Code
Claude Code už umí plánovat, pracovat s nástroji a udržovat kontext. LongHorizon-Harness nad něj přidává hlavně:
- oddělený, auditovaný stav úlohy mimo rostoucí konverzaci;
- čerstvý kontext Executora v každém kole;
- kontrakt s hranicemi a kritérii přijetí pro jeden krok;
- nezávislou kontrolu prostředí před tím, než se změna zapíše jako hotový pokrok;
- dashboard, auditní stopu a možnost pokračovat nebo zastavit běh.
To odpovídá principům z článku Effective harnesses for long-running agents: postupovat po malých ověřitelných funkcích, používat Git a průběžný záznam práce, po každé relaci ponechat projekt v čistém stavu a neoznačovat položku za hotovou bez end-to-end ověření.
Instalace a první běh
Pro CLI workflow je potřeba Python 3.10+ a alespoň jeden agentní runtime v cestě, například `claude`, `codex` nebo `opencode`. Pro ovládání desktopových aplikací je navíc nutný podporovaný computer-use plugin a oprávnění operačního systému.
Nejbezpečnější je začít v samostatném Git repozitáři, ne v produkčním projektu:
# Nejprve se přihlásit do Claude Code, pokud se má použít předplatné claude # Instalace harnessu uv tool install lh-harness # V adresáři testovacího projektu lh-harness init lh-harness doctor # Krátký první běh bez dashboardu lh-harness run --task @task.md --agent claude_code --max-rounds 5 --no-dashboard
Soubor `task.md` by měl obsahovat konkrétní cíl, omezení a ověřitelné Definition of Done. Příkaz `lh-harness run` standardně pracuje v aktuálním adresáři, proto je izolovaný workspace důležitý.
Claude Code předplatné nebo API klíč
API klíč není pro Claude Code povinný. Volba pro předání API klíče je v LongHorizon-Harness volitelná; pokud ji nepředáš, adapter spustí CLI `claude` a použije jeho existující přihlášení. Pro lokální použití s aktivním předplatným Claude Code tedy stačí se nejdřív přihlásit přes `claude`.
API klíč je vhodný nebo nutný, pokud:
- běh probíhá v CI nebo na headless serveru bez interaktivního přihlášení;
- je potřeba řídit náklady podle tokenů nebo používat samostatný billing;
- používá se proxy, vlastní kompatibilní endpoint nebo jiný poskytovatel modelu;
- jednotlivé role mají používat různé modely mimo účet Claude Code.
Předplatné Claude Code nepokrývá volání modelů jiných poskytovatelů. Také je potřeba počítat s tím, že Manager, Executor a Auditor znamenají opakované samostatné invokace modelu. Dlouhý běh proto může narazit na usage limity předplatného dříve než běžná interaktivní práce v Claude Code.
Bezpečnost a omezení
Executor má měnit skutečné prostředí. Claude Code adapter ve frameworku spouští Claude v režimu přeskočení potvrzování oprávnění; omezení rolí se realizuje hlavně seznamem zakázaných nástrojů. Nejde o bezpečnostní sandbox.
Nespouštět první úlohy proti produkci, na hostiteli s citlivými přístupy nebo v hlavní větvi důležitého repozitáře. Vhodný postup je samostatný workspace, omezený počet kol, Git commit před během, testovací data a průběžná kontrola dashboardu či auditních reportů.