Kihagyás

Graph Engineering vs Loop Engineering — mi változott valójában és mi csak átnevezés

Szerző: Shirley (AI Builder Club)
Dátum: 2026. július 20.
Forrás: aibuilderclub.com/blog/graph-engineering-vs-loop-engineering (10 perc olvasás)
Típus: public-affairs tech-elemzés (single-page blog poszt, AI Builder Club "Build AI Agents" kurzus 4.16-os lecke)

A szerző központi tézise

A 2026. július 18-án elindult "graph engineering" vita ("Loop engineering halott, éljen a graph engineering!") túlreagálás mindkét oldalon. A graph engineering valódi paradigmaváltás három konkrét új képességgel — de a gyakorlat (topológia, párhuzamosság, explicit vezérlési folyamat) nem új: a LangGraph, Microsoft AutoGen és Google ADK évekkel a buzzword előtt szállítják. A lényeg: a loop a graph speciális esete (egy node önmagába visszacsatlakozó éllel), és minden graph-node továbbra is loop. Nem dobjuk el a loopokat, hanem komponálunk belőlük graphot, amikor egy loop már nem elég.

A cikk struktúrája

1. A két fogalom tiszta szétválasztása

A cikk egy összehasonlító táblázattal nyit, ami a két megközelítést dimenziók mentén választja szét:

Dimenzió Loop engineering Graph engineering
Egység Egyetlen ügynök ciklusa Több node + él + megosztott állapot
Alak Ciklus: discover → plan → execute → verify → ismétlés Irányított graph: node-ok vezérlési élekkel összekötve
Node-ok Nincs (maga a loop) Specializált ügynökök vagy lépések (researcher, writer, reviewer)
Élek Az egyetlen "repeat" nyíl vissza az elejére Vezérlési folyamat node-ok között: elágazások, fan-out/fan-in, loopok
Állapot Az ügynök kontextusában Az élek mentén áramlik, node-ok között megosztva
Amit tervezel A ciklus és a stop condition A topológia és a routing
Mikor csődöl el A verifier gyenge A topológia rossz, vagy az állapot szivárog a node-ok között

A kulcsmondat @rohit4verse metaforája: "az ügynökök a while-loopokból org chartokká érettek" — specializált node-ok párhuzamosan futnak, az állapot közöttük áramlik. A loop a while-loop, a graph az org chart.

2. Az öt AI engineering réteg kontextusba helyezése

@sairahul1 keretezése: egy AI alkalmazás öt rétegből épül fel, kívülről befelé haladva: Prompt → Context → Harness → Loop → Graph. A graph a legkülső, ötödik réteg, ami nem helyettesíti az alatta levőket, hanem körbeveszi őket. A cikk hangsúlyozza: a graph engineering vita arról szól, hogy a nyilvános beszélgetés végre eljutott a legfelső rétegig, nem arról, hogy a többi elavult.

3. Mi változott valójában? — A napi kutatási brief példája

A cikk egy konkrét feladaton, a "napi kutatási brief"-en mutatja be a különbséget. A feladat: minden reggel forrásokat olvas, egyoldalas összefoglalót ír, és ellenőrzi a pontosságot, mielőtt a postaládába érkezik.

Egyetlen túlterhelt loopként egy ügynök mindent egy kontextusban csinál: keres, beönti a nyers HTML-t, megírja a briefet, majd "saját magát review-ja". Mire a review-hoz ér, a kontextus mocsár — nyers keresési HTML, félig megírt próza, korábbi érvelések összemosódnak. A review ugyanabban a kontextusban fut, ami írta, tehát saját munkáját igazolja. A forrásokat egyenként olvassa (a loop szekvenciális).

Egy kis graphként ugyanaz a feladat három node-dá válik, állapot áramlik közöttük:

in → [researcher] → notes → [writer] → draft → [reviewer] → brief
                    (fan-out       (clean      (fresh ctx, brief
                     N forrás,     notes       + accuracy bar)
                     párhuzamos)   only)
  • A researcher node párhuzamosan fan-out-ol a források felett, strukturált jegyzeteket ad vissza, soha nem ír prózát.
  • A writer node csak tiszta jegyzeteket lát, soha nem a nyers HTML-t, és megírja a briefet.
  • A reviewer node tiszta kontextusban fut, csak a briefet és a pontossági mércét látja, és hiba esetén visszairányítja a writer-hez.

A graph három valóban új képességet ad:

  1. Párhuzamos specializált node-ok tiszta, szeparált kontextussal — a writer nem fullad a keresési dumpokba, a reviewer nem a saját piszkos kontextusában dolgozik.
  2. Explicit, auditálható vezérlési folyamat — a routing előre definiált ("ha review elbukik, menj vissza"), diagramként olvasható, nem kell kibogarászni egy hosszú transcriptból. Pontosan az a fegyelem, amit @DavidKPiano (XState készítője) évek óta képvisel: a vezérlés legyen explicit és inspektálható, ne implicit és remélt.
  3. Fan-out / fan-in — egy loop ezt nem tudja: tíz research node tíz forráson, párhuzamosan, aztán merge. Google's ADK és a LangGraph is ezt a primitívet szállítja.

4. A graph ára (és az átnevezés valósága)

A graph nem ingyenes. Három promptot kell karbantartani egy helyett, kell egy állapot-séma a node-ok között ("mit ad át a researcher a writer-nek?"), és új failure mode-ok jönnek: merge ami csendben eldob egy forrást, routing bug ami örökké loopol, állapot ami szivárog egyik node-ból a másikba. A napi brief esetén ez a felhajtás megéri a minőséget. Egyszeri feladatnál tiszta adó.

