Better Harness od Qoderu prověřuje, zda workflow AI agenta skutečně funguje

Better Harness je open-source projekt Qoderu pro kontrolu a zlepšování workflow kolem programovacího agenta. Nehodnotí jen jednu odpověď modelu nebo jeden diff v kódu. Prověřuje instrukce v projektu, pravidla a oprávnění, cesty validace, konfiguraci agenta a – pokud jsou dostupné – také záznamy z reálných relací. Cílem je najít slabinu v procesu, navrhnout přiměřeně úzkou opravu a při dalším spuštění ověřit, zda změna obstála. 124

Podle dobového zpravodajství Qoder projekt otevřel na GitHubu 28. července 2026. 5

Nehodnotí jen model, ale celé jeho pracovní prostředí

Programovací agent nepracuje ve vzduchoprázdnu. Je součástí systému tvořeného pokyny v repozitáři, specifikacemi, nástroji, oprávněními, skripty, testy, požadavky na code review, kontrolami před vydáním i předáváním práce lidem. Qoder toto okolí označuje jako harness – volně řečeno provozní rámec agenta. Podle dokumentace může zahrnovat pokyny v repozitáři, pravidla, dovednosti (skills), hooky, pluginy, konektory, skripty, testovací příkazy, release kontroly a kroky lidské revize. 2

To je podstatné: i schopný model může dávat nespolehlivé výsledky, pokud je proces kolem něj nejasný nebo špatně měřitelný. Projekt například může mít testovací příkaz, ale agent nemá jasně určeno, kdy jej spustit. Může existovat soubor s pravidly, který agent ve skutečnosti nepoužívá. Nebo chybí způsob, jak z neúspěšného úkolu uchovat poučení pro příště. Better Harness má takové provozní mezery odhalovat – místo aby samotnou existenci konfigurace považoval za důkaz funkčního procesu. 145

Tři vrstvy: praxe, hodnocení a provedení

Better Harness je popisován jako třívrstvý rámec, který spojuje inženýrské praktiky, hodnoticí model a použitelnou implementaci. 5

1. Praktiky Harness Engineering

První vrstva pokrývá konkrétní mechanismy, které formují práci agenta: vzory pro relace a příkazový řádek, pozorovatelnost, pravidla, dovednosti, konfiguraci MCP, paměť, hooky a automatizaci. 5

V praxi odpovídá na otázky typu:

• Má agent jasně zadané cíle, omezení a kontext repozitáře?
• Jsou jeho možnosti spouštět nástroje a oprávnění přiměřeně řízené?
• Navazují na jeho práci testy, kontroly a revize?
• Mohou se užitečná zjištění stát udržovanou součástí projektu, místo aby zmizela s koncem relace?

Better Harness nejdříve zmapuje stávající rámec: cíle, kontext, vstupní body pro provádění práce, zpětnovazební smyčky, mechanismy doručení a zachycení poznatků. 1

2. Hodnocení pracovního cyklu agenta

Druhá vrstva převádí tyto praktiky do hodnocení pěti navazujících oblastí: porozumění úkolu, řízené provedení, validace změn, spolehlivé doručení a zachycení poznatků. 14

Otázka se tak posouvá od „vygeneroval agent uvěřitelný kód?“ k provozně užitečnějšímu testu: dokáže celý workflow opakovaně vytvářet změny, které jsou srozumitelné, řízené, ověřené, doručitelné a poučené předchozí prací?

Model má hledat místa, kde se tento cyklus láme – například chybějící mechanismus, odpojenou integraci, krok, který nebyl skutečně spuštěn, nebo nedostatečný důkaz výsledku. 1

3. Spustitelná implementace

Třetí vrstva převádí praktiky a hodnoticí model do podoby použitelné v reálných projektech, nikoli jen do souboru doporučení. Better Harness běží prostřednictvím programovacího agenta, shromažďuje důkazy z projektu a tam, kde to prostředí umožňuje, také z relací. Následně vytváří prioritizované kroky, které lze ověřit. 4

Aktuální materiály projektu uvádějí podporu deseti hostitelských adaptérů. Zprávy při uvedení konkrétně zmiňovaly mimo jiné prostředí Claude Code, Codex, Qoder a Cursor. 56

Podpora adaptérů se může měnit, proto je vhodné konkrétní integraci ověřit v aktuální dokumentaci projektu. Dodané zdroje zejména nepotvrzují podporu OpenClaw.

Tři druhy důkazů místo pouhého dojmu

Důležitou součástí přístupu je oddělení sběru důkazů od výsledného hodnocení. Qoder uvádí, že hlavní analytický tok nejprve shromáždí surová data a pak je předá třem nezávislým subagentům v režimu pouze pro čtení; teprve poté se výsledky spojí. 1

