Verständnis von KI-Agenten: Tool-Aufrufe, MCP und der Agent-Zyklus
Wie Tool-Calling, MCP und der Agent-Loop in die tatsächliche Architektur von KI-Agenten passen, ausgehend vom erweiterten LLM und ohne überflüssige Begriffe.
Quellen: Tool Calling vs MCP: How AI Agents Actually Use Tools
Wenn Menschen mit der Erkundung von KI-Agenten beginnen, tauchen überall immer wieder dieselben wenigen Begriffe auf:
Agenten. Tools. Funktionsaufrufe. MCP. Kontext. Speicher.
Auf den ersten Blick wirken diese wie eine Ansammlung unzusammenhängender Technologien.
Doch wenn man genügend Zeit investiert, um herauszufinden, wie echte agentbasierte Systeme aufgebaut sind – insbesondere indem man sich die technischen Dokumentationen von Anthropic zu Agenten und MCP ansieht – wird allmählich eine viel einfachere zugrundeliegende Architektur sichtbar.
Dieser Artikel erläutert diese Architektur aus einer praktischen, für Entwickler orientierten Perspektive.
Was macht eigentlich ein KI-System zu einem Agenten?
Eine typische App, die auf einem großen Sprachmodell basiert, kann wie folgt dargestellt werden:
User
↓
LLM
↓
Response
Hier nimmt das Modell einfach Eingaben entgegen und erzeugt Ausgaben.
Doch viele reale Aufgaben lassen sich nicht allein durch das Erstellen von Text lösen.
Nehmen wir diese Anfrage als Beispiel:
„Schauen Sie sich dieses GitHub-Repositorium nach offenen Problemen an, konzentrieren Sie sich auf das wichtigste davon und geben Sie einen Überblick darüber, was noch behoben werden muss.“
Zur Bewältigung solcher Aufgaben muss das System Folgendes tun:
- Die Anfrage verstehen.
- Beschließen, welche Informationen benötigt werden.
- Ein geeignetes Werkzeug auswählen.
- Das Werkzeug ausführen.
- Das Ergebnis überprüfen.
- Beschließen, was als Nächstes getan werden soll.
- Möglicherweise ein anderes Werkzeug aufrufen.
- Eine endgültige Antwort erstellen.
Genau hier kommt das Konzept eines agentbasierten Systems ins Spiel.
Anthropic zieht eine nützliche Linie zwischen Abläufen und Agenten.
Ein Ablauf folgt einer festgelegten Reihenfolge von Schritten:
LLM → Step 1 → Step 2 → Step 3 → Answer
Ein Agent hingegen entscheidet selbst, welche Aktionen und Werkzeuge verwendet werden sollen:
┌──────────────┐
│ LLM │
└──────┬───────┘
│
choose action
↓
Tool
↓
Result
│
└──────────→ LLM
│
choose next action
Der entscheidende Punkt ist nicht nur, dass ein LLM irgendwo in der Pipeline zum Einsatz kommt.
Sondern vielmehr, dass das LLM selbst Einfluss darauf hat, den Prozess zu gestalten.
Anthropic betrachtet Agenten als Systeme, in denen das LLM aktiv seinen eigenen Arbeitsablauf sowie die Nutzung von Tools steuert, während herkömmliche Workflows auf einer im Voraus vom Entwickler definierten Orchestrierungslogik beruhen.
Das erweiterte LLM
Eine besonders nützliche Idee aus den Materialien von Anthropic ist das Konzept des erweiterten LLMs.
Anstatt sich ein LLM einfach als Folgendes vorzustellen:
LLM → Text
kann man es sich wie Folgendes vorstellen:
┌─────────────┐
│ LLM │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Retrieval Tools Memory
In dieser Sichtweise erhält das LLM die Fähigkeit, über seine eigenen trainierten Parameter hinauszugehen und mit externen Informationen sowie Fähigkeiten zu interagieren.
Anthropic bezeichnet das Abrufen von Informationen, den Zugriff auf Tools sowie das Speichern von Daten als Formen der Erweiterung, die ein einfaches LLM in einen grundlegenden Bestandteil für den Aufbau leistungsfähigerer agenter Systeme verwandeln.
Dies ist wichtig, weil es klarstellt, dass das Modell selbst nicht auf magische Weise in ein vollständiges Softwaresystem umgewandelt wird.
Es ist die um das Modell herum entwickelte Anwendung, die diese zusätzlichen Funktionen bereitstellt.
Was ist also Tool Calling?
Bevor wir uns MCP ansehen, hilft es, sich etwas Grundlegenderem zuzuwenden.
Stellen Sie sich vor, einem LLM wird der Zugriff auf ein Tool wie folgt gewährt:
get_weather(city)
Dann fragt ein Benutzer:
"Wie ist das Wetter in Colombo?"
Anstatt sofort zu antworten, kann das Modell mit einer Anfrage darauf reagieren, die Funktion aufzurufen:
{
"name": "get_weather",
"arguments": {
"city": "Colombo"
}
}
Die umgebende Anwendung ist es, die tatsächlich diese Funktion ausführt.
Diese Ausführung könnte etwas wie Folgendes zurückgeben:
{
"temperature": 29,
"condition": "Partly cloudy"
}
Diese Ausgabe wird wieder in das Kontextfenster des Modells eingegeben.
Von dort aus kann das Modell eine Antwort wie folgt erzeugen:
"Derzeit sind es 29°C und es ist in Colombo teilweise bewölkt."
Der entscheidende Punkt hier ist:
Das LLM entscheidet lediglich, dass ein Tool aufgerufen werden soll. Die Anwendung ist es, die es tatsächlich ausführt.
Das Modell öffnet niemals eine direkte Verbindung zum Wetterdienst selbst.
Toolaufrufe sind nicht MCP
Das ist wohl der wichtigste Unterschied, den man in diesem gesamten Bereich verstehen muss.
Toolaufrufe und MCP beheben zwei verschiedene Probleme.
Toolaufrufe drehen sich im Grunde um den Austausch zwischen:
LLM
↓
Tool request
↓
Application
↓
Tool result
MCP hingegen ist ein Protokoll, das darauf abzielt, zu standardisieren, wie KI-Anwendungen mit externen Tools, Datenquellen und Kontexten verbunden werden.
Anthropic veröffentlichte MCP im November 2024 als offenen Standard, um KI-Assistenten mit den Systemen zu verbinden, in denen die tatsächlichen Daten und Tools gespeichert sind.
Laut der eigenen Dokumentation von Anthropic standardisiert MCP die Art und Weise, wie Anwendungen Kontext an LLMs übergeben, wobei als Vergleich angegeben wird, dass es wie ein USB-C-Anschluss für KI-Anwendungen funktioniert.
Zusammenfassend:
Tool Calling
↓
How an LLM requests an action
MCP
↓
How AI applications can standardize connections
to external tools and data
Anders ausgedrückt, ergänzen sich diese beiden Konzepte gegenseitig anstatt miteinander zu konkurrieren.
Was MCP tatsächlich beiträgt
Stellen Sie sich eine KI-Anwendung vor, die auf Folgendes zugreifen muss:
- GitHub
- PostgreSQL
- Google Drive
- Slack
- das lokale Dateisystem
- interne Unternehmens-APIs
Ohne ein gemeinsames Protokoll könnte jede dieser Verbindungen eigene, maßgeschneiderte Verkabelung benötigen. Man könnte leicht zu einer solchen Konfiguration kommen:
AI Application
├── Custom GitHub integration
├── Custom Slack integration
├── Custom PostgreSQL integration
├── Custom filesystem integration
└── Custom internal API integration
MCP tritt ein, indem es ein standardisiertes Protokoll definiert, das zwischen der KI-Anwendung und den externen Systemen steht, die Funktionen bereitstellen. Konzeptionell sieht es so aus:
AI Application
│
MCP Client(s)
│
┌───────────────┼────────────────┐
↓ ↓ ↓
MCP Server MCP Server MCP Server
GitHub Database Files
│ │ │
↓ ↓ ↓
GitHub API PostgreSQL Filesystem
Durch diese Anordnung benötigt die KI-Anwendung nicht mehr umfassende, individuelle Kenntnisse über jedes Backend-System. Stattdessen stellen MCP-Server ihre Funktionen über eine gemeinsame Protokollschicht zur Verfügung.
Die MCP-Architektur
MCP basiert auf einem Client-Host-Server-Modell. Auf höherer Ebene sieht es so aus:
┌─────────────────────────────────────┐
│ HOST │
│ │
│ AI Application │
│ │
│ ┌──────────────────────────┐ │
│ │ MCP Client │ │
│ └────────────┬─────────────┘ │
└─────────────────┼───────────────────┘
│
│ MCP
↓
┌──────────────────┐
│ MCP Server │
│ │
│ Tools │
│ Resources │
│ Prompts │
└────────┬─────────┘
│
↓
External System
Die wichtigsten Rollen in dieser Architektur werden unten beschrieben.
Host
Der Host ist die KI-Anwendung, die für die Koordination der gesamten Interaktion verantwortlich ist. Dies könnte etwas wie Folgendes sein:
- eine KI-Codehilfe
- eine Desktop-KI-Anwendung
- ein Entwicklerwerkzeug
- eine maßgeschneiderte Agentenanwendung
MCP-Client
Der MCP-Client befindet sich im Host und ist dafür verantwortlich, die Verbindung zu einem MCP-Server aufrechtzuerhalten und funktionsfähig zu halten.
MCP-Server
Ein MCP-Server ist im Grunde ein Programm, das über das MCP-Protokoll Funktionen bereitstellt. Er kann Funktionalitäten anbieten, die mit Dingen wie folgendem zusammenhängen:
GitHub
Databases
Files
Cloud services
Internal systems
Development environments
Wichtig ist, dass der MCP-Server selbst kein Agent sein muss und keine KI-Logik enthalten darf. Seine Aufgabe besteht lediglich darin, bestimmte Funktionen verfügbar zu machen.
MCP umfasst mehr als nur Werkzeuge
Ein Punkt, der viele Menschen leicht in die Irre führen kann, ist die Annahme, dass MCP nichts weiter als ein „Tool-Aufruf-Protokoll“ ist. Tatsächlich definiert MCP mehrere unterschiedliche Primitiven neben Tools.
Tools
Diese sind Aktionen, die ein Modell ausführen kann, wie zum Beispiel:
create_issue()
search_repository()
query_database()
send_message()
Ressourcen
Ressourcen sind Informationen, die eine Anwendung abrufen und dem Modell als Kontext zur Verfügung stellen kann, zum Beispiel:
file://project/README.md
database://schema
Aufforderungen
MCP kann außerdem wiederverwendbare Aufforderungsvorlagen als eigenständige Primitiven bereitstellen.
Die MCP-Dokumentation von Anthropic zieht eine klare Linie zwischen denjenigen, die jeweils welche Komponenten steuern: Tools werden vom Modell gesteuert, Ressourcen von der Anwendung und Aufforderungen vom Benutzer. Diese schichtweise Steuerung macht MCP zu mehr als nur einem aufwendigen Funktionsaufrufmechanismus.
Ein vollständiges Beispiel
Nehmen wir eine Anfrage wie diese:
„Zeigen Sie mir die offenen Probleme in diesem GitHub-Repository.“
Eine vereinfachte Version des daraus resultierenden Ablaufs könnte so aussehen:
User
│
│ "Show me the open issues"
↓
AI Application
│
↓
LLM
│
│ decides a GitHub tool is needed
↓
Tool Call
│
↓
MCP Client
│
│ MCP
↓
GitHub MCP Server
│
↓
GitHub API
│
↓
Issue Data
│
↓
MCP Client
│
↓
LLM
│
↓
Final Answer
Bemerken Sie, wie viele verschiedene Schichten hier beteiligt sind. Das Modell überlegt, welche Informationen es benötigt. Die Anwendung kümmert sich um Orchestrierung und Ausführung. MCP stellt den standardisierten Kanal zum Kommunizieren mit der externen Funktionalität bereit. Der externe Dienst selbst führt die eigentliche Arbeit aus. Das sind vier getrennte Verantwortungsbereiche, keine zusammengefasste Schrittfolge.
Wo passt Docker hinein?
Oft werden MCP-Server als Docker-Container verpackt und bereitgestellt, zum Beispiel:
AI Application
│
│ stdio
↓
Docker Container
│
↓
MCP Server
│
↓
External Service
Es ist wichtig zu betonen, dass Docker an sich kein MCP ist. Docker ist lediglich eine praktische Methode, um einen MCP-Server zu verpacken und auszuführen. Derselbe Server kann genauso leicht als gewöhnlicher lokaler Prozess laufen oder als Service remote gehostet werden. Das Protokoll selbst ist völlig unabhängig davon, wie Sie es bereitstellen möchten.
STDIO gegenüber Streamable HTTP
MCP arbeitet über mehr als einen Übertragungsmechanismus.
Wenn die Integration lokal erfolgt, kann ein MCP-Client einen MCP-Server als eigenen Prozess starten und mit ihm über STDIO kommunizieren.
Konzeptionell:
AI Application
│
│ stdin/stdout
↓
MCP Server Process
In Szenarien, in denen der Server remote liegt, setzt MCP stattdessen auf Streamable HTTP.
AI Application
│
│ HTTP
↓
Remote MCP Server
Deshalb funktioniert MCP problemlos, egal ob die Tools auf dem Rechner eines Entwicklers liegen oder als gehosteter Service an einem anderen Ort laufen.
MCP gegenüber REST API
Eine weitere Unterscheidung, die hervorgehoben werden sollte, betrifft den Vergleich von MCP mit einer herkömmlichen REST API.
Eine Interaktion mit einer REST API sieht so aus:
Application
│
│ HTTP request
↓
REST API
│
↓
Data
Eine Interaktion mit MCP sieht so aus:
AI Application
│
│ MCP
↓
MCP Server
│
↓
REST API / Database / Filesystem / Other system
Interessanterweise darf ein MCP-Server im Hintergrund gerne REST APIs aufrufen.
Daher dient MCP nicht dazu, REST zu ersetzen.
Besser lässt es sich als eine für KI geeignete Schicht verstehen, die auf bereits vorhandenen Systemen basiert.
Warum MCP interessant wurde
Die Größenordnung des Integrationproblems wird klar, wenn man sich vorstellt, dass mehrere KI-Anwendungen jeweils mit verschiedenen externen Tools kommunizieren müssen.
Ohne ein gemeinsames Protokoll ergibt sich etwas wie folgt:
AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database
AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database
Jede neue Kombination aus Anwendung und Tool kann bedeuten, dass neuer Integrationsscode geschrieben werden muss.
Ein gemeinsames Protokoll verändert dieses Szenario völlig:
MCP
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Slack Database
MCP MCP MCP
Server Server Server
Im Grunde ist das der Grund, warum Anthropic MCP als offenen Standard veröffentlicht hat anstatt es nur als etwas zu betrachten, das ausschließlich für Claude entwickelt wurde.
Seitdem hat Anthropic MCP erweitert, um entfernte Server zu unterstützen, und die direkte MCP-Verbindung in seine API sowie Produkte integriert.
Aber mehr Tools machen einen Agenten nicht automatisch besser
Daran wird die spätere ingenieurtechnische Arbeit von Anthropic wirklich interessant.
Es ist leicht, anzunehmen:
Mehr Tools = leistungsstärkerer Agent.
Diese Annahme hält in der Praxis jedoch nicht stand.
Anthropics Forschung zum Tool-Design zeigt, dass Agenten tatsächlich schlechter abschneiden können, wenn ihnen zu viele überlappende oder ungenau konzipierte Tools zur Verfügung gestellt werden.
Ein gut konstruiertes Tool sollte einen einzigen, klaren Zweck haben und nützliche Informationen liefern, während unnötige Überlastung im Kontextfenster des Modells vermieden wird.
Zum Beispiel ist es effektiver, dem Agenten anstelle von drei separaten Aufrufen wie folgt eine kombinierte Funktion zur Verfügung zu stellen:
list_users()
list_transactions()
list_notes()
anstatt dessen kann es sinnvoller sein, dem Agenten eine integrierte Fähigkeit zu geben, wie zum Beispiel:
get_customer_context()
unter der Annahme, dass dies besser zu dem passt, was der Agent tatsächlich erreichen möchte.
Anders ausgedrückt wird die Tool-Schnittstelle selbst zu einem Teil der Umgebung, in der der Agent agiert.
Tools sind eine Schnittstelle für den Agenten
Diese Beobachtung weist auf eine wichtigere Idee hin, die hervorgehoben werden sollte:
Tools sollten mit dem Agenten im Blick entwickelt werden, und nicht einfach aus einer bestehenden API umverpackt werden.
Eine herkömmliche API kann hervorragend funktionieren, wenn ein deterministisches Programm sie aufruft.
Ein von einem LLM gesteuerter Agent unterliegt jedoch einer anderen Reihe von Einschränkungen.
Er muss sich mit folgendem auseinandersetzen:
- einem begrenzten Kontextfenster
- wahrscheinlichkeitsbasierten Ausgaben
- gelegentlichen Fehlern bei der Auswahl des richtigen Tools
- gelegentlichen Fehlern bei der Erstellung korrekter Parameter
- Ambiguitäten bezüglich der tatsächlichen Anfrage
Deshalb ist die Beschreibung eines Tools von großer Bedeutung.
Betrachten Sie, wie vage dies ist:
search(id)
im Vergleich dazu, wie viel klarer das hier ist:
search_github_issues(
repository,
query,
state
)
Damit das Modell ein Tool richtig nutzen kann, muss es wissen:
- was das Tool tatsächlich tut
- wann es das richtige Tool ist
- was jeder Eingabeparameter bedeutet
- welche Form die Ausgabe hat
- was das Tool nicht kann
Anthropics Leitlinien zur Tool-Entwicklung betonen präzise Benennung, klare Beschreibungen, gut definierte Parameter, nützliche Rückgaberesultate sowie kontinuierliche Bewertung.
Kontext wird zu einem wichtigen Bestandteil der Agentenentwicklung
Anthropic hat kürzlich auch die Idee des just-in-time Kontexts hervorgehoben.
Die naive Vorgehensweise bei der Handhabung von Kontexten sieht so aus:
Load everything
↓
Put everything into context
↓
Ask the LLM to reason
Der Ansatz stößt schnell auf Skalierungsprobleme.
Ein nachhaltigeres Muster sieht so aus:
Small amount of initial context
↓
Agent identifies what it needs
↓
Tool retrieves relevant information
↓
Relevant information enters context
↓
Agent continues
Anstatt alles vorab bereitzustellen, was das Modell benötigen könnte, holt der Agent Informationen nur dann ab, wenn er feststellt, dass sie tatsächlich notwendig sind.
Anthropic bezeichnet dies als Schritt in Richtung einer „just-in-time“-Kontextverarbeitung für agentbasierte Systeme.
Dies hängt direkt mit MCP zusammen.
MCP stellt den standardisierten Weg zu externen Funktionen bereit, während der Agent selbst entscheidet wann etwas abgerufen werden soll und genau was.
Der Agent-Zyklus
Sobald alle diese Komponenten zusammengefügt sind, ergibt die Gesamtarchitektur viel mehr Sinn.
Eine vereinfachte Version des Agent-Zyklus sieht so aus:
┌──────────────┐
│ User │
└──────┬───────┘
↓
┌──────────────┐
│ LLM │
└──────┬───────┘
↓
Need a tool?
/ \
No Yes
↓ ↓
Answer Tool Call
↓
Tool/MCP
↓
Tool Result
│
└─────────┐
↓
LLM
│
┌──────────┴──────────┐
↓ ↓
Continue Answer
dieser Zyklus steht im Zentrum eines großen Teils der heutzutage verwendeten agentbasierten Systeme.
Anthropic beschreibt ihn in äußerst einfachen Begriffen: Ein Agent ist im Grunde ein LLM, das innerhalb eines Zyklus Tools aufruft, wobei Rückmeldungen aus der Umgebung bestimmen, was er als Nächstes tut.
Das um diesen Zyklus herum aufgebaute System kann recht komplex werden, doch das zugrundeliegende Kernprinzip bleibt einfach.
Was ist mit Frameworks?
Frameworks wie LangGraph können das Aufbauen solcher Systeme übersichtlicher machen, indem sie eine Struktur bieten, innerhalb derer gearbeitet werden kann.
Trotzdem gibt es eine wichtige Vorsichtsmaßnahme, die man im Hinterkopf behalten sollte.
Anthropics Empfehlung lautet, zu verstehen, was unter dem Framework vor sich geht: die Rohaufrufe der LLMs, die Definitionen der Tools, die Orchestrierungslogik sowie die Antworten – anstatt das Framework als Schwarzes Loch zu betrachten.
Ein Framework macht in der Regel Dinge wie folgt zugänglich:
Agent
├── State
├── Nodes
├── Tools
├── Routing
└── Execution
Aber unter dieser Abstraktion sehen die tatsächlichen Mechanismen noch so aus:
LLM
↓
Messages
↓
Tool calls
↓
Tool execution
↓
Tool results
↓
LLM
Durch das Verständnis dieses niedrigeren Ebenenflusses wird es viel einfacher, über das Framework selbst nachzudenken, da man erkennen kann, was automatisiert wird, anstatt einfach darauf zu vertrauen, dass es funktioniert.
MCP ersetzt Agent-Frameworks nicht
Es ist wichtig zu klären, dass es sich hier um unterschiedliche Ebenen eines Systems handelt und nicht um konkurrierende Optionen.
Eine vereinfachte Stack-Struktur könnte so aussehen:
┌─────────────────────────────┐
│ User Interface │
├─────────────────────────────┤
│ Agent / Workflow │
├─────────────────────────────┤
│ LLM / Model API │
├─────────────────────────────┤
│ Tool Calling │
├─────────────────────────────┤
│ MCP │
├─────────────────────────────┤
│ External Tools / Systems │
└─────────────────────────────┘
Ein Agent-Framework verwaltet in der Regel Dinge wie:
- Zustand
- Ausführungsfluss
- Routing
- Schleifen
- Wiederholungen
- Ausführung von Tools
MCP hingegen standardisiert die Verbindung zu externen Funktionen.
Durch das Aufrufen von Tools erhält das Modell ein Verfahren, um die Ausführung einer Aktion anzufragen.
Niemand von diesen drei Elementen kann den anderen ersetzen.
Einige gängige Missverständnisse
„MCP ist ein KI-Modell.“
Das stimmt nicht.
MCP ist lediglich ein Protokoll, nichts weiter.
Es verfügt nicht über die Fähigkeit, selbst Text zu generieren oder zu reasoningen.
„MCP ersetzt Funktionsaufrufe.“
Auch das stimmt nicht.
Was tatsächlich passiert, ist, dass ein MCP-Server Tools bereitstellen kann, und eine KI-Anwendung stellt diese Tools dann über ihren vorhandenen Mechanismus zur Nutzung von Tools dem Modell zur Verfügung.
"Das LLM ruft direkt GitHub auf."
In der Regel nicht.
Das Modell erzeugt lediglich eine Anfrage zur Nutzung eines Tools.
Es sind die Anwendung sowie die zugrundeliegende Tool-Infrastruktur, die tatsächlich die Operation ausführen.
">Jeder MCP-Server benötigt Docker."
Falsch.
Docker ist nur eine mögliche Methode zur Bereitstellung eines Servers.
MCP befasst sich mit der Kommunikation und der Bereitstellung von Funktionalitäten, nicht damit, wie etwas konteiniert wird.
">Ein MCP-Server ist ein KI-Agent."
Nicht unbedingt.
Ein MCP-Server kann auch einfach nur einfache, deterministische Operationen bereitstellen, wie zum Beispiel:
search()
read()
create()
update()
delete()
">MCP ist nur für GitHub nützlich."
Keineswegs.
MCP wurde als universelles Protokoll entwickelt, um KI-Anwendungen mit externen Daten und Funktionen zu verbinden. Die ursprüngliche Ankündigung von Anthropic wies bereits auf Integrationen in Systeme wie GitHub, Slack, Google Drive, Datenbanken sowie verschiedene Entwicklungsumgebungen hin.
Die wichtigere Erkenntnis: Agentenentwicklung ist nicht nur Prompt-Engineering
Das ist wohl der bedeutendste Perspektivwechsel, der sich aus dem Studium dieses Materials ergibt.
Die Entwicklung wirklich nützlicher agentenbasierter Systeme ist nicht nur eine Frage von:
Write a clever prompt
↓
Use a powerful model
↓
Get a smart agent
Es sind mehrere unterschiedliche Engineering-Ebenen beteiligt:
Model
↓
Tool Selection
↓
Tool Definitions
↓
Tool Execution
↓
Context Management
↓
State / Memory
↓
Control / Guardrails
↓
Evaluation
Anthropics eigene technische Schriften legen zunehmend Wert auf diese umfassendere, systembezogene Sichtweise darauf, was die Entwicklung eines Agenten tatsächlich erfordert.
Als Beispiel dient ihre jüngste Arbeit zur Bewertung von Agenten, die sich auf die Beurteilung mehrschrittigen Verhaltens, der Werkzeugnutzung, von Zustandsänderungen sowie der Anpassung im Laufe der Zeit konzentriert – anstatt die Qualität ausschließlich am letzten generierten Textabschnitt zu beurteilen.
Das stellt einen deutlich anderen Ansatz bei der Gestaltung von KI-Anwendungen dar.
Der Teil, der mir am interessantesten erscheint
Der entscheidende Übergang ist eigentlich nicht:
Chatbot → Agent
Eher genau gesagt:
LLM
↓
LLM + Tools
↓
LLM + Tools + External Context
↓
LLM + Tools + Context + Control Loop
↓
Agentic System
MCP fügt sich in diesen Entwicklungsprozess ein, indem es KI-Anwendungen eine standardisierte Möglichkeit bietet, auf externe Fähigkeiten zuzugreifen.
Das Modell liefert die Intelligenz.
Die Anwendung übernimmt die Steuerung.
Werkzeuge liefern die Aktionen.
Externe Systeme stellen Informationen und Fähigkeiten aus der realen Welt bereit.
MCP stellt die standardisierte Verbindungsstufe dar, die KI-Anwendungen mit diesen Fähigkeiten verknüpft.
M mein aktuelles mentales Modell
Nachdem ich mich mit Tool Calling, MCP sowie Anthropics umfassenderen Schriften zu agierenden Systemen auseinandergesetzt habe, ist dies das einfachste architektonische Bild, das zeigt, wie all diese Komponenten zusammenpassen:
USER
│
↓
┌─────────────┐
│ LLM │
│ │
│ Reasoning │
│ Decision │
└──────┬──────┘
│
Tool request
│
↓
┌─────────────────┐
│ Agent Runtime │
│ │
│ State │
│ Control Flow │
│ Tool Execution │
└────────┬────────┘
│
↓
MCP / Tools
│
┌────────────┼────────────┐
↓ ↓ ↓
GitHub Database Files
│ │ │
└────────────┼────────────┘
↓
Tool Results
│
↓
LLM
│
↓
USER
Das Modell allein ist nicht das gesamte Agenten-System.
Ebenso wenig ist es ein einzelnes Tool.
Auch MCP allein reicht nicht aus.
Was tatsächlich als „der Agent“ entsteht, ergibt sich aus dem System um das Modell herum – jenem Teil, der es ermöglicht, zu reasoningen, Aktionen auszuführen, zu beobachten, was passiert, und weiterhin auf ein Ziel hinzuarbeiten.
Fazit
Falls Sie AI-Agenten entwickeln möchten, gibt es vier Konzepte, die man gründlich beherrschen sollte:
1. Tool Calling
Das Modell kann die Anwendung bitten, ein bestimmtes Tool auszuführen.
2. Agenten-Schleifen
Das System kann wiederholt über eine Situation reasoningen, darauf reagieren, das Ergebnis beobachten und von dort aus fortfahren.
3. MCP
Ein standardisiertes Protokoll zur Verbindung von KI-Anwendungen mit externen Tools, Ressourcen und Kontexten.
4. Tool-Engineering
Die Qualität Ihrer Tools, ihre Beschreibungen, ihre Parameter, der von ihnen zurückgegebene Kontext sowie die Qualität ihrer Bewertung können maßgeblich darüber entscheiden, wie gut ein Agent tatsächlich funktioniert.
Vielleicht ist die wertvollste Lektion aus Anthropics ingenieurtechnischen Praktiken folgende:
Fügen Sie keine Komplexität hinzu, nur weil Sie dazu in der Lage sind.
Begonnen wird mit der einfachsten Architektur, die in der Lage ist, das vorliegende Problem zu lösen. Workflow-Systeme, zusätzliche Agenten, weitere Tools, Speicher, MCP-Server und andere Komponenten werden erst hinzugefügt, wenn sie einen konkreten Nutzen bringen.
Ziel war niemals es, den möglichst ausgefeilten Agenten zu erstellen.
Ziel ist es, ein System zu entwickeln, das die Aufgabe zuverlässig erledigt.