Der Ehrgeiz von Alibaba Cloud liegt nicht bei Agent Builder

In den letzten zwölf Monaten haben mehrere Cloud-Anbieter sehr ähnliche Maßnahmen ergriffen. Im August dieses Jahres hat Alibaba Cloud seine dienstbezogenen Fähigkeiten im Zusammenhang mit Agenten zu einer umfassenden All-In-One-Unternehmensplattform für den gesamten Agenten-Stack – Agent Studio – aufgerüstet und offiziell auf Alibaba Cloud Bailian eingeführt; Auf der Microsoft Build im Juni hat Microsoft Foundry seinen Fokus deutlich auf die Produktionsphase verlagert, wobei Funktionen wie Hosted Agents, Toolboxes und Memory schrittweise in die Plattform integriert wurden; Im April hat Google Cloud die Gemini Enterprise Agent Platform eingeführt, die die Funktionen Build, Scale, Govern und Optimize in einer einzigen Plattform zusammenfasst; Im Oktober vergangenen Jahres hat AWS mit Bedrock AgentCore Funktionen wie Runtime, Memory und Gateway zu einer Gruppe kombinierbarer Dienste aufgeteilt, sodass Entwickler nicht für jeden Agenten die Laufzeitbasis neu aufbauen müssen.

Einige große Unternehmen mit ausreichenden Ingenieurskapazitäten verfolgen ähnliche Ansätze. Im Juli dieses Jahres hat DoorDash, die größte amerikanische Plattform für Essenslieferungen, allgemeine Funktionen wie Memory, Modellzugriff und Tracing zu einer gemeinsamen Infrastruktur abstrahiert und eine spezielle Agent Gateway-Ebene aufgebaut, die Identitäten, Berechtigungen, Anmeldeinformationen, Ratenbegrenzungen und Audits beim Aufruf interner Tools durch Agenten zentral verwaltet.

Während die öffentliche Aufmerksamkeit meist darauf gerichtet ist, welche neuen Aufgaben Agenten erledigen können und welche beliebten Anwendungen neu erschienen sind, bemerken nur wenige, dass immer mehr Unternehmen große Ingenieurskapazitäten für Dinge aufwenden, die nicht besonders nach KI klingen.

Der Grund ist einfach: Alle stoßen auf die gleichen Probleme: Wenn die Anzahl der Agenten steigt, die Aufgaben länger werden und die Aufrufkette komplexer wird, reicht die bisherige Organisationsweise der Infrastruktur nicht mehr aus.

Noch interessanter ist, dass selbst Unternehmen, die Modelle entwickeln, diesem „Problem“ nicht ausweichen können. Im April dieses Jahres hat Anthropic selten eine „Nachbearbeitung“ der Agenten-Infrastruktur nachvollzogen: Anfangs wurden aus Gründen der Einfachheit Session, Agent Harness und Sandbox in dasselbe Container gepackt. Nach dem eigentlichen Start des Betriebs stellten sich jedoch Probleme bei der Fehlerisolierung, dem Speichern von Zuständen und der Netzwerkerweiterung ein, sodass die drei Komponenten schließlich wieder getrennt werden mussten.

Diese Nachbearbeitung verdeutlicht eines: Selbst wenn das Modell optimal entwickelt ist, fehlt nach dem eigentlichen Start des Betriebs der Agenten keine der erforderlichen Ingenieurskompetenzen. Aber die Frage ist, muss jedes Unternehmen diese Infrastruktur selbst neu aufbauen?

Der eigentliche Engpass liegt außerhalb des Modells

Wenn wir den Fokus auf die Ausführung einer konkreten Aufgabe durch einen Agenten richten, stellen wir fest, dass die eigentlichen Probleme meist außerhalb des Modells auftreten.

Im Juli dieses Jahres veröffentlichte McKinsey eine Umfrage zum Enterprise AI FinOps. Wenn Unternehmen von verstreuten KI-Anwendungsfällen zu einem breiteren Einsatz übergehen, steigen die gesamten KI-Ausgaben fast auf das Vierfache; 93 % der befragten Organisationen gaben an, dass die KI-Ausgaben das Budget überschritten haben. Die Boston Consulting Group hat im Juni dieses Jahres sogar speziell die Kostenfrage der Agentic AI erörtert. Sie unterteilt die Kosten in zwei Kategorien: Einmalige Aufbaukosten einschließlich Cloud-Zugriff und Netzwerkanbindung; zum anderen laufende Betriebskosten, die neben den Modellaufrufen auch von der Orchestrierungsart der Agenten, der Häufigkeit der Tool-Aufrufe, der Überwachungsintensität und der Systemintegrationsart beeinflusst werden.

