Harness Engineering: Budování systémů kolem AI agentů (2026)

TL;DR

Co je Harness Engineering?

Harness engineering je disciplína zaměřená na budování systémů, nástrojů, omezení a zpětnovazebních smyček kolem AI kódovacích agentů, aby byli spolehliví a produktivní.

Termín vytvořil Mitchell Hashimoto (spoluzakladatel HashiCorp) a do širšího povědomí se dostal, když OpenAI publikovala svůj článek o Codexu na toto téma začátkem roku 2026.

Hlavní myšlenka je jednoduchá:

Agent = Model + Harness

Model poskytuje inteligenci. Harness činí tuto inteligenci užitečnou. Lepší harness je často důležitější než lepší model.

Proč na tom teď záleží

V roce 2025 přijal AI kódovací agenty každý tým. V roce 2026 jsou vítěznými týmy ty, které navrhly prostředí pro své agenty — nikoli ty, které si jen vybraly nejlepší model.

Hlavní zásada Mitchella Hashimota:

„Kdykoli zjistíte, že agent udělal chybu, věnujte čas inženýrskému řešení, aby agent tuto chybu už nikdy neopakoval.“

Nejedná se o prompt engineering. Je to systémové inženýrství pro AI.

Důkaz: Harness > Model

LangChain provedl kontrolovaný experiment na Terminal Bench 2.0. Bez změny podkladového modelu zlepšili přesnost svého kódovacího agenta z 52,8 % na 66,5 % — což je 26% zlepšení — pouze vylepšením harnessu.

Změny zahrnovaly:

• Lepší kontextové soubory (AGENTS.md)


• Omezení strukturovaného výstupu


• Smyčky vlastní verifikace (self-verification loops)


• Optimalizace nástrojů

7 komponent harnessu

1. Context Engineering

Context engineering je základem. Zde dáváte agentovi mapu vaší codebase, vašich konvencí a vašich omezení.

• Soubory CLAUDE.md / AGENTS.md v kořenovém adresáři repozitáře
• Mapy adresářů a přehledy architektury
• Pravidla stylu kódování a konvence pojmenování

# Příklad CLAUDE.md
## Architektura
- src/app/ — stránky Next.js app routeru
- src/lib/ — sdílené utility a API klienti
- src/components/ — React komponenty (koexistující styly)

## Pravidla
- Výchozí nastavení: server components
- Nikdy neimportovat přímo z node_modules v komponentách
- Všechna API volání jdou přes src/lib/api.ts

2. Architektonická omezení (Architectural Constraints)

Místo doufání, že si agent vybere správnou architekturu, ji vynuťte.

• Striktní vrstvené architektury validované lintery
• Strukturální testy, které selžou při porušení vzorů
• Omezení importů pomocí pravidel ESLint nebo vlastních skriptů

3. Nástroje & MCP servery

Agenti potřebují nástroje, aby byli efektivní. Nejlepší harnessy zpřístupňují interní nástroje prostřednictvím:

• CLI wrappery — preferujte známá CLI (git, docker, npm) před vlastními nástroji
• MCP (Model Context Protocol) servery — umožněte agentům volat vaše interní API, databáze a služby
• Přístup k souborovému systému — omezený na konkrétní adresáře, aby se zabránilo nechtěným škodám

4. Sub-agenti & kontextové firewally

Dlouho běžící relace agentů hromadí kontext, který časem degraduje výkon — to se nazývá degradace kontextu (context rot).

Řešení: sub-agenti s kontextovými firewally.

• Rozdělte složité úkoly na diskrétní sub-úkoly
• Každý sub-úkol běží ve vlastní relaci s čerstvým kontextem
• Mezi agenty předávejte pouze strukturované výsledky, nikoli surovou konverzaci

1. Initializer Agent — plánuje práci, vytváří seznam funkcí (feature list)
2. Coding Agent — provádí každou funkci izolovaně

5. Hooks & Back-Pressure

Automatizované zpětnovazební smyčky, které zachytí chyby dříve, než se nakumulují:

• Pre-commit hooks — kontrola typů, linting, formátování
• Test runners — agenti by měli spouštět testy po každé změně
• Build verification — rychlé selhání u nefunkčních sestavení

6. Smyčky vlastní verifikace (Self-Verification Loops)

Nenuťte agenty k verifikaci vlastní práce před označením úkolu za dokončený:

• Spuštění sady testů po změnách
• Kontrola, zda sestavení (build) projde
• Ověření, zda výstup odpovídá specifikaci
• Pořízení screenshotu a porovnání (pro práci na UI)

