Kihagyás

Loop Engineering Clearly Explained. Akshay (2026-06-30)

Cikk: Loop Engineering Clearly Explained • Szerző: Akshay (Agent Cookbook) • Forrás: https://agent-cookbook.com/tutorial/loop-engineering-clearly-explained • Publikálva: 2026-06-30 • Platform: Agent Cookbook (Beginner szint) • Hossz: 1327 szó Sorozat: Ez a cikk a „Previous” linkje a 14-step roadmap-nak (Lev Deviatkin, 2026-07-06). A „Next” cikk: „A harness for every task: dynamic workflows in Claude Code.” Forrásanyagok: Boris Cherny (Claude Code alkotója), Andrej Karpathy, LangChain (Agent = Model + Harness), Anthropic

A lényeg

Az Agent Cookbook 2026-06-30-i cikke (Akshay) a loop engineering „miért nehéz” oldalát mutatja be — a 14-step roadmap (Lev Deviatkin, 2026-07-06) előzményeként. A kiindulópont: Boris Cherny, a Claude Code alkotója szerint „I don't prompt Claude anymore. I have loops that are running. My job is to write loops.” A cikk központi tézise: a loop maga triviális (minden agent framework ugyanarra a hat sorra landol: while True: response = model(context); if response.has_tool_calls(): ...; else: break). A nehézség nem a loopban van, hanem abban, amit köré építesz. A cikk négy „hard part”-ban szervezi a kihívásokat: (1) knowing when to stop, (2) keeping the context clean, (3) tools the agent can actually use, (4) something that can say no. A kurrens mérési eredmény: a harness többet számít, mint a model — csapatok modell-fixen tartásával, csak a körülötte lévő kódot cserélve a benchmark közepéről a top 5-be ugrottak.

1. A loop maga triviális, hat sor

Egy agent a magjánál nem egy varázsdoboz, hanem egy egyszerű loop:

while True:
    response = model(context)
    if response.has_tool_calls():
        results = run_tools(response.tool_calls)
        context += results
    else:
        break

A modell olvassa a contextet, kéri egy tool hívását, te futtatod a tool-t és az eredményt visszafordítod a contextbe. A modell újraolvassa, és ez ismétlődik, amíg a modell be nem fejezi a tool-hívásokat.

A meglepő rész: ez a loop már meg van oldva. Minden komoly agent framework nagyjából erre a hat sorra landol. Senki nem a while statement-en versenyez. Ha a loop triviális, min dolgozik mindenki?

2. A munka a modell mellé költözött, az engineering rétegek

A center of gravity az AI-ban folyamatosan a modell mellé sodródik. Négy egymásra épülő réteg:

  1. Prompt engineering. A szavak, amiket küldesz.
  2. Context engineering. Minden, amit a modell lát, nem csak az utasításaid.
  3. Harness engineering. A modell körüli kód, ami tool-okat futtat, state-et kezel, hibákat dolgoz fel.
  4. Loop engineering. Az autonóm ciklus, ami az egészet a cél felé hajtja.

Minden réteg az előzőre épül. Nem szűnt meg a promptolás, csak rájöttél, hogy a prompt a rendszer egy kis része. A LangChain megfogalmazása tiszta: Agent = Model + Harness. Ha nem te vagy a modell, te vagy a harness.

A legfontosabb finding, aminek átrendezi a prioritásaidat: a harness most többet számít, mint a model. Csapatok a modellt fixen tartva, csak a körülötte lévő kódot cserélve a benchmark közepéről a top 5-be ugrottak. Ugyanaz az agy, más loop. Loop engineering = a fegyelem, hogy mindent megépítesz, amiben az agy fut.

3. Hard part 1: knowing when to stop

Ezt a problémát senki nem warning-olja. Amikor az agent befejezi a tool-hívásokat, befejezte a turn-jét. Ez nem ugyanaz, mint a feladat befejezése.

Képzelj el egy coding agent-et. Ír egy kis kódot, körbenéz, látja, hogy volt haladás, és kijelenti, hogy kész. A tesztek még mindig elbuknak. A győzelmet önmagának deklarálta. A terminálüzenet a turn-t zárja, nem a feladatot. Ez a két dolog összekeverése a loopok elromlásának leggyakoribb oka.

Jó loopok a jó okoknál állnak meg, ezért több féket rétegsz egymásra:

  • Max iterations, hard cap, hogy egy beragadt agent ne fusson a végtelenségig.
  • Budget és time limit, plafond a tokenekre, pénzre és másodpercekre.
  • No-progress detection, ha ugyanazt a hívást ugyanazokkal az argumentumokkal ismétli, spinning-ol.
  • Real completion check, automatizált condition, ami bizonyítja, hogy a munka kész.

