The Harness as Black Box — An Engineer's Guide to Harness Orchestration, Part 1¶
Szerző: Santosh Kumar Radha (CTO, AgentField) Dátum: 2026-04-29 Forrás: https://agentfield.ai/blog/harness-as-black-box Hossz: ~21 perc olvasás, 5 részes sorozat első darabja
Összegzés¶
A cikk amellett érvel, hogy a harness (autonóm coding agent, mint Claude Code/Codex/Gemini CLI) egy alapvetően új típusú számítástechnikai objektum — nem egyszerűen egy LLM extrákkal. A korábbi orkesztrációs patternek (prompt chain, output parser, tool-use graph) nem transzferálhatók erre a szintre.
Két hívási forma¶
| Constrained Call | Harness (autonomous loop) | |
|---|---|---|
| Példa | .ai() — szöveg be, parsolt objektum ki |
.harness() — cél be, munkakönyvtár, eredmény ki |
| Döntés | Az orchestrator irányít | A harness dönt |
| Eszközök | Nincs | Fájl írás/olvasás, parancs futtatás, API hívás |
| Állapot | Állapotmentes | Perzisztens (filesystem, memória) |
Három megkülönböztető tulajdonság¶
- Agency (ágensség) — önállóan kezdeményez munkát
- Embodiment (megtestesülés) — valódi hatást gyakorol a világra (fájlok, processzek, API-k)
- Persistence (perzisztencia) — állapotot hordoz időn át
A három tulajdonság Descartes-szorzata 8 cellát ad. Csak a harness foglalja el azt a cellát, ahol mindhárom egyszerre jelen van. Ez a kombináció produkál minden építészeti kihívást.
Variance Absorption (variancia-elnyelés)¶
A harness leghasznosabb tulajdonsága: ugyanaz a hívási forma képes bugfixet, feature-t és refaktort is kezelni, munkakönyvtár és prompt függvényében. Nincs szükség feladattípusonkénti pipeline-ra.
Empirikus bizonyíték: 40 azonos feladat ugyanazon modellen → 25 különböző git diff, de mind a 40 átment a verifieren. A trajektóriák divergálnak, az eredmények konvergálnak.
Attractor states: Egy megoldás 9-szer ismétlődött a 40-ből, 19 megoldás egyszeri volt. A harnessnek "vonzási pontjai" vannak — a modell priorja érvényesül.
A Membrán¶
A harness nem fekete doboz — membránja van. Szelektíven áteresztő határfelület: - Átenged: cél, konfiguráció, strukturált eredmény - Aktív munkával átengedhető: döntési racionálék, köztes állapot (journal) - Soha nem megy át: belső token stream, átmeneti munkamemória
A lényeg: A harness orkesztráció = szerződések, határok és verifikációk tervezése olyan intelligenciák között, amikbe nem látsz bele. Közelebb áll a szervezeti menedzsmenthez, mint a szoftverfejlesztéshez.
Három következmény az orchestrator számára¶
- Process control → Outcome verification — nem azt ellenőrzöd hogy a 3. lépés jó volt-e (nem látsz bele), hanem hogy a végeredmény átmegy-e a verifieren
- Prompt engineering → Membrane engineering — a határfelület (tool-ok, könyvtár, budget, sikerfeltételek) fontosabb, mint a prompt szövege
- Az orchestrator supervisorrá válik — nem a munkát specifikálja, hanem a feltételeket amik között a munka elfogadható
A sorozat további részei¶
- Part 2: Engineering the Membrane — a határfelület paraméterei
- Part 3: Contracts as Architecture — harnessek kompozíciója, verifierek mint join-ok
- Part 4: Generative Pipelines — önmódosító pipeline-ok, biológiai fejlődéshez hasonló növekedés
- Part 5: Operating Opaque Intelligence — produkciós failure mode-ok (goal drift, verifier gaming, sycophancy cascades, attractor collapse)
Kapcsolódó: A szerző csapata open-source harness orkesztrátorokat épít: SWE-AF, sec-af, cloudsecurity-af, af-deep-research, af-reactive-atlas-mongodb. A harness primitív nyílt forráskódú (Apache 2.0).