KI-Agenten, Tool-Use & MCP: wenn das Modell selbst handelt

Agent oder Workflow?

Nicht jedes „KI-System“ ist ein Agent. Anthropic trennt sauber: In einem Workflow sind Modell und Werkzeuge über fest vorgegebene Code-Pfade orchestriert – der Ablauf steht vorher fest. In einem Agenten steuert das Modell seinen eigenen Ablauf und Werkzeugeinsatz dynamisch selbst und behält die Kontrolle darüber, wie es die Aufgabe löst.

Der Unterschied ist praktisch, nicht akademisch: Ein Workflow ist vorhersehbar und günstig zu betreiben, ein Agent flexibel, aber teurer und schwerer zu kontrollieren. Die Faustregel vorweg: erst den einfachsten Weg ausreizen – oft genügt ein einzelner, gut gebauter Modellaufruf mit Kontext –, und Agenten nur dort einsetzen, wo die einfacheren Lösungen nicht reichen.

Merksatz Workflow = feste Pfade, vorhersehbar. Agent = das Modell bestimmt den Ablauf selbst, flexibel, aber schwerer zu führen.

Tool-Use: vom Reden zum Handeln

Der Motor jedes Agenten ist Tool-Use (auch Function-Calling). Wichtig: Das Modell führt nichts selbst aus. Es bekommt eine Liste definierter Werkzeuge – jeweils Name, Beschreibung und ein JSON-Schema der Parameter – und liefert, wenn es ein Werkzeug braucht, einen strukturierten Aufruf zurück. Die Anwendung führt diesen aus und reicht das Ergebnis ans Modell zurück.

So entscheidet das Modell, wann eine Datenbankabfrage, eine Berechnung oder ein API-Aufruf nötig ist – und arbeitet mit dem echten Ergebnis weiter, statt es zu raten. Eine Werkzeug-Definition sieht etwa so aus:

{
  "name": "wetter_abfragen",
  "description": "Liefert das aktuelle Wetter für einen Ort.",
  "input_schema": {
    "type": "object",
    "properties": {
      "ort":     { "type": "string", "description": "Stadt, z. B. Wien" },
      "einheit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["ort"]
  }
}

Der Agenten-Loop

Ein Agent ist im Kern ein Modell in einer Schleife: Es plant einen Schritt, ruft ein Werkzeug auf, beobachtet das Ergebnis aus der Umgebung und entscheidet auf dieser Basis den nächsten Schritt – so lange, bis die Aufgabe erledigt ist oder eine Grenze (Schrittzahl, Budget, Zeit) erreicht wird. Diese Rückkopplung mit der echten Umgebung unterscheidet den Agenten vom starren Skript.

Entscheidend ist, woran sich der Loop verankert: Läuft der Agent gegen einen echten Prüfstein – Tests, Compiler, ein Schema, die laufende Anwendung –, korrigiert er sich an Fakten. Ohne solche Rückmeldung rät er im Zweifel. Für das Programmieren ist dieser Loop im Coding-Artikel ausführlich beschrieben.

Merksatz Ein Agent ist ein Modell in einer Schleife – mit Werkzeugen und Umgebungs-Feedback. An echten Prüfsteinen verankert schlägt geraten.

Der Loop in der Praxis: KI-Coding →

MCP: ein Standard für die Anbindung

Jedes Werkzeug einzeln an jedes Modell zu koppeln, skaliert nicht – aus M Anwendungen und N Werkzeugen werden schnell M×N Einzel-Integrationen. Das Model Context Protocol (MCP) löst das wie ein gemeinsamer Stecker: Anthropic beschreibt es als „USB-C-Anschluss für KI“. Ein Werkzeug oder eine Datenquelle wird einmal als MCP-Server bereitgestellt und spricht dann mit jedem MCP-fähigen Client dieselbe Sprache.

Anthropic stellte MCP im November 2024 als offenen Standard vor – und es blieb nicht hauseigen: OpenAI übernahm MCP im März 2025 (u. a. ChatGPT-Desktop und Agents-SDK), Google bestätigte Unterstützung in den Gemini-Modellen, und Ende 2025 wurde das Protokoll in eine herstellerneutrale Stiftung überführt. Aus konkurrierenden Insellösungen wurde ein gemeinsamer Standard. Für Entwickler heißt das: einmal bauen, mit Modellen mehrerer Anbieter nutzbar.

MCP vorgestellt

Anthropic, Nov. 2024

Übernommen u. a. von

OpenAI (3/2025), Google

Werkzeuge & Tooling im Katalog →

Mehrere Schritte, mehrere Agenten

Zwischen „ein Modellaufruf“ und „voll autonomer Agent“ liegt eine Reihe bewährter Muster, die Anthropic beschreibt – meist als Workflow, also mit festen Pfaden: Prompt-Chaining (eine Aufgabe in eine Kette von Schritten zerlegen), Routing (Eingaben klassifizieren und an spezialisierte Pfade leiten), Parallelisierung (Teilaufgaben gleichzeitig laufen lassen oder mehrfach abstimmen), Orchestrator-Worker (ein führendes Modell zerlegt die Aufgabe und verteilt sie an Helfer) und Evaluator-Optimizer (ein Modell erzeugt, ein zweites bewertet und verbessert in Runden).

Mehr Agenten sind nicht automatisch besser: Jeder zusätzliche Schritt kostet Tokens, Latenz und Kontrolle. Ein gut dokumentiertes Beispiel, wann sich Aufteilung lohnt – spezialisierte Reviewer plus ein Koordinator, Aufwand nach Risiko dosiert –, steht im Coding-Artikel.

Multi-Agenten im Maßstab (Cloudflare-Fall) →

Grenzen & Sicherheit

Agenten greifen nach immer längeren Aufgaben, sind damit aber nicht zuverlässig fertig: Die Forschungsorganisation METR misst die Aufgabenlänge, die ein Modell mit 50 % Erfolg autonom schafft – eine 50-%-Marke ist kein „gelöst“. Und je länger ein Agent läuft, desto eher verliert er die ursprüngliche Anweisung aus dem Blick; unumkehrbare Aktionen gehören abgesichert.

Dazu kommt eine eigene Angriffsfläche durch Tool-Use und MCP. Sicherheitsforscher warnen vor „Tool Poisoning“ (schädliche Anweisungen, versteckt in der Werkzeug-Beschreibung, die das Modell sieht, der Mensch aber nicht), vor indirekter Prompt-Injection über die von Werkzeugen gelieferten Daten und vor „Rug Pulls“ (ein Werkzeug ändert sein Verhalten nach der Installation). Gegenmittel: nur vertrauenswürdige Server einbinden, Rechte minimal halten (Positivliste statt generischem Shell-Zugriff) und heikle Aktionen bestätigen lassen.

METR-Erfolgsmarke

50 % – kein „gelöst“

Merksatz So einfach wie möglich, so agentisch wie nötig. Und: Jedes Werkzeug ist eine Angriffsfläche – Rechte minimal halten, Quellen prüfen.

Mehr zu Sicherheit & Alignment →