Agenten, Tool-Nutzung und Orchestrierung

Vom Antworten zum Handeln

Die Systeme der vorigen Abschnitte erzeugen Text. Viele nützliche Systeme müssen aber auch handeln: eine Bestellung nachschlagen, eine Wissensdatenbank durchsuchen, eine Erstattung auslösen, einen Tisch reservieren, eine Testsuite ausführen. Tool Calling (oft Function Calling genannt) ist der Mechanismus dafür. Die Anwendung beschreibt die verfügbaren Tools, jedes mit einem Namen, einer Beschreibung und einem JSON Schema für seine Parameter. Statt in Prosa zu antworten, kann das Modell eine strukturierte Anfrage zurückgeben, eines oder mehrere davon mit bestimmten Argumenten aufzurufen. Die Anwendung, nicht das Modell, entscheidet, ob der Aufruf ausgeführt wird, führt ihn aus und gibt das Ergebnis an das Modell zurück, das dann fortfährt. Das Modell berührt nie selbst eine Datenbank oder eine API; jede Wirkung in der Welt läuft durch Code, den Sie geschrieben haben.

Ein Agent ist ein System, in dem das Modell wiederholt seine Aktionen wählt: Es ruft ein Tool auf, liest das Ergebnis, entscheidet, was als Nächstes zu tun ist, und macht weiter, bis das Ziel erreicht ist oder ein Limit es stoppt. Autonomie ist ein Spektrum. Am einen Ende ruft Code das Modell einmal auf, um ein Formular auszufüllen; am anderen plant und erledigt ein Modell eine lange Aufgabe mit Dutzenden von Tool-Aufrufen und wenig Aufsicht. Architektonisch entscheidend ist, dass jeder Schritt in Richtung Autonomie Entscheidungen aus deterministischem, prüfbarem Code in eine probabilistische Komponente verlagert, was die Flexibilität erhöht und Vorhersagbarkeit, Testbarkeit und Kontrolle verringert. Diese Abwägung sollte bewusst getroffen werden, und so spät und so sparsam, wie das Problem es verlangt.

{
  "name": "get_order_status",
  "description": "Look up the current status of one order placed by the signed-in customer. Use when the customer asks where an order is. Returns status, estimated arrival and courier position. Changes nothing.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "pattern": "^ORD-[0-9]{6}$",
        "description": "Order number, for example ORD-104233"
      }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

Die Agentenschleife: nachdenken, handeln, beobachten

Die Schleife hinter fast jedem Agenten beschrieben Shunyu Yao und Kollegen in ReAct: Synergizing Reasoning and Acting in Language Models (2022). ReAct verschränkt Nachdenken (das Modell schreibt auf, was es zu tun versucht), Aktionen (es ruft ein Tool auf) und Beobachtungen (das Ergebnis des Tools wird seinem Kontext hinzugefügt), sodass jeder Schritt von dem geprägt ist, was der vorige herausgefunden hat. Vor ReAct dachten Modelle entweder ohne Zugang zu Fakten nach und halluzinierten, oder sie handelten ohne nachzudenken und irrten umher. Die heutigen Tool-Calling-Schnittstellen und Reasoning-Modelle haben diese Schleife eingebaut, doch ihre Struktur ist noch immer die, um die herum Sie entwerfen sollten.

Im Code ist die Schleife kurz. Den Kontext aufbauen (Anweisungen, Ziel, Verlauf, Tool-Definitionen, bisherige Ergebnisse); das Modell aufrufen; gibt es eine endgültige Antwort zurück, aufhören; gibt es Tool-Aufrufe zurück, jeden gegen sein Schema und die Geschäftsregeln validieren, prüfen, ob der Nutzer dazu berechtigt ist, ihn mit einem Timeout ausführen, das Ergebnis (oder eine klare Fehlermeldung) an den Kontext anhängen, die Limits prüfen und die nächste Runde drehen. Das Diagramm unten zeigt, wo deterministischer Code das Modell umgibt. Alles außerhalb des Modellkastens ist gewöhnliche Software, die getestet, geprüft und durchgesetzt werden kann; daher stammen die Zuverlässigkeit und Sicherheit eines Agenten.

