Cseréld le a GPT-5-öt Claude-ra egy működő agensben, és az esetek többségében szinte semmi sem változik. Változtasd meg, hogyan kezeli az újrapróbálásokat, mit táplálsz a kontextusablakba, vagy mikor dönt a megállásról, és az egész agens másképp viselkedik. Ez a rés az árulkodó jel: a modell egy működő agens legkisebb és legkönnyebben cserélhető része. Az érdekes mérnöki munka mindenben lakozik, ami körülveszi.
Ennek a wrappernek most már van neve. A szakemberek a "harness" kifejezést fogadták el arra a rétegre, amely egy szöveggenerátorból valami olyat csinál, ami idővel cselekvéseket hajt végre, nem pedig rögzített szkriptet futtat. A kifejezés 2026 elején gyorsan elterjedt a Twitteren és a mérnöki blogokon, ami azt is jelenti, hogy lazán használták, ugyanaz a szó kicsit különböző munkát végzett minden egyes bejegyzésben. Ez a cikk pontosan meghatározza: mi a harness, miből áll, miben különbözik egy "framework"-től és egy "scaffold"-tól, és miért rejtőzik az agent minőségének nagy része a harnessben, nem a modellben.
A rövid verzió
- Az agent harness az LLM körüli szoftver, amely kezeli a végrehajtási ciklust, az eszközöket, a memóriát, a kontextust, az állapotot, a hibakezelést és a korlátokat. A modell szöveget generál; a harness dönti el, hogy mit lát a modell, mit tehet, mikor kell megállni és mi történik, ha valami elromlik.
- Éles üzemben a modellhívás gyakran a rendszer felületének legkisebb látható része. Egy gyengébb modell egy jól megépített harnessben legyőzhet egy erősebb modellt egy hanyagban, különösen hosszan futó, eszközigényes feladatoknál.
- Egy harnessnek nagyjából kilenc-tizenegy visszatérő összetevője van. Legtöbbjük olyasmi, amit a modell soha nem érint közvetlenül.
- A "harness" nem ugyanaz, mint a "framework". Egy framework (LangGraph, agents SDK) az a könyvtár, amellyel építesz; a harness az a futó réteg, amelyet az a könyvtár segít összerakni.
Mi az az Agent Harness?
Az agent harness az a szoftverinfrastruktúra, amely körülveszi a nyelvi modellt, és kezeli a végrehajtási ciklust, az eszközhozzáférést, a memóriát, a kontextust, az állapot-perzisztenciát, a hibakezelést és a korlátokat. A modell szöveget generál. A harness dönti el, hogy a modell mit lát minden körben, milyen tevékenységeket végezhet, mikor áll meg és mi történik, ha egy lépés meghibásodik.
A legtisztább megfogalmazás a LangChain-től származik, akik egy egyenletre redukálják: Agent = Model + Harness. A modell adja az intelligenciát. A harness az, ami ezt az intelligenciát valóban cselekvőképessé teszi a világban.
"A harness minden olyan kód, konfiguráció és végrehajtási logika, amely nem maga a modell."
— LangChain, Az ügynök harness anatómiája
A határt egy kérdésen keresztül érzem a legkönnyebben: amikor az ügynöke rosszat tesz, a modell saját következtetése volt hibás, vagy a körülötte lévő rendszer rossz kontextust, rossz eszközöket adott a modellnek, vagy nem hagyott helyet a helyreállásnak? A legtöbb esetben egy valódi rendszerben ez utóbbi a helyzet. A modell helyesen következtetett rossz bemenetek alapján. A harness az, ami a bemeneteket irányítja.
Fő tanulság: A modell generál; a harness irányít. Ez a kettéválasztás maga az egész koncepció.
Mik az ügynök harness összetevői?
Minden production harness ugyanazokat az ismétlődő részeket szereli össze: egy végrehajtási hurkot, amely lépésről lépésre vezérli a modellt, eszközhozzáférést a cselekvéshez, memóriát a lépések között, kontextuskezelést ahhoz, amit éppen lát, állapot-megőrzést, hogy a munka megmaradjon a munkamenetek között, hibakezelést a sikertelen lépésekhez és korlátokat, amelyek megszabják, mit tehet. A production rendszerek ellenőrzési hurkokat és részügynök-vezénylést adnak hozzá.
Egy hasznos leltár, amelyet a szakemberek valódi rendszerek leírásából vontak le:
- Végrehajtási / vezérlési hurok: az, ami az ágenst körről körre hajtja. Hívja a modellt, olvassa az eredményt, futtassa a kért eszközt, adja vissza az eredményt, ismételje a leállási feltételig.
- Tool-hozzáférés: a függvények, API-k, kódfuttatás és fájlrendszer, amelyeket a modell elérhet.
- Memória: amit az ágens megőriz a körök és a munkamenetek között.
- Kontextuskezelés: mi kerül be a modell ablakába minden körben, és mi kerül ki, ha megtelik.
- Állapot-megőrzés / checkpointing: az ágens állapotának mentése, hogy egy összeomlott vagy szüneteltetett futtatás folytatható legyen.
- Hibakezelés: újrapróbálkozások, tartalék megoldások és helyreállítás, ha egy tool- vagy modellhívás meghiúsul.
- Korlátok: korlátok arra vonatkozóan, hogy az ügynök mit tehet, például engedélyezett eszközök, lépéskorlátok és kimenet-ellenőrzés.
- Ellenőrző hurkok: az ügynök (vagy a harness) ellenőrzi saját munkáját, mielőtt befejezettnek nyilvánítja.
- Szubügynök-vezénylés: szubügynökök indítása, feladatok delegálása és eredmények összegyűjtése nagyobb feladatoknál.
Ezek nem mind univerzálisak. A végrehajtási hurok, az eszközök, a kontextuskezelés és a hibakezelés még egy hétvégi prototípusban is megjelenik. Az állapotperzisztencia, az ellenőrzés és a szubügynök-vezénylés az a pont, ahol a prototípusok és a produkciós rendszerek elválnak. Egy prototípus átugorhatja őket; egy hosszan futó produkciós ügynök nem. Az Anthropic leírása erről: hosszan futó ügynökök a csak produkciós részek bemutatója: hogyan építi fel újra egy ügynök a megértését egy haladási fájlból a kontextusablak visszaállítása után, és hogyan kapcsolódik be a tesztelés a hurokba.
Akik az akadémiai hidat keresik, egy nemrégiben áttekintés az ügynökarchitektúrákról ugyanezt a mechanikát egy kisebb formális tuple-be sűríti az alapkomponensekből. A praktikus lista és az áttekintés kerete ugyanannak a struktúrának két nagyítási szintje: az áttekintés összesűrít, a fenti leltár kibővít. A kilenc-tizenegy darabszámot úgy kezelje, mint a legtöbb produkciós harness által megosztott komponenseket, nem ratifikált szabványként; a terület még semmit sem ratifikált.
Fő tanulság: Az ügynök mozgó részeinek nagy része a harness-ben él, nem a modellben. A modell egy komponens a sok közül.
Miért fontosabb a harness a modellnél?
Egy gyengébb modell egy jól megtervezett harness-ben gyakran felülmúl egy erősebb modellt egy rosszul tervezettben. Az ok mechanikus, nem mágikus: egy agent end-to-end megbízhatósága minden egyes lépés megbízhatóságának szorzata, és ezeknek a lépéseknek a nagy része (eszközválasztás, kontextus összeállítás, hibahelyreállítás) a harness feladata, nem a modellé. Javítsa őket, és az egész lánc megbízhatóbbá válik, függetlenül attól, hogy melyik modell van belül.
Az aritmetika ezt kézzelfoghatóvá teszi. Tegyük fel, hogy egy tíz lépéses feladat minden egyes lépése 99%-ban sikeres. Az end-to-end siker nem 99%. Ez a 0,99 tizedik hatványa, kb. 90%. Nyomja fel az egyes lépéseket 99,9%-ra, és az end-to-end kb. 99%-ra ugrik. A lépésenkénti megbízhatóság összetett hatást vált ki, és a lépésenkénti megbízhatóság elsősorban a harness tulajdonsága. Ezért a hibakezelés és a kontextuskezelés optimalizálása jobban megtérül, mint egy valamelyik benchmarkon fél ponttal jobb modellre való cseréje.
Termelési jelek is ugyanebbe az irányba mutatnak. MongoDB, a Vercel esettanulmányára hivatkozva, arról számol be, hogy a Vercel megnyirbálta ügynökük eszközeinek nagy részét, és figyelte, ahogy a sikerességi arány ugyanazon a modellen élesen emelkedett, egy kisebb és letisztultabb harness-szel. Kezeljük ezt konvergens bizonyítékként, nem bizonyításként: ez egy termelési eset, nem kontrollált kísérlet, de ugyanabba az irányba mutat, mint a fenti összetett aritmetika és a felmérési munka.
Ez az a heurisztika, amelyhez platform mérnökként újra és újra visszatérek: a kontextus a szűk keresztmetszet, nem a nyers modellkapacitás, és a mai modellek hiányosságait eltakaró állványzat általában elveszik, ahogy a modellek fejlődnek. Építse fel a harness tartós részeit (a hurkot, az állapotot, a helyreállítást), és hagyja, hogy az alatta lévő modell a saját ütemezése szerint fejlődjön.
Fő tanulság: Amikor az ügynöke meghibásodik, először a harness-t gyanúsítsa, ne a modellt. A valószínűség ezt támasztja alá.
Mi a különbség a harness, a scaffold és a framework között?
Ezt a hármat felváltva használják, pedig nem kellene. A framework az a könyvtár vagy SDK, amellyel fejlesztesz, például LangGraph vagy egy agents SDK. A harness a modell körül futó végrehajtási és irányítási réteg, amelyet egy framework segít összerakni. A scaffold a három közül a leglazább: néha majdnem szinonimája a harness-nek, néha annak prototípus változata, néha konkrétan a prompt-és-eszközleíró réteg.
A szókincs valóban rendezetlen, és a legtisztább dolog a használatok feltérképezése, nem pedig egyetlen meghatározás előírása. A HuggingFace Ügynök szójegyzék ezt közvetlenül kimondja:
"Sok ilyen kifejezésnek még nincs általánosan elfogadott meghatározása, és a különböző framework-ök ugyanazt a szót másképp használják."
— HuggingFace, Ügynök szójegyzék
| Fogalom | Mire utal | Kapcsolat |
|---|---|---|
| Framework | A könyvtár vagy SDK, amellyel építesz (LangGraph, egy ügynök SDK) | Egy eszköz harness összeállításához |
| Harness | A modell körüli futó réteg: ciklus, eszközök, kontextus, állapot, guardrails | Amit szállítasz és futtatsz |
| Scaffold | Tágan használva: a harness közel-szinonimája, vagy a prototípus szintű / prompt-réteg verzió | Átfed a harness-szel; kevésbé pontos |
| Ciklus | A végrehajtási ciklus a harness-en belül | A harness egy összetevője |
A saját rendszerről való gondolkodás gyakorlati tanulsága: amikor valaki azt mondja, "framework", kérdezd meg, hogy a könyvtárat vagy a futó dolgot érti-e. Amikor valaki azt mondja, "scaffold", kérdezd meg, hogy a teljes harness-t vagy csak a prompt-és-eszköz réteget érti-e. Az érték itt az egyértelműsítés, nem az utolsó szó igénye.
Hogyan implementálja a LangGraph a harness mintát?
A LangGraph a harness minta egy népszerű nyílt forráskódú Python implementációja. Az ügynök végrehajtását csomópontok és élek irányított gráfjaként modellezi, tipizált állapottal köztük és minden átmenettel, amely checkpointolható. Ha a fenti absztrakt komponensek csúszósnak tűnnek, a LangGraph az a hely, ahol valódi eszközben láthatjuk őket konkrét alakot ölteni.
A leképezés majdnem egy-az-egyhez. A csomópontok és élek a végrehajtási ciklus: minden csomópont munkát végez, minden él eldönti, hova megy a vezérlés. A csomópontok között átadott tipizált állapotobjektum a kontextus-és-állapot komponens explicit megjelenítése. A checkpointing (LangGraph savers-en keresztül tárolja az állapotot mint a Postgres-alapú implementációja) az állapotperzisztencia komponens. Egy konfigurálható lépéskorlát egy megállási feltétel guardrail, amely megakadályozza, hogy egy hibásan viselkedő ügynök örökké ciklusoljon. Ugyanazok a komponensek, egy adott könyvtár által elnevezve és bekötve.
Ha saját szerveren szeretne LangGraph agentet futtatni éjjel-nappal, az egy deployment kérdés, nem pedig fogalmi. Lásd Linux VPS útmutatónkat arra az útra. Itt a LangGraph csak a kidolgozott példa: bizonyíték arra, hogy az "végrehajtási ciklus", "állapotperzisztencia" és "guardrail" nem absztrakciók, hanem dolgok, amelyekre rá lehet mutatni valódi kódban.
Gyakran ismételt kérdések
Mi az az Agent Harness?
Az agent harness a language model körüli szoftver, amely agenttá alakítja. Kezeli a végrehajtási ciklust, az eszközhozzáférést, a memóriát, a kontextust, az állapotperzisztenciát, a hibakezelést és a guardraileket. A modell szöveget generál; a harness dönti el, mit lát a modell, mit tehet, mikor kell megállni, és mi történik, ha valami meghibásodik.
Ugyanaz az agent harness, mint az agent framework?
Nem. A framework az a könyvtár vagy SDK, amellyel fejlesztesz, például LangGraph vagy egy agents SDK. A harness a modell körül futó végrehajtási és irányítási réteg (a ciklus, eszközök, kontextus, állapot és korlátok), amelyet egy framework segít összeállítani. A frameworköt arra használod, hogy harnesst építs.
Milyen komponensei vannak minden agent harnessnek?
A legtöbb harness közös visszatérő maggal rendelkezik: végrehajtási ciklus, eszközhozzáférés, memória, kontextuskezelés, állapot-megőrzés, hibakezelés és korlátok. A produkciós harnesszek ellenőrzési ciklusokat és szubagent-vezénylést is tartalmaznak. A prototípusok kihagyhatják a csak produkciós részeket, de a ciklus, az eszközök, a kontextuskezelés és a hibakezelés szinte mindenütt megjelenik.
Mit jelent az, hogy "Az LLM az ügynökrendszered legkisebb része"?
Ez azt jelenti, hogy egy ügynök viselkedésének és megbízhatóságának nagy része a harnessből, nem a modellből ered. A végponttól végpontig tartó megbízhatóság minden lépés sikerességi arányának szorzata, és a legtöbb lépés harness-munka. A MongoDB, a Vercel esettanulmányára hivatkozva, a sikerességi arány ugrásáról számol be pusztán harness-változtatásokból, ugyanazon a modellen. Ez bizonyíték arra, hogy a harness javítása felülmúlja a modell javítását.
Ahol az ügynöke minősége él
A harness az a hely, ahol az ügynök minőségének nagy része él, és most már megvan a szókincsed a saját rendszeredben lévő problémák azonosításához. Meghatározhatod a harnesst, megnevezheted összetevőit, megkülönböztetheted egy frameworktől és egy scaffoldtól, és érvelni tudsz arról, hogy egy adott hiba modellprobléma-e vagy harness-probléma.
Tehát legközelebb, amikor az ügynöke helytelenül viselkedik, először ellenőrizze a harness réteget: a kontextust, amelyet beadagol, az eszközöket, amelyeket elérhetővé tett, a leállási feltételeket, amelyeket beállított, a módot, ahogyan felépül egy sikertelen lépésből. Csak akkor nyúljon nagyobb modell után, ha ez a réteg megfelelt. Az esetek többségében nem lesz rá szükség.
