Claude-Plattform & Lösungsdesign

Screen 1: Lösungen mit Claude zu entwerfen geht über die bloße Modellauswahl hinaus.

UNTERRICHT 2 MIN · MODULEINFÜHRUNG Lösungen mit Claude zu entwerfen geht über die bloße Modellauswahl hinaus.

Bei der Gestaltung von Lösungen mit Claude müssen vier Schlüsselentscheidungen getroffen werden, bevor Sie mit dem Aufbau beginnen.

01 Welcher Teil der Arbeit sollte Claude übernehmen?

Bevor Sie etwas gestalten, sollten Sie entscheiden, was Sie Claude übergeben, was Sie bei bestehenden Systemen belassen und was bei einem Menschen bleibt.

02 Welche Form hat die Arbeit?

Erweitern Sie einen Live-Anruf, automatisieren Sie einen Workflow oder stellen Sie einen Agent bereit, der eigenständig handelt?

03 Können Sie die Referenzarchitektur benennen, zu der Sie sich verpflichten?

Die frühzeitige Auswahl einer Referenzarchitektur kann Sie vor teuren Umstrukturierungen bewahren.

04 Wo interagiert Ihre Arbeit mit Claude?

Die Auswahl des richtigen Einstiegspunkts, Modells und der Kontextstrategie hält Ihre Lösung funktionsfähig und kostenbewusst.

In diesem Modul erfahren Sie, wie Sie diese Entscheidungen treffen, um ein mehrdeutiges Geschäftsproblem in eine vorgeschlagene Lösung umzuwandeln und Ihre Entscheidungen gegen glaubwürdige Alternativen zu verteidigen.

Am Ende dieses Moduls können Sie: 1 Die Anfrage eines Partners in das aufteilen, was Claude tut, was bestehende Systeme tun und was Menschen tun, indem Sie die vier Eigenschaften von generativer KI als Entscheidungsleitfaden verwenden. 2 Zwischen einem erweiterten Anruf, einem Workflow und einem Agent wählen, indem Sie benennen, was jede Wahl kostet. 3 Ein Referenzarchitekturmuster für die Problemform vor Ihnen auswählen und erkennen, wann Abruf eine Aufgabe übernimmt, die der Live-Status übernehmen sollte. 4 Verteidigbare Modell-, Kontextfenster- und Kontextstrategieentscheidungen treffen und Evaluationen als Gate vor jedem Modellwechsel verwenden. 5 Wissen, wo jeder Plattformeinstiegspunkt passt (Claude. ai, die API, ein SDK, Claude Code oder ein MCP-Server) und welche Anpassung auf jeder Ebene stattfindet. 6 Zwischen den Claude-Einstiegspunkten, die ein Benutzer sieht, den Build-Zeit-Schnittstellen, gegen die ein Ingenieur programmiert, und den Lieferwegen, die ein Unternehmen beschafft, unterscheiden, sowie identifizieren, welche durch Governance- oder Compliance-Anforderungen der regulierten Industrie ausgeschlossen werden, bevor andere Kompromisse gelten. FÜR WEN DIESES MODUL IST

Dieses Modul ist für den Architekten, der die mehrdeutige Anfrage eines Partners in eine Lösung umwandelt, die jemand bauen, finanzieren und verteidigen kann. Sie sind technisch versiert, entscheidungsfreudig und kompromissbewusst. Sie schreiben in diesem Modul nicht den Produktionscode, und es lehrt Sie das nicht. Es lehrt die Entscheidungen, die über dem Code liegen: welche Arbeit Claude übernehmen sollte, welche Form diese Arbeit annimmt, welche Referenzarchitektur passt, und welche Modell-, Kontext- und Einstiegspunktentscheidungen das System genau und erschwinglich halten, wenn es real ist.

„Die Arbeit" in diesem Modul

Alles hier ist um ein Beispiel-Engagement herum aufgebaut: ein Geschäftsproblem von einem Partner nehmen und zu einer vorgeschlagenen Architektur gelangen, hinter der Sie stehen können, wenn eine glaubwürdige Alternative auf dem Tisch liegt. In diesem Szenario sind die Partner Unternehmenskäufer in hochriskanten, oft regulierten Umgebungen, in denen eine Designentscheidung, die in einer Demo sauber aussah, zu einer Fehlleitung wird, die drei Monate später in einer Audit entdeckt wird. Dieses Szenario wird als eine Reihe von Entscheidungen dargestellt, wobei jede Entscheidung etwas anderes von Ihnen verlangt.

Die Entscheidungen ordnen sich den folgenden Abschnitten zu:

Zerlegung ist der Ort, an dem Sie jeden Teil der Anfrage Claude, einem bestehenden System oder einem Menschen zuordnen, indem Sie die vier Eigenschaften von generativer KI als Leitfaden verwenden. Dies falsch zu machen, indem Sie zu viel Claude zuweisen, ist der häufigste und teuerste frühe Fehler. Musterwahl ist der Ort, an dem Sie entscheiden, ob die Arbeit ein erweiterter Anruf, ein Workflow oder ein Agent ist. Jede Wahl bietet und kostet Sie etwas, die Kosten zu benennen ist das Ziel. Referenzarchitekturen sind der Ort, an dem eine bekannte, gute Blaupause entweder zur Problemform passt oder falsch angewendet wird. Der Fehler, auf den Sie achten sollten, ist, dass Abruf stillschweigend eine Aufgabe übernimmt, die der Live-Transaktionsstatus übernehmen sollte. Modell, Kontext und Einstiegspunkt sind der Ort, an dem Sie ein Modelltier, eine Kontextstrategie und einen Lieferweg wählen, und wo Evaluationen zu einem Stage-Gate vor jedem Modellwechsel werden. Überprüfen Sie, ob Governance- und Compliance-Anforderungen der regulierten Industrie einen Weg ausschließen, bevor Sie andere Kompromisse in Betracht ziehen.

Anstatt diese als Phasen auswendig zu lernen, besteht das Ziel in diesem Modul darin, zu erkennen, welche Entscheidung vor Ihnen liegt, da jede eine andere Bewegung belohnt: die Entscheidung, die Ihnen bei der Zerlegung gut dient, ist anders als bei der Wahl eines Einstiegspunkts. In der kumulativen Aufgabe am Ende dieses Moduls werden Sie alles zusammenbringen, um eine vollständige Architektur aus einem neuen Brief zusammenzustellen.

HAFTUNGSAUSSCHLUSS / HINWEIS FÜR BILDUNGSINHALTE

Wir haben diesen Architect-Kurs Modul 1: Claude Platform & Solution Design erstellt, um Ihnen zu helfen, echte Arbeit mit Claude zu erledigen. Behandeln Sie ihn als Bildungsinhalte. Er stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher sollten Sie das Gelernte an Ihre eigene Situation anpassen. Unsere Produkte und Dienstleistungen entwickeln sich schnell, daher können bestimmte Inhalte Fehler enthalten oder veraltet sein; denken Sie daran, auf der Website oder in der Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien, die im Kurs verwendet werden, sind illustrativ und oft fiktiv. Wenn das Kursmaterial ein Unternehmen oder Produkt erwähnt, bedeutet dies nicht, dass Anthropic es unterstützt, sie Anthropic unterstützen oder dass wir verbunden sind. Beachten Sie auch, dass Ihre Nutzung von Anthropic-Produkten und -Dienstleistungen durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; wenn etwas in diesem Kurs damit in Konflikt steht, haben sie Vorrang.

Screen 2: Die vier Eigenschaften, um die Architekten herum entwerfen

Unterricht 12 min · Wie Claude sich verhält

Die vier Eigenschaften, um die Architekten herum entwerfen Bevor Sie entscheiden, was Claude in einer Lösung tun sollte, müssen Sie ein klares Verständnis dafür haben, wie Claude sich verhält. Vier Eigenschaften des Modells prägen jede folgende Designentscheidung. Keine dieser Eigenschaften ist ein Fehler, der behoben werden muss, jede ist eine Kraft, um die Sie herum entwerfen – wie ein Bauingenieur um die Eigenschaften seiner Baumaterialien herum entwirft.

Betrachten Sie diesen Bildschirm als grundlegende Vorbereitung, Sie werden nicht aufgefordert, an dieser Stelle Designentscheidungen zu treffen. Das Ziel ist, die vier Eigenschaften nach Namen zu erkennen und die Designkonsequenzen jeder Eigenschaft zu verstehen, um Sie auf informierte Entscheidungen in Übungsaufgaben später im Modul vorzubereiten.

Die vier Eigenschaften und ihre Designkonsequenzen Für jede Eigenschaft unten sind die gleichen Merkmale, die Claude in einer Situation fähig machen, die gleichen, die es in einer anderen zum Scheitern bringen. Lesen Sie jede Zeile als eine Fähigkeit, die mit ihrer entsprechenden Einschränkung gepaart ist, und die Minderung, auf die ein Architekt zurückgreift.

Wählen Sie jede Eigenschaft aus, um ihre gepaarte Fähigkeit, Einschränkung und Minderung zu sehen.

Next Token Prediction Knowledge Working Memory Steerability

Fähigkeit: Aufgaben, die auf häufigen Mustern aufgebaut sind: Zusammenfassen, Umformatieren und Erklären von etablierten Konzepten. Einschränkung: Alles, das Präzision bei Besonderheiten erfordert. Claude kann Text produzieren, der genau aussieht, aber nicht ist. Dieses Risiko konzentriert sich auf Namen, Daten, Zitate und Statistiken. Minderung: Verwenden Sie Zitate, Unsicherheitssignalisierung und Generator-Verifier-Schleifen. Leiten Sie spezifische faktische Nachschlagungen durch Tool-Aufrufe oder autoritative Quellen weiter, anstatt sich ausschließlich auf die Ausgabe des Modells zu verlassen.

Fähigkeit: Themen in den Trainingsdaten des Modells, die häufig, aktuell und konsistent enthalten sind, wo das Modell zuverlässig aus dem Gelernten antworten kann. Einschränkung: Themen, die selten, Nische, umstritten oder sich häufig ändern. Das Modell kann veraltete oder unvollständige Informationen mit dem gleichen selbstbewussten Ton präsentieren, den es für etablierte Fakten verwendet. Minderung: Verwenden Sie Websuche, Abruf (RAG), Tool-Nutzung oder MCP-Server, um ein externes System zur Quelle der Wahrheit zu machen, anstatt sich auf das Modell zu verlassen. Anstatt die parametrische Kenntnis des Modells zu überprüfen, kommt die autoritative Antwort aus der abgerufenen Quelle. Wenn Aktualität oder Autorität wichtig ist, führen Sie die Daten selbst erneut ein, anstatt sich auf das zu verlassen, das in den Trainingsdaten des Modells bereitgestellt wurde.

Fähigkeit: Alles, das in das aktive Kontextfenster passt. Einschränkung: Das Kontextfenster ist eine harte Kante: Sobald Inhalte außerhalb des Fensters fallen, hat das Modell keinen Zugriff darauf. Zwei verschiedene Fehler treten an der Kante auf, können aber leicht verwechselt werden. Einer ist eine übergroße Anfrage, was bedeutet, dass eine Eingabeaufforderung oder ein Gespräch bereits zu groß zum Senden ist. Wenn eine übergroße Anfrage gesendet wird, wird sie vor der Generierung abgelehnt. Wenn die Anfrage das Token-Limit des Modells überschreitet, gibt die API einen 400 invalid_request_error mit einer Nachricht zurück, die angibt, dass die Eingabeaufforderung zu lang ist. Wenn der rohe Anfragekörper das Byte-Limit der API überschreitet, gibt die API einen 413 request_too_large-Fehler mit einer Nachricht zurück, die angibt, dass die Anfrage die maximal zulässige Anzahl von Bytes überschreitet. Der andere Fehler tritt auf, wenn eine Eingabeaufforderung passt, aber ihre Generierung auf die Fensterdecke trifft und stattdessen früh stoppt; bei aktuellen Modellen kommt die Antwort mit einem model_context_window_exceeded-Stoppgrund und abgeschnittener Ausgabe zurück. Um das Limit zu vermeiden, können Sie das Feld „Nutzung" bei jeder Antwort und die Token-Zähl-API überprüfen, bevor Sie senden. Minderung: Verwenden Sie progressive Kontextladung, Chunking und Vorladen kritischer Informationen. Für erweiterte Arbeit können Projekte helfen, was im Umfang bleibt. Gewöhnen Sie sich daran, über Runden hinweg zusammenzufassen, wenn der Kontext lang wird.

Fähigkeit: Kurze, konkrete und überprüfbare Anweisungen mit definierten Formaten, expliziten Längenbeschränkungen, klaren Rollen. Einschränkung: Abstrakte oder mehrdeutige Anweisungen, lange Argumentationsketten und Aufgaben, die präzise numerische oder logische Berechnung erfordern. Für hochriskante numerische Genauigkeit sollte deterministische Berechnung oder Tool-Ausführung die Antwort übernehmen. Das Modell kann den Buchstaben einer Anweisung befolgen, während es von der Absicht abweicht. Minderung: Verwenden Sie System-Eingabeaufforderungen, strukturierte Ausgaben und Code-Ausführung für alles, das logische Präzision erfordert. Wenn Absicht und wörtliche Anweisung auseinandergehen könnten, wiederholen Sie das Ziel explizit neben der Anweisung.

Von der Eigenschaft zur Designkonsequenz Wir werden später in diesem Kurs auf jede dieser Eigenschaften zurückkommen. Ordnen Sie jede Eigenschaft ihrer Designkonsequenz jetzt zu, damit die Verbindung vorhanden ist, bevor Sie sie benötigen:

Nicht-Determinismus. Die gleiche Eingabe kann über Läufe hinweg unterschiedliche Ausgaben erzeugen. Deshalb existieren Evaluierungsrahmen: Sie können Verhalten, das Sie nur einmal beobachtet haben, nicht zertifizieren. (Speist die Evaluierungsarbeit in Modul 2. ) Kontext als endliche Ressource. Das Kontextfenster ist eine harte Kante mit einem festen Token-Budget. Was Sie hineinlegen, in welcher Reihenfolge und was Sie weglassen, sind Designentscheidungen, die sowohl beeinflussen, womit das Modell arbeiten kann, als auch was es kostet, es auszuführen. (Speist Modell- und Kontextstrategie, später in diesem Modul. ) Vertrauen ist nicht Gültigkeit. Claude kann eine falsche Antwort im gleichen fließenden, selbstbewussten Ton geben, den es für eine richtige verwendet. Deshalb sind Platzierung von Menschen in der Schleife und Überprüfung architektonische Entscheidungen, keine Nachgedanken. (Speist die verantwortungsvolle Bereitstellungsarbeit in Modul 3. ) Wissens- und Fähigkeitsgrenzen. Das Modell ist zuverlässig bei Themen, die häufig, aktuell und konsistent in seinen Trainingsdaten sind, und unzuverlässig bei Themen, die selten, privat oder sich schnell ändern. Für unzuverlässige Themen können Websuche, Abruf, Tools und MCP verwendet werden, um ein externes System zur Quelle der Wahrheit zu machen, anstatt sich auf das Modell zu verlassen. (Speist Referenzarchitekturen und RAG, später in diesem Modul. )

Szenario: Ein Fehler, der mit einer falsch gelesenen Eigenschaft begann Ein Architekt sah eine Demo fünfmal hintereinander sauber laufen und schloss daraus, dass das Verhalten deterministisch war. Auf dieser Grundlage schickte das Team eine finanzielle Abstimmungs-Pipeline, die jede Modellausgabe als festes, wiederholbares Ergebnis behandelte und keine Überprüfungen darum herum erstellte. In der zweiten Woche der Produktion drifteten die Ausgaben: die gleiche Aussage, erneut verarbeitet, erzeugte eine andere Kategorisierung. Diese Diskrepanz wurde nur zufällig entdeckt, als ein Analyst zufällig einen Batch erneut ausführte. Nichts hatte sich in der Eingabe geändert, aber unterschiedliche Ausgaben wurden erzeugt, weil das Modell ein nicht-deterministisches System ist und die Architektur so gebaut worden war, als wäre es deterministisch. Die Lektion ist nicht, dass das Modell unzuverlässig ist, sondern dass eine Demo kein Beweis für Determinismus ist und dass die vier Eigenschaften vorhanden sind, unabhängig davon, ob Ihre Architektur sie anerkennt oder nicht.

Kosten · Komplexität · Risiko Kosten: Das Entwerfen ohne Berücksichtigung dieser Eigenschaften ist der teuerste Fehler, den ein Architekt machen kann, da die Kosten nach dem Start landen, wenn Überarbeitungen am teuersten sind und das Vertrauen am schwierigsten wiederherzustellen ist. Komplexität: Die Benennung der vier Eigenschaften im Voraus hält spätere Designgespräche präzise. Sie können anerkennen, „dies ist ein Wissensgrenzen-Problem", anstatt zu debattieren, ob das Modell „gut genug" ist. Risiko: Die Eigenschaften kündigen sich nicht an. Ein System, das nicht um diese Eigenschaften herum entworfen ist, wird keinen Fehler erzeugen; es driftet stillschweigend und die Lücke führt zu variablen Ausgaben, die möglicherweise in einer Audit oder von einem verärgerten Benutzer gefunden werden, nicht vom System selbst.

Screen 3: Einstiegspunkte, Build-Zeit-Schnittstellen, Lieferwege

Unterricht 12 min · Plattformkarte & Primitive

Einstiegspunkte, Build-Zeit-Schnittstellen, Lieferwege Während dieses Kurses werden Sie wählen, wie ein Benutzer Claude erreicht, aber bevor das geschieht, benötigen Sie einen konsistenten Satz von Vokabeln. Drei Begriffe werden oft austauschbar verwendet, aber sie sitzen auf verschiedenen Ebenen der Architektur. Dieser Bildschirm lehrt jeden dieser Begriffe. Die Wahl zwischen ihnen kommt später, sobald der Rest des Designs vorhanden ist.

Drei Ebenen, drei unterschiedliche Entscheidungen Diese drei Ebenen sind keine Alternativen zueinander. Jede Bereitstellung beinhaltet alle drei und ihre Verwechslung ist die häufigste Quelle für verwirrte Architektur-Gespräche.

Einstiegspunkte Was eine Person oder ein System direkt mit interagiert. Einstiegspunkte sind die Wrapper, die entscheiden, wer mit Claude sprechen kann und wie. Beispiele: Claude. ai (Web, Mobilgeräte, Desktop), Claude Code, eine benutzerdefinierte Anwendung, die auf der API aufgebaut ist.

Build-Zeit-Schnittstellen Wie ein Ingenieur gegen Claude programmiert, die Ebene, gegen die der Code des Partners geschrieben wird. Beispiele: Die direkte API, die SDKs, MCP, das Agent SDK.

Lieferwege Wo API-Traffic endet. Lieferwege bestimmen, auf wessen Infrastruktur die Anfrage ausgeführt wird. Beispiele: Anthropic direkt, AWS Bedrock, GCP Vertex AI, Microsoft Foundry.

Warum die Ebenen unterschiedlich zu halten wichtig ist Ein Einstiegspunkt wird für den Benutzer und die Arbeit gewählt. Eine Build-Zeit-Schnittstelle wird für das Ingenieursteam und die Integration gewählt. Ein Lieferweg wird für die Cloud-Verpflichtungen und die Compliance-Haltung des Partners gewählt. Dies sind drei verschiedene Gespräche mit drei verschiedenen Stakeholdern, und eine Entscheidung in einer Ebene diktiert selten die anderen. Konzentrieren Sie sich vorerst darauf, ihre Namen und ihre Unterscheidung zu lernen. Die Auswahl zwischen ihnen unter echten Einschränkungen wird später gelehrt, sobald Sie ein Modell, ein Muster und eine Architektur haben, um sie anzupassen.

Ein Fehler, der aus dem Zusammenbrechen der Ebenen kam Ein Vorschlag für eine Einzelhandelsbankingworkflow-Lösung stellte Claude Code, einen Engineering-Einstiegspunkt, vor ein nicht-technisches Publikum, weil der Autor sagte: „Es ist alles Claude. " Es ist alles Claude, in dem Sinne, dass das gleiche Modell unter jedem Einstiegspunkt sitzt. Aber der Einstiegspunkt ist der Wrapper, und Claude Code wurde für Entwickler gebaut, die ein Terminal ausführen, nicht für Bankfilialmitarbeiter, die einen Workflow befolgen. Die Behandlung der drei Ebenen als eine löschte die Unterscheidung aus, die die Wahl sofort ausschließen sollte.

Kosten · Komplexität · Risiko Kosten: Jeder Einstiegspunkt trägt seine eigenen Integrationskosten. Die Auswahl der falschen Ebene, weil das Vokabular unklar war, kann dazu führen, dass Sie für die falsche Lösung bezahlen, dann erneut bezahlen, um sie zu ersetzen. Komplexität: Wenn die drei Ebenen präzise benannt und diskutiert werden, kann eine Designüberprüfung genau isolieren, welche Entscheidung umstritten ist. Wenn sie verschwommen sind, argumentiert die Überprüfung im Kreis. Risiko: Ein Einstiegspunkt, der gewählt wird, bevor der Benutzer benannt wird, ist ein häufiger und vermeidbarer Architektur-Fehler, der oft auf das Zusammenbrechen dieser drei unterschiedlichen Ebenen in ein Konzept zurückzuführen ist.

Screen 4: Platzieren Sie jedes Teil in seiner Ebene

Checkpoint 4 min · Plattformkarte & Primitive

Platzieren Sie jedes Teil in seiner Ebene Klicken Sie auf ein Plattformteil, um es auszuwählen, klicken Sie dann auf den rechten Ebenen-Eimer, um es zu platzieren. Klicken Sie auf ein platziertes Chip, um es zum Pool zurückzubringen. Alle 8 Elemente müssen platziert werden, bevor Sie absenden.

claude. ai Direkte API Claude Desktop SDKs Bedrock / Vertex / Foundry Claude Code MCP Agent SDK

Einstiegspunkte

Build-Zeit-Schnittstellen

Lieferwege

Absenden Jetzt überspringen

Screen 5: Die Teile, aus denen ein Architekt Lösungen zusammensetzt

Unterricht 16 min · Plattformkarte & Primitive

Die Teile, aus denen ein Architekt Lösungen zusammensetzt Jedes Muster und jede Architektur in diesem Kurs ist eine Zusammensetzung einer kleinen Menge von Primitiven. Benennen Sie sie einmal hier, damit die späteren Lektionen zu Kombinationen von Teilen werden, die Sie bereits erkennen.

Sieben Primitive, sieben Aufgaben Lesen Sie jedes Primitive als eine einzelne Aufgabe. Anstatt tief auf ein Primitive einzugehen, behalten Sie einen ganzheitlichen Überblick über alle sieben. Eine Schlüsselfähigkeit als Architekt ist das Zusammensetzen dieser Primitive, um eine Lösung zu entwickeln.

Klicken Sie auf jede Karte, um sie umzudrehen: Die Vorderseite benennt das Primitive und seine Ein-Wort-Aufgabe, die Rückseite gibt die Ein-Satz-Definition.

ActToolsFlip ↻ Was dem Modell ermöglicht, eine Aktion zu ergreifen oder ein Ergebnis aus Ihrem Code zu holen, eine Funktion, die das Modell aufrufen kann.

ConnectMCPFlip ↻ Ein Protokoll zum Verfügbarmachen einer Menge von Tools, damit mehrere Claude-Clients die gleichen Einstiegspunkte erreichen können.

Isolate / parallelizeSubagentsFlip ↻ Übergeben Sie eine begrenzte Teilaufgabe an einen separaten Kontext, damit die Arbeit isoliert oder parallel ausgeführt wird.

GuaranteeHooksFlip ↻ Deterministischer Code, der bei definierten Ereignissen ausgelöst wird, um eine Regel durchzusetzen, die das Modell nicht überspringen kann.

Package a procedureSkillsFlip ↻ Eine versionierte, wiederverwendbare Einheit (Anweisungen plus optionale Skripte), die eine wiederholbare Prozedur verpackt.

Coordinate peersAgent TeamsFlip ↻ Mehrere Agenten, die als koordinierte Peers arbeiten, jeder mit einem Teil eines größeren Ziels.

Compose at runtimeDynamic WorkflowsFlip ↻ Stellen Sie die Schritte eines Workflows zur Laufzeit zusammen, anstatt sie im Voraus zu beheben.

Agent Teams (koordinierte Peer-Agenten) und Dynamic Workflows (Laufzeit-Komposition) erweitern das ältere Vokabular von einzelnen Agenten und festen Workflows. Sie werden in aktuellen Praktiker-Gesprächen benannt, obwohl viele bestehende Systeme ihnen vorausgehen.

Warum sie jetzt inventarisieren Die später in diesem Modul gelehrten Muster – der erweiterte Anruf, der Workflow, der Agent – sind keine abstrakten Kategorien. Jedes Muster ist eine bestimmte Zusammensetzung der sieben Primitive. Ein Workflow ist Schritte, die in Ihrem Code verdrahtet sind, oft mit Tools. Ein Agent ist das Modell, das seine eigene Sequenz von Tool-Aufrufen wählt. Ein Multi-Agent-System ist ein Orchestrator, der an Subagenten delegiert. Wenn Sie diese Lektionen erreichen, werden Sie Primitive zusammensetzen, die Sie bereits benannt haben, nicht zum ersten Mal treffen.

Szenario: Ein Fehler, der aus fehlendem gemeinsamen Vokabular kam In einer Architektur-Überprüfung sagte jemand „wir werden einen Agent verwenden. " Fünf Personen im Raum hörten fünf verschiedene Dinge: einer hörte ein einzelnes Tool-verwendendes Modell, einer hörte einen Multi-Schritt-Workflow, einer hörte ein Team von Subagenten, einer hörte Claude Code und einer hörte einen Chatbot. Das Designgespräch steckte zwanzig Minuten fest, bevor jemand realisierte, dass sie verschiedene Architekturen mit dem gleichen Wort beschrieben. Durch die Etablierung eines gemeinsamen Verständnisses des Primitive-Vokabulars kann das Team mit Klarheit und Effizienz arbeiten.

Kosten · Komplexität · Risiko Kosten: Das Greifen nach einem schwereren Primitive als die Aufgabe erfordert, wird in Latenz, Tokens und Betriebsfläche bezahlt, jede Anfrage. Z. B. Verwendung eines Teams von Agenten, wenn ein einzelner Tool-Aufruf ausreichen würde. Komplexität: Jedes hinzugefügte Primitive ist ein Teil zum Bauen, Beobachten und Regieren. Die Disziplin ist die Verwendung der wenigsten Primitive, die notwendig sind, um die Anforderung zu erfüllen. Risiko: Ohne gemeinsames Vokabular können Teams nicht effektiv kommunizieren, weil sie sich nicht einig sind, was die Teile sind.

Screen 6: Ordnen Sie das Primitive der Aufgabe zu

