Verteilte Systeme — Vorlesung 3
Prof. Dr. Alexandra Mikityuk · HTW Berlin · Sommersemester 2026
✓ LLMs sagen das nächste Token vorher
✓ Transformer: Self-Attention, parallele Verarbeitung
✓ Training: Pre-Training → Fine-Tuning → RLHF
✓ Claude: Coding-stark, langes Kontextfenster
✓ Senior Developer Workflow: Sie designen, KI implementiert
✓ Halluzinationen: Immer testen & verifizieren!
Heute: Was passiert, wenn ein LLM nicht nur antwortet — sondern handelt?
Benutzer fragt, KI antwortet. Kein Zugriff auf externe Daten.
"Wie erstelle ich einen Socket-Server?" → Antwort als Text
KI kann Werkzeuge aufrufen: Dateien lesen, APIs nutzen, Berechnungen durchführen.
"Lies server.py und finde den Bug" → Datei wird gelesen
KI plant, entscheidet und handelt autonom. Nutzt mehrere Tools in einer Schleife.
"Fixe alle Bugs in diesem Projekt" → Plant, liest, fixt, testet
Claude Code ist ein Agent — er liest Ihren Code, entscheidet was zu tun ist, schreibt Dateien, führt Tests aus und iteriert bis zur Lösung.
➡️ Aber was steckt eigentlich in so einem Agenten? Schauen wir uns die Bauteile an.
Agent = LLM + Werkzeuge + Schleife
Chat ANTWORTET nur. Ein Agent HANDELT — und braucht dafür mehrere Schritte.
# Start: User-Frage als erste Aktion
action = user_prompt
while not done:
# 🛠️ Tool führt Aktion aus
observation = tool.execute(action)
# 🧠 LLM schaut Ergebnis an,
# entscheidet nächste Aktion
action = llm.decide(observation)
Schleife endet, sobald das LLM sagt: „Ich bin fertig".
Szenario: Ein Python-Projekt mit zwei Dateien:
📁 main.py · utils.py
Aufgabe: „Finde alle TODO-Kommentare im Code"
| # | 🧠 LLM-Aktion | 🛠️ Beobachtung |
|---|---|---|
| 1 | list_files(".") | main.py, utils.py |
| 2 | read("main.py") | (Datei-Inhalt) |
| 3 | grep "TODO" | 2 Treffer ✓ |
| 4 | read("utils.py") | (Datei-Inhalt) |
| 5 | grep "TODO" | 0 Treffer |
| 6 | FERTIG — Antwort liefern | — |
6 Iterationen — keiner der zwei Akteure könnte das alleine.
In genau diesem Moment, während ihr zuhört, läuft auf euren Rechnern ein KI-Agent — und ihr merkt es nicht mal.
Sein Name: Claude Code.
🏠 Host: Claude Code
VSCode-Extension auf eurem Rechner
🤖 Agent: der Loop
fest in Claude Code eingebaut
🧠 LLM: Claude Opus 4.7
in Anthropic's Cloud, über das Internet
🛠️ Tools: Read · Edit · Write · Bash · Grep · TodoWrite · Agent (für Subagents)
Ihr tippt: „Fixe den Bug in main.py"
| # | Wer | Was passiert |
|---|---|---|
| 1 | Host | schickt Frage + Datei-Liste an Anthropic-API |
| 2 | LLM | denkt: „brauche Read("main.py")" |
| 3 | Agent | prüft: ist Read erlaubt? → ja |
| 4 | Host | öffnet die Datei wirklich, liest die Bytes |
| 5 | LLM | findet Bug, plant: „brauche Edit(…)" |
| 6 | Agent | fragt euch: „Edit OK?" → ihr drückt ja |
| 7 | Host | schreibt Bytes, zeigt Diff im Editor |
Im Lab nutzt ihr genau diese Schleife — jede Anfrage an Claude Code läuft durch dieses Schema. Multi-Agent inklusive: wenn ich (das LLM) sage „Agent(Explore, …)", startet Claude Code einen zweiten Agenten für die Subaufgabe.
➡️ Schauen wir uns die Schleife jetzt im Detail an — auf Code-Ebene.
Wir haben die Schleife jetzt zweimal gesehen — abstrakt (Slide 4) und live in Claude Code (Slide 5).
Jetzt zoomen wir rein — was passiert in jeder einzelnen Iteration auf Code-Ebene?
„Agentic Loop" ist der englische Industrie-Begriff für genau diese Schleife. Seit 2023 das Herzstück von jedem Tool, das wirklich „Agent" heißt.
1. Observe — Kontext erfassen (Dateien, Fehler, User-Prompt)
2. Think — Situation analysieren, nächsten Schritt planen
3. Act — Tool aufrufen (Datei lesen, Befehl ausführen, …)
4. Observe — Ergebnis auswerten → zurück zu 2 (oder fertig)
# Agentic Loop
def agent_loop(user_prompt):
context = user_prompt
while True:
# 🧠 Think
plan = llm.think(context)
if plan.is_done:
return plan.answer
# 🛠️ Act
result = execute_tool(
plan.tool, plan.args)
# 👀 Observe
context += result
Wo läuft dieser Loop gerade jetzt? In Claude Code, Cursor, GitHub Copilot Agent, ChatGPT mit Tools, Devin — überall derselbe Pattern: Reason · Act · Observe.
➡️ Damit dieser Loop überhaupt funktioniert, braucht ein Agent eine bestimmte Architektur. Die schauen wir uns als Nächstes an.
Benutzer
→
Agent (LLM)
→
Tool 1: Dateisystem
Tool 2: API
Tool 3: Terminal
Drei Bausteine: Benutzer-Anfrage · das LLM als Steuerzentrale · eine Sammlung von Tools. Verbunden durch den Agentic Loop aus Slide 5.
➡️ Aber wie genau ruft der Agent eigentlich ein Tool auf? Das ist subtiler als es aussieht — gleich mehr.
Der Agent „ruft" kein Programm auf — er erzeugt einen strukturierten JSON-Request, der Agent-Host führt ihn aus.
Was ist der Agent-Host? Das Programm, in dem der Agent läuft — z.B. Claude Code, Claude Desktop, Cursor oder dein eigenes Python-Skript.
{
"tool": "read_file",
"args": {
"path": "server.py"
}
}
# Host liest die Datei
content = read_file(
"server.py"
)
# Ergebnis → zurück an LLM
# LLM sieht den Inhalt
# und entscheidet:
# → Bug auf Zeile 42
# → nächster Schritt:
# write_file(...)
Wichtig: Das LLM führt nie selbst Code aus! Es schickt nur den Wunsch als JSON. Der Agent-Host entscheidet, ob und wie er ausgeführt wird. Deshalb fragt Claude Code dich um Erlaubnis, bevor er etwas tut.
➡️ Bisher reden wir von einem Agenten. Was, wenn mehrere zusammenarbeiten müssen?
Mehrere KI-Agenten arbeiten zusammen — jeder mit eigener Rolle und eigenen Werkzeugen.
Zerlegt komplexe Aufgaben in Teilschritte. Koordiniert andere Agenten.
Schreibt Code, erstellt Dateien, implementiert Features.
Führt Tests aus, meldet Fehler zurück an den Coder.
Verbindung zu Verteilte Systeme: Multi-Agent = verteiltes System! Mehrere Prozesse, Nachrichtenaustausch, kein gemeinsamer Speicher, Koordination nötig. Genau das lernen wir in diesem Kurs.
➡️ Multi-Agent ist die eine Skalierung. Aber zurück zur Frage von Slide 7: woher kennt ein Agent überhaupt seine Tools? Wer sagt ihm, was sie können? Hier kommt MCP ins Spiel.
Beispiele für MCP-Server:
😶
✅
// Client → Server
{
"method": "tools/list"
}
// Server → Client
{
"tools": [
{"name": "get_weather",
"description": "...",
"inputSchema": {...}}
]
}
// Client → Server
{
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"city": "Berlin"
}
}
}
// Server → Client
{
"content": [{
"type": "text",
"text": "Wetter in
Berlin: 18°C,
bewölkt"
}]
}
Das ist JSON-RPC über stdio oder HTTP — ein klassisches Client-Server-Protokoll, wie wir es in Verteilte Systeme lernen!
Wie ein Telefongespräch: erst „Hallo!", dann reden, dann auflegen. Eine MCP-Session läuft immer in dieser Reihenfolge ab.
Schritte 5+6 wiederholen sich: der Client kann beliebig viele Tools aufrufen — die Session bleibt offen, wie ein laufendes Telefongespräch. Am Ende: shutdown.
MCP sagt nur, was in den Nachrichten steht (das Format).
Wie die Bytes von A nach B kommen, ist eine eigene Frage.
📨 MCP-Nachricht (JSON) → 🚚 Transport → 📨 Empfänger
Wie ein Brief: der Inhalt ist das eine, die Postzustellung das andere.
Dieselbe Technik, mit der euer Browser Webseiten lädt. MCP-Nachrichten gehen als HTTP-Requests übers Netzwerk.
HTTP im Detail kommt in einer späteren Vorlesung.
Für spezielle Fälle existieren weitere Transports: schnellere Varianten für lokale Setups, dauerhafte Verbindungen, …
Details, wenn ihr tiefer in Netzwerk-Protokolle einsteigt.
Take-away: MCP ist die Sprache. Der Transport ist die Leitung. Für heute reicht: meistens HTTP, manchmal andere.
Programme reden auf vier verschiedene Arten miteinander. MCP ist eine davon — speziell für AI:
Im selben Programm: summe = add(2, 3). Schnell, aber alles muss zusammen sein.
Programm A schreibt eine Datei, Programm B liest sie später. Einfach, aber asynchron.
Wie eine Bestellung im Restaurant: Anfrage rein, Antwort raus. (REST, GraphQL, gRPC — kommt später!)
Einheitlicher Stecker zwischen LLM und Tools — egal welche App, egal welches Tool.
USB-Analogie: vor USB hatte jedes Gerät seinen eigenen Stecker. Heute: ein Stecker für alles. MCP ist USB für AI.
Alle verfügbar auf: modelcontextprotocol.io — Open Source, Community-getrieben. Sie können auch Ihren eigenen MCP-Server bauen!
Jeder MCP-Server hat dieselben vier Bauteile. Schauen wir uns einen Wetter-Server an:
# ① Server-Objekt
from mcp.server import Server
server = Server("wetter")
# ② Tool-Decorator
@server.tool()
async def get_weather(city: str) -> str:
"""Aktuelles Wetter abrufen."""
# ③ Tool-Logik
return f"In {city}: 18°C"
# ④ Server starten
server.run()
① Server-Objekt — die Hülle. Bekommt einen Namen, mit dem er sich bei Clients meldet.
② Tool-Decorator — sagt: „diese Funktion ist ein Tool, das Clients aufrufen dürfen". Name + Typen werden automatisch ins MCP-Schema übersetzt.
③ Tool-Logik — was wirklich passiert, wenn der Tool aufgerufen wird (API-Call, Datei lesen, DB-Query, …).
④ Server starten — wartet auf Verbindungen und MCP-Nachrichten von Clients.
Mehr Tools? Einfach weitere @server.tool()-Funktionen darunter schreiben — der Server stellt sie automatisch allen Clients zur Verfügung.
So gibt man Claude Tools — direkt im Python-Code, ohne MCP:
import anthropic
client = anthropic.Anthropic()
# 1. Wir definieren das Tool selbst (Schema von Hand)
tools = [{
"name": "get_weather",
"description": "Aktuelles Wetter abrufen",
"input_schema": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"]
}
}]
# 2. Tools mit der Anfrage an Claude schicken
response = client.messages.create(
model="claude-sonnet-4-6",
tools=tools,
messages=[{"role": "user",
"content": "Wie ist das Wetter in Berlin?"}]
)
# Claude antwortet: „Ich brauche get_weather(city='Berlin')"
# → wir müssen die Funktion JETZT selbst aufrufen + Antwort zurückschicken
Problem: Bei jedem neuen Tool müssen wir das Schema schreiben, die Funktion bauen, das Tool ausführen und die Antwort zurückschicken. Bei 50 Tools wird das mühsam.
Lösung: MCP — der Server liefert die Tool-Definitionen automatisch, der Client muss nichts hardcoden.
Mit MCP: Server einmal schreiben — alle Clients (Claude Code, Claude Desktop, dein Python-Programm) nutzen ihn.
from mcp.server import Server
server = Server("wetter")
@server.tool()
async def get_weather(city: str) -> str:
"""Wetter für eine Stadt."""
return f"In {city}: 18°C"
server.run() # läuft auf Port 8000
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-6",
mcp_servers=[{
"name": "wetter",
"url": "http://localhost:8000"
}],
messages=[{"role": "user",
"content": "Wetter Berlin?"}]
)
Magie: der Client weiß nicht, welche Tools der Server bietet. Er fragt automatisch nach (tools/list aus dem Lebenszyklus!) — Claude entscheidet, welches Tool er braucht.
Derselbe Server funktioniert mit Claude Code, Claude Desktop, deinem eigenen Programm — überall.
Problem: Claude Code weiß nicht von alleine, welche MCP-Server auf deinem Rechner laufen sollen.
Lösung: eine Config-Datei mit einer Liste der Server, die Claude Code beim Starten automatisch hochfahren soll.
Datei: ~/.claude/settings.json
{
"mcpServers": {
"filesystem": { // Name den DU vergibst
"command": "npx", // welches Programm starten
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/pfad"]
}, // ↑ Argumente fürs Programm
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "ghp_xxx" } // geheime Daten
}
}
}
Pro Server brauchst du drei Dinge: command (welches Programm) + args (Parameter dafür) + optional env (Umgebungsvariablen, z.B. API-Tokens).
Beim Claude-Code-Start: liest die Datei → startet alle Server → ihre Tools sind sofort für Claude verfügbar.
Was ist npx? Ein Tool aus der Node.js-Welt: lädt ein npm-Paket runter, führt es einmal aus, fertig (kein dauerhafter Install). Hier startet es den MCP-Server, der als npm-Paket veröffentlicht ist. command könnte auch python, node oder eine eigene Binary sein.
Aber: Langsamer, weniger fähig (SLMs), braucht gute GPU (16GB+ VRAM ideal)
Aber: Daten verlassen Ihren Rechner, Internetabhängig, Kosten
Best Practice: Entwicklung mit Cloud-KI, sensible Daten lokal. Ollama + MCP = lokaler Agent!
➡️ Wenn wir uns für Cloud entscheiden — wohin genau gehen unsere Daten dann? Schauen wir es uns an.
Falsche Intuition: „Wenn der MCP-Server lokal läuft, bleiben meine Daten lokal." — Stimmt nicht.
Dateien werden zwar lokal gelesen — aber der Inhalt geht ans LLM in der Cloud. Anthropic sieht ihn.
Z.B. Ollama als LLM + lokaler MCP-Server. Erst dann verlässt nichts deinen Rechner.
Faustregel: Sensible Daten (Passwörter, API-Keys, Firmendaten) NIEMALS an MCP-Server geben, deren Output an ein Cloud-LLM weitergegeben wird.
KI-generierten Code immer prüfen — Sicherheitslücken möglich!
Nie in Prompts oder Code einfügen. Immer Umgebungsvariablen nutzen.
Nur vertrauenswürdige Quellen. Code vorher lesen!
Ollama, LM Studio — alles bleibt auf dem Rechner. Für sensible Projekte ideal.
Verschlüsselung: Wenn MCP über Netzwerk, dann nur über verschlüsselte Kanäle!
Never trust, always verify — auch bei KI!
Zero-Trust ist ein Grundprinzip verteilter Systeme — es gilt genauso für KI-Agenten wie für Microservices.
Sichere Kommunikation: Wie können KI-Agenten sicher über Netzwerke kommunizieren?
E2E-Verschlüsselung: Ende-zu-Ende-Verschlüsselung für Agent-to-Agent Kommunikation
Dezentrale KI: Dezentrale Infrastruktur statt Cloud-Abhängigkeit
Verifiable AI: Wie kann man die Integrität von KI-Antworten nachweisen?
Zero-Trust: MCP über sichere Tunnel — Zero-Trust-Architektur für KI-Tools
Sobald MCP über Netzwerk läuft (egal ob Café-WiFi oder Firmen-LAN), gelten klassische Angriffe.
„Intern" ist nicht automatisch sicher.
10.0.5.20:8080query_db("SELECT * FROM customers")Warum: Server lauscht auf offenem Port, keine Auth, jeder im LAN kann anrufen — auch ein gehackter Drucker.
Wie: Beide Seiten bauen ausgehende Verbindung zum Relay auf — kein lauschender Port, mutual auth via Schlüssel.
Bezug zu VS: Das ist Interprozesskommunikation über sichere Kanäle — kombiniert mit Zero-Trust (kein implizites Vertrauen, weder draußen noch drinnen). Kernthema dieses Kurses.
Praxis-Tools: Tailscale · WireGuard · mTLS-only HTTPS · Cloudflare Tunnel · Zero-Trust-Mesh-Networks
KI-Agenten SIND verteilte Systeme!
Deshalb lernen Sie beides: Die Prinzipien verteilter Systeme helfen Ihnen, KI-Agenten-Systeme zu verstehen, zu bauen und zu debuggen.
✓ Von Chat zu Agent: Die Evolution
✓ Agentic Loop: Observe → Think → Act
✓ Tool Use: JSON-basierte Werkzeugaufrufe
✓ Multi-Agent Systeme = Verteilte Systeme
✓ MCP: Standardprotokoll für KI-Tools
✓ MCP-Server konfigurieren & selbst bauen
✓ Lokale vs. Cloud KI
✓ Zero-Trust & Sicherheit bei KI-Tools
✓ Sichere KI-Infrastruktur (Staex)
✓ Agenten = Verteilte Systeme in der Praxis
Fragen?
Prof. Dr. Alexandra Mikityuk
Büro Raum 308
Tel +49 30 5019-2664
Nächste Woche: Prozesse, Threads & Nebenläufigkeit