Jahresrückblick auf die Agent-Welle: Alles war vorweggenommen, dass es so heiß werden würde.

Dieser Artikel ist der vierte Teil der Serie "Agenten · Neue Welt". Er konzentriert sich auf die plötzliche Beschleunigung der Agenten seit Anfang 2026. Aus der Perspektive eines AI-Branchenexperten wird ein systematischer Rückblick auf das letzte Jahr genommen, um herauszufinden, welche Schlüsselvariablen gemeinsam zum konzentrierten Ausbruch der Agenten geführt haben.

Bei einem Abendessen in der Bucht hat jemand halb im Spaß gesagt, dass die Atmosphäre bei der Diskussion über Agenten im vergangenen Jahr derjenigen bei der Diskussion über das Internet im Jahr 1999 ähnelte. Mit dieser Art von Tonfall, als würde "Geschichte geschrieben werden", war die Luft fast elektrisiert.

Damals wurde nicht über Produkte gesprochen, sondern über zukünftige Organisationsstrukturen und die Rolle der Menschen. Manche haben ernsthaft darüber diskutiert, dass die zukünftigen Unternehmen aus einer Gruppe von Agenten bestehen könnten und die Menschen nur die Überwachung übernehmen würden. Die Konzepte des Superindividuums und der Einpersonengesellschaft (OPC) begannen in die Realität zu treten.

Ich erinnere mich, dass jemand, der an Unternehmenssystemen arbeitete, plötzlich sagte: "Können wir es erstmal einen Monat lang stabil laufen lassen, bevor wir weiter reden."

Diese Worte habe ich später oft nachgedacht. Vor ein oder zwei Jahren war der Agent noch wie der Tigerjäger aus dem alten Märchen, der nicht weiter als fünf Schritte gehen konnte (d.h., er konnte keine längeren Ausführungsketten garantieren).

01 Konvergenz

Im vergangenen Jahr, das als das "Jahr der Agenten" bezeichnet wurde, wurde das Wort "Agent" immer wieder erwähnt. Zusammen mit der Verstärkung der Inferenz führte es zu einem Paradigmenwechsel. Die Modelle begannen nicht nur mehr zu chatten, sondern auch "Dinge zu tun". Sie konnten Planungen erstellen, Aufgaben zerlegen, Werkzeuge aufrufen und sogar selbst Code schreiben. Das Gefühl war wie ein Wendepunkt - die Software begann nicht mehr nur auf Klicks zu warten, sondern handelte aktiv.

Die Stimmung war damals hoch. Die Diskussionen um die Multi-Agenten-Gesellschaft, die autonomen Systeme, die AI-Mitarbeiter und die Umgestaltung der digitalen Organisationsstruktur haben die Debatte auf eine größere Skala gebracht. AutoGPT, Multi-Agenten und verschiedene autonome Erzählungen waren wie ein technologisches Fest. Viele glaubten, dass wir einen Moment ähnlich der Entstehung des Mobilinternets erlebten.

Aber wenn man diese Systeme in die reale Welt setzt, verschwindet die Euphorie schnell vor den technischen Details. Diejenigen, die diese Systeme in die Produktionsumgebung integrieren, haben schnell festgestellt, dass hinter der Euphorie eine andere Seite steckt. Die Modelle können abweichen, die Zugriffsbereiche sind unklar, die Langzeitaufgaben sind instabil und die Kosten sind nicht vorhersehbar. Man weiß nicht, wann das Modell eine zusätzliche Überlegung macht oder einen wichtigen Schritt übersieht. Es kann einen schönen Code schreiben, aber auch eine Randbedingung vergessen. Es kann eine Langzeitaufgabe ausführen, aber wenn es auf dem Weg fehlschlägt, ist es schwierig, den Fehlerort zu finden. Diese Unsicherheit eignet sich nicht für ernsthafte Arbeitsabläufe.

Das subtilste Problem ist, dass der Agent intelligent genug ist und eher wie ein Mensch als wie ein System wirkt. Die Schönheit eines Systems liegt in seiner Vorhersagbarkeit. Die Attraktivität und die Schwäche eines Menschen liegen in seiner Unvorhersagbarkeit. Der Agent neigt von Anfang an zu seinem Schöpfer.

02 Protokollentwicklung

Die erste systematische Anstrengung in Richtung Agenten kam tatsächlich von Protokollen, insbesondere von MCP und A2A.