Checkpoint 4 min · Plattformkarte & Primitive

Ordnen Sie das Primitive der Aufgabe zu Ordnen Sie jedes Element auf der linken Seite seinem Match auf der rechten Seite über die drei Sätze zu. Dies ist die Bereitschaftsprüfung vor der Design-Hälfte des Moduls. Beantworten Sie alle drei Sätze, dann absenden.

Satz 1 von 3: Verhaltenspropriäten zu ihren Designkonsequenzen Ordnen Sie jede Eigenschaft ihrer Designkonsequenz zu. Nicht-DeterminismusWählen... Warum Evaluierungsrahmen existierenWarum Abruf und Tools existierenWarum Kontextstrategie eine Designentscheidung istWarum Platzierung von Menschen in der Schleife wichtig ist WissensgrenzeWählen... Warum Evaluierungsrahmen existierenWarum Abruf und Tools existierenWarum Kontextstrategie eine Designentscheidung istWarum Platzierung von Menschen in der Schleife wichtig ist Kontext als endliche RessourceWählen... Warum Evaluierungsrahmen existierenWarum Abruf und Tools existierenWarum Kontextstrategie eine Designentscheidung istWarum Platzierung von Menschen in der Schleife wichtig ist Vertrauen ist nicht KorrektheitWählen... Warum Evaluierungsrahmen existierenWarum Abruf und Tools existierenWarum Kontextstrategie eine Designentscheidung istWarum Platzierung von Menschen in der Schleife wichtig ist

Satz 2 von 3: Plattformteile zu ihrer Ebene Ordnen Sie jedes Plattformteil der Ebene zu, auf der es sitzt. Claude CodeWählen... EinstiegspunktBuild-Zeit-Schnittstelle Lieferweg MCPWählen... EinstiegspunktBuild-Zeit-Schnittstelle Lieferweg BedrockWählen... EinstiegspunktBuild-Zeit-Schnittstelle Lieferweg

Satz 3 von 3: Primitive zu ihrer Aufgabe Ordnen Sie jedes Primitive seiner Ein-Wort-Aufgabe zu. ToolsWählen... AktIsolieren / parallelisierenGarantierenVerfahren verpacken SubagentsWählen... AktIsolieren / parallelisierenGarantierenVerfahren verpacken HooksWählen... AktIsolieren / parallelisierenGarantierenVerfahren verpacken SkillsWählen... AktIsolieren / parallelisierenGarantierenVerfahren verpacken

Absenden Jetzt überspringen

Screen 7: Wo Claude passt (Claude / Systeme / Menschen)

Unterricht 9 min · Zerlegung

Wo Claude passt (Claude / Systeme / Menschen) Wenn Sie eine Lösung für einen Partner entwerfen, treffen Sie bereits drei Arten von Entscheidungen: Was die Anfrage ist, welche Systeme Sie zur Verfügung haben, um sie zu adressieren, und wo menschliches Urteilsvermögen erforderlich ist. Dieses Modul fügt eine vierte Entscheidung hinzu: Bestimmung, wo Claude helfen kann. Diese vierte Entscheidung ist eine, die Architekten falsch machen, weil ihnen ein tiefes Verständnis der vorhersehbaren Stärken und Fehlermodi von Claude fehlt. Das Ziel dieses Moduls ist es, Ihnen einen konkreten Entscheidungsrahmen zu geben, um zu bestimmen, wo „Claude helfen kann" mit Spezifität.

Wer macht was? Jede Lösung hat drei Besitzer: Sie früh zuzuordnen setzt Sie auf Erfolg Jede Lösung, die Sie mit Claude entwerfen, landet in einem von drei Eimern:

BesitzerWas gehört hier hin

Was Claude tutDie Arbeit, die von Sprachverständnis, Zusammenfassung, Planung, Entwurf oder Tool-vermittelter Aktion profitiert. Was bestehende Systeme tunAlles, das Ihr Partner bereits bezahlt hat, um zuverlässig zu machen: der Bestellstatus-Service, die Policy-Engine, die Regeltabelle, die Datenbank der Aufzeichnung. Was Menschen tunDie Urteilsaufrufe, die Ausnahmepfade, die Genehmigungen, die Momente, in denen richtig zu sein wichtiger ist als schnell zu sein.

Architekten kollabieren manchmal alle drei in „was Claude tut", aber die Überassignation von Aufgaben an Claude macht den Prozess fast immer teurer, langsamer und schwieriger. Der Schlüssel ist zu wissen, was Claude am besten tut und wofür es in Ihrer Lösung verantwortlich sein sollte.

Delegation: Entscheidung, was Claude vertraut wird Zerlegung erzeugt eine Delegationskarte. Für jeden Teil der Anfrage entscheiden Sie nicht nur, ob Claude es tun kann, sondern ob Claude es übernehmen sollte: KI-geeignete Arbeit, von Menschen behaltene Arbeit oder kollaborative Arbeit, wo Claude entwirft und eine Person entscheidet. Rechtfertigen Sie jede Zuweisung durch:

Umkehrbarkeit: Kann ein falscher Anruf rückgängig gemacht werden? Einsätze: Was kostet ein falscher Anruf? Rechenschaftspflicht: Wer muss dafür antworten?

Dieser Bildschirm wird Ihnen die Disziplin der Delegation lehren, die erste der vier AI-Fluency-Kompetenzen. Die vier Verhaltenspropriäten, die Ihnen sagen, was Claude vertraut werden kann, wurden im Grundlagenabschnitt gelehrt; hier werden Sie sie anwenden.

Szenario: Zerlegung einer Partner-Anfrage, Zuweisung jedes Schritts zum richtigen Besitzer Ein Partner fragt nach einem „Claims-Triage-Assistenten, der einen Anspruch liest, Priorität entscheidet, Policy-Abdeckung nachschlägt und eine E-Mail an den Adjuster sendet. " Der erste Instinkt eines Architekten könnte sein, alle vier Schritte in den „Was Claude tut"-Eimer zu legen, aber die Vier-Eigenschaften-Linse stoppt dies:

„Den Anspruch lesen. " Dies liegt direkt in Claudes Fähigkeitszone. Das Lesen und Interpretieren eines Anspruchs ist mustereiche Spracharbeit, und wenn das Ausgabeschema eingeschränkt ist, arbeiten sowohl Next-Token-Prediction als auch Steerability zu Ihrem Vorteil. Dies ist Arbeit, die Claude tut. „Priorität entscheiden. " Dieser Schritt mag wie eine Sprachaufgabe aussehen, aber das ist es nicht. Priorität ist eine deterministische Regel, die Ihr Partner bereits definiert und verwaltet. Was als Priorität in der Organisation des Partners zählt, lebt in einer Policy-Engine, nicht in Claudes Trainingsdaten. Das Routing zu Claude führt eine unnötige Wissensbegrenzung ein. Stattdessen ruft Claude die Policy-Engine auf und das bestehende System übernimmt die Arbeit, um Priorität zu entscheiden. „Policy-Abdeckung nachschlagen. " Dies läuft in das gleiche Problem wie Priorität, aber mit höheren Einsätzen. Richtlinien ändern sich und Abdeckungstabellen werden aktualisiert, und das Modell hat keine zuverlässige Möglichkeit zu wissen, wann die Version, die es während des Trainings gelernt hat, aufgehört hat, aktuell zu sein. Die Antwort muss aus dem System kommen, das die Live-Abdeckungsdaten hält, abgerufen durch Tool-Nutzung oder einen MCP-Server. „E-Mail an den Adjuster senden. " Dieser Schritt muss aufgeteilt werden. Das Entwurf der Nachricht ist Spracharbeit und etwas für Claude zu tun. Das Senden der Nachricht gehört zum E-Mail-System. Ein Mensch sollte alles über einem Wertschwellenwert überprüfen und genehmigen, weil wenn Claude allein entscheidet, seine Working-Memory- und Steerability-Einschränkungen beide Risiken werden.

Zerlegung sollte von der Frage angetrieben werden „wo argumentieren die vier Eigenschaften für Claude über das System, das dies bereits richtig macht? " anstatt „Wo kann Claude helfen? " Achten Sie genau auf diese Verschiebung in der Rahmung, sie ist das Schlüsselkonzept, das dieses Modul aufbaut.

Kosten · Komplexität · Risiko Kosten: Jede Nachschlagung, die ein einfaches deterministisches System hätte handhaben können, wird stattdessen an Claude gesendet. Sie enden damit, dass Sie für das Modell bezahlen, um Arbeit zu tun, die eine Datenbankabfrage oder eine Regeltabelle für einen Bruchteil der Kosten hätte tun können, und über Tausende von Anfragen kann sich das schnell summieren. Komplexität: Wenn Sie Logik aus einem tabellengesteuerten System in das Modell verschieben, werden Fehler nicht mehr nachverfolgbar. Eine deterministische Regel schlägt auf vorhersehbare, debuggbare Weise fehl. Ein Modell, das die gleiche Aufgabe handhabt, erzeugt variable Ausgaben, die viel schwieriger zu beobachten und zu diagnostizieren sind. Risiko: Das Modell hat keine zuverlässige Möglichkeit zu wissen, wann seine Informationen veraltet sind, und es wird die Lücke nicht kennzeichnen. Wenn das Modell zur Quelle der Wahrheit wird, anstatt zum tatsächlichen System des Partners, können autoritative Antworten stillschweigend driften, ohne dass ein Fehler geworfen oder eine Warnung ausgelöst wird.

Screen 8: Wenn die deterministische Überprüfung stillschweigend driftete

Vorsicht 4 min · Zerlegung

Wenn die deterministische Überprüfung stillschweigend driftete

Setup-Hook Wenn das Team über Claude begeistert ist, bietet das Platzieren einer deterministischen Überprüfung im Modell ein saubereres Design: eine Komponente, weniger Integrationen und einfacher zu demonstrieren. Es ist die Art von Bewegung, die ein Senior-Architekt macht, wenn ein Team schnell vorangeht und die Regel „einfach genug" für das Modell aussieht.

Ein Scoping-Anruf, transkribiert Das Gespräch unten ist ein echtes Scoping-Austausch. Zwei Personen treffen eine vernünftige Entscheidung, um ein Design zu vereinfachen, und im Moment sieht es wie ein sauberer Gewinn aus. Was sie tatsächlich getan haben, ist eine deterministische Geschäftsregel, die jedes Mal richtig sein muss, an das Modell übergeben, ein probabilistisches System, das die meiste Zeit richtig ist, aber nicht immer. Diese Lücke tauchte während der Entwicklung nicht auf, sondern tauchte drei Monate später in einer Audit auf. Dieser Abschnitt erforscht einen Fehlermodus, bei dem das Ziel darin besteht, Ihnen zu zeigen, was schief gelaufen ist, damit Sie das Muster früh erkennen und eine andere Entscheidung treffen können.

Partner: „Wir haben eine Regel, dass jeder Anspruch über £5. 000 einen Senior-Adjuster benötigt. Heute machen wir eine SQL-Überprüfung gegen die Anspruchstabelle. Kann Claude das stattdessen handhaben? " Architekt: „Wir können Claude auffordern, den Betrag zu extrahieren und entsprechend weiterzuleiten, wenn er über 5K liegt. Das hält es in einem Schritt, anstatt ein separates System zu erreichen, um zu überprüfen, also ist es viel einfacher. " Partner: „Perfekt, das funktioniert für mich. "

[Drei Monate später, in der Produktion]

Von 14. 000 verarbeiteten Ansprüchen wurden 41 falsch weitergeleitet Alle 41 teilten das gleiche Problem. Der Betrag war nicht als saubere Zahl geschrieben. Er war in einem Satz versteckt, wie „Schäden geschätzt auf etwa fünftausend Pfund. " Das Modell behandelte „etwa fünftausend" als eine lose Schätzung, anstatt eine Zahl, die eine Senior-Überprüfung auslösen sollte, also gingen diese Ansprüche zur Standard-Handhabung. Die Regel war präzise. Die Informationen, mit denen es arbeiten musste, waren es nicht, und das Modell befolgte den Buchstaben der Regel, anstatt ihrer Absicht.

Was brach: eine deterministische Regel, die an ein probabilistisches System übergeben wurde Der Schwellenwert änderte sich nicht, aber was die Regel durchsetzte, tat es. Eine deterministische Regel, die jedes Mal richtig sein muss, wurde in Claude gefaltet, was die meiste Zeit richtig ist. Die Lücke zwischen ihnen ist der Ort, an dem die 41 Fehlleitung lebten. Das Team erstellte nie einen Satz von Testfällen, um das Routing zu überprüfen, weil sie Routing als etwas behandelt hatten, das das Modell einfach handhaben würde, anstatt eine Regel, auf die das Geschäft zählte. Dieser Unterschied ist der Kern des Problems. Eine Regel, auf die das Geschäft zählt, muss getestet, beobachtet und von einem Menschen übernommen werden. Etwas, das Sie annehmen, das Modell wird handhaben, wird allein gelassen, bis es bricht. Die Fehlleitung wurden von einer Audit gefunden, nicht vom System selbst. Die Art von Protokollierung, die einen gebrochenen SQL-Check gefangen hätte, zeichnet nicht die Entscheidungen auf, die ein Modell in einer einzelnen Anfrage trifft, also kennzeichnete nichts die Drift. Der Fehler blieb unsichtbar, bis jemand danach suchte.

Warum das brach Eine Regel, die jedes Mal richtig sein muss, wurde an ein System übergeben, das die meiste Zeit richtig ist. Dieser Kompromiss ist leicht zu übersehen, während Sie scoping, weil das Modell die sauberen Fälle korrekt handhabt, und saubere Fälle sind das, was Sie in Demos und frühen Tests sehen. Die Kosten von „die meiste Zeit" offenbaren sich nicht, bis Sie audieren und bis dahin ruft der Partner an.

Screen 9: Sortieren Sie die Feldservice-Fähigkeiten

Checkpoint 4 min · Zerlegung

Sortieren Sie die Feldservice-Fähigkeiten Ein Feldservice-Partner hat Ihnen eine Anfrageliste für einen Wissensassistenten übergeben, den ihre Ingenieure vor Ort verwenden werden. Klicken Sie auf eine Fähigkeit, um sie auszuwählen, klicken Sie dann auf den rechten Besitzer-Eimer, um sie zu platzieren. Alle 8 Elemente müssen platziert werden, bevor Sie absenden.

Zusammenfassung der Fallnotizen des Ingenieurs in eine einseitige Übergabe Rückgabe des aktuellen Lagerbestands des Teils SKU 78-A im nächsten Lagerhaus Genehmigung einer Rückerstattung über £2. 000, wenn der Ingenieur eine anfordert Extrahieren Sie die Teilenummer aus einem Foto des Einheitenetiketts Berechnen Sie die gesamte abrechenbare Zeit über drei Jobtickets Entwurf einer Folge-E-Mail an den Kunden, die die Verzögerung erklärt Sagen Sie dem Ingenieur, ob die Garantie für diese Seriennummer gilt Entscheiden Sie, ob Sie einen Sicherheitsvorfall zum Feldmanager eskalieren

Claude

Bestehende Systeme

Mensch

Absenden Jetzt überspringen

Screen 10: Zerlegung der Anfrage

Checkpoint 4 min · Zerlegung

Zerlegung der Anfrage Ein Partner-Brief ist unten. Wählen Sie für jeden Schritt den richtigen Besitzer: was Claude tut, was bestehende Systeme tun oder was Menschen tun. Der vorherige Checkpoint testete, ob Sie die vier Eigenschaften erkennen könnten; dieser testet, ob Sie die Aufteilung zerleggen können.

Der Brief Ein regionaler Logistik-Partner möchte einen Assistenten, der für jede eingehende Versand-Ausnahme: die Freitext-Ausnahmeanmerkung des Spediteurs liest, entscheidet, ob die Sendung für eine automatische Rückerstattung unter der veröffentlichten Richtlinie des Partners berechtigt ist, den Vertragstier des Kunden nachschlägt, eine Benachrichtigung an den Kunden entwirft und die Rückerstattung ausstellt.

Lesen Sie die Freitext-Ausnahmeanmerkung des Spediteurs

Claude Bestehendes System Mensch

Entscheiden Sie, ob die Sendung für eine automatische Rückerstattung unter der veröffentlichten Richtlinie des Partners berechtigt ist

Claude Bestehendes System Mensch

Nachschlag des Vertragstiers des Kunden

Claude Bestehendes System Mensch

Entwurf der Kundenbenachrichtigung

Claude Bestehendes System Mensch

Ausstellen der Rückerstattung

Claude Bestehendes System Mensch

Absenden Jetzt überspringen

Screen 11: Zusammensetzung von Primitiven in erweiterten Anruf, Workflow, Agent

Unterricht 13 min · Musterwahl

Zusammensetzung von Primitiven in erweiterten Anruf, Workflow, Agent Sobald Sie festgestellt haben, welche Teile einer Aufgabe Claude übernimmt, gegenüber dem, was Ihre Systeme und Menschen übernehmen, ist die nächste Entscheidung strukturell: Welche Form nimmt Claudes Beteiligung an? Es gibt drei Muster zur Auswahl: ein erweitertes LLM, ein Workflow und ein Agent. Jedes nimmt eine andere Position auf zwei Achsen ein: Vorhersehbarkeit (wie vorhersehbar der Weg durch die Arbeit ist) und Modell-Autonomie (wie viel Autonomie Sie dem Modell geben möchten).

Drei Muster zur Strukturierung von Claudes Beteiligung

Erweitertes LLM Workflow Agent

Ein einzelner Modell-Aufruf: Sie senden die Anfrage, das Modell vervollständigt die Aufgabe und Ihr Code handhabt die Verdrahtung darum. Sie können Tool-Nutzung, Abruf oder erweitertes Denken zu diesem Anruf hinzufügen, aber das Modell tut immer noch eine begrenzte Aufgabe in einem Pass. Der Kontrollfluss verzweigt sich nie basierend auf das, was das Modell entscheidet. Verwenden Sie dies, wenn die Aufgabe gut definiert ist, die Ausgabe etwas ist, das Sie überprüfen können, und es keinen Grund gibt, die Arbeit über mehrere Schritte zu teilen. Sie zerlegen die Aufgabe in benannte Schritte und orchestrieren sie in Ihrem eigenen Code. Jeder Schritt kann Claude aufrufen oder nicht. Weil der Kontrollfluss in Ihrem Code lebt, anstatt im Modell, können Sie ihn protokollieren, testen und sein Verhalten wie jedes andere Stück Software begründen. Verwenden Sie dies, wenn Fehlerkosten real sind, Beobachtbarkeit wichtig ist und die Schritte im Voraus bestimmt werden können. Sie geben Claude ein Ziel und eine Menge von Tools und das Modell bestimmt seine eigene Sequenz von Schritten, um dieses Ziel zu erreichen. Der Kontrollfluss lebt im Modell, nicht in Ihrem Code. Das ist das, was es zu einem Agent macht, anstatt zu einem Workflow: Der Weg durch die Arbeit ist nicht im Voraus irgendwo geschrieben, wo Sie ihn inspizieren können. Verwenden Sie dies nur, wenn der Weg durch die Arbeit nicht im Voraus aufgezählt werden kann, und nur wenn die Kosten einer unerwarteten oder inkonsistenten Ausgabe akzeptabel und wiederherstellbar sind. In der Produktion sind Agenten typischerweise durch begrenzte Tool-Einstiegspunkte, Pro-Turn-Budgets, explizite Berechtigungen und Stoppkriterien gebunden. Diese Einschränkungen sind keine Optionen; sie halten einen Agent davon ab, eine Haftung zu werden.

Zuordnung von Anwendungsfällen nach Vorhersehbarkeit und Autonomie Zeichnen Sie jeden Anwendungsfall auf zwei Achsen auf: wie vorhersehbar die Aufgabe ist und wie viel Autonomie Sie dem Modell gewähren möchten.

HOCH NIEDRIG NIEDRIGE VORHERSEHBARKEIT HOHE VORHERSEHBARKEIT MODELL-AUTONOMIE

AgentHohe Autonomie, niedrige Vorhersehbarkeit. Das Modell besitzt die Flugbahn. WorkflowVorhersehbare Form; begrenzte Modell-Urteilsfindung in jedem Schritt. Erweitertes LLMHohe Vorhersehbarkeit, niedrige Autonomie. Ein einzelner begrenzter Modell-Anruf.

Erweiterte LLMs sitzen im Quadranten hoher Vorhersehbarkeit, niedriger Autonomie. Sie kennen die Aufgabe, Sie wissen, was gut aussieht, und das Modell führt es einmal aus. Workflows besetzen das mittlere Band. Die Gesamtform ist vorhersehbar, aber jeder Schritt kann Modell-Urteilsfindung auf begrenzte Weise beinhalten. Agenten sitzen in der Ecke hoher Autonomie, niedriger Vorhersehbarkeit. Dies ist das Muster, das Sie erreichen, wenn die Aufzählung der Schritte im Voraus und die teure Teil des Problems ist: offene Untersuchung, langfristige Arbeit und Aufgaben, bei denen der nächste Schritt davon abhängt, was der letzte aufgedeckt hat. Claude Code ist ein produktionserprobtes Beispiel: Es erforscht eine unbekannte Codebasis, entscheidet, welche Dateien basierend auf dem, was es bereits gefunden hat, zu lesen sind, und führt Multi-Schritt-Engineering-Arbeit aus, die niemand im Voraus skripten könnte. Das ist die Fähigkeit, die Agenten freischalten, aber die zugehörigen Kosten sind genauso real. Dies ist der Ort, an dem sich nicht-deterministische Fehler in der Produktion konzentrieren, weil die Flugbahn des Modells der Kontrollfluss ist und es keine Code-Grenze gibt, wo eine Wache sitzen kann.

Unter-Muster innerhalb von Workflows Die Wahl eines Workflows spezifiziert das Design nicht vollständig. Es gibt vier Formen, die ein Workflow annehmen kann, und jede spiegelt eine andere Annahme darüber wider, wie die Schritte zueinander in Beziehung stehen.

Unter-MusterFormWann es seinen Platz verdientBeispiele

Verkettung Schritt 2 nimmt die Ausgabe von Schritt 1 als Eingabe, arbeitet sequenziell und linear. Verwenden Sie dies, wenn sich die Aufgabe natürlich in Phasen mit klaren Übergaben zerlegt, wie Extrahieren, dann Klassifizieren, dann Zusammenfassen. Jede Phase hat eine definierte Ausgabe, die die nächste Phase verbraucht. Eine Vertragsüberprüfungs-Pipeline: Der erste Anruf extrahiert alle Verpflichtungen und Fristen aus dem Rohdokument, der zweite klassifiziert jede nach Risikostufe und der dritte entwirft ein Zusammenfassungs-Memo für den Anwalt. Jede Phase hat eine saubere Ausgabe, die die nächste Phase verbraucht.

Routing Ein Klassifizierer, oft Claude selbst, entscheidet, welchen nachgelagerten Pfad zu nehmen. Verwenden Sie dies, wenn Eingaben in Art variieren und verschiedene Arten unterschiedliche Handhabung erfordern. Ein eingehender Support-Ticket kommt an: Ein Klassifizierer liest es und leitet Abrechnungsfragen an einen Abruf-Index über Kontodaten, technische Probleme an einen Abruf-Index über Produktdokumentation und Eskalationen direkt an eine menschliche Warteschlange. Der gleiche Eingabe-Einstiegspunkt, drei verschiedene Handhabungspfade.

Parallelisierung Mehrere Modell-Aufrufe laufen gleichzeitig; Ergebnisse werden aggregiert oder abgestimmt. Verwenden Sie dies, wenn Teilaufgaben unabhängig sind und gleichzeitig laufen können. Das Überprüfen mehrerer Dateien oder das Überprüfen unterschiedlicher Abschnitte eines langen Dokuments passt zu dieser Form, weil keine Teilaufgabe von der Ausgabe der anderen abhängt. Eine Due-Diligence-Überprüfung über zwölf Lieferantenverträge: Jeder Vertrag wird gleichzeitig an einen separaten Modell-Anruf gesendet. Alle zwölf Ergebnisse werden zurückgegeben und in einen einzelnen Risikobericht aggregiert. Kein Anruf hängt von der Ausgabe eines anderen ab, also gibt es keinen Grund, sie sequenziell auszuführen.

Evaluator-Optimizer Ein Modell-Anruf erzeugt einen ersten Versuch der Ausgabe. Ein zweiter Anruf bewertet ihn und fordert Überarbeitung an. Die Schleife wiederholt sich, bis ein Qualitätskriterium erfüllt ist oder ein Wiederholungslimit erreicht ist. Verwenden Sie dies, wenn Qualität überprüfbar ist, aber ein einzelner Versuch nicht zuverlässig genug ist. Code-Generierung gegen eine Test-Suite oder strukturierte Ausgabe-Extraktion mit einem strikten Schema sind häufige Anwendungen. Ein Modell entwirft eine Antwort auf eine Kundenbeschwerden. Ein zweiter Modell-Anruf bewertet den Entwurf gegen eine Rubrik (benennt er das spezifische Problem, übernimmt Verantwortung, bietet konkrete nächste Schritte im Ton der Marke an) und überprüft, ob die Ausgabe der erwarteten Struktur entspricht. Wenn nicht, gibt der Evaluator spezifisches Feedback zurück und der Generator schreibt um. Die Schleife endet, wenn jedes Rubrik-Element besteht oder ein Wiederholungslimit erreicht.

Diese vier Muster schließen sich nicht gegenseitig aus. Die meisten Produktions-Workflows kombinieren mehr als ein Muster, und die richtige Wahl ist normalerweise die einfachste, die die Fehlertoleranz und Beobachtbarkeitsanforderungen der Aufgabe erfüllt, und überprüfen Sie diese Wahl erneut, sobald Sie Produktionsdaten haben; eskalieren Sie nur, wenn die Messung zeigt, dass das einfachere Muster zu kurz kommt.

Ein Rahmen zur Wahl des richtigen Musters: fünf Faktoren in Reihenfolge Gehen Sie diese fünf Faktoren in Reihenfolge durch. Fragen Sie für jeden, ob der Faktor eines der drei Muster ausschließt – Erweitertes LLM, Workflows, Agent. Der erste Faktor, der ein Muster ausschließt, ist der entscheidende. Die Tabelle unten zeigt, was jedes Muster Sie auf jedem Faktor kostet, damit Sie genau sehen können, wo die Kompromisse landen.

FaktorDie Frage zu beantwortenErweitertes LLMWorkflowAgent

