> LlamaIndex 2026: MIT-licencű Python keretrendszer adatokhoz és agentekhez, több mint 300 integrációval, eseményvezérelt Workflows-szal, és egy céggel, amely a fókuszát LlamaParse-ra helyezte.
>
> Web page: https://balazscsorba.com/hu/blog/llamaindex · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/llamaindex.md) · [Deutsch](https://balazscsorba.com/de/blog/llamaindex.md)
> Author: Balázs Csorba · Published: 2026-07-14 · Keywords: llamaindex, llamaindex vs langgraph, llamaindex workflows, llama index agent framework, llamaparse pricing, rag framework python, durable workflows python, document agent framework

[Blog](https://balazscsorba.com/hu/blog)/MI-ágensek

# LlamaIndex teszt: a legszélesebb adat-eszközkészlet, aminek a súlypontja már elmozdult

LlamaIndex 2026: MIT-licencű Python keretrendszer adatokhoz és agentekhez, több mint 300 integrációval, eseményvezérelt Workflows-szal, és egy céggel, amely a fókuszát LlamaParse-ra helyezte.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. július 14.·10 perc olvasás

-   Agent framework
-   RAG
-   Python
-   Document parsing
-   Workflows

![Nyolc küllő egy középső négyzetes agy körül, egy sokkal hosszabb elér egy távoli dobozt.](https://balazscsorba.com/images/blog/llamaindex/cover.webp?v=222a9c2759)

## A lényeg röviden

-   A LlamaIndex továbbra is a legszélesebb open source adat-eszközkészlet LLM-alkalmazásokhoz: több mint 300 integrációs csomag, mindegyik vékony adapter, egy kis magabsztrakció-készlet fölött.
-   A Workflows, az orchestrációs réteg eseményvezérelt: egy lépés eseményt kap és eseményt ad vissza, a gráf a típusannotációkból származik, és a futás előtt validálódik.
-   A perzisztencia opcionális és kézzel írandó. Egy futás alapértelmezés szerint efemer, a mentés a \`Context.to\_dict()\` pillanatképéből és a csapat által írt hurokból áll, a folytatás at-least-once, tehát a lépéseknek újrafuttathatónak kell lenniük.
-   A cég saját README-je szerint a fókusz ma a dokumentumparsolás és a kinyerés. A LlamaParse a fizetős termék, kreditben árazva, a LiteParse pedig a helyi open source parser.
-   Az ítélet: használd az open source magot, a Workflows-ot pedig kis könyvtárként, de tartsd szűken a framework hatókörét, mert a karbantartás iránya egyértelműen máshová tolódott.

Ezen az oldalon

1.  [Mi ez](https://balazscsorba.com/#what-it-is)
2.  [Hogyan működik a Workflows](https://balazscsorba.com/#how-it-works)
3.  [Első lépések](https://balazscsorba.com/#getting-started)
4.  [Perzisztencia és újrapróbálkozás](https://balazscsorba.com/#durability)
5.  [Hol gyengül](https://balazscsorba.com/#where-it-falls-short)
6.  [A fordulópont a dokumentumfeldolgozás felé](https://balazscsorba.com/#the-pivot)
7.  [Ítélet](https://balazscsorba.com/#verdict)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A LlamaIndex MIT-licencű Python-keretrendszer, amely LLM-alkalmazásokat köt össze adatokkal. Konnektorok és indexabsztrakciók halmazaként indult retrievalre, és máig a legszélesebb ilyen eszközkészlet: a repository több mint 300 integrációs csomagot publikál modell-szolgáltatókhoz, embedding modellekhez, vektortárakhoz, dokumentum-betöltőkhöz és rerankerekhez. Ez a szélesség az oka, hogy a legtöbb csapat először ezzel találkozik, és az is, hogy hasznos marad akkor is, ha a cég figyelme már máshol jár. Az itt felvett állás egyszerű: használd az open source magot, és tudatosan döntsd el, melyik hosztolt részt veszed fel.

A modell-szolgáltató és az alkalmazás között helyezkedik el. A magban semmi nem beszél közvetlenül modell-szolgáltatóval; minden modell, embedder és vektortár egy integrációs csomagon keresztül érkezik, amely a mag egy absztrakt osztályát implementálja. Ez tiszta határ, és egyben a fő panasz forrása is: ugyanaz az absztrakciónak le kell fednie az OpenAI-t, egy helyi Ollama-folyamatot és egy tucat embedding modellt, így a hasznos közös nevező keskenyebb, mint a felület sugallja. A LangGraphgel ugyanazt az orchestrációs szerepet versenypályázza, a LangChainnel az adatkezelést, a kézzel összerakott vektortár-plusz-reranker kombinációval pedig a kényelmet versenyezi, nem a képességet.

## Mi ez

A csomagstruktúra az első, amit ellenőrizni kell, és ott kezdődik a legtöbb zavar. A `llama-index-core` tartalmazza az absztrakciókat, és a Workflows-ot is mellé szállítja. A `llama-index` az induló csomag, amely a magot és egy választott integrációcsoportot telepíti. A Workflows önállóan is megjelent `llama-index-workflows` néven, és ha a magon keresztül érkezik, akkor `llama_index.core.workflow` néven importálják. Minden más külön telepítés, és csak ezért marad kezelhető a függőségi fa.

-   MIT-licenc. A `llama-index-core` aktuális kiadása 0.14.25, 2026. szeptember 21-én.
-   Több mint 300 integrációs csomag a PyPI-n, mindegyik vékony adapter a mag egy absztrakt osztálya fölött.
-   A Workflows, az orchestrációs réteg eseményvezérelt: egy lépés egy eseményt kap, és egy másikat ad vissza, a framework pedig típusannotáció alapján irányít, nem deklarált él mentén.
-   Az eseménygráfot a futás előtt validálja a framework. Elutasítja az olyan workflow-kat, ahol egy eseménynek nincs termelője, egy előállított eseménynek nincs fogyasztója, vagy nem érhető el végső esemény.
-   A futások alapértelmezés szerint efemerisek. A perzisztencia opcionális `Context.to_dict()` pillanatképeken keresztül, vagy egy futásidejű pluginnon, mint a DBOS, amely a lépésátmeneteket adatbázisba naplózza.
-   A framework gyakorlati célplatformja a Python. Csak a LiteParse, a cég új helyi parserje szállít bindingokat a Pythonon túl.

## Hogyan működik a Workflows

A Workflows az a rész, amit érdemes megérteni, mert az is az, ami túléri a framework RAG-múltját. Egy workflow a `Workflow` egy alosztálya, amelynek metódusait a `@step` díszíti. Minden lépés egy eseménytípust fogad, és egy másikat ad vissza; a kezdeti eseménytípus visszaadása indítja a futást, a `StopEvent` visszaadása zárja. Az elágazások szokásos `if` utasítások, amelyek különböző eseménytípusokat adnak vissza, a hurok pedig olyan lépés, amely korábban kezelt eseménytípust ad vissza. A párhuzamosság egy `list[Event]`\-et visszaadó lépés, egy `list[Event]`\-et fogadó lépéssel párban, amely a gyűjtő.

![Workflows: tipizált események viszik előre a futást Egy kezdő esemény elindít egy retrieval lépést, amely nyolc párhuzamos workerre fanoutol, majd egy reranking lépés és egy záró StopEvent következik. Alattuk egy checkpoint lépés minden befejezett lépés után JSON-ba menti a kontextust, és egy resume útvonal csak a befejezetlen munkát ismétli.](https://balazscsorba.com/images/blog/llamaindex/diagram-7.webp?v=ef4c7d8e92)

A gráf a lépésszignatúrákból származik, és az első esemény kibocsátása előtt validálódik. A perzisztencia nem része a futásidejének: az egy hurok, amit a csapat ír körül.

-   Adj vissza `list[Event]`\-et, ha egy lépés véges halmazzal dolgozik, és minden munkaelemet előállíthat, mielőtt a további workerek elindulnak.
-   Fogadj el `list[Event]`\-et, ha a lépésnek az eredmények teljes halmazára szüksége van a folytatáshoz.
-   Hívd a `ctx.send_event(...)` metódust, ha az események száma előre ismeretlen, vagy ha egy eseményt lépen kívülről kell kibocsátani.
-   A `ctx.store` a futáson belüli megosztott állapotra való, a `Resource(...)` pedig azokra a kliensekre, modellekre és konfigurációra, amelyek nem kerülhetnek egy pillanatképbe.

A típusannotációk nem díszítőelemek, hanem teherhordók. Végrehajtás előtt a framework a lépésszignatúrákból levezeti az eseménygráfot, és megtagadja az indulást, ha van nem előállított esemény, elfogyasztatlanul maradó esemény vagy el nem érhető `StopEvent`. Ez olyan bekötési hibákat fog meg, amelyeket a kézzel megírt függvénykompozíció egyáltalán nem, és ez a tervezés legerősebb érve. Az ár az, hogy a szándékosan dinamikus workflow-nak a `ctx.send_event`\-hez kell visszatérnie, és meg kell jelölnie, mely statikus ellenőrzések hagyhatók ki, ami gyakorlatban azt jelenti: minél képesebb egy workflow, annál kevésbé ellenőrizhető statikusan.

## Első lépések

A legkisebb használható workflow körülbelül húsz sor. Két telepítési forma támogatott, és az importútban különböznek, ez a részlet szokott sokaknak megbukni:

```
import asyncio

from llama_index.core import VectorStoreIndex
from workflows import Workflow, step
from workflows.events import Event, StartEvent, StopEvent

class Answered(Event):
    question: str
    answer: str

class TriageFlow(Workflow):
    index: VectorStoreIndex

    @step
    async def retrieve(self, ev: StartEvent) -> Answered:
        retriever = self.index.as_retriever(similarity_top_k=8)
        nodes = await retriever.aretrieve(ev.question)
        best = max(nodes, key=lambda n: n.score or 0.0)
        return Answered(question=ev.question, answer=best.node.get_content())

    @step
    async def answer(self, ev: Answered) -> StopEvent:
        return StopEvent(result=ev.answer)

async def main():
    flow = TriageFlow(index=VectorStoreIndex.from_documents(documents), timeout=60)
    result = await flow.run(question="What is the refund window?")
    print(result.result)

asyncio.run(main())
```

A `run()` egy `WorkflowHandler`\-t ad vissza. Awaitelhető, és ha nem awaitelsz azonnal, hanem megtartod a handlert, közben hozzáférsz a `stream_events()`\-hez a folyamatjelzéshez. A `timeout` argumentum másodpercben értendő, és a konstruktorban adod át. Minden lépés szándékosan async, ezért egy önálló szkripthez egyetlen `asyncio.run` belépési pont kell; FastAPI-ben vagy jegyzetfüzetben nem szükséges.

**Válaszd ki tudatosan a telepítési formát**

Ha csak az orchestráció kell, telepítsd egyedül a `llama-index-workflows` csomagot; ha a retrieval-komponensek is jönnek, telepítsd a `llama-index-core`\-t, mert az újra exportálja a Workflows-ot `llama_index.core.workflow` néven. Az induló `llama-index` csomag egy választott integrációcsoportot húz be, amit a legtöbb alkalmazás már az első napon lecserél.

## Perzisztencia és újrapróbálkozás

A Workflows alapértelmezés szerint efemer: amint a `run()` visszatér, az állapot megszűnik, és a következő futás nulláról indul. Sok száz dokumentumra kiterjedő kiszámoláshoz, amelynek nem szabad nulláról újrakezdődnie, a dokumentáció checkpoint hurkot ír elő. A `Context.to_dict()` szerializálja a még folyamatban lévő eseményeket és az állapottárolót, a `Context.from_dict()` visszaépíti őket, a `run(ctx=...)` pedig egy másik folyamatban folytatja. Beépített checkpointer nincs: a futás belső `StepStateChanged` eseményt ad le, amikor egy lépés befejeződik, és ez a mentési jel.

```
import json

from workflows.events import StepState, StepStateChanged

handler = flow.run(question=q)

async for ev in handler.stream_events(expose_internal=True):
    if isinstance(ev, StepStateChanged) and ev.step_state == StepState.NOT_RUNNING:
        json.dump(handler.ctx.to_dict(), open("run.json", "w"))

result = await handler

# after a restart: resume from the last snapshot
ctx = Context.from_dict(flow, json.load(open("run.json")))
result = await flow.run(ctx=ctx)
```

A dizájn két tulajdonsága üzemeltetéskor jelentkezik. A folytatás at-least-once: az a lépés, amely a pillanatkép idején még futott, visszatekeredik és újrafut, tehát legfeljebb `num_workers` elem duplázódik. A pillanatkép pedig JSON, így ha a szerializáló nem tud kódolni egy értéket, a `to_dict()` feldob, és az egész mentés elhasal, nem csak az érintett mező. A nehéz bemenetek ezért `Resource`\-be kerülnek, amely folytatáskor újraalkotódik ahelyett, hogy szerializálódna. Aki nem akarja magát kezelni a hurkot, használhatja a DBOS futásidejű plugint, amely a lépésátmeneteket adatbázisba naplózza, és nem kell hozzá checkpoint-kód.

## Hol gyengül

A gyengeségek strukturálisak, nem bugok. A szélesség karbantartási felület: több száz integrációval egy frissítés olyan modell-wrappert is mozgathat, amelyet senki nem akart hozzáérni, és egy integráció rögzítése gyakran a mag rögzítését is jelenti. A magas szintű API annyit elrejt, hogy egy prototípus anélkül juthat productionbe, hogy bárki feljegyezné, melyik chunkméret, melyik top-k és melyik prompt-sablon adta a választ; az alapértékek kényelmesek, és nincsenek alapértékként dokumentálva. A perzisztencia opcionális és kézzel írandó, vagyis épp az ellentéte annak, amit egy hosszú életű batch feladat kér. És a framework mögötti cég nyíltan szűkítette a fókuszát, ami 2026-ban kínos értékelési tényező.

Framework

Orchestrációs modell

Perzisztencia és állapot

Hol nyer

**LlamaIndex Workflows**

Eseményvezérelt lépések, vezérlési folyamat normál Pythonban

Nincs beépített checkpointer; kontextusmentések a csapattól vagy a DBOS futásidejű plugin

A retrieval- és dokumentumkomponensek ugyanabban a könyvtárban vannak

**LangGraph**

Explicit állapotgráf feltételes élekkel

A tartós végrehajtás és a checkpointerek az alapértelmezés

Az állapotátmenetek maguk az artefaktum, és gráfként átláthatók maradnak

**Haystack**

Tipizált komponensekből álló pipeline-ok

Komponensenkénti hibaelágak és újrapróbálkozások

Stabil komponenskatalógus retrievalre épülő alkalmazásokhoz

**DSPy**

Deklaratív modulok, offline hangolva egy metrikára

Nincs; ez nem orchestrációs futásidej

Promptok és modulok hangolása, mielőtt kiszolgáló kód egyáltalán létezne

Végigolvasva a perzisztencia oszlopot a gyakorlati metszet jól látszik. A LangGraph alapértelmezetté teszi a checkpointot, és ezt azzal fizeti meg, hogy a gráf explicit, ami gondolkodási munka, viszont olvashatóságot vásárol. A Workflows a vezérlést normál Pythonban tartja, ami jobban olvasható és rosszabbul átlátható: egy workflow, amely 500 dokumentumra is kiterjed, 500 párhuzamos hívás, amelyek sorrendjét egyetlen eszköz sem segít meglátni. Egy csapat számára, amelynek munkája az állapotátmenetek átgondolása, ez rossz csere. Egy csapat számára, amely normál Pythont akar írni és elvárja, hogy előre nem láthatóan viselkedjen, ez jó csere.

Ide tartozik egy második megjegyzés. A dinamikus workflow elveszíti a statikus analízist, és a dokumentáció kimondja, hogy az el nem érhető lépések és az egyszeri események pontosan azok, amit ezek az ellenőrzések nem látnak. Aki kézzel rajzolt gráfot ültet át Workflows-ba, elég korán nyúl a `skip_graph_checks` opcióhoz, és ezzel csendben letiltja azt az ellenőrzést, amely az elhalt ágakat megtalálná, vagyis ugyanazt az ellenőrzést, amely eredetileg a bekötési hibát kiszúrta volna.

## A fordulópont a dokumentumfeldolgozás felé

A repository README-je mostantól feltűnő jegyzetet visel: a LlamaIndex aktuális fókusza a dokumentumparsolás és kinyerés, a LlamaParse pedig a cég vállalati platformja ehhez. Ez megváltoztatja, hogy mit finanszíroz egy karbantartási keret. Az integrációs csomagok továbbra is megjelennek és működnek; az már nem garantált, hogy mindegyik bővül, amikor új szolgáltató jelenik meg.

-   A LlamaParse a fizetős termék: agentikus OCR, parsolás, kinyerés és indexelés, kreditben értékesítve, nem felhasználói helyek szerint.
-   A LiteParse az open source ellensúly: egy Rust parser, amely helyben fut, LLM, felhőfüggőség és API-kulcs nélkül, TypeScripthez, Pythonhoz, Rusthoz és böngészős WASM-hez való bindingokkal.
-   A ParseBench és az ExtractBench a cég saját nyilvános benchmarkjai parsolásra és kinyerésre.
-   A framework MIT-licencű marad, és megjelent a PyPI-n, a `llama-index-core` 0.14.25 verzióval 2026. szeptember 21-én.
-   Az eredmény egy megosztott stratégia: nyílt eszközök a helyi parsoláshoz, hosztolt platform a nehéz dokumentumokhoz, és közöttük az agent-framework mint integrációs felület.

Ez megindokolható üzleti döntés, és enyhe figyelmeztetés mindenkinek, aki most keretrendszert választ. A halom azon részei, amelyeket leginkább karbantartanak, a fizetős fal mögött vannak, és a MIT-mag az, ami könyvtárként hasznos marad. Ezt úgy olvasd, hogy a framework hatókörét érdemes kicsire tartani: a Workflows-ot az orchestrációra használd, a betöltést és a parsolást tartsd házban, ahol ez lehetséges, és légy explicit abban, melyik hívások hagyják el az infrastruktúrádat.

**A LlamaParse árai számokban**

Az árazási oldal krediteket ad el, nem helyeket: 1000 kredit 1,25 dollár, 10 000 kredit az ingyenes csomagban, 40 000 az 50 dolláros starterben és 400 000 az 500 dolládos pro csomagban, a pay-as-you-go plafon pedig havi 500, illetve 5000 dollár. Az egyidejű parse feladatok száma 5 az ingyenes és a starter csomagban, 20 a prof, 100 az enterprise szinten. A parse, a kinyerés, a besorolás és az indexelés ugyanarról az egyenlegről von le, és ugyanaz a táblázat intelligens eredménytárolást sorol fel nulla kredites újraparse-sel, amit egy adott parse-konfigurációnál érdemes ellenőrizni, nem pedig feltételezni.

## Ítélet

Az ítélet az, hogy a LlamaIndex a legteljesebb válasz egy szűk kérdésre, hogyan kerülnek dokumentumok egy LLM-alkalmazásba saját integrációs réteg írása nélkül, és közepes válasz a tágabb kérdésre, hogyan kell orchestrálni egy agentet. A Workflows valóban jól fordítja elágazó logikát tipizált, validált Pythonná, és az at-least-once checkpoint modellje őszinte a saját hibaértelmezésével. Amit a framework nem kínál, az egy olyan futásideje, amelyre rámutathatsz és megnézhetsz: nincs állapotgráf átvizsgálásra, nincs alapértelmezett perzisztencia, és a karbantartás iránya nyilvánosan máshová tolódott.

1.  Vedd, ha az adataid többsége dokumentum, és a konektor-, chunker-, embedder- és reranker-absztrakciók már meg vannak írva. Ez valódi megtakarítás, és ez volt az eredeti cél.
2.  Vedd a Workflows-ot önálló, kis könyvtárként, ha az orchestráció elágazó, hurkozó Python, amely most az asyncio-ban összekeveredve él. A tipizált eseménygráf és az indulás előtti validáció az ok.
3.  Ne válaszd egy olyan gráf miatt, amelyen végig kell gondolkodni. Ha az állapotátmenetek maguk a vizsgálandó anyag, az explicit gráf ver a Python vezérlési struktúrája.
4.  Ne válaszd a hosztolt platform miatt. A LlamaParse, az Extract és az index szolgáltatás külön fizetős termék kreditárazással, és az ingestion-számládat frameworkhez kötni döntés, nem alapértelmezés.
5.  Kerüld TypeScript- vagy Go stackhez. A mag Python, csak az új LiteParse parser szállít szélesebb bindingokat.
6.  Értékeld újra egy év múlva, ha az integrációs szélesség hordozó. A cég parsolásra és kinyerésre fókuszáló iránya mellett a vektortár- és embedder-integrációk hosszú farka az, ami a leginkább kitett a lassú karbantartásnak.

> The current focus of LlamaIndex is to build the best AI-powered engine for document parsing and extraction.

Ez a mondat a projekt README-jében áll, nem egy blogbejegyzésben, ami szokatlan és megjegyzésre érdemes: maguk a framework fenntartói nevezik meg, merre tart az ütterv. Mérnöki olvasatban ez azt jelenti, hogy az orchestrációs réteget karbantartják, de nem az a cél, a fizetős dokumentumfeldolgozás viszont az.

## Források

1.  [LlamaIndex repository README and focus note](https://github.com/run-llama/llama_index)
2.  [Agent Workflows: introduction](https://developers.llamaindex.ai/python/llamaagents/workflows/)
3.  [Agent Workflows: writing durable workflows](https://developers.llamaindex.ai/python/llamaagents/workflows/durable_workflows/)
4.  [Agent Workflows: observability](https://developers.llamaindex.ai/python/llamaagents/workflows/observability/)
5.  [LlamaAgents overview](https://developers.llamaindex.ai/python/llamaagents/overview/)
6.  [llama-index-core on PyPI](https://pypi.org/project/llama-index-core/)
7.  [LlamaIndex and LlamaParse pricing](https://www.llamaindex.ai/pricing)
8.  [LiteParse documentation](https://developers.llamaindex.ai/liteparse/)
9.  [LangGraph on GitHub](https://github.com/langchain-ai/langgraph)

## Gyakori kérdések

Megéri-e még a LlamaIndex 2026-ban?

Igen, szűkebb hatókörrel. Az MIT-licencű magat továbbra is karbantartják, a \`llama-index-core\` 2026. szeptember 21-én a 0.14.25 verziónál állt, és a Workflows orchestrációs réteg valóban jól van megtervezve az elágazó és hurkozó logikához. Amitől megváltozott a helyzet, az a cég deklarált fókusza, amelyet a README a dokumentumparsolásra és kinyerésre, nem a frameworkre helyez.

Mik a LlamaIndex Workflows, és hogyan működnek?

Egy workflow a \`Workflow\` egy alosztálya, amelynek metódusait \`@step\` díszíti. Minden lépés egy eseménytípust fogad, és egy másikat ad vissza, a framework pedig típusannotáció alapján irányít, így az elágazások szokásos \`if\` utasítások, a hurkok pedig olyan lépések, amelyek egy korábban kezelt eseményt adnak vissza. A párhuzamosság egy \`list\[Event\]\`-et visszaadó lépés, egy \`list\[Event\]\`-et fogadó lépéssel párban. Az eseménygráf a futás előtt validálódik.

Hogyan kezeli a LlamaIndex a perzisztenciát és az újrapróbálkozást?

Alapértelmezés szerint nem. Amint a \`run()\` visszatér, az állapot megszűnik. A dokumentált mechanizmus egy checkpoint-hurok: a kontextust a \`Context.to\_dict()\`-tel mentjük, amikor egy \`StepStateChanged\` esemény egy lépést befejezettnek jelöl, majd a \`Context.from\_dict()\`-tel visszaépítjük, és meghívjuk a \`run(ctx=...)\`-t. A folytatás at-least-once, tehát a mentéskor még futó lépés újrafut. A DBOS futásidejű plugin az alternatíva, ami megszünteti a hurkot.

Mennyibe kerül a LlamaParse?

Az árazási oldal krediteket ad el, nem helyeket: 1000 kredit 1,25 dollár, 10 000 kredit ingyen, 40 000 az 50 dolláros starter csomagban és 400 000 az 500 dolládos pro csomagban, a pay-as-you-go plafon pedig havi 500, illetve 5000 dollár. Az egyidejű parse feladatok száma 5 az ingyenes és a starter csomagban, 20 a prof, 100 az enterprise szinten. A parse, a kinyerés, a besorolás és az indexelés ugyanarról az egyenlegről von le.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Eszközök tervezése AI-ágenseknek: nevek, leírások, sémák és hibaüzenetek](https://balazscsorba.com/hu/blog/agent-tool-design-descriptions-errors)
-   [Legacy kódbázis migrálása coding agentekkel: strangler fig playbook](https://balazscsorba.com/hu/blog/coding-agents-legacy-codebase-migration)
-   [Háttérben futó kódoló ügynökök: PR-ek, sorok és review](https://balazscsorba.com/hu/blog/background-agents-async-pr-workflow)
-   [Kontextusromlás hosszan futó ügynököknél: törlés, tömörítés, memória és al-ügynökök](https://balazscsorba.com/hu/blog/context-rot-compaction-long-running-agents)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)