Das, was MCP erreichen möchte, ist sehr ambitioniert - es möchte eine einheitliche Methode und Schnittstelle für die Anbindung von Modellen an Werkzeuge und Daten schaffen. A2A geht noch einen Schritt weiter und hofft, dass Agenten über Plattformen hinweg zusammenarbeiten können.

Die Vision hinter diesen Protokollen ist sehr klar - wenn die Schnittstellen einheitlich sind, erweitert sich die Ökosysteme natürlich. Wenn die Kommunikation standardisiert ist, können die Agenten wirklich "netzwerkfähig" werden. Dies ist die Grundlage für die Agentenzeit, vergleichbar mit TCP/IP im Internetzeitalter.

TCP/IP hat die Netzwerkkommunikation im Internetzeitalter einheitlich gemacht, und erst dadurch hat das Web und das Mobilinternet richtig explodiert. Wenn die Agenten und die Modelle mit den Werkzeugen über ein einheitliches Protokoll verfügen, wird sich auch hier ein Ökosystem entwickeln. Aber als TCP/IP erschien, war das physische Netzwerk bereits stabil und die Kommunikationsbedürfnisse waren einheitlich. Die Agenten stehen vor einem komplexen und vielfältigen Werkzeugsystem, Zugriffsbeschränkungen und geschäftlichen Grenzen. Sie versuchen, auf einem noch expandierenden kognitiven Netzwerk Ordnung zu schaffen, anstatt auf einem bereits bestehenden Netzwerk ein Protokoll zu vereinheitlichen.

Protokolle reifen nie über Nacht. Die Versionen ändern sich, die Hersteller haben unterschiedliche Standpunkte und die Umsetzungen sind nicht immer einheitlich. Man spürt eine Vorsicht - jeder versteht die Wichtigkeit der Standards, aber niemand möchte sein Schicksal vollständig in die Hände von noch wachsenden Normen legen.

Abbildung: Vergleich zwischen MCP (links) und A2A (rechts)

03 Architekturschichtung: Von Szenarioanwendungen zu Fähigkeitseinheiten

Der Wendepunkt war nicht eine bestimmte Pressekonferenz, sondern eine Veränderung der Atmosphäre.

Nach einem Jahr ist die Hektik etwas zurückgegangen, und die Form der Agenten ist klarer geworden. Man hat langsam gemerkt, dass es besser ist, einen allgemeinen kognitiven Kern zu behalten, der für das Verstehen von Absichten, das Zerlegen von Aufgaben, das Planen und das Verwalten von Gesprächen zuständig ist, anstatt für jedes Szenario einen speziellen kleinen Agenten zu entwickeln. Dann können die Aktionen, die bei der Umsetzung externe Auswirkungen haben, als wiederverwendbare und verwaltbare Ausführungskompetenzen herausgearbeitet werden. Mit anderen Worten, der Agent wird zu einer Kombination aus "Kognition + Ausführung": Die obere Ebene erlaubt eine flexible Inferenz, die untere Ebene muss kontrollierbar umsetzbar sein.

So ist die sogenannte "Architekturschichtung" wieder in den Vordergrund gerückt. Dies ist eine Arbeitsteilung, die durch die Realität erzwungen wurde, und umfasst die Kognitionsebene, die Fähigkeitsebene, die Verbindungsebene und die Kontinuitätsebene. Das LLM als Kognitionsebene bringt von Natur aus Unsicherheit mit sich und ist gut darin, Lösungen zu finden und Abwägungen zu treffen. Die Fähigkeitsebene besteht aus aufrufbaren Ausführungseinheiten: Alle Aktionen, die mit dem Senden von E-Mails, dem Ändern von Daten, dem Platzieren von Bestellungen, dem Überweisen von Geldern, dem Schreiben von Dateien und dem Aufrufen von Unternehmenssystemen verbunden sind und potenzielle Nebenwirkungen haben, müssen in klare Grenzen gesetzt werden - Eingabe und Ausgabe müssen klar sein, der Zugriffsbereich muss definiert sein, bei einem Fehler muss die Wiederholung möglich sein, und die wiederholte Ausführung darf keine Probleme verursachen, wie z.B. das Mehrfachabheben von Geld oder das Mehrfachsenden von E-Mails.