Workflows oder Agenten

In Building effective agents (Dezember 2024) trafen Erik Schluntz und Barry Zhang von Anthropic eine Unterscheidung, die inzwischen zum allgemeinen Vokabular gehört. Workflows orchestrieren Modelle und Tools über vordefinierte Codepfade; Agenten lassen das Modell seinen eigenen Ablauf und seine Tool-Nutzung steuern. Sie beschrieben eine kleine Menge von Workflow-Mustern, alle aufgebaut aus einem erweiterten LLM (einem Modell mit Retrieval, Tools und Gedächtnis), und rieten, mit dem einfachsten funktionierenden Entwurf zu beginnen, oft einem einzigen gut formulierten Aufruf mit Retrieval, und agentisches Verhalten erst hinzuzufügen, wenn es die Ergebnisse nachweislich verbessert.

Der Rat deckt sich mit der allgemeinen Haltung dieses Kurses zur Einfachheit. Ein Workflow hat eine bekannte Form, sodass sich Kosten, Latenz und Fehlerbilder vorhersagen und seine Schritte einzeln testen lassen. Ein Agent kann offene Aufgaben bewältigen, deren Schritte sich nicht im Voraus kennen lassen, etwa einen unbekannten Fehler untersuchen oder eine Frage über viele Quellen hinweg recherchieren, um den Preis schwankender Kosten, schwierigerer Tests und mehr Möglichkeiten, schiefzugehen. Viele Systeme, die als Agenten bezeichnet werden, wären als Workflows besser, und viele gute Agenten enthalten Workflows.

Tools für Modelle entwerfen

Tools sind eine Schnittstelle, deren Nutzer ein Modell ist, und sie verdienen dieselbe Sorgfalt wie jede API. Schluntz und Zhang nennen das die Agent-Computer-Schnittstelle. Geben Sie jedem Tool einen klaren Zweck und einen Namen und eine Beschreibung, die sagen, wann es zu verwenden ist, wann nicht und was es zurückgibt; Modelle wählen Tools vor allem anhand ihrer Beschreibungen. Halten Sie Parameter wenige und typisiert, verwenden Sie Aufzählungen statt Freitext und weisen Sie unbekannte Felder zurück. Machen Sie Fehler schwer, zum Beispiel indem Sie absolute Bezeichner statt Positionen in einer Liste verlangen. Geben Sie knappe, relevante Ergebnisse zurück, denn jedes Token eines Tool-Ergebnisses wird bezahlt und belegt das Kontextfenster; paginieren und fassen Sie große Ergebnisse zusammen. Geben Sie Fehlermeldungen zurück, mit denen das Modell arbeiten kann (Bestellung nicht gefunden; bitten Sie den Kunden, die Nummer zu prüfen), statt Stacktraces.

Trennen Sie Lesen vom Schreiben. Lese-Tools können meist frei laufen; Schreib-Tools verändern die Welt und brauchen Validierung, Autorisierung, Idempotenz und manchmal eine Freigabe. Halten Sie die Zahl der jeweils verfügbaren Tools klein, denn große Tool-Sammlungen verwirren Modelle und vergrößern die Angriffsfläche; leiten Sie an eine Teilmenge weiter oder laden Sie Tool-Definitionen bei Bedarf. Verlangen Sie eine strukturierte Ausgabe, wann immer Code das Ergebnis verarbeitet: Viele APIs können die Generierung auf ein JSON Schema beschränken, was Parsing-Fehler beseitigt, aber keine falschen Werte, sodass die Validierung des Inhalts weiterhin nötig ist.

Das Model Context Protocol

