Kategorie: Erklärer

Stell dir vor, du bekommst einen neuen Kollegen in deinem Team. Du übergibst ihm ein Handbuch, das aus früheren Jahren stammt: lang, voller überflüssiger Regeln, und ein paar Anweisungen widersprechen sich sogar. Was wird passieren? Er orientiert sich an den veralteten Details, statt sich auf die eigentliche Arbeit zu konzentrieren. Genauso geht es KI-Agenten, wenn ihr „Einarbeitungshandbuch“ – also der System-Prompt und die Tool-Beschreibungen – nicht zur aktuellen Modellgeneration passt. Das LangChain-Team hat daraus die Konsequenz gezogen und Deep Agents in Version 0.7 veröffentlicht. Die zentrale Botschaft: weniger Basis-Input-Tokens, gleiche Leistung, mehr Konfigurierbarkeit.

Doch was bedeutet das konkret? Wer mit KI-Agenten arbeitet, weiß: Ein Modell ist nur so gut wie der Kontext, den es bekommt. Und dieser Kontext entsteht fast vollständig durch den Prompt, den der Harness – also das Rahmenwerk, das den Agenten steuert – zusammenbaut. Der Harness entscheidet, welche Anweisungen, Tool-Beschreibungen und Middleware-Komponenten am Ende im Kontext landen. Lange Zeit galt: Je mehr geschickte Prompt-Formulierungen, desto besser. OpenAI, Anthropic und Google veröffentlichen regelmäßig ihre eigenen Prompting-Guides und haben sie mehrfach überarbeitet, weil die Modelle immer leistungsfähiger wurden. Ein Harness, der nicht mitzieht, schleppt dann Formulierungen mit sich herum, die das Modell längst überholt hat. Genau das hat das LangChain-Team beobachtet.

Die Lösung heißt Kontext-Engineering. Anthropic hat vor Kurzem einen aktualisierten Leitfaden dazu veröffentlicht. Dabei zeigte sich ein bemerkenswerter Effekt: Bei Modellen wie Opus 5 und Fable 5 konnte der System-Prompt von Claude Code um über 80 Prozent gekürzt werden, ohne dass die Ergebnisse bei den Coding-Evals nachließen. Zwei zentrale Erkenntnisse daraus sind auch in Deep Agents v0.7 eingeflossen. Erstens: Gut formulierte Tool-Schemas lehren die Bedienung besser als früher beliebte Few-Shot-Beispiele. Solche Beispiele schränken die Erkundung des Modells eher ein, als dass sie helfen. Zweitens: Wiederholungen bringen nichts. Wenn eine Anweisung sowohl im System-Prompt als auch in der Tool-Beschreibung steht, verstärkt sie das nicht – es verschwendet nur Tokens. Diese Einsichten mag man für banal halten, aber sie führen zu einer der größten strukturellen Änderungen in Deep Agents seit Langem: Der Basis-Harness ist um 65 Prozent schlanker geworden.

So wurde der Harness abgespeckt

Das Team hat eine klare Hypothese aufgestellt: Wenn man unnötige Tokens aus dem Basis-Input-Prompt entfernt, steigt die Token- und Kosteneffizienz, während die Leistung stabil bleibt. Um das zu testen, haben sie drei Änderungen vorgenommen. Zuerst wurde der System-Prompt entfernt, der bisher im Hintergrund von Deep Agents verwendet wurde. Er enthielt allgemeine Richtlinien und ausführliche Tool-Erklärungen. Zweitens wurden die Beschreibungen der eingebauten Tools um 43 Prozent gekürzt. Drittens ist die TodoList-Middleware jetzt optional: Der Befehl create_deep_agent aktiviert sie nicht mehr standardmäßig. Die Evals zeigten, dass der Planungs-Prompt und das Tool write_todos keine signifikante Leistungsverbesserung brachten. Zusammengenommen reduzieren diese Änderungen die Basis-Input-Tokens bei einem Standard-Agenten von etwa 6.000 auf rund 2.000 Tokens – also um 65 Prozent. Unter Basis-Input-Tokens versteht man die Tokens, die durch den eingebauten Prompt, die Tools und die Middleware entstehen, bevor irgendeine echte Aufgabe überhaupt beginnt.

Man kann sich das so vorstellen wie den Motor eines Autos. Wenn du einen V8-Motor einbaust, der aber ständig falsches Öl bekommt, verbraucht er unnötig Sprit. Entfernst du das falsche Öl und stellst die Zündung richtig ein, leistet der Motor dasselbe – mit weniger Verbrauch. Genau das ist hier passiert. Die Modelle sind inzwischen so gut, dass sie keine ausführlichen, redundanten Anweisungen mehr brauchen, um zu verstehen, wie ein Agent arbeiten soll. Sie brauchen klare und knappe Werkzeuge, keine predigenden Texte.

Wie die Änderungen validiert wurden

Natürlich reicht es nicht, einfach etwas zu streichen. Das LangChain-Team hat eine neue Eval-Suite aufgebaut, die sich auf drei Kategorien von Benchmarks stützt. Autonome Aufgaben umfassen End-to-End-Arbeiten wie Code-Erstellung oder Datenanalyse. Konversationsaufgaben testen mehrstufige Dialoge mit einem simulierten Benutzer. Und Langzeitkontext-Aufgaben verlangen das Auffinden und Verarbeiten von Informationen aus langen Kontexten. Diese drei Kategorien bilden ab, wofür Deep Agents in der Praxis eingesetzt wird: als automatischer Code-Assistent, als Chat-Bot mit Werkzeugen und als Recherche-Werkzeug für große Dokumente.

