Harness engineering: mi ez, és hogyan működik?

A harness engineering jelentése

A harness engineering egy MI-eszköz harnessének, vagyis az eszköz MI-modellen kívüli összes részének a megépítése.

A modell maga az MI-rendszer, amelyet nagy mennyiségű szövegen tanítottak be, hogy képes legyen nyelvet olvasni és írni. Ilyen MI-modell például az OpenAI GPT-je, az Anthropic Claude-ja vagy a Google Geminije.

Egy modell önmagában csak szöveget (és néha képet vagy hangot) tud fogadni, és válaszként szöveget ír. Nem emlékszik a korábbi beszélgetésekre, nem tud aktuális információkat keresni, és kódot sem tud futtatni. Ezért szüksége van egy harnessre, amely kezeli, milyen információkat kap a modell, mely alkalmazásokat használhatja, mit tehet meg, és hogyan ellenőrzik a munkáját.

Még egy egyszerű csevegőasszisztensnek is szüksége van harnessre. A modell minden üzenetváltást elfelejt, amint válaszolt, ezért a harness rögzíti a beszélgetést. Ha valaki Párizsról kérdez, majd hozzáteszi: „hány lakosa van?”, a harness mindkét kérdést együtt küldi el a modellnek. Így tudja a modell, hogy a „lakosa” szó Párizsra vonatkozik.

A harness engineering az egyik oka annak, hogy két, ugyanarra a modellre épülő eszköz ennyire eltérően teljesíthet. Egy független teszt során például a kutatók változatlanul hagyták a modellt (GPT5), és csak a harnesst módosították, a modell pontszáma egy kódolási teszten mégis akár 11%-kal is változott.

Az MI-modellek fejlesztői, például az Anthropic és az OpenAI, saját MI-termékeikhez – például a Claude Code-hoz és a Codexhez – építenek harnesst. Az MI-termékeket fejlesztő cégek pedig az általuk választott alapmodellekhez terveznek harnesst. Az MI-eszközök felhasználói is alakítják a harness egy részét. Sok eszközben állandó utasításokat adhatnak meg, alkalmazásokat csatlakoztathatnak, és kiválaszthatják, mely műveletekhez kell a jóváhagyásuk, mielőtt az eszköz továbblépne.

Harness engineering MI-ügynökökhöz

Minden MI-eszköznek van harnesse, de a harness engineering különösen fontossá válik, amikor MI-ügynökökkel dolgozunk. Az ügynökök önállóan végeznek el többlépéses feladatokat, például információt gyűjtenek a versenytársakról, és táblázatba rendezik az eredményeket, a harness pedig minden lépést lefuttat. Ha tehát a harness hibázik, például a tavalyi árakat kéri le, az a többi lépésre is kihat.

A legtöbb ügynöki harness hat fő részből áll:

1. Az ügynökciklus

Nagyítás

Az ügynökciklus a harness azon kódrésze, amely lépésről lépésre előreviszi a feladatot.

Az MI-modell eldönti, mi a következő lépés a feladat elvégzéséhez, és megír egy eszközhívást: egy rövid kérést, amely megnevezi a harness egyik eszközét – például a webes keresést –, valamint azt, hogy mit kell az eszköznek elvégeznie.

A harness észleli a kérést, lefuttatja a keresést, és az eredményeket hozzáadja ahhoz, amit a modell lát. A modell elolvassa őket, és eldönti, mi legyen a következő lépés.

2. Kontextuskezelés

A modell a tanítás során általános tudásra tesz szert, ez a tudás azonban csak a tanítás befejezésének időpontjáig terjed. Nem tartalmaz semmit, ami kifejezetten az adott feladathoz kapcsolódik, például egy cég fájljait, a mai híreket vagy azt, ami korábban elhangzott a beszélgetésben.

Mindehhez a modell a kontextusablakára támaszkodik: arra a szövegre, amelyet a harness minden válasz előtt átad neki, például az utasításaira, a kérdésre, az eddigi beszélgetésre és a keresési találatokra.

Az ablak csak meghatározott mennyiségű szöveget tud befogadni. A modellek pedig még azelőtt, hogy az ablak megtelne, néha nem veszik észre a hosszú bemenetek közepén megbújó információkat.

