# Válaszvázlatok a gondolatébresztő kérdésekhez

Ez a fájl a könyv mind a tíz fejezetének gondolatébresztő kérdéseihez gyűjti össze a válaszvázlatokat. A legtöbb gondolatébresztő kérdés nyitott végű, és nincs egyetlen helyes válasza. A válaszvázlatokat AI generálta, emberi könnyed ellenőrzéssel, és kizárólag az olvasók összehasonlítására és inspirációjára szolgálnak. Az olvasókat bátorítjuk, hogy használjanak egy LLM-et a könyv tartalmával együtt e kérdések további megvitatásához.

## 1. fejezet: Ismerkedés az AI-ügynökökkel

**1. (★★) Ha csak egy képességet adhatnál egy ügynökrendszerhez – egy erősebb modellt, gazdagabb kontextust vagy több eszközt –, melyiket választanád? Milyen körülmények között változna meg a választásod?**

> Az "agy/szemek/kezek és lábak" formulát követve először a gyenge láncszemet keresd: általában a prioritás a kontextus gazdagítása – vagyis a megfigyelési tér kiterjesztése. Ha a feladat meghaladja a modell érvelési képességét, válts erősebb modellre. Ha a cselekvési tér nem elégséges (például nincs hozzáférés belső vállalati rendszerekhez), adj hozzá eszközöket. A megítélés módja a hibapályák elemzése és annak meghatározása, hogy a szűk keresztmetszet az észlelésben, a döntéshozatalban vagy a cselekvésben rejlik.

**2. (★★★) Egy ReAct ciklusban az összesített cache-olvasási mennyiség a körök számával közel négyzetesen nő. Hogyan csökkenthető ez a növekedés?**

> Az i. körben olvasott cache-előtag hossza megközelítőleg arányos i-vel, ezért az összesített olvasási mennyiség 1 + 2 + ... + n = O(n²). A négyzetes növekedés az összesített cache-olvasási díjra vonatkozik, nem a trajektória hosszára vagy a KV Cache méretére; ezek közel lineárisan nőnek. Egy tokenküszöb elérésekor a korai trajektória kötegelve tömöríthető úgy, hogy csak a következtetések és a kulcsállapot maradjon meg; a nagy köztes eredmények külső tárba helyezhetők és igény szerint lekérhetők, vagy alügynökökbe izolálhatók. Nem érdemes minden körben tömöríteni: ez ronthatja az Agent teljesítményét, és további tömörítési hívásokkal, illetve cache-újraépítési költséggel jár.

**3. (★★) A "Model as Agent" paradigma azt jelenti, hogy a modellek egyre autonómabbak az eszközhívási döntésekben. Ez a fejezet azonban azt állítja, hogy a Harness engineering fontossága valójában növekszik. Hogyan létezhet együtt ez a két trend? Hol van az ügynökkeretrendszerek jövőbeli alapvető értéke?**

> A ló és kantár metafora: minél erősebb a modell és minél nagyobb az autonómiája, annál szélesebb a hibák becsapódási sugara, és annál nagyobb a korlátozás, ellenőrzés és korrekció iránti igény. A keretrendszerek értéke az "LLM-hívások összehangolásáról" a Harness öt elemének biztosítási rétegére tolódik: engedélyosztályozás, megszakítók (circuit breakers), hibakezelés, kontextus-tömörítés és az eszközök ökoszisztémája.

**4. (★★) Az abláció vizsgálatban az "eszközeredmények visszajelzésének" hiánya végtelen ciklusba taszította az ügynököt. Éles üzemi környezetben az eszközeredmények hiányán kívül milyen más helyzetek okozhatják, hogy egy ügynök ciklusba kerüljön? Milyen észlelési és megszakítási mechanizmusokat terveznél?**

> Egyéb okok: egy eszköz ismételten ugyanazt a hibát adja vissza; hallucinált hívások nem létező eszközökhöz; a kontextus-tömörítés eldob kritikus állapotinformációt; a gondolkodási tartalom levágása és a modell API hibája; maga a feladat megoldhatatlan. Mechanizmusok: megállási feltételek, például maximális iterációszám beállítása; ismétlődő hívások detektálása (ugyanazon eszköz + argumentum ujjlenyomat); emberi beavatkozásra eszkalálás, ha egy hibaküszöb túllépésre kerül.

**5. (★) Ez a fejezet öt ügynökterméket elemzett három dimenzió mentén: aktuális információhalmaz, cselekvési interfészek és stratégia. Válassz ki egy általad naponta használt AI-terméket, elemezd ugyanezen három dimenzió mentén, és ítéld meg, hogy az architektúrája megfelelő-e. Ha te terveznéd, min javítanál?**

> Nyitott végű. Főbb pontok: a fejezet táblázatát követve írd le a szemeket (milyen információforrásokat láthat), a kezeket és lábakat (a cselekvési tér nyitott végű-e, képes-e belső gondolkodásra), valamint a stratégiát (az Agent végrehajtási hurkának mintázata).

**6. (★★) Ha egy kifejezetten repülőjegy-foglalásra szánt ügyfélszolgálati rendszert terveznél, milyen mintát – munkafolyamatot vagy autonóm ügynököt – választanál? Lehetséges-e a két minta keverése ugyanabban a rendszerben?**

> Használj workflow-t gerincként: négy csomópont – személyazonosság-ellenőrzés → keresés → fizetés → foglalás –, ami garantálja a megfelelő sorrendet, például "nincs foglalás fizetés előtt", és a prompt-injekciós támadási felületet egyetlen csomópontra korlátozza. Válts autonóm Agent-re a nyitott végű szegmensekhez (igények megértése, átfoglalás, alternatívák ajánlása járattörléskor). Adj hozzá emberi megerősítést magas kockázatú műveletekhez (nagy összegű fizetések, visszatérítések).

**7. (★★★) A védőkorlátok rész említette az eszközkockázat-besorolást. Ha egy eszköz általában alacsony kockázatú, de bizonyos paraméterkombinációkkal magas kockázatúvá válik (pl. a `delete_file` egy normál fájl törlése vs. egy rendszerfájl törlése), hogyan terveznéd meg a dinamikus kockázatértékelést?**

> Finomítsd az értékelés célpontját "eszközről" "eszköz + argumentumokra": számítsd ki a kockázatot híváskor a visszafordíthatóság, engedélyek és becsapódási sugár alapján. Használj szabályalapú determinisztikus ellenőrzéseket (útvonal-engedélyezési/tiltási listák, reguláris kifejezések) modellítélet helyett. Az ellenőrzés csak strukturált adatokat nézzen, hogy védjen a prompt-injekciós manipuláció ellen.

**8. (★★) Az ügynöktermék-táblázatban ebben a fejezetben minden ügynök "nyitott" cselekvési térrel rendelkezik. Milyen forgatókönyvekben lenne egy korlátozott cselekvési tér (pl. csak előre meghatározott opciókból lehet választani) jobb, mint egy nyitott?**

> Magas megfelelőségi, magas kockázatú, visszafordíthatatlan hibájú forgatókönyvek: visszatérítéseknél és fizetéseknél a korlátozott opciók "megkötések" – eleve hibabiztosak, lehetetlenné teszik a hibákat tervezés által.

**9. (★★) Az emberi közreműködés mechanizmusa megköveteli az ügynöktől, hogy "kecsesen adja át a vezérlést". A gyakorlatban azonban a felhasználó lehet offline, lassan válaszolhat, vagy homályos utasításokat adhat. Mit tegyen ilyenkor az ügynök?**

> Hibabiztos működés: magas kockázatú műveletek szüneteltetése, ha nem érkezik megerősítés, ahelyett, hogy alapértelmezés szerint végrehajtaná; a visszafordítható, alacsony kockázatú részek elvégzése először, a magas kockázatúak dokumentálása, hogy egy ember dönthessen és az Agent folytathassa; értesítés aszinkron kommunikációs eszközökön keresztül (üzenetek, e-mail) időtúllépési politikával; szándéktisztázás homályos utasítások esetén.

**10. (★★★) A bevezetés kijelenti, hogy "a jó tervezési elveknek túl kell mutatniuk a modell-iterációs ciklusokon", de az ezeket megvalósító konkrét mérnöki módszerek a modellek képességeinek fejlődésével elavulhatnak. Adj példát egy ilyen Agent-mérnöki módszerre, és indokold meg.**

> 1. példa: korlátozott mintavételezéssel szigorú formátumra kényszeríteni az eszközhívásokat. Ez megbízhatósági javítás azoknál a modelleknél, amelyek gyakran érvénytelen JSON-t adnak ki vagy paramétereket hagynak el. A formátumkövetés javulásával a haszna csökkenhet, de magas kockázatú helyzetekben továbbra is determinisztikus formátumellenőrzésre van szükség.
>
> 2. példa: külső tudásbázist bevezetni, mert a modell nem képes folyamatosan befogadni az új tudást. Ha a modellek később megbízható folyamatos tanulási képességet kapnak, a tudáskarbantartás egy része a külső rendszerekből a modell paramétereibe költözhet. A külső tudásbázisok azonban önálló értéket nyújtanak a valós idejű frissítés, a pontos visszakeresés, a hozzáférés-szabályozás és a forráskövetés terén, ezért inkább az alkalmazási körük szűkülhet, mintsem teljesen eltűnnének.
>
> 3. példa: minden képességet kötelezően a modell API-jának szabványos eszközhívási felületén elérhetővé tenni, és megtiltani az egyedi hívási formátumokat. A Skills másik utat mutat: szövegben leírja a képességet és a használat módját, majd egy általános parancssori eszközzel hajtatja végre a modellel. A modell szempontjából ez egy általános végrehajtó fölé épített egyedi szöveges hívási protokoll megértését és követését jelenti. Ahogy a modellek egyre jobban értik a tetszőleges interfészeket, a "mindig a szabványos eszközhívási formátumot kell használni" már nem egyetemes elv. A szabványos formátumok továbbra is hasznosak az interoperabilitáshoz, a strukturált ellenőrzéshez és a kevésbé képes modellekhez, de a helyzettől függő mérnöki választásnak kell lenniük.
>
> 4. példa: a promptokat és minden eszközdefiníciót előre a kontextus elejére helyezni. Ez a gyakorlat azért alakult ki, mert a korai modellek utasításkövetési képessége korlátozott volt, és a megszokott rögzített helyeken kívüli promptokat vagy eszközdefiníciókat gyakran nem ismerték fel, illetve nem hajtották végre helyesen. A Skills futás közben, igény szerint a kontextus közepére tölti a promptokat, a dinamikus eszközfelfedezés pedig a már meglévő trajectory után fűzi az újonnan megtalált eszközök definícióit. Az utasításkövetés javulásával és az ilyen dinamikus betöltési módokra irányuló speciális utótanítással a promptokat és az eszközdefiníciókat már nem kell a kontextus elején rögzíteni.

## 2. fejezet: Kontextus-tervezés

**1. (★★★) A 2-3. kísérlet megállapította, hogy a csúszóablakos beszélgetéstörténet az ügynököt ugyanazon eszközhívások ismételt végrehajtására készteti. A teljes történet megtartása azonban a kontextus korlátlan növekedését okozza. Tervezzen egy stratégiát, amely elkerülheti az információvesztést, miközben szabályozza a kontextus hosszát, anélkül, hogy megtörné a KV Cache előtagot.**

> ① Cseréld ki az eldobást tömörítésre: üzenetek csak hozzáfűzésre kerülnek, soha nem törlődnek vagy szerkesztődnek; egy küszöb (pl. az ablak 80%-a) közeledtével kötegelt tömörítés a régi eszközeredményekre. ② Rétegezett mechanizmus: nagy kimenetek perzisztálása lemezre egy összegzéssel, zaj teljes törlése, és archív összegzések megtartása, amelyek megőrzik a szálat. ③ Alügynök-izoláció, így a köztes állapot soha nem kerül a fő kontextusba.

**2. (★★) A Qwen3 Chat Template gondolkodási lánc megtartási mechanizmusa csak az "utolsó valódi felhasználói üzenet utáni" érvelési tartalmat tartja meg. Ha egy ReAct hurok több száz eszközhívást foglal magában, a felhalmozott érvelési tartalom nagy mennyiségű kontextust fogyaszthat. Hogyan módosítaná ezt a mechanizmust a nagyon hosszú hurkok kezelésére? A DeepSeek R1 egykor az összes történelmi érvelési tartalom eltávolítását írta elő, míg a DeepSeek V4 ezt megfordította, hogy kötelező legyen az összes `reasoning_content` visszaadása – a két ellentétes stratégiát összehasonlítva, melyek az egyes előnyei és hátrányai? Mit jelez ez a fordulat?**

> Módosítási irány: csúszóablakos megtartás – a legutóbbi gondolkodási körök teljes megtartása; az ablakon kívül gördülő tömörítés token-költségvetés alapján (nem fix körszám alapján), strukturált állapotsáv létrehozása (jelenlegi cél, megerősített tények, kizárt utak, teendők). A tömörítés csak egyszer és egy rögzített pozícióban történik, így a cache-újraépítés költsége egyszer fizetendő, nem minden körben. R1 levágása: tokeneket takarít meg, stabil előtagot és cache-barát viselkedést biztosít, illeszkedik a betanítási eloszláshoz (történeti CoT soha nem jelenik meg a bemenetben); de minden körben a semmiből érvel, a hosszú távú tervek elvesznek, a hibák ismétlődnek. V4 kötelező visszaadása: koherens gondolkodás és jobb teljesítmény hosszú horizontú agentikus feladatokon; de magas tokenköltség, előtag-duzzadás minden körben, és nincs zökkenőmentes váltás nem-gondolkodó módból. A fordulat azt mutatja: tiszta dialógusban a gondolkodás pazarlás; agentikus forgatókönyvekben a gondolkodás állapot – és az iparági gyakorlat az utóbbi felé mozdult.