VorhersehbarkeitKönnen Sie die Schritte im Voraus aufzählen? Niedrig: einzelne begrenzte Aufgabe. Niedrig: Sie haben den Weg geschrieben. Hoch: Flugbahn ist von Natur aus unvorhersehbar. FehlerkostenWas kostet eine falsche Antwort: einen Wiederholungsversuch, eine Audit, eine Klage? Mittel: setzt Sie der Ausgabeverteilung des Modells ohne Schritt-Ebene-Wachen aus. Niedrig: deterministische Wachen sitzen zwischen Schritten. Hoch: setzt Sie der vollständigen Ausgabeverteilung über mehrere Runden aus. BeobachtbarkeitKann Ihr Betriebsteam sehen, was passiert ist und rekonstruieren, warum? Mittel: ein einzelner Anruf ist einfach zu protokollieren, aber undurchsichtig innen. Niedrig: Schritte protokollieren wie Code, mit Standard-Werkzeugen. Hoch: die Flugbahn liest wie ein Transkript; die meisten aktuellen Beobachtbarkeits-Werkzeuge sind nicht gebaut, um dies zu alarmieren. Latenz-BudgetWas ist die Benutzer-sichtbare Frist? Niedrig: schnellste in Standard-Konfigurationen, obwohl erweitertes Denken oder Abruf Zeit hinzufügt. Mittel: vorhersehbar, aber additiv in Dauer. Hoch: Laufzeit ist offen; Budget für den schlimmsten Fall, nicht den Median. KostenWas sind die Pro-Anfrage-Token-Kosten bei Ihrem erwarteten Volumen? Niedrig: wenigste Tokens pro Anfrage. Mittel: skaliert mit Schritt-Anzahl. Hoch: iteratives Denken, Multi-Turn-Tool-Nutzung, Wiederholungen und wachsender Kontext können Token-Nutzung und Latenz materiell erhöhen. Schlecht begrenzte Agenten sind oft das teuerste Muster.

Versuchen Sie Prompting, bevor Sie Fine-Tuning in Betracht ziehen Wenn Prompting sich unzuverlässig anfühlt, ist der Instinkt für viele Ingenieure, Fine-Tuning zu erreichen. Bei Claude ist das normalerweise der falsche erste Schritt. Arbeiten Sie zuerst durch diese Sequenz:

Optimieren Sie die Eingabeaufforderung. Die meisten Zuverlässigkeitsprobleme sind Eingabeaufforderungs-Probleme. Fügen Sie Tool-Nutzung oder Abruf hinzu, wenn die Eingabeaufforderung allein nicht ausreicht. Wechseln Sie zu einem stärkeren Muster wie einem Evaluator-Optimizer, wenn die Qualität immer noch nicht dort ist, wo sie sein muss. Erwägen Sie erst dann Fine-Tuning.

Fine-Tuning hat seinen Platz, aber in spezifischen Situationen:

Die Aufgabe läuft mit sehr hohem Volumen und Inferenz-Kosten sind die echte Einschränkung. Latenz ist kritisch und ein kleineres spezialisiertes Modell wird ein Prompt-allgemeines übertreffen. Die Ausgabe muss einem konsistenten Format folgen und Prompting hat es nicht zuverlässig gelöst.

Außerhalb dieser Situationen sperrt Fine-Tuning Sie auf eine feste Modellversion und verengt Ihre Optionen, ohne viel dafür zu zeigen. Behandeln Sie es als den letzten Schritt in einer absichtlichen Progression, nicht als schnelle Lösung für eine Eingabeaufforderung, die noch nicht funktioniert.

Hinweis zur Verfügbarkeit Fine-Tuning Claude ist nicht weit verfügbar. Der Zugriff ist begrenzt, variiert je nach Modell und Lieferweg und ändert sich, wenn Anthropic das Programm erweitert. Bestätigen Sie aktuelle Optionen mit dem Anthropic-Account-Team, bevor Sie diesen Weg einem Partner empfehlen.

Diese drei Muster sind keine abstrakten Kategorien. Jedes ist eine Zusammensetzung der Primitive, die Sie im Grundlagenabschnitt inventarisiert haben: ein erweiterter Anruf ist das Modell plus Tools; ein Workflow ist Primitive, die in Ihrem eigenen Code verdrahtet sind; ein Agent ist das Modell, das seine eigene Sequenz von Tool-Aufrufen wählt. Die Wahl eines Musters ist die Wahl, wie diese Teile zusammengesetzt werden.

Fähigkeits-basierte Architektur als Verpackungsoption Neben der Wahl eines Musters entscheiden Sie, wie die Fähigkeit verpackt wird. Drei Optionen sitzen auf einem Spektrum: eine Eingabeaufforderungs-Only-Lösung (nur Anweisungen), direkte Tool-Nutzung (das Modell ruft Funktionen in Ihrem Code auf) und eine Fähigkeits-basierte Architektur (eine versionierte, wiederverwendbare Fähigkeit, die die Prozedur, ihre Anweisungen und alle Skripte als eine regierte Einheit verpackt). Erreichen Sie eine Fähigkeit, wenn die gleiche Prozedur wiederholt läuft, über Teams oder Produkte verteilt werden muss oder versioniert und regiert werden muss. Wenden Sie die Delegations-Linse auf das Muster selbst an: Gewährt dieses Muster Claude angemessene oder übermäßige Entscheidungsautorität für das Risikoprofil vor Ihnen? Ein Agent, der autonom handeln kann, ist die richtige Wahl nur, wenn die Einsätze und Umkehrbarkeit seiner Handlungen die Autonomie rechtfertigen, die ihm gegeben wird.

Kosten · Komplexität · Risiko Kosten: Agenten kosten nicht automatisch mehr als Workflows. Was die Kosten antreibt, ist, wie viel Kontext über das Gespräch hinweg akkumuliert und wie viele Modell-Aufrufe gemacht werden. Ein schlecht gestalteter Workflow kann mehr kosten als ein gut gestalteter Agent. Design ist wichtiger als die Muster-Bezeichnung. Komplexität: Workflows und Agenten scheitern auf unterschiedliche Weise. Ein Workflow schlägt fehl, wenn ein Schritt in Ihrem Code schlägt fehl. Ein Agent schlägt fehl, wenn das Modell irgendwo in einer Sequenz von Runden eine schlechte Entscheidung trifft. Diese zweite Art von Fehler ist schwieriger zu erkennen und schwieriger zu diagnostizieren, und Ihre Standard-Debug-Werkzeuge werden es nicht auf die gleiche Weise fangen. Risiko: Die Autonomie eines Agenten ist Ihre Haftungsfläche. Ein Agent kann alles tun, das seine Tools erlauben, einschließlich Kombinationen, die Sie nicht getestet haben. Je breiter die Tool-Berechtigungen, desto größer der Raum von Dingen, die schief gehen können. Halten Sie den Tool-Einstiegspunkt so eng wie die Aufgabe erlaubt.

Screen 12: Wenn das Team Flexibilität wollte und Nicht-Determinismus bekam

Vorsicht 4 min · Musterwahl

Wenn das Team Flexibilität wollte und Nicht-Determinismus bekam

Setup-Hook: wenn Teams Agenten wählen und sollten nicht Dies ist ein häufiger Fehler. Agenten werden oft gewählt, weil sich eine Aufgabe offen-endig anfühlt, nicht weil die Aufgabe einen erfordert. Aber sich unsicher über die Strukturierung der Arbeit zu fühlen, ist anders als eine Aufgabe, bei der die Schritte wirklich nicht im Voraus bestimmt werden können. Wenn Sie die Schritte in Code hätten schreiben können, hätten Sie einen Workflow statt eines Agenten verwenden und die unnötige Komplexität des nicht-deterministischen Kontrollflusses vermeiden können.

Die drei Zitate unten sind aus der 90-Tage-Retrospektive eines einzelnen Teams. Jedes benennt eine andere Ebene des gleichen zugrunde liegenden Fehlers.

„Wir haben einen Agent gewählt, weil wir ihn nicht zu früh einschränken wollten. Nach Monat zwei hatten wir so viele Schutzschienen-Tools hinzugefügt, dass wir den Workflow im Wesentlichen im Agent-Loop umgeschrieben hatten, minus die Protokollierung. " „Compliance kam herein und fragte, welcher Schritt die Auszahlung genehmigt hatte. Wir zeigten auf einen Modell-Turn. Sie fragten, welche Version des Modells. Wir überprüften die Spur. Die Version war zwei Wochen früher vorangerollt und niemand hatte neu validiert. " „Die tatsächlichen Pfade durch das System, als wir die Spuren abbauten, fielen in nur vier Formen. Vier. Wir hätten das als einen Router und vier Ketten schreiben können und uns sechs Monate gespart. "

Was brach und warum Jedes Zitat benennt einen unterschiedlichen Fehler, und sie verstärken sich in Reihenfolge. Das Team optimierte für unbekannte zukünftige Flexibilität, anstatt für die bekannte gegenwärtige Form. Als das Team ihre Spuren nach Monat drei abbaute, fielen die tatsächlichen Pfade durch das System in vier Formen, alle aufzählbar von Woche eins. Der Workflow, den sie brauchten, war ein Router mit vier Ketten. Sie bauten stattdessen einen Agent und verbrachten sechs Monate damit, diese Struktur im Loop zu rekonstruieren. Nicht-Determinismus wurde ein Compliance-Problem. Als ein Auditor fragte, welcher Schritt eine Auszahlung genehmigt hatte, konnte das Team nur auf einen Modell-Turn zeigen. Was das Agent-Muster speziell hinzufügte, war, keinen diskreten, überprüfbaren Schritt zu haben, auf den man zeigen kann. Dies ist, wie Agent-Autonomie zu einem Compliance-Risiko wird: nicht im normalen Betrieb, sondern wenn eine externe Partei eine deterministische Antwort braucht und das System nur eine Flugbahn erzeugen kann. Eine ungepinnte Modellversion verstärkte die Lücke. Der Auditor fragte dann, welche Version des Modells gelaufen war. Die Spur zeigte, dass die Version zwei Wochen früher vorangerollt war, ohne Neu-Validierungs-Checkpoint. Dieser Voranroll ist eine Modell-Governance-Lücke und wäre ein Problem unter jedem Muster gewesen: eine ungepinnte Version ohne Neu-Validierungs-Gate oder ein Workflow, der auf die gleiche Weise versendet wurde, hätte die gleiche Exposition geerbt. Nur einer dieser zwei Fehler ist über das Agent-Muster selbst.

Die Wahl eines Agenten, wenn Sie sich nicht sicher sind, ob es das richtige Muster ist, ist keine sichere Voreinstellung. Ein Agent ist die richtige Wahl nur, wenn die Schritte durch die Arbeit wirklich nicht im Voraus bestimmt werden können. Wenn die Schritte im Voraus bekannt sind, die Wahl eines Agenten über einen Workflow bedeutet, dass Sie für Flexibilität bezahlen, die Sie nicht verwenden werden: zusätzliche Tokens, Latenz und Audit-Lücken, die sich offenbaren, wenn Compliance etwas fragt, das Ihre Spuren nicht beantworten können. Agenten sollten nicht vermieden werden, aber sie sollten zweckmäßig sein. Wenn die Arbeit wirklich unvorhersehbar gewesen wäre, wäre ein Agent genau aus diesem Grund die richtige Wahl gewesen. Der Fehler dieses Teams war, zu einem Agent zu springen, wenn die vier Pfade durch ihr System von Anfang an bekannt waren. Ein Router und vier Ketten hätten ihnen eine saubere, überprüfbare Struktur gegeben. Stattdessen verbrachten sie sechs Monate damit, diese Struktur von Hand im Agent-Loop zu rekonstruieren.

Screen 13: Multi-Agent-Systeme und Orchestrierung

Unterricht 9 min · Musterwahl

Multi-Agent-Systeme und Orchestrierung Musterwahl sagte Ihnen, wann Sie einen Agent erreichen sollten. Einige Probleme sind zu groß oder zu vielfältig für einen einzelnen Agent, um in einem Kontext zu halten. Wenn das passiert, bewegt sich das Design zu mehreren Agenten, die zusammenarbeiten: ein Orchestrator, der die Arbeit zerlegt und Subagenten, die jeweils einen Teil tragen. Dieser Bildschirm lehrt, wie diese Systeme strukturiert sind, wie sie scheitern und wo ein Mensch in der Schleife gehört.

Orchestrator und Subagenten: Rollen, Delegation, Synthese Ein Multi-Agent-System hat zwei Rollen.

Der Orchestrator Besitzt das Ziel: Er zerlegt die Arbeit, entscheidet, was zu delegieren ist, und synthetisiert die Ergebnisse in eine einzelne Antwort. Der Orchestrator tut die Teilaufgaben-Arbeit selbst nie; seine Aufgabe ist Delegation und Synthese.

Die Subagenten Besitzen begrenzte Teilaufgaben: Jeder läuft in seinem eigenen Kontext, tut ein Stück und gibt ein Ergebnis zurück.

Drei Dinge müssen entworfen werden, nicht angenommen: wie die Arbeit in Teilaufgaben zerlegt wird, wie das Ergebnis jedes Subagenten strukturiert wird, damit der Orchestrator es kombinieren kann, und wie der Orchestrator Konflikte oder Lücken auflöst, wenn die Ergebnisse zurückkommen.

Das bearbeitete Muster: Fan-Out über ein großes Arbeitselement Die häufigste Multi-Agent-Form ist ein Fan-Out. Zum Beispiel: Ein übergeordneter Agent steht vor einem Arbeitselement, das zu groß für einen Kontext ist: eine 400-Datei-Codebasis zum Audieren, ein 200-Dokument-Korpus zum Zusammenfassen und eine regulatorische Einreichung zum Überprüfen gegen fünfzig Regeln. Der Orchestrator teilt das Element in unabhängige Einheiten, sendet einen Subagenten pro Einheit (parallel, wo die Einheiten nicht voneinander abhängen) und synthetisiert dann die zurückgegebenen Ergebnisse in ein einzelnes Lieferelement. Hier ist der Gewinn zweifach: Jeder Subagent arbeitet in einem sauberen Kontext, der auf seine Einheit dimensioniert ist, und unabhängige Einheiten laufen gleichzeitig.

Fehlerwiederherstellung: wo ein Fehler gefangen werden kann und wo nicht In einem Multi-Agent-System ist die architektonische Frage zu stellen: „Wo ist jeder Fehlermodus wiederherstellbar? "

Ein Subagenten-Fehler ist normalerweise wiederherstellbar: Wenn eine Einheit schlägt fehl, kann der Orchestrator sie erneut versuchen, sie woanders leiten oder sie fallen lassen und die Lücke kennzeichnen, während der Rest der Arbeit fortfährt. Ein Orchestrator-Fehler ist normalerweise nicht wiederherstellbar: Wenn der Agent, der das Ziel besitzt und die Synthese hält, seinen Faden verliert, schlägt der ganze Lauf fehl und teilweise Subagenten-Arbeit kann gestrandet sein.

Entwerfen Sie für diese Asymmetrie, machen Sie Subagenten-Arbeit idempotent und wiederholbar, und schützen Sie den Orchestrator-Status.

FehlerWo es landetDesign-Antwort

Ein Subagent gibt ein fehlgeformtes oder leeres Ergebnis zurückSubagenten-Grenze (wiederherstellbar)Validieren Sie jedes Ergebnis; versuchen Sie die fehlgeschlagene Einheit erneut oder leiten Sie sie um; zeichnen Sie die Lücke auf, anstatt den Lauf fehlschlagen zu lassen. Zwei Subagenten geben widersprüchliche Ergebnisse zurückSynthese-Schritt (wiederherstellbar)Geben Sie dem Orchestrator eine explizite Konflikt-Auflösungs-Regel oder eskalieren Sie den Konflikt zu einem Menschen. Der Orchestrator verliert das Ziel oder seinen Synthese-StatusOrchestrator (oft nicht wiederherstellbar)Schützen Sie Orchestrator-Status; Checkpoint-Fortschritt, damit ein fehlgeschlagener Lauf fortgesetzt werden kann, anstatt neu zu starten. Spuren fragmentieren sich über Orchestrator und SubagentsBeobachtbarkeit (übergreifend)Propagieren Sie eine gemeinsame Spur-ID, damit ein einzelner Lauf end-to-end rekonstruierbar ist.

Menschliche-in-der-Schleife-Checkpoint-Muster für Agent-Workflows Ein Multi-Agent-System kann viele Aktionen ergreifen, bevor ein Mensch die Ausgabe jemals sieht, was die Checkpoint-Platzierung zu einer absichtlichen Designentscheidung macht. Ein Menschliche-in-der-Schleife-Checkpoint ist ein Gate, das die Ausführung für Überprüfung pausiert, positioniert nach dem Risiko und der Umkehrbarkeit der Aktion, die der Subagent sonst autonom ergreifen würde. Platzieren Sie ein Gate vor jeder irreversiblen oder hochriskanten Aktion, die ein Subagent sonst autonom ergreifen würde; probieren Sie niedrigere Risiko-Aktionen, anstatt jede zu gaten. Die vollständige Behandlung des Routings nach Einsätzen wird in einem späteren Abschnitt abgedeckt, hier ist der Punkt, dass das Gate Teil des Orchestrierungs-Designs ist, nicht später angebracht.

Kosten · Komplexität · Risiko Kosten: Multi-Agent-Systeme multiplizieren Token-Ausgaben, jeder Subagent hat seinen eigenen Kontext, und der Orchestrator bezahlt, um zu synthetisieren. Erreichen Sie das Muster, wenn die Arbeit wirklich einen Kontext überschreitet, nicht als Voreinstellung. Komplexität: Jeder hinzugefügte Agent ist eine weitere Fehler-Grenze zum Beobachten und Regieren. Die Disziplin ist die wenigsten Agenten, die die Anforderung erfüllen, mit klarem Besitz des Ziels. Risiko: Der gefährliche Fehler ist der stille: Ein Subagent lässt eine Einheit fallen und der Orchestrator synthetisiert eine selbstbewusste, vollständig aussehende Antwort über unvollständige Arbeit. Validieren Sie Abdeckung, nehmen Sie nicht an, dass sie vorhanden ist.

Screen 14: Wenn Fan-Out eine gelöschte Einheit versteckte

Vorsicht 4 min · Musterwahl

Wenn Fan-Out eine gelöschte Einheit versteckte

Die Spur Ein Compliance-Team baute ein Multi-Agent-System, um einen 50-Abschnitt-Lieferantenvertrag gegen eine interne Policy-Checkliste zu überprüfen. Der Orchestrator fächerte die Arbeit zu einem Subagenten pro Abschnitt auf, jeder gab ein Pass/Flag-Urteil zurück, und synthetisierte eine saubere Zusammenfassung: „48 Abschnitte überprüft, 3 gekennzeichnet. " Die Zusammenfassung las sich als vollständig und wurde an den Rechtsleiter verteilt. Zwei Abschnitte waren nie überprüft worden. Ein Subagent war abgelaufen und hatte nichts zurückgegeben; ein anderer hatte eine gescannte Seite nicht geparst und ein leeres Ergebnis zurückgegeben. Der Orchestrator, dem keine Abdeckungs-Überprüfung gegeben wurde, zählte nur die Ergebnisse, die er erhielt, und meldete „48 überprüft", aber es gab 50 Abschnitte, und niemand hatte dem Synthese-Schritt gesagt, die Anzahl zu reconciliieren.

Was brach und warum

Keine Abdeckungs-Überprüfung bei Synthese. Der Orchestrator synthetisierte über die Ergebnisse, die er zufällig erhielt, ohne Regel, dass die Anzahl der Ergebnisse der Anzahl der versendeten Einheiten entsprechen muss. Ein wiederherstellbarer Fehler wurde nie wiederhergestellt. Ein abgelaufener Subagent ist der wiederherstellbare Fall, aber nur wenn etwas ihn erneut versucht oder die Lücke kennzeichnet. Hier war der Fehler still, weil nichts die Grenze beobachtete. Selbstbewusste Synthese über unvollständige Arbeit. Die Ausgabe-Fließfähigkeit maskierte die Lücke. Ein Multi-Agent-System schlägt am gefährlichsten fehl, wenn die Zusammenfassung vollständig aussieht und nicht ist.

Warum das brach Vollständigkeit wurde angenommen, nicht überprüft. Der Orchestrator versendete 50 Einheiten und meldete über die Ergebnisse, die er erhielt. Zwei Einheiten kamen nie zurück, und nichts im Design bemerkte den Unterschied. Drei Lücken ordneten sich an, um das durchzulassen.

Die Anzahl wurde nie reconciliiert. Der Synthese-Schritt addierte die Urteile, die er erhielt, und stoppte dort. Keine Regel sagte, dass die Anzahl der Ergebnisse der Anzahl der versendeten Einheiten entsprechen muss, also wurden 48 zurückgegebene Ergebnisse zu „48 überprüft", anstatt „zwei fehlen. " Ein wiederherstellbarer Fehler hatte nichts, das ihn beobachtete. Ein abgelaufener Subagent und ein leeres Parse-Ergebnis sind beide der wiederherstellbare Fall, aber nur wenn etwas die Einheit erneut versucht oder die Lücke kennzeichnet. Keine Komponente besaß die Subagenten-Grenze, also passierten beide Fehler still. Die Ausgabe las sich als vollständig. Die Zusammenfassung war fließend und gut geformt, was genau das war, das die Lücke unsichtbar machte. Ein Multi-Agent-System schlägt am gefährlichsten fehl, wenn eine selbstbewusste Zusammenfassung über Arbeit gebaut wird, die nie beendet wurde. Die Lösung ist eine Abdeckungs-Überprüfung bei Synthese: Zurückgegebene Ergebnisse müssen gleich versendeten Einheiten sein, oder der Lauf kennzeichnet den Unterschied, bevor jemand die Zusammenfassung liest.

Screen 15: Kritisieren Sie das Orchestrierungs-Design

Checkpoint 5 min · Musterwahl

Kritisieren Sie das Orchestrierungs-Design

Entwurf-Architektur zur Überprüfung eingereicht Unten ist ein Entwurf Multi-Agent-Architektur zur Überprüfung eingereicht: ein Orchestrator, der einen großen Dokument-Klassifizierungs-Job zu Subagenten aufbläst. Sechs Komponenten sind aufgelistet. Wählen Sie die drei, die einen Kontroll- oder Fehler-Grenz-Defekt tragen.

Wählen Sie genau 3 Komponenten, die einen Kontroll- oder Fehler-Grenz-Defekt tragen.

1Orchestrator zerlegt den Korpus in Pro-Dokument-Einheiten

↓

2Subagenten laufen parallel, jeder gibt ein Urteil zurück

↓

3Synthese summiert zurückgegebene Urteile in einen Bericht

↓

4Irreversible Aktion (Auto-Archiv) mit keinem Menschliche-Gate

5Kein Wiederholungsversuch oder Gap-Flag auf einem fehlgeschlagenen Subagenten 6Gemeinsame Spur-ID an jeden Subagenten propagiert

Absenden Jetzt überspringen

Screen 16: Die Formen, die die Industrie bereits bezahlt hat, um zu lernen

Unterricht 15 min · Referenzarchitekturen

Die Formen, die die Industrie bereits bezahlt hat, um zu lernen Die Wahl eines Musters gibt Ihnen die richtige Struktur. Muster geben Ihnen die Form. Die nächste Frage zu stellen ist, wie diese Struktur mit allem um sie herum verbunden ist. Referenzarchitekturen werden Ihnen die Verdrahtung geben.

Referenzarchitekturen: was gut aussieht und wo Projekte schief gehen Referenzarchitekturen sind Referenzen, keine Blaupausen, an die man sich halten muss. Das Ziel ist nicht, ein Problem einer festen Gestaltung zuzuordnen und es wie gezeichnet zu implementieren. Jede Partner-Arbeitslast ist einzigartig, daher besteht Ihr Ziel darin, diese häufigen Muster gut genug zu verstehen, um von ihnen zu verallgemeinern. Letztendlich sollten Sie in der Lage sein, die Form zu nehmen, die passt, sie an die Arbeitslast vor Ihnen anzupassen und zu erkennen, wenn eine Arbeitslast mehr als ein Muster auf einmal zieht. Die meisten Partner-Probleme ordnen sich einem von einer Handvoll bereits bewährter Referenzarchitekturen im Claude-Ökosystem zu: dokumentierte Muster für die Verdrahtung einer LLM-Anwendung, um eine wiederkehrende Problemklasse zu lösen. Die Tabelle unten behandelt häufige Referenzarchitekturen, wie sie aussehen, wenn sie gut gebaut sind, und die Fehlermodi, die sich wiederholt zeigen.

Erweitern Sie jedes Muster, um zu sehen, was gut aussieht und wo Projekte schief gehen.

Agent (siehe S11)Was gut aussieht: Das Modell arbeitet auf ein Ziel hin, indem es entscheidet, welche Tools zu rufen sind und in welcher Reihenfolge. Autonomie wird in Schach gehalten, indem begrenzt wird, was die Tools tun können und ein Budget auf wie viele Runden das Modell bekommt. Verwenden Sie dies, wenn der Weg durch die Arbeit nicht im Voraus geschrieben werden kann: Untersuchung einer Codebasis, Ziehen aus mehreren Forschungsquellen oder Triage komplexer Kundenfälle. Wo Projekte schief gehen: Unbegrenzte Autonomie: Geben Sie dem Modell Tools, die den Status mit keiner Menschliche-Überprüfung, keinem Turn-Limit und keiner Möglichkeit, ob das Ziel erfüllt wurde, ändern. Retrieval-Augmented Generation (RAG) (siehe S11)Was gut aussieht: Ein stabiler Wissens-Korpus, wie Produkthandbücher, interne Dokumente oder regulatorischer Text, wird in Chunks aufgeteilt und indexiert. Wenn eine Frage kommt, werden die relevantesten Chunks abgerufen und an das Modell als Kontext übergeben. Wo Projekte schief gehen: Verwendung von RAG, um Fragen über Live-Status zu beantworten: Bestellstatus, Lagerbestände, Ticket-Warteschlangen. Der Index ist ein Schnappschuss. Wenn die zugrunde liegenden Daten sich seit der letzten Aktualisierung geändert haben, wird die Antwort falsch sein. Dokument-Verarbeitungs-Pipeline → Evaluator-Optimizer (siehe S11)Was gut aussieht: Strukturierte Extraktion aus semi-strukturierten Dokumenten wie Ansprüchen, Rechnungen und Verträgen. Die Pipeline handhabt OCR, extrahiert Felder gegen ein Schema, validiert die Ausgabe und leitet Ausnahmen weiter. Ein Evaluator-Optimizer ist hier häufig, weil Extraktion auf erste Durchgang bei Grenzfällen nicht zuverlässig genug ist, um ohne Überprüfung zu vertrauen. Wo Projekte schief gehen: Kein Ausnahmepfad. Niedrig-Vertrauens-Extraktionen gehen durch die gleiche Pipeline wie saubere Dokumente, mit keinem Menschliche-Gate, um die zu fangen, die das Modell falsch machte. Kundenservice / Ticket-Triage → Routing (siehe S11)Was gut aussieht: Klassifizieren Sie Absicht und was der Benutzer fragt, dann leiten Sie zum richtigen Backend: eine Wissens-Abruf-Schicht für Dokumentations-Fragen, eine transaktionale API für Live-Status-Abfragen wie Bestellstatus oder Konto-Änderungen und eine Menschliche-Genehmigungsschicht für hochfolge-Aktionen. Wo Projekte schief gehen: Verwendung von Abruf für Live-Bestellstatus, anstatt die API direkt zu rufen. Kein Eskalations-Pfad zu einem Menschen. Bereitstellung einer Agent-Variante, bevor der einfachere geroutete Workflow ordnungsgemäß gemessen wurde. Coding Agent (agentic Erkundung mit deterministischen Edit/Test/Review-Schritten) (siehe S11)Was gut aussieht: Die Arbeit teilt sich in zwei Phasen. Zuerst erforscht der Agent die Codebasis, um zu verstehen, was sich ändern muss: dieser Teil ist agentic, weil der Weg durch eine unbekannte Codebasis nicht im Voraus geschrieben werden kann. Zweitens folgen die tatsächlichen Edits deterministischen Schritten: Parse, Plan, Propose, Test, Review. Subagenten handhaben isolierte Aufgaben mit genug Kontext, um die Aufgabe zu tun, aber nicht so viel, dass die Schritte unverwaltbar werden. Wo Projekte schief gehen: Lassen Sie den Agent bearbeiten und committen, ohne eine Menschliche-Überprüfungs-Gate. Nicht Tracking-Regressions-Raten gegen einen Eval-Satz für jede Sprache oder Framework in der Codebasis. Behandlung des ganzen Dings als ein Gespräch, anstatt einer strukturierten Pipeline mit definierten Übergaben.

