Az elmúlt két évben az MI-ügynökökkel kapcsolatos karriertanácsok többnyire arról szóltak, hogy tanuljunk meg jól promptolni őket. Ez már nem a szűk keresztmetszetet jelentő készség. A szűk keresztmetszetet az ügynök köré épített infrastruktúra jelenti — az, amit egyre gyakrabban harnessnek neveznek —, és ez annyira sajátos és nehéz terület, hogy kezd önálló munkaköri leírássá válni, nem pedig a csapat „MI-s emberének” mellékes feladatává.

A legvilágosabb nyilvános bemutató arról, hogy ez a gyakorlatban mit jelent, a Lenny's Newsletterben jelent meg, amely dokumentálja, hogyan épített a ChatPRD termékmenedzsment-eszköz egy harness-t a Sentry hibáinak automatikus felderítésére. Érdemes az egész írást elolvasni, ha mérlegeled, hogy erre szakosodj-e, mert rávilágít egy könnyen elsiklásra okot adó pontra: a modell sosem volt a szűk keresztmetszet. A csapat a Claude Agent SDK-ra épített alapként, majd mérnöki erőfeszítéseinek zömét egy egyedi terminálfelületre és a Sentryhez, a Linearhoz, a GitHubhoz és a Vercelhez csatlakozó adapterekre fordította. Röviden erről szól ez a munka. Négy rendszer, négy különböző hitelesítési séma, négy különböző adatforma, valamint egy felület, amely lehetővé teszi, hogy az ember figyelje és beavatkozzon anélkül, hogy minden egyes lépést felügyelnie kellene.

Mire bomlik le valójában a „harness”?

Ha megpróbálod eldönteni, hogy érdemes-e ezt a készségkészletet kiépíteni, segít, ha különválasztod olyan részekre, amelyekre külön-külön vesznek fel embereket, vagy amelyeket legalább külön értékelnek egy állásinterjún:

  • Jogosultságtervezés. Annak eldöntése, hogy mit tehet meg egy ügynök felügyelet nélkül (elolvashat egy ticketet, elkészíthet egy PR-tervezetet), szemben azzal, amihez ember közreműködése szükséges (merge, telepítés, törlés, pénzköltés) — és ennek tényleges, kódba foglalt szabályként való rögzítése, nem pedig promptutasításként, amelyet a modell nyomás alatt figyelmen kívül hagyhat. Ez közelebb áll a hozzáférés-vezérlés tervezéséhez, mint a promptíráshoz.
  • Eszközadapterek. Vékony, alaposan tesztelt burkolók minden egyes külső rendszer köré (Sentry, Linear, GitHub, Vercel vagy a vállalatod technológiai stackjének bármely más eleme), amelyek az ügynök szándékát biztonságos, validált API-hívássá alakítják, majd a választ visszaalakítják olyasmivé, amiről a modell képes következtetni. Ez hagyományos szoftverfejlesztés — hibakezelés, újrapróbálkozás, sémaellenőrzés — egy új felhasználóra alkalmazva.
  • Terminál- vagy konzolfelület. Olyan megoldás, amelyen az ember láthatja, mit csinál az ügynök, jóváhagyhatja vagy elutasíthatja a műveleteket, és közbeléphet, amikor az elakad. A ChatPRD egyedi felületet épített; sok csapat inkább kész ügynökkonzolokat használ majd, de valakinek akkor is el kell döntenie, mi jelenjen meg, mi maradjon rejtve, és mihez kell kattintás a végrehajtás előtt.
  • Eszközválasztás nagy léptékben. A Machine Learning Mastery egyik írása olyan dolgot emel ki, amit érdemes tudni, ha demónál többet építesz: az ügynökök eszközhívási pontossága általában romlani kezd, amikor az eszközkatalógus nagyjából egy tucat lehetőségnél többre nő — a modell elkezd rossz eszközöket hívni, paramétereket hallucinálni vagy hibás hívások miatt elakadni. Az általa felsorolt enyhítő megoldások (annak szabályozása, hogy egy adott kontextusban egyáltalán mely eszközök legyenek láthatók, visszakeresésalapú eszközkeresés, specializált alügynökökhöz irányítás, explicit tervezési lépések, tartaléklogika és a regressziók kiszűrésére szolgáló benchmark-harnessök) önmagukban is egy ellenőrzőlistát alkotnak mindarról, amit egy harnessmérnöknek tudnia kell megvalósítani, nem csupán ismernie.
  • Kontextus- és memóriamérnökség. Ugyanez a forrás egy olyan különbségtételt tesz, amelyet érdemes rögzíteni: a kontextusmérnökség (mi kerül be egyetlen inferenciahívásba, és hová) és a memóriamérnökség (mi marad meg munkamenetek között, hogyan tárolják, hogyan kérik vissza) különböző, eltérő hibamódokkal rendelkező szakterületek. Állítása szerint a hosszan futó, több munkameneten átívelő ügynökök legtöbb meghibásodása a kettő összekeverésére vezethető vissza — arra, hogy a munkamenet memóriáját egyszerűen több kontextusként kezelik, vagy fordítva — különösen azon a ponton, ahol a rendszer eldönti, mit kérjen vissza.