Offensichtlich wird die Unternehmensrechnung bei tieferem Einsatz von Agenten immer schwerer allein mit der Angabe „wie viele Token aufgerufen wurden“ zu erklären. Berechnung, Speicherung, Datenzugriff, Tooldienste, Laufzeit und Betriebsverwaltung werden alle berechnet, und ein erheblicher Teil dieser Investitionen ist wahrscheinlich eine reine Ausgabe, die kaum direkte geschäftliche Vorteile bringt.

Das ist derzeit ein großes Problem für viele Unternehmen: Wie viele Dinge müssen Unternehmen selbst entwickeln, um Agenten einzusetzen? Derzeit gibt es in der Branche grob drei verschiedene Erprobungswege für diese Frage.

Der erste Weg ist der vollständige Eigenaufbau, bei dem Unternehmen ihre eigene Agenten-Plattform aufbauen. Ein typisches Beispiel ist das bereits erwähnte DoorDash, das in seinem im Juli dieses Jahres veröffentlichten technischen Artikel die Plattform hinter Ask DoorDash detailliert erläuterte: Geschäftsagenten für Bereiche wie Restaurant, Grocery und Reservations werden weiterhin von den jeweiligen Teams betreut, aber Funktionen wie Session State, Memory, Artifacts, Modellzugriff, Tracing, Evaluation und Rollout Controls, die jeder Agent wiederholt benötigt, werden einheitlich auf der Plattformebene zusammengefasst.

Der Schwerpunkt dieses Ingenieursprojekts liegt darin, den wiederholten Teil zwischen den Agenten so weit wie möglich zu beseitigen. DoorDash geht davon aus, dass es sich nur dann lohnt, eine Funktion zu einer öffentlichen Infrastruktur zu machen, wenn mehrere Geschäftsbereiche dieselbe Funktion benötigen und die separate Umsetzung durch einzelne Teams Zuverlässigkeits- oder Betriebsprobleme verursacht. Das Endergebnis ist deutlich sichtbar: Der Reservations Agent hat die Produktionsketten von Restaurant und Grocery wiederverwendet und konnte innerhalb einer Woche erfolgreich eingeführt werden, was die Geschwindigkeit um das Zehnfache steigerte; Jeder neue Agent nutzt die einheitliche Tracing-Funktion, wodurch fast ein Monat an Aufbauarbeiten für die Beobachtbarkeit eingespart werden kann.

DoorDash hat jedoch nicht offengelegt, wie viel Geld, Personal und Zeit für diese Plattform aufgewendet wurden, da die Plattform selbst ein Produkt ist, das kontinuierlich weiterentwickelt werden muss. Dieser Weg funktioniert für DoorDash zu einem großen Teil, weil es über genügend Agenten und ein starkes Ingenieursteam verfügt. Für die meisten Unternehmen ist es jedoch keine einfache Rechnung, erst ein Team für die Entwicklung der Agenten-Infrastruktur aufzubauen, nur um Agenten optimal einzusetzen. Daher bevorzugen mehr Unternehmen den zweiten Weg: Zuerst den Agenten mit einem Entwicklungsframework aufbauen.

In den letzten Jahren sind eine Reihe von Frameworks wie LangChain, LangGraph, Microsoft AutoGen und CrewAI erschienen, die viele ursprünglich von Entwicklern handgeschriebene Logik zu wiederverwendbaren Komponenten machen und die Hürden für den Aufbau von Agenten in Unternehmen senken. Der amerikanische Fahrdienstleister Lyft erwähnte in einem früher vorgestellten Fall zum Aufbau eines Kundenservice-Agenten, dass es mit LangGraph mehrere spezialisierte Agenten orchestriert und die Entwicklungszeit eines Agenten von etwa sechs Monaten auf wenige Wochen verkürzt hat.

Die derzeitigen Entwicklungsframeworks lösen jedoch hauptsächlich die ersten Probleme, die bei der Entwicklung von Agenten auftreten. Die Probleme nach dem eigentlichen Start des Betriebs der Agenten bleiben weiterhin ungelöst.