Vollständige RAG-Implementierungs-Tiefe, einschließlich Chunking-Strategien, Embedding-Ansätze, Hybrid-Lexical-Plus-Semantic-Abruf und Reciprocal-Rank-Fusion, wird im RAG-Pipeline-Design-Bildschirm abgedeckt, der folgt.

Wie man entscheidet, ob ein Problem ein oder mehrere Muster braucht Echte Partner-Probleme sitzen häufig an der Grenze zwischen zwei Architekturen. Ein Routing-Workflow könnte bestimmte Absichten an eine agentic-Untersuchungs-Schleife übergeben. Eine Dokument-Verarbeitungs-Pipeline könnte RAG über Policy-Text verwenden, wenn sie auf einen Ausnahmfall trifft. Das Zeichnen auf mehr als ein Muster ist manchmal die richtige Antwort. Was wichtig ist, ist, warum Sie ein zweites Muster erreichen. Denken Sie nicht an Muster als Teile, die Sie zusammenschalten. Schauen Sie sich an, warum jedes funktioniert und formen Sie die Idee, um Ihr Problem zu passen. Zeichnen Sie auf ein zweites Muster, wenn die zwei Teile Ihres Problems auf unterschiedliche Weise brechen, die es wert sind, separat verwaltet zu werden. Wenn Sie ein zweites Muster erreichen, weil Sie nicht entschieden haben, welches Problem Sie lösen, passen Sie stattdessen ein einzelnes Muster an. Das ist eine Designentscheidung, die Sie aufschieben, nicht ein Muster, das Sie anwenden.

Der häufigste Fehler: Abruf auf Live-Status angewendet Der häufigste Referenzarchitektur-Fehler ist die Verwendung von Abruf, wo ein Tool-Aufruf gehört. Sie können es durch das Aussehen nach diesen Symptomen erkennen: veraltete Chunks, Ergebnisse, die sich mit jeder Index-Aktualisierung verschieben, Antworten, die dem widersprechen, was in der Datenbank ist. Ein besseres Embedding-Modell oder ein kürzeres Aktualisierungs-Intervall wird dieses Problem nicht beheben. Stattdessen rufen Sie das System, das den Live-Status besitzt, direkt auf, anstatt eine gecachte Version davon abzurufen.

Kosten · Komplexität · Risiko Kosten: Das Zusammensetzen von zwei Referenzarchitekturen verdoppelt ungefähr die Oberfläche, die Sie verwalten müssen. Im Zweifelsfall wählen Sie eine. Komplexität: Jede Referenzarchitektur trägt ihren eigenen Eval-Vertrag. Sie brauchen separate Eval-Sätze pro Architektur, nicht einen einzelnen Eval-Satz für das zusammengesetzte System. Ein System, das auf der obersten Ebene gesund aussieht, kann Fehler in einer seiner Komponenten maskieren. Risiko: Die Fehlapplikation von Abruf auf Live-Status erzeugt veraltete, aber selbstbewusste Antworten. Das System sieht von außen gesund aus: normale Latenz, keine Fehler. Erkennungs-Kosten sind hoch, weil es kein Signal gibt, dass etwas falsch ist, bis ein Benutzer bemerkt, dass die Antwort nicht mit der Realität übereinstimmt.

Screen 17: Wenn Abruf statt eines Tool-Aufrufs erreicht wurde

Vorsicht 4 min · Referenzarchitekturen

Wenn Abruf statt eines Tool-Aufrufs erreicht wurde

Setup-Hook: wie RAG schlägt fehl, wenn auf Live-Status angewendet Die breitere zugrunde liegende Fähigkeit hier ist Kontext-Engineering: Entscheidung, welcher Mechanismus verantwortlich ist, um jede Art von Daten vor das Modell zu bringen. Abruf über einen Vektor-Index ist ein Beispiel, und diese Spur zeigt, was passiert, wenn es aufgefordert wird, Daten zu besitzen, die es nicht besitzen kann. Dies passiert oft, wenn ein Team RAG erreicht, weil es bei einem vorherigen Anwendungsfall funktioniert hat, ohne zu fragen, ob der neue die gleichen Eigenschaften teilt. RAG funktioniert gut, wenn die Antwort in einem Körper von Referenzmaterial lebt, das zwischen Index-Aktualisierungen stabil bleibt, z. B. Dokumentation, Policy-Text, Produkthandbücher. Es bricht für Live-Status, weil Abruf Ihre Daten als Text-Schnappschüsse behandelt, nicht als ein System mit aktuellen Werten. Wenn diese Schnappschüsse nicht übereinstimmen, wählt das Modell den ähnlichsten und antwortet selbstbewusst. Es gibt keine Möglichkeit zu wissen, welcher Schnappschuss aktuell ist. Die Spur unten zeigt genau, wie dies sich abspielt.

Die Spur: Elektronik-Einzelhandelskunden-Service-Assistent Benutzer fragt: „Wo ist meine Bestellung? "

ABGERUFENER CHUNK #1 (Ähnlichkeit 0,78): „Bestellung #88412 wurde am 11. Juni aufgegeben und am 12. über Standard-Kurier versendet. Tracking-Nummer AB123…" ABGERUFENER CHUNK #2 (Ähnlichkeit 0,74): „Bestellung #88412 wird derzeit verarbeitet. Erwartete Versendung innerhalb von 24 Stunden. "

MODELL-AUSGABE: „Ihre Bestellung wurde am 12. Juni über Standard-Kurier versendet. Tracking: AB123…"

Beide Chunks waren echte Strings, die zu verschiedenen Zeiten im Korpus existierten. Der Index verwirrte sie. Die Bestellung war versendet, zum Depot zurückgegeben worden, weil ein beschädigtes Etikett, und wartete auf Neuversendung. Beachten Sie, dass dieser aktuelle Status in keinem Chunk erscheint: Der Korpus hielt zwei veraltete Schnappschüsse und keine Aufzeichnung, wo die Bestellung war, weil ein Index erfasst, was wahr war, als es geschrieben wurde, nicht in der Gegenwart. Ein Kundenservice-Tool zum Abrufen von Live-Bestellstatus existierte in der API des Partners. Es wurde nicht aufgerufen.

Was brach und warum Der Kategorie-Fehler: Abruf ist der richtige Mechanismus für Wissen: FAQs, Richtlinien, Handbücher. Es ist der falsche Mechanismus für transaktionalen Status. Bestellstatus schlägt nicht fehl, weil Abruf kaputt ist. Es schlägt fehl, weil aktueller Status als historische Text-Schnappschüsse dargestellt wurde, um zu beginnen. Ein Daten-Architektur-Fehler, kein Abruf-Fehler: Live-Status wurde als Text indexiert, also suchte das System einen Korpus von vergangenen Schnappschüssen, anstatt das System der Aufzeichnung abzufragen. Ähnlichkeit ist nicht Wahrheit: Embedding-Ähnlichkeit fusionierte selbstbewusst zwei veraltete Schnappschüsse in eine Antwort. Ein höherer Ähnlichkeits-Score bedeutet nicht eine wahrere Antwort; es bedeutet, dass der abgerufene Text semantisch nah an der Abfrage war, was nicht das gleiche ist, wenn der zugrunde liegende Status sich seit dem Schreiben des Textes geändert hat. Die Lösung ist ein Tool-Aufruf: Nicht ein besserer Chunker, ein kürzeres Aktualisierungs-Intervall oder ein höherer Ähnlichkeits-Schwellenwert: ein Tool-Aufruf zum Bestellstatus-Service. Die Wissensbasis hält den FAQ-Inhalt. Die transaktionale Datenbank hält die Bestellungen. Zwei Arten von Daten, zwei Zugriffs-Muster, zwei Mechanismen.

Das Abruf-Prinzip Abruf ist für stabiles Wissen: Dinge, die gestern wahr waren und morgen wahr sein werden. Tool-Nutzung ist für Live-Status: Dinge, deren aktueller Wert von einem System besessen wird und sich unabhängig von Ihrem Index ändert. Das Vermengen von ihnen erzeugt Antworten, die fließend, selbstbewusst und falsch auf Weise sind, die schwer zu erkennen sind, weil das System kein Fehler-Signal zeigt. Das Modell gab eine Antwort zurück. Die Antwort sah korrekt aus. Der Kunde bekam falsche Informationen über ihre eigene Bestellung.

Screen 18: Kritisieren Sie das Diagramm

Checkpoint 6 min · Referenzarchitekturen

Kritisieren Sie das Diagramm Praxis: Überprüfung eines Partner-Entwurfs-Architektur Unten ist ein Referenzarchitektur-Skizze eines Kundenservice-Assistenten. Sechs Komponenten sind aufgelistet. Wählen Sie die drei, die für dieses Routing-Design falsch angewendet sind. Wählen Sie genau 3 Komponenten, die falsch angewendet sind.

1Intent-Klassifizierer (Claude-Anruf)

↓↓

2Abruf über „Bestellstatus-Index" 3Abruf über „Produkthandbuch-Korpus"

↓↓

4Agent-Schleife mit Tool-Einstiegspunkt: Rückerstattung, Stornierung, Adresse-Update 5(fehlend) Eskalations-Pfad zu Menschliche-Agent

↓↓

6Antwort-Composer (Claude-Anruf)

Absenden Jetzt überspringen

Screen 19: Chunking und Indexierung

Unterricht 10 min · RAG-Pipeline-Design

Chunking und Indexierung Der vorherige Bildschirm über Referenzarchitekturen benannte RAG als eine bekannt-gute Form und zeigte, wo es falsch angewendet wird. Dieser Bildschirm geht eine Ebene tiefer, in das Design der Abruf-Pipeline selbst: wie ein Korpus in Chunks aufgeteilt wird, wie diese Chunks indexiert werden und wie die Abruf-Strategie zu den Abfrage-Mustern abgestimmt wird, die das System sehen wird.

Chunking: wie Sie den Korpus aufteilen, nach dem, was der Korpus ist Ein Chunk ist die Einheit, die abgerufen wird. Der Chunking-Ansatz wird durch die Struktur des Quellmaterials gewählt, nicht durch eine Standard-Größe.

Chunking-AnsatzWie es funktioniert Wann es seinen Platz verdient

Feste GrößeAufteilen in einheitliche Spannweiten (mit Überlappung), unabhängig von Struktur. Homogener, unstrukturierter Text, wo natürliche Grenzen schwach sind; am einfachsten zu betreiben. SemantischAufteilen auf Bedeutungs-Grenzen, Thema-Verschiebungen, Satz-Gruppen, die zusammenhängen. Prosa, wo ein abgerufener Chunk selbst-enthalten sein muss, um gut zu antworten; reduziert Mid-Idee-Schnitte. HierarchischBewahren Sie Dokument-Struktur, Abschnitte, Unterabschnitte und rufen Sie auf der Ebene ab, die passt. Strukturierte Dokumente (Verträge, Handbücher, Richtlinien), wo Abschnitt-Kontext Bedeutung trägt.

Indexierung: wie Sie Chunks auffindbar machen, nach wie Abfragen formuliert werden Indexierung entscheidet, was „ähnlich" bedeutet, wenn eine Abfrage ankommt. Die Strategie wird durch das Abfrage-Muster gewählt.

Indexierungs-StrategieWas es abgleichtWann es seinen Platz verdient

Dicht (Embeddings)Semantische Ähnlichkeit, Bedeutung, nicht Wörter. Abfragen, die anders als die Quelle formuliert sind; Umformulierung, Absicht, Konzept-Abgleich. Dünn (Schlüsselwort, z. B. BM25)Exakte Begriffe, Identifizierer, Codes, Namen. Abfragen, die auf spezifischen Tokens hängen: Teilenummern, Statute-Zitate, Fehler-Codes. HybridBeide, mit den Ergebnissen kombiniert. Gemischte Abfrage-Muster, der häufige Produktions-Fall; erholt die exakten Abgleich-Ergebnisse, die dichte Abruf vermisst.

Wenn ein Hybrid-Index zwei rangierte Listen zurückgibt, müssen sie in eine zusammengeführt werden. Reciprocal Rank Fusion ist der Standard, niedrig-Tuning-Weg, um es zu tun: Jedes Ergebnis wird nach seinem Rang in jeder Liste bewertet, und der kombinierte Score bevorzugt Elemente, die in beiden gut rangieren. Der Punkt für einen Architekten ist, dass das Zusammenführen von dichten und dünnen Ergebnissen eine Designentscheidung mit einem bekannten, verteidigbaren Standard ist.

Die Kompromisse artikulieren Jedes Abruf-Design macht Kompromisse zwischen drei Dingen:

Abruf-Qualität: Kommt der richtige Chunk zurück? Latenz: Wie viel Latenz fügt Abruf zu jeder Anfrage hinzu? Wartung: Wie viel kostet es, die Pipeline korrekt zu halten, wenn der Korpus wächst und sich ändert?

Kleinere Chunks und Hybrid-Indexierung neigen dazu, Qualität und Latenz zusammen zu erhöhen; größere Chunks und Nur-Dicht-Indexierung senken Latenz und Wartung, aber vermissen exakte Abgleich-Abfragen. Es gibt keinen universell richtigen Punkt, nur den Punkt, der zu diesem Korpus und diesen Abfragen passt, angegeben als ein Kompromiss, den Sie verteidigen können.

Kosten · Komplexität · Risiko Kosten: Hybrid-Indexierung und kleinere Chunks erhöhen sowohl Abruf-Berechnung als auch Pro-Anfrage-Latenz. Dimensionieren Sie die Pipeline zu den Abfrage-Mustern, die Sie tatsächlich haben, nicht zu dem gründlichsten, das Sie sich vorstellen können. Komplexität: Jede Chunking- und Indexierungs-Wahl ist etwas, das Sie verwalten müssen, wenn sich der Korpus ändert. Eine Pipeline, die beim Start korrekt war, kann stillschweigend degradieren, wenn Dokumente hinzugefügt werden. Risiko: Der Fehler-Modus ist eine selbstbewusste Antwort, die auf dem falschen Chunk gebaut ist. Abruf-Qualität ist nicht in der Ausgabe sichtbar, sie muss gegen einen beschrifteten Satz gemessen werden, weshalb diese Arbeit direkt zu Evaluierung führt.

Screen 20: Entwerfen Sie die RAG-Pipeline

Übung 8 min · RAG-Pipeline-Design

Entwerfen Sie die RAG-Pipeline

Der Brief: Ein Professional-Services-Partner hat einen Korpus von ungefähr 4. 000 Dokumenten: Client-Engagement-Verträge (hochstrukturiert, Abschnitt-nummeriert), vergangene Projekt-Schreib-Ups (Langform-Prosa) und ein Methodologie-Handbuch (strukturiert, mit definierten Verfahren). Ihr Team stellt drei Arten von Fragen: „Was sagt unsere Methodologie über X? " (Konzept-Nachschlag), „Finden Sie die Klausel über Beendigung im Acme-Vertrag" (Exakt-Ziel-Nachschlag) und „Zusammenfassung, wie wir Engagements wie diesen gehandhabt haben" (breite Synthese über Schreib-Ups). Entwerfen Sie Ihre Pipeline. Für jeden der drei Dokumenttypen benennen Sie den Chunking-Ansatz, den Sie verwenden würden, und erklären Sie, warum. Dann benennen Sie die Indexierungs-Strategie für den vollständigen Korpus und geben Sie den Kompromiss an, den Sie machen. Schreiben Sie Ihre Antwort, bevor Sie klicken, um die Modell-Antwort zu offenbaren. Fühlen Sie sich frei, Claude zu fragen, um zu vergleichen, was Sie geschrieben haben, mit der bereitgestellten Antwort.

Ihr Pipeline-Design

Offenbaren Sie die Modell-Antwort Überspringen Sie jetzt

Verträge und Methodologie-Handbuch: Hierarchisches Chunking, das Abschnitt- und Unterabschnitt-Struktur bewahrt. Beide Quellen sind strukturiert und Abschnitt-nummeriert, also das Abrufen auf Abschnitt-Ebene hält die Klausel oder das Verfahren intakt und selbst-enthalten. Feste-Größe-Chunking schneidet über Abschnitt-Grenzen und verliert den strukturellen Kontext, auf den die Abfrage angewiesen ist. Projekt-Schreib-Ups: Semantisches Chunking auf Bedeutungs-Grenzen, damit jeder abgerufene Chunk selbst-enthalten ist. Langform-Prosa hat keine Abschnitt-Nummern, um hierarchisches Chunking zu verankern, und feste-Größe-Chunks schneiden Mid-Idee. Semantisches Chunking hält jede abgerufene Passage kohärent genug, um die Frage allein zu beantworten. Indexierungs-Strategie: Hybrid Dicht-Plus-Dünn. Die Abfrage-Menge mischt exakte-Klausel-Nachschläge („Finden Sie die Beendigungs-Klausel im Acme-Vertrag") mit offenen konzeptionellen Fragen („Wie haben wir X angegangen? "). Dünn handhabt exakte-Ziel-Nachschläge, wo spezifische Identifizierer wichtig sind; Dicht handhabt Konzept-Nachschlag und Synthese-Abfragen, wo Bedeutung, nicht exakte Begriffe, den Abgleich antreibt. Keiner allein deckt beide Muster ab. Der dominante Kompromiss: Abfrage-Vielfalt ist die Last-tragende Einschränkung. Der Hybrid-Index fügt Abruf-Berechnung und einen Rank-Fusion-Schritt hinzu, aber diese Kosten verdienen ihren Platz, weil die Abfrage-Menge wirklich beide Modi braucht.

Wie verglich sich Ihr Design?

Korrekt: Mein Design stimmte überein Teilweise: Nah, aber auf einem Stück falsch Falsch: Ich habe die Struktur vermisst

Screen 21: Modell, Kontextfenster und Kontextstrategie

Unterricht 13 min · Modell & Kontextstrategie

Modell, Kontextfenster und Kontextstrategie An diesem Punkt sollten Sie ein Muster und eine Referenzarchitektur haben, aber kein versandfähiges System. Drei Entscheidungen bleiben, und jede bestimmt, was die gleiche Architektur bei Produktionsvolumen kostet: 1. Welches Modell passt zur Aufgabe, 2. Wie viel des Kontextfensters tatsächlich zu verwenden und 3. Ob Ihre Kontextstrategie progressiv oder monolithisch sein sollte. Diese Entscheidungen verstärken sich über jede Anfrage bei Produktionsvolumen.

Unterschiedliche Begriffe, die leicht zu verwechseln sind Die folgenden Begriffe werden in der Praxis oft austauschbar verwendet, aber das Verwechseln von ihnen erzeugt Referenzarchitektur-Fehler. Nehmen Sie sich Zeit, um jeden Begriff im Detail sorgfältig zu überprüfen:

Kontextfenster. Der aktive Aufmerksamkeitsraum des Modells. Alles innerhalb des Kontextfensters ist verfügbar für Denken und alles außerhalb existiert nicht für das Modell. Das Kontextfenster setzt sich zwischen Aufrufen zurück, es sei denn, Ihre Anwendung verwaltet explizit die Kontinuität. Abruf. Abgerufenes externes Wissen, gezogen zur Abfrage-Zeit aus einem Korpus, den das Modell nicht im Speicher hält. Abruf erweitert das Kontextfenster; es ersetzt es nicht. Das Modell sieht nur, was der Abrufer an die Oberfläche bringt. Persistenter Anwendungs-Status. Besessen und verwaltet von Ihrem System, nicht vom Modell. Bestellstatus, Benutzer-Aufzeichnungen, Konto-Guthaben. Das Modell hat keinen inhärenten Zugriff und erfordert einen Tool-Aufruf, um es zu bekommen. Zusammenfassungen und Speicher-Schichten. Anwendungs-verwaltete Kontinuität über Runden oder Sitzungen. Das Modell hat keinen nativen Speicher zwischen Aufrufen, also bleibt alles, das bleibt, weil Ihre Anwendung es speicherte und es zurück übergab. Dies ist eine architektonische Wahl, keine Modell-Fähigkeit.

Modell-Auswahl: Beginnen Sie mit Sonnet, bewegen Sie sich absichtlich Die Claude-Modell-Familie besteht derzeit aus Opus, Sonnet und Haiku, jedes optimiert für verschiedene Kosten-, Latenz- und Fähigkeits-Kompromisse. Opus ist Anthropics fähigstes verfügbares Modell zur Nutzung, geeignet für anspruchsvolle Denk-, fortgeschrittene Codierung und Forschungs-Synthese, wo Sonnet Ihren Qualitäts-Balken nicht erfüllt. Der Standard-Startpunkt ist immer noch Sonnet. Wechseln Sie zu Opus nur, wenn ein Eval-Satz Ihnen sagt, dass Sonnet Ihren Qualitäts-Balken nicht erfüllt. Wechseln Sie zu Haiku nur, wenn ein Eval-Satz bestätigt, dass der Qualitäts-Kompromiss für Ihre spezifische Aufgabe akzeptabel ist. Ihre Entscheidung, Modelle zu wechseln, sollte immer gemessen sein, nicht reflexiv.

Kontextfenster-Dimensionierung: die Working-Memory-Klippe Alles, das das Modell beachtet, lebt im Kontextfenster. Innerhalb des Fensters ist Aufmerksamkeit verfügbar. Außerhalb davon hat das Modell keinen Zugriff. Working Memory ist die Eigenschaft mit der härtesten Kante der vier: Dinge funktionieren, bis sie nicht funktionieren, und dann ist der Übergang abrupt. Das Kontextfenster wird in Tokens gemessen. Wie viel Text ein Token abdeckt, variiert je nach Modell-Generation, Tokenizer und Sprache, also behandeln Sie jedes feste Zeichen-pro-Token-Verhältnis als eine grobe Illustration, anstatt einer Regel. Messen Sie stattdessen: Jede API-Antwort meldet tatsächliche Token-Zählungen in ihrem Nutzungs-Feld, und diese gemessenen Zählungen sind das, auf das das Kontext-Limit und die Abrechnung angewendet werden. Alles, das in das Kontextfenster eintritt, Ihre System-Eingabeaufforderung, die Gesprächs-Geschichte, abgerufene Dokumente, Tool-Ausgaben und die Antworten des Modells, wird in Tokens gezählt. Dies ist wichtig aus zwei Gründen: Das Kontextfenster hat ein festes Token-Limit und Sie werden pro Token bei jedem API-Aufruf abgerechnet. Beide Einschränkungen zeigen sich direkt in den Entscheidungen, die in diesem Abschnitt abgedeckt werden. Die praktische Implikation ist direkt: Budgetieren Sie nicht das vollständige Fenster. Budgetieren Sie für das größte realistische Gespräch, plus abgerufener Kontext, plus System-Eingabeaufforderung, plus Arbeits-Kratzer, plus Marge für Wachstum. Das Kontextfenster ist eine Decke, keine Zielmarke, also bedeutet das Entwerfen zur Decke, dass Sie sie in der Produktion treffen.

Kontextstrategie: Spektrum zwischen progressiv und monolithisch Jede Produktions-Arbeitslast trifft eine Wahl, implizit oder explizit, darüber, wie Kontext das Modell bei jedem Aufruf erreicht. Die Wahl sitzt auf einem Spektrum zwischen zwei Polen. An einem Ende platziert eine monolithische Kontextstrategie alles in die Eingabeaufforderung auf einmal: das vollständige Dokument, die vollständige Gesprächs-Geschichte, den vollständigen abgerufenen Korpus. Es funktioniert für begrenzte Aufgaben mit vorhersehbaren Eingabe-Größen. Es ist auch die Strategie, die die Working-Memory-Klippe in der Produktion trifft, weil Kontext sich über Runden hinweg akkumuliert und das Fenster stillschweigend füllt, bevor jemand bemerkt, dass etwas abgeschnitten wurde. Am anderen Ende stellt eine progressive Kontextstrategie den Kontext stattdessen in Phasen: Sie ruft Just-in-Time ab, fasst über Runden zusammen und lädt nur, was der nächste Schritt braucht. Die meisten Produktions-Arbeitslasten gehören hier hin. Zwei andere Muster sitzen zwischen den Polen und zeigen sich oft genug, um sie als Strategien zu behandeln. Die Tabelle unten legt dar, wo jede der vier Strategien ihren Platz verdient und wo sie zusammenbrechen. Erweitern Sie jede Strategie, um zu sehen, wo sie ihren Platz verdient und wo sie zusammenbrechen.

