Python ist nur die Vorfreude, die JVM ist das Hauptgericht. Eclipse präsentiert ein neues Open-Source-Konzept, um Agents auf K8s ohne Stackwechsel zu implementieren.

In jüngster Zeit hat die Eclipse Foundation angekündigt, die "Agent Definition Language" (ADL) auf ihrer Open-Source-Plattform Eclipse LMOS einzuführen. Dies ist eine strukturierte, modellunabhängige Beschreibungsweise, die es Benutzern ermöglicht, AI-Verhalten zu definieren, ohne Code schreiben zu müssen.

Laut Eclipse wird die ADL eine Kernkomponente der intelligenten Agenten-Computing-Plattform LMOS. Das Projekt LMOS zielt von Anfang an darauf ab, nativ auf Kubernetes / Istio zu laufen und die JVM-Ökosystem zu bedienen. Es zielt darauf ab, die Entwicklung und das Betriebsmanagement von Unternehmens-AI-Agenten auf eine einheitliche und offene Weise neu zu gestalten. Gleichzeitig ist es auch ein Gegenentwurf zu proprietären Plattformen und der hauptsächlich auf Python basierenden Unternehmens-AI-Technologie-Stack. Dies bedeutet auch eine direkte Herausforderung an die langjährig dominierenden proprietären Alternativen in der Unternehmens-AI.

Es ist bemerkenswert, dass das Projekt LMOS einen Ansatz verfolgt, bei dem es zunächst in die Praxis umgesetzt und erst später als Open-Source-Projekt veröffentlicht wird. Seine Vorgängerversion war eine produktionsreife Praxis der Deutschen Telekom in der traditionellen Cloud-Native-Architektur und wurde erst später in der Eclipse Foundation weiterentwickelt.

Vollständige Open-Source-Adresse des Projekts: https://github.com/eclipse-lmos

1  Technologische Konvergenz: AI auf vertrautem Technologie-Stack 

In den letzten zehn Jahren hat sich in der Unternehmenswelt ein erfolgreiches Engineering-Paradigma für Cloud-Anwendungen entwickelt: Statt Monolithanwendungen zu schreiben, werden Anwendungen möglichst in Microservices aufgeteilt, sodass verschiedene Teams für verschiedene Teile verantwortlich sind und die Komponenten einfach kombiniert werden können. Gleichzeitig werden alle Komponenten in Container verpackt, um die Migration und Bereitstellung in verschiedenen Umgebungen zu erleichtern. Bei steigendem Datenverkehr können auch durch die Replikation von Instanzen die Kapazitäten horizontal skaliert werden, sodass mehrere Kopien gemeinsam Anfragen und Berechnungen verarbeiten können. Dies ist in etwa die aktuelle Praxis bei der Entwicklung von Cloud-Anwendungen und funktioniert ziemlich gut.

Dann kam die generative AI. In den letzten zwei Jahren mussten die Menschen scheinbar immer wieder "eine Reihe neuer Fähigkeiten lernen", um die neuen Technologien nutzen zu können. Rückblickend auf das Jahr 2023: Auf GitHub tauchen ständig neue Frameworks auf, und viele Menschen zögerten, diese zu nutzen (damals war Spring AI noch nicht aufgetaucht und LangChain4j war erst in den Anfängen). Aber eigentlich war die größte Herausforderung immer, wie man die Entwicklungsgeschwindigkeit erhöhen und die vorhandenen Ressourcen effizient nutzen kann.

Angesichts der bestehenden Technologie-Ökosysteme, insbesondere für Unternehmen, die tief in das JVM-System eingebunden sind, ist es eigentlich nicht notwendig, "alles von vorne zu beginnen" und ein neues, teures Team zusammenzustellen. Daher ist das Ziel des LMOS-Projekts, zu untersuchen, wie man die AI-Fähigkeiten so nah wie möglich an den bereits vertrauten Technologie-Stack heranbringt, anstatt Unternehmen zu zwingen, ihre bestehenden Ergebnisse zu verwerfen und Python-Skripte zu schreiben und alles von Grund auf neu aufzubauen.

Wir können die Erfahrungen der letzten zehn Jahre nicht einfach wegwerfen und dann "ein neues Team zusammenstellen und einen ganzen neuen Technologie-Stack einführen".

Das LMOS-Projekt steht in Zusammenhang mit diesen Umständen. Das Projekt wurde 2023 von Arun Joseph, dem Projektverantwortlichen, gestaltet. Damals war er für ein AI-Projekt der Deutschen Telekom verantwortlich, bei dem die AI-Fähigkeiten für Vertrieb und Kundenservice in zehn europäischen Ländern eingeführt werden mussten.

"Als wir begannen, waren zwar einige Frameworks wie LangChain aufgetaucht, aber alle waren in Python geschrieben", erklärt Joseph. "Aber wie die meisten Telekommunikationsunternehmen und Unternehmen insgesamt basiert der gesamte Unternehmens-Technologie-Stack der Deutschen Telekom auf der JVM."

