grok-bot
40977dff22
Dokumentiert die stateless Revision als Übergangsentscheidung, hält Buch und Companion normativ auf 2025-11-25 und verdrahtet Vorwort, Anhang D sowie COMPATIBILITY.
6.0 KiB
Vorwort
Architektur schlägt Modell-Hype
Wenn du in den letzten Jahren Software gebaut hast, hast du die KI-Welle in Schüben erlebt: Autocomplete, dann Chat, dann Tools, dann Agenten, die Issues lesen, Patches vorschlagen und Tests anstoßen. Irgendwann stellt sich nicht mehr die Demo-Frage „Kann das Modell Code?“, sondern die Produktionsfrage:
Welches System um das Modell herum macht Agentenarbeit steuerbar – und wann solltest du bewusst nicht automatisieren?
Dieses Buch antwortet als Architektur- und Musterbuch, nicht als SDK-Handbuch und nicht als Prompt-Sammlung. Die zentrale Beobachtung ist nüchtern:
Agentenqualität = Modell × Kontext × Tools × Prozess.
Ein schwaches Glied dominiert das Ergebnis.
Daraus folgen drei Hebel, die den roten Faden bilden:
- Context Engineering – was wann, in welcher Form, mit welcher Autorisierung und welchem Token-Budget ins Context Window kommt (und was bewusst draußen bleibt).
- Agent Harness – Loop, Permissions, Verify, Observability, UX: alles, was aus einem Modell einen betriebsfähigen Agenten macht (Agent = Model + Harness).
- Portable Capabilities – oft über das Model Context Protocol (MCP), wenn Tools und Kontext über Hosts und Teams hinweg wiederverwendbar sein sollen; host-nativ, wenn Pixel und Millisekunden im Editor zählen.
MCP ist dabei Infrastruktur, kein Heilsversprechen. Die oft zitierte USB-C-Analogie gilt nur so weit: Standardisierung von Anschluss und Discovery – nicht von Intelligenz, Sicherheit oder gutem Prozess.
Für wen dieses Buch ist – und für wen nicht
Geschrieben für:
- Tech-Leads, Architects und Senior ICs, die Agenten in den SDLC bringen,
- Platform- und AI-Engineers, die MCP-Server, Policies und Evals verantworten,
- Engineering Manager, die Autonomy, Risiko und Nutzen steuern müssen – ohne Folien-10×.
Weniger geeignet, wenn du suchst:
- eine Transformer-Forschungsmonografie,
- No-Code-Marketing-Automation,
- die Bestätigung, dass „ein Modell die Entwickler ersetzt“.
Agenten verstärken bestehende Engineering-Kultur. Schlechte Reviews, schwache Tests und unklare Ownership multiplizieren sie nur.
Was du nach diesem Buch entscheiden kannst
Nicht „mehr wissen“, sondern entscheiden und bauen:
| Entscheidung | Du kannst … |
|---|---|
| Architektur | Host-first vs. MCP-first vs. Custom-Harness begründen (Kap. 4, 6) |
| Kontext | eine Working-Set-/Context-Policy entwerfen und Context Waste messen (Kap. 3, 7, 10) |
| Integration | sagen, wann MCP die richtige Schicht ist – und wann nicht (Kap. 4.7.5) |
| Lieferfähigkeit | Autonomy L0–L3 an Orakel, Review und Error Budgets koppeln (Kap. 7, 11) |
| Betrieb | Threat Boundaries, Allowlists und Audit für Tools/Server skizzieren (Kap. 11) |
| Nutzen | in 90 Tagen messen statt behaupten (Scorecard in Kap. 7 / ES-III; Anhang F) |
| Build | in ≤ 5 Min den Offline-Agenten im Companion starten und den Context Trace lesen (Kap. 10.0; code/README.md) |
Was stabil bleibt, wenn Specs sich ändern
MCP-Hosts, Framework-APIs und Dekoratoren ändern sich weiter. Deshalb priorisiert dieses Buch Haltbarkeit:
| Schicht | Du nimmst mit |
|---|---|
| Stabil | Host/Client/Server; Tools, Resources, Prompts; Context- und Harness-Prinzipien; Trust Boundaries |
| Mittelstabil | Server-Schnitt, Verify-Loops, Skills/Progressive Disclosure, Hybrid-KB, Eval-Scorecards |
| Volatil / Übergangsphase (2026/2027) | MCP-Protokollkern (Sessions, initialize-Handshake, Request-Envelope) – siehe Kap. 4.8; konkrete SDK-Syntax und Host-JSON (Stand Juli 2026, Companion code/) |
Begründung Primitiven vs. Protokollkern: Die Revision 2026-07-28 bricht primär den Zustands- und Handshake-Vertrag, nicht die Capability-Klassen. Tools/Resources/Prompts bleiben die stabile Integrationssprache; der Protokollkern ist in der Übergangsphase bewusst als volatil markiert, damit ihr Migrationsbudget dort plant – und nicht an Context Policy oder Server-Schnitt.
Normative Spec-Referenz: MCP Specification 2025-11-25 unter modelcontextprotocol.io/specification/2025-11-25. Code: Tags book-2026-07 / latest (siehe code/COMPATIBILITY.md, code/README.md).
Spec-Pin und Revision 2026-07-28. Dieses Buch basiert normativ auf der MCP Specification 2025-11-25. Am 28. Juli 2026 erscheint die Revision 2026-07-28 (stateless Redesign): sie entfernt den protocol-level Session-Handshake und macht Requests self-contained. Wir behandeln den beobachtbaren Bruch und die Migrations-Entscheidung gezielt in Kapitel 4.8 – nicht durch Umschreiben des Architekturkerns. Begründung des Pinnings: Context Engineering, Harness und Capability-Schnitt bleiben haltbarer als die Session-/Transport-Details einer einzelnen Spec-Generation; Teams sollen auf stabilen Mustern entscheiden und den Spec-Wechsel bewusst terminieren.
Wie du liest
| Pfad | Einstieg |
|---|---|
| Architect (empfohlen) | Einleitung → Kap. 3 → 4 → 5 → 6.6 → 11 |
| Builder | Kap. 4.5–4.7 → 10 → 11.7 |
| Lead | Executive Summaries → Kap. 7 → 11 → 13 |
| 30 Minuten | Kap. 4.5 → 4.7.5 → python 05-coding-agent/agent.py --demo → Kap. 11.7 |
Kapitel 1–2 sind Auffrischung. Wenn du Tool-Use und Agent-Loops schon produktiv nutzt, überspringe sie ohne schlechtes Gewissen.
Lesevereinbarung
Ich setze voraus: du mitdenkst, im Terminal mitbaust und Demo-Prompts misstraust. Im Gegenzug bekommst du keine Hype-Roadmap, sondern Trade-offs, Failure Modes und die Einladung, Nein zu sagen – zu MCP an der falschen Stelle, zu Autonomy ohne Orakel, zu Multi-Agent ohne Evals.
Viel Erfolg. Bau Systeme, in denen Kontext und Werkzeuge so sauber spezifiziert sind wie eure APIs – und in denen Menschen die Verantwortung behalten.
Martin Richardt