Aus diesem Grund neigen in den letzten zwölf Monaten viele Cloud-Anbieter, Unternehmenssoftwareplattformen, Datenplattformen und sogar Modellentwickler dem dritten Weg zu: der unternehmensweiten Agenten-Plattform. Neben den bereits erwähnten Anbietern AWS, Google und Microsoft hat Salesforce Agentforce 360 eingeführt, das Daten, Geschäftsprozesse und Agenten in einer einheitlichen Plattform zusammenfasst; Snowflake hat zudem Cortex Agents weiter ausgebaut und legt den Fokus auf Funktionen wie Build, Managed Runtime, MCP-Zugriff und Code-Ausführung.

In China wird dieser Weg ebenfalls zunehmend klar, ein typisches Beispiel ist Alibaba Cloud. Auf dem Alibaba Cloud Feitian Launch Event am 14. August zielt das neu vorgestellte Agent Studio darauf ab, die ursprünglich verstreuten Funktionen zu einer Dienstschicht rund um Agenten zu bündeln, sodass Unternehmen die Entwicklung von Agenten aus einer Hand erledigen und Agenten per Drag & Drop aufbauen können.

Noch diskutabler ist jedoch, wie viele der Ingenieurarbeiten und lästigen Aufgaben, die Unternehmen ursprünglich in jedem Agenten-Projekt wiederholt ausführen mussten, nicht mehr selbst erledigt werden müssen. Agent Studio bietet genau einen Ansatzpunkt für die Betrachtung.

Agent Studio ist bereits auf Alibaba Cloud Bailian verfügbar, der Zugangslink lautet: agent.console.aliyun.com

Welche „lästigen Aufgaben“ übernimmt Agent Studio für Unternehmen?

Nachdem der Agent tatsächlich mit der Arbeit begonnen hat, steigt die Anzahl der Punkte, um die sich Unternehmen kümmern müssen, deutlich an.

Wenn man die gesamte Kette von dem Aufbau eines Agenten bis zu seinem produktiven Einsatz auseinandernimmt, stellt man fest, dass der Betrieb nur die grundlegendste Fähigkeit darstellt. Das bedeutet aber nicht, dass diese Angelegenheit einfach ist.

Agenten unterscheiden sich von herkömmlichen Anwendungen und Chatbots: Sie können für eine einzelne Aufgabe mehr als zehn Stunden oder sogar mehrere Tage laufen, müssen währenddessen kontinuierlich Dateien lesen und schreiben sowie Tools aufrufen und sind in der Regel zustandsbehaftete Dienste. Die von Anthropic im April dieses Jahres durchgeführte Umstrukturierung, bei der Session, Agent Harness und Sandbox getrennt wurden, löste das Problem, dass der Zustand nicht mehr von einem einzelnen Ausführungscontainer abhängig ist.

Auf Cloud-Plattformen ist diese Art von Problem bereits zu einem direkt aufrufbaren Dienst geworden. Das Managed Agent in Agent Studio ist im Wesentlichen ein verwaltetes Agenten-Laufzeitumgebung. Entwickler müssen nur definieren, was der Agent tun soll, und die restlichen lästigen Aufgaben wie Betrieb, Isolierung, Zustandsverwaltung und Anmeldeinformationen können an Managed Agent übergeben werden.

Die Einsparung einer ganzen Reihe von Ingenieurarbeiten wirkt sich letztendlich auf die Geschäftsergebnisse aus: Mit dem gleichen Personalbestand können mehr Aufgaben bearbeitet werden, die Bereitstellungsgeschwindigkeit steigt und die Ergebnisse sind stabiler.

Am Beispiel der Prüfung von Versicherungsvertragsklauseln: Früher musste ein komplexer Versicherungsvertrag von Versicherungsprüfern selbst analysiert, mit den Klauseln abgeglichen, risikobewertet und konform geprüft werden. Nach der Kapselung als Managed Agent kann dieser Prozess in der Cloud kontinuierlich ausgeführt werden, und Mitarbeiter müssen nur die letzten zu bestätigenden Schlüsselpunkte bearbeiten. Laut den von Alibaba Cloud veröffentlichten Daten wurde die Prüfzeit von ursprünglich drei bis vier Stunden auf etwa 15 Minuten verkürzt, die Effizienz stieg um mehr als das Zehnfache, die Anzahl der Versicherungsverträge, die ein Prüfer pro Tag bearbeiten kann, hat sich mehrfach erhöht, und die Kosten für einen Versicherungsvertrag betragen nur 0,12 Yuan.

