What is Harness Orchestration? — AgentField¶
Szerző: Santosh Kumar Radha (CTO, AgentField) Dátum: 2026-04-23 Forrás: https://agentfield.ai/blog/what-is-harness-orchestration Hossz: ~18 perc olvasás
Összegzés¶
A cikk a harness orkesztráció alapító esszéje — az az írás, ami az egész sorozat előtt jelent meg. Azt írja le, hogy mi változik meg, amikor az intelligencia atomi egysége már nem egy LLM API call, hanem egy teljes harness (autonóm coding agent).
Az absztrakciós létra¶
Minden számítástechnikai ugrás ugyanazt a mintát követi: az atomi egység feljebb mászik, abszorbeálva az alatta lévő komplexitást. Assembly → process → service → container. Most: model call → harness. Ami alatta van, nem tűnik el — csak nem az a szint, ahol dolgozol.
Model call vs. Harness — minőségi különbség¶
A model call állapotmentes, statikus I/O, az orchestrator minden lépést kontrollál. A harness állapotos, ágensi, opak: célt adsz neki, és ő dönti el hogy oldja meg. Az orchestrator nem látja a döntéseket — csak a cél bemegy, az eredmény kijön.
Kompetencia-prediktabilitás inverzió¶
Minél magasabb az absztrakció, annál képességesebb az egység — és annál megjósolhatatlanabb. Ugyanaz a cél, ugyanaz a kódbázis, ugyanaz a modell alatta → két harness hívás teljesen más trajektóriát jár be. Mindkettő lehet helyes. Ez nem hiba, hanem a képesség ára. Ha megpróbálod fix lépéssorra korlátozni, elvetted a képességet amiért fizettél.
Process control → Outcome verification¶
A SWE-AF (saját rendszerük) első verziója "karmester" architektúra volt: pontosan specifikált lépések. Ez egy hétig működött. A megoldás: úgy kell felépíteni mint egy mérnöki szervezetet.
A SWE-AF architektúra szerepekre tagolódik, nem lépésekre:
| Szerep | Felelősség |
|---|---|
| Product manager | Kódbázis olvasása → követelménydokumentum |
| Architect | Követelmények → rendszerterv |
| Sprint planner | Terv → issue DAG függőségekkel |
| Coderek | Párhuzamos munka izolált git worktree-ken |
| QA | Más által írt kód tesztelése |
| Reviewerek | Minőség, biztonság |
| Merger | Párhuzamos branchek merge-elése |
Három egymásba ágyazott kontrollhurok¶
- Inner loop (retry): Coder output nem megy át QA-n → vissza a coderhez hibajelzéssel
- Middle loop (re-scope): Inner loop kimerül → advisor harness belép, split/re-scope/approach change
- Outer loop (replan): Túl sok eszkaláció → replanner harness újrastrukturálja a DAG-et
Ez a minta pontosan ugyanaz, mint a Kubernetes-ben, a cascade kontrollerekben, és a jól működő mérnöki csapatokban. Nem véletlen.
A modell jelentősége csökken¶
Az absztrakció emelkedésével a modell hatása zsugorodik:
- Model-call szinten: A modell szinte mindent meghatároz
- Harness szinten: A tesztelési loop kompenzál — gyengébb modell → több iteráció
- Harness-team szinten: A QA, review, merge rétegek kiküszöbölik a modellkülönbséget
Empirikus eredmény: Claude Haiku frontier és MiniMax M2.5 (tizedannyi költség) → mindkettő 95/100 pont ugyanazon a benchmarkon. Az architektúra kompenzálta a modellkülönbséget.
Verifikáció mint termék¶
Végrehajtás-verifikáció arány: - Model-call szint: 99:1 (szinte csak execution) - Harness: 70:30 - Harness-team (SWE-AF): 31% coder, 44% verifikáció — a rendszer többet költ ellenőrzésre, mint munkára
Ahogy az ágensség nő, a verifikációs igény is nő. A megkülönböztető képesség nem a har-nessek tüzelése, hanem a QA agentek, review agentek, integrációs tesztek, tipizált hiba-propagáció — a hiba nem csak azt mondja meg hogy fail, hanem hogy miért és milyen típusú adaptáció kell.
Konklúzió¶
Az iparág túlsúlyozza a modellképességet és alulsúlyozza a kontrollarchitektúrát. A megbízható eredmény és az alkalmankénti jó eredmény között szinte soha nem a modell a különbség — hanem a verifikációs loopok, az eszkalációs utak, a hiba-taxonómia és a governance struktúra. Ezek mérnöki hozzájárulások, és drámaian alulinvesztáltak a hatásukhoz képest.
A következő lépés: Az absztrakciós létra tovább fog mászni. A mai harness teamek holnap atomi egységek lesznek, amiket a felettük lévő szinten orkesztrálnak. Aki a kialakulóban lévő absztrakciós szintre épít — nem a maira — infrastruktúra-előnyt fog építeni, ami kamatozik.