Dabei haben sie den neuen v0.7-Harness gegen den alten v0.6.12 über eine Matrix aus allen drei Eval-Kategorien und vier verschiedenen Modellen laufen lassen: gpt-5.6-luna, gemini-3.6-flash, claude-sonnet-4-6 und claude-opus-4-8. Das Ergebnis: Die Rewards, also die Bewertungsmetriken für die Qualität der Agentenleistung, blieben insgesamt stabil. Gleichzeitig sanken die Token-Kosten meist. Besonders deutlich war der Rückgang bei gpt-5.6-luna: 34 Prozent weniger Tokens und 15 Prozent weniger Kosten, bei sogar 4 Prozent höherem Reward. Eine Ausnahme gab es: claude-sonnet-4-6 verzeichnete eine höhere Kostenbelastung, was die Analyse von LangSmith-Traces auf zwei besonders schwierige autonome Aufgaben zurückführte. Solche Ausreißer sind typisch, wenn man mit kleinen Benchmark-Sets arbeitet.

Wichtig ist die statistische Einordnung: Die Konfidenzintervalle der Rewards überlappen bei allen Modellen die Null, das heißt, die Leistungsänderung ist nicht signifikant. Bei den Tokens hingegen sehen die Forscher bei Luna und Opus einen statistisch klaren Rückgang, und Luna zeigt auch einen klaren Kostenvorteil. Womit wir beim Kern der Sache wären: Die Effizienzsteigerung ist messbar, das Risiko von Leistungseinbußen ist statistisch nicht nachweisbar. Das ist genau das, was man sich von einem Refactoring wünscht.

Der Status der Todo-Listen

Eine der auffälligsten Änderungen ist, dass die Todo-Listen nicht mehr automatisch aktiv sind. TodoListMiddleware ist jetzt opt-in. Die Evals über drei Kategorien und drei Modelle zeigten leicht bessere Rewards und niedrigere Kosten, wenn die Todo-Listen deaktiviert sind. Also haben die Entwickler das write_todos-Werkzeug aus dem Basis-Harness entfernt. Das klingt radikal, ist aber nachvollziehbar: Kleinere Modelle profitieren vielleicht davon, wenn sie einen expliziten Plan führen müssen, um nichts zu vergessen. Leistungsfähige Modelle erzeugen durch diese zusätzlichen Schritte aber eher unnötige Tokens und lenken sich selbst von der eigentlichen Aufgabe ab.

Dennoch gibt es drei Szenarien, in denen die Todo-Listen weiterhin sinnvoll sind. Erstens bei langen, mehrstufigen Aufgaben, in denen ein Agent über viele Runden hinweg einen klaren Plan braucht, um nicht den Faden zu verlieren. Zweitens bei weniger leistungsfähigen Modellen, die mehr Gerüst benötigen, um ein Problem sauber zu Ende zu arbeiten. Und drittens bei Benutzeroberflächen, wo ein sichtbarer Plan und Fortschritt fast genauso wichtig sind wie die eigentliche Ausführung. Für alle, die in einem dieser Szenarien stecken, ist das Aktivieren eine Zeile Code: middleware=[TodoListMiddleware()]. Die Entwickler appellieren damit an die Vernunft, nicht an die Mode: Wer die Funktion braucht, stellt sie ein; wer sie nicht braucht, spart Tokens.

Mehr Konfigurierbarkeit als oberstes Gebot

Die größte Bitte der Deep-Agents-Nutzer in den letzten sechs Monaten war nicht eine neue Funktion, sondern mehr Kontrolle. Sie wollten die FilesystemMiddleware übersteuern, die Schwellenwerte der SummarizationMiddleware anpassen und den Basis-Prompt global verändern. Bisher scheiterten alle Versuche an einer fehlenden Schnittstelle: Es gab keinen unterstützten Weg, den Standard-Harness anzupassen. In v0.7 ändert sich das gleich auf zwei Arten.

Erstens haben Nutzer die volle Kontrolle über ihre eigenen Prompts. Das Entfernen der versteckten Standard-Prompts hat einen angenehmen Nebeneffekt: Eigene Prompts werden wirkungsvoller, weil kein unsichtbarer Basis-Prompt mehr darunterliegt, der aufbläht oder im schlimmsten Fall sogar widerspricht. Zweitens ist das Übersteuern der Middleware jetzt erstklassig unterstützt. Wenn man eine Middleware-Instanz mit dem gleichen Namen wie eine Standard-Middleware übergibt, ersetzt sie diese – zusätzliche Fehlermeldung gibt es nicht mehr. Ein Power-User beschrieb es treffend: „Früher mussten wir ein paar Tricks anwenden, um Standard-Middleware zu entfernen. Dass wir sie jetzt einfach übersteuern können, ist eine sehr willkommene Ergänzung.“

Ein gutes Beispiel ist die SummarizationMiddleware. In der Voreinstellung greift sie, sobald ein Gespräch 85 Prozent des Kontextfensters erreicht, mit einem generischen Zusammenfassungs-Prompt. Für viele Anwendungen ist das zu starr. Manche Applikationen brauchen eine spezifischere Zusammenfassung, andere wollen früher eingreifen, um dem sogenannten „Dumb-Zone-Effekt“ vorzubeugen – der Zone, in der das Modell trotz noch offenem Kontextfenster schlechter wird, weil die relevanten Informationen in der Masse untergehen. Jetzt können Entwickler eine eigene Summarization-Middleware einbauen. Das gleiche Muster funktioniert für jede Standard-Komponente, etwa für die TTL-Werte des Prompt-Cachings. So entsteht ein Baukasten, den sich viele gewünscht haben.

Dateisystem-Optimierungen