Ezért a harness végzi a kontextuskezelést, és csak azokat az információkat választja ki, amelyekre az adott lépésnek szüksége van. Ha például a feladat öt versenytárs árazásának összehasonlítása, a harness az egyes cégek teljes webhelye helyett csak az árazási oldalukat adhatja át. Hosszú feladatoknál a harness a korábbi lépések részletes leírását egy rövid összefoglalóval is helyettesítheti, így a modell nyomon követi, mit végzett már el, anélkül, hogy ez az előzmény megtöltené az ablakot.

3. Eszközök

Az eszközök olyan kódrészek, amelyek végrehajtják a modell által kért műveleteket. Minden eszköz egyféle műveletet kezel, például a webes keresést, egy weboldal megnyitását és elolvasását, kód futtatását vagy egy fájl szerkesztését. Amikor a modell megír egy eszközhívást, a harness továbbítja azt a megfelelő eszköznek, majd visszaadja az eredményt.

Sok harness csatlakozókat is tartalmaz: ezek olyan eszközök, amelyek egy adott alkalmazáshoz – például e-mailhez, naptárhoz vagy megosztott meghajtóhoz – kapcsolják az ügynököt egy felhasználó által engedélyezett hozzáféréssel. Egy naptárcsatlakozóval például az ügynök ellenőrizheti, hogy valaki ráér-e, mielőtt időpontot javasolna egy megbeszélésre.

4. Memória

A memória olyan tárolt információ, amely az egyik munkamenetből átkerül a következőbe. A harness egy munkamenet során rövid jegyzeteket ment, például a felhasználó preferenciáiról vagy arról, hogy hol tart egy projekt. A következő munkamenet elején a harness hozzáadja ezeket a jegyzeteket a kontextusablakhoz, így a modell még az új kérdés előtt elolvassa őket. Így tudja például egy ügynök ott folytatni a heti jelentést, ahol abbahagyta, ahelyett, hogy újra az elejéről kezdené.

5. Engedélyek

Az engedélyek olyan szabályok, amelyek meghatározzák, mihez férhet hozzá és mit tehet meg egy ügynök. A hozzáférési szabályok rögzítik, mely fájlokat, alkalmazásokat vagy webhelyeket nyithatja meg. A jóváhagyási szabályok azt határozzák meg, mely műveleteknek – például egy üzenet elküldésének vagy egy vásárlásnak – kell megvárniuk egy személy jóváhagyását.

Ezeknek a szabályoknak egy részét az ügynököt készítő cég állítja be a harness kódjában. Ezután egy szervezet rendszergazdái hozzáadhatják a saját szabályaikat, az egyes felhasználók pedig például azt választhatják ki, mely fiókokat csatlakoztatják.

6. Ellenőrzés

Az ellenőrzés olyan kód, amely átvizsgálja az ügynök munkáját, mielőtt az eljutna egy személyhez. Kétféle ellenőrzést alkalmaz:

• Rögzített szabályok: olyan konkrét tesztek, amelyek minden alkalommal ugyanúgy sikeresek vagy sikertelenek, például annak megerősítése, hogy egy jelentés minden adata szerepel egy olyan dokumentumban, amelyet az ügynök ténylegesen elolvasott.
• Egy másik MI-modell általi felülvizsgálat, amely elolvassa és értékeli a munkát. Olyan problémákat is kiszűrhet, amelyeket nehéz szabályba foglalni, például ha egy összefoglalóból kimarad egy fontos szempont.

Egyetlen ellenőrzés sem szűr ki mindent, ezért a harnessek általában mindkét típust kombinálják. Ha egy ellenőrzés problémát talál, a harness hozzáadja annak leírását a modell kontextusablakához, és visszaküldi a feladatot az ügynökciklusba. A modell kijavítja a problémát, és újra próbálkozik, így sok hibát még azelőtt kijavít, hogy a felhasználó látná az eredményt.

Harness engineering a gyakorlatban

Felkészülés egy ügyféltalálkozóra

Feladat: Egy ügyfélkapcsolati menedzser megkér egy ügynököt, hogy készítsen felkészítő anyagot a holnapi ügyféltalálkozóhoz, amely kitér a nyitott kérdésekre, és tartalmaz egy napirendtervezetet.

Mit tesz a harness:

• Egy e-mail-csatlakozón keresztül az ügynök az ügyféllel folytatott levelezést keresi meg a menedzser postafiókjában.
• Az engedélyek lehetővé teszik számára az e-mailek olvasását, a küldésüket azonban nem.
• A kontextuskezelés a teljes postafiók helyett csak az adott ügyféllel az elmúlt három hónapban váltott üzeneteket adja át a modellnek.
• Az ügynökciklus több keresési és olvasási kört futtat le, a modell pedig nyitott kérdésekbe csoportosítja a talált információkat.
• Az ellenőrzés ezután megvizsgálja, hogy a felkészítő anyagban szereplő minden kérdés visszavezethető-e egy valós e-mailre.

Lehetséges eredmény: A menedzser egyoldalas felkészítő anyagot kap, amelyben minden pont visszavezethető a forrásául szolgáló e-mailre.

Havi értékesítési jelentés frissítése

Feladat: Egy operatív vezető megkér egy ügynököt, hogy frissítse a havi értékesítési jelentést az e havi számokkal.

Mit tesz a harness:

• A memória betölti a múlt havi munkamenet jegyzeteit, köztük a jelentés formátumát és a vezető kérését, hogy a számokat ezresekre kell kerekíteni.
• Egy fájlkezelő eszköz megnyitja az értékesítési táblázatot a csapat megosztott meghajtóján.
• Az engedélyek lehetővé teszik, hogy az ügynök szerkessze a jelentéstervezetet, a forrástáblázatot azonban nem, így az eredeti számok nem módosulhatnak véletlenül.
• Az ellenőrzés megvizsgálja, hogy a jelentésben szereplő végösszegek egyeznek-e a táblázattal.

Lehetséges eredmény: A jelentés ugyanabban a formátumban készül el, mint a múlt havi, anélkül, hogy a felhasználónak újra el kellene magyaráznia.

Közös postafiók rendezése

Feladat: Egy ügyfélszolgálati csapat megkér egy ügynököt, hogy témák szerint rendezze a reggel beérkezett kéréseket, és készítsen válaszvázlatokat a gyakoriakra.

Mit tesz a harness:

• Az ügynökciklus üzenetről üzenetre halad végig a postafiókon.
• A modell mindegyikhez kiválaszt egy témacímkét, a harness pedig az e-mail-csatlakozón keresztül alkalmazza azt.
• A feladat elején a harness útmutatóként hozzáadja a csapat jóváhagyott válaszsablonjait a kontextusablakhoz, így a modell minden vázlatot egy sablonra alapoz.
• Egy jóváhagyási szabály minden választ vázlatként tart vissza, amíg a csapat valamelyik tagja át nem nézi és el nem küldi.

Lehetséges eredmény: A csapat úgy kezdi a napot, hogy a kérések már rendezve vannak, a válaszok pedig átnézésre várnak.

Hiba javítása egy webhelyen

Feladat: Egy fejlesztő megkér egy kódolóügynököt, hogy javítson ki egy hibát, amely miatt nem működik a fizetési gomb.

Mit tesz a harness:

• Az ügynök egy sandboxban dolgozik, vagyis a kód egy elkülönített másolatában, ahol a módosításai nem érintik az élő webhelyet.
• Egy kódkezelő eszköz lehetővé teszi, hogy a modell fájlokat olvasson és szerkesszen.
• Minden módosítás után az ellenőrzés lefuttatja a projekt automatizált tesztjeit.
• A sikertelen tesztek eredményei új információként visszakerülnek a modellhez.

Lehetséges eredmény: Az ügynök addig finomítja a javítást, amíg a tesztek sikeresen le nem futnak. A fejlesztő ezután átnézi a módosítást, mielőtt az élesbe kerülne.

Harness engineering, prompt engineering és context engineering: mi a különbség?

A prompt engineering egyetlen kérdés megfogalmazása és optimalizálása. A context engineering mindannak a kezelése, amit a modell lát. A harness engineering pedig annak a teljes rendszernek a megtervezése és fejlesztése, amelyen belül a modell dolgozik.

Így befolyásolhatják a felhasználók az MI-harnesst

Az ügynöki harness nagy részét az ügynököt készítő cég biztosítja, de számos MI-termék lehetővé teszi, hogy a felhasználók beállításokkal módosítsák annak egy részét, például egyéni utasításokkal, csatlakoztatott alkalmazásokkal és jóváhagyásokkal.