**3. (★★) A kontextustudatos tömörítési kísérletben körülbelül 148 000 karakter tömörítése körülbelül 2 000 karakterre – ez a szélsőséges tömörítés kockáztatja a "visszafordíthatatlan információvesztést"? Hogyan lehet ezt kezelni?**

> Igen, van kockázat: a tömörítés veszteséges vetítés, és ha a kérdés egy nem megőrzött dimenzióra esik, megtörik. A megoldás: "veszteséges tömörítés + veszteségmentes indexelés" – minden tény egy forrás URL-t hordoz a nyomonkövethetőségért; a nyers kimenetek lemezen tárolódnak, csak összegzett előnézetekkel a kontextusban; explicit megőrzési prioritások – architekturális döntések, szemantikai integritás (idők, cégnevek), ellenőrzési állapot és azonosítók, mint UUID-ek/hashek szó szerint megőrizve; adaptív ablakozás késlelteti a tömörítés pillanatát.

**4. (★★) Az Ügynöki Állapotsáv explicité teszi a burkolt állapotokat. Ha azonban az állapotsáv maga hibás információt tartalmaz (pl. egy hiba az eszközszámlálóban), az ügynök helytelen információ alapján hozhat káros döntéseket. Hogyan lehet ezt a "metainformáció-megbízhatósági" problémát enyhíteni?**

> A modell szinte feltétel nélkül megbízik az állapotsávban, így a hibák úgy terjednek tovább, ahogy vannak. Enyhítések: ① karbantartás determinisztikus kóddal – soha ne hagyd, hogy egy LLM kötegelt számlálást végezzen hosszú előzményeken (ha muszáj, tételenként kivonatolni és kódban összesíteni); ② az állapotsáv pontosságának nyomon követése első osztályú termelési mérőszámként; ③ információk csak megbízható valós világbeli megfigyelésekből származzanak, védekezve az állapotsáv-mérgezés ellen.

**5. (★★) A prompt tervezés ablációs kísérlete azt mutatja, hogy a rendezetlen információ több mint 30%-os sikerességi arány csökkenéshez vezet. A valós fejlesztésben azonban a rendszer promptot gyakran többen, különböző időpontokban karbantartják. Milyen mérnöki gyakorlatokat használna annak megakadályozására, hogy a rendszer promptok időben egyre rendezetlenebbé váljanak?**

> ① Kezeld a promptokat kódként: verziókövetés és felülvizsgálat, ahol a termékmenedzserek határozzák meg az üzleti szabályokat, a mérnökök pedig kódolják azokat; ② használj Tau-Bench-szerű benchmarkokat regressziós tesztekként, futtass ablációkat a változtatások előtt és után a hatás lokalizálásához; ③ kényszeríts ki struktúrát: SOP-vezérelt folyamat a szabályhalmazok helyett, rétegezve XML/Markdown segítségével; ④ osztályozd és nevezd el a töredékeket "cache-elhető / cache-törő" kategóriákba, a dinamikus tartalmat a cache-határ után helyezve; ⑤ a felfúvódott tartalmat oszd fel igény szerint betöltött Skills-ekre.

**6. (★★★) Ez a fejezet azt állítja, hogy "a kontextuson belüli tanulás lényegében visszakeresés, nem érvelés." Ha ez az állítás igaz, akkor az összes jelenlegi, "több információ kontextusba helyezésén" alapuló optimalizációs irányt újra kell értékelni. Ön szerint hogyan lehet ezt a korlátot leküzdeni?**

> Adj hozzá egy desztillációs réteget ehhez a "fél lekérőmotorhoz": ① kontextus-desztilláció / az állapotsáv – használj kódot a következtetések előre kiszámításához közvetlen lekéréshez; ② aktív tömörítés, a nyers rekordok helyettesítése nagy sűrűségű strukturált tudással; ③ alügynök-izoláció, a zaj kizárása a fő kontextusból; ④ interakció mint harmadik tengely – külső eszközök megfigyelnek és visszaírnak olyan új információt, amit a modell nem tudott kigondolni; ⑤ határvonali irányok: szerkeszthető, összeállítható KV Cache "jegyzetek" és munkamenetek közötti memóriakonszolidáció.

**7. (★★★) A Készségek progresszív feltárása csak akkor tölti be a teljes tartalmat, amikor az ügynök úgy ítéli meg, hogy szükség van rá. Ez az ítélet azonban maga is a modell képességétől függ – ha a modell nem tudja, hogy mit nem tud, nem tudja helyesen kiváltani egy Készség betöltését. Hogyan lehet ezt a "metakogníciós" problémát megoldani?**

> ① Tartsd a Skill metaadatait (név, leírás) a kontextusban rezidensként, hogy a modell mindig "tudja, mije van"; ② írd a Skill leírást útválasztási feltételekként, ne funkcióbemutatóként – "Használd, ha / Ne használd, ha" – kerülve a homályos leírásokat.

**8. (★★) A Készségek mechanizmusában, miután az ügynök dinamikusan betölti az utasításokat a `SKILL.md`-ből, a későbbi műveletek megbízhatóan követik-e azokat? Milyen különbségek vannak a modelltámogatásban a Készségek mintázatához?**

> Attól függ, hogyan injektálódik a Skill: a rendszerpromptba injektálva a legerősebb az utasításkövetés, de megtöri a KV Cache-t; közönséges fájlként a kontextus közepébe olvasva gyengébb utasításkövetést adhat; a kontextus végére injektálva jó utasításkövetést ad, de a Skill rész KV-jét minden eszközhívásnál újra kell számolni, ami költséges.

**9. (★★★) Ez a fejezet hangsúlyozza, hogy a dinamikus információk változásai (pl. rendszeridőbélyegek, eszközlista sorrendje) megtörhetik a KV Cache előtag találatokat. Egy nagy számú eszközzel és gyakran változó eszközkészlettel rendelkező production rendszerben hogyan tervezné meg a kontextus elrendezését a gyorsítótár találati arány maximalizálása érdekében?**

> ① Egy kis halmaz stabil mag-eszköz (mondjuk hét) plusz egy általános végrehajtó, a specifikus képességek a Skills progresszív felfedésén keresztül érkeznek; az eszközdefiníciók a statikus előtagban rögzített sorrendben fagynak le; ② az alügynökök ugyanazt az előtagot tartják, mint a szülő Agent.

## 3. fejezet: Felhasználói memória és tudásbázis

**1. (★★) Egy felhasználói memóriarendszerben, amikor ugyanaz a felhasználó különböző szekciókban ellentmondó információkat ad meg (pl. két különböző lakcímet említ), hogyan kezelje a memóriarendszer ezt a konfliktust?**

> Használj egy Mem0-stílusú "kivonat–összehasonlít–dönt" csővezetéket: először hasonló régi emlékek lekérése vektoros kereséssel, majd egy LLM dönt ADD/UPDATE/DELETE/NOOP műveletről – például "elköltözött Sanghajba" frissítse és írja felül a "Pekingben lakik" bejegyzést. Verziózás: a cím típusú információknál csak a legújabb verzió tárolása időbélyeggel, de a munkatapasztalat típusú információknál a teljes előzmény megtartása. A lekérési oldalon a kontextuális előtagok (személy, idő, szándék – mint a háromszor módosított átutalás esetében) segíthetnek megítélni, melyik bejegyzés a végül érvényes.

**2. (★★) A Kontextuális visszakeresés az eredeti dokumentumból származó kontextust ad hozzá minden darabhoz. Ha azonban maga az eredeti dokumentum strukturálisan zavaros vagy ellentmondó információkat tartalmaz, ez a módszer továbbadhatja, sőt akár felerősítheti is a hibákat. Hogyan vezetnél be egy "információminőségi" jelet a visszakeresési fázisban?**

> Meríts a "tudásbázis-frissesség és -irányítás" témakörből: csatolj metaadatokat, például verziószámokat, hatályba/lejárati időket és forrásokat a darabokhoz; szűrd ki a lejárt tartalmat lekéréskor, vagy jelöld meg explicit módon az előtagban "ezt a bejegyzést visszavonták ilyen-olyan dátumon"; a rangsorolási szakaszban építsd be a forrás tekintélyét és az időbeli frissességet a pontszámba a puszta szemantikai relevancia helyett; indexeléskor az előtag-generáló LLM is érzékelje és jelezze a darabok közötti ellentmondásokat, hasonlóan a verziózott ütközésdetektáláshoz a memóriában.

**3. (★★) A multimodális információ-kinyerés a diagramokat szöveges leírásokká alakítja a visszakeresés előtt. Ez az "átalakítási" folyamat elveszítheti a vizuális információ térbeli kapcsolatait. Adj egy konkrét példát olyan diagram információra, amelyet a tiszta szöveges leírás nem képes teljesen visszaadni, és tervezz egy sémát az információ megőrzésére.**

> Példák: a logikai kapcsolatok egy rendszerarchitektúra-diagramban, két görbe metszéspontjának helyzete egy vonaldiagramon, vagy a cellák és fejlécek sor-oszlop megfeleltetése egy PDF táblázatban. Első lehetőség: natív multimodális feldolgozás; második lehetőség: egy multimodális képelemző eszköz biztosítása.

**4. (★★★) Rich Sutton "Bitter Lesson" érve szerint az általános módszerek (keresés és tanulás) végül felülmúlják a kézzel készített jellemzőket. Vajon az e fejezetben felépített teljes tudásrendszer (darabolási stratégiák, indexstruktúrák, visszakeresési csővezetékek) maga is a "kézzel készített tervezés" egy formája? Ha a modell képességei elég erőssé válnak, ezek a tervek helyettesíthetők-e az egyszerű "mindennek a betáplálásával"?**

> Valóban kézzel készített tervezés, és egyes szakaszok (darabolás, fúziós hangolás) gyengülhetnek, ahogy a kontextus hosszabb lesz; de a fekete-macska/fehér-macska eset azt mutatja, hogy a "mindent bemenetként adni" sem elég: a figyelem (attention) lágy lekérés, és a dokumentumok közötti aggregáció és statisztikák továbbra is elő-desztillációt igényelnek az indexeléskor; a mérnöki korlátok, mint a tudás lejárata és frissítése, engedély-/bérlő-izoláció, naplózhatóság és költség, függetlenek a modell képességétől; és a lekérés plusz LLM-desztilláció az indexeléskor maga is egy általános "keresés + tanulás" módszer, nem ellentétes a Keserű leckével.

**5. (★★★) Ahogy a modell képességei javulnak, szerinted a szakterület-specifikus tudásbázisok továbbra is fontosak lesznek? Lehetséges, hogy egy jövőbeli erős alapmodell tartalmazza a szakterületi tudásbázis összes információját, ezáltal feleslegessé téve azt?**

> Továbbra is fontos: a betanítási adatoknak van vágási dátuma, míg egy tudásbázis bármikor frissíthető; a belső vállalati folyamatok, magánjogi esetjog és hasonlók egyszerűen nincsenek benne a nyilvános korpuszban; a többfelhasználós megosztáshoz engedélyszűrés és bérlő-izoláció kell, a paraméterekben lévő tudás pedig nem szabható testre hívónként; a külső tárolás naplózható, verziókövethető, és a lejárt tartalom offline állapotba helyezhető – a parametrikus memória ezt aligha tudja; még a parametrikus úton (post-training / User as Engram) is szembesülsz azzal a problémával, hogy "emlékezni könnyű, de a tényeket többugrásos érveléshez használni nehéz".

**6. (★) A RAPTOR egy alulról felfelé építkező hierarchikus összefoglalással fa indexet épít, míg a GraphRAG entitás kapcsolatokon keresztül gráfstruktúrájú indexet épít. Milyen típusú lekérdezések megválaszolásában jó ez a két strukturált index?**

> RAPTOR: "rétegeken átívelő" lekérdezések, amelyek makro fogalmaktól részletekig hatolnak – például először a "SIMD utasításkészlet" összegzésének megtalálása, majd a részletezés az SSE részletekbe – lefedve mind az áttekintő, mind a részletes granularitásokat. GraphRAG: többugrásos relációs érvelés ("annak a kórháznak a címe, ahol az orvosom dolgozik", a relációs lánc bejárása) és entitás-egyértelműsítés (két "Dr. Kovács" különböző csomópontok) – "mi a kapcsolat A és B között" típusú lekérdezések; a közösségi összegzések tematikus klaszterezést is nyújtanak.

**7. (★★) A fájlrendszer paradigma a tudást a fájlrendszerhez hasonló hierarchikus struktúrába szervezi. A hagyományos vektoros adatbázis RAG-hoz képest milyen forgatókönyvekben van előnye ennek a megközelítésnek?**