Monolithisch, laden Sie den vollständigen erforderlichen Kontext in eine einzelne EingabeaufforderungWo es seinen Platz verdient:Begrenzte Aufgaben mit vorhersehbarer Eingabe-Größe. Stabile Präfixe, die von Eingabeaufforderungs-Caching profitieren. Einzelne Schuss-Q&A, wo Abruf-Latenz nicht wert ist zu zahlen. Denken, das wirklich gleichzeitigen Zugriff auf alle Materialien erfordert. Wo es zusammenbrechen:Gespräche oder Tool-Schleifen, wo Kontext sich über Runden hinweg akkumuliert. Kosten und Latenz skalieren linear mit Eingabe-Länge. Aufmerksamkeits-Qualität kann auf sehr langen Kontexten gut vor der harten Grenze degradieren. Progressiv, tragen Sie nur das vorwärts, das der nächste Schritt brauchtWo es seinen Platz verdient:Multi-Turn-Dialog und iterative Verfeinerung. Agent-Schleifen, wo jeder Schritt hauptsächlich auf aktuellem Status abhängt. Workflows, die sich in Phasen mit engen, gut-definierten Übergaben zerlegen. Der richtige Standard für die meisten Produktions-Arbeitslasten. Wo es zusammenbrechen:Aufgaben, die lange-Reichweite-Kohärenz über die vollständige Geschichte erfordern. Entscheidungen, die auf Detail abhängen, das in einem früheren Turn gelöscht wurde. Eingabeaufforderungs-Caching ist schwieriger, wenn getragener Kontext sich bei jedem Turn mutiert. Die exakte Eingabe, die das Modell bei Schritt N sah, ist nicht mehr rekonstruierbar, was Debugging kompliziert. Abruf (RAG), rufen Sie relevante Chunks aus einem externen Speicher zur Abfrage-Zeit abWo es seinen Platz verdient:Wissensbasis zu groß, um in Kontext zu passen. Quellen, die sich schneller ändern als die Eingabeaufforderung erneut bereitgestellt wird. Domänen, wo jede einzelne Abfrage nur einen kleinen Schnitt des verfügbaren Materials braucht. Fälle, wo Quellen-Zitierung eine Anforderung ist. Wo es zusammenbrechen:Abfragen, die Synthese über viele Dokumente erfordern, die der Abrufer unabhängig bewertet. Chunking, das semantische Einheiten wie Tabellen, Code-Blöcke oder Multi-Absatz-Argumente aufteilt. Rückruf-Fehler, wo das richtige Dokument nie in die Top-K eintritt. Abruf-Qualität wird zu einem System, das Sie evaluieren und verwalten müssen. Kompression, periodisch zusammenfassen oder komprimieren Sie akkumulierten KontextWo es seinen Platz verdient:Langfristige Agenten und Gespräche, wo das vollständige Transkript verschwenderisch ist, aber aktueller Status wichtig ist. Phasen-Übergänge in Multi-Schritt-Workflows, die zu einer sauberen Zusammenfassung Checkpoint können. Sitzungen, die sonst das Kontext-Limit Mid-Task treffen würden. Wo es zusammenbrechen:Zusammenfassungen, die Last-tragende Detail fallen lassen: exakte Identifizierer, numerische Werte, frühere Entscheidungen, Grenzfälle, die einmal erwähnt wurden. Der Zusammenfasser ist selbst ein Modell-Aufruf mit Latenz, Kosten und Fehler-Modi. Kompression ist weitgehend einseitig. Das Messen von Zusammenfassungs-Treue gegen das ursprüngliche Transkript ist ein ungelöstes Evaluierungs-Problem.

In der Praxis können Strategien kombiniert werden Die vier Strategien oben werden separat für Lern-Klarheit dargestellt, aber Produktions-Systeme kombinieren fast immer sie. Jede handhabt eine andere Dimension des Kontext-Problems, also schichtet ein gut gestaltetes System sie absichtlich, anstatt eine zu wählen. Ein bearbeitetes Beispiel, Langfristige Coding-Agent:

PhaseWas passiert Strategie im Spiel

Sitzungs-StartLaden Sie die Aufgaben-Beschreibung und die wenigen Dateien, die der Benutzer explizit referenziert hatMonolithischer Präfix, Ein kleiner, stabiler Kontext, der einmal geladen wird, ideal für Eingabeaufforderungs-Caching. Aktive ArbeitJeder Tool-Aufruf (Datei lesen, Tests ausführen, bearbeiten) hängt an den Arbeits-KontextProgressive aktueller Status, Die neuesten Ergänzungen ist das, das der nächste Schritt braucht. ErkundungAgent realisiert, dass es eine Datei braucht, die es nicht geladen hat; durchsucht die Codebasis und zieht in MatchesJust-in-Time-Abruf, Der Korpus ist zu groß, um vorzuladen, und nur ein relevanter Schnitt wird bei Bedarf abgerufen. Kontext-FüllenNach vielen Runden ist frühe Erkundung Platz nehmend; die Schlussfolgerungen wichtig, aber die wörtlichen Tool-Ausgaben nichtKompression, Zusammenfasst „was wir versucht haben und was wir gelernt haben," bewahrt nur die Einsichten und Entscheidungen, die die Arbeit vorwärts tragen.

Beachten Sie, dass keine einzelne Strategie diese Arbeitslast tragen könnte. Monolithisch allein trifft das Kontext-Limit. Progressiv allein hat keine Möglichkeit, Code an die Oberfläche zu bringen, den der Agent nicht anfangs geladen hat. Abruf allein verliert den Faden von dem, was versucht wurde. Kompression allein hat nichts zu komprimieren, bis andere Strategien die Flugbahn gebaut haben. Der architektonische Takeaway: Wenn Sie ein Kontext-System entwerfen, stellen Sie sich diese separaten Fragen:

Was braucht das Modell am Start? → treibt die monolithische Grundlinie Was braucht es aus den neuesten Schritten? → treibt das progressive Fenster Was könnte es bei Bedarf abrufen müssen? → treibt die Abruf-Schicht Welches frühere Material kann komprimiert werden, ohne Last-tragende Detail zu verlieren? → treibt die Kompressions-Richtlinie

Kontextstrategie und Kontext-Dimensionierung sind separate Entscheidungen, die interagieren, aber nicht bestimmen, was der andere ist. Sie als eine zu behandeln, ist der Ort, an dem die meisten Kontext-Management-Designs schief gehen.

Was erweitertes Denken kontrolliert Erweitertes Denken ist eine Pro-Anfrage-Fähigkeit: Das Modell arbeitet durch das Problem in einem separaten Block von Denk-Tokens, bevor es die endgültige Antwort erzeugt. Wie Sie es kontrollieren, hat sich über Modell-Generationen geändert. Bei Claude Opus 4. 6 und später, Claude Sonnet 4. 6 und später und Claude Sonnet 5 ist adaptives Denken mit dem Effort-Parameter die empfohlene Kontrolle: Sie stellen ein, wie viel Denk-Anstrengung zu anwenden ist, anstatt ein Token-Budget zu konfigurieren. Adaptives Denken ist der einzige Denk-Modus bei Claude Fable 5. Das ältere manuelle Denk-Token-Budget (budget_tokens) ist bei der 4. 6-Generation veraltet und bei Claude Sonnet 5 entfernt, wo es einen 400-Fehler zurückgibt; überprüfen Sie aktuelle Modell-Unterstützung gegen platform. claude. com zur Veröffentlichungs-Zeit. Denk-Tokens werden als Ausgabe-Tokens zum Standard-Ausgabe-Satz des Modells abgerechnet und das Generieren von ihnen fügt Latenz zum Aufruf hinzu. Wenn erweitertes Denken nicht engagiert ist, werden keine dieser Tokens generiert und keine werden abgerechnet. Die Entscheidung, erweitertes Denken zu verwenden, verankert sich darin, ob ein abgerechneter Denk-Pass zu einem Aufruf hinzugefügt werden soll. Das Modell denkt intern, egal wie. Was Sie wählen, ist, ob Sie Tokens und Latenz auf einen erweiterten Pass ausgeben. Bei Modellen, die erweitertes Denken unterstützen, kann die API eine zusammengefasste Darstellung des Denk-Prozesses zurückgeben, anstatt der vollständigen Denk-Ausgabe. Sie werden für die Denk-Tokens abgerechnet, die tatsächlich während des Denkens verbraucht wurden, nicht für die Länge der sichtbaren Zusammenfassung. Sobald diese Unterscheidung klar ist, ist die Entscheidungs-Regel einfach. Erweitertes Denken ist ein Kosten- und Latenz-Kompromiss. Führen Sie Ihre Evals ohne es zuerst aus: Wenn die Genauigkeit immer noch Ihre Anforderungen nicht erfüllt, nachdem Sie an der Eingabeaufforderung selbst gearbeitet haben, dann erwägen Sie, es zu aktivieren. Mit erweitertem Denken engagiert, zahlen Sie für die Denk-Tokens und die zusätzliche Latenz bei jedem Aufruf. Der Fall für das Einschalten sollte aus einer gemessenen Genauigkeits-Lücke kommen, nicht aus der Annahme, dass es ein Modus ist, der „nicht schaden kann. " Ohne diese Evidenz, zahlen Sie die Kosten ohne Beweis, dass es Ihre Genauigkeits-Metriken bewegt.

Gate jeden Modell-Wechsel mit einem Eval, bevor Sie ihn versenden Jeder Wechsel zum Modell ist ein Wechsel zum Verhalten des Systems. Ein Swap zwischen zwei Modellen ist eine Code-Bereitstellung und sollte als solche behandelt werden. Mindestens brauchen Sie drei Dinge:

Ein kuratierter Test-Satz von Eingabeaufforderungen mit bekannt-guten Ausgaben, die die echte Verteilung der Arbeit abdeckt, die das System sieht Eine Bewertungs-Funktion (Modell-bewertet gegen eine Rubrik oder programmatisch, wo Sie die Überprüfung in Code ausdrücken können) Ein Delta-Schwellenwert, der im Voraus gesetzt wird, unter dem Sie nicht versenden. Stellen Sie den Schwellenwert vor dem Ausführen des Evals ein. Wenn Sie ihn danach einstellen, stellen Sie keinen Standard ein, Sie schreiben die Akzeptanz-Kriterien nach dem Build.

Bearbeiteter Fall: ein Sonnet-zu-Haiku-Downgrade, gut gemacht Der Fall unten zeigt die vollständige Sequenz eines Modell-Downgrades, das gegen eine echte Produktions-Einschränkung läuft. Das Muster, das Sie in Ihre eigene Arbeit tragen sollten, ist das Rollback-Kriterium: im Voraus gesetzt, geweigert zu verhandeln, wenn die Daten kamen, und verwendet, um eine teilweise Migration zu motivieren, anstatt einer vollständigen. Eine Dokument-Intelligenz-Pipeline läuft seit sechs Monaten auf Sonnet und hat ihr gesamtes Budget verwendet. Jetzt möchte das Team zu Haiku wechseln.

Das Team baut einen Eval-Satz von 250 repräsentativen Dokumenten mit Hand-validierten Extraktions-Zielen, stratifiziert über die Dokumenttypen, die in Produktions-Traffic zeigen. Die Stichprobe wird so dimensioniert, dass Pro-Dokumenttyp-Scores bedeutungsvoll bleiben, nicht nur der Gesamt-Durchschnitt. Das Team führt beide Modelle gegen den gleichen Satz aus und bewertet jede Extraktion mit der gleichen Bewertungs-Rubrik. Die Regressions-Signatur kommt zurück als: Sonnet bewertet 0,94 im Durchschnitt, Haiku bewertet 0,86 im Durchschnitt, und die Varianz konzentriert sich in zwei Dokumenttypen, wo Haiku 0,71 und 0,74 bewertet. Der Rest der Dokumenttypen kommt innerhalb der Toleranz. Das Rollback-Kriterium war im Voraus gesetzt: Wenn ein einzelner Dokumenttyp unter 0,85 fällt, wird die Migration abgelehnt. Zwei Dokumenttypen überquerten diese Linie, also wird die Migration wie vorgeschlagen abgelehnt. Der Salvage-Schritt ist, diese zwei Dokumenttypen über den bestehenden Klassifizierer zu Sonnet zu leiten und die anderen Typen zu Haiku zu leiten. Kosten fallen materiell, ohne die Regression auf den schwierigen Dokumenttypen zu nehmen.

Anstatt der spezifischen Scores sollte Ihr Takeaway aus diesem Fall auf die Fokussierung auf wie das Rollback-Kriterium vor der Daten-Ankunft entschieden wurde. Dies bedeutete, dass, wenn die Daten kamen, das Team nicht mit sich selbst verhandeln musste, und der Eval-Satz eine teilweise Migrations-Option an die Oberfläche brachte, die ein einzelner Gesamt-Score versteckt hätte.

Vorwärts-Zeiger Modell-Auswahl und Kontextstrategie sind zwei der Prompting-Bereichs-Hebel. Sie werden später in diesem Modul zwei andere Prompting-Bereichs-Hebel lernen (System-Eingabeaufforderungs-Design und Eingabeaufforderungs-Wiederverwendung).

Kosten · Komplexität · Risiko Kosten: Monolithischer Kontext ist der stille Budget-Killer. In einer Dokument-schweren Pipeline kann ein Gespräch, das mit einer 4. 000-Token-Eingabeaufforderung beginnt, 80. 000 Tokens bei Turn 30 tragen. Die Pro-Aufruf-Kosten wachsen mit dem Gespräch, und es gibt kein sichtbares Signal, bis es in der Abrechnung zeigt. Komplexität: Ein Modell-Swap sieht wie eine Ein-Zeilen-Konfiguration-Änderung aus, aber es schreibt um, wie das ganze Produkt sich verhält. Behandeln Sie Modell-Swaps als Releases. Risiko: Kein Eval-Satz bedeutet kein Rollback-Signal. Eine Regression, die in der Produktion entdeckt wird, ist eine Regression, die überhaupt nicht entdeckt wurde, weil der Benutzer bereits sie hat, wenn Sie sie sehen.

Screen 22: Wenn das Standardisieren auf Opus überall eine 7× Kosten-Überziehung erzeugte

Vorsicht 4 min · Modell & Kontextstrategie

Wenn das Standardisieren auf Opus überall eine 7× Kosten-Überziehung erzeugte

Setup-Hook Wenn die Demo landen muss und der Partner im Raum ist, ist die intelligente Antwort „verwenden Sie das beste verfügbare Modell. " Diese Antwort ist auch der Weg des geringsten Widerstands während des Builds: kein Eval-Satz erforderlich, keine Verteidigung einer Wahl. Die Rechnung kommt später, und bis dahin ist das System lange genug live, dass ein Downgrade eine zugehörige Change-Management-Kosten trägt.

90 Tage nach dem Start Symptom. Die monatlichen Kosten laufen bei sieben Mal der ursprünglichen Modellierungs-Zahl. Latenz auf dem Benutzer-sichtbaren Pfad sitzt bei 2,3 Sekunden Median, was gut über dem 800-Millisekunden-Ziel liegt, das der Partner beim Start vereinbart hat. Kundenzufriedenheits-Scores haben sich nicht im Vergleich zur Pre-Launch-Grundlinie bewegt. Ursache. Jeder Aufruf im Stack verwendet Opus. Es gibt keine Pro-Schritt-Modell-Auswahl in der Architektur, weil es keinen Pro-Schritt-Eval gab, der Pro-Schritt-Auswahl notwendig gemacht hätte. Das Team standardisierte auf „das beste verfügbare Modell" während des Builds und kam nie zurück, um die Wahl zu überprüfen, sobald Traffic live war. Beitragende Faktoren. Drei Dinge verstärkt: Das ursprüngliche Architektur-Dokument enthielt keine Modell-Tier-Entscheidung bei jedem Schritt, also trug die implizite Voreinstellung durch zur Bereitstellung. Kosten wurden monatlich überprüft, anstatt während der Entwicklung bestimmt, also tauchte die Lücke zwischen projiziert und tatsächlich nicht auf, bis Wochen nach dem Start. Erweitertes Denken war auf einem Routing-Klassifizierer aktiviert worden, der kein Denken brauchte, und diese Einstellung fügte messbare Latenz und Kosten zu jedem Anfrage hinzu, die den Klassifizierer passierte. Was das Team änderte. Das Team baute einen Eval-Satz rückwirkend, der die Arbeit abdeckte, die jeder Pipeline-Schritt tatsächlich tat. Sie leiteten den Klassifizierer-Schritt zu Haiku und bestätigten keine Regression auf dem Eval. Sie leiteten Mid-Pipeline-Zusammenfassung zu Sonnet und bestätigten keine Regression dort. Sie behielten Opus auf dem endgültigen Antwort-Kompositions-Schritt, der der Ort war, an dem der Eval sagte, dass die höhere Tier ihren Platz verdient. Monatliche Kosten fielen 71%. Latenz fiel auf 940 Millisekunden Median. Kundenzufriedenheits-Scores blieben unverändert.

Wie eine Modell-Tier-Entscheidung zu einem Budget-Gespräch wird Drei Fehler-Mechanismen verstärkt, und jeder ist im Voraus erkennbar.

Der erste: „keine Modell-Tier-Entscheidung" war selbst eine implizite Entscheidung, und das System standardisierte auf die teuerste Option. Die Abwesenheit einer absichtlichen Wahl ist nicht neutral. Der zweite: Kosten-Sichtbarkeit verzögerte den Build um Wochen. Die Rechnung kam nach dem Start, nachdem der Partner bereits live gegangen war. Das bewegte das Kosten-Gespräch aus dem Design und in das Change-Management. Der dritte: Der Eval-Satz existierte nicht während des Builds, also wenn „verwenden Sie das beste Modell" vorgeschlagen wurde, hatte das Team nichts, auf das es zeigen konnte, das eine andere Wahl begründet hätte. Der Eval-Satz ist nicht nur ein Release-Gate, es ist das einzige, das die Tier-Entscheidung verteidigbar macht, während des Design-Gesprächs.

Warum bricht das? Nicht ein Modell zu wählen, ist gleichbedeutend mit der Wahl des teuersten. Ein Eval-Satz fühlt sich wie zusätzliche Arbeit im Voraus an, aber es ist auch das einzige, das die Modell-Entscheidung verteidigbar macht.

Screen 23: Kosten- & Latenz-Rechner

Checkpoint 9 min · Modell & Kontextstrategie

Kosten- & Latenz-Rechner Verwenden Sie den Rechner, um Konfigurationen zu erforschen. Stellen Sie das Modell-Tier (Opus / Sonnet / Haiku), die Kontextstrategie (Monolithisch / Progressiv), das Anruf-Volumen pro Tag und erweitertes Denken (Ein / Aus) ein. Die Readouts zeigen Kosten und Latenz für jede Einstellung. Ihr Ziel: Finden Sie eine Konfiguration, die sowohl die Kosten-Decke als auch das Latenz-Budget zur gleichen Zeit erfüllt, die zwei können nicht gegeneinander getauscht werden. Der Rechner zeigt nur Werte an; er bewertet Ihre Erkundung nicht. Mehr als eine gültige Konfiguration existiert.

Modell-Tier OpusSonnetHaiku

Kontextstrategie MonolithischProgressiv

Anrufe pro Tag

Erweitertes Denken AusEin

Geschätzte monatliche Kosten, Median-Latenz,

Illustrative Zahlen basierend auf veröffentlichter List-Preisgestaltung ab Juni 2026 (aktuelle Pro-Million-Token-Input/Output-Preisgestaltung für Opus, Sonnet und Haiku, verfügbar bei docs. claude. com). Überprüfen Sie aktuelle Preisgestaltung und Latenz bei docs. claude. com, bevor Sie sich auf diese Zahlen mit einem Partner verlassen.

Entscheidung: Identifizieren Sie die Last-tragende Kontrolle Sobald Sie eine Konfiguration haben, wo beide Readouts innerhalb des Budgets sind, fragen Sie: Welche einzelne Einstellung, wenn entspannt, würde ein Budget zuerst brechen?

A. Das Anruf-Volumen, weil es die einzige Eingabe ist, die Sie nicht ändern können. B. Die dominante Einschränkungs-Kontrolle, zum Beispiel, wenn Latenz das enge Budget ist, das Modell-Tier oder die Erweitertes-Denken-Einstellung, die Latenz antreibt. C. Keine; jede Einstellung kann frei geändert werden, sobald beide Readouts grün sind.

Absenden Jetzt überspringen

Sobald Sie eine bestandene Konfiguration haben und die richtige Antwort oben ausgewählt haben: In 2–3 Sätzen, benennen Sie die dominante Einschränkung in Ihrer bestandenen Konfiguration und identifizieren Sie die einzelne Einstellung, die Last-tragend dafür ist. Schreiben Sie Ihre Antwort, dann offenbaren Sie die Modell-Antwort unten.

Ihre Begründung

Offenbaren Sie die Modell-Antwort Die dominante Einschränkung hängt davon ab, welches Budget enger in Ihrer Konfiguration war. Wenn Latenz die bindende Einschränkung ist, sind das Modell-Tier und die Erweitertes-Denken-Einstellung Last-tragend, das sind die Kontrollen, die Latenz am direktesten bewegen. Wenn Kosten bindend sind, sind das Tier und die Kontextstrategie Last-tragend. Die Last-tragende Kontrolle ist die, die an welches Budget die wenigste Marge gebunden ist. Sie explizit zu benennen ist das, das die Konfiguration verteidigbar macht, anstatt glücklich.

Screen 24: Entwerfen von System-Eingabeaufforderungen, Vorlagen und Schutzschienen

Unterricht 10 min · Prompting als Architektur

Entwerfen von System-Eingabeaufforderungen, Vorlagen und Schutzschienen Der Modell- und Kontext-Bildschirm behandelte die Wahl eines Modell-Tiers und einer Kontextstrategie. Der andere große Hebel in diesem Entscheidungs-Bereich ist die Eingabeaufforderung selbst. Bei Enterprise-Skala ist die Eingabeaufforderung nicht ein Satz, den Sie tippen, sondern ein Asset, das Sie entwerfen: eine System-Eingabeaufforderung, eine wiederverwendbare Vorlage und die Schutzschienen, die beide sicher und konsistent halten. Dies ist der erste von drei Bildschirmen über Prompting als architektonische Disziplin.

System-Eingabeaufforderungs-Architektur für Enterprise-Wiederverwendung Eine System-Eingabeaufforderung für ein einmaliges Chat und eine System-Eingabeaufforderung, auf die Hunderte von Anfragen pro Tag angewiesen sind, sind verschiedene Artefakte. Die Enterprise-Version ist für Wiederverwendung entworfen, was bedeutet, dass sie Struktur hat: eine klare Aussage von Rolle und Umfang, die Einschränkungen, die das Modell halten muss (was es nicht tun muss, was es immer tun muss) und einen Ausgabe-Vertrag, der die Form benennt, die die Antwort haben muss. Wenn eine System-Eingabeaufforderung bei Skala wiederverwendet wird, ist Mehrdeutigkeit ein Defekt, der über jede Anfrage multipliziert wird.

Vorlagen: Konsistenz und Sicherheit, durchgesetzt Eine Vorlage ist eine System-Eingabeaufforderung mit parametrisierten Slots (die Teile, die sich pro Anfrage ändern) und fester Gerüstung darum. Das Design-Ziel ist, dass die feste Gerüstung die Konsistenz- und Sicherheits-Garantien trägt, also dass das Füllen eines Slots nicht versehentlich eine Einschränkung entfernen kann. Eine gut gestaltete Vorlage macht den sicheren Pfad zum Standard-Pfad: Die Person, die sie verwendet, liefert den variablen Inhalt und erbt die Schutzschienen, ohne sie neu zu verfassen.

Beschreibung: die 4D-Kompetenz, auf Eingabeaufforderungs-Design angewendet Beschreibung ist eine der vier AI-Fluency-Kompetenzen, die Disziplin, dem Modell präzise zu sagen, was Sie wollen: der Umfang der Aufgabe, das Format der Ausgabe und die Einschränkungen, die es begrenzen. Auf Eingabeaufforderungs-Design angewendet, ist Beschreibung das, das eine Eingabeaufforderung trennt, die in einer Demo funktioniert, von einer, die in der Produktion hält. Eine gut beschriebene Eingabeaufforderung benennt:

Der Umfang: Was ist in und außerhalb der Grenzen Das Format: Der exakte Ausgabe-Vertrag Die Einschränkungen: Die Regeln, die nie verletzt werden dürfen

Unterspecifikation ist eine Lücke, die das Modell mit seiner eigenen Annahme füllt, unterschiedlich jedes Mal, und ist der Schlüssel-Fehler, auf den man achten muss.

Diagnose von Unterspecifikation-Lücken Die Architekt-Fähigkeit hier ist das Lesen einer Eingabeaufforderung für das, das sie nicht sagt. Wo die Eingabeaufforderung still ist, improvisiert das Modell und Improvisation ist genau der Nicht-Determinismus, den Sie nicht in einem wiederverwendeten Asset wollen. Das Diagnostizieren der Lücke bedeutet zu fragen, für jede Anforderung, die die Ausgabe erfüllen muss, ob die Eingabeaufforderung es tatsächlich angibt oder nur dafür hofft. Die Lösung ist, das Implizite explizit zu machen: die Absicht neben der Anweisung zu wiederholen, das Format zu benennen und die Einschränkungen zu begrenzen.

Kosten · Komplexität · Risiko Kosten: Eine vage System-Eingabeaufforderung wird in jeder Anfrage bezahlt, die Korrektur, Wiederholung oder menschliche Bereinigung braucht. Die Eingabeaufforderung gut zu entwerfen, einmal, ist viel billiger als das zu diagnostizieren, über Tausende von Aufrufen. Komplexität: Vorlagen konzentrieren Komplexität an einem Ort, wo sie überprüft und regiert werden kann, anstatt sie über Ad-Hoc-Eingabeaufforderungen zu zerstreuen, die niemand besitzt. Risiko: Eine unterspecifizierte Schutzschiene ist schlimmer als eine fehlende, weil sie den Anschein einer Kontrolle ohne die Substanz erzeugt. Eine Einschränkung, die das Modell stillschweigend umleiten kann, ist keine Einschränkung.

Screen 25: Eingabeaufforderungs-Engineering-Techniken über Modelle

Unterricht 7 min · Prompting als Architektur

Eingabeaufforderungs-Engineering-Techniken über Modelle Sobald eine Eingabeaufforderung für Wiederverwendung entworfen ist, ist die nächste Frage, welche Technik darin zu verwenden. Die Technik wird durch die Komplexität der Aufgabe gewählt, nicht durch Gewohnheit. Dieser Bildschirm behandelt die Haupt-Techniken, wie die Wahl sich über Modelle ändert und wie man Bias in die Eingabeaufforderung einbaut.

Technik-Auswahl nach Aufgaben-Komplexität

TechnikWas es istWann es passt

Null-ShotNur Anweisung, keine Beispiele. Gut-spezifizierte Aufgaben, die das Modell bereits zuverlässig handhabt; der Standard, um zuerst zu versuchen. Wenig-ShotEine Handvoll Input/Output-Beispiele in der Eingabeaufforderung. Aufgaben, wo das gewünschte Format oder Urteil einfacher zu zeigen als zu beschreiben ist. Kette-des-Denkens Fordern Sie das Modell auf, Schritt für Schritt zu denken, bevor Sie antworten. Multi-Schritt-Denken, Arithmetik-ähnliche Logik oder Aufgaben, wo der Weg wichtig für die Antwort ist.

Die Progression ist absichtlich: Beginnen Sie Null-Shot, fügen Sie Beispiele nur hinzu, wenn die Aufgabe sie braucht, und fügen Sie explizites Denken nur hinzu, wenn die Aufgaben-Struktur es verlangt. Jeder Schritt fügt Tokens und Latenz hinzu, also erreichen Sie nach der leichtesten Technik, die die Anforderung erfüllt.