A felhasználók négyféleképpen alakíthatják az ügynöki harnesst, és javíthatják ezzel az ügynök eredményeit:

1. Állandó utasítások

Az állandó utasítások olyan feljegyzések, amelyeket egy személy egyszer megír, a harness pedig minden feladat elején hozzáadhatja őket a kontextusablakhoz. Mindenhez érdemes beállítani őket, amit valaki egyébként kérdésről kérdésre megismételne: hogy ki ő és mivel foglalkozik, milyen stílusú szövegeket szeretne kapni, vagy milyen szabályok vonatkoznak egy ismétlődő munkára, például egy ügyfél havi jelentésére.

Sok MI-termék két szinten kínál állandó utasításokat. A fiókszintű utasítások olyan dolgokhoz illenek, amelyek minden munkára érvényesek, például a helyesírási preferenciákhoz. A projektutasítások egyetlen ügyfélhez vagy munkafolyamathoz illenek, így az egyikre vonatkozó útmutatás nem kerül át a másikba.

Az állandó utasítások ugyanúgy működnek a csevegőasszisztensekben és az ügynökökben, de az ügynökök jobban támaszkodnak rájuk. Csevegés közben az ember minden válasz után kijavíthatja az MI-t. Egy ügynök viszont sok lépést megtehet, mielőtt bárki látná a munkáját, így az előre megadott utasítások azon kevés módszer egyikét jelentik, amellyel menet közben irányítani lehet.

Hatékony állandó utasítások írása

• Kezdj egy rövid utasítással, például: „Marketingmenedzser vagyok egy szoftvercégnél. Írj egyszerű, közérthető angolsággal, az összefoglalók legyenek 200 szónál rövidebbek, és használj amerikai helyesírást.”
• Bővítsd őket, amikor az MI hibázik. Ha az MI folyton kerekíti azokat a számokat, amelyekre a csapatnak pontosan van szüksége, adj hozzá egy erről szóló sort.
• Fogalmazz konkrétan: a „Pontos számokat adj meg, soha ne kerekíts” többet ér, mint a „Légy pontos”.
• Tartsd rövidre a listát, és töröld a sorokat, amint már nem hasznosak, mivel minden sor helyet foglal a kontextusablakban.

2. Csatlakoztatott alkalmazások

A csatlakoztatott alkalmazások összekapcsolják az MI-terméket azokkal az eszközökkel, amelyeket valaki már használ, például az e-maillel, a naptárral vagy egy megosztott meghajtóval. Amint egy alkalmazás csatlakoztatva van, az MI a felhasználó saját információival is dolgozhat, nem csak azzal, amit beillesztenek a csevegésbe.

A kapcsolatokat akkor érdemes beállítani, ha egy feladat az ezekben az alkalmazásokban tárolt információktól függ, például ha e-mail-szálak alapján kell felkészítő anyagot készíteni egy megbeszélésre, vagy egy megosztott meghajtón lévő dokumentumokat kell összefoglalni.

Alkalmazások biztonságos csatlakoztatása

• Csak azokat az alkalmazásokat csatlakoztasd, amelyekre az adott feladathoz szükség van, mivel minden kapcsolat újabb hibalehetőséget jelent.
• Ahol lehetőség van rá, válaszd a csak olvasási hozzáférést. Egy megbeszélésekhez felkészítő anyagot készítő ügynöknek például olvasnia kell az e-maileket, küldenie nem.
• Ahol a termék lehetővé teszi, projektenként állítsd be a kapcsolatokat. A Perplexityben például a felhasználók kiválaszthatják, hogy az egyes projektek mely csatlakozókat használják.
• Ne felejtsd el leválasztani a már nem használt alkalmazásokat.

3. Jóváhagyási beállítások

A jóváhagyási beállítások határozzák meg, mely műveleteknél kell megvárni egy személy jóváhagyását, mielőtt az MI továbblépne. Egyes jóváhagyások be vannak építve a termékbe, egyes termékekben pedig a felhasználók maguk választhatják ki, mely további műveletekhez legyen szükség jóváhagyásra.

Jóváhagyási szabályok beállítása

