Preskoči na glavni sadržaj

Kolega: "U doba AI-ja još uvek koristite Javin LangGraph4J umesto da pređete na Python?" Nasmejao sam se: "Sa Codex+Claude Code koji jezik nije problem? Agentu uopšte nije stalo."

Chenmo Wang ErAIAgentLangGraph4JSpring AI3364 reči11 minuta

U dobu AI-ja, naišao sam na mnogo kolega koji još uvek dvoume između učenja Jave i Pythona — po mom mišljenju, programski jezik je samo nosilac, zaista nije važno koji učite.

Jer Agent tečno govori svaki jezik.

Bilo Claude Code ili Codex, kod koji napišu već prevazilazi 99.9% programera.

Ovo je van sumnje.

Sa ova dva Agent alata, bilo ko može da postane top full-stack inženjer.

Pogledajte, ovo je dify frontend koji sam malopre replicirao pomoću jedne jedine rečenice sa Codex-om, izgled PaiAgent-a se odmah popelo na mnogo viši nivo.

ps: PaiAgent je moj Vibe Coding projekat open source na GitHub-u, nisam ga previše propagirao, a već ima preko 300 zvezdica.

Python ili Java?

Trebamo razmišljati samo o jednoj stvari: da li je postojeći projekat pisan u Javi ili Pythonu. Ili, da li intervjueri više dolaze iz Java ili Python pozadine, jer intervju još uvek u velikoj meri ispituje ispitna pitanja.

Java ekosistem AI infrastrukture se već popunio.

Spring AI je već veoma jak, LangChain4j je dobio 4.9k zvezdica, LangGraph4j je takođe došao do 1.6k zvezdica.

Sve što treba da postoji, tu je.

01,LangChain4j

Prvo o LangChain4j, jer je on osnova.

LangChain4j je Java port Python LangChain-a, pozicioniran kao "opšta LLM integraciona alatna kutija". Rešava ključni problem: kako u Java projektu zgodno pozvati veliki model.

Stvari koje radi obuhvataju:

①,Jedinstven API poziv — bez obzira na to da li je podrenderer OpenAI, Tongyi Qianwen, DeepSeek ili Zhipu, kod na gornjem sloju je napisan konzistentno. Promena provajdera modela zahteva samo izmenu konfiguracije, bez diranja poslovnog koda.

②,Registracija Tool — anotacijom @Tool se Java metoda označava kao "alat koji može pozvati LLM". Ako model treba da proveri vreme, zove metodu za vreme; ako treba da pretražuje bazu, zove metodu za upit. Java implementacija Function Calling-a.

③,RAG pretraga — integrisano je preko 20 vrsta Embedding skladišta (Milvus, Pinecone, Qdrant itd.), pomaže vam u sečenju dokumenata, vektorizaciji i pretrazi sličnosti.

④,Prompt šablon — zamena promenljivih, upravljanje Few-shot primerima.

⑤,Memorija razgovora — upravljanje kontekstnim prozorom razgovora u više rundi.

Za scenarije "pozovi jednom model i uzmi rezultat", "uradi jednostavan RAG Q&A", "registruj nekoliko Tool-ova pa neka model sam bira", LangChain4j je sasvim dovoljan.

Ali ako potreba postane: "Agent prvo pretražuje, na osnovu rezultata pretrage ocenjuje da li treba da postavi dopunsko pitanje, nakon dopune sažima, ako kvalitet sažetka nije dovoljan, pretražuje ponovo." Za ovakve višekoračne procese sa uslovnim granama i petljama, LangChain4j nije dovoljan.

Jer LangChain4j-ov model izvršenja je lanac (Chain), suštinski je jedna prava linija. Možeš dodati if-else, ali to je hardkodirani tok kontrole, nedovoljno fleksibilan.

Zato nastupa LangGraph4j.

02,LangGraph4j