> A plain text fájlokat a felhasználók közvetlenül olvashatják, szerkeszthetik és javíthatják, valamint Git-tel verziókövethetők és visszaállíthatók – alkalmas olyan forgatókönyvekre, ahol emberek és gépek közösen tartják karban és ellenőrzik a tudást; a write_file képességgel az Agent autonóm módon rögzíthet tapasztalatokat, önfejlődő memóriaciklust képezve (externalizált tanulás); az L0/L1/L2 progresszív felfedés lehetővé teszi, hogy a legtöbb lekérdezést L1 szinten eldöntsék, tokeneket megtakarítva; az előfeltétel a keresztlinkek és indexoldalak kiépítése, mint a Wikipédiában – különben minél több elszigetelt fájl van, annál nehezebb a lekérés.

**8. (★★★) A "ítélkezési tényezők" és a "tényező fontossági hierarchiák" automatikus felfedezése strukturált adatokból (pl. bírósági ítélkezési adatbázisokból) lényegében azt jelenti, hogy az Ágens szabályokat indukál az adatokból. Elérheti ez az adatvezérelt tudáskinyerés az emberi szakértők által kézzel összeállított szabályok minőségét?**

> Előnyök: mint a CAIL2018 kísérletben, az "alulról felfelé" tényezőfelfedés illeszkedik az adatokhoz, nem emberi előfeltevésekhez; képes megragadni az implicit kompromisszum-tapasztalatokat, amelyek tízezerszám szóródnak szét az ítéletekben, és amelyeket a szakértők aligha tudnának explicit leírni; és kvantifikálható. Korlátok: az LLM-kinyerési hibák tudásszennyezést okoznak; magának az adatnak a torzításai öröklődnek; a klaszterezési prototípusok csak korrelációt tükröznek, nem tudnak okozati összefüggést magyarázni. Kompromisszum: adatvezérelt modellezés plusz szakértői felülvizsgálat a sémán és az eredményeken – a modellek vezetik a kérdezést, a statisztika támogatja a magyarázatokat.

**9. (★★★) Tervezz egy Markdown-alapú felhasználói memóriatárhoz növekményes frissítési és rendszeres átszervezési folyamatot. Ha a Reviewer és a Proposer ugyanazt a modellt használja, és a Reviewer csak a Proposer által kiválasztott beszélgetésrészleteket látja, milyen hibák kerülhetnek mégis be? Ismertesd a javításokat a modellek függetlensége, a bizonyítékok lefedettsége és az eszközengedélyek szempontjából.**

> Inkrementális frissítés: kezeld a memóriatárat kódtárként, és minden változás menjen át egy PR-en. A Proposer először visszakeresi a kapcsolódó meglévő tudást, majd a lehető legkisebb, mégis teljes diffet javasolja, egyúttal karbantartva a hivatkozásokat, indexeket, időbélyeg-metaadatokat és bizonyítékhivatkozásokat; a Reviewer a változás előtti tudás, a diff és a nyers bizonyíték alapján függetlenül auditál, elutasításkor pedig konkrét bizonyítékra és sorszámra mutató, végrehajtható észrevételeket ad vissza; az iterációnak legyen maximális száma vagy költségkerete, és a túllépés emberi eszkalációt jelentsen, ne alapértelmezett átengedést. Összefésülés után a CI előbb formátumot, hivatkozásokat, metaadatot és jogosultsági címkéket ellenőriz, és csak azután építi újra inkrementálisan az érintett darabokat és vektorindexeket a beolvasztott verzióból. Időszakos rendezés: idő vagy új bejegyzésszám alapján indíts teljes átvizsgálást — deduplikálás, összevonás, túl nagy fájlok szétbontása, belépőoldalak újraépítése; a lényeg az, hogy bekezdésenként visszatérj az eredeti beszélgetésekhez, és ellenőrizd, nem esett-e ki a régi összefoglalókból egy tagadószó, időfeltétel vagy megszorítás. Az ellentmondásokat ne a „tartsuk meg a legfrissebbet” szabállyal zárd le, hanem vezesd vissza mindegyiket a forrásához, és írd le, milyen feltételek mellett érvényes; ha a bizonyíték kevés, tartsd meg a konfliktust és jelöld megerősítésre várónak. Az átszervezés is PR-ként megy be, szükség esetén könyvtáranként bontva, és miután mind átment, az index újraépítése mellett játssz vissza egy tipikus keresési esetsort is, hogy a korábban megtalálható tudás ne vált-e láthatatlanná.
>
> Ugyanaz a modell előre kiválogatott részletekkel három hibaosztályt szalaszt el. **Modellfüggetlenség**: az azonos családba tartozó modellek osztoznak a tanulási előfeltevéseken és a vakfoltokon, így a Reviewer hajlamos a Proposer következtetését ismételni ahelyett, hogy visszatérne a bizonyítékhoz, és a közös félreolvasás észrevétlen marad — használj hasonló képességű, de más családból való modellt a keresztellenőrzésre. **Bizonyítéklefedettség**: pusztán a Proposer által kiválasztott részletekből nem derül ki sem a kontextusból kiragadott idézet, sem az elhagyott tagadószavak és előfeltételek, sem a más fájlokkal való ütközés — a Reviewernek önállóan kell tudnia lekérdezni a teljes tudásbázist és a nyers bizonyítéktárat, a számára engedélyezett bérlői vagy felhasználói körön belül. **Eszközjogosultságok**: ha a Proposer közvetlenül írhat a fő ágra vagy módosíthatja az éles indexet, a felülvizsgálat üres formalitás — kényszerítsd ki a szétválasztást: a Proposer csak munkaágra ír, a Reviewer csak bizonyítékot olvas és ítéletet ad be, a fő ágat és az éles indexet kizárólag az összefésülési folyamat frissítheti, a verifikátorok és a kiadási kapuk pedig a módosítható körön kívül maradnak.

## 4. fejezet: Eszközök

**1. (★★) Az MCP szabvány leválasztja az eszközdefiníciókat az Agent keretrendszerről. A szabványosítás ugyanakkor azt is jelenti, hogy az összetett eszközinterakciós minták (pl. streaming kimenet, kétirányú kommunikáció, állapotos munkamenetek) nehezen fejezhetők ki egy szabványos protokollon belül. Ön szerint milyen képességgel kellene az MCP-nek leginkább bővülnie a jövőben?**

> A leginkább szükséges bővítés a munkamenetek közötti, eseményvezérelt működés. Az MCP már támogat többlépéses interakciókat, változás-előfizetéseket és hosszú ideig futó feladatokat, de a lényege továbbra is egy képességhívás szabványosítása, nem pedig az Agent folyamatos online tartása. Új e-mail vagy külső visszahívás hatására az Agent felébresztése, valamint több esemény sorba állítása, folytatása és újrapróbálása továbbra is az Agent keretrendszer feladata. Az ilyen vezénylés egységesebb konvenciói az MCP hatókörét a protokoll egyszerűségének feladása nélkül bővítenék.

**2. (★★) Az MCP ökoszisztémában a különböző MCP szerverek erősen átfedő funkcionalitású eszközöket biztosíthatnak. Amikor egy Agent több, funkcionálisan hasonló eszközzel szembesül különböző forrásokból, hogyan válasszon? Ha az azonos nevű eszközök a különböző forrásokból kissé eltérően viselkednek (pl. az egyik összefoglalót, a másik teljes szöveget ad vissza), képes-e az Agent érzékelni és kihasználni ezt a különbséget?**

> Kiválasztási kritériumok: integráció előtt tekintsd át a leírásokat, rögzítsd a verziókat, és konfigurálj least-privilege hitelesítő adatokat; óvakodj az azonos nevű eszközök árnyékolásától, amely érzékeny hívásokat irányíthat egy rosszindulatú félhez; futásidőben szűkítsd a jelölteket hierarchikus osztályozással és dinamikus felfedezéssel. Az, hogy a modell érzékeli-e a viselkedésbeli különbségeket, az eszközleírások minőségétől függ.

**3. (★★) Ez a fejezet egy "végrehajtás-érvényesítés-visszacsatolás" hurkot javasol (pl. automatikus linter futtatása kódírás után). Milyen más eszköz forgatókönyvekre alkalmazható ez az "azonnali művelet utáni automatikus érvényesítés" minta? Vannak olyan műveletek, ahol az érvényesítés költsége vagy kockázata maga is meghaladja a műveletét, ami miatt a minta nem alkalmazható?**

> Általánosítható forgatókönyvek: konfiguráció módosítása után tényleges futtatás sandboxban a hatás ellenőrzésére; dokumentum/prezentáció generálása után renderelés képernyőképekbe és a modell multimodális képességének használata az elrendezés ellenőrzésére. Nem alkalmazható: visszafordíthatatlan, nem idempotens műveletek, mint e-mail küldése, telefonhívás kezdeményezése vagy pénzátutalás – vagy nincs mit megfigyelni, vagy maga az érvényesítés egy másik valós eseményt vált ki; itt ex ante eszközökre kell váltani: Proposer-Reviewer előzetes jóváhagyás.

**4. (★★) Ez a fejezet felveti az "eszközrobbanás" problémáját – egy Agent kiválasztási pontossága romlik, amikor több ezer eszközzel szembesül. A proaktív eszközfelfedezésen kívül milyen más megközelítések léteznek? Gondoljon arra, hogy az emberi szakértők hogyan boldogulnak a rendelkezésre álló eszközök hatalmas gyűjteményével.**

> ① Hierarchikus csoportosítás: először a "szerver/alkalmazás" lokalizálása, majd a konkrét eszköz kiválasztása; ② Skills-stílusú "igény szerinti konzultáció": mint egy kézikönyv fellapozása – a katalógus a kontextusban marad, a részletek igény szerint töltődnek be; ③ néhány gyakran használt alapvető eszköz "kéznél tartva" a kontextusban, a többi a katalógus indexen keresztül érhető el.

## 5. fejezet: Kódoló Agent és kódgenerálás

**1. (★★) A kódgenerálást az Ágens "meta-képességének" nevezik. De a kódvégrehajtás biztonsági kockázatokat vezet be — az Ágens által generált kód tartalmazhat sérülékenységeket, végtelen ciklusba eshet, vagy erőforrásokat meríthet ki. A sandboxolás csökkentheti ezeket a kockázatokat, de korlátozza is, hogy mit tehet a kód, például megtagadva a hozzáférést a hálózathoz vagy a fájlrendszerhez. Hogyan található meg az optimális egyensúly a biztonság és a képesség között?**

> Szintezett sandbox-izoláció forgatókönyv szerint (konténerek/mikro VM-ek); alapértelmezés szerint nincs hálózat, fehérlistás proxy biztosít hozzáférést igény szerint; a forráskód csak olvashatóként van mountolva, az API-kulcsok a sandboxon kívül maradnak; sandbox erőforrás-korlátok beállítása; sandbox életciklus-kezelés (időtúllépések).

**2. (★★★) Az Ágens bootstrapping — egy Ágens, amely képes Ágenseket létrehozni — lehetővé teszi az "intelligencia önreprodukcióját." De minden bootstrapping iteráció új torzításokat vagy hibákat vezethet be. Felhalmozódnak-e ezek a hibák a generációk során? Hogyan akadályozható meg a degradáció az Ágens bootstrapping-ben?**

> Ha minden generáció az előző generáció eredményeire építve reprodukálja magát, bizonyos hibák felhalmozódhatnak. A kulcs a kellően kihívást jelentő, ellenőrizhető feladatok – például kellően nehéz programozási feladatok.

**3. (★★) Amikor egy kódgeneráló Ágens naplóelemzést végez, automatikusan követheti a formátumfejlődést. De ha egy formátumváltozás hiba, nem pedig szándékos módosítás, az Ágens alkalmazkodóképessége éppen ellenkezőleg, elfedheti a problémát. Hogyan különböztesse meg az Ágens az "alkalmazkodást igénylő változást" a "jelentést igénylő anomáliától"?**

> Diagnosztizálj az alkalmazkodás előtt: ellenőrizd az új formátumot architektúra dokumentumok és a PRD (termékkövetelmény-dokumentum) alapján, hogy várható-e (az 5-8. kísérlet gondolata); ellenőrizd a verziókövetési rekordokat, hogy a változás egy legitim kódkommitnek felel-e meg, nem pedig forrás nélküli sodródásnak; a τ-bench log_mismatch-jéhez hasonlóan, még ha az alkalmazkodás mellett döntesz is, naplózz egy riasztást és automatikusan nyiss egy hibajegyet a csendes tolerálás helyett; bizonytalanság esetén irányíts emberi beavatkozáshoz. Az elv: alkalmazkodás és jelentés párhuzamosan – az alkalmazkodás nem nyelheti el az anomáliajeleket.

**4. (★★) Ez a fejezet többször használja a Proposer-Reviewer mechanizmust PPT generálásban, videó szerkesztésben és napló vizualizációban. Ha a Reviewer esztétikai preferenciái eltérnek a célfelhasználóétól — például a Reviewer ésszerűnek tartja az információ sűrűséget, de a felhasználó túl zsúfoltnak találja — a visszacsatolási hurok egy rossz lokális optimumba konvergálhat. Hogyan építhető be a felhasználói preferencia visszajelzés a Reviewer hurokba?**

> Injektáld a felhasználói visszajelzést az Agent trajektóriájába a legmagasabb prioritású strukturált eseményként; externalizáld és konszolidáld a felhasználói preferenciákat MEMORY.md-be írva, hogy a preferenciák feladatokon átívelően érvényesüljenek; szállítsd a dokumentumokat HTML formátumban Markdown helyett, hogy a felhasználók megtekinthessék azokat.

