Embabel 1.0 lar planleggeren finne veien i stedet for grafen du tegner
Slipper Embabel 1.0, et Java- og Kotlin-rammeverk der du deklarerer mål og typede handlinger og lar en planlegger finne veien i stedet for å tegne grafen selv.
LangGraph ber deg tegne grafen på forhånd: noder er funksjoner, kanter er rutingen mellom dem, og du bestemmer hvilke overganger som finnes før agenten kjører. Embabel snur på det. Du oppgir et sett typede handlinger med forutsetninger og effekter, og en planlegger søker i kjøretid etter en sekvens som oppfyller målet. Rammeverket nådde 1.0.0 GA da utgivelsen ble merket på GitHub 20. juli, melder InfoQ.
Planleggingen låner en idé fra spill-KI som heter Goal-Oriented Action Planning. Poenget er hva som skjer når verden endrer seg midt i oppgaven. Feiler et verktøykall, eller dukker det opp ny informasjon, kan planleggeren vurdere på nytt og finne en annen vei, i stedet for å velte fordi den grenen ikke var tegnet inn på forhånd. Embabel kan også kombinere GOAP-planlegging med eksplisitte tilstandsmaskiner i samme agent, så du kan beholde fast ruting der du faktisk vil ha det.
Embabel erstatter ikke Spring AI, men bygger på det. Prosjektet er co-skapt av Rod Johnson, mannen bak Spring Framework og Spring MVC i 2003, og analogien kommer fra prosjektets egen README.
«Spring AI eksisterer på nivå med Servlet-APIet, mens Embabel er mer som Spring MVC» — fra Embabels README, gjengitt av InfoQ
Sammenligningen bærer et konkret løfte. Rå servletter fungerer, men hver applikasjon ender med å løse de samme problemene på nytt: parse parametere, dispatche til riktig handler, konvertere objekter til og fra HTTP. Spring MVC fjernet ikke servlettene, den la seg oppå og lot deg skrive en typet metodesignatur i stedet. Embabel gjør samme veddemål for agenter: Spring AI snakker med modellen, Embabel er laget der du erklærer målene og de typede handlingene.
Fordi det ligger på Spring AI, arver Embabel modellstøtten derfra: OpenAI, Anthropic, Gemini, Bedrock, Mistral og DeepSeek, pluss lokalt og selvhostet via Ollama, Docker eller et OpenAI-kompatibelt LMStudio-endepunkt. Valget tas ikke én gang for hele agenten. Du kan feste en enkelt handling til en bestemt modell, eller definere rollealiaser i konfigurasjonen, en «best» for stegene som trenger sterk resonnering og en «cheapest» for rutinen, og la handlingen referere rollen. Én agent kan dermed rute hvert steg dit kostnad, personvern eller kapabilitet tilsier.
Konkurrentene plasserer strukturen ulike steder. Akkas agentplattform bygger på aktormodellen: agenten lever som en aktor med egen isolert tilstand og postkasse, overvåket av et hierarki som kan starte den på nytt etter krasj og distribuere den over et cluster. JetBrains' Koog satser på Kotlins egne språkfunksjoner. Embabel satser på typesystemet, Akka på kjøretiden, Koog på språket. Repoet står i dag med 3 888 stjerner og er skrevet i Kotlin.
For deg som allerede kjører Spring Boot er dette punktet der Embabel går fra å være et prosjekt å følge med på til et du kan vurdere i praksis.
Hva bør du gjøre?
- Har agenten din mange betingede grener du har måttet forutse manuelt, er det der GOAP-planlegging betaler seg. Er flyten lineær og forutsigbar, gir en graf mindre overhead.
- Test rollealiasene tidlig: å kunne rute ett dyrt resonneringssteg til en sterk modell og resten til en billig er den enkleste kostnadsgevinsten i rammeverket.
- Ollama- og LMStudio-støtten arves fra Spring AI, så du kan prototype hele planleggingsløkka lokalt uten å betale per token.
KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.