Das Dateisystem ist das zentrale Kontext-Management von Deep Agents. Es ist die Umgebung, über die der Agent Zustand liest, schreibt und navigiert. Die Optimierungen in v0.7 stammen aus derselben Eval-Suite sowie aus Trajektorien-Analysen echter dcode-Nutzung – mit offenen und geschlossenen Modellen. Die Neuerungen sind praxisnah: write_file überschreibt jetzt eine bestehende Datei statt einen Fehler zu werfen. read_file gibt bei paginiertem Lesen die Gesamtzahl der Zeilen, die noch verbleibenden Zeilen und den nächsten Offset zurück. grep und glob liefern Teilergebnisse mit einem truncated-Flag, statt auf großen Verzeichnisbäumen hängen zu bleiben. Das grep-Tool hat außerdem eine Obergrenze von 1.000 Treffern, gestreamte Ausgabe und optionale Kontextzeilen. Diese Änderungen klingen unspektakulär, sind aber für reale Arbeit entscheidend: Agenten müssen robust auf großen Codebasen arbeiten, nicht nur in Spielzeug-Projekten.

Was sich konkret ändert – Breaking Changes

Mit der neuen Version kommen auch ein paar bewusste Bruchstellen. Die TodoListMiddleware ist nicht mehr standardmäßig aktiv – das ist die wichtigste. Wer sie braucht, aktiviert sie einfach. Zweitens wurde der Support für Backend-Factories entfernt, der bereits in v0.5 abgekündigt war; stattBackendProtocol-Instanzen sind jetzt die Norm. Andere Dateiformat- und Backend-Protokoll-Deprecations aus v0.5 sind ebenfalls entfernt. Drittens wurde das delete-Tool zur Standard-Liste der Dateisystem-Tools hinzugefügt. Das FilesystemMiddleware akzeptiert eine Tool-Auswahlliste, sodass man das Löschen deaktivieren kann, wenn man das Sicherheitsrisiko vermeiden will. Wer eine Migration plant, findet alle Details im Changelog – inklusive Notizen und einem Upgrade-Prompt für Coding-Agenten. Viele Projekte pflegen ein solches Prompt, um Agenten bei Versionswechseln zu helfen.

Was bedeutet das alles für dich? Wenn du Deep Agents einsetzt, wird dein nächster Upgrade-Schritt wahrscheinlich wehtun – aber nur kurz. Die entfernteren Kompatibilitätsschichten sind kein Verlust, sondern eine Einladung, den eigenen Stack zu modernisieren. Und wenn du ohnehin mit vielen Agenten arbeitest, sind 65 Prozent weniger Basis-Tokens ein Unterschied, der sich in der Kostenrechnung bemerkbar macht. Stell dir vor, du betreibst eine Plattform mit Millionen von Agent-Aufrufen pro Tag. Die Einsparungen sind enorm.

Die Botschaft der Release ist klar: Kontext-Engineering ist die neue Königsdisziplin. Ein Modell wird nicht durch möglichst viele Prompt-Tokens besser, sondern durch die richtigen – und durch die Fähigkeit, die Struktur an das jeweilige Modell anzupassen. Deep Agents v0.7 zeigt, wie ein schlanker, konfigurierbarer Harness aussieht. Kein Wunder, dass die Entwickler bei der Validierung weniger auf neue Features als auf vergleichbare Leistung und geringere Kosten geachtet haben. In einer Zeit, in der jeder Token zählt, ist das die richtige Priorität.

Klar ist aber auch: Es gibt keine Universallösung. Die Entscheidung, Todos abzuschalten, mag für moderne Hochleistungsmodelle richtig sein. Für ältere oder kleinere Modelle kann es dennoch weiterhin helfen, einen expliziten Plan zu führen. Das Schöne an Deep Agents v0.7 ist, dass diese Entscheidung jetzt beim Entwickler liegt, nicht im Rahmenwerk. Mehr Konfigurierbarkeit bedeutet mehr Verantwortung – und genau das zeichnet eine reife Software aus. Wenn du dir also die Frage stellst, wie viel Prompt ein Agent wirklich braucht, lautet die Antwort aus dieser Version: Weniger, als du denkst – aber mit der Freiheit, genau das nachzujustieren. Das ist geerdete, ehrliche Ingenieursarbeit.

Quelle: langchain.com

Ein IT-Administrator betreibt eine Flotte von Windows-Geräten. BitLocker, Secure Boot und Code Integrity sind aktiv, Intune zeigt grün. Dann kommt ein Dienstag im Juli. Eine neue Build wird ausgerollt. Intune meldet für zahlreiche Geräte: „Noncompliant“. Drei rote Fehler, alle mit dem Code 2016345708. Was ist passiert? Die Geräte wurden nicht gehackt, sie haben keine Sicherheitslücke. Sie sind immer noch genauso geschützt wie vor dem Update. Aber Intune sieht das anders. Das liegt an einem unsichtbaren Mechanismus im Hintergrund: Wenn der Ausweis nicht mehr passt, kommt keiner rein.

Ein Beitrag auf PatchMyPC hat das Problem beschrieben. Auslöser war ein Reddit-Post, der vielen IT-Administratoren bekannt vorkam: BitLocker aktiviert, Secure Boot aktiviert, Code Integrity aktiviert – und trotzdem meldete Intune für alle drei Checks einen Fehler mit dem gleichen Code 2016345708. Das sah nach einem Problem mit den Geräteeinstellungen aus, war es aber nicht. Die Ursache lag eine Ebene tiefer, im Zusammenspiel zwischen Windows, dem Trusted Platform Module (TPM) und dem Microsoft Device Health Attestation Service.

Wenn Intune prüft, ob ein Gerät compliant ist, vertraut es nicht einfach auf eine lokale Ja/Nein-Antwort. Stattdessen fragt es den Health Attestation Service: der sammelt beim Hochfahren des Geräts gemessene Boot-Protokolle und TPM-Nachweise, schickt sie an Microsofts Cloud-Dienst und erhält ein signiertes Gesundheitszertifikat zurück. Dieses Zertifikat fungiert als „Reisepass“ des Geräts für Intune. Fehlt der Reisepass, weil die Ausstellung nicht geklappt hat, kann Intune nicht bestätigen, dass BitLocker eingeschaltet ist. Das Gerät erscheint noncompliant, obwohl lokal alles korrekt ist.

