Vom Modellaufruf zu Systemen, die abrufen, handeln und delegieren.
Einfache API- und Tool-Demos
Senior AI Engineer & Technical Lead. Master in Autonomous Systems.
Head of Development bei einem KI-Bildungs-Startup, 2023–2026. Ein Teil meiner Arbeit: Agents bauen.
Heute: die Architektur hinter LLM-Anwendungen, von einem Request bis zu koordinierter Arbeit.
| Wann | Ein nützlicher Wegpunkt | Was es zeigt |
|---|---|---|
| Vor 2023 | RAG-Forschung (2020); ReAct (2022) | Retrieval und Reasoning/Action-Loops gab es vor dem Wrapper-Boom. |
| 2023 | Chat-Anwendungen; Function Calling; AutoGen | Modell-APIs werden zum üblichen Einstieg. Multi-Agent-Experimente laufen bereits. |
| Ende 2024 | MCP erscheint | Ein gemeinsames Protokoll für Tools und Kontext über Anwendungen hinweg. |
| 2025–2026 | Diese Fähigkeiten kombiniert | Runtime-Kontrolle, Kontext, wiederverwendbare Integrationen und Koordination greifen ineinander. |
Ein vertrauter Anfang
Ein UI nimmt die Eingabe entgegen. Eure Anwendung ergänzt Anweisungen, ruft ein Modell auf und zeigt die Antwort. Alles Anwendungsspezifische muss im Request mitgeschickt werden.
Dieses Beispiel ist zustandslos. Die Anwendung muss die Historie mitliefern.
Die nächste Frage: Wie wird die Antwort nützlich für eure Dokumente, eure Nutzer und eure aktuellen Daten?
Was die Anwendung vom Modell will.
Relevante Passagen, Datensätze oder Suchergebnisse, mit Quellen.
Die Historie, die man braucht, um diesen Request zu verstehen.
Retrieval-Augmented Generation: Informationen abrufen und die Antwort darauf stützen.
| Bedarf | Aufgabe der Anwendung |
|---|---|
| Relevante Belege | Nützliche Passagen auswählen; Quellenangaben behalten. |
| Platz zum Arbeiten | Budget für Anweisungen, Historie, Tool-Ergebnisse und die Antwort. |
| Lange Gespräche | Historie auswählen, kürzen oder zusammenfassen; wichtige Fakten bewahren. |
| Kontinuität über Sessions | Nützlichen Zustand speichern und bei Bedarf abrufen. |
Mehr Kontext kann helfen. Irrelevanter oder zu viel Kontext kann aber verdecken, was zählt.
Function Calling · noch kein Framework
Wir fragen das Modell und geben ihm die Tool-Schemas neben den Messages mit.
Hat es kein Tool angefordert, hat es geantwortet, und wir sind fertig.
Sonst führen wir das Tool auf unserer Seite aus und geben das Ergebnis als Message zurück. Das Modell führt nie ein Tool aus, das ihr definiert habt.
Dann geht es in die nächste Runde. Das Modell wählt den nächsten Schritt anhand des Ergebnisses. Das ist ein minimaler Agent-Loop.
# this loop is the agent for turn in range(1, 9): resp = client.chat.completions.create( model=args.be.model, messages=messages, tools=TOOLS, ) msg = resp.choices[0].message messages.append(msg.model_dump(exclude_none=True)) # no tool wanted → it answered if not msg.tool_calls: break # we execute, not the model for call in msg.tool_calls: result = dispatch(call.function.name, call.function.arguments) messages.append({"role": "tool", "tool_call_id": call.id, "content": result})
Die Decke
Jeder externe Dienst braucht einen Adapter: Tool-Beschreibung, Argumente, Ausführung, Ergebnisse. Verschiedene Anwendungen wiederholen diese Arbeit womöglich.
Gemeinsame Bibliotheken helfen. Ein gemeinsames Protokoll lässt kompatible Anwendungen eine Integration über dieselbe Schnittstelle wiederverwenden. Genau da sitzt MCP.
Model Context Protocol
Der Host entdeckt Tool-Schemas über MCP und gibt ausgewählte Tools ans Modell. Der Loop aus Entscheidung, Aktion, Ergebnis bleibt gleich.
Der Server implementiert die Integration. Kompatible Anwendungen können sie wiederverwenden. MCP unterstützt auch Resources und Prompts.
Eine brauchbare Analogie. Genauer: MCP ist eine Standardschnittstelle, über die LLM-Anwendungen Tools und Kontext entdecken und nutzen, oft mit bestehenden APIs dahinter.
| MCP liefert | Host / Runtime entscheidet |
|---|---|
| Tool-Discovery und -Aufruf | Welche Tools in den Kontext des Modells kommen und welche Aufrufe erlaubt sind. |
| Resources und Prompts | Wann Daten oder Anweisungen hineinkommen. |
| Eine lokale oder Remote-Verbindung | Credentials, Scopes, Isolation und Verbindungsregeln. |
Tool-Suche und verzögertes Laden ersparen es, jedes Schema in jeden Request zu packen.
Nutzereingabe
ProviderBindet das Modell an
Hooks + PermissionsPrüfen / erlauben / blocken
After-Tool-Hook
Nächster Aufruf
↑ Endantwort → Nutzer
SteeringNeue Vorgabe → Kontext
| Begriff | Rolle im System |
|---|---|
| Agent | Ein modellgesteuerter Loop, der mit Kontext und verfügbaren Aktionen eine Aufgabe verfolgt. |
| Harness / Runtime | Führt den Loop aus und verwaltet Ausführung, Zustand, Limits und Permissions. |
| Framework / SDK | Wiederverwendbarer Code zum Bauen von Agents, Runtimes und Workflows. |
| Skill | Aufgabenanweisungen und zugehörige Ressourcen, geladen wenn relevant. |
| Plugin | Ein host-spezifisches Paket aus Erweiterungen: Tools, Skills oder Integrationen. |
Was dieser Modellaufruf sieht: Anweisungen, ausgewählte Historie, Ergebnisse.
Informationen, die für später aufbewahrt und bei Bedarf abgerufen werden.
Was angefordert wurde, was fertig ist und wo es weitergeht.
Die Anwendung entscheidet, was bleibt, was geteilt wird und was jeder Agent bekommt.
Andere Anweisungen, Tools oder Zugriffe für andere Zuständigkeiten.
Jeder Spezialist bekommt nur das Material für seinen Auftrag.
Unabhängige Recherchen können gleichzeitig laufen.
Jeder Spezialist ist ein weiterer Agent-Loop. Mehrere Agents können dasselbe Modell nutzen - müssen aber nicht
| Muster | Kontrolle | Tradeoff |
|---|---|---|
| Agents als Tools | Ein Parent delegiert begrenzte Aufgaben und nutzt die Ergebnisse. | Klare Verantwortung; Parent-Kontext und Synthese können zum Engpass werden. |
| Graph / Workflow | Explizite Abhängigkeiten, bedingte Verzweigungen, mögliche Schleifen. | Klare Struktur; Routing und Zustand brauchen trotzdem sorgfältiges Design. |
| Handoffs / Swarm | Agents wählen selbst, welcher Spezialist übernimmt. | Flexibles Routing; wiederholte Handoffs verschwenden Arbeit und Budget. |
| Schritt | Was bewegt sich | Wer kontrolliert es |
|---|---|---|
| 1 · Zuweisen | Frage, relevanter Kontext, erwartetes Ergebnis, erlaubte Tools | Parent wählt Aufgaben; Runtime erzwingt Zugriffe. |
| 2 · Recherchieren | Tool-Requests → Ausführung → Belege | Jeder Spezialist fährt seinen eigenen Loop. |
| 3 · Zurückgeben | Befunde, Quellenangaben, Unsicherheit, Blocker | Spezialist gibt ein Ergebnis an den Parent zurück. |
| 4 · Entscheiden | Ein Vorschlag mit Belegen, und was er kosten würde | Abhängige Arbeit startet nach den Befunden. |
| 5 · Handeln oder eskalieren | Die Erstattung, oder ein Mensch, der sie freigibt | Runtime sichert den einen folgenreichen Aufruf ab. |
| Kosten | Design-Antwort |
|---|---|
| Wiederholter Kontext und Modellaufrufe | Begrenzte Arbeit delegieren; nur Relevantes weitergeben. |
| Verlorene Details bei Handoffs | Explizite Ergebnisformate, Belege und Artefakt-Referenzen nutzen. |
| Widersprüchliche Änderungen oder Entscheidungen | Verantwortung festlegen; Schreibzugriffe isolieren; Änderungen abgleichen. |
| Schleifen, Fehler, Abbruch | Gemeinsame Budgets, Timeouts und klare Abschlussregeln erzwingen. |
Gegen eine Single-Agent-Baseline vergleichen: Qualität, Laufzeit, Kosten, Fehlerrate.
Hat es die Aufgabe gelöst? Checks und eine klare Bewertungsrubrik nutzen.
Waren Aktionen erlaubt, Pflichtschritte erledigt, Fehler behandelt?
Wiederholte Runs, lange Sessions, Latenz und Gesamtverbrauch messen.
Runtime-Regeln günstig testen. Aufgabenerfolg mit dem Modell und der Konfiguration aus dem Deployment evaluieren.
| Form der Aufgabe | Ein vernünftiger Startpunkt |
|---|---|
| Eine begrenzte Transformation | Ein Modellaufruf. |
| Eine Antwort auf Basis eurer Daten | Retrieval plus Generierung. |
| Eine bekannte Abfolge von Schritten | Ein expliziter Workflow. |
| Aktionen hängen davon ab, was gefunden wird | Ein Agent-Loop mit eingegrenzten Tools. |
| Trennbare Arbeit oder getrennte Zuständigkeiten | Koordinierte Agents, gemessen an einer einfacheren Baseline. |
Tools führen Aktionen aus. MCP standardisiert den Zugang zu Integrationen.
Der Harness steuert den Loop. Skills und Plugins liefern wiederverwendbare Fähigkeiten.
Mehrere Loops tauschen Aufträge und Ergebnisse aus, unter einer Orchestrierungs-Policy.
Die Architektur wächst um die Arbeit herum, die sie erledigen soll.
Was muss das Modell wissen? Was darf es tun? Wer entscheidet, was als Nächstes passiert?
Ali Karpuzoglu · watermelonson.com