LangGraph4j rešava problem "kako orkestrirati više Agenata da sarađuju". Grafikon stanja, uslovno rutiranje, petlja sa ponovnim pokušajem, oporavak putem checkpoint-a — te sposobnosti LangChain4j nema, a LangGraph4j ima.

Do maja 2026. godine, LangGraph4j je na GitHub-u dobio 1.6k zvezdica, najnovija verzija 1.8.14 (objavljena 2026-04-27). MIT licenca, minimalan zahtev Java 17.

On i LangChain4j nisu u odnosu konkurencije, već u odnosu gornji-donji sloj.

LangGraph4j zvanično to objašnjava ovako: designed to work seamlessly with both LangChain4j and Spring AI.

Nacrtajmo jednu sliku da pomognemo izgradnju intuicije:

LangChain4j može samo pravo, LangGraph4j može grafikon. Grafikon znači da mogu postojati grane, petlje, paralelnost.

Da upotrebimo poređenje: LangChain4j je autoput, od ulaza do izlaza samo jedna putanja. LangGraph4j je gradska mreža ulica, na svakom raskršću može se na osnovu stanja saobraćaja izabrati koja ulica, može se i okrenuti.

Naš PaiAgent (workflow engine Pai Congming-a) koristi upravo ovu kombinaciju — Spring AI igra ulogu LangChain4j-a zaduženu za pozive modela na nižem sloju, dok LangGraph4j upravlja orkestracijom radnih tokova na gornjem sloju.

03,Tri ključna koncepta LangGraph4j

Ako intervjuer pita za LangGraph4j, sigurno će izvući tri stvari:

StateGraph, AgentState, Edge.

Ova tri koncepta su čitav model izvršenja podrenderer.

StateGraph

StateGraph je definicija celog grafikona. Na njemu registrujemo čvorove, povezujemo grane, postavljamo ulaz i izlaz, i konačno pozivamo compile() da ga kompajliramo u nepromenljiv CompiledGraph za izvršenje.

Ovaj korak kompajliranja radi strukturnu proveru — ispituje da li ima izolovanih čvorova, da li ima ulaza i izlaza.

Ako struktura grafikona ima problema, greška se prijavljuje već u fazi kompajliranja.

PaiAgent koristi langgraph4j-core-jdk8 (1.1.5) plus langgraph4j-spring-ai (1.8.0-beta3), prvi pruža jezgrovni engine grafikona, a drugi radi integracioni sloj za Spring AI.

AgentState

AgentState je kontejner stanja deljen između čvorova.

Suštinski je Map<String, Object>, svaki čvor ga može čitati i menjati, a izmenjeni rezultat se prosleđuje sledećem čvoru. Veoma podseća na upravljanje state-om u React-u — stanje je nepromenljivo, svaki čvor vraća novu Mapu stanja, a framework ti spaja.

LangGraph4j takođe podržava mehanizam koji se zove Channel, kojim se mogu definisati Reducer-i za kontrolu strategije ažuriranja stanja.

Na primer, AppenderChannel će dodavati vrednosti u listu umesto da ih prepisuje.

Ovo je posebno korisno u ReAct modu — intermediate_steps koje Agent generiše u svakoj rundi petlje treba akumulirati, i AppenderChannel to omogućava. Nakon svakog poziva alata, rezultat se dodaje u listu, a u sledećoj rundi Agent može videti kompletnu istoriju.

Edge (grana)

Obična grana je samo fiksna linija A → B.

Uslovna grana na osnovu trenutnog stanja odlučuje gde dalje — EdgeAction prima trenutno stanje, vraća string za rutiranje, a framework na osnovu tog stringa odlučuje kojom granom ide.

Uslovna grana je najjače oružje LangGraph4j-a. Sa njom, Agent sam može odlučiti "da li da odmah dam odgovor ili da prvo pozovem alat pa se vratim". Ovo je strukturni izraz ReAct moda u grafikonu — Agent ocenjuje da je zadatak završen pa ide na END, ili ocenjuje da mu je potreban alat pa se rutira na tool_executor čvor, a nakon izvršenja se vraća da nastavi razmišljanje, formirajući petlju.

