Thema: Praxisteil 0. AgentClinic-production Labor
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 4-6 Stunden (Theorie + Praxis des ersten Durchgangs)
Voraussetzungen: Abgeschlossener erster Band von AgentClinic (Routen, SQLite, Feature-Spezifikationen, Prüfungen und Reviews)
Grundlegende Beherrschung von TypeScript und Python
Verständnis von CI/CD- und Produktionsbetriebskonzepten auf Leseniveau
Fähigkeit zur Arbeit mit Kommandozeile und Git
Vertrautheit mit Konzepten des Alertings, Metriken und Incident-Managements
Lernziele: Den Unterschied zwischen dem didaktischen Produktionsmodell und der realen Infrastruktur erklären und die Rollen von Kubernetes, Grafana, PagerDuty korrekt als Szenariobezeichnungen interpretieren
Drei Typen von Befehlsblöcken klassifizieren ([runnable], [project script], [conceptual interface]) und die Regel anwenden, nur [runnable]-Befehle bei der Bildung des Prüfungspakets auszuführen
Den durchgängigen Prüfungsfall high_memory_usage in appointments-api bilden, den Haupt-Incident auswählen und Prinzipien aus zusätzlichen Fällen für die Übertragung in capstone/ auswählen
Die Struktur capstone/ erstellen und die ersten Artefakte (genealogy.md, Spezifikationspaar, constitution.md) nach dem minimalen Pfad der Kapitel 1–3 ausfüllen
Den Smoke-Durchlauf bash book2/examples/smoke_all.sh ausführen und die Funktionsfähigkeit der didaktischen Simulatoren vor dem Durchlaufen der Kapitel 4–11 verifizieren
Überblick: Praxisteil 0 — methodische Einführungslabor des zweiten Bands von AgentClinic. Er führt keine neue Technik ein, sondern etabliert eine Lesekarte: wie man eine Reihe fortgeschrittener Kapitel in einen einheitlichen didaktischen Produktionskontext um das vertraute Projekt AgentClinic verwandelt. Zentrale Erkenntnis: der zweite Band verwendet denselben Stack (TypeScript, Hono, SQLite), fügt aber eine zweite Ebene hinzu — kleine Python-Skripte in book2/examples/ als didaktische Simulatoren von Produktionsmechanismen. Diese Skripte ersetzen den Produktionsstack nicht; sie ermöglichen es, ein minimales Beispiel in Sekunden zu starten, ohne Infrastruktur aufzubauen. Teil 0 führt die Regel „ein Projekt, ein Hauptkontur, ein wachsendes Beweispaket“ ein, definiert den durchgängigen Fall high_memory_usage, die Struktur capstone/ und den minimalen Pfad für begrenzte Zeit. Erfolgreiches Absolvieren dieses Teils wird durch einen Kontrollfakt gemessen: Haupt-Incident-Fall ausgewählt, leeres capstone/ erstellt, runnable-Beispiele geprüft oder mit explizitem Grund zurückgestellt.
Schlüsselkonzepte: Agentclinic-production: Didaktisches Produktionsmodell um das vertraute Projekt AgentClinic. Erfordert kein echtes Kubernetes, Grafana, PagerDuty oder GitOps — diese Begriffe bezeichnen Rollen in Szenarien: woher das Signal kam, welche Aktion gefährlich ist, wo ein Rollback nötig ist, welches Artefakt die Lösung beweist. Das Modell ermöglicht das Studium von Produktionspraktiken ohne Infrastrukturkosten.
High memory usage: Hauptprüfungsfall für den durchgängigen Durchlauf. Incident im Dienst appointments-api, geeignet für die Vervollständigung zum vollen Beweispaket: Webhook-Normalisierung, Readiness-Gateway, Probelauf, abschließendes Paket. Andere Fälle (autoscale_200pct, cdn_error_budget_burn, node_not_ready usw.) dienen als Laborfenster für einzelne Mechanismen, aber ihre Prinzipien werden in den Hauptfall übertragen, statt als gleichberechtigt gemischt zu werden.
Capstone/: Abschließendes Beweispaket zu einem Incident. Die Struktur folgt der Logik des ersten Bands: Absicht und Grenzen → Plan und Fakten → Review und Ergebnis. Jedes Kapitel eröffnet eine konkrete Datei. Schlüsselregel: ein Incident im Paket, die Lösung verständlich ohne Chat-Verlauf.
Drei Typen von Befehlsblöcken: [runnable] — wie geschrieben ausführen, Beispiele in book2/examples/; [project script] — Vertrag eines zukünftigen Skripts in Ihrem Projekt, muss nicht im Repository existieren; [conceptual interface] — Form einer zukünftigen Integration, wird beim didaktischen Durchlauf nicht ausgeführt. Das Prüfungspaket verweist nur auf ausgeführte Fakten oder manuelle Artefakte, die ohne Chat-Kontext lesbar sind.
Didaktische Simulatoren (Python stdlib): Zweite Code-Ebene des zweiten Bands — kleine Skripte in Python-Standardbibliothek. Kein Stack-Wechsel des Produkts, sondern die billigste Möglichkeit, ein Beispiel ohne Build zu starten: Stress-Mutator, Duell, Spec CI, Token-Budget, Readiness-Kalkulator. In einem realen Projekt würden solche Prüfungen zu pre-commit, GitHub Actions, MCP-Werkzeug oder Dienst im Produktionsstack werden.
Prinzipienübertragung vs. Fallübertragung: Aus dem lokalen Kapitelfall in high_memory_usage wird nicht der Fall selbst übertragen, sondern das prüfbare Prinzip. Beispiel: aus autoscale_200pct — Guard-Regel „Radius der Folgen nicht über Quota erweitern“; aus cdn_error_budget_burn — Anti-Goodhart-Invariante „MTTR nicht zum Preis von silent P0 verbessern“; aus node_not_ready — Provenienz der Anforderung und Regel „nicht ohne Wiederherstellungsbeweis schließen“.
Genealogy.md: Artefakt von Kapitel 1. Herkunft der Anforderung und Vertrauensniveau. Minimale Ausgabe: eine Anforderung mit zwei Quellen.
Poisoned-spec.md / fixed-spec.md: Artefakt von Kapitel 2. Paar von Spezifikationen „mit Defekt / korrigiert“, das eine Fehlerklasse demonstriert.
Constitution.md: Artefakt von Kapitel 3. Zwei unveränderliche Regeln und eine Regel mit Gültigkeitsdauer.
Validation.md: Artefakt der Kapitel 4 und 7. Befehle, manuelle Fakten und Blocker. Enthält Happy Path, Negative Path und Gegenbeispiel.
Judgment.md: Artefakt von Kapitel 8. Urteil zu einer umstrittenen Änderung mit Verweis auf den Beweis.
Budget-note.md: Artefakt von Kapitel 9. Risiko der Erschöpfung des Modell-Budgets und Schwellwert für den Wechsel zur günstigeren Ebene.
Goodhart-note.md: Artefakt von Kapitel 10. Zielmetrik und paarweise Schutzmetrik gegen Goodhart-Verzerrung.
Readiness.md: Artefakt von Kapitel 11. Zulassungsurteil für Produktion und Dry-Run der erlaubten Aktion.
Antipattern-audit.md: Artefakt von Kapitel 12. Drei Punkte blocker / owner / next_check.
Minimaler Pfad: Gekürzter Weg für begrenzte Zeit: Teil 0 + README des runnable-Beispiels → Kapitel 1–3 (drei manuelle Artefakte) → Kapitel 4–11 (nur [runnable]-Befehle, Prinzipien anderer Fälle werden als Zeichenketten übertragen) → Kapitel 12 (diagnostische Checkliste) → Kapitel 13 (Zusammenbau von capstone/ mit fünf PASS-Zeilen der Rubrik). Erfordert keine externen Orchestrierer, MCP-Server, Kubernetes-Integrationen.
Vollständiger Track: Erweiterter Durchlauf mit realen Integrationen. Dateien wie scorebook, metric_network, decision_hash, precedents.md und CI-Berichte werden nur hinzugefügt, wenn sie tatsächlich erstellt wurden oder einen runnable-Analogon existiert, das das Prinzip bestätigt.
Übungsaufgaben: Titel: Klassifikation von Befehlsblöcken
Problem: Ihnen werden drei Fragmente aus verschiedenen Kapiteln des zweiten Bands vorgelegt:
Fragment A: python3 book2/examples/stress-mutator/run.py --spec capstone/fixed-spec.md Fragment B: [project script] deploy-gate --readiness capstone/readiness.md --dry-run Fragment C: [conceptual interface] Integration mit PagerDuty Oncall API für automatische Ingenieurszuweisung
Bestimmen Sie den Typ jedes Fragments. Geben Sie an, welches davon jetzt ausführbar ist, welches später in Ihrem Projekt implementiert werden kann, welches beim didaktischen Durchlauf nicht ausgeführt wird. Erklären Sie, ob sich das Prüfungspaket auf jedes davon beziehen kann.
Lösung: 1. Fragment A — [runnable]. Kann jetzt ausgeführt werden, wenn die Datei capstone/fixed-spec.md existiert. Das Prüfungspaket kann sich auf das Ergebnis der Ausführung als prüfbaren Fakt beziehen.
- Fragment B — [project script]. Dies ist der Vertrag eines zukünftigen Skripts in Ihrem Projekt. Muss nicht im Lehrbuch-Repository existieren. Das Prüfungspaket kann sich nur darauf beziehen, wenn Sie ein Analogon implementiert und ausgeführt haben, oder wenn Sie ein manuelles Artefakt beschrieben haben, das ohne Chat-Kontext lesbar ist.
- Fragment C — [conceptual interface]. Form einer zukünftigen Integration, wird beim didaktischen Durchlauf nicht ausgeführt. Fällt beim ersten Durchlauf nicht als Fakt ins Prüfungspaket; wenn das Prinzip wichtig ist, wird es als einzeilige Invariante in die entsprechende Datei
capstone/eingetragen.
Schwierigkeit: Anfänger
Titel: Bildung der Übertragungskarte für autoscale_200pct
Problem: Sie durchlaufen ein Kapitel mit dem lokalen Fall autoscale_200pct. Nach den Regeln von Teil 0 dürfen Sie diesen Fall nicht mit dem Hauptfall high_memory_usage in einem capstone/ mischen. Nach dem Lesen des Kapitels stellen Sie fest: die automatische Skalierung hat bei einem Alert die Ressourcen verdoppelt, aber dies hat den Folgenradius erweitert (Nachbardienste betroffen) und die Quota überschritten. Welches Prinzip ist in den Hauptfall high_memory_usage zu übertragen und in welche Datei capstone/ ist es einzutragen?
Lösung: 1. Der lokale Fall autoscale_200pct bleibt im Kapitel als Laborfenster.
- Das prüfbare Prinzip für die Übertragung: Guard-Regel „Folgenradius nicht über Quota erweitern“.
- Diese Regel gehört zum Gegenbeispiel oder Begrenzer, daher wird sie in
validation.md(Kapitel 4 und 7) als Negative Path oder inconstitution.md(Kapitel 3) als Regel mit Gültigkeitsdauer eingetragen, wenn sie regelmäßig geprüft wird. - Formulierung in
capstone/: ein konkreter Punkt, z.B.: „Guard: bei Alert high_memory_usage ist Skalierung auf Quota X begrenzt; Gegenbeispiel aus autoscale_200pct zeigt, dass Quota-Überschreitung zu kaskadierendem Ausfall führt“. - Verweis auf das lokale runnable-Beispiel ist zulässig, aber die Lösung in
README.mderklärthigh_memory_usage.
Schwierigkeit: Mittelstufe
Titel: Smoke-Durchlauf und Ausfalldiagnose
Problem: Sie führen bash book2/examples/smoke_all.sh vor Kapitel 5 aus. Das Skript bricht im Block stress-mutator mit dem Fehler ModuleNotFoundError: No module named 'json' ab. Mit dem Wissen aus Teil 0 bestimmen Sie die wahrscheinliche Ursache und Maßnahmen. Kann der didaktische Pfad ohne Korrektur fortgesetzt werden?
Lösung: 1. json ist Teil der Python-stdlib, ein ModuleNotFoundError dafür ist in einer normalen Installation unmöglich. Wahrscheinliche Ursache: das Skript wurde in einer isolierten Umgebung ausgeführt (custom Python build, Container ohne stdlib, oder PYTHONPATH überschrieben).
- Prüfung:
python3 -c "import json; print(json.__file__)"— wenn dies fehlschlägt, ist die Umgebung defekt. - Gemäß Teil 0 verwenden alle
book2/examples/Python-stdlib und müssen ohne Abhängigkeiten starten. Wennjsonnicht verfügbar ist, ist dies ein Vertragsbruch der Umgebung, nicht des Lehrmaterials. - Maßnahmen:
which python3prüfen, systemweites Python 3.8+ verwenden, virtuelle Umgebung mit custom-Konfiguration entfernen. - Kann ohne Korrektur fortgesetzt werden: nein, Smoke-Durchlauf ist Kontrollfakt vor den Kapiteln 4–11. Es ist jedoch möglich, die minimale Variante zu wählen:
examples/README.mdöffnen, nur den Block des aktuellen Kapitels manuell ausführen, den Rest mit explizitem Grund „Umgebung nicht standard, für Kapitel 5 manuell geprüft“ zurückstellen.
Schwierigkeit: Mittelstufe
Titel: Strukturplanung von capstone/ nach Kapitel 3
Problem: Sie haben die Kapitel 1–3 nach dem minimalen Pfad durchlaufen. Sie haben: genealogy.md mit der Anforderung „readiness-gateway muss memory_before_allow prüfen“ (Quellen: Incident high_memory_usage und SRE-Leitfaden des Teams), das Paar poisoned-spec.md/fixed-spec.md, das den Defekt „Alert unterscheidet nicht zwischen memory leak und legitimate spike“ zeigt, und constitution.md mit zwei unveränderlichen Regeln („keine Aktionen ohne dry-run“ und „alle P0 erfordern Audit“) und einer Regel mit Gültigkeitsdauer „readiness-Prüfung 24 Stunden gültig“. Prüfen Sie, ob dies der minimalen Ausgabe von Teil 0 entspricht. Was fehlt für den Übergang zu Kapitel 4?
Lösung: 1. Prüfung nach der Tabelle der minimalen Ausgaben:
- Nach Kapitel 1: eine Anforderung mit zwei Quellen in
genealogy.md— ✅ (Anforderung + Incident + SLE-Leitfaden). - Nach Kapitel 2: Spezifikationspaar mit sichtbarer Fehlerklasse — ✅ (poisoned/fixed zeigen Defekt der Alert-Klassifizierung).
- Nach Kapitel 3:
constitution.mdmit zwei unveränderlichen und einer mit Gültigkeitsdauer — ✅.
- Für den Übergang zu Kapitel 4 wird ein minimales Gegenbeispiel zu einer Regel oder Formulierung des nächsten Begrenzers benötigt. Dies ist Ausgabe von Kapitel 4, nicht Kapitel 3 — daher ist der Übergang zu Kapitel 4 möglich.
- Es ist jedoch nützlich, vorab zu wählen, welche Regel aus
constitution.mdin Kapitel 4 ein Gegenbeispiel erhält. Empfehlung: die Regel „readiness-Prüfung 24 Stunden“ — leicht ein Gegenbeispiel mit einem Alert zu konstruieren, der 25 Stunden nach der Prüfung eintrifft. - Prüfung der Struktur
capstone/: Dateien mischen keine Incidents, jeder ist ohne Chat-Verlauf lesbar — ✅. - Es fehlt nur die Ausführung von
smoke_all.shoder ihre bewusste Verschiebung mit Begründung.
Schwierigkeit: Mittelstufe
Titel: Unterscheidung von minimalem Pfad und vollständigem Track
Problem: In Kapitel 7 begegnen Sie den Begriffen scorebook, Spec CI pipeline, decision_hash. Gemäß Teil 0, wie bestimmen Sie, ob diese Begriffe für das Prüfungspaket benötigt werden? Ihre aktuelle minimale Ausgabe — die Zeile Spec CI: was abgedeckt ist, was blockiert wird. Formulieren Sie, was in capstone/ einzutragen ist, wenn scorebook und decision_hash nicht von Ihnen erstellt wurden, aber konzeptionell im Kapitel beschrieben sind.
Lösung: 1. Regel von Teil 0: wenn ein Begriff die aktuelle Ausgabe des Kapitels nicht beeinflusst, verweilen Sie beim ersten Lesen nicht dabei.
- Minimale Ausgabe von Kapitel 7: Zeile Spec CI — was abgedeckt ist, was blockiert wird. Dies geht in
validation.md. scorebookunddecision_hash— Elemente des vollständigen Tracks. Sie sind nur nötig, wenn Sie sie tatsächlich erstellt haben oder ein runnable-Analogon erklären können, dass dasselbe Prinzip bestätigt.- Aktion: in
validation.mddas Prinzip, dasscorebookunddecision_hashschützen, in einer Zeile ohne Erwähnung der Begriffe selbst eintragen. Z.B.: „Abdeckung: Spezifikation besteht 5/5 Prüfungen der Spec CI. Blocker: wenn Mutator unbehandelten Payload findet, ist merge verboten. Prüfbarer Fakt: Ausführung vonpython3 examples/spec-ci/run.pyauffixed-spec.mdergibt PASS“. - Wenn später im vollständigen Track
scorebookimplementiert wird — Datei hinzufügen. Beim ersten Durchlauf ist dies überflüssig.
Schwierigkeit: Fortgeschritten
Fallstudien: Titel: Migration des didaktischen Modells in echte SRE-Praxis: von AgentClinic-production zum production-ready Pipeline
Szenario: Ein Team von 8 Personen hat den ersten und zweiten Band von AgentClinic nach dem minimalen Pfad abgeschlossen. Ihr capstone/ enthielt das vollständige Paket zu high_memory_usage: genealogy.md mit zwei Quellen, Spezifikationspaar mit Defekt der Alert-Klassifizierung, constitution.md mit Guard-Regeln, validation.md mit Ergebnissen von stress-mutator und Spec CI, readiness.md mit dry-run-Urteil. Das Team erhielt den Auftrag, einen analogen Prozess für einen echten Arzttermin-Dienst in einem Kliniknetzwerk einzuführen.
Herausforderung: Drei Schlüsselprobleme bei der Übertragung des didaktischen Modells: (1) der echte Dienst verwendete Go und PostgreSQL, nicht TypeScript/SQLite — es entstand die Versuchung, den didaktischen Stack als irrelevant abzulehnen; (2) die Infrastruktur erforderte echtes PagerDuty, DataDog und GitHub Actions, nicht Python-Simulatoren; (3) das Management verlangte sofort den „vollständigen Track“ inklusive scorebook und metric_network, was die Dauer von 2 Wochen auf 3 Monate erhöhte und zum Projektstillstand führte.
Lösung: Das Team wendete die Prinzipien von Teil 0 an: (1) trennte Produktionsstack (Go/PostgreSQL) von der Prüfebene — Python-Simulatoren wurden durch GitHub Actions und pre-commit-Hooks in Go ersetzt, aber die Struktur der Artefakte (genealogy.md, constitution.md usw.) blieb; (2) Begriffe PagerDuty/DataDog wurden als Szenariorollen verwendet, Integration schrittweise realisiert: zuerst Webhook-Simulator in Slack, dann echtes PagerDuty; (3) bestand auf dem minimalen Pfad: die ersten 2 Wochen lieferten eine funktionierende Pipeline mit 5 Dateien in capstone/, der vollständige Track wurde iterativ nach dem Prinzip „ein neuer prüfbarer Ausgabe pro Sprint“ hinzugefügt.
Ergebnis: Die minimale Pipeline lief nach 10 Tagen. Der erste echte Incident (Memory-Druck auf dem Termin-Dienst) wurde nach capstone/ in 45 Minuten statt bisher 4 Stunden bearbeitet. Die Guard-Regel „Folgenradius nicht erweitern“ verhinderte die kaskadierende Abschaltung des Zahlungsgateways. Der vollständige Track (scorebook, decision_hash) wurde über 6 Monate iterativ eingeführt, ohne Stillstand. Die didaktischen Python-Skripte blieben als Prototypen für lokale Fehlersuche bei neuen Guard-Regeln.
Gelernte Lektionen: Das didaktische Modell ist wertvoll nicht durch den Stack, sondern durch die Struktur der Artefakte und die Prinzipien der Trennung von Prüfungen und Produkt
Der minimale Pfad ist keine Vereinfachung für Schwache, sondern eine Strategie der schnellen Validierung vor Skalierung
Szenariorollen (PagerDuty, Kubernetes) ermöglichen Prozessgestaltung vor Infrastrukturreife
Vollständiger Track ohne funktionierenden minimalen Pfad — Risiko des architektonischen Stillstands
Python-Simulatoren des Lehrbuchs haben lange Lebensdauer als Prototypierungswerkzeuge für Guard-Regeln
Verwandte Konzepte: AgentClinic-production
Minimaler Pfad
Drei Typen von Befehlsblöcken
Prinzipienübertragung vs. Fallübertragung
capstone/
Titel: Fehler der Fallmischung: wenn autoscale_200pct high_memory_usage absorbierte
Szenario: Ein Ingenieur durchlief den zweiten Band und beschloss, „alles richtig zu machen“ — beide Incidents als gleichberechtigte Fälle in capstone/ aufzunehmen. README.md beschrieb high_memory_usage, aber die Dateien validation.md und readiness.md enthielten Lösungen für autoscale_200pct, und budget-note.md — für cdn_error_budget_burn.
Herausforderung: Beim Review durch einen anderen Ingenieur war das Paket unlesbar: Guard-Regeln aus autoscale_200pct widersprachen dem Readiness-Gateway für high_memory_usage, judgment.md verwies auf eine umstrittene Änderung ohne Kontext, und README.md erklärte nicht, warum drei Incidents im Paket waren. Der Reviewer verbrachte 2 Stunden mit Kontextrecherche und lehnte das Paket ab.
Lösung: Überarbeitung nach den Regeln von Teil 0: ein Hauptfall high_memory_usage ausgewählt; Prinzipien aus anderen Fällen als einzeilige Invarianten in entsprechenden Dateien herausgearbeitet. Z.B. statt eines Abschnitts über autoscale_200pct — eine Zeile in validation.md: „Guard-Regel: Skalierung auf Quota begrenzt (Gegenbeispiel aus autoscale_200pct)“.
Ergebnis: Das überarbeitete Paket bestand das Review in 15 Minuten. Der Ingenieur erlernte die Schlüsselfertigkeit von Teil 0: Trennung von Prinzip und Fall. In späteren Projekten wendete er dies an, um Post-mortems aus Dutzenden von Incidents in einen einheitlichen Satz von Guard-Regeln zu konsolidieren.
Gelernte Lektionen: Fallmischung in einem capstone/ erzeugt Unlesbarkeit und Widersprüche
Das Prinzip „ein Incident — ein Paket“ beschränkt das Lernen nicht, sondern fokussiert es
Review „durch eine andere Person“ ist ein Qualitätskriterium, keine Formalität; das Paket muss ohne Chat-Verlauf verständlich sein
Gegenbeispiel aus einem anderen Fall stärkt den Hauptfall, wenn als Invariante eingetragen, nicht als separate Geschichte
Verwandte Konzepte: high_memory_usage
Prinzipienübertragung vs. Fallübertragung
capstone/
validation.md
Studientipps: Lesen Sie Teil 0 vollständig, bevor Sie Code berühren. Dies ist ein methodisches Kapitel ohne Schritte; sein Ziel ist die Karte, nicht die Ausführung. Der Versuch, „einfach smoke_all.sh auszuführen“ ohne Verständnis des Prüfungsfalls führt zu Ansammlung irrelevanter Artefakte.
Erstellen Sie physikalisch mkdir -p capstone unmittelbar nach dem Lesen. Ein leerer Ordner ist ein Anker für Entscheidungen: „diese Datei hierher oder das ist vollständiger Track?"
Drucken Sie die Tabelle „Nach Kapitel → Minimale Ausgabe“ aus oder halten Sie sie offen. Verwenden Sie sie als Checkliste: wenn die Datei nach dem Kapitel nicht der Beschreibung entspricht, gehen Sie erst zur nächsten Kapitel nach Nacharbeit.
Für visuellen Stil: zeichnen Sie auf Papier Pfeile zwischen den Dateien capstone/. genealogy.md → poisoned-spec.md/fixed-spec.md → constitution.md → ... Dies hilft zu erkennen, dass jede Datei kein isoliertes Dokument, sondern ein Glied der Beweiskette ist.
Für auditive Lerner: lesen Sie die Kontrollfragen laut vor und zeichnen Sie die Antworten als Sprache auf, bevor Sie prüfen. Wenn die Antwort länger als 30 Sekunden dauert — ist das Verständnis wahrscheinlich nicht tief genug.
Für kinästhetische Lerner: führen Sie den Smoke-Durchlauf physisch aus, ohne das Skript zu lesen. Öffnen Sie dann smoke_all.sh im Editor und verfolgen Sie, welcher Block zu welchem Kapitel gehört. Manuelles Zuordnen „Code → Kapitel → Ausgabe“ stärkt die Struktur.
Bei der Arbeit mit zusätzlichen Fällen (autoscale_200pct, cdn_error_budget_burn usw.) verwenden Sie die Technik „ein Prinzip — eine Zeile“. Öffnen Sie die Datei, in die die Übertragung geht, und tragen Sie das Prinzip ein, bevor Sie die Kapitel-Registerkarte schließen. Sonst geht der Kontext verloren.
Führen Sie Selbstreview durch: schließen Sie alle Materialien und versuchen Sie, „warum man Fälle nicht mischen kann“ mit eigenen Worten einem 8-jährigen Kind oder einem Kollegen aus einem anderen Team zu erklären. Wenn Kubernetes oder PagerDuty erwähnt werden müssen — sind Sie noch in der Falle der „echten Infrastruktur“, steigen Sie in „Szenariorollen“ um.
Für Kapitel 4–11: starten Sie runnable-Beispiele mit dem Flag --help oder studieren Sie die argparse-Sektion vor der Ausführung. Das Verständnis der Simulator-Parameter ist wichtiger als das schnelle Ergebnis — Sie müssen erklären können, was genau das Skript prüft, nicht nur dass es PASS ausgab.
Finale Prüfung vor Kapitel 1: nennen Sie den Hauptfall, zeigen Sie das leere capstone/, demonstrieren Sie das Ergebnis von smoke_all.sh oder seine bewusste Verschiebung. Wenn ein Punkt unmöglich ist — kehren Sie zu Teil 0 zurück.
Zusätzliche Ressourcen: Examples/templates/capstone-dossier.md: Minimale Form der Antwort auf die Frage „welche Spur sollte nach dem ersten Durchlauf übrig bleiben?“. Keine Vorlage für gedankenloses Kopieren, sondern Orientierung für Selbstprüfung der Paketstruktur
Examples/readme.md: Beschreibung aller runnable-Beispiele nach Kapitelblöcken. Verwenden für selektiven Smoke-Durchlauf, wenn der vollständige smoke_all.sh viel Zeit beansprucht
Book2/examples/smoke all.sh: Skript des vollständigen Smoke-Durchlaufs. Wird auf temporärer Kopie ausgeführt, hinterlässt keine Artefakte im Arbeitsbaum
Erster Band agentclinic (Routen, sqlite, Feature-Spezifikationen): Fundament, auf dem der zweite Band aufbaut. Stellen Sie sicher, dass genealogy.md und Spezifikationspaare aus dem ersten Band verständlich sind
Kontrollfragen von Teil 0 (innerhalb des Dokuments): Vier Fragen zur Selbstprüfung vor dem Übergang zu Kapitel 1. Verwenden als Lernkarten
Glossar der Begriffe der Kapitel 4–13: Nicht vorauslernen nach der Tabelle von Teil 0 — Begriffe werden in ihren Kapiteln eingeführt. Aber griffbereit halten für schnelle Prüfung, wenn ein unbekanntes Wort auftritt
Zusammenfassung: Praxisteil 0 — fundamentale methodische Labor, die definiert, wie man den zweiten Band von AgentClinic als einheitlichen Produktionskontur liest, nicht als Sammlung isolierter fortgeschrittener Techniken. Schlüsselprinzipien: (1) das didaktische Modell AgentClinic-production verwendet Szenariorollen statt echter Infrastruktur; (2) Python-Skripte in book2/examples/ — Simulatoren für lokale Ausführung, kein Wechsel des Produktionsstacks; (3) ein durchgängiger Fall high_memory_usage, die übrigen — Laborfenster für Prinzipienübertragung; (4) drei Typen von Befehlsblöcken mit klarem Prüfungsregel; (5) Struktur capstone/ als wachsendes Beweispaket, verständlich ohne Chat-Verlauf; (6) minimaler Pfad gegen vollständigen Track — schnelle Validierung vor Skalierung. Erfolgreiches Absolvieren wird durch Kontrollfakt gemessen: Fall ausgewählt, capstone/ erstellt, runnable-Beispiele geprüft. Alles Folgende baut auf dieser Basis auf.