Verhaltens-Unterschiede über Modelle Die gleiche Eingabeaufforderung verhält sich nicht identisch über Modell-Tiers oder Generationen. Ein fähigeres Modell könnte weniger Gerüstung brauchen (weniger Beispiele, weniger explizite Schritt-für-Schritt-Anweisung), um die gleiche Qualität zu erreichen, während ein weniger fähiges Modell mehr brauchen könnte. Eine Eingabeaufforderung, die für ein Modell abgestimmt ist, ist ein Startpunkt für ein anderes, nicht ein fertiges Artefakt. Dies ist, warum ein Modell-Swap als Release behandelt wird und mit einer Evaluierung gated wird: die Eingabeaufforderungs-Modell-Paarung ist das, das Sie tatsächlich versenden.

Bias in Eingabeaufforderungs-Konstruktion vermeiden Eingabeaufforderungs-Konstruktion kann Bias einführen, den die Aufgabe nie beabsichtigte. Führende Formulierung, unausgewogene Beispiele (Wenig-Shot-Sätze, die nur eine Art von Fall zeigen) und Annahmen, die in die Anweisung eingebacken sind, lenken alle die Ausgabe auf Weise, die leicht zu übersehen sind. Die Disziplin ist, neutral zu formulieren, Beispiele über die Fälle auszugleichen, die das System tatsächlich sehen wird, und zu überprüfen, ob die Eingabeaufforderung eine Antwort voraussetzt, die sie elicitieren sollte.

Checkpoint: Technik-Auswahl-Matrix Für jede Aufgabe unten, wählen Sie die Technik (Null-Shot / Wenig-Shot / Kette-des-Denkens) und geben Sie einen Ein-Satz-Grund ein. Beide sind erforderlich, bevor Sie absenden.

Aufgabe 1. Klassifizieren Sie ein Kundenservice-Ticket in eine von fünf Standard-Kategorien: Abrechnung, Technisch, Rückgaben, Konto oder Allgemein. Wählen... Null-ShotWenig-ShotKette-des-DenkensKorrekt: Null-Shot. Die Aufgabe ist gut-spezifiziert, die Kategorien sind benannt, und das Modell handhabt Klassifizierung zuverlässig ohne Beispiele. Aufgabe 2. Extrahieren Sie strukturierte Felder, Datum, Anbieter und Betrag, aus Spesen-Quittungen, die in Layout und Formatierung stark variieren. Wählen... Null-ShotWenig-ShotKette-des-DenkensKorrekt: Wenig-Shot. Das gewünschte Extraktions-Format ist einfacher, mit Beispielen zu demonstrieren als zu beschreiben, besonders angesichts Layout-Variation. Aufgabe 3. Bestimmen Sie, ob eine Multi-Schritt-Vertrags-Klausel eine Haftung unter drei Bedingungen erzeugt, die miteinander interagieren. Wählen... Null-ShotWenig-ShotKette-des-DenkensKorrekt: Kette-des-Denkens. Die Antwort hängt von einer Sequenz von bedingter Logik-Schritte ab; Prompting für Schritt-für-Schritt-Denken reduziert die Chance, eine Interaktion zu überspringen. Aufgabe 4. Zusammenfassung einer 400-Wort-Produktbeschreibung in zwei Sätze. Wählen... Null-ShotWenig-ShotKette-des-DenkensKorrekt: Null-Shot. Standard-Zusammenfassung auf einer gut-begrenzten Eingabe; das Hinzufügen von Beispielen oder expliziten Denk-Schritten fügt Tokens und Latenz hinzu, ohne Qualitäts-Gewinn.

Absenden Jetzt überspringen

Kosten · Komplexität · Risiko Kosten: Schwerere Techniken kosten Tokens und Latenz bei jedem Aufruf. Kette-des-Denkens auf einer Aufgabe, die es nicht braucht, ist eine wiederkehrende Steuer für keinen Gewinn. Komplexität: Wenig-Shot-Beispiele sind Inhalt zu verwalten: wenn sich die Aufgabe entwickelt, lenken veraltete Beispiele das Modell stillschweigend falsch. Risiko: Bias, der in die Eingabeaufforderung eingeführt wird, ist in jeder einzelnen Ausgabe unsichtbar und zeigt sich nur in Aggregat, weshalb neutrale Formulierung und ausgewogene Beispiele eine Design-Anforderung sind, nicht ein Polish-Schritt.

Screen 26: Caching-Mechaniken, modulare Eingabeaufforderungen und Fähigkeiten

Unterricht 8 min · Prompting als Architektur

Caching-Mechaniken, modulare Eingabeaufforderungen und Fähigkeiten Wiederverwendbare Eingabeaufforderungen werfen eine Frage auf, die die einmalige Eingabeaufforderung nie tut: Wie verwenden Sie sie effizient wieder, und wie verpacken Sie sie, damit ein Team sie teilen und regieren kann? Dieser Bildschirm behandelt die Mechaniken des Caching, den Unterschied zwischen einer modularen Eingabeaufforderungs-Bibliothek und einer Fähigkeit und die Entscheidung, welche zu verwenden.

Ein Cache, der nie trifft Ein Team legte ihre wiederverwendbare Analyse-Eingabeaufforderung in die Produktion und sah keine der Kosten-Einsparungen, die Caching bringen sollte. Die Ursache war Reihenfolge: Sie hatten den Pro-Anfrage-Inhalt (das Dokument, das analysiert wird) oben in der Eingabeaufforderung platziert, vor dem großen festen Anweisungs-Block. Weil der Cache auf einem stabilen Präfix abgleicht, bedeutete das Platzieren von dynamischem Inhalt zuerst, dass sich der Präfix bei jedem Aufruf änderte und der Cache nie traf. Die Lösung war, mit festem Inhalt zuerst und dynamischem Inhalt zuletzt umzuordnen.

Caching-Mechaniken, die ein Architekt um entwerfen muss Cache-Breakpoints: Caching funktioniert auf einem stabilen Präfix. Markieren Sie die Grenze zwischen dem festen Teil der Eingabeaufforderung (cachebar) und dem variablen Teil (nicht), und halten Sie den festen Teil wirklich fest. Inhalts-Reihenfolge: Statisch vor dynamisch, immer. Der große, unveränderliche Anweisungs-Block geht zuerst; der Pro-Anfrage-Inhalt geht nach dem Breakpoint. TTL-Auswahl: Gleichen Sie die Cache-Lebensdauer ab, wie oft der feste Inhalt sich tatsächlich ändert und wie häufig die Eingabeaufforderung aufgerufen wird. Eine Eingabeaufforderung, die ständig aufgerufen wird, profitiert von einem länger-lebenden Cache; eine, die selten aufgerufen wird, könnte nie die Schreib-Kosten amortisieren. Wenn die Schreib-Kosten nicht wert sind: Das Schreiben zum Cache hat seine eigenen Kosten. Wenn eine Eingabeaufforderung selten aufgerufen wird oder ihr fester Anteil klein ist, kann Caching mehr kosten als es spart. Caching ist eine Design-Entscheidung, nicht eine Voreinstellung, um überall einzuschalten.

Modulare Eingabeaufforderungs-Bibliotheken vs. Fähigkeiten als versionierte wiederverwendbare Einheiten Es gibt zwei Wege, eine Eingabeaufforderung über ein Team wiederverwendbar zu machen. Eine modulare Eingabeaufforderungs-Bibliothek ist eine gemeinsame Sammlung von Eingabeaufforderungs-Fragmenten und Vorlagen, die Ingenieure in ihrem eigenen Code zusammensetzen. Eine Fähigkeit ist eine formellere, versionierte, selbst-enthaltene Einheit: eine SKILL. md, die die Anweisungen, optionale ausführbare Skripte und Versions-Management verpackt, damit die ganze Prozedur als eine regierte Artefakt reist. Eine Fähigkeit ist das Wiederverwendungs-Primitive, das im Grundlagenabschnitt benannt wird (Verpackung einer wiederholbaren Prozedur), auf Prompting angewendet.

Die Wiederverwendungs-Entscheidung: Bibliothek oder Fähigkeit

ÜberlegungLehnen Sie sich zu einer Eingabeaufforderungs-BibliothekLehnen Sie sich zu einer Fähigkeit

WiederholbarkeitEine zusammengesetzte, oft-angepasste Eingabeaufforderung pro Nutzung. Eine stabile Prozedur, die jedes Mal auf die gleiche Weise läuft. VerteilungGeteilt innerhalb einer Codebasis oder eines Teams. Verteilt über Teams oder Produkte, die die gleiche Prozedur brauchen. GovernanceLeicht; Ingenieure besitzen die Fragmente. Braucht Versionierung, Genehmigung und Rollback, Fähigkeiten tragen das.

Kosten · Komplexität · Risiko Kosten: Caching kann Kosten materiell senken, wenn es trifft, und Kosten hinzufügen, wenn es nicht. Die Ökonomie hängt von Anruf-Häufigkeit und Präfix-Größe ab, also modellieren Sie sie, bevor Sie sich verpflichten. Komplexität: Eine Fähigkeit konzentriert eine Prozedur in eine versionierte Einheit, die überprüft und zurückgerollt werden kann; eine Ausbreitung von kopierten Eingabeaufforderungen kann nicht. Risiko: Eine unregierte Eingabeaufforderung, die über Teams kopiert wird, driftet in viele leicht verschiedene Versionen, jede mit ihrem eigenen stillschweigend verschiedenen Verhalten. Versionierte Wiederverwendung ist die Kontrolle.

Screen 27: Verfassen Sie das wiederverwendbare Eingabeaufforderungs-Asset

Übung 6 min · Prompting als Architektur

Verfassen Sie das wiederverwendbare Eingabeaufforderungs-Asset

Der Brief: Die Support-Organisation eines Partners führt die gleiche Operation Hunderte von Malen pro Tag aus: Gegeben ein Support-Ticket eines Kunden und der relevante Abschnitt des Produkthandbuchs, erzeugen Sie einen entworfenen Antwort, die den Ton-Richtlinien des Partners folgt, den Handbuch-Abschnitt zitiert, auf den sie sich verließ, und verspricht nie eine Rückerstattung oder einen Zeitplan, den der Agent nicht genehmigt hat. Entwerfen Sie das wiederverwendbare Eingabeaufforderungs-Asset. Treffen Sie die drei Design-Entscheidungen unten und schreiben Sie eine kurze Begründung für jede:

Wo endet der stabile Präfix und wo beginnt der Pro-Anfrage-Inhalt? Benennen Sie die Breakpoint-Platzierung und erklären Sie, warum. Wie erzwingen Sie die Nie-Versprechen-einer-Rückerstattung-Schutzschiene strukturell, nicht nur als eine angegebene Anweisung? Beschreiben Sie die Ausgabe-Vertrags-Einschränkung. Sollte dies als eine Vorlage oder eine Fähigkeit versendet werden? Benennen Sie die Verpackungs-Wahl und geben Sie den Grund an.

Schreiben Sie Ihre Antwort, dann offenbaren Sie die Modell-Antwort unten. Fühlen Sie sich frei, Claude zu fragen, um zu vergleichen, was Sie geschrieben haben, mit der bereitgestellten Antwort.

Ihr Eingabeaufforderungs-Asset-Design

Offenbaren Sie die Modell-Antwort

Cache-Breakpoint-Platzierung: Platzieren Sie die Rolle, Ton-Regeln, Ausgabe-Vertrag und Nie-Versprechen-Schutzschiene zuerst als den stabilen Präfix, dann das Ticket und den Handbuch-Abschnitt als den einzigen Pro-Anfrage-Inhalt. Dynamischer Inhalt vor dem Breakpoint bedeutet, dass sich der Präfix bei jedem Aufruf ändert und der Cache nie trifft. Bei Hunderten von Aufrufen pro Tag ist der stabile Präfix, wo die Kosten-Einsparungen leben. Erzwingung der Schutzschiene: Bauen Sie sie in den Ausgabe-Vertrag als eine strukturelle Einschränkung, die das Format erfordert, nicht als ein Satz in der Rollen-Text. Eine Regel, die in der Rollen-Text angegeben ist, kann driftend sein. Eine Einschränkung, die in den Ausgabe-Vertrag eingebaut ist, formt die Antwort-Format und kann nicht stillschweigend ignoriert werden. Verpackung: Eine versionierte Fähigkeit. Die Prozedur ist stabil, läuft identisch Hunderte von Malen pro Tag über die Support-Org und braucht Versionierung und Rollback. Eine geklebte Eingabeaufforderungs-Vorlage, die jeder Agent lokal hält, hat keine zentrale Governance, kann nicht zurückgerollt werden und driftet in leicht verschiedene Versionen über die Zeit.

Screen 28: Einstiegspunkt-, Weg- und Governance-Auswahl

Unterricht 11 min · Einstiegspunkte & Governance

Einstiegspunkt-, Weg- und Governance-Auswahl Sie haben das Modell und die Form gewählt, und jetzt ist es Zeit, zu wählen, wie ein Partner Claude konsumiert. Die Wahl, wie ein Partner Claude konsumiert, beinhaltet drei separate Entscheidungen, die in Reihenfolge getroffen werden. Sie in der richtigen Reihenfolge zu bekommen, verhindert die häufigsten Architektur-Fehler.

Welcher Einstiegspunkt passt zur Arbeit? Welche Build-Zeit-Schnittstelle passt zum Team? Welcher Lieferweg passt zu den Cloud-Verpflichtungen des Partners?

Die drei Ebenen (Einstiegspunkte, Build-Zeit-Schnittstellen und Lieferwege) wurden als Vokabeln im Grundlagenabschnitt gelehrt. Dieser Bildschirm ist die Auswahl-Arbeit: Wahl zwischen ihnen unter echten Einschränkungen.

Welcher Einstiegspunkt passt zur Arbeit? Ein Einstiegspunkt ist der Wrapper, der entscheidet, wer mit Claude sprechen kann, was Claude berühren kann und wie viel Engineering der Partner tun muss, um dort zu gelangen. Denken Sie an Einstiegspunkte als die gleiche Intelligenz, die für verschiedene Aufgaben verpackt ist. Die Wahl des falschen Einstiegspunkts bricht die Arbeit nicht, aber es fügt Reibung hinzu, die der Partner jeden Tag fühlen wird. Über Claude. ai und Claude Code hinaus, versendet Anthropic drei Einstiegspunkte, die Claude in spezifische Anwendungen oder Umgebungen erweitern. Bevor Sie Partner-Workflows bauen, die auf einen von ihnen angewiesen sind, überprüfen Sie die aktuellen Fähigkeiten, unterstützten Konfigurationen und Verfügbarkeit gegen Anthropic-Dokumentation. End-Benutzer-Einstiegspunkte EinstiegspunktBeschreibungAudience und UseCore-Kompromiss

Claude. ai (Web-, Mobil- und Desktop-Apps)Das End-Benutzer-Chat-Produkt. Ein angemeldeter Benutzer öffnet ein Gespräch, hängt Dateien an, verwendet Projekte für gemeinsamen Kontext und verbindet Services wie Slack, Outlook oder Google Drive über eingebaute Konnektoren. Es kommt in Consumer-Tiers (Kostenlos, Pro, Max) und in Claude für Arbeit. Claude für Arbeit hat zwei Tiers. Der Team-Tier fügt Admin-Kontrollen, SSO und SAML, Domain-Erfassung und eine vertragliche Verpflichtung hinzu, nicht auf Kundeninhalt zu trainieren. Der Enterprise-Tier fügt SCIM-Bereitstellung, konfigurierbare Aufbewahrung, Audit-Logs, eine Compliance-API und eine HIPAA-bereite Option mit einem unterzeichneten BAA hinzu. Für Wissensarbeiter, die Claude als Denk-Partner für Forschung, Entwurf, Analyse und Überprüfung verwenden. Kein Code wird geschrieben. Die Web-App, die Mobil-App und Claude Desktop erreichen alle das gleiche Claude. ai-Produkt. Dies ist der Einstiegspunkt für angewendete KI-Benutzer, nicht Erbauer. Die Consumer-Tiers passen Einzelpersonen und kleine Teams und Claude für Arbeit passt Organisationen, die Governance und Identitäts-Kontrollen auf dem gleichen Produkt brauchen. Null Build-Kosten vs. Null-Integrations-Einstiegspunkt: Sie bekommen das Produkt, das Anthropic versendet, und Sie können es nicht in ein anderes Produkt einbetten oder anpassen, was exponiert wird. Der richtige Tier hängt von Governance-Bedarf ab: Consumer-Tiers für niedrig-Empfindlichkeits-Arbeit, Claude für Arbeit, wo Admin-Kontrollen, SSO und Keine-Training-Verpflichtungen erforderlich sind. Claude Code (Terminal, IDE-Plugin, Desktop, Web)Ein agentic Coding-Tool, das Dateien liest, Code bearbeitet, Befehle ausführt und Multi-Schritt-Engineering-Aufgaben unter konfigurierbaren Berechtigungs-Grenzen ausführt. Für Ingenieure, die echte Entwicklungs-Arbeit tun: Codebasis-Erkundung, Refaktorierung über Dateien, Debugging, Feature-Bau. Das Produkt läuft in einem Terminal, in IDE-Plugins (VS Code, JetBrains, andere), auf dem Desktop und im Web bei claude. ai/code. Der gleiche Agent, wo immer Sie arbeiten. Zweck-gebaut für Engineering: Hervorragende Option für Code, aber könnte die falsche Form für ein Kundenservice-Produkt oder einen nicht-Engineering-Workflow sein. Claude Cowork: Ein Desktop-Agent für Nicht-Entwickler, der mit lokalen Dateien und Anwendungen arbeitet, Datei- und Aufgaben-Management auf dem Computer des Benutzers unter konfigurierbaren Berechtigungen automatisiert. Für Betrieb, Admin und andere nicht-Engineering-Rollen, die Claude brauchen, um Aktionen auf ihrem Computer zu ergreifen, anstatt nur Text in einem Chat-Fenster zu erzeugen. Verfügbar auf allen bezahlten Plänen (Pro, Max, Team, Enterprise) über die Claude Desktop-App auf macOS und Windows; Linux-Unterstützung ist in Beta. Echte System-Aktionen vs. Aufsichts-Overhead: Mächtig für Datei- und Aufgaben-Automatisierung, weil Cowork auf dem Computer des Benutzers direkt arbeitet, mit der Konsequenz, dass Berechtigungs-Scoping und menschliche Überprüfung wichtiger sind als in einem Chat-Only-Einstiegspunkt. Claude in Chrome: Ein Browsing-Agent, der innerhalb des Chrome-Browsers arbeitet, Seiten navigiert und Aktionen im Namen des Benutzers ergreift. Wissensarbeiter, deren Aufgaben in Web-Anwendungen verankert sind, anstatt in Dateien oder Codebasis. N/A Claude für Excel: Ein Spreadsheet-Agent, der innerhalb von Excel arbeitet, direkt mit Zellen, Formeln und strukturierten Daten arbeitet. Analysten, Finanz-Teams und jede Rolle, deren primäres Arbeits-Tool ein Spreadsheet ist. N/A

Build-Zeit-Schnittstellen: Wie Sie gegen Claude programmieren Sobald ein Einstiegspunkt gewählt ist, ist die nächste Entscheidung, welche programmatische Ebene der Code des Partners mit spricht. Die Tabelle unten beschreibt die vier Build-Zeit-Schnittstellen. Die API, SDKs, MCP und das Agent SDK sind nicht in jedem Fall Alternativen zueinander, sie schichten aufeinander. Build-Zeit-Schnittstellen Schnittstelle Definitionaudience und ZweckKompromiss