04,PaiAgent-ov graditelj grafikona

Pošto smo objasnili koncepte, pogledajmo kako se to implementira u PaiAgent-u.

PaiAgent-ova orkestracija radnih tokova ima dva engine-a: jedan stari DAG engine (topološko sortiranje i redosledno izvršenje), jedan novi LangGraph engine.

Ključna klasa je GraphBuilder, zadužena za pretvaranje JSON konfiguracije koju prosledi frontend u StateGraph LangGraph4j-a:

Logika identifikacije ulaznog čvora je veoma jednostavna: prolazi kroz sve čvorove, i ako neki čvor nema nijednu ulaznu granu koja pokazuje na njega, on je ulaz.

Izlaz je isti.

Tako korisnik na frontendu ne mora eksplicitno da označava šta je početak a šta kraj, nakon crtanja grafikona se automatski zaključuje.

JSON struktura koju prosledi frontend izgleda ovako:

{
  "nodes": [
    {"id": "input-1", "type": "input", "data": {"label": "Unos"}},
    {"id": "qwen-1", "type": "qwen", "data": {"configId": 1, "prompt": "{{question}}"}},
    {"id": "output-1", "type": "output", "data": {"responseContent": "{{response}}"}}
  ],
  "edges": [
    {"source": "input-1", "target": "qwen-1"},
    {"source": "qwen-1", "target": "output-1"}
  ]
}

GraphBuilder radi to da "prevede" ovaj JSON u pozive LangGraph4j API-ja.

05,Adapter čvorova

Ako te na intervjuu pitaju "kako poslovne čvorove integrišete u LangGraph4j", odgovori sa NodeAdapter i to je to.

PaiAgent ima mnogo tipova čvorova: Input, Output, razni LLM (Qwen, DeepSeek, Zhipu, OpenAI).

Logika izvršenja ovih čvorova je različita, ali LangGraph4j zahteva da svi čvorovi implementiraju interfejs AsyncNodeAction<AgentState> i vraćaju CompletableFuture<Map<String, Object>>.

NodeAdapter je upravo taj most.

Njegova ključna logika je u pet koraka: iz stanja izdvoji currentInput → preko fabrike dobavi odgovarajući NodeExecutor → izvrši logiku čvora → izgradi novo stanje (nepromenljiva ažuriranja, new HashMap<>(state.data())) → izlaz upiši nazad u currentInput i nodeOutputs.

Ovde ima nekoliko ključnih dizajna:

  • Nepromenljivo ažuriranje stanja — svaki čvor uradi new HashMap<>(state.data()) da napravi kopiju pa onda menja, ne dira direktno originalno stanje. Ovo osigurava da čak i ako neki čvor ne uspe, prethodno stanje neće biti kontaminirano.
  • Lančani prenos currentInput-a — izlaz svakog čvora se ubacuje u currentInput, a sledeći čvor iz currentInput-a uzima ulaz. Na taj način između čvorova nastaje implicitni cevovod podataka.
  • Globalna arhiva nodeOutputs — izlazi svih čvorova se čuvaju u nodeOutputs, Output čvor može putem sintakse šablona {{nodeId.paramName}} referencirati izlaz bilo kog čvora.

Na intervjuu možeš ovako da odgovoriš: "Adapter patternom smo odvojili logiku izvršenja poslovnih čvorova od LangGraph4j-ovog modela stanja. NodeExecutor brine samo o ulazu i izlazu, ne mora da zna za LangGraph4j. NodeAdapter je zadužen za izdvajanje i upisivanje stanja."

06,Menadžer stanja

Kako se stanje inicijalizuje, kako teče između čvorova i kako se konačno izdvajaju rezultati — to je odgovornost StateManager-a.