Posuzují se tři perspektivy:

• Project Harness: inženýrské základy repozitáře, například instrukce, skripty, kontroly a mechanismy doručení.
• Agent Customization: pravidla, dovednosti, hooky a další konfigurace konkrétního agenta.
• Session Evidence: záznamy o tom, co agent při skutečné práci opravdu dělal, pokud jsou tyto údaje k dispozici.

Toto rozdělení pomáhá odlišit zamýšlený proces od pozorovaného. Důkazy z projektu a konfigurace mohou ukázat, že určitá schopnost je k dispozici. Záznam relace pak může doložit, zda ji agent při konkrétním úkolu vhodně použil. 14

Soubor existuje. To ale ještě neznamená, že proces funguje

Nejužitečnější princip rámce zní jednoduše: existence artefaktu není důkazem jeho účinnosti.

Představme si repozitář s automatizovanými testy. Přítomnost testů dokládá potenciální schopnost. Sama o sobě ale neprokazuje, že agent po změně spustil relevantní testy, výsledek správně vyhodnotil a použil jej k tomu, aby zabránil chybnému nasazení. Totéž platí pro pravidla, hooky, dovednosti i schvalovací brány. 15

Better Harness proto usiluje o explicitní řetězec důkazů. Report převádí doložené nedostatky do prioritizovaných zjištění (findings), u nichž uvádí dopad, očekávaný výstup, rozsah opravy a akceptační kontroly. Chybějící důkazy nezakrývá ani je automaticky nemění ve vysoké hodnocení. 46

Pro tým by pak každé zjištění mělo být kontrolovatelné ve čtyřech bodech:

1. Co bylo pozorováno v projektu, konfiguraci nebo záznamu relace.
2. Proč na tom záleží pro pracovní cyklus doručování změn.
3. Jaká úzká oprava je navržena, například pravidlo, dovednost, hook, skript, automatizace nebo lidské schválení.
4. Jak opravu ověřit po jejím zavedení.

Zlepšování v cyklu: prověřit, opravit, přeměřit

Better Harness není navržen jako jednorázový audit. Jeho postup je iterativní:

1. Zmapovat současný pracovní rámec.
2. Najít místa přerušení workflow a mezery v důkazech.
3. Vytvořit omezený úkol k opravě doloženého problému.
4. Ověřit opravu podle předem určených akceptačních kontrol.
5. Spustit kontrolu znovu a prověřit nové důkazy. 14

Na tom stojí tvrzení o průběžném zlepšování. Nástroj může ukázat, že se workflow změnilo, a zda nově dostupné důkazy podporují lepší hodnocení. Sám o sobě však neprokazuje, že konkrétní oprava způsobila lepší výkon agenta ve všech projektech nebo hostitelských prostředích. Materiály Qoderu zdůrazňují pozorované důkazy a jasně uvedená omezení, nikoli změny skóre jako důkaz příčinné souvislosti. 46

Jak číst zmínku o 30 projektech na GitHubu

Zprávy při uvedení projektu uváděly počáteční použití rámce na 30 reálných projektech na GitHubu. 5 Je vhodné to chápat jako průzkumné nasazení, nikoli jako kontrolovaný důkaz, že Better Harness zlepší každý programovací agent nebo každý repozitář.

Dostupná primární dokumentace podporuje popis důkazního modelu, struktury zjištění i iterativního postupu oprav. Dodané zdroje však neposkytují dostatek primárních detailů pro nezávislé posouzení výběru vzorku, metodiky skórování nebo souhrnných výsledků této třicetiprojektové analýzy. To je důležité při srovnávání Better Harness s formálními benchmarky nebo při formulaci širokých tvrzení o výkonu. 14

Krok k měřitelnějšímu inženýrství agentů

Širší argument Qoderu zní, že by se Harness Engineering měl stát součástí infrastruktury kvality pro vývoj softwaru s pomocí AI: sdílenou slovní zásobou pro řízení workflow, pozorovatelnými důkazy, srovnatelnými oblastmi doručování a opakovatelnými cykly zlepšování. 12

Better Harness tuto myšlenku převádí do praktického nástroje. Týmům dává způsob, jak napříč podporovanými hostitelskými prostředími prověřit podmínky práce agentů, debatovat nad důkazy místo dojmů a zkoušet, zda navržená oprava workflow obstojí i při dalších bězích. Jeho přínosem není záruka, že každá změna zlepší výsledek. Je jím disciplinovanější způsob, jak workflow agentů učinit kontrolovatelným, přezkoumatelným a vyvratitelným. 46