--- title: "Prüfung von Prompts und Harness vor dem Wechsel zu Claude Opus 5" locale: de category: how_to category_name: "Anleitungen" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/claude-opus-5-verification-and-migration-guide published_at: 2026-07-28T11:42:11+09:00 --- # Prüfung von Prompts und Harness vor dem Wechsel zu Claude Opus 5 > Hier wird erläutert, wie sich die in den bereitgestellten Unterlagen behaupteten Eigenschaften von Claude Opus 5 von überprüfbaren Informationen unterscheiden lassen und wie Prompts, Harness und Evaluationssysteme bei der Einführung einer neuen Modellgeneration neu gestaltet werden sollten. Verfügbarkeit, Preise und Modellbezeichnungen müssen stets anhand der offiziellen Modellliste und Preistabelle von Anthropic geprüft werden. ## Key Points - Die in den bereitgestellten Unterlagen genannten Veröffentlichungstermine, Preise und Leistungswerte von Claude Opus 5, Fable 5 und Sonnet 5 sollten vor der Nutzung unabhängig anhand offizieller Quellen geprüft werden. - Bei einem neuen Modell sollten bestehende Prompts nicht einfach kopiert werden; Qualität, Kosten und Latenz müssen mit realen Arbeitsdaten neu gemessen werden. - Redundante Prüfanweisungen und unbegrenzte Aufrufe von subagents können Kosten und Ausführungszeit erhöhen, ohne die Ergebnisse zu verbessern. - Wenn Systemanweisungen, Projektregeln, bei Bedarf geladene Skills und technische Referenzen getrennt werden, lässt sich der Kontext leichter verwalten. - Eigene Evaluationen, die die tatsächlichen Aufgaben und Fehlerkosten der Organisation berücksichtigen, bieten eine direktere Grundlage für die Modellauswahl als Benchmark-Ranglisten. Die bereitgestellten Unterlagen stellen Claude Opus 5 als ein auf alltägliche Enterprise- und Agentenaufgaben zugeschnittenes Modell vor und vertreten die Auffassung, dass bestehende Prompts und Harnesses für die neue Claude-Generation neu gestaltet werden müssen. Allerdings konnten die in den Unterlagen genannten **Veröffentlichungstermine, Preise und Leistungsdaten von Claude Opus 5, Fable 5 und Sonnet 5 sowie die Aussagen von Partnern anhand der in diesem Artikel bereitgestellten Informationen nicht unabhängig verifiziert werden.** Insbesondere sollte zunächst in der offiziellen Modellliste geprüft werden, ob `Fable` tatsächlich eine offizielle Modellbezeichnung von Anthropic ist. Daher wiederholt dieses Dokument diese Veröffentlichungsinformationen nicht als bestätigte Tatsachen, sondern unterscheidet zwischen Punkten, die anhand offizieller Dokumente überprüft werden müssen, und Prüfverfahren, die sich auf einen tatsächlichen Modellwechsel anwenden lassen. ## Zunächst zu prüfende Veröffentlichungsinformationen Bevor ein neues Modell in die API, die Claude-App oder Claude Code integriert wird, sollten die folgenden Punkte mit der offiziellen Dokumentation von Anthropic und der Modellauswahl des verwendeten Dienstes abgeglichen werden. | Prüfpunkt | Behauptung der bereitgestellten Unterlagen | Erforderliche Prüfung | |---|---|---| | Modellbezeichnungen | Claude Opus 5, Fable 5, Sonnet 5 | Genaue Produktnamen und Modell-IDs in der offiziellen Modellliste | | Veröffentlichungstermine | Jeweils 9. Juni, 30. Juni und 24. Juli | Jahr und Datum in der offiziellen Ankündigung und im Änderungsverlauf | | Preis von Opus 5 | 5 Dollar für Eingaben, 25 Dollar für Ausgaben/1 Million Token | Offizielle API-Preisliste sowie separate Gebühren für Batch-Verarbeitung, Caching und lange Kontexte | | Standardmodell im Produkt | Neues Standardmodell von Claude Max | Verfügbarkeit nach Region, Tarif und Client | | Rollen der Modelle | Unterteilung in langfristige autonome Aufgaben, alltägliche Aufgaben und ressourcenschonende Aufgaben | Offizielle Modellbeschreibungen und Ergebnisse aus der Bewertung realer Arbeitsaufgaben | | Leistungsverbesserungen | Verbesserungen um bestimmte Prozentsätze gegenüber früheren Modellen | Bewertungsaufgaben, Stichprobengröße, Messkriterien und Originalaussagen der Partner | Wenn Modellbezeichnungen oder Preise nicht in der offiziellen Dokumentation zu finden sind, dürfen sie nicht für API-Konfigurationen oder Budgetberechnungen verwendet werden. Bei der Nutzung eines Cloud-Anbieters oder Wiederverkäufers können sich Modell-ID, Preis und Bereitstellungszeitpunkt zudem von der direkten API von Anthropic unterscheiden. ## Entscheidungskriterien, die sich beim Modellwechsel ändern müssen ### 1. Effizienz pro Aufgabe statt Spitzenleistung messen Wenn jede Anfrage mit dem teuersten Modell bearbeitet wird, können die Kosten schnell steigen, sobald ein Agent wiederholt mehrere Tools und subagent aufruft. Ein Modell sollte nicht anhand seines Namens oder seiner Kategorie ausgewählt werden, sondern anhand der folgenden Kennzahlen in ihrer Gesamtheit. - **Erfolgsquote:** Anteil der Fälle, in denen die Anforderungen ohne menschliche Korrekturen erfüllt wurden - **Gesamtkosten:** Kosten einschließlich erneuter Versuche sowie Tool- und subagent-Aufrufe, nicht nur der ersten Anfrage - **Bearbeitungszeit:** Zeit einschließlich Wartezeiten sowie menschlicher Prüf- und Korrekturzeit - **Fehlerkosten:** Auswirkungen eines Fehlers, etwa Sicherheitslücken, fehlerhafte Bereitstellungen oder unvollständige Analysen - **Konsistenz:** Ausmaß, in dem die Ergebnisse bei wiederholter Bearbeitung derselben Aufgabenart schwanken Die Kosten pro Aufgabe dürfen nicht allein anhand des Tokenpreises beurteilt werden. Konzeptionell lassen sie sich wie folgt berechnen. `Gesamtkosten pro Aufgabe = Kosten des Hauptmodells + subagent-Kosten + Toolkosten + Kosten erneuter Versuche + menschliche Prüfkosten` ### 2. Öffentliche Benchmarks und eigene Bewertungen trennen Öffentliche Benchmarks sind ein Ausgangspunkt für den Vergleich allgemeiner Modelleigenschaften, garantieren aber keinen Erfolg bei einer bestimmten Codebasis, Dokumentvorlage oder Geschäftsregel. Organisationen sollten aus anonymisierten realen Aufgaben eigene Bewertungssets erstellen. Ein gutes Bewertungsset umfasst gemeinsam die folgenden Fälle. - Repräsentative Aufgaben, die regulär abgeschlossen werden müssen - Grenzfälle, bei denen das Modell häufig Fehler macht - Aufgaben mit unklaren Anforderungen, bei denen Rückfragen erforderlich sind - Aufgaben, die Toolaufrufe oder die Prüfung externer Quellen erfordern - Hochriskante Aufgaben, bei denen die Ausführung abgebrochen oder eine menschliche Genehmigung eingeholt werden muss - Aufgaben, bei denen während einer langen Ausführung der Zustand gespeichert und wiederhergestellt werden muss Ein Vergleich ist nur möglich, wenn auf jedes Modell dieselben Eingaben, Tools, Zeitlimits und Erfolgskriterien angewandt werden. Statt ein oder zwei beeindruckender Ergebnisse ist es sicherer, die Erfolgsquote und Kostenverteilung über mehrere Wiederholungen hinweg zu erfassen. ### 3. Modell und Harness als ein System bewerten Ein **Harness** bezeichnet die Ausführungsumgebung rund um das Modell. Dazu gehören System-Prompts, Projektanweisungen, Suche, Speicher, Tools, Skill, subagent, Berechtigungsverwaltung sowie Prüf- und Wiederholungslogik. Auch dasselbe Modell kann je nach Harness unterschiedliche Ergebnisse liefern. Wenn das Modell beispielsweise selbst Tests erstellt und ausführt und der Harness dieselbe Prüfung ebenfalls erzwingt, kann dieselbe Arbeit doppelt ausgeführt werden. Umgekehrt ist es riskant, auch Schritte, die deterministische Kontrollen erfordern, etwa Bereitstellungsfreigaben oder Sicherheitsprüfungen, dem autonomen Urteil des Modells zu überlassen. Das zentrale Prinzip besteht darin, **zwischen Schlussfolgerungen, die das Modell gut beherrscht, und Kontrollen, die das System zwingend gewährleisten muss, zu unterscheiden**. ## 6 Punkte zur Prüfung von Prompts und Harnesses ### 1. Doppelte Prüf- und Kontrollanweisungen versuchsweise entfernen Es ist nicht grundsätzlich richtig, Sätze wie `Nach Abschluss unbedingt erneut prüfen` ausnahmslos zu löschen. Zunächst muss nachvollzogen werden, ob sich die Prüfungen, die das neue Modell eigenständig ausführt, mit den Prüfschritten des Harness überschneiden. - Wenn sich die Selbstprüfung des Modells lediglich wiederholt, ohne die Qualität zu verbessern, sollte der Prompt gekürzt werden. - Automatisierbare Prüfungen wie Tests, Schemavalidierung und statische Analyse sollten im Harness verbleiben. - Genehmigungen für Hochrisikoaufgaben wie Zahlungen, Bereitstellungen und Datenlöschungen dürfen nicht durch die Selbstprüfung des Modells ersetzt werden. ### 2. Aufrufbedingungen und Obergrenzen für subagent festlegen subagent sind für parallele Recherchen oder die Aufteilung nach Fachgebieten nützlich. Werden jedoch selbst kleine Aufgaben delegiert, steigen Kosten und Latenz. Dafür können Richtlinien wie die folgenden festgelegt werden. - subagent nur für Aufgaben verwenden, die sich unabhängig voneinander aufteilen lassen. - Die Anzahl gleichzeitig ausführbarer subagent pro Anfrage begrenzen. - Jedem subagent ein klares Arbeitsergebnis und eindeutige Abbruchbedingungen vorgeben. - Verhindern, dass mehrere Agenten dieselben Quellen redundant durchsuchen. - Eine menschliche Genehmigung einholen, wenn die erwarteten Kosten oder der erwartete Zeitaufwand einen Schwellenwert überschreiten. ### 3. Detaillierte Verbote durch Entscheidungskriterien ersetzen Lange Verbotslisten können sich widersprechen oder neue Situationen nicht abdecken. In Bereichen mit geringem Risiko, etwa beim Stil, kann dem Modell überlassen werden, den umgebenden Kontext zu lesen und selbst zu entscheiden. - Regelbasiert: `Schreibe niemals docstrings mit mehreren Absätzen.` - Delegierte Entscheidung: `Halte dich an die Kommentardichte, das docstring-Format, die Benennung und die Konventionen des vorhandenen Codes.` Regeln mit hohen Verstoßkosten, etwa zum Umgang mit personenbezogenen Daten, zur Sicherheit oder zu gesetzlichen Pflichten, müssen jedoch als explizite Einschränkungen und programmatische Prüfungen beibehalten werden. ### 4. Antwortlänge und Ausgabeformat direkt vorgeben Die für Schlussfolgerungen eingesetzten Ressourcen und die Länge der für den Benutzer sichtbaren Antwort sind nicht dasselbe. Selbst wenn der Client `effort` oder eine ähnliche Option für die Schlussfolgerungsintensität anbietet, müssen für kurze Antworten separate Ausgabevorgaben formuliert werden. Beispiele: - `Nenne zuerst die Schlussfolgerung und fasse die Begründung in höchstens drei Punkten zusammen.` - `Die endgültige Antwort darf höchstens 500 Zeichen umfassen.` - `Gib ohne Erläuterung ausschließlich ein gültiges JSON-Objekt zurück.` - `Berichte nur über geänderte Dateien, die wichtigsten Gründe und verbleibende Risiken.` ### 5. Schlussfolgerungsintensität anhand realer Aufgaben neu kalibrieren Die beim vorherigen Modell verwendete Schlussfolgerungsintensität oder der Standardwert für effort darf nicht unverändert auf das neue Modell übertragen werden. Die Kostenkurve sollte gemessen werden, indem mit einer niedrigen Einstellung begonnen und diese nur bei unzureichender Qualität erhöht wird. | Aufgabentyp | Richtung der Anfangseinstellung | Bedingung für eine Erhöhung | |---|---|---| | Klassifizierung und Formatkonvertierung | Niedrig beginnen | Wenn Schemafehler oder Auslassungen wiederholt auftreten | | Allgemeine Dokument- und Codeänderungen | Mittleren Bereich vergleichen | Wenn Abhängigkeiten zwischen mehreren Dateien übersehen werden | | Komplexes Debugging | Mittlere oder höhere Einstellung testen | Wenn Ursachenanalyse und Prüfungserfolgsquote unzureichend sind | | Langfristige Agentenaufgaben | Schrittweise messen | In schwierigen Abschnitten, die Neuplanung oder Wiederherstellung erfordern | Da die genaue Bezeichnung der Optionen und ihr Unterstützungsumfang je nach API-Version und Produkt variieren können, muss die offizielle Dokumentation geprüft werden. ### 6. Kontext nach Rollen aufteilen und schrittweise offenlegen Wenn sämtliche Anweisungen in einem einzigen System-Prompt oder einer einzigen `CLAUDE.md` untergebracht werden, können bei jeder Anfrage auch irrelevante Informationen übermittelt werden. Praktisch ist eine Hierarchie wie die folgende. 1. **System- und Produktanweisungen:** Stets erforderliche Regeln wie Rolle, Sicherheitsgrenzen und Ausgabevertrag 2. **Kompakte Projektanweisungen:** Build-Befehle, Verzeichnisstruktur und gemeinsame Arbeitsweisen 3. **Bei Bedarf geladener Skill:** Bedingte Verfahren für Bereitstellungen, Datenbankänderungen, bestimmte Frameworks und Ähnliches 4. **Technische Referenzen:** API-Schemata, Codebeispiele, Designdokumente und prüfbare Spezifikationen Dies kann als **schrittweise Offenlegung** bezeichnet werden. Das Modell soll die in der jeweiligen Phase benötigten Unterlagen suchen oder laden. Um Reproduzierbarkeit und Auditierbarkeit sicherzustellen, muss jedoch protokolliert werden, welche Unterlagen verwendet wurden. ## Empfohlenes Migrationsverfahren ### Schritt 1: Aktuellen Zustand fixieren Prompts, Toolversionen, Erfolgsquoten, Tokenverbrauch, Latenzen und Fehlerfälle des bisherigen Modells werden gespeichert. Ohne Ausgangsbasis lässt sich nur schwer beurteilen, ob das neue Modell tatsächlich eine Verbesserung darstellt. ### Schritt 2: Modellinformationen und Berechtigungen prüfen Die offizielle Modell-ID, den Preis, das Kontextlimit, die Toolunterstützung und die Richtlinie zur Datenspeicherung prüfen. In der Testumgebung werden Berechtigungen zum Schreiben, Löschen und Bereitstellen eingeschränkt. ### Schritt 3: Bestehenden Harness unverändert testen Zu Beginn sollte nicht alles auf einmal geändert werden. Wird nur das Modell ausgetauscht und mit der Ausgangsbasis verglichen, lässt sich die Auswirkung der Modelländerung isolieren. ### Schritt 4: Doppelte Anweisungen einzeln entfernen Prüfanweisungen, ausführliche Stilregeln, unnötige Beispiele und stets eingebundene Referenzen werden jeweils nach Art entfernt. Nach jeder Änderung werden Qualität und Kosten erneut gemessen. ### Schritt 5: Routing-Richtlinie erstellen Das Modell wird anhand von Aufgabenschwierigkeit, Risiko, erwartetem Kontext und Zeitlimit ausgewählt. Die in den bereitgestellten Unterlagen vorgeschlagenen Rollen der einzelnen Modelle dürfen erst nach Bestätigung der offiziellen Bezeichnungen und Leistungsdaten als Hypothesen getestet werden und dürfen nicht unverändert als Betriebsrichtlinie übernommen werden. ### Schritt 6: Zunächst mit begrenztem Datenverkehr bereitstellen Die Umstellung wird zunächst auf einige Benutzer oder nicht riskante Aufgaben angewandt. Nach Beobachtung von Fehlerquote, Wiederholungsversuchen, Anzahl der subagent, Toolfehlern und menschlicher Korrekturzeit wird der Umfang erweitert. ## Checkliste für den Betrieb - [ ] Die offizielle Modellbezeichnung und API-Modell-ID wurden geprüft. - [ ] Die tatsächlich geltenden Preise für Ein- und Ausgabe, Caching, Batch-Verarbeitung und weitere Komponenten wurden geprüft. - [ ] Es gibt ein eigenes Bewertungsset aus realen Arbeitsaufgaben. - [ ] Die Prüfschritte von Modell und Harness überschneiden sich nicht. - [ ] Es gibt Kriterien für subagent-Aufrufe, eine Obergrenze für parallele Ausführungen und ein Budgetlimit. - [ ] Antwortlänge und Ausgabeschema wurden festgelegt. - [ ] Qualität, Kosten und Latenz wurden für verschiedene Schlussfolgerungsintensitäten verglichen. - [ ] Für Hochrisikoaufgaben bleiben deterministische Prüfungen und menschliche Genehmigungen bestehen. - [ ] Der Kontext ist in dauerhaft geltende Anweisungen, Skill und Referenzen unterteilt. - [ ] Das bisherige Modell und seine Konfiguration stehen für ein Rollback bereit. ## Fazit Der Kern eines Wechsels zu einem neuen Modell besteht weder darin, Prompts bedingungslos zu verkürzen, noch darin, die Autonomie bedingungslos auszuweiten. Entscheidend ist, **zunächst die offiziellen Produktinformationen zu prüfen und anschließend anhand realer Arbeitsbewertungen die Rollen von Modell und Harness neu aufzuteilen**. Die in den bereitgestellten Unterlagen genannten Zahlen und Bezeichnungen zu Claude Opus 5 müssen bis zur Bestätigung durch offizielle Quellen als vorläufige Informationen behandelt werden. Die Beseitigung doppelter Prüfungen, die Begrenzung von subagent, klare Ausgabeverträge, die schrittweise Offenlegung von Kontext und ein auf eigenen Bewertungen basierendes Routing sind jedoch unabhängig von der Modellgeneration anwendbare Grundsätze für einen Wechsel. ## FAQ ### Ist Claude Opus 5 ein offiziell veröffentlichtes Modell? In den bereitgestellten Materialien werden zwar ein Veröffentlichungsdatum und Preise genannt, doch anhand der in diesem Artikel enthaltenen Informationen allein lässt sich dies nicht unabhängig bestätigen. Bis der genaue Modellname und die Modell-ID in der offiziellen Modellliste von Anthropic, in einer Ankündigung und in der API-Konsole bestätigt wurden, ist es ratsam, diese Angaben nicht als gesicherte Produktinformationen zu betrachten. ### Ist Fable 5 eine offizielle Modellbezeichnung von Anthropic? Anhand der bereitgestellten Materialien lässt sich dies nicht bestätigen. Da bei Anthropic selbst bei ähnlichen Produktnamen die API-Modell-ID oder die Bezeichnung je nach Dienst unterschiedlich sein kann, muss in der offiziellen Modellliste überprüft werden, ob die Bezeichnung `Fable 5` tatsächlich existiert. ### Muss ich beim Wechsel zu einem neuen Claude-Modell alle bestehenden Prompts löschen? Nein. Zunächst sollte mit den bestehenden Einstellungen eine Referenzbewertung durchgeführt werden. Anschließend sollten redundante Validierungsanweisungen oder unnötige Stilregeln einzeln entfernt und dabei Qualität und Kosten verglichen werden. Kontrollen, die das System gewährleisten muss, wie Sicherheitsprüfungen, die Validierung des Ausgabeschemas und die Freigabe der Bereitstellung, sollten beibehalten werden. ### Was ist ein Harness? Ein Harness ist ein System, das ein AI-Modell umgibt, damit es in der tatsächlichen Arbeit eingesetzt werden kann. Es umfasst System-Prompts, Projektanweisungen, Tools, Suche, Speicher, Skills, Subagents, Wiederholungsversuche, Berechtigungsverwaltung und automatisierte Verifizierungsverfahren. ### Wie sollte die Nutzung von Subagenten begrenzt werden? Sie sollten nur für Aufgaben eingesetzt werden, die sich unabhängig voneinander aufteilen lassen, und sowohl die Anzahl gleichzeitiger Ausführungen als auch die Gesamtzahl der Aufrufe sollte nach oben begrenzt werden. Die Ergebnisse und Abbruchbedingungen jedes Subagenten sollten klar festgelegt werden; zudem kann das System so gestaltet werden, dass die Zustimmung eines Menschen erforderlich ist, wenn die erwarteten Kosten oder der Zeitaufwand einen Schwellenwert überschreiten. ### Warum sind eigene Evaluierungen wichtiger als öffentliche Benchmarks? Öffentliche Benchmarks spiegeln die Codebasis, Dokumentformate, Tool-Umgebung und Fehlerkosten einer Organisation nicht unverändert wider. Um beurteilen zu können, welches Modell für die Betriebsumgebung geeignet ist, müssen Erfolgsquote, Gesamtkosten, Bearbeitungszeit und Ergebniskonsistenz anhand realer Anwendungsfälle gemessen werden. ### Kann man auf Tests verzichten, wenn das Modell eine Selbstvalidierung durchführt? Nein. Die Selbstüberprüfung des Modells ist ein Hilfsmittel und ersetzt weder Tests, Schemaüberprüfungen und statische Analysen noch Sicherheitsrichtlinien. Insbesondere bei risikoreichen Vorgängen wie Bereitstellungen, Zahlungen und Datenlöschungen sind deterministische Prüfungen und die Zustimmung eines Menschen erforderlich. ### Werden die Antworten automatisch kürzer, wenn man effort reduziert? Das ist nicht unbedingt der Fall. Die Intensität des Schlussfolgerns und die Länge der endgültigen Ausgabe können separat gesteuert werden. Wenn eine knappe Antwort benötigt wird, sollte das Antwortformat, etwa die Zeichenanzahl, die Anzahl der Punkte oder das Ausgabeschema, direkt im Prompt vorgegeben werden. ## Sources - [Anthropic Docs: Modellübersicht](https://docs.anthropic.com/en/docs/about-claude/models/overview) - [Anthropic-Preise](https://www.anthropic.com/pricing) - [Anthropic Docs: Überblick über Prompt Engineering](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) - [Anthropic-Dokumentation: Claude Code-Speicher](https://docs.anthropic.com/en/docs/claude-code/memory) ## Images ![체크 항목과 경고 장벽 사이에서 AI 큐브를 돋보기로 점검하는 일러스트](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--f44d725b558668593419631e29f28834deb66ecc/ai-95ae89bc.webp) ![중앙 AI 모델에 보안, 문서, 사용자, 도구와 에이전트 차단 장치가 연결된 점검 구성도](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--5ddddd2dfbbbcedb1849fbdfe606aca94f9a98af/ai-b298a672.webp)