Pri inicijalizaciji, StateManager u Mapu stanja ubacuje pet ključeva:

  • inputData (originalni unos)
  • currentInput (ulaz trenutnog čvora, početna vrednost je originalni unos)
  • nodeOutputs (istorija izlaza svih čvorova, inicijalno prazna Mapa)
  • status (RUNNING)
  • startTime.

Nakon završetka izvršenja, getFinalOutput() direktno iz currentInput-a uzima vrednost koju je upisao poslednji čvor — jer svaki čvor nakon izvršenja prepisuje svoj izlaz u currentInput, tako da je konačni currentInput zapravo izlaz poslednjeg čvora.

Kompletan životni ciklus toka stanja: inicijalizacija → izvršenje Node A → ažuriranje stanja → izvršenje Node B → ažuriranje stanja → ... → izdvajanje konačnog izlaza.

Stanje koje svaki čvor vidi sadrži istoriju izlaza svih prethodnih čvorova. To znači da kasniji čvorovi mogu referencirati rezultate bilo kog ranijeg čvora.

Praktičan scenario: radni tok "prevod + korektura", Translation čvor izbacuje prevod, Review čvor ne samo da vidi prevod (preko currentInput), već može videti i original (preko nodeOutputs["input-1"]).

Ili radni tok "prvo pretraži pa sažmi", Search čvor preko RAG-a pronalazi tri dokumenta, Summary čvor mora istovremeno da vidi i originalno korisničko pitanje i rezultate pretrage.

Da postoji samo lančani prenos currentInput-a, Summary čvor bi izgubio originalno pitanje. Globalna arhiva nodeOutputs rešava ovaj problem — bilo koji čvor može da "pogleda unazad".

07,Kako se LLM čvorovi povezuju sa Spring AI

PaiAgent podržava više LLM provajdera (Qwen, DeepSeek, Zhipu, OpenAI, Step Stars), ali svi dele istu logiku izvršenja.

U tome je vrednost AbstractLLMNodeExecutor-a.

Proces izvršenja ima šest koraka: izdvajanje konfiguracije (API URL, Key, Model, Temperature) → učitavanje povezanog Skill-a (opciono) → zamena Prompt šablona (zamena {{question}} stvarnim unosom) → kreiranje ChatClient-a preko ChatClientFactory → poziv LLM-a → izdvajanje rezultata i Token statistike.

Spring AI-ov ChatClient je jedinstveni ulaz za poziv LLM-a.

Bez obzira na to da li je podrenderer Qwen ili DeepSeek, kod na gornjem sloju je potpuno isti — chatClient.prompt().system(systemPrompt).user(userPrompt).call().chatResponse(). ChatClientFactory na osnovu provider-a bira različitu Model implementaciju i izlaže jedinstveni interfejs.

Na intervju možeš reći: "Naš LLM čvor je zasnovan na Spring AI-ovom ChatClient-u sa jednim slojem apstrakcije, podrškom za prebacivanje više provajdera preko fabričkog patterna, uz zadržavanje streaming sposobnosti, frontend renderuje u realnom vremenu preko SSE-a."

08,Prebacivanje između DAG i LangGraph dual engine-a

WorkflowExecutor je jedinstveni interfejs, koji i DAGWorkflowEngine i LangGraphWorkflowEngine implementiraju.

EngineSelector na osnovu polja engineType iz Workflow entiteta radi distribuciju — "dag" ide na stari engine, "langgraph" na novi engine, ako se ne pronađe podrazumevano se vraća na DAG.

Spring automatski ubacuje sve implementacije, tipičan strategija pattern.

Zašto zadržati oba engine-a?

Jer za jednostavne linearne radne tokove DAG engine je dovoljan, topološko sortiranje sa redoslednim izvršenjem, logika je jednostavna i performanse su dobre.