Jeder Assistent, der jede Datenquelle oder jedes Tool erreichen will, bräuchte sonst für jedes Paar eine eigene Integration: N Anwendungen mal M Systeme. Das Model Context Protocol (MCP), im November 2024 von Anthropic als offener Standard eingeführt, ersetzt das durch ein einziges Protokoll, so wie es das Language Server Protocol für Code-Editoren getan hat. Eine Host-Anwendung (ein Chat-Assistent, eine IDE, ein Agent) betreibt einen MCP-Client pro Verbindung zu einem MCP-Server. Server stellen Tools (Funktionen, die das Modell aufrufen darf), Ressourcen (Daten, die die Anwendung in den Kontext laden kann) und Prompts (wiederverwendbare Vorlagen) bereit. Nachrichten nutzen JSON-RPC 2.0, über Standardein- und -ausgabe für lokale Server oder über HTTP für entfernte, und Remote-Server nutzen eine Autorisierung auf Basis von OAuth.

Die Verbreitung ging schnell. Bis Dezember 2025 meldete Anthropic mehr als 10.000 aktive öffentliche MCP-Server und Unterstützung in Produkten wie ChatGPT, Cursor, Gemini, Microsoft Copilot und Visual Studio Code. Am 9. Dezember 2025 übergab Anthropic MCP an die neu gegründete Agentic AI Foundation, einen Directed Fund unter der Linux Foundation, mitgegründet von Anthropic, Block und OpenAI, sodass das Protokoll nun an einem herstellerneutralen Ort verwaltet wird. Die Spezifikation wird nach Datum versioniert. Die Revision 2026-07-28 machte das Kernprotokoll zustandslos, sodass Remote-Server hinter gewöhnlichen Load Balancern ohne Sticky Sessions laufen können; sie führte Unterstützung für optionale Erweiterungen ein und verlagerte lang laufende Aufgaben aus dem Kern in eine offizielle Erweiterung; sie verschärfte die Autorisierung; und sie erklärte ältere Funktionen (Roots, Sampling und Logging) für veraltet, mit einer Übergangsfrist von mindestens einem Jahr. Für die Kommunikation zwischen unabhängigen Agenten statt zwischen einer Anwendung und ihren Tools führte Google im April 2025 das Protokoll Agent2Agent (A2A) ein; es wurde im Juni 2025 an die Linux Foundation übergeben, und im August 2026 kündigten seine Unterstützer an, dass es ebenfalls in die Agentic AI Foundation wechseln werde.

Architektonisch ist ein MCP-Server eine Abhängigkeit, die Ihre Daten lesen und in Ihrem Namen handeln kann, behandeln Sie ihn also auch so. Geben Sie die Server, die genutzt werden dürfen, im Rahmen der Sicherheit der Software-Lieferkette frei und legen Sie ihre Versionen fest; bevorzugen Sie Server, die Sie selbst oder ein vertrauenswürdiger Anbieter betreiben; geben Sie den Anmeldedaten jedes Servers nur das Least Privilege, das seine Tools brauchen; denken Sie daran, dass Tool-Beschreibungen und -Ergebnisse in den Kontext des Modells fließen und eingeschleuste Anweisungen enthalten können; und leiten Sie entfernten MCP-Verkehr über dasselbe Gateway, dasselbe Logging und dieselben Richtlinienkontrollen wie anderen Modellverkehr. Das Protokoll standardisiert die Verrohrung; es entscheidet nicht, was ein Agent tun darf.

Gedächtnis und Zustand

Modelle sind zustandslos, daher ist das Gedächtnis eines Agenten das, was das umgebende System speichert und wieder in den Kontext gibt. Das Kurzzeitgedächtnis sind das Gespräch und die bisherigen Ergebnisse der Tool-Aufrufe. Es wächst mit jedem Schritt, erhöht Kosten und Latenz und sprengt schließlich das Fenster, deshalb verwalten lang laufende Agenten es: Sie verwerfen oder kürzen alte Tool-Ergebnisse, fassen frühere Gesprächsrunden zusammen (Compaction) und führen einen laufenden Plan oder eine Notizdatei, die das Modell aktualisiert. Das Langzeitgedächtnis sind Informationen, die über Sitzungen hinweg aufbewahrt werden, etwa die Ernährungsvorlieben eines Kunden oder Fakten, die ein Assistent über ein Projekt gelernt hat, gespeichert in einer Datenbank und bei Bedarf abgerufen, was es zu einem kleinen RAG-System mit denselben Fragen nach Relevanz, Aktualität und Zugriffskontrolle macht.