A "graph engineering" szó maga naming event, nem technical event. A state-machine és graph orchestration a LangGraph-ban (StateGraph: add_node, add_edge, state az élek mentén), Microsoft AutoGen GraphFlow-ban (DiGraph: szekvenciális, párhuzamos, feltételes, loop flow), és Google ADK-ban (graph workflows, routing, multi-agent delegation A2A protokollal) mind a buzzword előtt szállítják. A topológia, a párhuzamosság és az explicit vezérlés valódi képességek; a "graph engineering" elnevezés csak címke.

5. A 4-kérdéses gut check — tényleg paradigmát váltottál?

A cikk egy használható önellenőrző listát ad. Mielőtt azt mondod magadnak, hogy "átmentem loopról graphra", számold meg az igennel válaszolt kérdéseket:

  1. Szétválasztottad egy kontextus több specializált kontextusra? Külön promptok és tool-ok node-onként, nem egy ügynök ami kalapot vált egyetlen transcripton belül. (Nem = átnevezted a loopot.)
  2. Van valódi fan-out / fan-in? Valami párhuzamosan fut és összeolvad, nem egy dobozokkal rajzolt szekvencia. (Nem = flowchartos loop.)
  3. A vezérlési folyamat diagramként olvasható? A routing ("ha review elbukik, visszamegy") előre definiált és inspektálható, nem egy ügynök megítéléséből emergál. (Nem = implicit loopod van.)
  4. Az objektív és a siker-mérce megváltozott? @PawelHuryn érve: ha "kész és helyes" pontosan úgy van definiálva mint eddig, a mögöttes fegyelem nem mozdult, csak a rajz.

Értékelés: 0-1 igen = loopod van graph diagram alatt. Tartsd meg loopnak és kíméld meg magad a failure mode-októl. 2-3 igen = valóban komponálsz loopokat graphba, az új képességek megérik az árukat. 4 igen = paradigmát váltottál, és ezt a munka követelte meg, nem a timeline.

Az egysoros teszt: ha meg tudod nevezni a specializált szerepeket és tudsz köztük nyilat húzni, az graph. Ha egyetlen feladat amit ismételgetni kell amíg helyes, az loop — tartsd meg loopnak.

A cikk érvelési stratégiája

A szerző három technikát alkalmaz a hype lehűtésére:

  1. Pozitív és negatív szkeptikus idézése egyaránt — a "graph engineering halott" tábor (@PawelHuryn "I call BS") és a "state machine, kedd van" tábor (@DavidKPiano) is megjelenik, és a szerző mindkettőből integrál: Huryn-től a fegyelmet, DavidKPiano-tól a topológia prior art-ját.
  2. Egy konkrét feladat (napi kutatási brief) szembeállítása — a két megközelítést nem absztrakt módon hasonlítja össze, hanem egy konkrét use-case-en demonstrálja a különbséget és az árát.
  3. A 4-kérdéses gut check — a szerző nem állítja, hanem eszközt ad: az olvasó maga dönti el, hogy az ő rendszerénél van-e paradigmaváltás vagy csak átnevezés.

A prior art rész konkrét és ellenőrizhető: LangGraph StateGraph API, AutoGen GraphFlow DiGraph, Google ADK graph workflows + A2A protokoll. A cikk explicit módon jelzi, hogy ezek 2026. júliusi állapot szerintiek, és a keretrendszer-specifikációk a forrásdokumentációkból származnak (LangChain docs, Microsoft AutoGen docs, Google ADK docs).

A szerző kapcsolódó tanácsai (cselekvési keret)

  • Mielőtt graphot építesz, urald a node-ot — minden node loop, és a gyenge loopokra épített graph több helyen csődöl el egyszerre. A Loop Engineering kurzus a kiindulópont.
  • A legtöbb feladat továbbra is egyetlen jól határolt loop — a graphot akkor érdemes bevezetni, ha egy loop ténylegesen erőltetett: a munka különböző specialitásokra oszlik, párhuzamos-then-join-t igényel, más modellt vagy tool-t kér lépésenként, vagy auditálható vezérlési folyamra van szükség.
  • A loop → graph migráció iteratív — kezdj egy looppal, és csak akkor promotáld graphba, ha a loop tényleg csődöl. A cikk egy "Graph or Loop: How to Decide" döntési táblát ígér a testvér-guide-ban.

Összegzés

A graph engineering valódi és túlreklámozott — és mindkettő egyszerre igaz. A valóban új három képesség: párhuzamos specializált node-ok tiszta kontextussal, fan-out / fan-in mint első osztályú move, és auditálható vezérlési folyamat. Az átnevezés rész: a topológia, a párhuzamosság, és az explicit vezérlés a LangGraph, AutoGen és ADK rendszerekben mind a "graph engineering" buzzword előtt szállítva voltak. A keret, ami túlélja a hype-ot: a loop a graph speciális esete (egy node önmagába visszacsatlakozó éllel). Nem graduálunk loopokból graphokba — komponálunk loopokat graphba, amikor és csakis amikor egy loop már nem elég, és a többlet promptsokban, állapot-sémákban és új failure mode-okban fizetődik. A rövid távú döntés a legtöbb feladatra: maradj loopnál, amíg a loop dolgozik.

Forrás

Vissza a tetejére