7. Dokumentace postupu

Pro dlouhotrvající úkoly (30+ minut):

• Udržujte soubor s postupem (progress file), který sleduje dokončené kroky
• Commitujte práci často, aby následné relace mohly pokračovat
• Používejte strukturované seznamy úkolů, nikoli volné poznámky

Reálné výsledky

OpenAI Codex Team

3 inženýři vyprodukovali milion řádků kódu s nulovým množstvím ručně psaného kódu během 5 měsíců. V průměru dosáhli 3,5 sloučených PR na inženýra za den — propustnost, která je bez vyspělého harnessu nemožná.

Jejich harness zahrnoval: přísné konvence commitů, automatizované testování u každého PR a CI/CD pipelines uzpůsobené pro agenty.

Stripe „Minions“

Interní systém společnosti Stripe produkuje více než 1 000 sloučených PR týdně pomocí AI agentů. Jejich harness obsahuje:

• Úzce vymezené definice úkolů
• Povinné code review lidmi
• Automatizované regresní testování
• Automatizaci rollbacků

Architektura dvou agentů Anthropic

Anthropic zveřejnil svůj přístup k efektivním harnessům pro dlouho běžící agenty:

• Strukturované seznamy funkcí jako formát pro předávání práce mezi agenty
• Sledování postupu založené na Gitu, aby agenti mohli po přerušení pokračovat
• Explicitní kritéria ukončení, aby agenti věděli, kdy přestat

Jak začít stavět svůj harness

Krok 1: Vytvořte kontextový soubor

Přidejte CLAUDE.md (nebo AGENTS.md) do kořenového adresáře projektu:

# Projekt: [Váš projekt]

## Stack
[Framework, jazyk, databáze, hosting]

## Architektura
[Struktura adresářů s jednořádkovými popisy]

## Pravidla
[5-10 striktních pravidel, která agent musí dodržovat]

## Běžné úkoly
[Jak spouštět testy, sestavení, nasazení]

Krok 2: Přidejte architektonická omezení

# Příklad: Pravidlo ESLint zabraňující přímým importům DB v komponentách
# .eslintrc — pravidlo no-restricted-imports

Nastavte pre-commit hooks, které automaticky vynucují vaše pravidla.

Krok 3: Vybudujte verifikační smyčky

Ujistěte se, že váš agent může:

1. Spouštět testy (npm test, pytest atd.)


2. Kontrolovat typy (tsc --noEmit, mypy)


3. Provádět linting (eslint ., ruff check)

Krok 4: Vymezte rozsah relací agentů

Nedávejte agentovi celý svůj backlog. Místo toho:

• Jedna funkce na relaci
• Jedna oprava chyby na relaci
• Jasná akceptační kritéria pro každý úkol

Krok 5: Iterujte na harnessu

Pokaždé, když agent udělá chybu:

1. Identifikujte hlavní příčinu
2. Přidejte pravidlo, omezení nebo hook, který jí zabrání
3. Otestujte opravu

Harness Engineering vs. Prompt Engineering

Prompt engineering je stále užitečný, ale je to jen malá část skládačky. Harness engineering je násobitel.

Nová role: Harness Engineer

Inženýrství se dělí na dvě poloviny:

1. Budování prostředí — vytváření struktury, nástrojů, omezení a zpětnovazebních smyček
2. Správa práce — plánování, revize a orchestrace paralelních relací agentů

Nezaměňovat s: Harness.io

Pokud jste hledali „Harness Engineering“ a očekávali platformu DevOps — Harness.io je zcela jiná věc. Je to CI/CD platforma poháněná AI s hodnotou 5,5 miliardy dolarů (k prosinci 2025), která nabízí kontinuální integraci, doručování, feature flags, správu nákladů na cloud a testování bezpečnosti.

Ačkoli Harness.io a harness engineering sdílejí jméno, řeší odlišné problémy. Existuje však zajímavý průnik: DevOps s podporou AI od Harness.io je v podstatě aplikací principů harness engineeringu na pipeline nasazení.

Sečteno a podtrženo

Model je motor. Harness je auto. Nikdo nevyhraje závod jen s motorem.

Pokud v roce 2026 používáte AI kódovací agenty a neinvestujete do svého harnessu, necháváte většinu hodnoty nevyužitou. Začněte s kontextovým souborem, přidejte omezení, vybudujte verifikační smyčky a iterujte pokaždé, když se něco rozbije.

Týmy, které doručují nejrychleji, nepoužívají lepší modely. Používají lepší harnessy.