ki-buch/teil-01-grundlagen/kapitel-01-evolution-sprachmodelle.md

Kapitel 1: Warum Agenten jetzt? – Evolution in acht Minuten

Teil I · Vom Modell zum Agenten-Problem

---

Auffrischung – überspringbar. Wenn du Tool-Use und Agent-Loops bereits produktiv nutzt, weiter zu Kapitel 3.

„Plötzlich können Modelle codebasierte Projekte steuern“ klingt nach Intelligenzsprung – und verdeckt den eigentlichen Treiber. Was sich geändert hat, ist die Schnittstelle zur Welt: von reiner Textvervollständigung über Chat-Messages und Function Calling bis zu Agent-Loops mit Tools, Hosts und Verifikation. Parallel explodierten Editoren, CLIs und interne Plugins – und mit ihnen der Lock-in über Integrationen, nicht nur über Modellgewichte.

These: Heutige Coding Agents sind das Ergebnis einer API- und Systemevolution, nicht einer magischen Emergenz. Wer das versteht, trennt Modellwahl von der Integrationsschicht und erkennt, warum portable Capabilities (später: MCP) architektonisch Sinn ergeben.

Leitfrage: Welche Systemschritte von Completion zu Agent erzwingen Kontext, Tools und Verifikation – und wo entsteht Lock-in?

Dieses Kapitel ist keine ML-Geschichte und kein Paper-Review. Es verdichtet die Evolution in lesbarer Form: Transformer-Konsequenzen, die du brauchst; den Übergang Completion → Chat → Tools → Agent; Open- vs. Closed-Models als Trade-off; den unterschätzten Lock-in über Tools und Plugins. Kapitel 2 liefert danach die Betriebsphysik (Tokens, Window, Host als Prompt-Compiler).

Lernziele

Nach diesem Kapitel kannst du:

• den Übergang Completion → Chat → Tool Use → Agent als Systemevolution beschreiben,
• Open- vs. Closed-Models als Trade-off-Matrix (nicht als Glaubensfrage) bewerten,
• den unterschätzten Lock-in über Tools und Plugins benennen,
• begründen, warum mit wachsender Host- und Tool-Vielfalt portable Capabilities (später: MCP) architektonisch sinnvoll werden – ohne das Protokoll hier im Detail zu lernen.

---

1.1 Was du vom Transformer-Fundament mitnehmen musst

Self-Attention (Transformer, Vaswani et al., 2017) hat die technische Voraussetzung für große Context Windows und In-Context Learning geschaffen: Das Modell kann Muster aus Prompt, Diffs und Tool-Results „mitlesen“, ohne für jede Aufgabe neu trainiert zu werden.

Für den Rest des Buches reichen drei Konsequenzen:

1. Modelle bleiben probabilistische Generatoren – keine Wissensdatenbanken und keine sicheren Executor.
2. „Groß“ heißt Parameter, Daten, Compute – für dich zählt die Systemqualität drumherum mehr als die exakte Milliarden-Zahl.
3. Pretraining liefert Sprach- und Code-Regularitäten; Instruction Tuning und Alignment (RLHF/RLAIF) machen Assistenten nutzbar – aber nicht infallibel. Ein höflich halluzinierter Import ist gefährlicher als ein grober Syntaxfehler.

Faustregel: Größere Modelle können qualitative Sprünge machen. Viele Produkt-„Wunder“ sind in Wahrheit besseres Prompting, bessere Tools und besserer Kontext (Kap. 3) – nicht magische Emergenz allein.

{ width=100% }

---

1.2 Von Completion zu Chat zu Tools zu Agenten

Die folgenden Stufen sind eine Systemgeschichte, keine Produkt-Timeline: Jeder Schritt löst ein Integrationsproblem und erzeugt ein neues. Completion war gut für Autocomplete; Chat machte Multi-Turn und Rollen explizit; Function Calling trennte „Wunsch“ von „Ausführung“; der Agent-Loop verbindet Planung, Tools und Beobachtung. Lies die Unterabschnitte als Evolution der Schnittstelle zur Welt – nicht als vier isolierte Buzzwords.

Completion

Frühe APIs: ein Prompt-String rein, Fortsetzungstext raus. Ideal für Editor-Autocomplete. Multi-Turn, Rollen und Tool-Ergebnisse mussten in einen String gehackt werden.

Chat: Messages als Schnittstelle

Chat-APIs strukturieren Kontext als Nachrichtensequenz (system, user, assistant). Das ist ein Kontextprotokoll im Kleinen: Der Host entscheidet, was bleibt, was summarisiert wird, was der Systemprompt darf.

Function Calling / Tool Use

Das Modell erzeugt strukturierte Aufrufwünsche (Name + JSON-Argumente nach Schema); der Host führt aus und schreibt das Ergebnis zurück.

Wichtig:

• Das Modell führt nichts aus. Der Host ist Executor und Policy-Enforcer.
• Tool-Schemas fressen Context-Budget.
• Lange Zeit definierte jede App eigene Schemas, Transports und Discovery – Vendor- und Framework-Lock-in inklusive.

Vom Tool-Call zum Agenten

Ein einzelner Tool-Call ist kein Agent. Ein Agent verfolgt ein Ziel in einer Schleife aus Planung, Aktion und Beobachtung – oft über viele Schritte. Sobald mehrere Datenquellen und wechselnde Toolsets dazukommen, rächt sich fehlende Standardisierung.

{ width=100% }

Parallel hat sich die Praxis verschoben: nicht nur größeres Modell, sondern Inference-Time Compute (längeres Nachdenken, Agent-Loops) und System-Skalierung (Memory, Tools, portable Capabilities). Das ist der rote Faden ab Kapitel 2.3 und 3.

---