Direkte APIdie direkte HTTP-Schnittstelle zu Claude. Ein Entwickler authentifiziert, sendet eine Anfrage mit Nachrichten, einem Modell-Namen und Parametern und bekommt eine Antwort zurück. Für Teams, die Claude direkt in ihr eigenes Produkt bauen. Das Team des Partners besitzt alles: Wiederholungen, Streaming, Tool-Nutzung, Beobachtbarkeit und die UI. Es ist die grundlegendste Build-Zeit-Schnittstelle, und die Ebene, auf der alles andere sitzt. Maximale Kontrolle vs. maximale Verantwortung: Verwenden Sie dies, wenn ein SDK ein Feature nicht exponiert hat, das Sie brauchen, oder wenn das Team rohe HTTP bevorzugt. SDKs (Python, TypeScript, Java, Go, Ruby, C#, PHP)SDKs bieten die gleiche Fähigkeit wie die API, verpackt in Sprach-native Typen und Helfer, die Boilerplate reduzieren. Sie handhaben Authentifizierung, Anfrage-Formatierung, Wiederholungen, Streaming und Tool-Nutzungs-Plumbing in idiomatischem Code. Die Agent-Schleife, wenn vorhanden, ist immer noch der Code des Partners. Für Teams, die den gleichen Anwendungsfall wie die direkte API verwenden, aber das Team möchte Sprach-native Typen, weniger Boilerplate und eingebaute Ergonomie für Streaming und Tool-Nutzung. Standard-Wahl für das Einbetten von Claude in ein Produkt. Ergonomie vs. Kontrolle: SDK-Abstraktionen bewegen sich bei Anthropic-Release-Kadenz. Wenn Sie ein rohes API-Feature brauchen, das das SDK noch nicht exponiert hat, werden Sie sowieso zu HTTP zurückfallen. MCP: Ein offenes Protokoll zum Exponieren von Tools, Eingabeaufforderungen und Ressourcen von einem Server, damit jeder MCP-bewusste Client, einschließlich Claude. ai, Claude Code, die API oder ein Drittanbieter-Client, sie entdecken und verwenden kann. Nicht eine Aufruf-Konvention für Claude in einem einzelnen Produkt, sondern eine Sharing-Konvention über Produkte. Nicht eine Aufruf-Konvention für Claude in einem einzelnen Produkt, sondern eine Sharing-Konvention über Produkte. Für Teams, die die gleichen Tools von mehreren Claude-Clients erreichbar brauchen. Der gleiche Tool-Einstiegspunkt wird in zwei oder mehr Clients benötigt: Claude. ai, Claude Code, eine interne App, ein Partner-Produkt. Bauen Sie den Server einmal, verbinden Sie ihn überall. Wiederverwendbarkeit über Clients vs. zusätzliche architektonische Komplexität: Wenn nur ein Client es jemals verwenden wird, fügt MCP Overhead ohne viel Rückgabe hinzu. Agent SDK (@anthropic-ai/claude-agent-sdk)Laufen einer verwalteten Agent-Schleife, die gleiche Schleife, die Claude Code antreibt, aus dem Code des Partners selbst. Das Paket handhabt Iteration, Tool-Ausführung und Beendigung. Derzeit TypeScript (@anthropic-ai/claude-agent-sdk auf npm) und Python (claude-agent-sdk auf PyPI). Für Teams, die Claude brauchen, um über mehrere Runden innerhalb des Partners eigenem Produkt zu handeln, mit dem Partner-Anwendung, die den umgebenden Workflow kontrolliert, und die Claude Code CLI ist die falsche Form. Häufiger Fall: ein interner Agent, der in eine Web-App eingebettet ist, nicht ein Terminal-Tool. Verwaltete Schleife vs. benutzerdefinierte Orchestrierung: Das Agent SDK handhabt Iteration und Beendigung, aber der Partner gibt fein-körnige Kontrolle über die Schleife selbst auf.

Ein Weg, um diese Begriffe separat zu halten API und SDK: der gleiche Einstiegspunkt, verschiedene Ergonomie. Die API und das SDK sind der gleiche Einstiegspunkt aus Claudes Perspektive. Das SDK ist ein Wrapper mit Meinung, der über der API gestapelt ist. Es fügt Sprach-native Typen hinzu, handhabt Streaming und Tool-Nutzungs-Boilerplate und lässt das Team des Partners in ihrem bevorzugten Stack arbeiten (Python, TypeScript, Java, Go, Ruby, C# oder PHP), anstatt gegen rohe HTTP. Das SDK ist der Standard für die meisten Teams. Der einzige Grund, zu rohem HTTP zu fallen, ist, wenn ein frisch versendetes API-Feature noch nicht in das SDK gemacht hat. MCP und API-Tool-Nutzung: verschiedene Ebenen, keine Alternativen. MCP ist das Protokoll zum Teilen von Tools über Einstiegspunkte, wie ein Tool-Einstiegspunkt exponiert und über mehrere Clients entdeckt wird. API-Tool-Nutzung ist, wie Claude ein Tool innerhalb einer einzelnen Anfrage aufruft. MCP und API-Tool-Nutzung sind keine Alternativen. Unter der Haube exponiert ein MCP-Server Tools, die jeder MCP-bewusste Client mit API-Tool-Nutzung aufrufen kann. Die Wahl kommt darauf an, wie häufig Sie die Funktion wiederverwenden werden: Wählen Sie MCP, wenn ein Tool-Einstiegspunkt von mehreren Claude-Clients erreichbar sein muss; Wählen Sie rohe API-Tool-Nutzung, wenn die Tools nur in einem Produkt leben. Claude Agent SDK: Wenn ein Partner eine Agent-Schleife braucht, die sie in ihr eigenes Produkt einbetten können. Partner und Ingenieure verwenden oft „SDK", um entweder das Anthropic SDK oder das Agent SDK zu bedeuten, abhängig vom Kontext. Das Anthropic SDK ist ein Convenience-Wrapper über der API. Es handhabt Boilerplate, aber läuft keine Agent-Schleife. Das Agent SDK ist die verwaltete Laufzeit, die die Schleife läuft, die gleiche, die Claude Code antreibt. Das Modell wählt ein Tool, läuft es, sieht das Ergebnis und geht weiter, bis die Aufgabe erledigt ist oder eine Stop-Bedingung feuert. Der Partner ruft es aus ihrem eigenen Anwendungs-Code auf, und das SDK handhabt den Rest. Welche Ebene zu verwenden kommt darauf an, was Claude tun muss: eine Anfrage, eine Antwort? Verwenden Sie die API oder das SDK. Wiederverwendbare Tools über mehrere Clients? Verwenden Sie MCP. Claude, der über mehrere Runden innerhalb des Partners eigenem Produkt handelt? Verwenden Sie das Agent SDK. Die drei Ebenen arbeiten zusammen, nicht gegeneinander.

Claude Code: Anpassungs- und Governance-Ebenen Die Wahl von Claude Code ist der Start einer zweiten Entscheidung: Welche Anpassung gehört auf welche Ebene. Eine Ebene ist in diesem Kontext ein diskreter Konfiguration-Einstiegspunkt, der einen Aspekt kontrolliert, wie der Agent denkt oder handelt: jeder ist unabhängig, zusammensetzbar und auf einem anderen Punkt in der Agent-Ausführung angewendet. Die Ebenen fallen in zwei Gruppen: Form, was der Agent weiß und tut (CLAUDE. md, Fähigkeiten, Subagenten, MCP) und Regieren, was der Agent berühren darf (Hooks, Berechtigungs-Grenzen, Genehmigungsflüsse, Sandboxing und eingeschränkte Ausführung). Formungs-Ebenen und Governance-Ebenen sind unterschiedlich. Das Bekommen dieser Aufteilung richtig ist das, das einen Agent sowohl nützlich als auch sicher macht, um in der Produktion zu laufen. Claude Code-Anpassungs- und Governance-Ebenen EbeneWas es tutWann es gehört hier hin

FORMUNG: Was der Agent weiß und tut CLAUDE. mdEine Markdown-Datei, die am Sitzungs-Start in den Kontext geladen wird. Setzt stehende Anweisungen, Projekt-Konventionen und Hintergrund-Wissen, das der Agent immer haben sollte. Persistenter Kontext, der auf jede Aufgabe im Projekt angewendet wird (Coding-Standards, Repo-Layout, Team-Konventionen). Fähigkeiten: Markdown-definierte Prozeduren, die Claude Code bei Bedarf aufrufen kann, anstatt sie im Voraus zu laden, was den Haupt-Kontext schlank hält. Wiederholbare Workflows, die das Team nicht jedes Mal buchstabieren sollte. Typische Beispiele sind ein Commit-Push-PR-Fluss, ein Release-Notes-Generator, eine Schema-Migrations-Prozedur. Subagenten: Agent, der zusätzliche Agenten aufruft und erzeugt, um Abschnitte einer Aufgabe zu parsen oder isolierte Kontext-Fenster-Helfer für begrenzte Aufgaben wie Code-Überprüfung oder Codebasis-Erkundung, die sonst den Haupt-Faden verstopfen würden. Arbeit, die mit Read-Only-Tools laufen sollte, einem eingeschränkten Tool-Einstiegspunkt oder einem anderen System-Eingabeaufforderung vom Haupt-Sitzung. MCP-Server: Externe Tools und Daten-Einstiegspunkte, die zu Claude Code über das standardisierte Protokoll verbunden sind. Wenn der gleiche Tool-Einstiegspunkt über Clients wiederverwendbar sein muss, zum Beispiel wenn der Linear MCP-Server des Teams auch von Claude. ai arbeiten sollte. GOVERNANCE: Was der Agent berühren darf Hooks: Skripte, die auf Claude Code-Lebenszyklen-Ereignisse feuern (z. B. vor/nach einem Tool-Lauf, beim Sitzungs-Start, beim Stop), verwendet als deterministische Gates, die der Agent nicht überspringen kann. Deterministische Gates, die der Agent nicht überspringen darf, wo die Garantie aus Code kommen muss, anstatt aus Prompting. Berechtigungs-Grenzen und Genehmigungsflüsse: Sechs Berechtigungs-Modi kontrollieren, was Claude Code ohne Prompting tun kann. Standard fragt vor jeder Aktion. acceptEdits genehmigt Datei-Edits und häufige Filesystem-Befehle (mkdir, touch, rm, mv, cp, sed), obwohl andere Bash-Befehle immer noch prompts. Plan-Modus sperrt die Sitzung auf Read-Only, bis der Benutzer einen Plan genehmigt. Auto-Modus verwendet einen Klassifizierer, um sichere Aktionen zu genehmigen und riskante zu blockieren; es ist ein Forschungs-Preview, das auf allen Plänen funktioniert (Admin-aktiviert auf Team und Enterprise) und standardisiert auf die Anthropic API als Provider. Eine Umgebungs-Variable aktiviert CSP-Provider. dontAsk lehnt alles automatisch ab, das prompts würde und läuft nur, was Ihre Allow-Regeln abdecken, was es zum Modus für gesperrte CI macht. bypassPermissions überspringt alle Überprüfungen und ist auf Container oder CI begrenzt. Jede Umgebung, wo die Kosten einer unbeabsichtigten Aktion nicht trivial sind. Berechtigungen regieren, was der Agent berühren darf. Hooks regieren, was vor oder nach einer Aktion passieren muss. Sandboxing und eingeschränkte Ausführung: Eindämmung um den Arbeitsbereich, in dem Claude Code läuft, einschließlich Filesystem-Grenzen, Netzwerk-Egress-Regeln und eingeschränkte Befehls-Oberflächen. Jede Bereitstellung, wo eine falsche Aktion echte Konsequenzen hätte und wo Genehmigungsaufforderungen allein nicht ein ausreichender Backstop sind. Die Umgebung selbst sollte die Grenze durchsetzen, nicht nur die Agent-Urteilsfindung.

CSP-Lieferwege: Wo API-Traffic endet Sobald der Einstiegspunkt und die Build-Zeit-Schnittstelle gewählt sind, sitzt eine weitere Entscheidung darunter: Wo endet der API-Traffic? Das gleiche Claude-Modell ist über vier Lieferwege verfügbar. Was sich unterscheidet, ist welches Cloud-Konto die Ausgaben landen, welches Identitäts-System Authentifizierung handhabt, welche Region der Traffic endet und welcher Beschaffungs-Vertrag der Partner bereits unterzeichnet hat. Die Entscheidungs-Regel ist nicht über technische Fähigkeit, das Modell verhält sich auf jedem Weg gleich. Die Regel ist über das, das der Partner bereits verpflichtet hat. Wenn der Partner bereits einen langfristigen AWS-Vertrag hat, ist Bedrock normalerweise der einfachste Weg, die KI-Ausgaben fallen unter den gleichen Vertrag, den sie bereits haben, und das Identitäts-System, das ihr Team verwendet (IAM), funktioniert wie-ist. Die gleiche Logik gilt für Vertex AI auf GCP und Foundry auf Azure: Wenn der Partner in dieser Cloud lebt, verwenden Sie diesen Weg. Die direkte Anthropic API ist der richtige Anruf, wenn der Partner keine starke Cloud-Präferenz hat, neue Features in dem Moment möchte, in dem sie versendet werden, oder KI-Ausgaben direkt mit Anthropic konsolidieren möchte. Ein Kompromiss: CSP-vermittelte Wege (Bedrock, Vertex, Foundry) neigen dazu, auf neue Features um Wochen zu verzögern, manchmal länger für große Fähigkeiten. CSP-Lieferwege Lieferweg: Was es ist und wie der Partner es erreichtWann zu wählen

Anthropic First-Party: Die direkte Anthropic API bei api. anthropic. com, abgerechnet von Anthropic und authentifiziert mit einem Anthropic API-Schlüssel. SDKs in Python, TypeScript, C#, Java, Go, PHP und Ruby verpacken diesen Einstiegspunkt. Partner hat keine bindende Cloud-Verpflichtung, möchte neueste Features am Tag, an dem sie versendet werden, oder bevorzugt, KI-Ausgaben direkt mit Anthropic zu konsolidieren. Standard-Wahl, wenn keine Beschaffungs-Einschränkung die andere Richtung zieht. AWS Bedrock: Claude, der als verwaltetes Modell auf AWS dient. Aufgerufen über die Messages API bei /anthropic/v1/messages auf AWS-verwalteter Infrastruktur, abgerechnet auf dem AWS-Konto des Partners und authentifiziert über IAM. Die vorherige Bedrock Runtime-Integration (InvokeModel/Converse über boto3 oder das AWS SDK) bleibt als der dokumentierte Legacy-Weg verfügbar. Regionale Verfügbarkeit ist wichtig und Inferenz-Profile lösen das Cross-Region-Routing-Problem. Partner hat einen verpflichteten AWS-Enterprise-Vertrag, läuft den Rest ihres Stacks auf AWS und möchte, dass KI-Ausgaben gegen diesen Vertrag gezogen werden. Identität, Netzwerk und Audit erben alle vom bestehenden AWS-Konto. GCP Vertex AI: Claude, der als verwaltetes Modell in Google Cloud's Vertex AI Model Garden dient. Aufgerufen über den Anthropic Vertex-Client oder Google's SDK, abgerechnet auf dem GCP-Projekt des Partners, authentifiziert mit Google Cloud-Anmeldedaten. Modelle werden pro Projekt in der Model Garden-Konsole aktiviert. Partner läuft auf GCP, der Rest ihres ML-Stacks lebt in Vertex AI und sie möchten einen einzelnen Abrechnung- und Audit-Einstiegspunkt über Foundation-Modelle. Microsoft Foundry (Azure): Claude, der durch Microsoft's Foundry-Katalog auf Azure dient. Abgerechnet auf dem Azure-Abonnement des Partners, authentifiziert über Entra ID, bereitgestellt in die Azure-Region des Partners. Partner hat einen Microsoft-Enterprise-Vertrag, läuft Identität über Entra ID und der Rest ihres Cloud-Fußabdrucks ist auf Azure. Foundry konsolidiert KI-Beschaffung auf dem gleichen Papier. Hinweis: Foundry bietet Claude-Modelle in zwei Hosting-Formen: Gehostet auf Azure (allgemein verfügbar, Inferenz läuft in der Azure-Umgebung des Partners; ab diesem Schreiben Opus 4. 8, Sonnet 5 und Haiku 4. 5, überprüfen Sie die aktuelle Liste zur Veröffentlichungs-Zeit) und Gehostet auf Anthropic-Infrastruktur (andere Modelle, Inferenz leitet zu Anthropic-verwalteter Infrastruktur). Partner mit strikten Daten-Residenz- oder GDPR-Anforderungen sollten die Hosting-Form und Compliance-Haltung der spezifischen Modelle überprüfen, die sie bereitstellen, bevor sie sich zu diesem Weg verpflichten.

Was sich über Wege nicht ändert. Das Claude-Modell selbst ist das gleiche, unabhängig vom Weg. Prompting, Evaluierungs-Strategie, Tool-Nutzung und Kontextfenster-Verhalten übertragen alle. Was sich ändert, ist der Wrapper: Modell-Identifizierer und Versions-Strings unterscheiden sich über Wege, regionale Verfügbarkeit unterscheidet sich und CSP-seitige Funktionen, die Inferenz verpacken (wie Inferenz-Profile auf Bedrock, Modell-Bereitstellungen in Foundry und Model Garden-Zugriffs-Kontrollen in Vertex) fügen alle Konzepte hinzu, die der Architekt wissen muss, existieren, auch wenn das Ingenieur-Team des Partners die Implementierung besitzt.

Fähigkeiten als ein Integrations-Mechanismus Fähigkeiten sind ein Integrations-Mechanismus, nicht nur ein Verpackungs-Mechanismus. Eine Fähigkeit kann an eine Anfrage über den container. skills-Parameter angehängt werden, über den /v1/skills-Einstiegspunkt veröffentlicht und versioniert und unter Versions-Kontrolle wie jedes andere bereitgestellte Asset verwaltet werden. Fähigkeiten erfordern das Code-Ausführungs-Tool, um zu laufen, was bedeutet, dass das Integrations-Muster eine Abhängigkeit von einer Sandbox-Ausführungs-Umgebung trägt. Wenn die Integrations-Entscheidung ist, wie eine wiederverwendbare Prozedur Claude über Einstiegspunkte erreicht, ist eine versionierte Fähigkeit ein Mechanismus, um neben MCP und direkter Tool-Nutzung zu wiegen.

Kosten · Komplexität · Risiko Kosten: Jeder Einstiegspunkt trägt seine eigenen nicht-trivialen Integrations-Kosten. Wählen Sie nicht mehr als einen, es sei denn, der Anwendungsfall des Partners erstreckt sich über sie. Komplexität: Die zwei häufigsten Fehler sind das Erreichen von Claude Code auf nicht-Engineering-Arbeit und das Behandeln von MCP als der Standard-Integrations-Ebene, unabhängig davon, ob die Wiederverwendbarkeit, die es bietet, benötigt wird. Der Einstiegspunkt sollte der Arbeit folgen, nicht ihr vorausgehen. Risiko: Das Auswachsen des falschen Einstiegspunkts ist teuer, nicht nur wegen des Codes, der umgeschrieben werden muss, sondern wegen der Konventionen und Benutzer-Gewohnheiten, die darum gebaut wurden. Neu auf einem besseren Einstiegspunkt zu starten ist billiger als das und auf dem richtigen zu starten ist billiger.

Sicherheit, Governance und Compliance-Industrie-Einschränkungen Einige Einstiegspunkt-Entscheidungen sind nicht in Ihrer eigenen Diskretion. Wenn ein Partner Anwalt-Klient-Privileg, HIPAA, GDPR, FedRAMP oder eine interne Daten-Residenz-Richtlinie unterliegt, schließen diese Einschränkungen Einstiegspunkte ein oder aus, bevor Kosten, Ergonomie oder Build-Anstrengung in das Gespräch kommen. Claude. ai ist der Einstiegspunkt, den dies am häufigsten trifft. Das Consumer-Grade-Produkt wurde nicht entworfen, um jede Enterprise-Daten-Handhabungs-Anforderung aus der Box zu erfüllen. Die API und das SDK, geroutet durch ein Partner-genehmigtes Gateway mit Protokollierung, Aufbewahrung und Identitäts-Kontrollen in der Partner-eigenen Infrastruktur, sind die Einstiegspunkte, die die meisten regulierten Überprüfungen überstehen. Benennen Sie die Governance-Einschränkung, wenn Sie einen Einstiegspunkt empfehlen und lassen Sie die Einschränkung Optionen eliminieren, bevor Vorlieben es tun. Compliance-Industrie-Einschränkungen EinschränkungWas es neigt auszuschließenWas normalerweise Überprüfung überlebt

Anwalt-Klient-PrivilegConsumer-Tiers von Claude. ai für privilegierte Dokument-Überprüfung und alles, das privilegiertes Material über eine Oberfläche berührt, die die Firma nicht end-to-end audieren kann. Claude für Arbeit fügt Admin-Kontrollen und Audit-Protokollierung hinzu, aber eine Firma muss immer noch bestätigen, dass die Konfiguration ihre eigene Privileg-Handhabungs-Leiste erfüllt, bevor privilegiertes Material durch sie fließt. API oder SDK hinter der Firma-eigenen Anwendung, authentifiziert über SSO, geroutet durch ein Firma-genehmigtes LLM-Gateway, das jede Anfrage protokolliert. Die Firma besitzt die Audit-Spur end-to-end, was Privileg-Überprüfung sich dreht. HIPAA (PHI-Handhabung)Jeder Einstiegspunkt, wo ein Business Associate Agreement nicht für die spezifische Konfiguration, die der Partner verwendet, vorhanden ist. Ein BAA, das für eine Konfiguration existiert, erstreckt sich nicht auf eine andere, also ist ein nicht-abgedeckter Weg ausgeschlossen, auch wenn der Partner einen BAA anderswo hält. API oder SDK auf einer BAA-abgedeckten Konfiguration über den Lieferweg, den der Partner bereits verwendet. BAA-Existenz ist nicht ausreichend, weil Feature-Berechtigung wichtig ist. Beta-Features sind allgemein von BAA-Abdeckung ausgeschlossen, es sei denn, sie sind explizit als berechtigt aufgelistet. GDPR & Daten-Residenz: Lieferwege, wo die Region der Modell-Ausführung nicht gepinnt werden kann und Wege, wo Daten die genehmigte geografische Grenze bei jedem Schritt verlassen. Ein CSP-vermittelter Lieferweg (Bedrock oder Vertex) mit der Region zu einer abgedeckten Gerichtsbarkeit gepinnt und DPA-Begriffe, die vom bestehenden Cloud-Vertrag geerbt werden. Foundry ist der Weg, um hier zu überprüfen, weil seine Residenz-Garantien nicht etwas sind, das dieser Kurs bestätigen kann. Überprüfen Sie mit der Foundry-Weg-aktuellen Dokumentation, bevor Sie sich auf sie für Residenz verlassen. FedRAMP / Regierung: Jeder Weg, der nicht auf einer autorisierten Cloud-Umgebung auf der erforderlichen Impact-Ebene ist. Claude für Regierung (C4G) für FedRAMP High zivile Arbeitslasten. Bedrock GovCloud für FedRAMP High und DoD IL4/5. Vertex Assured Workloads für FedRAMP High und IL2. Hinweis: autorisierte Regierungs-Umgebungen laufen auf einem Modell-Lag, also erreichen die neuesten Claude-Modelle GovCloud und Assured Workloads nach der kommerziellen Release. Bestätigen Sie, welches Modell der Weg bietet, bevor Sie sich zu ihm verpflichten. Interne Daten-Residenz-Richtlinie: Wege außerhalb der Partner-genehmigten Cloud-Anbieter-Liste, unabhängig von der zugrunde liegenden technischen Fähigkeit. Der Lieferweg auf der Partner-genehmigten CSP. Dies ist Beschaffung, nicht Engineering: Der richtige Weg ist, welcher ihr CIO bereits freigegeben hat.

Hinweis: Überprüfen Sie immer die aktuelle Autorisierungs-Umfang für jede der Einschränkungen mit Anthropic, bevor Sie sich verpflichten.

Vorwärts-Zeiger Modul 3 (Verantwortungsvolle KI, Sicherheit und Risiko für Architekten) geht tief auf Schutzschienen-Design, Daten-Handhabung und das vollständige Compliance-Industrie-Framework. Die Rolle dieses Abschnitts ist, die Einschränkung an dem Punkt in der Design-Konversation an die Oberfläche zu bringen, wo sie Optionen eliminiert, was genau hier beim Einstiegspunkt und Lieferweg ist.

Screen 29: Wenn Claude Code außerhalb von Engineering gewählt wurde

Vorsicht 4 min · Einstiegspunkte & Governance

Wenn Claude Code außerhalb von Engineering gewählt wurde Setup-Hook: Claude Code macht einen starken ersten Eindruck. Es kann komplexe, Multi-Schritt-Engineering-Aufgaben in einem Bruchteil der Zeit ausführen, die ein Entwickler manuell verbringen würde, und diese Fähigkeit ist schwer zu vergessen. Das Risiko ist, dass dies Teams dazu führt, Claude Code standardmäßig zu erreichen, auch wenn die Arbeit es nicht erfordert und eine einfachere Integration oder Claude allein ausreichen würde. Das Diagramm unten war ein echtes Handoff von einem Partner, der uns bat, ihr Design zu validieren. Die vorgeschlagene Architektur: Regionalbank-Betriebsassistent Eine Regionalbank wollte, was sie einen „Betriebsassistenten" für ihr Filialpersonal nannten. Die Arbeit erforderte das Nachschlagen von Kundenguthaben, das Planen von Terminen und das Beantworten von Policy-Fragen. Die vorgeschlagene Architektur hatte drei Komponenten:

Claude Code, das auf Filiallaptops läuft, mit einer CLAUDE. md-Datei, die pro Filiale verwaltet wird, um lokale Konventionen zu kodieren. MCP-Server für die Kundendatenbank, das Termin-System und den Policy-Korpus, jeder über das standardisierte Protokoll exponiert. Subagenten, die Compliance-Überprüfungen bei jeder Interaktion handhaben, mit ihrem eigenen eingeschränkten Tool-Einstiegspunkt.

Die Anmerkung über das Diagramm

Claude Code auf Filiallaptops (Pro-Filiale CLAUDE. md)

Engineering-Einstiegspunkt für einen Betriebsworkflow: Filialpersonal führt keine Terminals aus; der Einstiegspunkt ist falsch abgestimmt mit dem Benutzer ↓

MCP-Server: Kundendatenbank, Termin-System, Policy-Korpus

MCP verdient seinen Platz nur, wenn über Clients wiederverwendet: Keine anderen Claude-Clients existierten in dieser Bank ↓

Subagenten führen Compliance-Überprüfungen bei jeder Interaktion aus

Compliance, die der schwächsten deterministischen Garantie zugewiesen wird: Hochfolge-Pfad sollte nicht auf Subagenten laufen

Die Anmerkung in Rot über das ganze Diagramm liest: Dies ist ein Engineering-Einstiegspunkt für einen Betriebsworkflow. Filialpersonal führt keine Terminals aus, also ist der Einstiegspunkt selbst falsch abgestimmt mit dem Benutzer. Compliance ist ein hochfolge-Pfad und sollte nicht auf Subagenten laufen, die schwächere deterministische Garantien bieten als Server-seitiger Code. Die Kundendatenbank muss nicht über MCP exponiert werden, nur weil MCP auf dem Menü für den Einstiegspunkt war; MCP verdient seinen Platz, wenn der gleiche Tool-Einstiegspunkt über Clients wiederverwendet wird, und in diesem Fall gab es keine anderen Clients in der Bank. Die Architektur, die zur Arbeit passt, ist eine benutzerdefinierte Web-Anwendung, die die API direkt aufruft. Compliance lebt in deterministischem Server-seitigen Code, wo die Garantien explizit sind, anstatt emergent. Die Benutzer-Schnittstelle ist authentifiziert über die Bank-SSO und passt zu einem Banking-Workflow, anstatt zu einem Entwickler-Workflow. Tool-Aufrufe werden an der Server-Grenze audiert. Das war die richtige Antwort von Bildschirm eins. Drei Fehler-Mechanismen, jeder sichtbar in dem ursprünglichen Vorschlag Der erste: Der Einstiegspunkt wurde gewählt, bevor der Benutzer benannt wurde. Filialpersonal braucht eine Schnittstelle, die zu einem Banking-Workflow passt, nicht ein Entwickler-Tool. Diese Einschränkung sollte den Einstiegspunkt bestimmt haben, bevor jede andere Entscheidung getroffen wurde. Der zweite: MCP wurde von einem vorherigen Projekt als Standard-Integrations-Ebene mitgenommen. Das Wiederverwendungs-Argument, das MCP rechtfertigt, galt hier nicht. Es gab keine anderen Claude-Clients in der Bank, die den gleichen Tool-Einstiegspunkt konsumieren würden. Die Protokoll-Ebene zahlte Integrations-Kosten für eine Fähigkeit, die der Partner nicht brauchte. Der dritte: Compliance, der höchste-Folge-Pfad im System, wurde dem Einstiegspunkt mit den schwächsten deterministischen Garantien zugewiesen. Das Muster war invertiert. Die Arbeit, die am meisten Code-Ebene-Sicherheit brauchte, lief auf dem Einstiegspunkt, der am weitesten davon entfernt war. Warum bricht das? : Einstiegspunkt-Wahl sollte dem Benutzer und der Arbeit folgen. Das Erreichen von Claude Code oder MCP, nur weil das letzte Projekt sie verwendete, zahlt für Fähigkeiten, die der Partner nicht braucht.

Screen 30: Wählen Sie den Einstiegspunkt und benennen Sie den entscheidenden Kompromiss

Checkpoint 7 min · Einstiegspunkte & Governance

Wählen Sie den Einstiegspunkt und benennen Sie den entscheidenden Kompromiss Für jedes Partner-Szenario, wählen Sie die Option, die sowohl den richtigen Einstiegspunkt ALS AUCH den Kompromiss benennt, der die Wahl antreibt. Ein richtiger Einstiegspunkt, der mit dem falschen Grund gepaart ist, ist nicht korrekt, die Begründung ist das, das getestet wird. Ein bearbeitetes Beispiel wird für Szenario 1 gezeigt; Sie vervollständigen Szenarien 2 bis 6.

Szenario 1, bearbeitetes Beispiel Ein nicht-Engineering-Betriebsteam braucht einen Chat-Assistenten über genehmigte interne Dokumente. Richtige Wahl: claude. ai mit einem Projekt, weil der entscheidende Kompromiss Publikum ist: ein nicht-technisches Team braucht einen vorgefertigten Einstiegspunkt, nicht eine Build-Zeit-Schnittstelle.

Szenario 2. Eine Regionalbank möchte einen Loan-Officer-Assistenten bereitstellen, der Kundenkonto-Daten aus einem Core-Banking-System abruft und Entwurf-Loan-Zusammenfassungen erzeugt. Die Bank läuft auf AWS und hat einen bestehenden Enterprise-Vertrag.

A. AWS Bedrock, weil der entscheidende Kompromiss Integrations-Tiefe ist: Der Assistent braucht programmatischen Zugriff auf Core-Banking-Daten und muss in die bestehende AWS-Infrastruktur der Bank eingebettet werden. B. claude. ai Enterprise, weil der entscheidende Kompromiss Integrations-Tiefe ist: Die Bank braucht ein regiertes Produkt mit SSO und Audit-Kontrollen. C. Direkte API, weil der entscheidende Kompromiss Integrations-Tiefe ist: Die direkte API gibt die meiste Kontrolle darüber, wie Anfragen gebaut werden.

Szenario 3. Eine Anwaltskanzlei möchte Claude verwenden, um Anwälte bei der Überprüfung privilegierter Dokumente zu unterstützen. Der General Counsel der Kanzlei hat bestimmt, dass alle KI-Tools, die privilegiertes Material berühren, hinter der eigenen Audit-Infrastruktur der Kanzlei laufen müssen.

A. claude. ai Enterprise, weil der entscheidende Kompromiss Governance/Kontrolle ist: Enterprise fügt SSO, Audit-Protokollierung und Admin-Kontrollen hinzu. B. Direkte API oder SDK hinter der Kanzlei-eigenen Anwendung und dem Gateway, weil der entscheidende Kompromiss Governance/Kontrolle ist: Die Kanzlei muss die Audit-Spur end-to-end besitzen, was Routing durch Infrastruktur erfordert, die die Kanzlei kontrolliert. C. AWS Bedrock, weil der entscheidende Kompromiss regulatorische Residenz ist: Bedrock bietet regionale Daten-Handhabung, die Privileg-Anforderungen erfüllt.

Szenario 4. Ein globales Logistik-Unternehmen möchte Lagerhaus-Betriebspersonal einen Claude-Assistenten für Schicht-Übergabe-Notizen und Ausrüstungs-Checklisten-Vervollständigung geben. Das Personal ist nicht-technisch und arbeitet von gemeinsamen Tablets auf dem Boden.

A. Direkte API mit einer benutzerdefinierten Schnittstelle, weil der entscheidende Kompromiss Integrations-Tiefe ist: Ein benutzerdefinierter Build gibt vollständige Kontrolle über die Erfahrung. B. claude. ai mit einem Projekt, weil der entscheidende Kompromiss Publikum ist: Nicht-technisches Personal braucht eine vorgefertigte Schnittstelle, die sie ohne Training verwenden können, und Projekte bieten den gemeinsamen Kontext, den das Team braucht. C. Claude Code, weil der entscheidende Kompromiss Publikum ist: Claude Code läuft auf Tablets und gibt Personal direkten Zugriff auf Claudes Fähigkeiten.

Szenario 5. Ein Gesundheitsnetzwerk muss einen klinischen Dokumentations-Assistenten bereitstellen, der Patienten-Aufzeichnungen verarbeitet. Das Netzwerk hält einen BAA mit AWS und hat bestätigt, dass Bedrock unter diesem Vertrag abgedeckt ist. Ein konkurrierender Vorschlag schlägt vor, die direkte Anthropic API mit einem separat verhandelten BAA zu verwenden.

A. AWS Bedrock, weil der entscheidende Kompromiss regulatorische Residenz ist: Bedrock pinnt Daten zu einer US-Region, die HIPAA erfüllt. B. Direkte Anthropic API mit einem separat verhandelten BAA, weil der entscheidende Kompromiss Governance/Kontrolle ist: Die direkte API gibt mehr Kontrolle darüber, wie PHI durch das System fließt. C. AWS Bedrock, weil der entscheidende Kompromiss Governance/Kontrolle ist: Der bestehende BAA des Netzwerks deckt diese Konfiguration ab, was das Compliance-Risiko eliminiert, bevor andere Kompromisse gelten. D. claude. ai Enterprise mit einem BAA, weil der entscheidende Kompromiss Governance/Kontrolle ist: Enterprise fügt HIPAA-bereite Konfiguration und Audit-Kontrollen hinzu.

Szenario 6. Ein Finanzdienstleistungs-Unternehmen baut ein Hochfrequenz-Handels-Kommentar-System. Das System muss eine kurze Natur-Sprache-Zusammenfassung jedes Handels innerhalb von 400 Millisekunden nach Ausführung erzeugen. Das Unternehmen läuft auf GCP.

A. Google Vertex AI, weil der entscheidende Kompromiss Latenz ist: Die 400ms-Anforderung verlangt den niedrig-Latenz-Weg, und Vertex AI hält den Anfrage-Weg innerhalb der bestehenden Google Cloud-Umgebung des Unternehmens, was Netzwerk-Roundtrip minimiert. B. Direkte Anthropic API, weil der entscheidende Kompromiss Latenz ist: Die direkte API hat die schnellsten Feature-Releases und niedrigsten Overhead. C. AWS Bedrock, weil der entscheidende Kompromiss Latenz ist: Bedrocks verwaltete Infrastruktur ist für niedrig-Latenz-Inferenz optimiert.

Absenden Jetzt überspringen

Screen 31: Ein Vertrags-Überprüfungs-System für eine Mid-Market-Anwaltskanzlei

Checkpoint 7 min · Zusammenbau & Recap

Ein Vertrags-Überprüfungs-System für eine Mid-Market-Anwaltskanzlei Vier vollständige Architekturen werden unten beschrieben. Jede verpflichtet sich zu allen fünf Design-Entscheidungen, die das Modul behandelte: der Plattform-Einstiegspunkt, das Muster, wie die Arbeit über Claude, bestehende Systeme und Menschen aufgeteilt wird, die Modell- und Kontextstrategie und die Menschliche-in-der-Schleife-Haltung. Nur eine hält gegen den Brief. Die anderen drei sehen jeweils vernünftig aus, schlagen aber auf einer einzelnen Entscheidung fehl. Wählen Sie die, die Sie vor ein Partner-seitiges Überprüfungs-Komitee stellen würden.

Der Brief Eine 180-Anwalt Mid-Market-Anwaltskanzlei möchte die Vertrags-Überprüfung beschleunigen. Senior Associates verbringen derzeit geschätzte 12 bis 18 Stunden pro Woche damit, Anbieter- und Partnerschafts-Verträge zu lesen, um Klauseln zu kennzeichnen, die mit dem Standard-Playbook der Kanzlei in Konflikt stehen. Durchschnittliche Vertrags-Länge ist 35 Seiten. Die aktuelle Ausgabe ist ein rot-markiertes PDF mit Rand-Kommentaren. Die Kanzlei verwendet iManage für Dokument-Speicherung, hat ein privates LLM-Gateway, das von ihrem CIO genehmigt wurde, und ist durch Anwalt-Klient-Privileg gebunden, das Consumer-Grade-Tools ausschließt. Das Ziel ist, die Associate-Zeit pro Vertrag um 60% zu reduzieren, während der Senior Associate als endgültiger Reviewer bleibt.

Schritt 1: Entwerfen Sie Ihre Architektur Bevor Sie die vier Optionen lesen, entwerfen Sie Ihre eigene Architektur für die Anwaltskanzlei. In einem Absatz, behandeln Sie alle fünf Entscheidungen: der Plattform-Einstiegspunkt, das Muster, wie die Arbeit über Claude und bestehende Systeme aufgeteilt wird, die Modell- und Kontextstrategie und die Menschliche-in-der-Schleife-Haltung. Klicken Sie zum Offenbaren einer Antwort, um mit Ihrer Antwort zu vergleichen; fühlen Sie sich frei, Claude zu fragen, um zu vergleichen, was Sie geschrieben haben, mit der bereitgestellten Antwort.

Ihre Architektur

Offenbaren Sie die Modell-Antwort Bauen Sie auf der direkten API oder dem SDK auf, eingebettet in eine dünne interne Web-App, die über die Kanzlei-SSO authentifiziert und durch das genehmigte LLM-Gateway geroutet wird. Ein parallelisierter Workflow überprüft den Vertrag Abschnitt für Abschnitt, mit einem Evaluator-Pass, der ein striktes Schema auf der gekennzeichneten-Klauseln-Ausgabe durchsetzt. Claude handhabt Extraktion, Klassifizierung gegen das Playbook und Entwurf-Redlines. Das Playbook bleibt in den Kanzlei-Systemen als eine versionierte Quelle der Wahrheit, abgerufen pro Klausel zur Anruf-Zeit. iManage handhabt Dokument-Abruf. Sonnet ist der Standard mit progressivem Kontext, erweitertes Denken aktiviert pro Klausel nur, wo ein Eval-Satz es rechtfertigt. Der Senior Associate unterschreibt jede Ausgabe, und niedrig-Vertrauens-Klauseln werden für Aufmerksamkeit gekennzeichnet.

Schritt 2: Welche der vier Optionen stimmt am meisten mit Ihrem Design überein?

Option A. Bauen Sie auf Claude. ai auf, mit Associates, die jeden Vertrag in ein Projekt hochladen, das das Playbook als Referenz-Dateien hält. Ein parallelisierter Workflow überprüft den Vertrag Abschnitt für Abschnitt und aggregiert die gekennzeichneten Klauseln. Sonnet ist der Standard mit progressivem Kontext. Der Senior Associate überprüft jede Ausgabe, bevor etwas zu einem Client geht. Option B. Bauen Sie auf der direkten API oder dem SDK auf, eingebettet in eine dünne interne Web-App, die über die Kanzlei-SSO authentifiziert und durch das genehmigte Gateway geroutet wird. Das Playbook wird in die System-Eingabeaufforderung in voller Länge bei jedem Aufruf geladen, damit das Modell den Kanzlei-Standard immer im Kontext hat. Ein parallelisierter Workflow überprüft den Vertrag nach Abschnitt und aggregiert Ergebnisse. Sonnet ist der Standard. Der Senior Associate überprüft jede Ausgabe. Option C. Bauen Sie auf der direkten API oder dem SDK auf, eingebettet in eine dünne interne Web-App hinter SSO und dem genehmigten Gateway. Ein offener Agent wird dem Vertrag und den iManage-Tools gegeben und bleibt sich selbst überlassen, um zu entscheiden, wie er das Dokument durcharbeitet. Das Playbook wird pro Klausel zur Anruf-Zeit abgerufen. Opus läuft bei jedem Aufruf für maximale Genauigkeit. Der Senior Associate überprüft jede Ausgabe. Option D. Bauen Sie auf der direkten API oder dem SDK auf, eingebettet in eine dünne interne Web-App, die über die Kanzlei-SSO authentifiziert und durch das genehmigte Gateway geroutet wird. Ein parallelisierter Workflow überprüft den Vertrag Abschnitt für Abschnitt, mit einem Evaluator-Pass, der ein striktes Schema auf der gekennzeichneten-Klauseln-Ausgabe durchsetzt. Claude handhabt Extraktion, Klassifizierung gegen das Playbook und Entwurf-Redlines. Das Playbook bleibt in den Kanzlei-Systemen als eine versionierte Quelle der Wahrheit, abgerufen pro Klausel zur Anruf-Zeit. iManage handhabt Dokument-Abruf. Sonnet ist der Standard mit progressivem Kontext, erweitertes Denken aktiviert pro Klausel nur, wo ein Eval-Satz es rechtfertigt. Der Senior Associate unterschreibt jede Ausgabe, und niedrig-Vertrauens-Klauseln werden für Aufmerksamkeit gekennzeichnet.

Absenden Jetzt überspringen

Screen 32: Glossar

Referenz·Zusammenbau & Recap Glossar Die Schlüssel-Begriffe, die über dieses Modul verwendet werden, in alphabetischer Reihenfolge. Klicken Sie auf einen Begriff, um seine Definition zu erweitern.

Adaptives Denken: Erweitertes Denken, wo das Modell selbst, anstatt Sie, entscheidet, ob zu denken und wie viel, basierend auf der Komplexität jeder Anfrage. Es kann bei Länge auf einem schwierigen Problem denken und Denken ganz auf einem trivialen überspringen. Sie lenken es mit einem Anstrengung-Niveau, anstatt ein Token-Budget zu konfigurieren. Bei aktuellen Claude-Modellen ist es die empfohlene Kontrolle, und bei den neuesten Modellen ist es die einzige. API: Application Programming Interface. Der direkte Weg, Anfragen an Claude von Ihrem eigenen Code zu senden, mit vollständiger Kontrolle über die Eingabeaufforderung, das Modell, die Parameter und wie die Antwort handhabt wird. Die Verwendung der API bedeutet, dass Sie die umgebende Anwendung selbst bauen: die Benutzer-Schnittstelle, die Gesprächs-Geschichte, die Fehler-Handhabung, die Protokollierung. Der Kompromiss ist maximale Flexibilität im Austausch für das Besitzen der Infrastruktur darum. Autoritativ: Autoritativ bedeutet die Quelle, die Sie vereinbart haben, als korrekt zu behandeln: das System der Aufzeichnung des Partners, die Live-Policy-Tabelle, die aktuelle Preisliste. Wenn eine Antwort autoritativ ist, kommt sie aus dieser vertrauten Quelle, anstatt aus der Modell-Erinnerung, also können Sie dahinter stehen. Claude Agent SDK: Eine verwaltete Agent-Laufzeit, die als das @anthropic-ai/claude-agent-sdk-Paket für TypeScript und Python verteilt wird. Es gibt einem Partner programmatischen Zugriff auf die gleiche Agent-Schleife, die Claude Code antreibt: Iteration, Tool-Ausführung, Beobachtung, Beendigung, also kann der Partner einen Agent in sein eigenes Produkt einbetten, anstatt Claude Code in einem Terminal auszuführen. Unterschiedlich vom Anthropic SDK, das ein dünner Convenience-Wrapper über der API ist und keine Agent-Schleife läuft. Claude Code: Ein agentic Coding-Tool, das Dateien liest, Code bearbeitet, Befehle ausführt und Multi-Schritt-Engineering-Aufgaben unter konfigurierbaren Berechtigungs-Grenzen ausführt. Verteilt als CLI, IDE-Plugins (VS Code, JetBrains und andere), eine Desktop-Anwendung und ein Web-Produkt bei claude. ai/code. Claude Code ist der Einstiegspunkt, den Ingenieure verwenden, um echte Entwicklungs-Arbeit zu tun, und es ist anpassbar über CLAUDE. md, Fähigkeiten, Subagenten, Hooks, MCP-Server und Berechtigungs-Einstellungen. Claude. ai: Das End-Benutzer-Chat-Produkt, das von Anthropic gehostet wird. Erreicht über die Web-, die Mobil-Apps und Claude Desktop. Benutzer melden sich an, öffnen Gespräche, laden Dateien hoch, teilen Kontext über Projekte und verbinden externe Services über eingebaute Konnektoren. Kein Code wird geschrieben. Claude. ai ist der Einstiegspunkt für Benutzer, nicht Erbauer, weshalb das Ingenieur-Team eines Partners normalerweise nicht Claude. ai konsumiert, wenn Claude in ihr eigenes Produkt einbettet. Korpus: Der Körper von Dokumenten, den ein Abruf-System durchsucht. Ein Korpus könnte eine Wissensbasis, ein Satz von Policy-Dokumenten, ein Produkthandbuch oder eine Sammlung von vergangenen Tickets sein. Der Korpus wird im Voraus geladen und indexiert, weshalb er für stabiles Referenzmaterial funktioniert und nicht für Live-Status. CSP-Lieferweg: Cloud Service Provider-Lieferweg: Der Weg, den API-Traffic nimmt, um Claude zu erreichen. Anthropic bietet einen direkten Weg bei api. anthropic. com an, und die gleichen Claude-Modelle sind auch über AWS Bedrock, GCP Vertex AI und Microsoft Foundry auf Azure verfügbar. Der Weg, den Sie wählen, bestimmt, wo die Ausgaben abgerechnet werden, wie der Aufruf authentifiziert wird, welche Region der Traffic endet und welcher Vertrag es abdeckt. Es beeinflusst nicht, wie sich das Modell verhält. Deterministische Regel: Eine deterministische Regel ist eine Regel, die immer die gleiche Ausgabe für die gleiche Eingabe erzeugt. Gleich rein, gleich raus, jedes Mal, mit keiner Variation. Eval: Eval kurz für Evaluierungen ist ein strukturierter Test-Satz, der verwendet wird, um zu messen, ob ein Modell gut genug auf einer definierten Aufgabe funktioniert. Ein Eval paart Eingaben mit erwarteten Ausgaben oder Qualitäts-Kriterien, läuft sie gegen das Modell und erzeugt einen Score, den Sie über Modell-Versionen, Eingabeaufforderungen oder Konfigurationen vergleichen können. Evals sind, wie Teams entscheiden, ob eine Änderung eine Verbesserung oder eine Regression ist, bevor sie die Produktion erreicht. Erweitertes Denken: Die Fähigkeit, wo das Modell durch ein Problem in einem separaten Block von Denk-Tokens arbeitet, bevor es sich zu einer endgültigen Antwort verpflichtet, anstatt in einem Pass zu antworten. Es hilft bei Aufgaben, wo eine Ein-Schuss-Antwort Schritte überspringen würde. Denk-Tokens werden als Ausgabe-Tokens abgerechnet und fügen Latenz hinzu. Wie viel Denken passiert, hängt vom Kontroll-Modus ab: ein Denk-Token-Budget, das Sie selbst auf älteren Modellen konfigurieren, oder adaptives Denken (siehe Adaptives Denken) auf aktuellen. IDE: Integrated Development Environment. Eine Software-Anwendung, die einen Code-Editor, Debugger und andere Tools in einem Ort zum Schreiben und Ausführen von Code bündelt (z. B. VS Code, PyCharm, Xcode). Live-Status: Daten, die sich während der Lebensdauer eines Gesprächs oder Prozesses ändern: ein Bestellstatus, ein Lagerbestands-Zähler, ein Preis, ein Kalender-Slot, eine Benutzer-aktuelle Sitzung. Live-Status ist unterschiedlich von statischem Referenzmaterial, weil die richtige Antwort um 10:00 Uhr um 10:05 falsch sein könnte. Systeme, die Live-Status brauchen, erfordern einen direkten Nachschlag gegen die Quelle der Wahrheit, nicht einen gespeicherten Schnappschuss. MCP: Model Context Protocol. Ein offener Standard, der Claude ermöglicht, sich über einen dedizierten Server mit externen Tools und Datenquellen zu verbinden, anstatt zu erfordern, dass Sie eine benutzerdefinierte Integration für jeden schreiben. Ein MCP-Server exponiert Tools, Eingabeaufforderungen und Ressourcen, die jeder MCP-kompatible Client verwenden kann, was bedeutet, dass eine einzelne Integration, die einmal geschrieben wird, über Anwendungen wiederverwendet werden kann. MCP verschiebt die Arbeit des Bauens und Verwaltens von Tool-Definitionen weg von Ihrem Anwendungs-Code und in wiederverwendbare Server. Monolithisch: Das Gegenteil von progressiv: Alles, das das Modell möglicherweise braucht, wird im Voraus in einen Block geladen. Monolithischer Kontext ist einfacher zu einrichten und gut für kurze, enthaltene Aufgaben, aber er wächst über die Zeit, drückt gegen das Kontextfenster und zwingt das Modell, Material zu beachten, das möglicherweise nicht relevant für den aktuellen Schritt ist. Langfristige Bereitstellungen, die monolithisch gebaut sind, neigen dazu, zu degradieren, wenn sich das Gespräch akkumuliert. Beobachtbarkeit: Fähigkeit zu sehen, was Ihr System tut, rekonstruieren, warum es sich auf eine bestimmte Weise verhielt und erkennen, wenn etwas schief geht. Parametrische Kenntnis: Parametrische Kenntnis bedeutet, was das Modell während des Trainings gelernt hat und in seinen Gewichten trägt (seine Parameter). Es ist das Modell, das aus Speicher antwortet, mit keinem außen Nachschlag. Das Gegenteil ist Kenntnis, die das Modell im Moment der Anfrage zieht, wie ein Dokument, das Sie ihm geben oder ein Web-Such-Ergebnis. Progressiv: Ein Ansatz, wo Kontext, Anweisungen oder Fähigkeiten in Phasen geladen werden, wenn die Arbeit sie erfordert, anstatt alle auf einmal am Start. Progressiver Kontext gibt dem Modell nur, was es bei jedem Schritt braucht, was die Arbeits-Menge fokussiert hält und die Kosten jedes Aufrufs niedriger. Das Muster zeigt sich in Fähigkeiten, die Referenz-Dateien bei Bedarf laden und in Agenten, die Informationen durch Tool-Aufrufe sammeln, anstatt alles in der anfänglichen Eingabeaufforderung zu erhalten. Eingabeaufforderungs-Caching: Eingabeaufforderungs-Caching ist eine Funktion, die Ihnen ermöglicht, häufig verwendete Teile einer Eingabeaufforderung zu speichern, typischerweise eine lange System-Eingabeaufforderung oder ein großes Dokument, also das Modell muss sie nicht von Grund auf bei jedem Aufruf neu verarbeiten. Der gecachte Anteil wird einmal berechnet und über mehrere Aufrufe wiederverwendet. Abruf: Abrufen von relevanten Informationen aus einer außen Quelle im Moment der Anfrage und Übergabe an das Modell neben der Frage. Anstatt sich auf das zu verlassen, das das Modell während des Trainings gelernt hat, ziehen Sie das aktuelle Dokument, die Aufzeichnung oder den Durchgang und legen ihn vor das Modell, damit die Antwort in dieser Quelle verankert ist. SDK: Software Development Kit. Eine Sprach-spezifische Bibliothek (Python, TypeScript und andere), die die API in idiomatischem Code für diese Sprache verpackt. Das SDK handhabt Anfrage-Formatierung, Authentifizierung, Wiederholungen und Antwort-Parsing, also können Sie Claude mit ein paar Zeilen Code aufrufen, anstatt HTTP-Anfragen von Hand zu konstruieren. Das SDK ist auf der API gebaut, also kann alles, das die API tun kann, das SDK tun, mit weniger Boilerplate. Wenn ein Ingenieur „SDK" sagt, könnten sie dieses Anthropic SDK (ein Wrapper über der API) oder das Claude Agent SDK (eine verwaltete Agent-Laufzeit) bedeuten; jedoch sind dies zwei verschiedene Dinge. Versendbar: Bereit für Produktions-Nutzung, nicht nur ein funktionierender Demo. Versendbare Ausgabe erfüllt den Balken für Genauigkeit, Latenz, Kosten und Zuverlässigkeit, die die Bereitstellung tatsächlich erfordert, und sie hat die Evals und Überprüfungs-Gates bestanden, die das Team verwendet, um Änderungen freizugeben. Die Unterscheidung ist wichtig, weil ein Prototype, der den Happy-Path handhabt, nicht das gleiche ist wie ein System, das den langen Schwanz von echten Benutzer-Eingaben handhabt. Terminal: Eine Text-basierte Schnittstelle für die Interaktion mit dem Betriebssystem Ihres Computers durch das Tippen von Befehlen. Auch genannt eine Befehlszeile oder Shell (z. B. Terminal auf Mac, Command Prompt auf Windows). Tool-Nutzung: Die Fähigkeit, die Claude ermöglicht, externe Funktionen, APIs oder Services während einer Antwort aufzurufen, anstatt nur Text zu erzeugen. Das Modell entscheidet, wann ein Tool aufzurufen ist, welche Argumente zu übergeben sind und wie das Ergebnis in seinem nächsten Schritt zu verwenden ist. Tool-Nutzung ist das, das Claude von einem Text-Generator in ein System verwandelt, das Dateien lesen, Datenbanken abfragen, das Web durchsuchen oder Aktion in anderer Software ergreifen kann. Wrapper: Code, der ein anderes Stück Code, eine Bibliothek oder eine API umgibt oder kapselt, um es einfacher zu verwenden, Funktionalität hinzuzufügen oder zwischen Schnittstellen zu übersetzen. Zum Beispiel, ein Python-Wrapper um eine C-Bibliothek lässt Sie C-Funktionen aufrufen, als wären sie native Python.

Screen 33: Schlüssel-Takeaways

Recap 3 min · Zusammenbau & Recap

Schlüssel-Takeaways

01

Zerlegung ist die Bewegung, die vor Architektur kommt. Bevor Sie ein Muster wählen können, müssen Sie die Arbeit in drei Eimer aufteilen: was Claude handhabt, was Ihre bestehenden Systeme handhabt und was Menschen handhabt. Die Aufteilung wird von wie das Modell sich auf jedem Stück der Arbeit verhält angetrieben, was Ihnen sagt, ob eine Aufgabe überhaupt mit Claude gehört oder irgendwo anders im Stack. Designs, die diesen Schritt überspringen, enden damit, Claude in Arbeit zu zwingen, die ein anderes System bei niedrigeren Kosten tun würde oder es zu fragen, ohne den Kontext zu arbeiten, den ein Mensch einem Kollegen gegeben hätte.

02

Die Wahl eines Musters ist die Wahl, wie viel Autonomie zu gewähren. Das erweiterte LLM, der Workflow und der Agent sind Punkte auf einem Spektrum von „Claude hilft einem Schritt" zu „Claude plant die ganze Sequenz", mit vier Workflow-Unter-Mustern darunter. Die Entscheidung hängt von fünf Faktoren ab: Vorhersehbarkeit (wie vorhersehbar die Aufgabe ist), Fehler-Kosten (wie teuer eine falsche Antwort wäre), Beobachtbarkeit (wie sichtbar die Arbeit ist, während sie läuft), Latenz (wie lange Sie warten können) und Kosten (wie viel Sie pro Lauf ausgeben können). Wenn Fehler-Kosten die bindende Einschränkung sind, wählt Fehler-Kosten das Muster. Die engste Einschränkung ist der Faktor, der entscheidet.

03

Erreichen Sie die getesteten Referenzarchitekturen, bevor Sie Ihre eigene erfinden. Die fünf Referenzarchitekturen: Agent, RAG, Dokument-Verarbeitungs-Pipeline (Evaluator-Optimizer), Routing und Coding Agent sind dokumentiert, weil andere Teams bereits gelernt haben, was in jedem bricht. Kombinieren Sie sie, wenn verschiedene Teile Ihres Systems auf verschiedene Weise brechen und wählen Sie eine, wenn Sie immer noch unsicher sind, was das System handhaben muss. Der häufigste Fehler ist die Verwendung von Abruf als Ersatz für Live-Status. Abruf ist für statische Dokumente und veraltete Schnappschüsse gebaut, also verwenden Sie sie nicht während eines Gesprächs, das Live-Daten braucht.

04

Modell-Auswahl: Beginnen Sie mit Sonnet und behandeln Sie jeden Swap als Release. Sonnet ist der Standard-Tier, weil er Intelligenz, Geschwindigkeit und Kosten für die meisten Produktions-Arbeitslasten ausgleicht. Das Wechseln zu Opus oder Haiku ist eine absichtliche Entscheidung, die das gleiche Gate braucht, das jede andere Release bekommt: ein Eval-Satz, der definiert, was „besser" bedeutet und ein Rollback-Kriterium, das vor dem Swap gesetzt wird, nicht danach. Das gleiche Prinzip gilt für Kontext. Progressiver Kontext, wo das Modell nur das erhält, das es bei jedem Schritt braucht, hält sich besser über eine langfristige Bereitstellung als monolithischer Kontext, der alles im Voraus lädt und wächst, bis es bricht.

05

Wählen Sie den Einstiegspunkt nach der Arbeit, die er tun muss, nicht nach dem, das bereits auf dem Regal ist. Claude. ai, die direkte API, das SDK, Claude Code und MCP tragen jeweils einen anderen Kern-Kompromiss: Geschwindigkeit des Setups gegen Tiefe der Kontrolle, vorgefertigte UI gegen benutzerdefinierte Integration, Breite von Tools gegen Fokus. Die richtige Empfehlung ist die, wo Sie den Kompromiss laut bei der Zeit benennen können, die Sie ihn machen. Den Kompromiss laut zu benennen, wenn Sie den Einstiegspunkt empfehlen, ist das, das Ihnen später sagt, wann zu wechseln.

Quellen

Anthropic Skilljar, Claude 101: Modell-Familie (Opus, Sonnet, Haiku), Claude. ai und API-Einstiegspunkte. Anthropic Skilljar, Claude Code 101 In Action: Claude Code-Anpassungs-Stack, CLAUDE. md, Subagenten, MCP, Fähigkeiten. Anthropic Skilljar, AI Fluency Foundations: Das Vier-Eigenschaften-Framework, Next-Token Prediction, Knowledge, Working Memory, Steerability. Anthropic Skilljar, Building with the Claude API: RAG, Chunking, Hybrid-Abruf, Tool-Nutzung, Erweitertes Denken, Evaluierung.

Screen 34: Glückwunsch! Sie haben dieses Modul erfolgreich abgeschlossen.

Modul Abgeschlossen · Architekt · 2 min Glückwunsch! Sie haben dieses Modul erfolgreich abgeschlossen. Modul 1 etabliert die Plattform-Entscheidungen, auf die jede nachgelagerte Architekt-Wahl angewiesen ist. Sie haben durch Modell-Auswahl, Eingabeaufforderungs-Architektur, Tool-Design und die Kompromisse, die jede Ebene mit dem Geschäftsfall verbinden, gearbeitet. Die Entscheidungen, die Sie auf der Plattform-Ebene treffen, setzen die Decke für alles, das darüber gebaut wird.

0 von 0 Checkpoints bestanden

M1

Claude-Plattform & Lösungsdesign Modell-Auswahl, Eingabeaufforderungs-Architektur, Tool-Design und Plattform-Ebene-Kompromisse.

Sie sind hier

M2

Enterprise-Integration & Produktion Bereitstellungs-Muster, Integrations-Architektur und Produktions-Zuverlässigkeit.

Nächstes

M3

Verantwortungsvolle KI, Sicherheit & Risiko Sicherheits-Frameworks, Risiko-Identifizierung und Governance-Praktiken.

M4

Stakeholder-Engagement, Lebenszyklusmanagement & Go-to-Market Stakeholder-Kommunikation, Lebenszyklusmanagement und Go-to-Market-Strategie.

M5

Team-Befähigung und Betriebliche Produktivität Team-Werkzeug-Konfiguration und Betriebliche Unterstützungs-Praktiken.

Modul überprüfen Neu starten