Bei den Juli-Builds war der Fehler genau dieser: Das Gesundheitszertifikat kam nie an. Der Tpm-HASCertRetr-Task blieb hängen – der Health-Attestation-Status verharrte auf 0xFFFF, dem Code für einen aus unbekanntem Grund fehlgeschlagenen Zertifikatsabruf. Weil dieser eine Nachweis fehlte, gingen auch alle abhängigen Compliance-Prüfungen (BitLocker, Secure Boot, Code Integrity) ins Leere. Das war kein Einzelfall. Bereits 2023 gab es ähnliche Berichte. Diesmal war die Ursache eine neue Windows-Funktion, die mit dem Juli-Update aktiviert wurde.

Die Analyse zeigte ein verstecktes Windows-Feature: die Funktions-ID 62861611, intern „PCPKspEKPubEnumeration“ genannt. Diese Funktion ändert, wie Windows die TPM-Identität vorbereitet, bevor der Attestierungsprozess beginnt. Normalerweise verwendet Windows einen etablierten RSA-basierten Pfad, um den Endorsement Key (EK) und den Attestation Identity Key (AIK) auszulesen. Mit Feature 62861611 erweitert Windows diesen Pfad: es sammelt zusätzliche öffentliche Schlüssel aus dem TPM – sowohl RSA als auch ECC – und bereitet einen neuen AIK-Typ (v2) vor. Das ist eine Modernisierung für mehr Krypto-Agilität und verschiedene Algorithmen.

Doch diese Erweiterung führte zu Kompatibilitätsproblemen. Bei physischen TPMs von Herstellern wie Nuvoton oder STMicroelectronics konnte Windows zwar die vorhandenen Zertifikate finden, aber die neu angelegten Identitäten ließen sich nicht vollständig mit dem Microsoft-AIK-Dienst abgleichen. Die Zertifikatskette wurde als ungültig zurückgewiesen. Bei virtuellen TPMs – etwa in Parallels Desktop – war das Problem noch schwerwiegender: Der neue Code erwartete bestimmte Schlüsselformate, die die virtuelle TPM-Umgebung nicht lieferte. Get-Tpm gab den Fehler „Structure is wrong size“ zurück, und Hello, BitLocker sowie alle Attestierungsfunktionen brachen zusammen.

Microsoft hat das Problem mit Advisory IT1431577 anerkannt. Die Ursache wurde als „Windows-Code-Regression“ beschrieben, die Device Health Attestation und die Intune-Compliance-Auswertung beeinträchtigt. Das Advisory geht nicht auf die Details des Features 62861611 ein, bestätigt aber: Es war kein Konfigurationsfehler in Intune, sondern ein Windows-Update, das die Attestierung während der Enrollment-Phase veränderte. Die offizielle Lösung war KB5101684, ein Preview-Update, das die Regression behob. Davor hatte Microsoft bereits serverseitige Anpassungen vorgenommen, um die Auswirkungen abzumildern.

Was bedeutet das konkret für Administratoren? Wenn nach einem Windows-Update plötzlich hunderte Geräte als noncompliant wegen BitLocker, Secure Boot und Code Integrity auftauchen, sollten sie nicht jede Einstellung einzeln debuggen. Der gemeinsame Nenner ist das Device Health Attestation-Zertifikat. Ein einfacher A/B-Test, den der PatchMyPC-Autor durchgeführt hat, zeigt, wie man das Problem isolieren kann: Deaktiviert man das Feature 62861611 mit einem Tool wie ViVeTool und startet neu, funktioniert die Attestierung wieder. Das belegt, dass die Ursache in der neuen TPM-Identitätslogik liegt und nicht im TPM selbst.

Für die Zukunft bleibt die Erkenntnis: Microsoft treibt die Krypto-Agilität von Windows voran, auch wenn das bei bestehenden Infrastrukturen zu kurzzeitigen Aussetzern führen kann. Die Einführung von AIK v2 und die breitere Nutzung von ECC-Schlüsseln erhöht die Sicherheit, erfordert aber, dass sowohl physische als auch virtuelle TPMs die neuen Anforderungen erfüllen. Die betroffene Feature-ID ist nur der Anfang. IT-Teams sollten ihre TPM-Umgebungen auf Kompatibilität prüfen, insbesondere bei Geräten mit unterschiedlichen TPM-Herstellern oder virtualisierten TPMs.

Diese Geschichte zeigt, wie tief die Abhängigkeiten in modernen Windows-Umgebungen reichen. Ein kleiner Schalter in der Windows-Binary kann Compliance-Ergebnisse auf der ganzen Flotte kippen lassen, ohne dass sich an den Sicherheitseinstellungen selbst etwas ändert. Die Lösung kommt in Form eines kumulativen Updates, aber das Verständnis der Ursache hilft, ähnliche Störungen schneller zu erkennen. Der schlimmste Fehler wäre, jetzt an den BitLocker-Richtlinien zu drehen – das würde das Problem nur verschleiern, nicht beheben.

Quelle: patchmypc.com

Der Prototyp läuft. Die Produktion nicht.

Du hast eine Idee für eine KI-gestützte Anwendung. Ein paar Wochen später läuft der Prototyp gut – schnell, beeindruckend. Der Kunde ist zufrieden, das Team feiert. Doch dann schickst du das System in die echte Welt. Und plötzlich treten Probleme auf, die du nicht erwartet hast. Requests timeouten. Workflows verlieren ihren Zustand. Drittanbieter-APIs antworten nicht oder senden Müll. Im Prototyp war alles kontrolliert. In der Produktion wird es schwierig. Entwickler, die KI-Systeme in großem Maßstab betreiben, bestätigen: Die größte Hürde ist nicht die KI selbst. Es ist die Umgebung.