Außerdem ist die Komplexität der operativen Geschäftsprozesse der Deutschen Telekom an sich sehr hoch: Ein und dasselbe System muss in mehreren Ländern deployed werden und muss flexibel an verschiedene Kanäle (Web, App, Hotline usw.) angeschlossen werden können. Gleichzeitig ist das API-System sehr umfangreich, und die Client-Bibliothek enthält Hunderte von Attributen und jahrelange Fachkenntnisse. Wenn man es in Python von vorne beginnen würde, würde man die bestehenden Vermögenswerte aufgeben und das Team zwingen, das System von Grund auf neu aufzubauen.

Darüber hinaus muss die technologische Architektur für den Betrieb in zehn Ländern eine "plattformbasierte, zentrale" einheitliche Bereitstellung und Verwaltung unterstützen. Angesichts dieser Überlegungen hat das Team beschlossen, im vertrauten Ökosystem zu evolvieren: Es wurde Kotlin verwendet, um die bestehenden Infrastrukturen, APIs und DevOps-Fähigkeiten wiederzuverwenden und eine Plattform für mehrere intelligente Agenten aufzubauen.

Die Plattform basiert auf Kubernetes und nutzt die von Komponenten wie Istio angebotenen Funktionen, um die "Agenten / Tools" in Form von Microservices in einer K8s-Umgebung bereitzustellen und durch benutzerdefinierte Ressourcen (CRD) zu ersten Klasse Objekten zu machen, um die deklarative Verwaltung und die Beobachtbarkeit zu unterstützen.

Auf diese Weise können die Entwickler den bestehenden Arbeitsablauf beibehalten: Sie müssen nur ein Image eines intelligenten Agenten hochladen, und dann können sie ihn in einer neuen Umgebung ausführen und unabhängig testen. Das Betriebsteam kann direkt mit kubectl get agents und kubectl apply überwachen und veröffentlichen.

Deshalb geht Eclipse LMOS in der Philosophie von der derzeit vorherrschenden AI-Tools-Ökosystem ab. Joseph weist darauf hin, dass viele "Unternehmens-AI-Technologie-Stacks" oft eine Python-Code-Bibliothek sind, die mit den SDKs von von Risikokapital geförderten Start-ups zusammengefügt wird - jede dieser Komponenten löst nur ein kleines Problem wie Telemetrie, Gedächtnis, Bewertung usw. - und dann wird alles mit einem Dekorator in die Infrastruktur eingebunden. "Ich habe einige Bewertungstools gesehen, die für eine Funktion 25 Container benötigen", sagt er. "Das bedeutet, dass für eine Codezeile 25 Container einen benutzerdefinierten Kubernetes-Operator ausführen. Unternehmen können sich diese ungeordnete Expansion nicht leisten."

Der Ansatz von Eclipse LMOS vermeidet diese Probleme: Es integriert sich nativ in Kubernetes, Istio und JVM-basierte Anwendungen und passt sich nahtlos in die über Jahre hinweg aufgebauten DevOps-Prozesse, Beobachtungstools und API-Bibliotheken der Organisationen ein, sodass die AI-Agenten mit minimalem Migrationsaufwand in die Produktionssysteme integriert werden können.

Diese Plattformen unterstützen bereits mehrere AI-Anwendungen der Deutschen Telekom, darunter den mehrfach ausgezeichneten Kundenservice-Roboter Frag Magenta. Ende 2023 wurde der erste Agent in der Deutschen Telekom in die Produktion eingeführt und in Europa beschleunigt erweitert: Die Reichweite stieg von 3 - 4 Ländern auf 10 Länder, und nach der Einführung wurden monatlich durchschnittlich etwa 4,5 Millionen Gespräche bearbeitet. Im Jahr 2024 sank die Anzahl der Überleitungen an Menschen um 38 %. Somit ist es eines der größten und tatsächlich in der Produktion eingesetzten Agent-Systeme in Europa.

Durch die Verwendung des vertrauten Technologie-Stacks konnte auch die Entwicklungszeit verkürzt werden: "Es hat zunächst einen Monat gedauert, um den ersten Agenten zu entwickeln (währenddessen wurde auch die Plattform aufgebaut). Anschließend konnte die Zeit mit der Beteiligung weniger Ingenieure auf 15 Tage reduziert werden. Später konnte man in ein oder zwei Tagen einen Agenten zusammen mit einem Satz von Testfällen entwickeln."

"Nach einer gewissen Zeit haben wir festgestellt, dass es mit einem Data Scientist und einem Ingenieur in Paararbeit sehr schnell von der Idee oder Problembeschreibung des Geschäfts bis zur Bereitstellung des Agenten in der Produktion gehen kann. Auch in der Wartungsphase kann schnell iteriert werden, und das kleine Team bringt auch deutliche Kostenvorteile. Wir haben uns am Anfang nicht darum gekümmert, ob wir frühzeitig AI/ML-Ingenieure oder Data Scientists einstellen sollten - viele Teams haben in den Jahren 2023 und 2024 viel Zeit mit solchen Entscheidungen verschwendet."