1.3 Open vs. Closed – und der Lock-in darüber

Die Landschaft 2026 (pragmatisch)

Dimension	Closed / Managed APIs	Open Weights / Self-Host
Einstieg	schnell, wenig Ops	mehr Ops, mehr Kontrolle
Datenpfad	oft außerhalb der eigenen Infra (vertraglich regeln)	lokal/VPC möglich
Spitzenqualität / Features	häufig Early Access	abhängig von Fine-Tunes und Serving
Kosten	pro Token / Request	Hardware + Energy + People
Anpassbarkeit	begrenzt	hoch

In echten Systemen 2026 oft Hybride: Frontier für schwierige Planung, kleinere Modelle für Routing und Routine-Edits.

Der unterschätzte Lock-in: Tools, nicht nur Gewichte

• proprietäre Tool-Formate der Plattform,
• IDE-spezifische Indexer und Memory-Formate,
• Agent-Frameworks mit eigenen Plugin-APIs,
• Prompt-Templates, die nur in einem Host funktionieren.

Wenn dein „Agent“ nur in einer Oberfläche lebt und euer Issue-Connector nur dort, hast du ein Produkt – keine Plattform.

Portable Capabilities (Ausblick, nicht Deep-Dive)

Mit wachsender Host- und Tool-Vielfalt wird die Frage: „Welchen Connector schreiben wir für IDE X?“ zu „Welche Capability betreiben wir einmal – und welche Hosts dürfen andocken?“

Das Model Context Protocol (MCP) ist seit Ende 2024 spezifiziert und 2025/26 der prominenteste offene Ansatz für genau diese Schicht (Host–Client–Server; Tools, Resources, Prompts) – nicht der einzige Weg, aber der im Buch kanonische. Details, Lifecycle und wann MCP nicht folgen in Kapitel 4.7 – hier reicht die Architektur-Einsicht:

Best Practice: Entkopple Modellwahl (häufig wechselnd) von Kontext- und Tool-Schicht (stabil und versioniert).

{ width=100% }

---

Praxisbeispiel: Derselbe Use Case, drei Generationen

Aufgabe: „Fasse die letzten Fehler der CI-Pipeline zum Service billing zusammen und schlage einen Fix vor.“

Generation	Vorgehen	Limit
Chatbot 2022	Mensch kopiert Log-Auszug	Auswahlbias, keine Live-Daten
Tool-Assistent 2024	Feste Funktion get_ci_logs im Host	Nur dieser Host; Schema-Duplikation
Capability-Schicht 2026	Host entdeckt CI-Tools/Resources dynamisch (z. B. via MCP)	Server-Qualität, Auth und Context Policy bleiben kritisch

Der Sprung ist weniger „das Modell wurde magisch besser“ als „das System darf die richtige Welt sehen und anfassen – idealerweise portabel“.

---

Best Practices

1. Wähle Modelle nach Workload, nicht nach Hype: Planung vs. Bulk-Edit vs. Klassifikation trennen.
2. Investiere in portable Kontext-Schnittstellen, bevor du den dritten proprietären Plugin-Stack baust.
3. Behandle Alignment und Safety als Produktfeature – besonders bei schreibenden Tools.
4. Versioniere Systemprompts und Tool-Policies wie Code.
5. Miss Systemqualität (Task Success, Human Edit Rate, Token Cost), nicht nur Modell-Benchmarks.

---

Pitfalls

Pitfall	Folge	Gegenmaßnahme	Kapitel-Querverweis
„Wir brauchen nur das größte Modell“	Kosten ↑, Kontextmüll bleibt	Routing + Context Engineering	Kap. 3
Tool-Logik tief in einer IDE vergraben	Lock-in, Doppelarbeit	portable Capability-Schicht	Kap. 4.7
Open-Source-Modell ohne Serving-/Eval-Disziplin	Latenz, Drift	SRE-Standards wie für APIs	Kap. 6.5
Completion-Denken in Agenten-Systemen	unklare Rollen-/Tool-Grenze	Message- und Tool-Protokolle	Kap. 2.5
Trainingdaten mit „unserem Wissen“ verwechseln	halluzinierte interne APIs	Runtime-Kontext (Repo, Docs, Tools)	Kap. 3

---

Key Takeaways

• Für Architekturentscheidungen zählt die API-Evolution Completion → Chat → Tools → Agent mehr als die Transformer-Vorgeschichte.
• Assistenten sind Stacks aus Pretraining, Instruction Tuning und Alignment – und bleiben fehlbar.
• Open vs. Closed ist eine Trade-off-Matrix; Hybride sind normal.
• Der strategische Hebel sitzt oft in der Kontext- und Tool-Schicht, nicht nur in den Modellgewichten.
• Entkopple Modellwahl von stabilen Capabilities: Server und Policies überdauern Modellgenerationen.

---

Was als Nächstes kommt

Kapitel 2 (ebenfalls Auffrischung): Tokens, Context Window, Sampling, Host als Prompt-Compiler – und warum Window + RAG allein für Agenten nicht reichen. Der MCP-Deep-Dive wartet in Kapitel 4.

---

Übungsanregungen

1. Aufgabe: Liste fünf Team-Aufgaben, die heute Clipboard-Kontext brauchen.
   DoD: ☐ je Resource- vs. Tool-Kandidat · Zeit: ~15 Min

2. Aufgabe: Skizziere eure AI-Hosts und Integrationen als N×M-Matrix.
   DoD: ☐ eine Zelle als „einmal bauen, multi-host“ markiert · Zeit: ~20 Min

3. Aufgabe: Teste (ohne Secrets), ob euer Modell einen internen API-Namen „kennt“.
   DoD: ☐ eine Konsequenz für eure Kontextstrategie notiert · Zeit: ~10 Min