Die Illusion der einfachen KI

Liest du die Schlagzeilen, entsteht der Eindruck, KI sei ein Prompt, den man an ein Sprachmodell schickt, und dann läuft es. In der Praxis zählt Infrastruktur, Orchestrierung, Fehlermanagement und Zustandspersistenz über asynchrone Aufrufe hinweg. Ein Team baute ein Go-to-Market-Tool: eine Plattform, die Firmen bewertet, Leads anreichert und E-Mails verfasst. Klingt harmlos. In Wirklichkeit orchestriert das System Dutzende von Drittanbieter-APIs – CRM, Datenanbieter, E-Mail-Dienste. Jede hat eigene Limits, Fehlermodi, Timeouts. Fällt eine aus, darf der ganze Workflow nicht sterben. Der schlimmste Fehler: Den Zustand eines Workflows nur im Arbeitsspeicher zu halten – ein Serverneustart und alles ist weg.

Wie Orchestrierung zum Rettungsanker wird

Ohne Orchestrierung scheitern komplexe Workflows. Entwickler, die KI-basierte Prozesse ohne zuverlässige Orchestrierung bauen, brauchen ein System, das den Fortschritt dauerhaft speichert, automatische Wiederholungsversuche durchführt und Zustände über Stunden oder Tage nachhält. Lösungen wie Temporal – eine Workflow-Engine für langlaufende, fehlertolerante Prozesse – helfen dabei. Das beruht auf Erfahrungen mehrerer Teams, die ihre KI-Systeme damit in den Griff bekommen haben.

Fall 1: Cargo – das API-Orchester

Das erste Team, Cargo, hatte genau dieses Problem. Ihre Plattform orchestriert Anfragen an externe Dienste – Firmenbewertung, Lead-Anreicherung, E-Mail-Generierung. Jeder Dienst hat eigene Ratenlimits, Failover-Strategien und Antwortformate. Anfangs lösten sie das mit klassischen Job Queues: ein Job in die Warteschlange, ein Worker holt ihn ab. Das funktioniert nicht, sobald ein Job mehrere Schritte nacheinander umfasst. Wenn der zweite Schritt fehlschlägt, muss der ganze Job von vorne beginnen. Oder der Zustand geht verloren. Die Lösung war der Wechsel zu Temporal: Jeder Workflow wird als Code geschrieben, mit expliziten Schritten, Bedingungen und Fehlerbehandlungen. Aurelien Aubert, CEO von Cargo, beschreibt es so: „Unsere gesamte Orchestrierung basiert heute auf Temporal.“

Fall 2: Grepsr – Daten im Tsunami-Modus

Das zweite Team, Grepsr, baute ein Web-Scraping-System, das täglich über 600 Millionen Datensätze aus mehr als 10.000 Quellen verarbeitet. Millionen parallele Jobs. Traditionelle Job Queues wie RabbitMQ oder Celery sind dafür nicht ausgelegt. Sie verlieren Jobs bei Worker-Ausfällen, können keine langlaufenden Workflows mit Zwischenzuständen abbilden, das Monitoring wird aufwendig. Mit Temporal modellierten sie jeden Scraping-Job als Workflow – mit eigener ID, persistentem Zustand und definierten Fehlerstrategien. Subrat Basnet, Co-Founder von Grepsr, sagt: „Unsere Entwickler müssen sich nicht mehr um das Orchestrieren von Wiederholungsversuchen oder das Nachhalten des Job-Zustands kümmern. Sie konzentrieren sich auf das Wesentliche – bessere Datenerlebnisse für unsere Kunden zu bauen.“

Fall 3: Dust – KI-Teammitglieder, die funktionieren

Dust, ein Unternehmen für KI-gestützte „Teammitglieder“, hatte eine komplexere Aufgabe. Ihre KI-Agenten führen über 10 Millionen Workflow-Schritte pro Tag aus. Diese Schritte umfassen Entscheidungslogik, Kontextwechsel und Interaktionen mit verschiedenen KI-Modellen. Ohne robuste Orchestrierung – so der CTO – wäre ein Agent nicht mehr als ein Chatbot, der nach dem ersten Fehler aufgibt. Sie setzen auf Temporal und lernten: Zuverlässigkeit steckt nicht im KI-Modell, sondern in der Fähigkeit, einen Workflow nach Ausfällen kontrolliert fortzusetzen. Wenn ein KI-Aufruf fehlschlägt, muss der Workflow nicht von vorne beginnen. Er kann an der Stelle weitermachen, an der er unterbrochen wurde. Das erfordert eine Orchestrierungsplattform, die genau das leistet.

Warum der Kampf um die Zustandserhaltung entscheidend ist

Warum reicht es nicht, jeden Schritt in einer Datenbank zu protokollieren und bei Bedarf neu zu starten? KI-Workflows sind oft nicht linear. Sie verzweigen sich, rufen asynchrone Dienste auf, warten auf menschliche Rückmeldungen oder auf Ergebnisse anderer Workflows. Wenn ein Worker während eines solchen Prozesses abstürzt, muss der Zustand wiederherstellbar sein, ohne dass Logik verloren geht. In vielen Systemen wird der Zustand implizit durch den Call-Stack gehalten. Sobald der Prozess stirbt, ist dieser Zustand weg. Temporal löst das, indem es den Zustand jedes Workflows in einen dauerhaften Speicher schreibt – ähnlich wie ein Flugschreiber. Fällt ein Worker aus, übernimmt ein anderer exakt an der Stelle, an der der Workflow unterbrochen wurde. Das ist der Unterschied zwischen einem Prototyp unter Laborbedingungen und einem zuverlässigen Produktivsystem.