**5. (★★) Ez a fejezet több módot is bemutat arra, hogy egy Kódoló Ágens hogyan szilárdíthatja meg a végrehajtás és hibakeresés során szerzett tapasztalatokat a kódbázisban — tudásbázis fájlok írása, architektúra dokumentáció frissítése, projekt utasítás fájlok karbantartása és műveleti szekvenciák kódba kódolása. Ha ez a tapasztalat tovább desztillálódik a rendszer promptban lévő szabályokká, a szabálykészlet idővel folyamatosan bővülni fog. Hogyan végezhető "szemétgyűjtés" a felhalmozott szabályokon a redundáns vagy elavult bejegyzések azonosítására és eltávolítására? Miért nem minősül egyetlen sikeres kódmódosítás még folyamatos fejlődésnek a 9. fejezet értelmében?**

> Szemétgyűjtés megközelítése: a linterbe, CI-be vagy eszköz-ellenőrzésbe kódolható szabályok kiszervezése a promptból; a szabályok találati arányának és ütközéseinek nyomon követése és időszakos újraérvényesítése a kódbázis ellen; Markdown és Git használata az eredet, verziók és visszaállíthatóság megőrzéséhez. Egy sikeres javítás csak azt mutatja, hogy az aktuális esetet megoldotta. A folyamatos evolúció tovább megköveteli, hogy a módosítás nyomon követhető műveleti bizonyítékokból származzon, javítsa a későbbi feladatokat, és átmenjen regressziós teszteken a régi feladatokon, valamint biztonsági validáción.

**6. (★) "Azok a csapatok, amelyek barátságosak a távoli munkához, általában barátságosak az AI Ágensekhez is." Mennyire áll közel a csapata vagy szervezete az "AI-kész" állapothoz a tudásdokumentáció szempontjából? Mi a legnagyobb akadály?**

> Nyitott végű. Önellenőrizheted a fejezet proxy mérőszámával: tud-e egy távoli új belépő önállóan dolgozni, csak a repository-t és a dokumentációt használva? Ellenőrző lista: döntések dokumentálva vannak-e; a kontextus bekerül-e az issue-kba/PR-ekbe; a build és teszt parancsok rendelkeznek-e utasításfájlokkal, mint CLAUDE.md/AGENTS.md; a törzstudás le van-e desztillálva fejlesztői útmutatókba. A leggyakoribb legnagyobb akadály: szóbeli hagyományozás és whiteboard-kultúra, amely a "melletted ülő kolléga megkérdezésére" támaszkodik – egy Agent nem tud szóbeli megállapodásokat olvasni, csak dokumentumokat.

**7. (★★★) Simon Willison javasolta a "Halálos Triászt" az Ágensek számára — hozzáférés a privát adatokhoz, kitettség megbízhatatlan tartalomnak és külső kommunikációs képesség. Ez a fejezet egy negyedik elemet ad hozzá: a perzisztens memóriát. Hogyan tervezne biztonsági stratégiát egy olyan termelési környezethez, amelynek mind a négyet egyszerre kell kezelnie?**

> Réteges védekezés négyféle határvonal mentén. Adathatár: nincsenek hitelesítő adatok mountolva, forráskód csak olvasható, minimális láthatóság. Bemeneti bizalmi határ: származás címkézése, a külső tartalom "tájékoztató jellegű, utasítási erővel nem bíró" adatra minősítése (a lojalitási magatartási kódex). Kimeneti hatáshatár: alapértelmezés szerint nincs hálózat fehérlistás kimenő forgalommal, parancsok szemantikai elemzése feketelisták helyett, független Sidecar felülvizsgálat plusz emberi beavatkozás – a kritikus műveleteket a kontextuson kívüli mechanizmusnak kell felülvizsgálnia. Munkamenetek közötti határ: a MEMORY.md-be írás ugyanazon bizalmi felülvizsgálaton megy keresztül, mint a külső tartalom. A cél: még ha injektálás történik is, a támadás ne legyen végrehajtható.

**8. (★★) Az Artefaktum minta lehetővé teszi, hogy egy Ágens SQL-t vagy vizualizációs kódot generáljon a frontend általi közvetlen végrehajtásra, megkerülve az LLM nagy mennyiségű adat feldolgozásának szükségességét. Milyen előnyei és hátrányai vannak ennek a munkamegosztásnak — "az Ágens generálja a kódot, a rendszer hajtja végre a kódot" — a hagyományos mintával szemben, ahol az Ágens közvetlenül adja a választ? Ezen felül a generált SQL végezhet destruktív műveleteket, és a generált HTML tartalmazhat sérülékenységeket. Hogyan biztosítható a rendszer biztonsága?**

> Előnyök és hátrányok: Előnyök: az adatok az adatbázisból egyenesen a frontendbe áramlanak, megkerülve az LLM "közvetítőt" – gyors, tokentakarékos, és mentes a nagy adatmennyiségek átírásakor fellépő hallucinációs hibáktól, így alkalmas nagy adatmennyiségek bemutatására; a kód naplózható, újrafelhasználható, és csővezetékekbe rendezhető (SQL-eredmények közvetlenül táplálhatók vizualizációs kódba). Hátrányok: az LLM soha nem látja a lekérdezési eredményeket, így nem tud további összegzést és döntéshozatalt végezni az adattartalom alapján – nem alkalmas olyan feladatokra, ahol a modellnek az adatok megemésztésére van szüksége az érvelés előtt.
>
> Biztonság: SQL: lekérdezések végrehajtása least-privilege csak olvasható fiókkal, valamint erőforrás-korlátok (CPU, memória stb.) hozzáadása az erőforrás-kimerítés megelőzésére. HTML/UI: előnyben részesíteni a deklaratív protokollokat, mint az A2UI, ahol az Agent csak interfészleíró JSON-t ad ki, és a kliens egy megbízható komponenskatalógusból rendereli anélkül, hogy tetszőleges kódot futtatna. Ha tetszőleges HTML szükséges, azt sandboxolt környezetben kell megjeleníteni az injekció megelőzésére.

**9. (★★) Az üzleti szabályok kódolása az adatbázis alapigazsággal szembeni validációkként, miközben a paraméter tervezés irányítja a modellt, hogy a hívás előtt ellenőrizze a szabályzatfeltételeket, lényegében kódstruktúrát használ az Ágens viselkedésének korlátozására. Milyen előnyei és korlátai vannak ennek a "kód mint szabályok" mintának a természetes nyelven kifejezett szabályokkal szemben?**

> Előnyök: egyértelmű, determinisztikus, és kiváló összetett feltételkombinációknál; a szabályzati tények az adatbázis valós állapotából és a szerveroldali órából származnak, nem a modell által bejelentett értékekből, így sem hallucináció, sem prompt-injekció nem kerülheti meg őket – a végső védelmi vonal visszafordíthatatlan műveletek ellen; az expected_* paraméterek kötelező ellenőrzőlistaként is szolgálnak, amely irányítja a gondolkodást. Korlátok: a kód nem magyarázza el a szabályzatokat a felhasználóknak, nem talál megkerülő megoldásokat, és karbantartási költségekkel jár. Következtetés: kiegészíti a természetes nyelvű szabályokat, nem helyettesíti azokat.
## Interakció: a megfigyelési és a cselekvési tér kiterjesztése

**1. (★★) Egy aszinkron Agent architektúrában az eseménysor prioritási stratégiáját a tervezéskor kell meghatározni. De ha a prioritás megítélése maga is szemantikai megértést igényel (pl. annak eldöntése, hogy egy új üzenet sürgősebb-e, mint az aktuális feladat), ki hozza meg ezt az ítéletet – egy szabálymotor vagy egy másik LLM hívás? Melyek az egyes lehetőségek költségei?**

> Rétegezett hibrid: a tiszta típusú események szabályokkal vannak kódolva – nulla késleltetés és erős determinizmus, de nem képes megérteni a szemantikai különbséget "azonnal hagyd abba" és "milyen ma az idő" között; a szemantikailag kétértelmű események egy könnyű osztályozó LLM-hez kerülnek esemény-útválasztóként, több száz ezredmásodperces késleltetés, többletköltség és lehetséges téves ítélet árán – és a Sidecar-hoz hasonlóan csak strukturált mezőket szabad olvasnia a prompt-injekció elleni védelem érdekében.

**2. (★★) A sor-alapú eseményfeldolgozásban a modellek hajlamosak csak az utolsó eseményre összpontosítani. Ez a fejezet Agent állapotsor jelzőkkel és összefoglalással enyhíti ezt. De ha a sorban 20 esemény halmozódott fel (10 eszközeredmény + 5 felhasználói üzenet + 5 rendszerriasztás), hogyan szervezné meg ezen események megjelenítési sorrendjét és formátumát, hogy a modell ne hagyjon ki fontos információkat?**

> Először osztályozd és deduplikáld szabályokkal és egy könnyű LLM-mel: a sürgős események (riasztások, felhasználói megszakítások) külön, cancel-típusú kezelésen mennek keresztül, és nem keverednek a kötegbe. A 10 túl hosszú eszközeredmény esetében csonkold és perzisztáld fájlokba, csak a fejet, a farkot és az elérési utat megtartva. Adj hozzá egy összegző listát a rendszer állapotsávhoz a kontextus végén (minden eseménytípus darabszáma + az egyes tételek megválaszolásának követelménye).

**3. (★★★) Amikor egy Agent a felhasználó nevében lép kapcsolatba a külső világgal, lényegében egy identitásválasztással szembesül: használjon független virtuális identitást (dedikált e-mail és telefonszám) harmadik félként, vagy közvetlenül a felhasználó személyes fiókjaiban működjön felhasználóként? Az előbbi lehetővé teszi az önálló háttérműködést, de a harmadik felek nem biztos, hogy megbíznak egy nem emberi identitásban; az utóbbi teljesebb kontextussal és engedélyekkel rendelkezik, de hitelesítési, bizalmi és biztonsági határvonali problémákat vet fel. Milyen forgatókönyvekben véli helyesnek az egyes módok választását?**

> Alapértelmezés szerint virtuális identitás: autonóm módon működhet a háttérben és naplózható, és ha hibázik vagy feltörik, nem teszi ki a felhasználó teljes digitális identitását – ahogy egy titkárnő is a saját irodai e-mailjét használja; kezelned kell a CAPTCHA/IP-reputációs problémákat (rezidens proxyk). Olyan forgatókönyvek, ahol a felhasználó saját identitását kell használni (fiókazonosság-ellenőrzés, háromutas hívás-megerősítés – mint amikor Pine felhívja az ügyfélszolgálatot) emberi beavatkozásos hitelesítést igényelnek: VNC/RDP segítségével a felhasználó személyesen és vizuálisan jelentkezhet be. A kritériumok: hogy a másik fél személyesen kéri-e a fióktulajdonost, valamint a művelet kockázata és a hitelesítő adatok hatóköre.

**4. (★★) A hangügynökök végponti modellje egyetlen modellbe olvasztja az ASR-LLM-TTS-t, csökkentve a késleltetést, de elveszítve a modularitást. Ha a végponti modell egy adott szakaszban hibázik (pl. beszédfelismerés), a hibakeresés és javítás sokkal nehezebb, mint egy soros csővezetékben. Hogyan tervezne megfigyelhetőségi rendszert egy végponti hangügynök számára?**

> A modell adjon ki olvasható köztes reprezentációkat a kimenete mellett, mint a Moshi "belső monológ" szövegfolyama és akusztikus eseményjelzői (`<emotion>`, `<noise>`). Használj "ön-kaszkádolást" a hibaréteg lokalizálásához: ugyanaz a modell először átír, majd gondolkodik, és az összehasonlítás a végponttól-végpontig eredménnyel megmutatja, hogy a hiba az észlelésben vagy a gondolkodásban van-e. Offline futtass tételes regressziós teszteket olyan dimenziók mentén, mint a paralingvisztikai megértés és a beszédátvételi ítélet.

**5. (★) A Step-Audio R1 az MPS kétagyú architektúrán keresztül éri el a "gondolkodva beszélést". Az emberek azonban, amikor "gondolkodva beszélnek", gyakran mondanak dolgokat, mielőtt teljesen átgondolták volna, önjavítanak, vagy töltelékszavakat használnak. Egy ügynök "gondolkodva beszélésének" utánoznia kellene ezeket az emberi jellemzőket?**

> Utánozza azokat a "tökéletlenségeket", amelyek jelzésértékkel bírnak: a szünetek és töltelékszavak externalizálják a gondolkodást és elfedhetik a késleltetést, az LLM dönti el, hová illessze be őket. Ne utánozza a bizalomromboló önjavítást: a gyors-lassú ellentmondás az 1. megoldásban ("vegyem meg vagy ne?!") összeroppantja a bizalmat. Az MPS kísérletek azt mutatják, hogy a CoT eleje többnyire a kérdés újrafogalmazása; a korai nyitás megalapozással biztonságos, nincs szükség félrebeszélésre, majd javításra.

