Der Paradigmenwechsel: Von traditionellen APIs zur sprachgesteuerten Integration

Verschiedene Softwaresysteme miteinander ins Gespräch zu bringen, ist eine klassische Herausforderung für Entwickler. Jahrelang haben wir APIs mit genau definierten Regeln verwendet, um dies zu erreichen. Jetzt aber verändern große Sprachmodelle (LLM) das Spiel und bieten einen neuen Weg für die Interaktion von Systemen auf der Grundlage des Verständnisses von Sprache, nicht nur von strengen Formaten. Dies eröffnet aufregende Möglichkeiten, stellt uns aber auch vor neue Probleme, die es zu lösen gilt - was einmal mehr beweist, dass die Arbeit eines Entwicklers nie wirklich getan ist! 

Was das für Entwickler bedeutet, wollen wir nun erkunden.

Wie wir früher Systeme verbunden haben: Traditionelle APIs

Denken Sie daran, wie wir normalerweise Systeme verbinden. Wir verwenden Dinge wie:

• REST-APIs: APIs verwenden oft JSON, vielleicht mit einer OpenAPI (Swagger)-Spezifikation, und geben genau an, welche Daten in ein System ein- und ausgehen, einschließlich Datentypen (wie Strings oder Zahlen).
• RPC (Remote Procedure Call): Mit Werkzeugen wie gRPC können Systeme gegenseitig Funktionen über Dinge wie Protokollpuffer aufrufen, um genau zu definieren, was eine Funktion benötigt und zurückgibt.
• SOAP/WSDL: Dies ist eine ältere Methode, die aber ebenfalls auf einer detaillierten Beschreibung (WSDL) des Dienstes beruht.
• Nachrichten-Warteschlangen (z. B. Kafka, RabbitMQ): Diese Systeme senden Nachrichten hin und her und folgen dabei in der Regel einem bestimmten, vereinbarten Format.

Das Wichtigste dabei ist, dass diese Methoden auf expliziten Regeln und Formaten beruhen. Maschinen prüfen, ob die Daten mit der vordefinierten Struktur (dem Schema oder der Typdefinition) übereinstimmen. Die Entwickler lesen die Dokumentation, um zu verstehen, was die APIs tun, und schreiben dann den Code, um sie in der erforderlichen Reihenfolge aufzurufen und die zurückgegebenen Daten zu verarbeiten. Das ist ein Tanz, den die Entwickler seit dem Aufkommen der Computertechnik vollführt haben.

Aufkommende Paradigmen: MCP, Agenten-Frameworks und aufforderungserweiterte APIs

Der Weg von starr definierten traditionellen APIs zu den fließenden, sprachgesteuerten Interaktionen von LLMs ist nicht immer ein direkter Sprung in reine, uneingeschränkte natürliche Sprache für jede Systemkomponente. Stattdessen beobachten wir das Aufkommen leistungsfähiger Zwischenparadigmen und Frameworks, die diese Kluft überbrücken sollen und es bestehenden Systemen und neuen Diensten ermöglichen, "LLM-kompatibel" zu werden.

Im Mittelpunkt dieser neuen Ansätze steht das Konzept der prompterweiterten APIs. Anstatt von einem LLM zu verlangen, die Funktionalität von Grund auf zu erahnen, oder von einem Entwickler, komplexen Adaptercode zu schreiben, "schmücken" oder "verpacken" wir unsere APIs - ob es sich nun um altehrwürdige REST-Dienste oder neue gRPC-Endpunkte handelt - mit reichhaltigen, natürlichsprachlichen Beschreibungen. Diese Beschreibungen wirken wie ein Benutzerhandbuch speziell für ein LLM und erklären den Zweck der API, wie sie aufzurufen ist, welche Parameter sie erwartet (und in welchem Format), und was sie zurückgibt.