• Írja elő a jóváhagyást a visszavonhatatlan műveleteknél, például üzenet küldésekor, vásárláskor vagy fájl törlésekor.
• Tartsa rövidre a jóváhagyást igénylő lépések listáját. Ha egy ügynök minden apró lépéshez engedélyt kér, az emberek elolvasás nélkül kezdenek el mindent jóváhagyni.

4. Követelmények és ellenőrzések

A legtöbb AI-termékbe eleve be vannak építve bizonyos követelmények. A Perplexity például forrásmegjelöléseket csatol a válaszaihoz, így minden állítás ellenőrizhető. A felhasználó által megadott követelmények azzal egészítik ki ezeket, amit a termék magától nem tudhat, például hogy egy csapat milyen formátumban szereti a jelentéseket.

Követelmények meghatározása az AI által végzett munkához

• Adjon sablont az ismétlődő feladatokhoz, hogy az AI egy rögzített szerkezetet tölthessen ki.
• Osszon meg egy korábbi munkát, amely elnyerte a csapat tetszését, hogy az AI igazodni tudjon annak hangneméhez és részletességéhez.
• Kérjen forráshivatkozást minden számadat mellé.
• Az első eredményeket nézze át alaposan, és minden ismétlődő hiányosságból alakítson ki egy új, állandó utasítást.

Hogyan közelíti meg a Perplexity az ügynök-harnesseket

A Perplexity Computer egy modellfüggetlen harnessen fut, amely több mint 20 fejlett modellt egyesít egyetlen rendszerben. Minden feladatot részfeladatokra bont, ezeket alügynököknek (különálló ügynököknek, amelyek mindegyike egy-egy részt vállal) adja át, és minden munkarészt az arra alkalmas modellhez irányít.

Az utasítások, fájlok és csatlakozók beállításáról a Perplexity-projektekről szóló útmutatóban olvashat bővebben.

Gyakori kérdések

Mi az a harness-mérnök?

A harness-mérnök azt a rendszert tervezi és tartja karban, amely lehetővé teszi, hogy egy AI-modell megbízhatóan végezze a munkáját. Ide tartozhat például egy új eszköz hozzáadása az ügynök számára, annak kiderítése, hogy egy ügynök miért követi el újra és újra ugyanazt a hibát, vagy azoknak az ellenőrzéseknek a szigorítása, amelyeket egy feladat befejezése előtt lefuttat. Nem bevett munkaköri megnevezés, bár ez még változhat. Ezt a munkát általában AI-cégeknél vagy ügynököket fejlesztő csapatokban dolgozó szoftvermérnökök végzik. A gyártóiparban ugyanez az angol megnevezés olyan szakembert jelöl, aki kábelkötegeket, vagyis az autókban és gépekben található, kötegbe fogott vezetékeket tervez.

Mi az az ügynök-harness?

Az ügynök-harness általában egy AI-ügynök minden olyan részét jelenti, amely nem maga a modell. Ide tartozik az a kód, amely futtatja az ügynök ciklusát, kezeli a kontextust, végrehajtja az eszközhívásokat, tárolja a memóriát, érvényesíti a jogosultságokat, és ellenőrzi az ügynök munkáját, mielőtt az egy emberhez kerülne.

Minden AI-eszköznek van harnesse?

Igen. Még egy egyszerű csevegőasszisztens is harnessre támaszkodik a beszélgetés nyomon követéséhez, mivel a modell magától nem emlékszik a korábbi üzenetekre.

A fejlesztők úgy is használhatnak egy modellt, hogy saját szoftverükből API-n keresztül küldenek neki kéréseket (az API olyan kapcsolat, amelyen keresztül az egyik program kéréseket küldhet egy másiknak). Ebben az esetben a harness feladatát a fejlesztő saját kódja látja el.

Feleslegessé teszik-e a jobb modellek a harnesseket?

A jobb modelleknek talán kevesebb lépésenkénti útmutatásra lesz szükségük, így a harnessek mai szerepe részben visszaszorulhat. Egy modell azonban önmagában csak szöveget alakít szöveggé. Nincs internetkapcsolata, és más alkalmazásokhoz sem fér hozzá. A fájlok elérése, a műveletek végrehajtása és a jóváhagyási szabályok érvényesítése mind a modellt körülvevő szoftverben történik, így ez a munka valószínűleg a harnessnél marad, bármennyire fejlettek is lesznek a modellek.