Was Entwickler daraus lernen können

Die drei Fallstudien zeigen ein Muster: KI in der Produktion ist kein Problem der KI, sondern der Orchestrierung, Zustandsverwaltung und Fehlertoleranz. Gute Modelle nützen nichts, wenn die Infrastruktur versagt. Abkürzungen gibt es nicht. Von Anfang an muss man Fehlerstrategien einplanen. Zustandspersistenz ist Kernanforderung, kein nachträglicher Einfall. Werkzeuge müssen für diese Herausforderungen entwickelt sein. Erfolgreiche Teams haben den Prototypen verworfen und eine robuste Architektur aufgebaut. Das ist Ingenieursarbeit.

Der Weg nach vorne – ohne Illusionen

KI wird bleiben und wachsen. Entwickler, die langfristig bestehen, verstehen: Ein KI-System ist mehr als ein Modell – es ist ein verteiltes System mit all seinen Tücken. Wenn du deine nächste KI-Anwendung baust, frag dich nicht nur, welches Modell du verwendest. Frag dich, wie dein System mit Timeouts umgeht, wie es verlorenen Zustand wiederherstellt, wie es tausende parallele Workflows orchestriert. Die Antworten entscheiden, ob dein System ein weiterer Prototyp bleibt, der unter realen Bedingungen zerbricht, oder ob es in der Produktion lebt. Diese Lektion ist wichtiger als jeder neue KI-Trend.

Quelle: temporal.io

Stell dir vor, du sitzt vor einem Safe, der als unknackbar gilt. Du hast alle Werkzeuge – aber niemand hat sie je in dieser Kombination ausprobiert. Genau das ist passiert, als Anthropic zwei neue kryptanalytische Ergebnisse veröffentlichte. Der Blogbeitrag stammt von einem bekannten Kryptografie-Experten. Er zeigt, wie KI-Modelle wie Claude Mythos – ein noch nicht veröffentlichtes Modell – bestehende Werkzeuge geschickt kombinieren. Es geht nicht um übernatürliche Intelligenz, sondern um gründlichere Anwendung des Bekannten. Das macht die Ergebnisse spannend und unheimlich zugleich.

Die zwei Resultate könnten unterschiedlicher nicht sein. Eines betrifft ein vorgeschlagenes Signaturschema namens HAWK, basierend auf dem Module Lattice Isomorphism Problem (module-LIP). Das andere ist ein Angriff auf eine abgeschwächte Version des AES-Verschlüsselungsstandards. Beide stammen von Claude Mythos, einem internen KI-Modell von Anthropic. Der Autor des Artikels betont: Qualität und Relevanz der Ergebnisse sind sehr unterschiedlich. Das muss man verstehen, bevor man in Panik verfällt.

Der Angriff auf HAWK: Ein echter Warnschuss

HAWK ist kein Standard, sondern ein Vorschlag. Es gehört zur Familie der Post-Quanten-Signaturen – Algorithmen, die gegen Quantencomputer-Angriffe sicher sein sollen. Claude Mythos fand einen Key-Recovery-Angriff. Ein Angreifer kann den geheimen Schlüssel aus öffentlichen Informationen ableiten. Der Angriff ist exponentiell in der Laufzeit, aber er halbiert die Sicherheit in Bits. Das klingt dramatisch – und ist es auch, zumindest für HAWK.

Der Clou: Der Angriff braucht keine neuen mathematischen Entdeckungen. Der Autor schreibt: „Was diesen Angriff wirklich interessant macht – und ehrlich gesagt ein bisschen peinlich für die Fachwelt – ist, dass keine der Zutaten exotisch ist.“ Alle Werkzeuge lagen bereit. Niemand hatte sie in dieser Kombination und mit dieser Gründlichkeit eingesetzt. Genau das können KI-Modelle besonders gut: Sie arbeiten sich durch alle Kombinationen, ohne müde zu werden, und entdecken Muster, die Menschen übersehen.

Der Angriff wurde an einer abgeschwächten Challenge-Instanz von HAWK demonstriert. Die Autoren der ursprünglichen Arbeit hatten diese Instanz für Testzwecke bereitgestellt. In einigen Stunden war die Key-Recovery abgeschlossen. Für die echten Parameter würde der Angriff ebenfalls funktionieren, aber deutlich langsamer – nicht praktikabel, aber nah genug, um das Sicherheitsniveau massiv zu senken. Die Folge: HAWK wird vermutlich nicht standardisiert, da es seinen Hauptvorteil – die Effizienz – verlieren würde, wenn man die Schlüsselgrößen verdoppelt. Das ist ein echter Erfolg für die KI-gestützte Kryptoanalyse.

Der Angriff auf AES: Weniger spektakulär, aber nicht bedeutungslos

Der zweite Angriff betrifft reduziertes AES. AES ist ein Blockverschlüsselungsstandard, der seit 2001 überall eingesetzt wird. Der vollständige AES läuft über 10, 12 oder 14 Runden – je nach Schlüssellänge. Der neue Angriff von Anthropic attackiert eine abgeschwächte Version mit nur 7 Runden. Nüchtern betrachtet: Angriffe auf 7-Runden-AES gibt es schon lange. Der neue Angriff ist eine moderate Verbesserung eines Ergebnisses aus dem Jahr 2013.

Der Autor beschreibt die Zahlen nüchtern: Der Angriff benötigt 2^89 Verschlüsselungsoperationen. Noch unrealistischer ist die Voraussetzung: Man müsste einen legitimen Verschlüssler dazu bringen, 2^105 Verschlüsselungen von ausgewählten Klartexten unter seinem geheimen Schlüssel zu erzeugen. Beides ist in der Praxis völlig unmöglich. Der angebliche Geschwindigkeitsvorteil ist nur auf dem Papier nachweisbar – ob der Angriff tatsächlich schneller laufen würde, ist unklar.