A bizonyíték arra, hogy ez valódi, finanszírozható szerepkör — nem csupán egy hobbisták által betöltött réspiac

A szkeptikusok joggal kérdezhetik, hogy a „harnessmérnök” önálló munkakör-e, vagy csupán valaki más munkáján belüli feladat. Az összefoglaló két adata arra utal, hogy inkább az előbbi felé halad. Először is a Microsoft Aspire csapata — egy 10 fős csoport — a GitHub Agentic Workflows segítségével automatizálta a repozitóriumokon átívelő dokumentációs PR-eket, és két kiadás alatt 82 PR-t vontak be, a megfelelő termék-PR élesítése után mediánosan 44.8 órával, új létszám felvétele és a folyamat újratanítása nélkül. Ez egy kis csapat, amely azért ért el aránytalanul nagy hatást, mert valaki beruházott az infrastruktúrába (a munkafolyamat-definíciókba, az ellenőrzési útvonalakba és a kiváltási logikába), ahelyett hogy a mérnökök kézzel írták volna meg a dokumentációs PR-eket. Másodszor a Microsoft Research SkillOpt projektje az ügynök „skill” fájljait — azokat az utasításokat és korlátozásokat, amelyek meghatározzák, hogyan viselkedik az ügynök a harnessében — olyasminek tekinti, amit szisztematikusan optimalizálni kell, nem pedig kézzel szerkeszteni, és arról számol be, hogy egy benchmarkrács mind az 52 cellájában (hat benchmark, hét modell, három végrehajtási mód) a legjobb vagy holtversenyben legjobb eredményt érte el, miközben az optimalizált skillek különböző modellek és különböző harnessök között is átvihetők voltak. Függetlenül attól, hogy ez a konkrét eszköz szabvánnyá válik-e, azt jelzi, hogy az iparág kezdi a harness konfigurációját saját eszközökkel és benchmarkokkal rendelkező mérnöki műtermékként kezelni — ugyanazon a pályán, amely a „DevOps”-t alkalmi szkriptek halmazából önálló szakterületté alakította.

Ehhez a réteghez már kifejezetten infrastruktúra is épül. A Google újonnan bejelentett „Managed Agents” képességei a Gemini API-ban — háttérben és aszinkron módon történő végrehajtás, távoli MCP-szerverintegráció, egyedi függvényhívás, valamint a hitelesítő adatok frissítése az interakciók között — lényegében előre elkészített infrastruktúrát jelentenek pontosan azokhoz a problémákhoz, amelyeket a ChatPRD csapata kézzel oldott meg. Ez szokásos minta: amit az egyik csapat idén egyedileg megépít, azt egy platformszállító jövőre termékesíti. Ez nem szünteti meg a harnessmérnöki szerepkört; megemeli az alapvető szintet, és a munkát a kezelt építőelemek integrálása és konfigurálása felé tolja, ahelyett hogy minden adaptert a semmiből kellene megírni — hasonlóan ahhoz, ahogy a felhőinfrastruktúra sem szüntette meg az üzemeltetési mérnökök munkáját, csak megváltoztatta, mire fordítják az idejüket.

Mit jelent ez, ha ilyen szerepkörre pályázol?

Néhány konkrét, ellenőrizhető dolog, amelyet érdemes bemutatni a portfóliódban vagy az önéletrajzodban, ha hiteles akarsz lenni ezen a területen: építs fel egy adaptert teljes egészében egy általad nem irányított, valódi API-hoz (a hitelesítést, a hibakezelést és a sebességkorlátozásokat is beleértve, nem csupán egy ideális útvonalat bemutató demót); tervezz meg és dokumentálj egy jogosultsági modellt egy olyan ügynökhöz, amely különbséget tesz az olvasási, javaslattételi és végrehajtási műveletek között, és bemutatja, miért ott húzódik az egyes határvonal; továbbá építs vagy konfigurálj egy ellenőrzési felületet, ahol egy ember jóváhagyja az ügynök műveleteit azok végrehajtása előtt, mivel a legtöbb vállalat ehhez fog ragaszkodni, mielőtt engedné, hogy egy ügynök hozzáférjen az éles rendszerhez. Ha egy harnessmérnöki állásajánlatot értékelsz, vagy saját felelősségi köreidet határozod meg, kérdezd meg konkrétan, ki felel a jogosultsági modellért, ki az adapterekért, és ki az emberi ellenőrzési felületért — sok csapatban jelenleg ennek a három dolognak nincs egyértelmű felelőse, és pontosan ezt a hiányt készül betölteni ez a szerepkör.

Egy fontos megjegyzés: a fenti források egyike sem állapít meg konkrét adatot az adott munkakör iránti munkaerőpiaci keresletről, és a „harnessmérnök” még nem olyan munkaköri megnevezés, amellyel álláshirdetésekben találkoznál — inkább olyan címek alatt jelenik meg, mint „MI-infrastruktúra-mérnök”, „ügynökplatform-mérnök”, vagy egyszerűen „senior backendmérnök, MI-rendszerek”. Tekints erre kiépítendő és pontosan leírható készségkészletként, ne pedig olyan munkaköri címként, amelyre a LinkedInen kell rákeresni.