Vrednost LangGraph engine-a dolazi do izražaja u scenarijima koji zahtevaju uslovne grane i petlje — na primer "ako kvalitet odgovora LLM-a nije dovoljan, generiši ponovo", ili "na osnovu namere korisnika rutiraj na različite grane obrade". Ovi scenariji DAG ne može da odradi, jer DAG ne dozvoljava cikluse.

Ovaj dizajn se na intervjuu zove strategija pattern + backward kompatibilnost. Nove funkcije koriste novi engine, stare funkcije se ne prisiljavaju na nadogradnju, sa glatkim prelazom.

09,Sistem događaja

Kada se radni tok pokrene, kako frontend zna "gde je sada stigao"?

PaiAgent rešava ovaj problem preko callback događaja + SSE.

Svaki čvor okida događaj pre i posle izvršenja:

Frontend u realnom vremenu prima ove događaje preko SSE, na platnu ističe čvor koji se trenutno izvršava i prikazuje vreme i izlaz svakog čvora.

GET /api/workflows/{id}/execute/stream?inputData=...

→ WORKFLOW_START
→ NODE_START (input-1)
→ NODE_SUCCESS (input-1, 2ms)
→ NODE_START (qwen-1)
→ NODE_PROGRESS (qwen-1, "Generisanje...")
→ NODE_PROGRESS (qwen-1, "Generisanje...")
→ NODE_SUCCESS (qwen-1, 1523ms)
→ NODE_START (output-1)
→ NODE_SUCCESS (output-1, 1ms)
→ WORKFLOW_COMPLETE (SUCCESS, 1527ms)

10,Pokreni jedan radni tok

Prvi korak, kreiraj radni tok

Poseti PaiAgent frontend http://localhost:5173, kreiraj novi radni tok, za tip engine-a izaberi LangGraph.

Na platno ubaci tri čvora:

  • Input čvor
  • DeepSeek V4 LLM čvor (konfiguriši API Key i model)
  • Output čvor

Po redosledu ih poveži: Input → DeepSeek V4 → Output.

U konfiguraciji DeepSeek V4 čvora, Prompt neka bude:

Odgovori na sledeće pitanje, traži se sažet i dubok odgovor: {{input}}

U responseContent Output čvora napiši:

{{output}}

Drugi korak, izvrši radni tok

U polje za unos upiši:

Koja je razlika između LangGraph4j i LangChain4j? Objasni na nivou arhitekture.

Klikni "Pokreni".

Videćeš kako se čvorovi redom ističu, dok se DeepSeek V4 čvor izvršava ima streaming izlaz, a konačno Output čvor sažima rezultat.

Treći korak, posmatraj zapise izvršenja

Nakon završetka izvršenja pregledaj zapise izvršenja, za svaki čvor se može videti:

  • Ulaz i izlaz
  • Vreme izvršenja
  • Potrošnja Tokena (ulazni Token / izlazni Token / ukupno Token)

11,LangGraph4J intervju, deset pitanja i deset odgovora

Pomažem vam da sastavim 10 pitanja sa intervjua visoke frekvencije, odgovori su u verziji za usmeno izlaganje, naučite ih napamet i možete ih koristiti.

Q1: Kakav je odnos između LangGraph4j i LangChain4j? Možeš li u jednoj rečenici da objasniš?

A: LangChain4j brine o "kako pozvati model", LangGraph4j brine o "kako orkestrirati više poziva".

LangChain4j pruža jedinstven ChatClient, registraciju Tool-a, Embedding skladište, RAG pretragu — tu osnovnu infrastrukturu.

LangGraph4j se nadograđuje na to, povezujući više Agent čvorova u grafikon stanja, uz podršku za uslovne grane i petlje.

Njih dvojica nisu u odnosu zamene, već u odnosu gornji-donji sloj. U PaiAgent projektu, Spring AI igra ulogu LangChain4j-a, zadužen za pozive modela na donjem sloju, dok LangGraph4j upravlja orkestracijom radnih tokova na gornjem sloju.