„Managed Agent wurde speziell für komplexe Aufgaben mit langer Laufzeit und vielen Schritten entwickelt, sodass Geschäftsgenten nicht nur kommunizieren, sondern tatsächlich produktiv arbeiten können“, so der Produktverantwortliche von Managed Agent. Hinter Managed Agent stehen fünf Ebenen von Funktionen: Die unterste Ebene ist die Laufzeitbasis, die Sitzungszustände, Sandbox, Tool-Ausführung, Ereignisprotokolle und Agent Harness gemeinsam verwaltet und die Fortsetzung von unterbrochenen Langzeitaufgaben unterstützt. Darüber liegt die Kontextverwaltung, die die dauerhafte Wiederverwendung von Dateien, Code-Repositories und sitzungsübergreifenden Erinnerungen ermöglicht. Weiter oben befindet sich die Toolebene, die externe Systeme über MCP und Skills einbindet und ausgereifte Prozesse zu wiederverwendbaren Funktionen kapselt. Die Sicherheitsebene ist für die Sandbox-Isolierung und die Verwaltung von Geheimnissen zuständig. Die oberste Ebene dient der Beobachtbarkeit und Integration, die den Ausführungsprozess der Agenten und die Tool-Aufrufe protokolliert und über Schnittstellen wie API und Deployment in Geschäftssysteme eingebunden wird.

Wenn man diese fünf Ebenen von Funktionen zusammen betrachtet, stellt man fest, dass die lästigsten grundlegenden Arbeiten beim Betrieb von Langzeitaufgaben durch Agenten bereits von Managed Agent verwaltet werden können. Das ist jedoch nur der erste Schritt: Nach dem Start des Betriebs der Agenten muss zudem das Problem der Anbindung von Tools gelöst werden.

MCP standardisiert einen Teil der Art und Weise, wie verschiedene Tools in Agenten eingebunden werden, beseitigt aber nicht vollständig die Anbindungskosten. Für die Einbindung jedes einzelnen MCP-Dienstes müssen Entwickler oft noch separate Konten registrieren, API-Schlüssel beantragen, die Authentifizierung durchführen und die Rechnungen getrennt verwalten. Bei einer großen Anzahl von Diensten werden die ursprünglich eingesparten Entwicklungsarbeiten leicht zu einer neuen Betriebslast.

Aus diesem Grund hat das im Rahmen des aktuellen Updates von Agent Studio eingeführte One Key Service-System schnell Diskussionen in der Fachgemeinschaft ausgelöst. Es zielt darauf ab, das echte „One Key All Server“ zu realisieren, sodass mit einem einheitlichen API-Schlüssel N verschiedene Authentifizierungsketten zu einer einzigen zusammengefasst werden können.

Laut Angaben von Alibaba Cloud sind in der ersten Phase von One Key MCP 14 Partner des Cloud-Marktes eingebunden, die Bereiche wie E-Commerce, Geoinformation, Finanzen, Recht, Industrieforschung und Logistik abdecken. In Kürze werden fast 50 MCP-Ökosystemdienstleister in das One Key Service-System aufgenommen. Später werden auch die zugehörigen Dienste von Agent Studio, die das A2A-Protokoll unterstützen, schrittweise in dieses System integriert.

Wenn One Key MCP das Problem der „Verbindungsmöglichkeit“ löst, dann löst das neu gestaltete Skill-System das Problem der „optimalen Nutzung“. Bei dem aktuellen Update unterteilt Agent Studio die Skills in drei Ebenen: streng ausgewählte Angebote aus dem Skill-Markt, Direktlieferungen von Dienstanbietern und benutzerdefinierte Skills. Allgemeine Funktionen können direkt verwendet werden, Branchendienstanbieter können MCP zusammen mit Prompts, Aufrufbeispielen und bewährten Verfahren kapseln, und Unternehmen können ihre eigenen Tools, Daten und Prozesse zu privaten Skills zusammenfassen.

Wenn der Agent laufen kann und Zugriff auf die Tools hat, muss er bei komplexen Geschäftsvorgängen zudem wissen, „welche Informationen derzeit fehlen“ und „welche Informationen bereits vorliegen“. Eine einzelne Suche reicht offensichtlich nicht aus, das ist auch der Punkt, an dem herkömmliche RAG bei komplexen Aufgaben an ihre Grenzen stößt. Die aktualisierte Agentic Search-Funktion von Agent Studio verfolgt den Ansatz, dass der Agent wie ein Experte kontinu