Java-Entwickler bauen seit Jahrzehnten Enterprise-Anwendungen, aber wenn es um KI geht, wurde die Diskussion von Python dominiert. Spring AI ändert diese Situation. Es bringt die gleichen Muster, die wir von Spring kennen – Dependency Injection, Auto-Configuration, portable Abstraktionen – in die KI-Entwicklung.
Im Januar 2026 haben wir eine Beispielanwendung für einen Agenten entwickelt und möchten unsere Erkenntnisse aus dem Entwicklungsprozess teilen. Der KI-Agent führt Konversationen mit Memory, beantwortet Fragen aus internen Knowledge Bases, nutzt externe APIs und integriert sich mit bestehenden Microservices – alles läuft auf Amazon Bedrock. Wenn Kunden es selbst ausprobieren möchten, führt diese den Workshop Building AI Agents with Java and Spring AI [1] durch typische Herausforderungen von Generative AI Modellen und bietet Schritt-für-Schritt-Lösungen mit Code auf GitHub [2].
Das richtige Modell wählen
Bevor Code geschrieben wird, muss ein Modell ausgewählt werden. Amazon Bedrock gibt Zugriff auf Foundation Models von Anthropic, Amazon, Meta und anderen über eine einheitliche API. Die Wahl ist wichtig – sie beeinflusst, wie sich der Agent verhält, wie viel bezahlt werden muss und wie schnell er antwortet.
Einige Modelle verarbeiten nur Text, während multimodale Modelle wie Anthropic Claude und Amazon Nova 2 Bilder und PDFs analysieren und visuellen Kontext verstehen können. Wenn der Agent Spesenbelege verarbeiten oder Dokumente lesen soll, sind multimodale Fähigkeiten notwendig.
An dieser Stelle ist es wichtig, auf die Trade-offs zwischen Intelligenz, Geschwindigkeit und Kosten hinzuweisen:
- Anthropic Claude Opus funktioniert am besten, wenn Intelligenz die oberste Priorität ist: komplexe Aufgaben, die starke Reasoning-Fähigkeiten erfordern. Hier fällt klar die Wahl auf Qualität über Geschwindigkeit und Kosten.
- Anthropic Claude Haiku glänzt, wenn Geschwindigkeit am wichtigsten ist. Echtzeit-Benutzerinteraktionen oder High-Volume-Verarbeitung, wo die schnellstmöglichen Antworten benötigt werden.
- Anthropic Claude Sonnet trifft den Sweet Spot für die meisten Anwendungen – gute Intelligenz, angemessene Geschwindigkeit, überschaubare Kosten.
- Amazon Nova 2 Lite ist ein schnelles, kosteneffizientes Reasoning-Modell für alltägliche Workloads. Es bietet branchenführende Price Performance und hilft Unternehmen und Entwicklern, leistungsfähige, zuverlässige und effiziente Agentic-AI-Anwendungen zu entwickeln.
- Amazon Nova 2 Pro ist das intelligenteste Nova-Modell, konzipiert für hochkomplexe, mehrstufige Aufgaben wie Multi-Document-Analyse und Software-Migrationen.
Wir haben die Entwicklung mit Anthropic Claude Sonnet 4 begonnen und festgestellt, dass es gut für unseren Agenten-Use-Case funktioniert. Für die Produktion würden wir die tatsächliche Workload profilen und Nova 2 Lite in Betracht ziehen, wenn Kostenoptimierung wichtig wird.
spring.ai.bedrock.converse.chat.options.model=global.anthropic.claude-sonnet-4-20250514-v1:0
ChatClient: das Fundament
Das ChatClient Interface ist der Punkt, an dem in Spring AI alles zusammenkommt. Es ist eine einheitliche API für die Kommunikation mit KI-Modellen – ein Interface, das mit Amazon Bedrock, OpenAI, Azure OpenAI, Google Vertex AI oder lokalem Ollama funktioniert. Sie können die Entwicklung lokal mit Ollama starten (kostenlos, privat, keine API-Kosten), gegen OpenAI validieren und für die Produktion auf Amazon Bedrock deployen – gleicher Code, unterschiedliche Konfiguration.
Was ChatClient mächtig macht, ist das Advisor-Pattern. Advisors kümmern sich um Cross-Cutting Concerns wie Memory, Retrieval-Augmented Generation (RAG) und Logging, ohne Ihre Business-Logik zu überladen. Betrachten Sie sie als Middleware für KI-Konversationen – jeder Advisor fängt Requests und Responses ab, modifiziert Prompts oder verarbeitet Outputs.
So sieht unsere ChatClient-Konfiguration aus, nachdem wir alle Capabilities hinzugefügt haben:
this.chatClient = chatClientBuilder
.defaultSystem(DEFAULT_SYSTEM_PROMPT)
.defaultAdvisors(
MessageChatMemoryAdvisor.builder(chatMemory).build(),
QuestionAnswerAdvisor.builder(vectorStore).build()
)
.defaultTools(new DateTimeTools(), new WeatherTools())
.defaultToolCallbacks(mcpTools)
.build();
Eine Konfiguration gibt Ihnen Conversation Memory, RAG-gestützte Knowledge Retrieval, Custom Tools und Model Context Protocol (MCP) Integrationen. Die Advisor Chain läuft in Reihenfolge – Memory lädt die Historie, RAG ruft relevante Dokumente ab, dann trifft der angereicherte Prompt auf das Modell mit allen verfügbaren Tools.
Conversation Memory
Als wir unseren Agenten zum ersten Mal getestet haben, stellten sich Benutzer vor, stellten einige Fragen und fragten dann “Wie heiße ich?” – und der Agent hatte keine Ahnung. Jeder Request war quasi ein “leeres Blatt”. So funktionieren KI-Modelle: Sie sind zustandslos. Die Anwendung muss die Konversationshistorie verwalten und sie bei jedem Request zurückgeben.
Spring AI handhabt dies mit MessageChatMemoryAdvisor. Es kann ein Memory Store konfiguriert werden, dieser wird mit dem ChatClient verdrahtet und der Advisor lädt automatisch die Konversationshistorie vor jedem Request und speichert neue Nachrichten danach.
Für die Speicherung existieren unterschiedliche Optionen: InMemory für die Entwicklung, JDBC für die Produktion mit bestehenden Datenbanken, Redis für Distributed Caching, Cassandra für Scale. Wir haben uns für JDBC und PostgreSQL entschieden, da die meisten Spring-Anwendungen bereits eine relationale Datenbank haben, es muss also keine neue Infrastruktur verwaltet werden.
var chatMemory = MessageWindowChatMemory.builder()
.chatMemoryRepository(JdbcChatMemoryRepository.builder()
.dataSource(dataSource)
.dialect(new PostgresChatMemoryRepositoryDialect())
.build())
.maxMessages(20)
.build();
Für Produktionsanwendungen mit längeren Konversationen sollte eine dreistufige Memory-Architektur in Betracht gezogen werden: Session Memory für aktuelle Nachrichten (etwa 20), Context Memory für Konversationszusammenfassungen und Preferences Memory für Benutzerprofile. Dies gibt Benutzern Kontinuität, ohne Tokens für die vollständige Historie zu verbrennen. Wir haben dieses Pattern ausführlich dokumentiert [8], falls Kunden es implementieren möchten.
Es existiert auch einen einfacherer Weg, um auf Amazon Bedrock AgentCore [5] zu deployen. AgentCore bietet vollständig verwaltetes Memory – Event Memory für Konversationshistorie mit automatischer Retention und Semantic Memory für langfristige Knowledge Extraction. Es muss lediglich der spring-ai-bedrock-agentcore-starter [6] hinzugefügt werden und Memory funktioniert out of the box, kein Custom Code ist erforderlich.
Knowledge mit RAG
Wenn ein generisches KI-Modell nach den Reisekostenlimits eines bestimmten Unternehmens gefragt wird, gibt diese eine selbstbewusste, plausible und völlig falsche Antwort zurück. Das Modell halluziniert, weil es mit allgemeinen Trainingsdaten arbeitet, nicht mit Ihren tatsächlichen Dokumenten.
RAG (Retrieval-Augmented Generation) löst dies, indem es Antworten in echten Inhalten verankert. Während der Ingestion werden Dokumente in Chunks aufgeteilt, in Vector Embeddings konvertiert und gespeichert. Zur Query-Zeit wird die Frage des Benutzers zu einem Embedding, ähnliche Chunks werden durch Semantic Search abgerufen, und diese Chunks gehen als Kontext in den Prompt. Das Modell generiert Antworten basierend auf tatsächlichen Dokumenten, anstatt zu raten.
Die VectorStore-Abstraktion von Spring AI unterstützt PGVector, OpenSearch, Pinecone, Weaviate, Milvus und mehr. Wir haben PGVector verwendet, da wir bereits PostgreSQL für Memory hatten – also die gleiche Datenbank. Mit dieser Entscheidung vermeiden wir die Einführung zusätzlicher Services, was die Komplexität des Gesamtsystems unnötig erhöhen würde. Der QuestionAnswerAdvisor handhabt das Retrieval automatisch, sobald es konfiguriert ist:
spring.ai.bedrock.titan.embedding.model=amazon.titan-embed-text-v2:0
spring.ai.vectorstore.pgvector.initialize-schema=true
spring.ai.vectorstore.pgvector.dimensions=1024
Spring AI 2.0 bringt Unterstützung für Amazon Bedrock Knowledge Bases, ein vollständig verwaltetes RAG, bei dem AWS Document Chunking, Embeddings und Vector Storage handhabt. Sie verbinden S3, Confluence oder SharePoint als Datenquellen und erhalten erweiterte Features wie Hybrid Search (Kombination aus Semantic und Keyword Matching), Reranking und Metadata Filtering. Das gleiche QuestionAnswerAdvisor-Pattern funktioniert, nur mit einer anderen VectorStore-Implementierung. Wir haben eine Hands-on-Anleitung “RAG Made Serverless – Amazon Bedrock Knowledge Base with Spring AI” [9] geschrieben, falls Kunden es ausprobieren möchten.
Tools und MCP
Unser Agent konnte sich an Konversationen erinnern und Fragen aus Dokumenten beantworten, aber er konnte Benutzern nicht das Wetter für ihre Reise sagen oder nicht einmal, welcher Tag heute ist. KI-Modelle haben Knowledge Cutoffs – sie kennen nicht das heutige Datum, das aktuelle Wetter oder was in einer Unternehmensdatenbank ist.
Tool Calling überbrückt diese Lücke. Damit können Funktionen definiert werden, die die KI aufrufen kann und das Modell entscheidet basierend auf der Konversation, wann es sie verwendet. Die @Tool-Annotation von Spring AI macht dies unkompliziert:
@Tool(description = """
Get weather forecast for a city on a specific date.
Use for answering questions about weather forecasts.
""")
public String getWeather(
@ToolParam(description = "City name, such as Paris, London, New York") String city,
@ToolParam(description = "Date in YYYY-MM-DD format") String date) {
// Call weather API and return formatted result
}
Die Description ist wichtiger, als viele Kunden vielleicht erwarten. Die KI liest sie, um zu entscheiden, welches Tool sie mit welchen Parametern in welcher Reihenfolge aufruft. Vage Descriptions führen zu falscher Tool-Auswahl; präzise ermöglichen genaues autonomes Verhalten.
Für größere Systeme skaliert das Hardcoding jeder API in den Agenten nicht gut. Verschiedene Teams besitzen verschiedene Services mit eigenen Release-Zyklen. Sie möchten den Agenten nicht jedes Mal neu deployen, wenn das Booking-Team einen Endpoint hinzufügt.
Model Context Protocol (MCP) [7] standardisiert, wie Agenten Tools entdecken und verwenden. MCP Server stellen Tools über ein Standardprotokoll bereit; Clients entdecken sie zur Laufzeit. Der MCP Server Starter von Spring AI verwandelt bestehende Microservices in KI-zugängliche Tools: es muss lediglich die Dependency hinzugefügt und die Methoden mit @Tool annotiert werden und schon wird der Service zu einem MCP Server. Das Booking-Team pflegt seine Tools, HR pflegt seine, und der Agent entdeckt alles beim Startup ohne Code-Änderungen.
@Tool(description = """
Find flights between two cities.
Requires: departureCity - Name of the departure city,
arrivalCity - Name of the arrival city.
Returns: List of available flights sorted by price from lowest to highest.)
public List<Flight> findFlightsByRoute(String departureCity, String arrivalCity) {
return flightService.findFlightsByRoute(departureCity, arrivalCity);
}
Eine Sache, die wir gelernt haben: Agenten mit Tools haben oft große System Prompts und Tool Definitions, die mit jedem Request gesendet werden. Amazon Bedrock Prompt Caching (verfügbar für Anthropic-Modelle) reduziert Kosten, indem dieser wiederholte Content gecacht wird:
spring.ai.bedrock.converse.chat.options.cache-options.strategy=SYSTEM_AND_TOOLS
Eine sinnvolle Vorgehensweise ist die Strukturierung von Prompts mit stabilem Content zuerst (System Instructions, Tool Definitions) und benutzerspezifischem Content zuletzt. Cache Hits können die Kosten für die gecachten Teile erheblich reduzieren.
Deployment auf AWS
Spring AI Agenten sind Standard Spring Boot Anwendungen, die als Container Images gepackt werden. Sie laufen überall, wo Container laufen. Auf AWS haben existieren mehrere Optionen, abhängig davon, wie viel Infrastruktur Kunden verwalten möchten.
Amazon Elastic Kubernetes Service (Amazon EKS) gibt Ihnen Kubernetes-Flexibilität mit Amazon EKS Auto Mode, das Kubernetes Cluster Management für Compute, Storage und Networking auf AWS mit einem einzigen Klick vollständig automatisiert. Das ist eine gute Wahl, wenn Teams Kubernetes bereits kennen und feinkörnige Kontrolle über Networking und Scaling benötigt.
Amazon Elastic Container Service (Amazon ECS) bietet Serverless Container mit AWS Fargate. Amazon ECS Express Mode automatisiert Infrastructure Setup einschließlich Domains, Networking und Load Balancing – schlüsselfertiges Deployment, wenn Teams schnell starten möchten. Amazon ECS Managed Instances bieten mehr Kontrolle über Instance Types und Pricing (Spot, Reserved), während ECS das Provisioning übernimmt.
AWS Lambda funktioniert gut für Event-Driven Workloads mit sporadischen Traffic-Mustern, wo auf null skaliert werden soll.
Amazon Bedrock AgentCore ist eine vollständig verwaltete Agent Runtime mit integriertem Memory, Code Interpreter, Browser Tools, Gateway und Observability. Der Spring AI AgentCore Starter [6] bietet Adapter für das Ausführen von Spring AI Anwendungen auf Amazon Bedrock AgentCore mit nur einer Annotation @AgentCoreInvocation:
@Service
public class InvocationService {
@AgentCoreInvocation
public Flux<String> handleInvocation(InvocationRequest request, AgentCoreContext context) {
// Parse JWT, extract user identity for memory isolation
...
return chatService.chat(request.prompt(), sessionId);
}
}
AgentCore integriert sich mit Amazon Cognito für User Authentication (OAuth 2.0). JWT Tokens werden automatisch validiert, und User Identity fließt durch zu Ihrer Anwendung für Memory Isolation und Audit Logging. VPC Mode ermöglicht Zugriff auf Datenbanken und interne Services. IAM Roles bieten Least-Privilege Access zu Bedrock Models.
Der gleiche Spring AI Anwendungscode funktioniert über alle diese Deployment-Ziele hinweg. Der Unterschied liegt darin, wie viel Infrastruktur verwaltet werden soll versus wie viel AWS für Kunden übernehmen soll. Für den schnellsten Weg zur Produktion mit integrierten Agent Capabilities ist Amazon Bedrock AgentCore schwer zu schlagen.
Zusammenfassung
Spring AI gibt Java-Entwicklern vendor-neutrale Abstraktionen für den Bau von KI-Agenten – ChatClient für Model Access, ChatMemory für Stateful Conversations, VectorStore für RAG, Tools und MCP für Real-Time Data und Integrationen. Die Patterns fühlen sich vertraut an, wenn Teams zuvor mit Spring gearbeitet haben.
Die Modellauswahl ist wichtiger, als wir anfangs erwartet haben. Wir haben mit Anthropic Claude Sonnet begonnen und es hat gut funktioniert, aber das Profiling der tatsächlichen Workload hilft bei der Optimierung – Amazon Nova 2 Lite für kosteneffizientes Reasoning, Anthropic Claude Haiku für Geschwindigkeit, Anthropic Claude Opus, wenn Sie maximale Intelligenz benötigen.
Für das Deployment bietet Amazon Bedrock AgentCore den schnellsten Weg zur Produktion mit integriertem Memory, Security und Observability. Falls mehr Kontrolle benötigt wird, läuft der gleiche Code auf Amazon EKS, Amazon ECS oder AWS Lambda.
Wir hoffen, dass dies für die Leser einen guten Ausgangspunkt gibt. Der Workshop [1] führt durch alles im Detail, falls Kunden selbst hands-on Erfahrung mit den vorgestellten Services und Patterns sammeln möchten.
Referenzen:
[1] Workshop: https://catalog.workshops.aws/java-spring-ai-agents [2] GitHub: https://github.com/aws-samples/java-on-aws [3] Spring AI: https://docs.spring.io/spring-ai/reference/ [4] Amazon Bedrock: https://aws.amazon.com/bedrock/ [5] Amazon Bedrock AgentCore: https://aws.amazon.com/bedrock/agentcore/ [6] Spring AI AgentCore Starter: https://github.com/spring-ai-community/spring-ai-bedrock-agentcore [7] Model Context Protocol: https://modelcontextprotocol.io/ [8] Memory Implementation: https://dev.to/yuriybezsonov/a-practical-guide-to-building-ai-agents-with-java-and-spring-ai-part-2-add-memory-odn [9] Bedrock Knowledge Bases: https://dev.to/yuriybezsonov/rag-made-serverless-amazon-bedrock-knowledge-base-with-spring-ai-2dn9
Interessiert an KI-Agenten mit Java?
Yuriy Bezsonov & Sascha Möllering sind Speaker auf der JCON.
In diesem Artikel analysieren sie, wie sich produktionsreife KI-Agenten mit Java und Spring AI entwickeln lassen. Ihre JCON-Session demonstriert, wie KI zur Analyse und Optimierung der Java-Performance eingesetzt werden kann.
Falls Du die Session verpasst hast, kein Problem! Das Video zum Talk ist nach der JCON verfügbar.