Trotzdem ist das Ergebnis nicht wertlos. Aus wissenschaftlicher Sicht ist jeder Fortschritt, so klein er auch ist, interessant. Der Autor betont: Dies ist ein kleiner Schritt im Verständnis der AES-Struktur, aber kein praktischer Durchbruch. Der eigentliche Wert liegt in der Methodik: KI-Modelle können subtile Verbesserungen an etablierten Angriffen finden, selbst wenn diese marginal sind.

Wie Anthropic zu diesen Ergebnissen kam

Der Blogbeitrag gibt einen erstaunlich transparenten Einblick in den Forschungsprozess. Und der ist, wie der Autor schreibt, „irgendwie witzig“. Es war kein Team von Krypto-Experten, das monatelang das Modell feinjustierte. Stattdessen gaben sie der KI einfache Anweisungen wie: „Finde einen Angriff auf HAWK.“ Dann ließen sie sie arbeiten. Die Prompts waren extrem simpel – fast so, als würde man einem Praktikanten sagen: „Geh und mach was Nützliches.“

Der Autor zitiert einige Prompts aus dem Anthropic-Blog: Bilder von Instruktionen, die im Grunde besagen: „Hier ist die Spezifikation, hier sind die bekannten Techniken – finde einen Angriff.“ Und das Modell lieferte. Es verstand die existierenden Resultate, synthetisierte sie und erweiterte sie zu neuen Angriffen. Ohne detaillierte menschliche Anleitung. Das ist beeindruckend, auch wenn es noch keine Superintelligenz ist. Es zeigt aber: KI kann echte kryptanalytische Arbeit leisten – Arbeit, die bisher nur hochspezialisierten Wissenschaftlern vorbehalten war.

Das Problem der Verifizierbarkeit

Der Autor hat als Forscher selbst Erfahrung mit KI-Modellen. Er berichtet, dass er in den letzten Monaten immer wieder überraschende „Ergebnisse“ von Modellen bekommen hat. Aber dann kommt die Ernüchterung: Nur weil ein Modell ein Ergebnis ausspuckt, heißt das nicht, dass es korrekt ist. KI-Modelle sind hervorragend darin, Ergebnisse zu produzieren, die echt aussehen, aber in die Irre führen. Das ist ein wachsendes Problem.

Für Angriffe wie den auf HAWK ist die Verifikation einfach: Man kann den Code ausführen und prüfen, ob er Schlüssel wiederherstellt. Für subtilere Verbesserungen, wie beim AES-Angriff, ist das schwieriger. Formale Beweise in Lean können helfen, aber solche Beweise hängen davon ab, wie die Theoremaussage formuliert ist. Das erfordert menschliche Experten. Der Autor prognostiziert, dass dieser Bedarf an menschlicher Prüfung den Fortschritt verlangsamen wird – zumindest solange die KI nicht ihre eigenen Beweise überprüfen kann.

Was bedeutet das für die reale Welt?

Die Antwort hängt davon ab, wen man fragt. Für die Nutzer von Kryptografie gibt es zwei gute Nachrichten und eine gemischte. Erstens: Symmetrische Chiffren wie AES sind extrem robust. Der Autor vergleicht sie mit einem Bauern, der einen Traktor in Treibsand zieht und dann mit Zement bedeckt. Die Struktur ist absichtlich chaotisch und schwer zu entwirren. KI mag viele Rechenstunden haben, aber ihr fehlt die revolutionäre Intuition, um solche Systeme grundlegend zu brechen. Und selbst wenn sie diese Intuition entwickelt, könnte sie gleichzeitig bessere Chiffren entwerfen.

Die zweite gute Nachricht: Wir befinden uns mitten in einem historischen Übergang von traditionellen Public-Key-Verfahren wie RSA und ECC hin zu Post-Quanten-Verfahren. Es gibt viele Standards in der Entwicklung – genau der perfekte Zeitpunkt für eine massive neue Kryptoanalyse-Fähigkeit. Wenn KI Schwachstellen in diesen neuen Verfahren findet, können wir sie beheben, bevor sie eingesetzt werden. Im besten Fall gewinnen wir echtes Vertrauen in die Sicherheit dieser Verfahren.

Die gemischte Nachricht betrifft die Public-Key-Kryptografie selbst. Diese basiert auf wenigen, sorgfältig konstruierten mathematischen Problemen. Es gab nie genügend menschliche Forscher, um alle möglichen Angriffe auszuschöpfen. Hier bietet sich viel Raum für KI, um neue Schwachstellen zu entdecken. Das ist beunruhigend, aber auch eine Chance: Wenn KI diese Schwachstellen findet, bevor sie ausgenutzt werden, sind wir besser geschützt.

Für Wissenschaftler ist die Lage eher aufregend. Sie haben nun einen „plastischen Kollegen“ – einen, der über Probleme diskutieren kann, aber noch nicht schlauer ist als sie. Das beschleunigt die Forschung. Offene Fragen bleiben: Wer bekommt die Anerkennung für KI-generierte Resultate? Und wer wird all diese neuen Ergebnisse überprüfen? Der Autor zeigt sich noch nicht alarmiert, aber er warnt: Wer denkt, KI sei nur ein „verherrlichtes Autocomplete“ oder dass der Fortschritt nachlasse, irrt gewaltig.

Abschließend eine ernüchternde Einsicht: Die Ergebnisse von Anthropic sind kein Grund zur Panik, aber ein Weckruf. Sie zeigen, dass KI echte kryptanalytische Arbeit leisten kann – Arbeit, die bisher hochspezialisierten Experten vorbehalten war. Der Autor selbst ist beeindruckt, aber auch nachdenklich. Die kommenden Jahre werden entscheiden, ob KI die Kryptografie revolutioniert oder ob wir sie kontrollieren können. Die Zeit, in der wir uns auf die Langsamkeit menschlicher Forschung verlassen konnten, ist vorbei.