Der Ausführungszustand zählt am meisten für die Zuverlässigkeit. Ist ein Agent mitten in einer Aufgabe mit zwanzig Schritten, wenn sein Prozess neu startet, sollte er fortfahren, nicht von vorn beginnen und Nebeneffekte wiederholen. Speichern Sie den Zustand nach jedem Schritt (den Kontext, den Plan, welche Tool-Aufrufe abgeschlossen sind und ihre Ergebnisse) als Checkpoint, oder lassen Sie den Agenten auf einer Durable-Execution-Engine laufen, die das für Sie erledigt, so wie lang laufende Geschäftsprozesse und Sagas betrieben werden. Gedächtnis ist auch personenbezogene Daten: Entscheiden Sie, was gespeichert wird, wie lange, ob Nutzer es sehen und löschen können, und halten Sie das Gedächtnis eines Kunden aus dem Kontext eines anderen heraus (siehe Privacy by Design).

Multi-Agenten-Systeme

Ein Multi-Agenten-System verteilt die Arbeit auf mehrere modellgesteuerte Agenten, meist einen leitenden Agenten, der plant und an Sub-Agenten delegiert, jeder mit eigenen Anweisungen, Tools und eigenem Kontextfenster, deren Ergebnisse der leitende Agent zusammenführt. Die Vorteile sind Parallelität, Spezialisierung und vor allem die Trennung der Kontexte: Jeder Sub-Agent kann eine große Menge Material durchgehen und nur eine kurze Zusammenfassung zurückgeben. Anthropic berichtete im Juni 2025, dass sein Multi-Agenten-Recherchesystem in seiner internen Recherche-Evaluierung einen einzelnen Agenten klar übertraf, aber auch, dass solche Systeme etwa 15-mal so viele Tokens verbrauchten wie gewöhnliche Chats und sich für breite, parallelisierbare Aufgaben besser eignen als für eng gekoppelte wie die meisten Programmieraufgaben.

Fachleute sind uneins darüber, wie weit man gehen sollte. Im selben Monat argumentierte Walden Yan von Cognition in Don't Build Multi-Agents, dass Sub-Agenten, die mit unvollständigem Kontext arbeiten, widersprüchliche Annahmen treffen, und empfahl als Standard einen Single-Thread-Agenten mit sorgfältigem Kontextmanagement. Beide Positionen sind sich über die eigentliche Ursache einig: Koordination zwischen Agenten ist verlustbehaftete Kommunikation zwischen Komponenten, die keinen Zustand teilen. Das ist das zentrale Problem verteilter Systeme, und es gilt derselbe Rat. Verteilen Sie nicht ohne Grund; halten Sie die Schnittstellen zwischen Agenten explizit und schmal; bevorzugen Sie unabhängige Teilaufgaben; verfolgen Sie jeden Sprung per Tracing; und rechnen Sie damit, dass sich Kosten, Latenz und Fehlerbilder mit der Zahl der Agenten vervielfachen.

Zuverlässigkeits-Engineering für Agenten

Agenten versagen auf neue Weise: Sie drehen sich im Kreis und rufen dasselbe Tool mit denselben Argumenten auf; sie schweifen ab und verfolgen ein Nebenthema, bis das Budget erschöpft ist; sie geben vorzeitig auf oder behaupten Erfolge, die sie nicht erzielt haben; und sie führen Aktionen aus, mit denen ihre Entwickler nicht gerechnet haben. Die Abhilfen sind die Muster aus Kapitel 9 und Kapitel 6, angewandt bei jedem Schritt statt einmal pro Anfrage, dazu die feste Regel, dass folgenreiche Nebeneffekte mehr brauchen als das Wort des Modells. Abschnitt 12.6 behandelt die Sicherheitsseite, die übermäßige Handlungsbefugnis, ausführlich; die Checkliste unten deckt die Zuverlässigkeit ab.