Q2: Koji je model izvršenja StateGraph-a? Koja je razlika u odnosu na običan DAG?

A: StateGraph je usmereni grafikon, podržava cikluse.

Nakon kompajliranja postaje nepromenljiv CompiledGraph, pri izvršenju polazi od START i duž grana redosledno izvršava čvorove.

Svaki čvor prima trenutno stanje, obrađuje ga i vraća novo stanje.

Običan DAG ne dozvoljava cikluse, može samo topološki sortirati i izvršavati redom. Ključna prednost LangGraph4j-a je upravo tu — podrška za uslovne grane radi rutiranja u toku rada, podrška za petlje. To omogućava ReAct mod (razmišljanje → poziv alata → ponovno razmišljanje). DAG to ne može.

Q3: Šta je AgentState? Zašto se ne koriste parametri metode za prenos vrednosti?

A: AgentState je suštinski Mapa, to je kontejner globalnog stanja koji svi čvorovi dele.

Ne koriste se parametri metode zato što je topologija grafikona utvrđena prilikom kompajliranja, ali je putanja kojom se ide u toku rada dinamička — uslovne grane mogu preskočiti neke čvorove.

Ako bi se koristili parametri metode, preskočeni čvorovi ne bi mogli da proslede vrednosti kasnijim čvorovima. Sa deljenim stanjem tog problema nema — bilo koji čvor može pročitati podatke koje je upisao bilo koji prethodnik. U našem projektu je dogovoreno da currentInput radi lančani prenos, a nodeOutputs globalnu arhivu, i ta dva načina se međusobno dopunjuju.

Q4: Kako se koriste uslovne grane? Navedi praktičan scenario.

A: Suština uslovne grane je EdgeAction — ona prima trenutno stanje, vraća string za rutiranje, a framework na osnovu tog stringa odlučuje kojom granom ide.

Praktičan scenario je "provera kvaliteta" — nakon što LLM generiše tekst, Quality čvor ocenjuje skor kvaliteta, ako je ispod praga, rutira nazad na LLM čvor radi ponovnog generisanja, a ako je zadovoljavajući, rutira na Output čvor za izlaz.

Ovo je jedna petlja, koju DAG ne može da odradi. Još ima ReAct mod — Agent ocenjuje da li treba da pozove alat, ako da, rutira na tool_executor, nakon izvršenja se vraća da nastavi razmišljanje.

Q5: Kako poslovnu logiku integrišete u LangGraph4j?

A: Adapter pattern.

Poslovni sloj ima jedan set NodeExecutor interfejsa, svaki tip čvora (Input, Output, razni LLM) posebno implementira execute metodu, brine samo o ulazu i izlazu.

U sredini je jedan sloj NodeAdapter koji umotava NodeExecutor u AsyncNodeAction koji LangGraph4j zahteva. Adapter je zadužen za izdvajanje currentInput iz AgentState, pozivanje executor-a i upisivanje izlaza u novo stanje. Prednost ovoga je: ako budemo menjali engine za orkestraciju, svi NodeExecutor-i se ne moraju menjati nijednom linijom.

Q6: Koju ulogu Spring AI igra u projektu? Kako se kombinuje sa LangGraph4j?

A: Spring AI je zadužen za sloj pozivanja modela — pruža jedinstveni ChatClient interfejs, bez obzira na to da li je podrenderer Tongyi Qianwen, DeepSeek ili OpenAI, kod na gornjem sloju je potpuno isti.

Naš ChatClientFactory na osnovu parametra provider bira različitu Model implementaciju i izlaže jedinstveni interfejs.

LangGraph4j je na višem sloju, njega ne zanima kako se model zove, već samo kako između čvorova teče. Njihovo presečno mesto je LLM čvor — LangGraph4j prosleđuje stanje LLM čvoru, koji interno koristi Spring AI-ov ChatClient da pozove model, a dobijeni rezultat upisuje nazad u stanje.