Az utolsó hordozza a terhet. A „done” jelentése: a tesztek átmennek, nem az agent jó érzése a saját munkájáról.

4. Hard part 2: keeping the context clean

A hosszú loopok belülről rothadnak. Minél több turn-t vesz egy agent, annál több szemét halmozódik a contextjében, régi tool outputok, zsákutcák, lejárt reasoning. A modell teljesítménye esik, ahogy a halom nő. Az ipar „context rot”-nak hívja.

A loop ezt spirálissá teszi. A rothadt context rosszabb döntést produkál, ami újabb zajt ad hozzá, ami a contextet tovább rothasztja. Ezt „doom loop”-nak hívják — és érezted már. Az agent butul, minél tovább fut.

A harcot úgy vívod, hogy a contextet költségvetésnek kezeled, nem vödörnek:

  • Compaction, összegzi a beszélgetést, amikor hosszú lesz, aztán a summaryról folytatja.
  • Offloading, a nagy output-ot fájlba pusholja, és csak a szeletét tartja meg, amire szüksége van.
  • Sub-agents, egy rendetlen részfeladatot átad egy külön agentnek, és csak a tiszta eredményt hagyja visszatérni.

Az instinct az, hogy mindent megtartsz „hátha kell”. A skill az, hogy tudd, mit dobsz el.

5. Hard part 3: tools the agent can use

A loop csak annyira jó, mint a tool-ok, amik benne vannak. Halmozz fel száz tool-t, és az agent elveszti a fonalat, melyikhez nyúljon. Egy szűk, fókuszált, nem-átfedő tool-set nyer. Az Anthropic szabálya éles: ha egy emberi mérnök nem tudja biztosan megmondani, melyik tool passzol, az agent-nek esélye sincs.

Két dolog számít többet, mint az emberek gondolnák:

  • A write-okat safe-to-repeat-té tenni. A loopok retry-znak, és ha egy újrapróbált „create customer” hívás egy második customer-t hoz létre, duplicate rekordokra és dupla számlázásra ébredsz. Bármi, ami state-et változtat, safe-to-call-twice kell legyen.
  • Az error message-eket az agent-nek írni, nem az embernek. A jó error megmondja az agentnek, mit tegyen legközelebb. Mielőtt egy tool kimegy, kérdezd meg: ha egy LLM olvassa az error-t, tudná-e a következő lépést?

Egy loop-ban az error nem zsákutca. A következő utasítás.

6. Hard part 4: something that can say no

Az autonóm loopoknak van egy csendes failure mode-ja. Az agent egyedül hagyva hajlamos egyetérteni önmagával. A vita legélesebb kommentje megragadta: a loop megtervezése a munka fele, a másik fele, hogy tegyél valamit a loopba, ami tud nemet mondani, mint egy teszt, type check, vagy valódi error.

Egy kritikus nélküli loop csak egy agent, aki bólogat a saját munkájára. A javítás: szétválasztani a maker-t a checker-től. Egy modell csinálja a munkát. Egy másik check (gyakran külön modell vagy hard teszt) osztályozza. A worker nem javítja a saját házi feladatát.

7. A tényleges shift

Most Cherny idézete érthető. A prompting = te kormányozod az agent-et lépésről lépésre. A loop engineering = te megépíted a rendszert, ami kormányozza, aztán hátralépsz.

A munkád megváltozik: ahelyett, hogy utasításokat adsz, három dolgot tervezel:

  1. A goal, siker-kritériumok formájában, amiket az agent maga ellenőrizhet.
  2. A loop, sane brakes-ekkel, hogy jól álljon meg.
  3. A verifier, hogy a „done” bizonyított legyen, ne állított.

Andrej Karpathy megfogalmazza a mindsetet: „Don't tell the model what to do, give it success criteria and watch it go.” Éjjel futó research loopokat üzemeltet, amelyek tweak-elnek egy scriptet, tesztelik, megtartják ami működik, eldobják ami nem — ő maga nincs a loopban. Egyszer elrendezi, és megnyomja a go-t.

Ez az egész move. Ahelyett, hogy a kéz vagy, a gépet tervező ember leszel.

8. Hol kezdj