Für alle, die sich fragen, ob sie ihr Bitcoin-Wallet leeren sollten: Der Autor beruhigt. Der HAWK-Angriff betrifft ein nicht standardisiertes Verfahren. AES bleibt für alle praktischen Zwecke sicher. Die eigentliche Botschaft ist eine andere: Wir müssen umdenken. Kryptoanalyse wird schneller, automatisierter und umfassender. Das ist, wenn man genau hinschaut, eher eine Chance. Denn wenn KI die Löcher findet, können wir sie stopfen – bevor die Bösen es tun.

Quelle: blog.cryptographyengineering.com

Canva betreibt eine Online-Plattform mit Hunderten Millionen Nutzern. Hunderttausende Anfragen pro Sekunde. Jede muss prüfen: Wer ist der Nutzer? Darf er das? Das Team stand vor der Aufgabe, die Sitzungsverwaltung zu verbessern. Normalerweise würde man bei jedem Request in einer Datenbank nachschlagen – zu langsam und teuer. Canva setzt auf verschlüsselte Browser-Cookies mit allen Sitzungsinformationen: User-ID, Berechtigungen, Rollen. Die Gateways entschlüsseln diese Cookies und prüfen die Legitimität sofort, ohne einen Netzwerkservice zu fragen.

Das Problem: Wenn Sitzungen ungültig werden

Was passiert bei Abmeldung oder Rechteänderung? Alte Cookies müssen in Echtzeit ungültig werden. Canva speichert widerrufene Sitzungen (Revocations) im Arbeitsspeicher der Gateways. Das ist schnell und zuverlässig. Der Haken: Bei jedem Deployment starten Hunderte Gateway-Instanzen neu. Jede lädt alle Revocations aus der MySQL-Datenbank. Das führte zu einer Stampede – Millionen Abfragen pro Instanz. Der Datenbankcluster ächzte unter der Last. Read-Replicas halfen kurzfristig, aber nicht nachhaltig.

Die Idee: S3 als Zwischenspeicher

Die Ingenieure Joeby Neil und Martin Doms suchten eine Lösung, die das Deployment nicht verlangsamt und die Datenbank schont. Ein Zwischenspeicher wie Redis wäre naheliegend, aber Redis ist nicht vollständig dauerhaft. Die Konsistenzprobleme hätten sich nur verschoben. Sie wählten Amazon S3. S3 eignet sich für günstige, schnelle Downloads großer, dauerhafter Dateien. Das Problem: Revocations sind kein statischer Block, sondern ein gleitendes Fenster von 12 Stunden (Cookies erneuern sich regelmäßig). Wie lässt sich ein dynamisches Fenster in S3 abbilden?

30-Minuten-Blöcke als Bausteine

Die Lösung: Sie teilten das 12-Stunden-Fenster in 30-Minuten-Blöcke auf. Jeder Block ist ein separates S3-Objekt. Der Dateiname enthält den Startzeitstempel. Ein Gateway lädt beim Start nur die jüngsten 24 Blöcke herunter – insgesamt wenige Dutzend Megabyte pro Instanz. Jede Revocation ist ein binärer Eintrag von 16 Bytes: 8 Bytes für die Nutzerkennung (Principal), 8 Bytes für den Zeitstempel der Gültigkeit. Dank Sortierung und binärer Suche finden die Gateways Revocations extrem schnell, ohne Java-Objekte zu erzeugen. Speicherverbrauch sank um 87,5 Prozent gegenüber dem alten System.

Die Herausforderung: Aktualisierung der Blöcke

Wie hält man die S3-Blöcke aktuell, ohne bei jeder neuen Revocation den gesamten Block neu zu schreiben? Canva nutzt einen asynchronen Worker, der regelmäßig die Datenbank abfragt, den passenden Block aus S3 lädt, neue Einträge in das sortierte Array einfügt und ihn wieder hochlädt. Mehrere Worker laufen parallel, um Ausfälle zu überbrücken. Das kann zu Datenkonflikten führen. Sie verwenden bedingte PUT-Requests (Conditional PUT) von S3: Vor dem Schreiben prüfen sie, ob sich der Block seit dem Lesen geändert hat. Falls ja, wiederholen sie die Operation. Zusätzlich sorgt ZooKeeper für eine Leader Election, um unnötige Konflikte zu minimieren.

Theoretisch ist die Skalierung problematisch: Jede Batch-Hinzufügung sortiert den gesamten Block – O(N²). In der Praxis arbeiten sie mit Batches von mehreren Hundert Revocations und erreichen über 2000 Schreiboperationen pro Sekunde. Das reicht. Moderne CPUs verarbeiten dichte Arrays so effizient, dass die Netzwerklatenz der Flaschenhals ist, nicht die Sortierung.

Der Effekt: Schnellere Deployments, weniger Datenbanklast

Seit der Umstellung hat Canva die Read-Replicas für die Session-Revocation-Datenbank auf zwei reduziert. Deployments laufen schneller. Gateways streamen Revocations direkt aus S3, statt die Datenbank zu überlasten. Die Systemlast skaliert vorhersagbar mit Schreibrate und Traffic, nicht mit der Anzahl der Gateway-Neustarts.

Das Projekt zeigt: Scheinbar ineffiziente Ansätze können in der Praxis die besten sein. Ein einzelner Worker sortiert Hunderttausende Datensätze immer wieder – klingt nach Verschwendung. Wegen der kompakten Daten und schnellen Rechner ist es die einfachste und stabilste Lösung. Canva testete mehrere Ansätze auf echter Infrastruktur und wählte den pragmatischsten.

Quelle: canva.dev