Die Verbindungsebene ist für die Anbindung dieser Fähigkeiten an die Außenwelt zuständig: Datenbanken, SaaS, Unternehmenssysteme, Browser, Terminalbefehlszeilen - dies sind die "Hände" und die "Schnittstellen". Schließlich gibt es die sogenannte "Kontinuitätsebene", die für den "Zustand und das Gedächtnis" zuständig ist: Der Fortschritt einer Aufgabe, der Zustand für das Fortsetzen nach einem Unterbruch, das Langzeitgedächtnis und der erforderliche Wissenscache werden hier verwaltet. Das Modell übernimmt nicht mehr alles, sondern tritt zurück in die Rolle des "Entscheiders"; die Bestimmtheit, die Einhaltung von Vorschriften und die Kontrollierbarkeit der Ausführung werden von der Systemebene übernommen.

Viele setzen auf Claude Code als Symbol für diese Phase. Ich sehe es eher als eine Veränderung der Haltung: Es wird nicht mehr über Persönlichkeit oder autonome Gemeinschaften in großem Stil gesprochen, sondern es wird der Fokus auf praktischere Dinge gelegt - ob die Aufgabe kontinuierlich ausgeführt werden kann, ob die Fähigkeiten wiederverwendbar gekapselt werden können, ob die Werkzeuge stabil aufgerufen werden können und ob die Aufrufketten nachverfolgt, wiederholt, berechtigt und abgerechnet werden können. Es zieht den Agenten von der Bühne in die Werkstatt.

In diesem Prozess hat ein altes Wort wieder eine neue Bedeutung erhalten - "skills" (Fähigkeiten).

Im Alexa-Zeitalter waren die Skills Regelerweiterungen, die bei fehlender semantischer Fähigkeit als vertikale Patches für das Sprachverstehen dienten. Jeder Skill war eine Insel, die auf der Intentionseinteilung und der Vorlagenanpassung basierte und einen eigenen Zustand aufrechterhielt. Für verschiedene Fragestellungen mussten Tausende von unabhängigen Skills erstellt werden, um z.B. nach dem Wetter, den Aktienkursen oder der Uhrzeit zu fragen.

Im Zeitalter der großen Modelle wird der Skill neu definiert. Das Verstehen wird auf das Modell zentralisiert. Der Skill ist nicht mehr für das "Verstehen" zuständig, sondern ist nur eine Ausführungseinheit in der Fähigkeitsebene - ein aufrufbarer, einschränkbarer und auditable "action primitive". Die Verbindung und die Zustandsverwaltung werden weiterhin von der Systemebene übernommen. Das Modell trifft die Entscheidungen, der Skill führt die Aktionen aus, und das System definiert die Grenzen.

Was heißt "aufrufbar, einschränkbar und auditable"? Oder: Können nicht auch APIs vom LLM aufgerufen werden? Was ist also neu am Skill? Ist es nur ein anderer Name für die API?

Abbildung: Darstellung eines Skills (mit AI-Unterstützung erstellt)

Nehmen wir ein konkretes Szenario als Beispiel.

Angenommen, der Benutzer sagt: "Analysiere bitte die Aktienkursentwicklung von Tesla in den letzten drei Monaten. Wenn es ungewöhnliche Schwankungen gibt, erkläre sie und erstelle ein Diagramm."

In der traditionellen API-Struktur, auch wenn das LLM beteiligt ist, sieht es normalerweise so aus: Der Programmierer schreibt den Ablauf im Voraus. Zuerst wird die Schnittstelle zur Datenabfrage aufgerufen, dann die Analyseschnittstelle und schließlich die Schnittstelle zur Diagrammerstellung. Das LLM ist möglicherweise nur für das Füllen der Parameter zuständig. Der Ablauf ist festgelegt. Was passiert, wenn es fehlschlägt? Der gesamte Abschnitt wird erneut ausgeführt. Was passiert, wenn es Verzweigungen gibt? Die Entscheidungslogik muss im Voraus geschrieben werden. Die Kombinationsfähigkeit existiert, aber die Kombinationsreihenfolge ist im Code und nicht im Modell.

Die API ist ein Werkzeug, der Ablauf gehört dem Programmierer; der Skill ist ebenfalls ein Werkzeug, aber der Ablauf wird nun vom Modell gesteuert.