Nem kell első nap egy overnight autonóm agent. Építsd fel odáig:

  1. Kezdd az alap looppal, és adj hozzá azonnal max iteration cap-et, timeout-ot és cost ceiling-et.
  2. Definiáld a „done”-t automatizált check-ként, mielőtt elkezded, ne vibe-ként utána.
  3. Védd a contextet. Compact-old a hosszú futásokat, offload-old a nagy outputokat, izoláld a rendetlen részfeladatokat.
  4. Auditáld a tool-jaidat. Tartsd őket kevesen és fókuszáltan, safe-to-repeat write-okat, és írj újra error-okat, amikre az agent tud cselekedni.
  5. Tegyél egy kritikust a loopba. Csak akkor menj teljesen hands-off-ba, ha megbízol abban, ami nemet tud mondani.

9. A cikk Henky-szempontú jelentősége

Ez a cikk a frontier AI engineering kategóriájában az egyik legrövidebb, legsűrűbb 2026-os bevezető. Az Akshay-féle „Clearly Explained” a 14-step roadmap (Lev Deviatkin, 2026-07-06) előzménye, és a két cikk együtt ad teljes képet: az előbbi a „miért fáj” négy hard part-ját adja, az utóbbi a „hogyan építsd meg” 14 lépését.

Az ai-automation topic szempontjából hat szál a fontos:

  1. A „loop maga triviális” insight. Minden serious agent framework ugyanarra a hat sorra landol. A munka a modell mellé költözött — harness engineering + loop engineering. Ez a „Harness > Model” finding a podcast-processing pipeline-ra is érvényes: a sub-agent-ek, az auto-review, a golden dataset, a state file-k mind a harness részei, és ezek együttesen adják a rendszer értékét, nem a modell önmagában.

  2. Knowing when to stop, a terminálüzenet vs. feladat megkülönböztetése. Ez a Ralph Wiggum loop (Geoffrey Huntley) és a Deviatkin-cikk 12. lépésének alapja. A podcast-processing sub-agent-ek esetén ez a /goal Claude Code primitív megfelelője.

  3. Context rot és doom loop, a context budget, nem bucket. A compaction + offloading + sub-agents triád a Henky-ágens memory-relevance-filter és recite-before-answer mintáinak felel meg. A Deviatkin-cikk 7. lépésének (skills) és az Akshay-cikk 4. hard part-jának összekapcsolása: a skill = offloading, a recite-before-answer = compaction.

  4. Safe-to-repeat writes. A tool-ok tervezésénél a Henky-loop-okban is érvényes: a transcript sync, a wiki raw copy, a topic file patch mind idempotens kell legyen. A 30 napos re-audit ciklus a permission scope creep ellen.

  5. Error messages for the agent, not the human. A Henky-loop-okban a sub-agent prompt-ok és a failure_modes feedback közvetlenül ezt a mintát alkalmazzák: a sub-agent-ek LÁTJÁK a közelmúltbeli hibákat (lásd a failure_modes feedback pipeline-t a references/auto_review.py render_subagent_prompt.py --with-failures).

  6. Andrej Karpathy „success criteria” elmélete. A Verifier = a loop szíve. A podcast-processing pipeline-ban ez az auto_review.py golden dataset alapú pontozás. A Deviatkin-cikk 11. lépése (minimum viable loop: one automation + one skill + one state file + one gate) és az Akshay-cikk „The verifier, so done is proven, not claimed” összhangban vannak.

A cikk értéke: egy 1327 szavas, 4 hard part-os, Karpathy-idézettel és Cherny-idézettel keretezett sűrű tutorial, amely a loop engineering „miért nehéz” oldalát adja, és kiegészíti a 14-step „hogyan építsd meg” roadmapet. A két cikk együttesen a 2026 nyár loop engineering kézikönyvének tekinthető.

Forrás

  • Eredeti cikk: https://agent-cookbook.com/tutorial/loop-engineering-clearly-explained
  • Szerző: Akshay (Agent Cookbook)
  • Publikálva: 2026-06-30 • Platform: Agent Cookbook (Beginner szint)
  • Sorozat: Previous = (nincs), Next = Loop engineering: the 14-step roadmap from prompter to loop designer (Lev Deviatkin, 2026-07-06). Következő utána: A harness for every task: dynamic workflows in Claude Code
  • Forrásanyagok: Boris Cherny (Claude Code alkotója, „I don't prompt Claude anymore”), Andrej Karpathy („Don't tell the model what to do, give it success criteria”), LangChain (Agent = Model + Harness), Anthropic
  • Cikk kulcsszavak: loop engineering, harness engineering, Boris Cherny, Andrej Karpathy, knowing when to stop, context rot, doom loop, compaction, offloading, sub-agents, safe-to-repeat writes, error messages for the agent, maker vs. checker, real completion check, success criteria, verified not claimed
  • Feldolgozás: Henky-pipeline (article_from_blog, 2026-08-13, fő agent self-write, 1327 szó < 5000 küszöb)
Vissza a tetejére