Das Model Context Protocol (MCP) beispielsweise ist ein Beispiel für eine strukturiertere Art und Weise, einer LLM-basierten Steuerebene eine Vielzahl von Fähigkeiten zur Verfügung zu stellen. Systeme können ihre Dienste und die von ihnen unterstützten Aktionen zusammen mit Metadaten und natürlichsprachlichen Beschreibungen deklarieren. Ein LLM kann dann dieses "Menü" deklarierter Fähigkeiten abfragen und Aufrufe dieser zugrunde liegenden Dienste auf der Grundlage von Benutzeranfragen oder übergeordneten Zielen orchestrieren, wobei es versteht , was sie tun und wie sie durch ihre deklarierten, prompt-ähnlichen Schnittstellen zu verwenden sind.

Dies steht in engem Zusammenhang mit der sich rasch entwickelnden Welt der Agent-Frameworks. Diese Frameworks bieten oft das Gerüst für den Aufbau eines primären, LLM-gesteuerten Kontrollagenten. Dieser zentrale Agent fungiert als Orchestrator oder als "Gehirn", das in der Lage ist, zu denken, zu planen und Aufgaben zu delegieren. Die wirkliche Macht entsteht, wenn dieser kontrollierende Agent Zugang zu einer Reihe von "Werkzeugen" oder Sub-Agenten erhält.

Diese Untervermittler können sehr unterschiedlich sein:

• Einige könnten andere spezialisierte LLM-basierte Agenten sein, die für bestimmte Aufgaben wie komplexe Datenanalyse oder kreative Inhaltserstellung entwickelt wurden.
• Andere wiederum können einfachere Softwaremodule oder, was besonders wichtig ist, Wrapper für bestehende traditionelle APIs sein. In diesem Szenario erstellt ein Entwickler einen leichtgewichtigen Wrapper, z. B. für eine interne Auftragsverwaltungs-API. Dieser Wrapper stellt nicht nur die technischen Endpunkte zur Verfügung, sondern enthält sorgfältig ausgearbeitete Eingabeaufforderungen, die die Funktionen der API in natürlicher Sprache beschreiben: "Mit diesem Tool können Sie den Bestellstatus abrufen. Es erfordert eine 'order_id' als Eingabe und gibt den aktuellen Status, das voraussichtliche Lieferdatum und die Artikel in der Bestellung zurück."

Die Gemeinsamkeit dieser Paradigmen liegt auf der Hand: Die API, egal ob es sich um einen brandneuen Microservice oder ein über einen Wrapper zugängliches Legacy-System handelt, ist nicht mehr nur ein technischer Vertrag. Sie wird durch eine Schicht von beschreibenden Aufforderungen ergänzt. Dies ermöglicht es einem LLM (in der Regel einem Kontrollagenten), dynamisch eine Vielzahl von Tools und Fähigkeiten zu entdecken, zu verstehen und zu nutzen. Das LLM muss nicht die komplizierten Implementierungsdetails jedes Tools kennen; es muss lediglich die auf Aufforderungen basierende Beschreibung verstehen, wie es zu verwenden ist. Dieser Wandel verändert grundlegend die Art und Weise, wie wir über Systemintegration nachdenken, und legt einen noch größeren Wert auf die Klarheit, die Präzision und den Umfang dieser beschreibenden Aufforderungen, auf die wir noch näher eingehen werden.

Die Zukunft ist... anders

Der Übergang von strikten, formatbasierten APIs und sogar diesen aufkommenden prompterweiterten Schnittstellen zu wirklich weit verbreiteten sprachbasierten Interaktionen mit LLMs ist eine große Veränderung. Als Entwickler habe ich mich an die Tatsache gewöhnt, dass ich eine klare Definition von möglichen Eingaben, Ausgaben und Fehlermeldungen habe. Die Arbeit mit LLMs bringt eine riesige Menge an Möglichkeiten, die wir nie hatten. Aber es wird auch die Art und Weise, wie man mit anderen Systemen interagiert, neu definieren. Als Entwickler wird es immer wichtiger zu verstehen, wie man präzise und umfassende Aufforderungen zur Beschreibung von Fähigkeiten formuliert, insbesondere wenn wir Systeme bauen, bei denen mehrere KI-Agenten zusammenarbeiten müssen.