Fortgeschrittene Algorithmen und Programmierung
Prof. Dr. Alexandra Mikityuk
HTW Berlin
2026 ist KI nicht mehr „nice to have" — sie sitzt in jeder Entwickler-Toolchain (Copilot, Claude Code, Cursor). Wer sie nicht versteht, wird produktivitätsmäßig abgehängt.
Die Konzepte LLM/Agent/MCP sind nicht magisch — es sind Algorithmen + Protokolle. Heute zerlegen wir sie systematisch — mit Code, nicht nur mit Buzzwords.
In einem Satz: ein neuronales Netz, das die nächste Worteinheit (Token) vorhersagt — gegeben den bisherigen Text.
Ein Token ist eine Worteinheit — ca. 3-4 Zeichen oder ein kurzes Wort. Beispiel:
"Hallo Welt!" → ["Hallo", " Welt", "!"] → [15043, 4435, 0] (Zahlen)
Das LLM sieht nur Zahlen, niemals Buchstaben direkt.
Bei Input "Die Hauptstadt von Frankreich ist" gibt das LLM für jedes mögliche nächste Token eine Wahrscheinlichkeit aus:
"Paris" → 92% "Berlin" → 2% "Lyon" → 1% …
Vor 2017: RNNs/LSTMs verarbeiteten Text sequenziell — langsam, kurzer Kontext. Der Transformer („Attention is all you need", Vaswani et al. 2017) änderte alles.
Wie hat man Text vor 2017 verarbeitet? Mit sequenziellen Netzen — und das war das Problem.
Verarbeitet Text Wort für Wort, sequenziell — wie Lesen von links nach rechts.
Jedes Wort wird verarbeitet, ein „Gedächtnis" (Hidden State) wird weitergegeben.
Verbesserte RNN mit einem „Notizbuch": kann gezielt Informationen merken oder vergessen.
Hat „Gates" (Tore), die steuern, welche Infos behalten und welche verworfen werden.
Gigantische Text-Mengen (Internet, Bücher) → das Modell lernt Sprache vorherzusagen. Statistisch nächstes Token bei beliebigem Input.
Dauer: Wochen bis Monate · Kosten: 10 Mio. € aufwärts
Kleinere Datensätze mit Q&A-Paaren: „Frage X → gute Antwort Y". Das Modell lernt, hilfreich zu antworten — nicht nur Text fortzusetzen.
Reinforcement Learning from Human Feedback: Menschen bewerten Antworten, das Modell wird auf „präferierte" Antworten getrimmt. Macht es höflich, sicher, hilfreich.
| Modell | Anbieter | Stärken | Context |
|---|---|---|---|
| Claude 4.x (Opus, Sonnet, Haiku) | Anthropic | Code, Reasoning, Tool-Use | bis 1 Mio. Tokens |
| GPT-5 | OpenAI | Generalist, Multimodal | ~ 400k Tokens |
| Gemini 2.x | Multimodal, große Context-Fenster | 2+ Mio. Tokens | |
| Llama 4 | Meta | Open-Weight, lokal lauffähig | ~ 128k Tokens |
| Mistral / DeepSeek | EU / China | Effizient, Open-Weight | 32k-200k Tokens |
Realistische Erwartungen — was ein LLM standalone kann, und wo es scheitert.
Die maximale Anzahl Tokens, die das Modell in einem Request sehen kann — Input + Output zusammen.
Bei 1 Mio. Tokens (Claude Opus): ca. 750 000 Wörter — ein ganzes Buch passt rein.
Wichtig: Tokens kosten Geld. Längerer Context = teurer API-Aufruf.
Ein Parameter (0.0 - 1.0) der die Zufälligkeit der Antwort steuert:
0.0 — immer das wahrscheinlichste Token (deterministisch)1.0 — sehr variabel, kreativCode-Generierung: 0.0 - 0.3. Brainstorming: 0.7 - 1.0.
Das Modell erfindet plausible, aber falsche Fakten — weil es nur statistisch vorhersagt, nicht „weiß".
Beispiel: Frage nach einem Paper-Titel → das Modell erfindet einen, der nie existierte, aber stilistisch passt.
Statt sich auf Modell-„Wissen" zu verlassen: relevante Dokumente aus einer Datenbank abrufen, in den Prompt einfügen, dann antworten lassen.
Ablauf: Frage → Dokumente suchen → an Prompt anhängen → Modell antwortet mit Kontext.
Die KI-Engine für Entwickler, die wir hier nutzen. Läuft in zwei Modi.
# Claude Code starten
$ claude
# Beispiel-Prompts:
> Erkläre mir dieses Projekt
> Finde den Bug in server.py
> Schreibe Unit-Tests für api.py
Vier Regeln, die 80% des Unterschieds zwischen brauchbaren und unbrauchbaren Antworten ausmachen.
"Mach mir eine API"
"Erstelle einen REST-Server in
Python mit Flask:
- GET /api/sensors → Liste (JSON)
- POST /api/sensors → Hinzufügen
- Verwende SQLite
- Füge Error-Handling hinzu"
Bisher: ein Prompt → eine Antwort. Aber moderne KI-Anwendungen brauchen mehr: mehrere Schritte, externe Daten, Aktionen in der Welt.
| Stufe | Was kann's? | Beispiel |
|---|---|---|
| Chat-LLM | antwortet auf Frage | ChatGPT-Tab |
| + Tool-Use | kann externe Tools aufrufen (Web-Suche, Rechner) | ChatGPT mit Browser-Plugin |
| Agent | plant, ruft Tools in Schleife, korrigiert sich | Claude Code, Cursor, Auto-GPT |
| Multi-Agent | spezialisierte Agenten arbeiten zusammen | komplexe Workflows |
Definition: ein Agent ist ein LLM, das in einer Schleife läuft, Tools aufrufen kann und autonom entscheidet, welcher Schritt als nächstes kommt.
Schritt 1 → beobachte Ergebnis → Schritt 2 → … bis Ziel erreicht oder Limit.
Funktionen, die der Agent aufrufen kann: Datei lesen, HTTP-Request, Bash-Command, Datenbank-Query.
Der Agent entscheidet selbst, welches Tool wann — kein hartgekodeter Ablauf.
Wiederholt sich, bis Modell kein Tool mehr aufruft (= „Aufgabe erledigt").
while-Schleife in der Host-Anwendung — solange das Modell ein tool_use-Block zurückgibt, ausführen + Ergebnis anhängen + erneut fragen.
Wir geben Claude ein Tool zum Wetter-Abfragen — und lassen es entscheiden, wann es dieses ruft.
# 1. Tool definieren — JSON-Schema
tools = [{
"name": "get_weather",
"description": "Aktuelles Wetter für eine Stadt",
"input_schema": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"]
}
}]
# 2. Anfrage mit Tools
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=1024,
tools=tools,
messages=[{"role": "user", "content": "Wie ist das Wetter in Berlin?"}]
)
# 3. Claude antwortet mit tool_use Block
if response.stop_reason == "tool_use":
tool_call = response.content[0]
# tool_call.name = "get_weather"
# tool_call.input = {"city": "Berlin"}
result = get_weather(tool_call.input["city"]) # unsere Funktion
# 4. Ergebnis zurück an Claude, fragen weiter
final = client.messages.create(
model="claude-opus-4-7", max_tokens=1024, tools=tools,
messages=[
{"role": "user", "content": "Wie ist das Wetter in Berlin?"},
{"role": "assistant", "content": response.content},
{"role": "user", "content": [{"type": "tool_result",
"tool_use_id": tool_call.id, "content": result}]}
]
)
print(final.content[0].text) # "In Berlin ist es heute 18°C…"
Statt einem großen Agent: mehrere spezialisierte Agenten, koordiniert von einem Orchestrator.
Jede Host-App (Claude Desktop, Cursor, Claude Code) braucht Zugriff auf Tools und Daten. Bisher: jede App implementiert ihre Integration selbst → Code-Duplikation, inkompatibel.
Bei M Hosts und N Datenquellen = M × N Integrationen. Jede Tool-Anbindung muss für jeden Host neu geschrieben werden.
Standardisiertes Protokoll (JSON-RPC). Tool-Anbieter implementieren einmal einen MCP-Server. Hosts implementieren einmal einen MCP-Client. Fertig.
Drei Rollen, klar getrennt.
Die App, in der das LLM läuft. Z.B. Claude Desktop, Claude Code, Cursor. Sie spricht mit dem LLM und mit den MCP-Servern.
Im Host eingebaut: spricht das MCP-Protokoll (JSON-RPC), verbindet zu Servern, ruft deren Tools auf.
Stellt Tools/Resources/Prompts zur Verfügung — z.B. Filesystem-Zugriff, GitHub-API, Datenbank. Wird vom Host gestartet.
MCP nutzt JSON-RPC 2.0 — ein einfaches Request/Response-Format.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": {
"path": "/etc/hosts"
}
}
}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [{
"type": "text",
"text": "127.0.0.1 localhost..."
}]
}
}
Mit pip install mcp ist das offizielle SDK installiert.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("htw-tools")
@mcp.tool()
def grade_lookup(student_id: str) -> str:
"""Liefert die Note eines Studierenden anhand seiner Matrikelnummer."""
# Hier würdest du eine DB abfragen — vereinfacht hardcoded:
grades = {"12345": "1.7", "67890": "2.3"}
return grades.get(student_id, "keine Note gefunden")
@mcp.tool()
def average(numbers: list[float]) -> float:
"""Berechnet den Durchschnitt einer Liste von Zahlen."""
return sum(numbers) / len(numbers)
if __name__ == "__main__":
mcp.run() # startet stdio-Server
@mcp.tool()-Decorator-Magie macht JSON-Schema-Generierung + Routing automatisch. Funktions-Signatur + Docstring → fertiges Tool.
Wir verbinden den MCP-Server von eben mit Claude Desktop / Claude Code.
In Claude Desktop / Claude Code legt man eine Config-Datei an. Beispiel ~/.claude/mcp.json:
{
"mcpServers": {
"htw-tools": {
"command": "python",
"args": ["/Users/htw/server.py"]
}
}
}
python server.pygrade_lookup + averageAnthropic + Community pflegen einen großen Pool — meistens reicht: installieren, konfigurieren, fertig.
Dateien lesen/schreiben in einem Sandbox-Verzeichnis. Der Standard für IDE-Integration.
Issues, PRs, Code-Suche. Claude kann Issues triagieren, PRs reviewen, Releases erstellen.
SQL-Queries gegen eure DB ausführen lassen. Vorsicht: nur read-only empfehlen!
Brave Search, Fetch, Puppeteer. Live-Recherche zur Laufzeit.
Nachrichten posten, Tickets erstellen — Anbindung an Team-Workflow.
Wir bauen unseren eigenen für die Klausur-DB im Lab.
Dateien werden 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 den Rechner.
KI-generierten Code immer prüfen — Sicherheitslücken möglich! Vor allem Input-Validation, Auth-Checks, SQL-Strings.
Nie in Prompts oder Code einfügen. Immer .env-Dateien + Umgebungsvariablen nutzen.
Nur vertrauenswürdige Quellen. Code vorher lesen! Ein fremder MCP-Server bekommt Tool-Use-Anweisungen vom LLM — er kann viel anstellen.
Ollama, LM Studio — alles bleibt auf dem Rechner. Für vertrauliche Projekte (Firma, Forschung) ideal.
Fragen?
Prof. Dr. Alexandra Mikityuk
HTW Berlin · Büro Raum 308
Tel +49 30 5019-2664
Nächste Woche: Sicherheit I — Hashing & Passwörter