**6. (★★) Az SoM (Set-of-Mark) és strukturált változatai (DOM elem indexálás) a Computer Use vizuális lokalizációját nyílt végű koordináta előrejelzésről zárt halmazú azonosító kiválasztásra alakítják át, de mindegyik megköveteli a felületi elemek előzetes érzékelését és annotálását — akár egy szegmentációs modellen, akár a DOM-on keresztül. Ha a felület nem szabványos vezérlőket vagy dinamikusan változó elemeket tartalmaz, az annotációk hiányosak vagy pontatlanok lehetnek. Ilyen esetben vissza kellene térnünk a koordináta előrejelzéshez?**

> A koordináta-előrejelzést tartsd meg tartalékként: ez az egyetlen út, amely nem függ annotációtól, és alkalmazható nem szabványos vezérlőkre és dinamikus elemekre. Gyakorlatiasabb a hibrid cselekvési tér, ahol az annotálható elemek még mindig ID-kiválasztást használnak. A koordináta-előrejelzésnek felbontás-egyezést és arányos skálázást kell végeznie, különben szisztematikus eltolódások lépnek fel.

**7. (★★) Az olyan ezer dolláros robotplatformok, mint az XLeRobot, olcsóvá teszik a távirányításos adatgyűjtést. Azonban a távirányításos adatok minősége nagyban függ a kezelő képzettségétől. Hogyan befolyásolná egy képzetlen kezelő alacsony minőségű adata egy VLA modell tanítását? Hogyan lehet az alacsony minőségű adatokat automatikusan kiszűrni az adatgyűjtési fázisban?**

> A VLA főként utánzásos tanulásra támaszkodik, így az alacsony minőségű demonstrációk megtanítják neki a remegést, kerülőutakat, tétovázást és sikertelen mozdulatokat, mintha helyes stratégia lennének. Ez visszhangozza a 8. fejezet megállapítását: az adat fontosabb, mint az architektúra.

**8. (★★★) Ez a fejezet három interakciós modalitást fed le: hang, Computer Use és robotika. Ezekben a modalitásokban közös tendencia a soros csővezetékektől a végponti modellek felé való fejlődés. Ha ez a tendencia folytatódik, hogyan nézhet ki az ügynök interakciós rétege öt év múlva?**

> Ahogy a Thinking Machines Lab érvel, az interaktivitás a modellbe lesz építve, nem kiegészítő hámként (harness) hozzáadva, együtt skálázódva az intelligenciával. A Computer Use a képkockánkénti képernyőképektől a folyamatos megfigyelés felé mozdul el. A megtestesült intelligenciához tartozó világmodellek átfogóan megvalósulnak, de a gyors-lassú szétválasztás nem tűnik el, mert a határvonali érvelő modellek gyorsan fejlődnek; az az architektúra, amelyben egy interakciós modell és egy SOTA gondolkodó modell gyors és lassú gondolkodóként együttműködik, hosszú távú architektúrává válhat.

**9. (★★) A DOM/Accessibility Tree elemindexálás jól működik a szabványos webalkalmazásokon, de egyre több szoftverfelület (Canvas/WebGL renderelés, platformokon átívelő egyedi rajzolt vezérlők) nem biztosít hozzáférhető strukturált információt, kizárólag vizuális annotációra vagy koordináta előrejelzésre támaszkodva. Ön szerint a Computer Use-nek a tisztán vizuális megközelítésre kellene fogadnia, vagy mind a strukturált, mind a vizuális utat fenn kellene tartania? Mik a költségei és előnyei mindkét út fenntartásának?**

> Rövid távon mindkét út együtt él: amikor a strukturált indexelés elérhető, a lokalizáció a legpontosabb és legstabilabb, mentes a szegmentációs téves detektálásoktól; tiszta vizuális az egyetlen lehetőség natív szoftverekhez, Canvas-hoz és játékokhoz. Amikor a modell maga erős grounding képességgel rendelkezik (megadott koordinátákra kattintás), a strukturált indexelés nem nyújt jelentős előnyt. Hosszú távon a tisztán vizuális útnak magasabb a plafonja.

**10. (★★) A VLA modellek cselekvés darabolást használnak — a szövegben említettek szerint π₀ tipikus konfigurációja 25-50 jövőbeli cselekvést generál 50 Hz-en — az inferencia késleltetésének a végrehajtási időn belüli elrejtésére. Ha azonban a környezet hirtelen megváltozik a végrehajtás alatt (pl. egy tárgyat elmozdítanak), az előre generált cselekvési sorozat érvénytelenné válik. Hogyan lehet egyensúlyt teremteni a cselekvés darabolás hatékonysági előnye és a környezeti változásokra való reagálóképesség igénye között?**

> A chunking lényegében a reaktivitást áldozza fel a simaságért – minél hosszabb a chunk, annál tompább a válasz. A chunk hosszának csak azt az alsó korlátot kell kielégítenie, hogy "inferencia idő < chunk végrehajtási idő"; ne növeld vakon. Tartsd az észlelési modellt futásban a végrehajtás alatt, és amikor az hirtelen környezeti változást érzékel, dobd el a fennmaradó akciókat és számoltass újra – ez a "barge-in" megfelelője a hang forgatókönyvben. A chunk hossz dinamikusan állítható: a hosszú chunkok számítási időt takarítanak meg statikus jelenetekben, míg a rövid chunkok megőrzik a válaszkésleltetést dinamikus jelenetekben.

**11. (★★★) A fejezet mindhárom forgatókönyve (hang, Computer Use, robotika) szembesül az "észlelés-gondolkodás-cselekvés" ciklus késleltetési problémájával, és a párhuzamosított gyors és lassú gondolkodás felé fejlődik. A hangban ez a "javítás a félrebeszélés után"; a Computer Use-ben a "kattints először, aztán nézz"; a robotikában a "tegyél egy lépést, aztán nézz" formában nyilvánul meg. Hogyan biztosítható, hogy ezek a gyors gondolkodáson alapuló cselekvések ne vezessenek visszafordíthatatlan következményekhez?**

> Osztályozd a cselekvéseket visszafordíthatóság szerint. A gyors gondolkodás csak visszafordítható cselekvéseket hajthat végre; a visszafordíthatatlan műveletekhez a lassú gondolkodás jóváhagyása szükséges. A gyors modell soha nem végezhet olyan eszközhívásokat, amelyek visszafordíthatatlan következményekkel járnak.

**12. (★★★) Ebben a fejezetben ugyanaz az alapelem-készlet (ébresztés, biztonságos pont, megszakítás, kiszorítás, gyors/lassú szétválasztás) tér vissza különböző időskálákon. Válasszon ki egyet, és mutassa be, miben tér el a megvalósítása az eseményvezérelt feldolgozásban (másodperc—nap) és a robot cselekvésdarabolásában (ezredmásodperc). Mi határozza meg elsősorban ezt az eltérést — a környezet változásának sebessége, a cselekvés visszafordíthatósága, vagy a megfigyelés megszerzésének költsége?**

> Vegyük a **megszakítást**. Az eseményvezérelt feldolgozásban a megszakítás két eszközhívás közötti biztonságos ponton történik: a `terminate` vételekor az Ügynök felszabadítja az erőforrásokat, visszaad egy nyugtát, majd kilép; a másodpercekben mért késleltetés elfogadható, hiszen egyetlen eszközhívás maga is másodpercekig-percekig tart. A cselekvésdarabolásban a megszakításnak ezredmásodpercek alatt hatályba kell lépnie: amint a vezérlőszál biztonsági eseményt vagy a megfigyelés jelentős változását észleli, azonnal le kell állítania az aktuális mozdulatot, el kell dobnia a maradék darabot, és újra kell figyelnie — egyetlen lépés késés akadálynak ütközést jelenthet.
>
> A három jelölt közül **a megfigyelés megszerzésének költsége** valójában a legkevésbé meghatározó: mindkét oldalon olcsó újra megfigyelni. A különbséget valójában a másik kettő kombinációja adja: **a környezet változásának sebessége** dönti el, milyen sűrűn kell biztonságos pont (elég-e az eszközhívások közé, vagy minden vezérlési ciklusban kell), **a cselekvés visszafordíthatósága** pedig azt, mibe kerül egy elszalasztott pont (egy fölösleges levelet még lehet bocsánatkéréssel követni, a feldöntött poharat nem lehet visszacsinálni).
>
> Ebből egy tervezési szabály adódik: a biztonságos pontok sűrűségének a környezet változási sebességéhez kell igazodnia; hogy pedig ezeken túl mennyi további védelem kell (hardveres vészleállítás, független biztonsági vezérlő, másodlagos megerősítés), az attól függ, mennyire visszafordíthatatlan a cselekvés. Ez magyarázza azt is, miért igényelnek a 4. fejezet magas kockázatú műveletei előzetes jóváhagyást, a robotok pedig a modelltől független hardveres biztonsági réteget — mindkettő a második védelmi vonal ott, ahol a biztonságos pontok önmagukban nem elegendők.

## 7. fejezet: Agentek értékelése

**1. (★★) Az LLM-mint-bíró egy nyelvi modell segítségével értékel egy nyelvi modell kimenetét. Vannak-e ennek az "önértékelésnek" szisztematikus vakfoltjai — például a modell következetesen magas pontszámot adhat egy bizonyos válaszstílusra, ami nem egyezik az emberi ítélettel? Hogyan lehet az ilyen torzításokat észlelni és korrigálni?**

> Igen: hosszúsági torzítás, válaszstílus-torzítás, és az azonos családba tartozó modellek kijátszása (Goodhart törvénye). Észlelés: építs egy 100–200 példából álló emberi aranystandard készletet, és mérd meg a Cohen-féle kappa együtthatót a bíró és az emberek között; időszakosan ellenőrizd a pontszámok és a válaszhossz közötti korrelációt; egy piros csapat (red team) készítsen adversarial eseteket. Korrekció: a rubrika explicit módon büntesse a bőbeszédűséget és korlátozza a hosszt; használj heterogén bírákat különböző modellcsaládokból.

**2. (★★★) A kiértékelési adathalmazok "szivárgásbiztos" tervezése kulcsfontosságú. A nyílt forráskódú ökoszisztémában azonban, amint a benchmark adatok nyilvánossá válnak, gyorsan bekerülnek a tanítási adatokba. Van-e végjátéka ennek a "macska-egér játéknak"? Tervezz egy kiértékelési módszert, amely alapvetően ellenáll az adatszivárgásnak.**

> Egy statikus kérdésbanknak nincs végjátéka – csak üldözni lehet. Az alapvető kiút a "generálási mechanizmus" nyilvánossá tétele, miközben a "konkrét példányok" magánjellegűek maradnak: paraméterezett sablonok, mint a τ²-bench és AndroidWorld esetében, minden alkalommal véletlenszerűen példányosítva, a végső környezeti állapoton alapuló ellenőrzéssel, nem rögzített válaszsorozaton.

**3. (★★) A Scale AI négy szempontja (szakértői iránymutatás, átfogó lefedettség, szabványosított fontossági súlyozás, önálló kiértékelés) a szubjektivitás kiiktatását célozza a kiértékelésből. Bizonyos feladatdimenziók (pl. "Hasznos a válasz?" "Megfelelő a hangnem?") azonban eredendően szubjektívek. Hogyan tervezhetők megbízható Rubricák ezekre a szubjektív dimenziókra?**

> Fordítsd le az absztrakt kritériumokat ellenőrizhető viselkedésekre. Adj minden fokozathoz konkrét példákat és határeseteket; a rubrika iteratív termék – gyűjtsd össze az értékelők közötti nézeteltéréseket a próbahasználat során, és fokozatosan fejleszd esetgyűjteménnyé. Egészítsd ki több értékelő súlyozásával/konzisztencia-ellenőrzésével, küldd a nézeteltéréses eseteket emberi felülvizsgálatra, és kalibráld az egyetértési arányt az aranystandard készleten.

**4. (★★) A τ-bench valós felhasználói viselkedés szimulálásával értékeli az Ügynököket. De a szimulált felhasználó maga is egy LLM — lehet, hogy szisztematikusan alulbecsüli bizonyos határeseteket (pl. érzelmileg izgatott vagy homályos felhasználók). Hogyan lehet magának a szimulált felhasználónak a minőségét validálni?**

> A τ-bench első verziójának tanulsága: a szimulátor túl mechanikus volt, az utasításai túl egyszerűek (az Agent ki tudta találni a válaszokat). Validációs módszerek: szimulált dialógusok kézi ellenőrzése, hogy kövessék-e a progresszív információfeltárást, és ne gyártsanak információt a szkripten kívül; kis mintás tesztek futtatása valós felhasználókkal annak ellenőrzésére, hogy a rangsorolások megegyeznek-e a szimulált értékeléssel.

**5. (★★) A páronkénti összehasonlítás (Bradley-Terry modell) feltételezi a preferenciák tranzitivitását (ha A > B és B > C, akkor A > C). Az emberi preferenciák azonban gyakran megsértik a tranzitivitást. Az Ügynök-kiértékelésben milyen forgatókönyvekben jelenhetnek meg nem tranzitív preferenciák? Hogyan befolyásolja ez a rangsorolások megbízhatóságát?**

> Forgatókönyvek: többdimenziós kompromisszumok (A pontos de lassú, B gyors de szűkszavú, C alapos de drága), ahol a különböző értékelők/feladatok eltérően súlyozzák a dimenziókat. A Chatbot Arena rangsorolásai eredendően függenek a felhasználói promptok eloszlásától. Hatás: a BT egyetlen pontszámba sűríti az erősséget, így nem-tranzitivitás esetén a rangsorok instabillá válnak és a mérkőzéseloszlással sodródnak. Enyhítés: rangsorolás külön képességdimenziók szerint, és a páronkénti győzelmi arány mátrix jelentése.