Im Jahr 2024 hat das Team die proprietären Codes der Deutschen Telekom in die Eclipse Foundation überführt und als Open-Source-Projekt veröffentlicht. Das Projekt wird unter der Apache-2.0-Lizenz vertrieben.

2  Wie man die besten Aspekte klassischer Bereiche in einer Plattform integriert 

Bei der Einführung von AI-Agenten in die Unternehmensproduktion hat Eclipse eine "Doppelstrategie" gewählt. Eine Strategie betrifft die LMOS-Plattform (die bereits vollständig als Open-Source-Projekt verfügbar ist). Die andere Strategie ist noch bahnbrechender: ADL (Agent Definition Language), "um es mehr Menschen zu ermöglichen, tatsächlich Agenten zu schreiben".

"Wir waren mit den damaligen Frameworks insgesamt 'unzufrieden', also haben wir einen 'radikal vereinfachenden' Ansatz gewählt: Wir haben Kotlin als Hauptsprache ausgewählt, weil es uns erleichtert, eine domänenspezifische Sprache (DSL) zu entwickeln - nämlich die ADL."

"Es ist von entscheidender Bedeutung, dass die geschäftlichen Hintergründe in den Arbeitsablauf und die Anwendungen der Künstlichen Intelligenz integriert werden, damit sie in großem Maßstab hochwertige Entscheidungen treffen können. Natürliche Sprachhinweise können nicht versioniert oder auditiert werden - dies ist das Problem, mit dem Unternehmen konfrontiert sind, und der Grund, warum Programmiersprachen existieren - daher kann dieser Ansatz die Bedürfnisse zwischen diesen beiden Extremen befriedigen."

Dieser Ansatz geht auch auf Probleme in der Praxis zurück. In der realen AI-Infrastruktur werden Agenten, Hinweise (Prompts) und Tools Schicht für Schicht übereinander gelegt, und die Komplexität steigt schnell an. Dasselbe Muster wird in verschiedenen Szenarien immer wieder neu entwickelt. Noch wichtiger ist, dass das System im Wesentlichen immer noch von natürlicher Sprache angetrieben wird - eine Vielzahl von Bedingungen, Regeln und SOPs müssen auf dem Modell ausgeführt werden. Interessanterweise sind die Märkte bereits von diesen Produkten überschwemmt. Betrachtet man sie einzeln, sind sie alle großartig, aber wenn man sie zu einem vollständigen System zusammenfügt, ist es schwierig, dass sie miteinander "sprechen" und "zusammenkleben".

Und wenn das System einmal wächst, wird die Integration von AI-Modellen äußerst empfindlich. Eine leichte Aktualisierung oder ein kleiner Unterschied im Modell kann die oberen Verhaltensweisen so stark beeinflussen, dass das gesamte System instabil wird (wie in der folgenden Abbildung gezeigt).

Am Ende besteht diese Plattform aus drei voneinander unabhängigen, aber kooperierenden Modulen:

ADL: Strukturiert, modellunabhängig, unterstützt die visuelle Erstellung und die Zusammenarbeit zwischen verschiedenen Rollen, sodass das Geschäfts- und das Ingenieurteam gemeinsam Agenten schreiben können. Sie ermöglicht es dem Geschäftsbereich, das Verhalten von Agenten genauso zu definieren wie SOPs, sofort zu testen und zu iterieren, ohne auf die Bearbeitung eines Ingenieurauftrags warten zu müssen. Gleichzeitig behält die ADL die Ingenieurstrenge bei: Das Verhalten kann versioniert, nachverfolgt und gewartet werden, was auch der Schlüssel ist, warum sie die traditionelle Prompt-Engineering ersetzen kann.

ARC Agent Framework: Basierend auf JVM/Kotlin, bietet es eine Entwicklungsumgebung auf IDE-Ebene und visuelle Debugging-Möglichkeiten, sodass die Ingenieure sich auf die Geschäfts-APIs und die Integrationslogik konzentrieren können, anstatt sich um die untere Ebene zu kümmern.

LMOS-Plattformschicht: Eine offene Cloud-Native-Orchestrierungsschicht für die Verwaltung des Lebenszyklus von Agenten, die Entdeckung, die semantische Routing und die Beobachtbarkeit. Sie basiert auf dem Technologie-Stack der Cloud Native Computing Foundation (CNCF) und befindet sich derzeit in der Alpha-Version.

Um diese Module herum bietet LMOS auch eine Steuerungsebene (Control Plane), die eng mit der Laufzeitumgebung integriert ist: Wenn ein Agent oder ein Tool in Form eines Microservices in Kubernetes bereitgestellt wird, ist der LMOS-Operator für die Verwaltung des Lebenszyklus verantwortlich. Bei jeder Installation einer neuen Anwendung erhält der Operator eine Ereignisbenachrichtigung, erfasst ihre Beschreibung und schreibt sie in die Kubernetes-Registrierung (derzeit als Speichermechanismus verwendet). Gleichzeitig bietet der Operator auch eine Directory-API aus dem Internet der Dinge, um zu ermitteln, welche Agenten derzeit in der Kubernetes-Umgebung installiert sind.

Hierbei ist auch das LMOS-Protok