Im System gibt es nicht nur "Schnittstellen", sondern auch eine Fähigkeitsregistrierung. Die Datenabfrage, die Trendsanalyse, die Diagrammerstellung und die Erklärungserstellung - diese Fähigkeiten werden genau beschrieben, registriert und in einen sichtbaren Fähigkeitsraum aufgenommen. Das Modell erstellt während der Planungsphase einen abstrakten Plan: Zuerst die Datenabfrage, dann die Trendsanalyse, wenn die Schwankungen einen Schwellenwert überschreiten, die Erstellung einer Erklärung und schließlich die Diagrammerstellung. Die Reihenfolge wird nicht im Voraus festgelegt, sondern während der Laufzeit entschieden.

Beachten Sie die Veränderung: Im API-Zeitalter ist die Kombinationslogik im Code geschrieben; im Skill-Architekturmodell liegt die Kombinationslogik in der Planung des Modells.

Dies ist nicht einfach eine "Umbenennung der API", sondern eine Verschiebung der Kontrolle.

Schauen wir uns das noch genauer an. Angenommen, es gibt im System zwei Trendsanalysefähigkeiten - eine schnelle, aber grobe und eine langsame, aber genaue. In der traditionellen Struktur müssen Sie im Voraus entscheiden, welche Version Sie aufrufen möchten. Im Skill-Framework kann das Modell die Wahl treffen, basierend auf seiner Interpretation der Benutzeranfrage in Bezug auf Geschwindigkeit oder Genauigkeit. Die Fähigkeiten werden zu vergleichbaren Objekten, anstatt auf feste Funktionen festgelegt zu sein.

Zum Beispiel bei der Fehlerbehandlung. Wenn ein Schritt eine Ausnahme zurückgibt, kann die Scheduler-Ebene die Fähigkeit erneut ausführen, anstatt den gesamten Ablauf neu zu starten. Das System kann die Erfolgsrate, die Verzögerung und die Kosten jeder Fähigkeit statistisch auswerten und diese Signale in die Orchestrierung zurückführen, um die Fähigkeitskombinationen schrittweise zu optimieren - im API-Zeitalter konnten diese Statistiken auch erstellt werden, aber sie dienten hauptsächlich der Wartung: um zu sehen, ob der Dienst läuft und wie schnell er ist.

Bei den Skills werden diese Statistiken "für die Planung" verwendet: Sie zeigen nicht nur, welche Schnittstelle instabil, langsam oder fehlerhaft ist, sondern auch, wie sich ein Fehler in einem Schritt auf die gesamte Aufgabenkette auswirkt - ob es zu einer lokalen Verzögerung, einer Kettenreaktion von Fehlern oder der Notwendigkeit einer sofortigen Umleitung kommt.

Das ist der Punkt, an dem der Skill wirklich Fuß fasst. Natürlich existiert dieser geschlossene Kreis der Fähigkeitsbeobachtung und -optimierung derzeit hauptsächlich in den Praktiken führender Teams und ist noch weit davon entfernt, eine weit verbreitete Standardpraxis zu werden. Aber die Struktur ist vorhanden, und es bleibt nur noch die Skalierung und die Zeit.

APIs sind im Wesentlichen für Programmierer gedacht. Skills werden vom Modell geplant. Die ersteren gehen davon aus, dass der Mensch den Ablauf schreibt. Die letzteren gehen davon aus, dass das Modell den Ablauf erstellt. Sobald die Kombinationsmacht vom Programmierer auf das Modell übertragen wird, ändert sich die Bedeutung der Fähigkeiten. Sie sind nicht mehr nur Funktionen in einer Codebasis, sondern Knoten in einem Fähigkeitsdiagramm. Der Wert eines Skills liegt nicht darin, dass er höherwertig als eine API ist, sondern darin, dass er die "Laufzeitkombination" ermöglicht und gleichzeitig die industriellen Grenzen einhält. Das Verstehen wird weiterhin vom großen Modell übernommen, die Ausführung wird nun klarer eingeschränkt. Dieser Schritt, der auf den ersten Blick konservativ erscheint, ist tatsächlich eine Industrialisierung.

Eine reife Fähigkeit bedeutet mindestens drei Dinge: Die Eingabe und Ausgabe sind strukturiert (es ist ein Schema definiert); die Ausführung kann wiederholt und rückgängig gemacht werden; die Zugriffsrechte sind isoliert und der Zustand kann überprüft werden. Sie können den Zugriffsbereich einschränken, die Aufrufkette protokollieren, die Kosten abrechnen und die Zugriffsrechte jederzeit widerrufen. Dies klingt nicht besonders aufregend, aber es sind