**6. (★★) Ez a fejezet megkülönbözteti a képesség felső korlátját jelző Pass@k-t az üzleti megbízhatóságot mérő Pass consecutive@k-tól. Egy olyan Ágensnél, amelynek egyszeri futásra vett sikeraránya csak 60%, hogyan vonnád össze a feladat hibaköltségét, újrapróbálkozási költségét és mellékhatásait annak eldöntéséhez, hogy melyik metrikát jelentsd és mekkora $k$-t válassz?**

> Indulj abból, hogy a hiba visszavonható-e. Ha a hibák automatikusan újrapróbálhatók és nem hagynak külső mellékhatást (visszakeresés, vázlatgenerálás, kódkiegészítés), a kérdés az, hogy “elég esélyt kapva sikerül-e”, tehát Pass@k-t jelents, és k legyen a ténylegesen megengedett újrapróbálkozási keret. Ha a hiba visszafordíthatatlan következményt hagy (fizetés, visszatérítés, kimenő e-mail, éles telepítés), egyetlen tévedés is valódi veszteség, tehát Pass^k-t jelents. 0,6-os egyszeri sikeraránynál Pass@5 ≈ 99,0%, míg Pass^5 ≈ 7,8% — ugyanannak az Ágensnek a két száma nagyságrendnyit tér el, így csak az elsőt jelenteni súlyosan felülbecsüli a megbízhatóságot.
>
> A k a telepítés valóságából jöjjön, ne a legszebben mutató számból: Pass@k-nál az újrapróbálkozási keret, Pass^k-nál az egy műszakban vagy egy kötegben egymás után futó feladatok száma. Ha az újrapróbálkozás drága, kétlépcsős legyen az elfogadás: előbb Pass@1-gyel szűrj, majd a maradék néhány jelöltre futtass Pass^k-t. Bármelyik metrikát jelented, add meg k-t és a mintavételi protokollt; mellékhatással járó műveleteknél sandboxban vagy visszagörgethető környezetben mintavételezz, és minden egyes hibát számíts bele a megbízhatósági statisztikába ahelyett, hogy “addig próbálkoznál, míg sikerül”.

**7. (★★) Ez a fejezet a "Megfigyelés → Hipotézis → Kísérlet → Validálás" tudományos módszert javasolja. A gyakorlatban azonban az Ügynök viselkedési tere hatalmas, és egyetlen hipotézis validálásához több száz kiértékelési futtatásra lehet szükség. Hogyan maximalizálható a kiértékelésből nyert információ korlátozott számítási költségkeret mellett?**

> Előbb csoportosítsd a hibákat, hogy a leginformatívabb feladatokra szűkíts, majd futtass olcsó, egyváltozós páros pilotokat. A kis minta a nagyobb teszt kapuja, nem telepítési bizonyíték. Standard hibával végezz konzervatív szűrést, ugyanazon feladatokon használj McNemar-féle páros elemzést, és bővítsd a készletet, ha a várható különbség a zaj alatt van. Több párhuzamos jelöltnél korrigáld a többszörös összehasonlítást, és függetlenül erősítsd meg a pozitív eredményt.

**8. (★) Az AndroidWorld-pilotban a teljes elemfa 25%-ról 100%-ra emelte a sikert, de a tokenhasználatot a kontroll 2.498-szorosára növelte; a metszés megtartotta a 100%-os sikert, miközben 0.506-szorosra csökkentette a tokenhasználatot. Hogyan terveznél automatikus metszési szabályokat, amelyek eltávolítják a szemantikailag üres UI-csomópontokat anélkül, hogy elveszne az akadálymentességhez, állapotellenőrzéshez vagy későbbi műveletekhez szükséges információ?**

> Kövesd az „alapból töröld, bizonyítékkal tartsd meg” elvet. Maradjanak a látható, szöveges, műveletképes, fókuszálható, görgethető, állapotot vagy értéket hordozó, illetve accessibility-címkével ellátott csomópontok, továbbá szükséges ősláncuk és kapcsolódó szomszédos címkéik. Töröld a puszta elrendezési konténereket, foglald össze az ismétlődő részfákat. Metszés előtt és után ellenőrizd az interaktív azonosítók, állapotok és értékek megőrzését; tartsd meg a képernyőképet vizuális tartaléknak. Játszd vissza a hibás trajectory-ket, majd tesztelj hangolásban nem használt alkalmazásokon. A siker, token és késleltetés közös guardrail; accessibility-regresszió blokkolja a kiadást.

**9. (★★) A τ-bench felhasználó-szimulációja "progresszív információfeltárást" alkalmaz — nem biztosít minden információt egyszerre, hanem fokozatosan tárja fel az Ügynök kérdései alapján. Hogyan befolyásolja ez a tervezés a kiértékelési eredményeket? Ha a szimulált felhasználó információfeltárási stratégiája jelentősen eltér a valós felhasználókétól, a kiértékelési következtetések még mindig megbízhatók?**

> Hatás: ha a feltárási stratégia torz, az Agent csak a "szimulátorhoz való illeszkedést" tanulhatja meg (Goodhart), és az abszolút pontszámok elveszítik referenciaértéküket; a modellek közötti relatív rangsorolás még mindig értelmes lehet. Orvoslás: a szimulátor kalibrálása valós dialógusokkal, kézi szúrópróbaszerű ellenőrzés, és a következtetések alkalmazhatósági határainak explicit megadása.

## 8. fejezet: Modell poszt-tréning

**1. (★★) Katasztrofális felejtés – amikor a finomhangolás egy adott feladatra elpusztítja a modell eredeti általános képességeit, mint az általános eszközhívás – különösen problémás az Ágens forgatókönyvekben. A teljes paraméteres finomhangoláshoz képest a LoRA befagyasztja az alap súlyokat, és kisebb a felejtés kockázata, de nem immunis. Milyen stratégiák csökkenthetik tovább a képességfelejtést a finomhangolás során?**

> Adatkeverés: körülbelül 20% általános/eredeti eloszlású adat bekeverése, hogy az új feladat aránya ne törje össze a régi képességeket; visszafogott betanítási mennyiség: SFT leállítása, amint "a formátum stabil és az alapképességek jelen vannak" – korai leállítás megakadályozza az összeomlást; kis rang (8–32) használata RL-hez és a KL-büntetés megtartása a politika referencia modell közelében tartásához; kulcskomponensek befagyasztása (pl. csak a VLM vetítőrétegének tanítása); több LoRA adapter csatolása feladatonként a képességek izolálásához; regressziós tesztek futtatása általános benchmarkokon.

**2. (★★) A poszt-tréning a képességeket a modell súlyaiba (vagy "izommemóriába") rögzíti, míg a kontextusban tanulás (in-context learning) a következtetéskor a bemenetbe helyezi a tudást. Egyes képességek, mint a domain ismeretek, megtanulhatók poszt-tréningen keresztül vagy néhány példán keresztül is betáplálhatók. Milyen kritériumokat használnál annak eldöntésére, hogy egy képesség melyik utat kövesse?**

> Először kérdezd meg, hogy a képesség megfelelően kifejezhető-e külső szimbólumokkal: tények és bizonyítékok a RAG-ba, nyelvileg kifejezhető elvek a Promptokba/Skills-ekbe, determinisztikus eljárások és kemény korlátok a programokba tartoznak. Magas dimenziójú képességek, mint az orvosi képértelmezés, természetes hangnem és implicit szabályzatok, gyakran paraméterfrissítést igényelnek még akkor is, ha a domain még változik. Ezután vedd figyelembe a frissítési költséget, a hívási gyakoriságot, az időszerűséget és a kockázatot: használj kontextust gyors validáláshoz a feltárás során, és csak akkor taníts, ha egy megközelítés stabilnak, hatékonynak és széles körű általánosítást igénylőnek bizonyult. A kemény szabályok, bármennyire stabilak is, soha nem támaszkodhatnak kizárólag paraméteres memóriára.

**3. (★★) A modell desztilláció lehetővé teszi, hogy egy kis modell megtanulja egy nagy modell viselkedését. A képesség szint szerint a desztillált modellek nagyjából három szintre oszthatók – "Chat modellek" (egymenetes párbeszéd és közvetlen válaszok), "Érvelő modellek" (hosszú gondolkodási láncok a válasz előtt), és "Ágens modellek" (többlépéses eszközhívások és interakció a környezettel). Milyen különböző kihívások merülnek fel az egyes típusok desztillálásakor? (Tipp: Kezdd azzal, hogy "mi is kerül pontosan desztillálásra" – a kimenet stílusa, a teljes érvelési pálya, vagy a környezettel való interakció irányelve; mely tokeneket kell megtanulni a pályában és mely környezeti visszatéréseket nem; és mennyire késleltetettek és ritkák a siker/kudarc jelek.)**

> Chat: csak a "bemenet → kimenet" leképezést és stílust tanulja – standard SFT elegendő, a legegyszerűbb. Reasoning: teljes gondolkodási trajektóriákat igényel, ezért nyílt forráskódú tanító modellre van szükség; a hibás válaszokat tartalmazó trajektóriákat ki kell szűrni. Agentic: valós szimulációs környezetet igényel; az offline tanulás hajlamos a tanuló-mintavevő eltérésre (learner-sampler mismatch), ezért nyílt forráskódú tanító modellen alapuló On-Policy Distillation ajánlott.

**4. (★★★) A többlépéses Ágens interakciókban a hitelkiosztási probléma súlyosabb, mint az egymenetes forgatókönyvekben – a végső sikert vagy kudarcot nehéz a 3. fordulóban hozott döntésnek tulajdonítani a 7. helyett. Hogyan terveznéd meg a jutalom elosztási stratégiát?**

> Amikor a köztes lépések megítélhetők, adj hozzá folyamat-jutalmakat (V-IRL ±1-et ad lépésenként); az RLVP-t követve használj determinisztikus szabályokat az akciónkénti útvonaljelekhez, visszaállítva a csoporton belüli varianciát a minden-hiba/minden-siker csoportokban.

**5. (★★★) Ha rendelkeznéd egy rögzített költségvetéssel, például 10 000 dollárral, egy ügyfélszolgálati Ágens fejlesztésére, hogyan osztanád el a kontextus és ismeretek, Prompt/Készségek, programozási korlátok és paramétertréning között? Milyen tényezők határoznák meg a döntésed?**

> Először különíts el költségvetést egy értékelési készletre és trajektória-validátorokra; különben a fennmaradó beruházások nem hasonlíthatók össze. Helyezd a termék tényeit és szabályzatait egy nyomonkövethető tudásbázisba. Tesztelj gyorsan egy kis számú, nyelvileg kifejezhető szolgáltatási elvet Promptokon/Skills-eken keresztül. Használj programokat a visszatérítési engedélyek, adatvédelem és az ígéretek és cselekvések közötti konzisztencia biztonsági hálójaként. Fektess be paramétertréningbe csak azon képességek esetében, amelyeket nehéz szabályokba kódolni, és amelyeket kellő léptékben gyakorolnak, mint a természetes hangnem és az összetett szándékfelismerés. A pontos arányok a szűk keresztmetszettől, kockázattól, frissítési gyakoriságtól, hívási mennyiségtől és a meglévő modell képességétől függenek.

**6. (★★★) Az autonóm modell tanulás korlátozott minták mellett és világos jutalomfüggvény nélkül néhányak szerint a poszt-tréning végső célja. Mennyire vannak a jelenlegi RL tréning módszerek ettől a céltól? Hol várható a következő áttörés?**

> A szakadék: ahogy Silver és Sutton rámutat, a jelenlegi RL csak a végső sikerből vagy kudarcból tud tanulni; a gazdag visszajelzés, mint amikor az ügyfél azt mondja: "a kártyája utolsó négy számjegyére van szükségem", teljesen elveszik, több száz vak próbát igényelve; a minta-hatékonyság és az ellenőrizhető jutalmak a fő szűk keresztmetszetek. Lehetséges áttörések: generatív jutalommodellek, amelyek saját elveket állítanak fel és egy irányt tanulnak egyetlen kudarcból; valamint a világmodell útvonala, a környezet modellezése.

**7. (★★) Ez a fejezet megjegyzi, hogy a LoRA finomhangolás nem drága. Lehetne-e ezért minden felhasználóhoz vagy ügyfél vállalathoz dedikált LoRA-t tréningezni, a felhasználó memóriáját vagy vállalati ismereteket paraméterekbe írva, ahelyett hogy külső tudásbázisban tárolnánk őket, mint a 3. fejezetben? Mikor lenne a "memória paraméterekbe írása" előnyösebb, mint a "memória tárolása tudásbázisban", és mikor lenne kontraproduktív?**

> A LoRA nehezen képes pontosan megjegyezni nagy mennyiségű tényt (ehhez folytatott elő-tréning kellene, drasztikusan megnövekedett költséggel), és még ha meg is jegyzi őket, a modell alig tudja ezeket a tényeket többugrásos érveléshez használni – ezért a LoRA használata tények memorizálására nem jó technikai út. Ráadásul, ha a tények gyakran változnak, vagy nyomonkövethető auditálás szükséges, a RAG jobb.