Q7: Za razvoj AI aplikacija u Javi, koje su prednosti u odnosu na Python? Zašto ne koristiti direktno Python?

A: Ključni stav u jednoj rečenici: doba AI-ja je osnaživanje postojećih sistema, ne rušenje i ponovna izgradnja.

Ogromna većina enterprise aplikacija u zemlji — e-commerce, finansije, ERP, CRM — napisana je u Javi. Onima ne treba da se u Pythonu prepisuju od nule, već da se na postojećoj arhitekturi doda AI sposobnost.

Prednost Jave je: zreo enterprise ekosistem (Spring Boot, mikroservisi, distribuirane transakcije), kompletan sistem tipova i provere pri kompajliranju, lakše upravljanje velikim inženjeringom.

Python je jak u brzom prototipiranju i istraživanju algoritama, Java je jaka u ugradnji AI sposobnosti u produkcione sisteme. Njih dvoje se ne sukobljavaju, scenariji su različiti.

Q8: Šta novo treba da nauče Java developeri u doba AI-ja?

A: Tri pravca.

Prvo, Spring AI — ovo je zvanični AI integracioni framework Spring-a, već je izašao iz GA fase, ujednačio je interfejs za pozive različitih modela, podržava Function Calling, RAG, streaming izlaz.

Drugo, LangGraph4j — kada posao zahteva višekoračnu saradnju Agenata, uslovno rutiranje i petlje sa ponovnim pokušajem, potrebne su sposobnosti orkestracije grafikonom.

Treće, MCP protokol — standardizovani protokol koji omogućava Agentu da poziva eksterne alate, na Java strani ima kompletnu server/client implementaciju.

Da sumiramo: sloj za pozive koristi Spring AI, sloj za orkestraciju koristi LangGraph4j, sloj alata koristi MCP. Ova tri sloja zajedno omogućavaju Java developerima da izgrade kompletnu AI Agent aplikaciju.

Q9: Kako se prebacuje vaš dizajn sa dva engine-a (DAG + LangGraph)?

A: Strategija pattern.

WorkflowExecutor je jedinstveni interfejs, koji i DAGWorkflowEngine i LangGraphWorkflowEngine implementiraju.

EngineSelector na osnovu polja engineType iz Workflow entiteta radi distribuciju — "dag" ide na stari engine, "langgraph" na novi engine.

Stari radni tokovi ne menjaju engineType, podrazumevano nastavljaju sa DAG; novi radni tokovi biraju LangGraph engine. Razmišljanje iza ovoga je: jednostavni linearni tokovi sa DAG-om su dovoljni, performanse su dobre, logika jasna. Složeni scenariji koji zahtevaju uslovne grane i petlje koriste LangGraph. Migracija bez koristi stvara samo rizik.

Q10: Ako bi trebalo od nule da dizajniraš AI engine za radne tokove, kako bi to uradio?

A: U četiri sloja.

Najdonji sloj je sloj za pozive modela, sa Spring AI se ujednačavaju interfejsi svih LLM provajdera.

Drugi sloj je sloj za izvršenje čvorova, svaki tip čvora implementira sopstvenu execute metodu, brine samo o ulazu i izlazu.

Treći sloj je sloj za orkestraciju, gde se sa LangGraph4j-ovim StateGraph definiše struktura grafikona, a NodeAdapter radi most.

Najviši sloj je API sloj, koji pruža REST interfejs i SSE tok događaja, kako bi frontend mogao vizualno da uređuje i prati u realnom vremenu.

Ključna dizajnerska odluka je: odvajanje sloja za orkestraciju od sloja za izvršenje, most se pravi preko adapter patterna. Na taj način se svaki sloj može nezavisno zameniti — promena modela ne utiče na orkestraciju, promena engine-a za orkestraciju ne utiče na poslovne čvorove.