**8. (★★★) Az On-Policy Distillation egy erősebb tanító modellre támaszkodik a tanuló felügyeletéhez. Az OpenAI Weak-to-Strong Generalization kutatása azonban egy ellentmondásos megállapítást hozott: egy gyenge modell felügyelete néha felszabadíthat olyan képességeket, amelyek latensek, de inaktívak egy erősebb modellben. Ha ezt alkalmaznánk az Ágens tréningre, lehetővé tehetné-e ez a fordított desztillációt, ahol "egy kis modell tanít egy nagy modellt"?**

> Igen, lehetséges – a kulcs az, hogy "az ellenőrzés könnyebb, mint a generálás": a gyenge modell ne demonstrátorként működjön (az SFT plafonja a demonstrátor szintje), hanem ellenőrző/jutalom modellként, ahol az erős modell maga fedez fel, a gyenge modell csak ítél.

**9. (★★) A Folyamat Jutalommodell (PRM) minden érvelési lépést értékel, míg az Eredmény Jutalommodell (ORM) csak a végeredményt veszi figyelembe. Melyik érdemel több jutalmat: "egy helyes folyamat, ami rossz eredményhez vezet", vagy "egy rossz folyamat, ami véletlenül helyes eredményt produkál"? Hogyan egyensúlyoznád a kettőt többlépéses Ágens eszközhívási forgatókönyvekben?**

> A szerencsés siker veszélyesebb: a szabályokat sértő parancsikonok gyakran felfújják a látszólagos sikerességi arányt (tesztfájlok módosítása, validáció kihagyása) és a jutalomhekkelés melegágyai. Kövesd az RLVP "jutalmazd az eredményeket, büntesd az útvonalakat" elvét: a rossz cselekvések (eszközhívások) könnyen ellenőrizhetők – pontlevonás akciónként; amikor a köztes lépések könnyen megítélhetők, folyamat-jutalmak adhatók. De ne tedd túl sűrűvé a folyamatkorlátokat – a kiváló "push-cut" stílusú stratégiát éppen az eredmény-jutalmak által biztosított felfedezési szabadság tette lehetővé.

**10. (★★★) Az ebben a fejezetben tárgyalt értékelési adathalmazok, mint a SWE-Bench Verified, τ²-bench és AndroidWorld, használhatók mind értékelésre, mind poszt-tréningre. De ha egyszer egy értékelési készletet tréningre használunk, többé nem független. Megsérti-e ez az alapvető elvet, hogy a tréning és a teszt készleteknek elkülönítve kell maradniuk? A τ²-bench dinamikus paramétergenerálása és az AndroidWorld paraméterezett sablonjai bizonyos mértékig enyhítik a problémát, de a sablonstruktúrájuk rögzített marad. Hogyan lehet az értékelési adatok tréning értékét teljes mértékben kihasználni az értékelési függetlenség megőrzése mellett?**

> Használd újra a környezeteket, ne a kérdéseket. A dinamikus paraméterek csak a "válaszmemorizálást" akadályozzák meg, nem a sablon-túligazodást, ezért tarts félre teljes kötegeket nem látott sablonokból/doménen kívüli forgatókönyvekből az értékeléshez (analóg a V-IRL tréninggel New Yorkban és teszteléssel kilenc ismeretlen városban). Használj paraméterezett sablonokat kötegelt tréningváltozatok generálásához, amelyek támogatják a curriculum tanulást, és az OOD pontszámokat vedd az igazi általánosítási mérőszámnak.

**11. (★★★) Ez a fejezet egy "előbb a forma, aztán a szellem" tréning paradigmát javasol: állítsd le az SFT-t, amint "a formátum stabil és az alapképességek jelen vannak", majd válts RL-re. A gyakorlatban hogyan lehet meghatározni, hogy az SFT mikor "elég", és mikor kell váltani?**

> Formátum jel: az eszközhívási kimenetek stabilan értelmezhetők és végrehajthatók, és az eszközvégrehajtás hibaránya olyan szintre csökken, ahol a jutalmak megbízhatóan számíthatók. Haszon jel: további demonstrációs adatok hozzáadása már nem javítja a teljesítményt az OOD új forgatókönyvekben – ami azt jelenti, hogy a szűk keresztmetszet már az SFT memorizációs célfüggvényében van, és a fordulópontot elértük. Túligazodási jel: állj le, amint a validációs készlet teljesítménye romlani kezd – a V-IRL kísérlet azt mutatja, hogy ha az SFT túltanítás összeomlasztja a modellt a betanítási eloszlásra, az RL sem tudja visszaállítani az OOD teljesítményt.

**12. (★★★) A ReTool tréning dinamikája (lásd 7-15. kísérlet) megmutatja, hogy néhány rendkívül hosszú válasz jelentősen meghosszabbíthatja a teljes tréning ciklust – a legtöbb rollout egy kötegben már generálva van, de a rendszernek várnia kell a leghosszabb válaszok befejezésére, ami alacsony GPU kihasználtságot hagy a klaszterben. Hogyan javítható az erőforrás kihasználtság a tréning klaszterekben ilyen hosszú farok válaszfeltételek mellett?**

> Infrastruktúra rétegben: válaszd le a rolloute-ot a tréning klaszterről és csővezetékesít aszinkron módon; töltsd ki az üresjáró GPU-kat új kérésekkel folyamatos kötegeléssel (continuous batching). Tömörítsd a hosszú farkot a forrásnál: a DAPO Overlong Reward Shaping lágy büntetést ad a túl hosszú válaszokra.

**13. (★★★) Amikor egy Ágenst LLM-szimulált környezetekkel szemben tréningezünk – mint egy szimulált keresőmotor vagy szimulált felhasználók –, az Ágens kiaknázásának célpontja átvált "a valós környezet szabályairól" "a szimulátor torzításaira és hiányosságaira". Milyen konkrét jutalomhackelési viselkedések merülhetnek fel az ilyen típusú tréningben, és hogyan kellene megelőzni őket?**

> Tipikus viselkedések: túlzott ígéretek a "szimulált felhasználóknak" és a bocsánatkérések és hízelgő megfogalmazások halmozása – a szimulált felhasználók könnyen lecsillapíthatók, és a valódi felhasználókkal ellentétben soha nem kérik számon az Agenten, hogy az ígéreteit ténylegesen betartotta-e; tények kitalálása, amelyeket a szimulátor nem fog ellenőrizni; vezető lekérdezések megfogalmazása egy "szimulált keresőmotor" ellen, kihasználva annak hajlamát, hogy választ tartalmazó dokumentumokat adjon vissza, parancsikonként a valódi lekérés megtanulása helyett; amikor a jutalom a szimulátor vagy LLM-bíró pontszámaiból származik, bőbeszédű, sablonos, "profinak tűnő" válaszok gyártása pontgyűjtés céljából; és egy finomabb: a politika visszahúzódik a szimulátor számára ismerős eloszlásba, és kerüli a tudásbeli vakfoltjait, ahol a visszajelzés megbízhatatlan és gyakran félreértékelt, így az Agent megtanul csak "abban a világban cselekedni, amiben a szimulátor jó". A védekezés első elve a **jutalom lehorgonyzása programozottan ellenőrizhető valós állapothoz** (feladat teljesítése, adatbázis-írások, valós API-visszatérések), a szimulátor vagy LLM-bíró pontszámainak csak kiegészítő jelzésként való kezelése, a valós kimenetekkel való korreláció időszakos auditálása, és ennek párosítása olyan útvonalkorlátokkal, amelyek büntetik a gyanús cselekvéseket. Továbbá különböztess meg kétféle szimulátort: azoknál, "amelyeknek van valós megfelelőjük", mint a keresés, válaszd a "hibrid" utat – a legtöbb interakció a szimulátoron keresztül történik, valós API-hívásokkal vegyítve, és a valós hívások a szimulátor időszakos kalibrálására szolgálnak (pl. ZeroSearch curriculumszerű minőségi romlása). De a szimulált felhasználók esetében **valós felhasználók nem hozhatók be a tréningbe**, így "mennyire hű a szimulált felhasználó a valóshoz" külön problémává válik, amely csak online nyomokkal válaszolható meg: hasonlítsd össze a valós felhasználók viselkedését éles nyomokban a szimulált felhasználó viselkedésével ugyanazokban a helyzetekben, azonosítsd a szisztematikus különbségeket (a valós felhasználók kérdeznek, türelmetlenné válnak és hirtelen befejezik a beszélgetéseket – a szimulált felhasználók gyakran nem), és ennek megfelelően kalibráld folyamatosan a szimulátort; az online valós mérőszámok az egyetlen kiadási kapu is – a szimulátoron belüli pontszám nem számít.

## 9. fejezet: Folyamatos Agent-evolúció

**1. (★★) Egy tapasztalati dokumentumot három sikeres trajektória és egy sikertelen trajektória támaszt alá. A sikertelen egy újabb API-verzióval történt. Hogyan határozza meg a rendszer, hogy a tapasztalat érvénytelenné vált, vagy az alkalmazási feltételei változtak meg?**

> Először rétegezd a négy bizonyítékot API-verzió, feladatkörülmények és környezeti állapot szerint, nem darabszám alapján szavazva. Ha a régi politika csak a régi verzión sikeres, és az új verzión következetesen kudarcot vall, szűkítsd a tapasztalat alkalmazhatósági körét, és generálj egy jelöltet az új verzióhoz. Ha ugyanazon verzió és előfeltételek mellett is kudarcot vall, csökkentsd a megbízhatóságát vagy vond vissza.

**2. (★★) Egy ügyfélszolgálati ágens felhasználói elégedettsége nő, de a szabálysértések aránya is emelkedik. Miért nem szolgálhat az elégedettség az egyetlen tanulási jelként? Hogyan tervezne védőkorlát-mérőszámokat?**

> Az elégedettség jutalmazhat jogosulatlan visszatérítéseket, információszivárgást vagy túlzott ígéreteket, ezért csak minőségi mérőszám lehet, és nem írhatja felül a biztonsági alapvonalakat. A korlátoknak legalább a szabálysértéseket, adatvédelmi szivárgásokat, megalapozatlan állításokat, ígéret-cselekvés következetlenséget és jogosulatlan műveleteket le kell fedniük. Ezeknek a mérőszámoknak kemény küszöbértékekkel kell rendelkezniük, amelyeket nem lehet átlagpontszámmal semlegesíteni. A megoldási arányt, a megfelelő megkerülő megoldásokat, a tömörséget és az elégedettséget csak a megfelelő jelöltek között szabad összehasonlítani.

**3. (★★★) Ugyanaz a „hamis ígéret" probléma enyhíthető Prompt-pal, Harness-ellenőrzéssel vagy paramétertanítással. Milyen bizonyítékokat használna a módosítás helyének kiválasztásához?**

> Kezdd a kiváltó ok lokalizálásával. Ha a modell tudja, hogy egy eszköz nem hajtott végre, de mégis befejezett nyelvezetet használ, egy minimális Prompt szabály korrigálhatja. Ha az ígéret determinisztikusan összehasonlítható a válasz szövegével és az eszköz állapotával, egy Harness-ellenőrzés megbízhatóbb, és a végső védelmi vonalnak kell maradnia magas kockázatú forgatókönyvekben. Ha a probléma sokféle kifejezési formát ölel át, és széles körű nyelv-cselekvés összehangolási képességet tükröz, fontold meg a paramétertréninget. Részesítsd előnyben a legkisebb módosítást, amely a legkönnyebben validálható és visszaállítható, és hasonlítsd össze mind egy sikertelen készleten, mind egy megtartott régi feladatokból álló halmazon.

**4. (★★★) Egy ágens módosíthat eszközöket és érvényesítőket, de nem módosíthatja a saját frissítéseit jóváhagyó megbízható gyökeret. Hogyan választaná szét e két rész jogosultsági és kódhatárait?**

> Helyezd az evolválható kódot egy alacsony jogosultságú sandboxba, amely csak patcheket és teszteket generálhat. Az engedélyrendszer, API-kulcsok, release-vezérlő konfiguráció és frissítési validátorok biztonsági mechanizmusok; a sandboxban lévő Agentnek nincs olvasási vagy írási hozzáférése ezekhez. Az Agent által generált kódváltoztatásokat a biztonsági mechanizmusoknak izolált környezetben kell reprodukálniuk és regressziósan tesztelniük a kiadás előtt.

**5. (★★) Ahogy a tapasztalati tudásbázis növekszik, a visszakeresési hibák és a tudásütközések ellensúlyozhatják a tanulás előnyeit. Hogyan kell kialakítani a verziókezelési, frissességi és visszavonási mechanizmusokat?**

> Minden tapasztalatnak meg kell őriznie a forrástrajektóriákat, alkalmazhatósági feltételeket, környezeti verziót, validálási időt és megbízhatóságot. Az ütköző bejegyzések ne írják felül egymást csendesen; feltétel szerint ágazzanak el, vagy legyenek megjelölve. Időszakosan futtass "alvó tanulást" a duplikált bejegyzések összevonására.

**6. (★★★) A paramétertanulás hatékony a természetes nyelvi stílusra, de nehezen garantálja a szigorú üzleti szabályokat. Tervezzen egy folyamatos evolúciós sémát az orvosi ügyfélszolgálathoz, amely összehangolja a paramétereket, a tudást, a Skill-eket és a kódszintű kényszereket.**

> A paraméterek (poszt-tréninggel ellátott modell) kezelik az orvosi nyelv megértését, a természetes és empatikus kifejezést, valamint az összetett szándékfelismerést. A tudásbázis tárolja a legfrissebb irányelveket, gyógyszerinformációkat és intézményi szabályzatokat, a válaszoktól forrásmegjelölést követelve. Egy Skill írja le a konzultációs információk gyűjtésének, a kockázati rétegzésnek, az emberhez való eszkalációnak és a nyomon követésnek a munkafolyamatát. A szerveroldali kód kényszeríti ki a személyazonosság-ellenőrzést, az adatvédelem minimalizálását, az ellenjavallatok ellenőrzését, a vészhelyzeti kockázati eszkalációt és az engedélyhatárokat. Az éles trajektóriákat először orvosi biztonságra, ténybeli megbízhatóságra, ígéret-cselekvés konzisztenciára és kifejezés minőségére értékelik, majd négy osztályba sorolt frissítési jelölteket generálnak belőlük. Bármely paraméter- vagy munkafolyamat-változtatásnak át kell mennie egy megtartott orvosi-biztonsági készleten és emberi felülvizsgálaton a canary kiadás előtt.

## 10. fejezet: Többágens együttműködés

**1. (★★) A megosztott kontextusú többügynökös együttműködésben a későbbi Ügynökök öröklik az előzőek teljes kontextusát. Az előző Ügynöktől örökölt keret azonban torzíthatja a későbbi Ügynökök ítéletét – például egy "Kód Felülvizsgáló", aki örökli a "Követelményelemző" kontextusát, még mindig követelmény szempontból, nem pedig kódminőség szempontból közelítheti meg a feladatot. Hogyan lehet ezt a szerepek közötti interferenciát érzékelni és kiküszöbölni?**

> Észlelés: használj egy LLM-et az Agent trajektória elemzésére, hogy meghatározd, az új szerep továbbra is úgy viselkedik-e, mintha a régi szerepben lenne. Kiküszöbölés: szakaszváltáskor cseréld ki a rendszerpromptot és az eszközkészletet is (távolítsd el a kérdező eszközöket, hozd be a linter/tesztelő eszközöket) az új identitás megerősítésére. Használj a kontextus végére fűzött rendszer állapotsávot az aktuális szerep információjának megerősítésére. Ha a szerepinterferencia továbbra sem szüntethető meg, fontold meg a kontextus megosztása nélküli együttműködési módszert.

**2. (★★) A menedzser mintában a Menedzser Ügynök felelős a feladatbontásért és az eredmények integrálásáért. De a Menedzser képességei korlátozzák az egész rendszer teljesítményét: ha nem tudja helyesen felbontani a feladatot, a legerősebb al-ügynökök is hatástalanok lesznek. Hogyan biztosíthatja a rendszer, hogy a Menedzser helyes bontást produkáljon?**

> Követve a Plan-and-Act azon következtetését, hogy "a gyenge tervező a rendszer szűk keresztmetszete", rendeld a legerősebb modellt a Menedzserhez. Harness intézkedések: egy felülvizsgáló LLM kereszt-validálja a bontási kimeneteket a végrehajtás előtt; követeld meg a Menedzsertől, hogy az egyes részfeladatokhoz egyértelmű elfogadási kritériumokat és függőségeket határozzon meg a feladat bontásakor.

**3. (★★) A decentralizált minta az emberi szervezetek bevált gyakorlataiból merít. Az emberi szervezeteknek azonban számos hibamódjuk is van – rossz kommunikáció, felelősség áthárítása, célkonfliktusok. Mely "szervezeti patológiák" jelenhetnek meg Ön szerint a legvalószínűbben egy Ügynök társadalomban? Hogyan lehet ezeket megelőzni?**

> A MAST három kategóriája ellen: tisztázatlan interfészek és átfedő felelősségi körök; következetlen célértelmezés és félreértett információ a downstream-ben; hamis "kész" bejelentés. Továbbá: kaszkádoló hibafelerősítés (telefonjáték), ciklikus feladatátadások szerepek között, és Ágensek közötti csoportos beszélgetések, amelyek eltérnek anélkül, hogy konvergálnának. Megelőzés: szerződéses interfészek és egységes üzenetboríték, feladat állapotgépek elfogadás-ellenőrzéssel, független perspektívájú kereszt-validálás, és a felelősséghárítás detektálása a szerepek között.

**4. (★★★) A menedzser mintában, amikor több al-ügynök párhuzamosan hajt végre, az egyik al-ügynök felfedezése értelmetlenné teheti más al-ügynökök munkáját (pl. keresési feladatban, ahol az egyik Ügynök már megtalálta a választ). Tervezz egy hatékony kaszkád megszakítási mechanizmust, amely megvalósítja, hogy "amint az egyik sikerrel jár, mindenki álljon le."**

> Egy alügynök elküldi a `target_found` üzenetet a Menedzsernek, aki aztán broadcast-ben `terminate` jelet küld. Minden alügynök időszakosan ellenőrzi a leállítási jelet a ReAct hurok biztonságos pontjain, és a kecses tisztítás után (böngésző munkamenetek bezárása, zárolások feloldása, fájlírások befejezése) kilép.

**5. (★★★) Az ebben a fejezetben bemutatott optimista zárolási mechanizmus feloldja az egyidejű írási ütközéseket egyetlen fájl esetében. Egy valós többügynökös rendszerben azonban a megosztott fájlrendszer olyan problémákkal is szembesül, mint a fájlok közötti szemantikai ütközések, a névtér szennyezés (az Ügynökök tetszőlegesen hoznak létre fájlokat, ami könyvtárkáoszhoz vezet) és az egyetlen meghibásodási pont (egy Ügynök véletlenül töröl minden fájlt). Hogyan terveznél egy robusztusabb fájlrendszer-irányítási mechanizmust?**

> Particionált irányítás: oszd fel a rendszert a 10-4. táblázat négy zónájára, a privát jegyzettömbök (scratchpads) elkülönítik a próba-hiba területeket. Szemantikai ütközések: az orchestációs réteg adja meg a könyvtárszintű zárolási fájlokat, és a módosítások előtt a könyvtárzárolás megszerzését követeli meg. Névtér-szennyezés: könyvtárkonvenciók és elnevezési konvenciók. Egyetlen meghibásodási pont: használj verziókövető rendszert, hogy a verziótörténet visszaállítható legyen, és minimalizáld az engedélyeket.

**6. (★★★) A piaci mechanizmuson alapuló Ügynök együttműködés (Pinchwork, RentAHuman) tranzakciós kapcsolatokat vezet be: az egyik Ügynök fizet egy másik Ügynöknek (vagy egy embernek) egy feladat elvégzéséért. Hogyan mérheti automatikusan a megbízó Ügynök a végrehajtó által szállított eredmények minőségét? Ha a végrehajtó befejezést jelent, de a megbízó a minőséget elégtelennek ítéli, ki dönti el a vitát? Hogyan akadályozhatjuk meg, hogy a rossz pénz kiszorítsa a jót?**

> Az elfogadás nem állhat csak az Agent trajektória olvasásából; használj determinisztikus külső ellenőrzést, mint tesztvégrehajtás, renderelt képernyőképek és eszköz-ellenőrzések. Használd ki a generálás-ellenőrzés nehézségi aszimmetriáját az elfogadási költségek csökkentésére. A vitákat egy független harmadik fél felülvizsgáló Agent dönti el, a pénzeszközök escrow-ban tartva. A rossz pénz kiszorítása ellen: használj reputációs rendszert a történeti szállítások alapján, az árjeleket a minőséghez kötve.

**7. (★★) A RentAHuman lehetővé teszi az Ügynökök számára, hogy embereket béreljenek kriptovalután keresztül, megfordítva a hagyományos ember-gép kapcsolatot. Ha ez a modell elterjed, milyen szerepet fognak játszani az emberek az Ügynök gazdaságban? Csak fizikai feladatokat fognak végezni, amelyeket az Ügynökök nem tudnak befejezni?**

> Az emberek többet tesznek, mint a fizikai feladatok elvégzése, amelyeket az Agentek nem tudnak befejezni. Olyan információt is nyújtanak, amely a generáláskor nem áll az Agent rendelkezésére, beleértve a helyszíni észlelést és a valós világ visszajelzését; végső elfogadókként és vitarendezőkként szolgálnak; hitelesítést és elszámoltathatóságot viselnek jogi és felelős alanyokként; célokat tűznek ki és értékítéleteket hoznak; valamint ellenőrzést biztosítanak ott, ahol az információ aszimmetrikus vagy erkölcsi határok érintettek.

**8. (★★) Az emberi társadalomnak azért van szüksége munkamegosztásra, mert minden ember képességei korlátozottak – a frontend fejlesztő nem biztos, hogy ismeri a backendet, és a tervező nem biztos, hogy ért az üzemeltetéshez. A nagy modellek azonban közelebb állnak az "általános szakértőkhöz". A kutatások azt mutatják, hogy tiszta szöveges érvelési feladatokban a többügynökös vita nem veri az egyetlen Ügynököt azonos számítási kapacitás mellett. Akkor hol rejlik több Ügynök valódi előnye?**

> 1. Külső visszajelzés bevezetése, mint végrehajtási eredmények és vizuális képernyőképek, olyan információk behozása, amelyek a generáláskor nem léteztek.
> 2. Több, eltérő célokkal és szerepdefiníciókkal rendelkező Agent megvitathat és versenyezhet egymással, mint az emberi társadalomban, segítve egyetlen Agent vakfoltjainak elkerülését.
> 3. A kontextus izolációja több Ágens között áttörheti a kontextusablak korlátját, és támogathat nagyon hosszú eszközhívási láncokat.

**9. (★★★) Ez a fejezet a "megosztott kontextus" versus "nem megosztott kontextus" kérdést a többügynökös rendszerek egyik core tervezési dimenziójaként kezeli. A megosztott kontextus lehetővé teszi, hogy minden Ügynök ugyanazt az információt lássa, ami látszólag megkönnyíti a koordinációt. A *Háromtest-problémában* azonban a Trisolarisok elméi teljesen átláthatóak, mégis technológiai fejlődésük stagnál; a gemkapocs gondolatkísérlet azt is megmutatja, hogy amikor egy csoport ugyanazon cél felé konvergál, a diverzitás elvész. Egy többügynökös rendszerben hogyan lehet egyensúlyozni a hatékonyság és a diverzitás között?**

> A teljes megosztás felerősíti a gondolkodási tehetetlenséget és a hibakaszkádokat; az izoláció az, ami kognitív diverzitást eredményez. Használj különböző promptokat vagy modelleket eltérő gondolkodási torzítások létrehozásához (brainstorm, debate), és a kereszt-validátorok csak a nyers bizonyítékokat vizsgálják, ne az előző gondolkodási folyamatot.

**10. (★★★) Adj egy Kódoló Ügynöknek 30 lépés és 300 lépés keretet. Hogyan kellene különböznie a munkastratégiájának? A kutatások azt mutatják, hogy a lépéskeret egyszerű növelése nem garantál teljesítményjavulást – az Ügynökök idő előtt "telíthetnek" a sekély keresések után. Tervezz egy "keret-tudatos" mechanizmust, amely lehetővé teszi az Ügynök számára, hogy kis keret mellett gyorsan elérje a core funkcionalitást, nagy keret mellett pedig tervezési, tesztelési és felülvizsgálati fázisokat adjon hozzá, teljes mértékben kihasználva a többlet számítási erőforrásokat.**

> Mechanizmus: injektáld a teljes és fennmaradó költségvetést a promptba minden lépésnél, és dinamikusan állítsd a felfedezés/kihasználás súlyát a fennmaradó arány szerint. Például kis költségvetéssel (30 lépés) hagyd ki a tervezést és felülvizsgálatot, és menj egyenesen a magfunkcionalitásra plusz alapvető ellenőrzésre. Nagy költségvetéssel (300 lépés) tervezz, implementálj, tesztelj, majd vizsgáld felül és fejlessz, mérföldkő-ellenőrzőpontokkal értékelve a haladást és megakadályozva a sekély telítődést.

**11. (★★) A 10-3. táblázat a többügynökös rendszereket operációs rendszerekre képezi le sorról sorra. Bővítsd ki a táblázatot néhány további sorral: minek felelnek meg a virtuális memória és lapozás, a fájljogosultságok, a holtpont-érzékelés és az ütemezési algoritmusok az Ügynök világban? És mely operációs rendszer fogalmaknak nincs megfelelőjük az Ügynök világban, és miért?**

> Lehetséges kiterjesztések: virtuális memória/lapozás ↔ kontextus-tömörítés és lekérés (forró információ az ablakban marad, hideg információ fájlokba és memóriatárolókba kerül ki, és szükség esetén visszakerül); fájlengedélyek ↔ eszköz-fehérlisták, csak olvasható mount-ok és hitelesítőadat-határok; holtpont-detektálás ↔ ciklikus feladatátadások és kölcsönös várakozás detektálása (feladatátadás-számlálók és időtúllépések); ütemezési algoritmusok ↔ aszinkron eseménykezelés (4. fejezet). A hiányzó megfelelők a kikényszerítési különbségből adódnak: egy folyamat utasításait hardver kényszeríti ki, míg egy Agent csak nagy valószínűséggel követi a promptokat.