# Vorschau des CDN-Bereinigungsumfangs für KI-Agenten Ein KI-Agent sollte niemals um Freigabe bitten, „den CDN-Cache zu leeren“. Dieser Satz verbirgt genau die Angaben, die ein Betreiber vor der Genehmigung braucht: welcher Host, welcher Pfad, wie viele Tags und wie viel zwischengespeicherter Inhalt möglicherweise nicht mehr ausgeliefert wird. Eine brauchbare Vorschau des CDN-Bereinigungsumfangs fasst den Wirkungsradius der endgültigen Anfrage kompakt zusammen. Sie muss eine gezielte Invalidierung außerdem einer anderen Risikoklasse zuordnen als eine vollständige Bereinigung. Ich habe erlebt, wie eine breite Bereinigung eine gewöhnliche Veröffentlichung in einen Lastvorfall am Ursprung verwandelte, weil der Freigabedialog einen Platzhalter wie einen harmlosen Pfad aussehen ließ. Die Anfrage war syntaktisch klein. Ihre Wirkung war es nicht. Die richtige Gestaltung fügt nicht bloß ein Bestätigungsfeld hinzu. Sie normalisiert die Anbieteranfrage, klassifiziert deren Umfang, schätzt die Reichweite mit ehrlicher Unsicherheit und bindet die Freigabe des Betreibers an genau diese Parameter. Ändert der Agent nach der Freigabe einen Host, Pfad, Tag, eine Umgebung oder den Bereinigungsmodus, muss das Gateway erneut fragen. ## Eine Bereinigungsanfrage braucht ein Wirkungsmodell Der CDN-Bereinigungsumfang umfasst die zwischengespeicherten Repräsentationen, die ein Anbieter invalidieren kann, nicht die Anzahl der Zeichenketten in einer API-Anfrage. Ein Platzhalter kann eine ganze Distribution abdecken. Ein Tag kann auf Tausende voneinander unabhängige URLs verweisen. Eine URL kann mehrere Cache-Varianten haben, weil der Cache nach Abfrageparametern, Headern, Cookies, Gerätetyp oder Sprache unterscheidet. Diese erste Unterscheidung wird in Teams häufig verwischt: Anfragegröße ist nicht Wirkungsgröße. Die Dokumentation von Amazon CloudFront macht das Missverhältnis ausdrücklich deutlich. Ein Invalidierungspfad mit Platzhalter zählt als ein eingereichter Pfad, selbst wenn er Tausende Dateien invalidiert. Abrechnungseinheiten beschreiben die Anfrage, nicht ihre Reichweite. Eine Freigabekarte mit „1 Pfad“, die `/*` verschweigt, zeigt eine technisch korrekte, betrieblich aber nutzlose Angabe. Modellieren Sie die vorgeschlagene Aktion entlang von vier Achsen: - **Ziel:** CDN-Konto, Dienst oder Distribution, Umgebung und Hostname. - **Selektor:** genaue URL, Pfadpräfix, Platzhalter, Cache-Tag, Surrogate Key oder anbieterweiter Schalter für die vollständige Bereinigung. - **Semantik:** wie Selektoren verknüpft werden, welche Varianten sie erfassen und ob der Anbieter Cache-Objekte invalidiert oder löscht. - **Folge:** geschätzte Anzahl betroffener Objekte oder Anfragen, erwartetes Wiederbefüllen und die Frage, ob veralteter Inhalt weiter ausgeliefert werden kann. Das Modell gehört in das Ausführungs-Gateway, nahe an Zugangsdaten und Anbieteradapter. Lassen Sie den Agenten nicht seine eigene Risikoklasse festlegen. Der Agent kann eine Bereinigung vorschlagen, aber Code mit Kenntnis der Anbieter-API muss berechnen, was dieser Vorschlag bedeutet. Diese Trennung ist nötig, weil Anbieter unterschiedliche Begriffe verwenden. Fastly nennt seine Gruppierungsmarke Surrogate Key. Google Cloud und Akamai sprechen von Cache-Tags. Cloudflare unterstützt Tags, Hostnamen, URL-Präfixe, einzelne Dateien und die vollständige Bereinigung. CloudFront unterstützt Pfade, Platzhalter und Invalidierung mit Cache-Tags. Ein übertragbares Agentenwerkzeug kann eine übersichtliche Oberfläche anbieten, doch die Vorschau muss die tatsächlichen Abgleichsregeln des Anbieters bewahren. Bevor eine Ausführungskomponente etwas anzeigt, sollte sie Aliasse auflösen, Hosts kanonisieren, Pfade nach den Anbieterregeln dekodieren und normalisieren, Komfortoptionen erweitern und die tatsächliche Umgebung bestimmen. Die Vorschau beschreibt anschließend die Anfrage, die signiert und gesendet wird. Wer die frühere, freundlichere Eingabe des Agenten zeigt, lässt eine Lücke, in der die Normalisierung den Umfang unbemerkt erweitern kann. ## Gezielte Invalidierung und vollständige Bereinigung sind getrennte Aktionen Eine gezielte Invalidierung wählt Inhalte über eine genaue URL, einen begrenzten Pfad oder ein Präfix, einen oder mehrere Tags oder eine Schnittmenge unterstützter Selektoren aus. Eine vollständige Bereinigung verwirft den nutzbaren Zustand eines gesamten Dienstes, einer Zone oder einer Distribution. Beide als zwei Werte derselben Auswahlliste zu behandeln, spielt den Unterschied herunter. Die Klassifizierung muss der Wirkung folgen, nicht dem Namen des Endpunkts. Alle folgenden Anfragen verdienen die Kennzeichnung als vollständige Bereinigung: - Der ausdrückliche Anbieterschalter `purge_everything`. - Ein Distributionspfad `/*`. - Ein Platzhalter oder Präfix, der nach der Normalisierung die Wurzel abdeckt. - Ein Tag, der gemäß lokaler Konvention jede Antwort eines Dienstes markiert. - Eine Liste von Selektoren, deren Vereinigungsmenge alle konfigurierten Hosts umfasst. Die letzten beiden Fälle benötigen lokale Metadaten. Ein Anbieter weiß möglicherweise nicht, dass `release-current` an jedem Objekt eines Dienstes steht. Das Bereitstellungssystem, das den Tag setzt, kann diese Tatsache jedoch festhalten. Kann das Gateway nicht belegen, dass ein Selektor begrenzt ist, sollte es die Reichweite als unbekannt markieren und die Freigabestufe erhöhen. Unbekannt ist ein gültiges Ergebnis. Unbekannt stillschweigend als klein zu behandeln, ist keines. Gezielt bedeutet nicht sicher. Das Präfix `/products/` eines großen Shops kann den größten Teil des Verkehrs abdecken, und ein Tag `tenant:42` kann über mehrere Hosts reichen. Die Bezeichnung bedeutet lediglich, dass die Anfrage eine Grenze ausdrückt, die die Vorschau zeigen kann. Der Betreiber braucht weiterhin eine Schätzung dessen, was innerhalb dieser Grenze liegt. Für eine vollständige Bereinigung ist ein visuell und technisch getrennter Ablauf nötig. Verlangen Sie einen ausdrücklichen Aktionsnamen wie `purge_all`, nicht einen leeren Selektor, den der Adapter als alles interpretiert. Lehnen Sie im gezielten Modus leere Host- und Pfadfelder ab. Der Betreiber muss die Produktionsumgebung und den ganzen benannten Dienst als Ziele bestätigen. Eine allgemeine Sitzungsfreigabe darf diese Aktion nicht mit abdecken, nur weil derselbe Agent zuvor eine harmlose URL-Bereinigung vorgenommen hat. An dieser Stelle widerspreche ich einem verbreiteten Rat: „Verlange einfach für jede Bereinigung eine Bestätigung.“ Wiederholung trainiert Menschen darauf, die Form eines Dialogs zu bestätigen, statt dessen Inhalt zu lesen. Eine Invalidierung einer einzelnen Datei während einer Veröffentlichung und die Bereinigung einer ganzen Distribution dürfen nicht dieselbe Schaltfläche, Warnung oder Authentifizierungsstufe zeigen. Menschliche Freigabe hilft nur, wenn die Oberfläche den wesentlichen Unterschied sichtbar macht. ## Host, Pfad und Tag-Anzahl gehören über die Schaltfläche Die Freigabekarte sollte mit dem tatsächlichen Ziel und Umfang beginnen, denn Betreiber lesen unter Zeitdruck. Zeigen Sie zuerst Anbieter und Produktionsumgebung, dann Hostname, normalisierten Pfad, Tag-Anzahl, geschätzte Reichweite und Aktionsklasse. Unterstützende Details können darunter aufklappbar sein, aber entscheidungsrelevante Angaben müssen ohne Klick sichtbar bleiben. Eine anbieterneutrale Vorschau kann so aussehen: ```json { "operation": "targeted_invalidation", "provider": "example-cdn", "environment": "production", "hosts": ["assets.example.test"], "paths": ["/releases/2026-07-24/*"], "tag_count": 2, "tag_samples": ["release:842", "asset:bundle"], "selector_logic": "host AND path AND (tag OR tag)", "estimated_reach": { "objects": {"low": 1600, "high": 2300}, "method": "tag-index snapshot", "observed_at": "2026-07-24T14:31:08Z" }, "refill": "origin requests expected on subsequent misses" } ``` Diese Zahlen dienen nur als Beispiel und versprechen nicht, dass ein CDN jedes aktive Edge-Objekt zählen kann. Wichtig ist die Ausgabeform: ein Bereich, seine Methode und der Beobachtungszeitpunkt. Fehlen dem Schätzer belastbare Daten, geben Sie `"objects": "unknown"` zurück und nennen Sie den Grund. Zeigen Sie alle Hosts, wenn es nur wenige sind. Bei einer langen Liste zeigen Sie die Anzahl und die ersten sortierten Namen zusammen mit einer eindeutigen Möglichkeit, den Rest einzusehen. Fassen Sie eine gemischte Produktions- und Staging-Liste niemals als „12 Hosts“ zusammen. Umgebungsgrenzen wiegen bei der Entscheidung schwerer als die Anzahl. Pfade brauchen sowohl den normalisierten Wert als auch die Abgleichsregel. `/picture*` und `/picture/*` sind in Google Cloud CDN nicht derselbe Selektor: Der erste erfasst auch Pfade wie `/pictures/dog.jpg` und `/picture1.jpg`, während der zweite unterhalb des Verzeichnisses bleibt. CloudFront verlangt den Platzhalter am Ende, damit er als Platzhalter wirkt; ein Sternchen an anderer Stelle ist ein gewöhnliches Zeichen. Eine Vorschau, die nur die Rohzeichen zeigt, zwingt den Betreiber im ungünstigsten Moment dazu, sich an die Anbietergrammatik zu erinnern. Auch die Tag-Anzahl braucht eine sorgfältige Formulierung. „2 Tags“ bedeutet zwei Selektoren, nicht zwei Cache-Objekte. Zeigen Sie die tatsächlichen Tags, solange sie keine sensiblen Mandantendaten enthalten. Andernfalls zeigen Sie beständige maskierte Bezeichnungen und eine sichere Detailansicht. Geben Sie an, ob Tags mit OR oder AND verknüpft werden. Google Cloud CDN behandelt mehrere Tags in einer Anfrage als OR, während zusätzliche Host- und Pfadfilter das Ergebnis durch eine Schnittmenge einschränken. Diese kurze Logikzeile erklärt oft den größten Teil des Wirkungsradius. ## Die geschätzte Reichweite muss Zählgrenzen des CDN anerkennen Eine Reichweitenschätzung sollte beantworten, wie viel Cache-Zustand sich ändern könnte, ohne einen verteilten Cache als Bestandsdatenbank darzustellen. Edge-Objekte erscheinen und verschwinden durch Ablauf, Verdrängung, regionale Nachfrage und Hintergrundbefüllung. Viele CDN-Bereinigungs-APIs akzeptieren einen Selektor, liefern aber keine Vorabanzahl. Nutzen Sie die besten verfügbaren Belege in einer festen Reihenfolge. Eine aktuelle Anbieterzahl ist am stärksten, wenn die API eine anbietet. Danach folgt ein vom Bereitstellungssystem geführter Tag-Index, der erfasst, welche URLs welchen Tag erhielten. Anschließend eignen sich Anfrageprotokolle oder Cache-Status-Telemetrie über ein angegebenes Zeitfenster. Ein Katalog konfigurierter Routen kann eine grobe Obergrenze liefern. Gibt es nichts davon, melden Sie unbekannt. Jede Schätzung sollte vier Eigenschaften tragen: - Eine Einheit wie Cache-Objekte, URL-Varianten oder jüngste Anfragen mit Cache-Treffer. - Einen Punktwert oder Bereich, nie eine unbeschriftete Ganzzahl. - Eine Quelle und einen Beobachtungszeitpunkt. - Eine vom Code aus Quellentyp und Alter abgeleitete Vertrauensstufe. Wandeln Sie das jüngste Anfragevolumen nicht in eine Objektzahl um. „Etwa 80.000 Cache-Treffer in der letzten Stunde passten zu diesem Präfix“ ist eine nützliche Auswirkungsangabe, bedeutet aber nicht, dass 80.000 Objekte invalidiert werden. Zeigen Sie beide Messwerte, wenn möglich: Die geschätzten Objekte beschreiben den Cache-Zustand, die jüngsten Treffer die wahrscheinliche Wiederbefüllungslast und die Betroffenheit von Nutzern. Selbst bei einer genauen URL kann die Reichweite größer als eins sein. Laut CloudFront-Dokumentation invalidiert die Invalidierung einer Datei auch Cache-Varianten, die auf weitergeleiteten Cookies oder Headern beruhen. Das Verhalten von Abfrageparametern hängt von Konfiguration und Selektor ab. Die Vorschau sollte „1 URL, alle Cookie- und Header-Varianten“ sagen, wenn dies das tatsächliche Verhalten ist. Eine bloße Objektzahl von eins würde den wichtigen Teil verschweigen. Schätzen Sie bei Tags die Vereinigungsmenge, nicht die Summe. Wenn `release:842` 1.700 Objekte und `asset:bundle` 900 Objekte umfasst, dürfen Überschneidungen nur einmal zählen. Verknüpft der Anbieter Tags mit OR, kann die Addition beider Zahlen die Reichweite überzeichnen. Für einen Freigabeschwellwert ist Überschätzung sicherer als Unterschätzung, doch sie schadet trotzdem dem Vertrauen. Berechnen Sie eine echte Vereinigung, wenn der lokale Index dies erlaubt, oder kennzeichnen Sie die Summe als Obergrenze. Verschwenden Sie bei einer vollständigen Bereinigung keine Zeit mit einer künstlich genauen Zahl. Schreiben Sie „gesamter Produktionsdienst“, zeigen Sie die Anzahl konfigurierter Hosts und ergänzen Sie das jüngste Cache-Treffer-Volumen als Hinweis auf die Ursprungslast. Die Aktionsklasse nennt dem Betreiber bereits die Cache-Grenze. Scheingenauigkeit lässt die Karte informiert wirken, ohne der Entscheidung zu helfen. ## Die Vorschau muss Folgen der Wiederbefüllung zeigen Eine Bereinigung ändert das Ziel nachfolgender Anfragen. Deshalb muss die Freigabe neben dem Selektor auch das Wiederbefüllungsverhalten beschreiben. Das betriebliche Risiko ist oft nicht das Verschwinden veralteter Inhalte. Es ist eine konzentrierte Welle von Cache-Fehlschlägen, die einen Ursprung erreicht, dessen Kapazität unter der Annahme bemessen wurde, dass der Cache die Anfragen auffängt. Die Google Cloud-Dokumentation empfiehlt, nur das Nötige zu invalidieren, weil eine zu breite Invalidierung zuvor vom Cache bediente Anfragen zurück an Instanzen oder Buckets schicken kann. Sie fordert außerdem, vor der Invalidierung zu prüfen, ob der Ursprung bereits den richtigen Inhalt liefert. Sonst kann das CDN die falsche Antwort erneut speichern. Dieser zweite Punkt gehört als Vorbedingung in den Agentenablauf: Prüfen Sie das neue Objekt am Ursprung, bevor die Bereinigung vorgeschlagen wird. Fastly unterscheidet außerdem sinnvoll zwischen harter und weicher Bereinigung. Eine harte Bereinigung macht den Cache-Inhalt für künftige Abfragen unbrauchbar. Eine weiche Bereinigung markiert ihn als veraltet, sodass er abhängig von der Konfiguration während der erneuten Prüfung weiter ausgeliefert werden kann. Fastly bietet keine weiche vollständige Bereinigung an. Eine Freigabe mit dem bloßen Wort „bereinigen“ verwirft diesen betrieblichen Unterschied. Die Vorschau sollte daher Folgendes enthalten: - Ob die Aktion eine harte Invalidierung, weiche Invalidierung oder anbieterspezifische Löschung ist. - Ob veraltete Inhalte während der Aktualisierung ausgeliefert werden können. - Die aktuelle Rate von Cache-Treffer-Anfragen im gewählten Umfang, falls verfügbar. - Den Ursprung oder die Backend-Gruppe, die Fehlschläge empfangen wird. - Ob und wann eine Bereitschaftsprüfung des Ursprungs erfolgreich war. Vermeiden Sie Versprechen wie „2.300 Anfragen werden den Ursprung erreichen“. Anfragebündelung, regionale Verteilung, Browser-Caches, Shielding und frische Befüllungen beeinflussen die tatsächliche Last. Nutzen Sie gemessenen aktuellen Verkehr und beschreiben Sie ihn ehrlich: „Der gewählte Umfang lieferte in den vergangenen 15 Minuten 46.000 Cache-Treffer aus.“ Das hilft einem Betreiber mehr als eine erfundene Prognose. Der Agent sollte seine Bereitschaftsprüfung nicht über eine uneingeschränkte Shell ausführen und das Ergebnis zusammenfassen. Das Gateway sollte eine definierte Prüfung gegen den vorgesehenen Ursprung durchführen, Antwortstatus und Inhaltsversion aufzeichnen und diese Belege an die Vorschau anhängen. Andernfalls kann eine kompromittierte Anweisung im selben Gespräch die Bereitschaft behaupten und die Freigabe verlangen. ## Normalisierung schließt die Lücke zwischen Anzeige und Ausführung Das Gateway muss eine kanonische Aktion genehmigen und genau diese Aktion ausführen. Wenn die Oberfläche eine Darstellung zeigt, während der Anbieteradapter eine andere sendet, ist die Freigabe nur Theater. Die Kanonisierung beginnt mit typisierten Feldern. Trennen Sie `hosts`, `paths`, `tags`, `purge_all`, `soft`, `provider`, `service_id` und `environment`. Akzeptieren Sie keinen frei formulierten curl-Befehl als Freigabeobjekt. Der Adapter erzeugt am Ende möglicherweise HTTP, doch Richtlinien- und Anzeigecode sollten mit geprüften Daten arbeiten. Wenden Sie vor der Klassifizierung die Anbieterregeln an. Schreiben Sie Hostnamen klein, entfernen Sie einen abschließenden DNS-Punkt, lehnen Sie eingebettete Zugangsdaten ab, lösen Sie den Dienstalias auf und parsen Sie Pfade, ohne ein Fragment als Teil der Anfrage zu behandeln. Bewahren Sie die Groß- und Kleinschreibung des Pfades, wenn das CDN sie unterscheidet. Nutzen Sie dieselbe URL-Normalisierung und Kenntnis von Umschreibungen wie der Anbieter. Cloudflare warnt, dass Präfixbereinigungen mit Transform Rules die transformierte Ursprungs-URL benötigen. CloudFront empfiehlt, bei einer Pfadänderung durch eine Viewer-Request-Funktion sowohl die Nutzer-URI als auch die umgeschriebene URI zu invalidieren. Die Vorschau sollte beide wirksamen Pfade zeigen, statt den zweiten still hinzuzufügen. Eine kompakte Klassifizierungsfunktion kann die gefährlichen Fälle nach der Normalisierung erzwingen: ```text if purge_all is true: return PURGE_ALL if any normalized path covers the root: return PURGE_ALL if any tag is cataloged as service_wide: return PURGE_ALL if selectors are empty: return REJECT return TARGETED ``` Anbieteradapter brauchen Tests aus ihrer eigenen Grammatik. Berücksichtigen Sie Wurzelpfade, kodierte Trennzeichen, wiederholte und abschließende Schrägstriche, Platzhalterpositionen, leere Arrays, gemischte Hosts, Abfrageparameter und umgeschriebene URLs. Eigenschaftstests können sicherstellen, dass die Normalisierung den Ausführungsumfang nie über den angezeigten Umfang hinaus erweitert. Regressionsfälle sollten die normalisierte Vorschau neben der exakten ausgehenden Anfrage speichern. Berechnen Sie schließlich einen Digest über die kanonische Aktion und die für die Vorschau entscheidenden Metadaten. Der Freigabedatensatz sollte Akteur, Agentenprozess, Werkzeugname, normalisierte Parameter, Umgebung, Schätzzeitpunkt, Digest und Ablaufzeit enthalten. Das AI Agent Security Cheat Sheet von OWASP empfiehlt, die Freigabe mit Akteur, Werkzeug, Ziel, normalisierten Parametern, Zeitpunkt und Ablauf an die genaue Aktion zu binden. Das ist der richtige Maßstab. Eine menschliche Entscheidung über einen Digest darf keine spätere Anfrage mit einem anderen Pfad genehmigen. ## Bei verändertem Umfang muss die Freigabe geschlossen scheitern Jede wesentliche Änderung nach der Vorschau muss die Freigabe ungültig machen. Wesentliche Felder sind Anbieter, Konto, Dienst, Umgebung, Host, Pfad, Selektorlogik, Tags, Bereinigungsmodus und die Klasse als gezielte oder vollständige Bereinigung. Eine reine Änderung der Schätzung muss nicht immer eine neue Abfrage auslösen, das Überschreiten eines konfigurierten Wirkungsschwellwerts aber schon. Geben Sie der Freigabe eine kurze Lebensdauer, weil sich Cache-Zustand und Verkehr ändern. Wartet ein Agent bis nach einer weiteren Bereitstellung, kann der Pfad andere Objekte enthalten und der Beleg über die Ursprungsbereitschaft veraltet sein. Der Ablauf sollte eine neue Vorschau erzwingen, nicht bloß einen weiteren Klick auf alte Daten. Die Werkzeugspezifikation des Model Context Protocol besagt, dass Anwendungen einem Menschen die Ablehnung von Werkzeugaufrufen ermöglichen und Bestätigungsaufforderungen zeigen sollten. Das ist sinnvoll, doch eine allgemeine Bestätigung reicht für zerstörerische Infrastrukturaufrufe nicht aus. Die Host-Anwendung kennt vielleicht Werkzeugname und JSON-Argumente. Nur der Ausführungsadapter weiß jedoch, dass ein Anbieteralias auf Produktion verweist oder `/` mit Platzhalter alles bedeutet. Die aussagekräftige Vorschau gehört in die Komponente, die diese Tatsachen auslegen und durchsetzen kann. Die Freigabe muss außerdem unabhängig von agentengesteuertem Text sein. Der Agent kann eine Begründung wie „das zurückgerufene Produktbild entfernen“ angeben, doch zeigen Sie sie in einem nachrangigen Bereich mit eindeutiger Kennzeichnung als Agentenerklärung. Erzeugen Sie die Umfangsangaben aus vertrauenswürdigem Code und der Anbieterkonfiguration. Lassen Sie in keinem Feld der Freigabekarte Markdown, Terminal-Steuersequenzen oder beliebiges HTML zu. Aktionen mit großer Wirkung verdienen mehr Reibung. Eine gezielte Bereinigung einer genauen URL kann einen Klick verlangen. Ein breites Präfix kann eine bewusste Bestätigung mit wiederholtem Umfang fordern. Die vollständige Bereinigung sollte eine getrennte Authentifizierung verlangen und die Freigabe nicht aus der Agentensitzung erben. Sallyport kann Zugangsdaten vom Agenten fernhalten, bei jeder Nutzung eines geschützten CDN-API-Schlüssels eine Freigabe zeigen und den resultierenden HTTP-Aufruf protokollieren; der Anbieteradapter muss trotzdem die normalisierten Umfangsfelder liefern, die diese Freigabe aussagekräftig machen. Fehler müssen das Tor schließen. Läuft die Schätzung in einen Timeout, zeigen Sie unbekannt statt null. Schlägt die Normalisierung fehl, lehnen Sie ab, statt die Roheingabe durchzureichen. Schlägt die Audit-Protokollierung fehl, führen Sie nichts aus. Weicht der Digest beim Senden ab, verwerfen Sie die Freigabe und erzeugen Sie eine neue Vorschau. ## Audit-Datensätze brauchen Entscheidung und Ergebnis Eine Audit-Spur der Bereinigung sollte bewahren, was der Mensch sah, was das Gateway sendete und was das CDN zurückgab. Nur die Werkzeuganfrage des Agenten zu protokollieren, beweist nicht, dass Normalisierung, Freigabe und Ausführung denselben Umfang betrafen. Speichern Sie die kanonische Anfrage, die dargestellten Vorschaufelder, die Quelle der Schätzung, den Freigabe-Digest, die Identität der genehmigenden Person, den Freigabezeitpunkt, den Ausführungszeitpunkt, die Anfragekennung des Anbieters und dessen Antwort. Markieren Sie, ob der Anbieter die Aktion annahm, abschloss, teilweise abschloss oder ablehnte. Stellt der Anbieter später Statusdaten bereit, hängen Sie Beobachtungen an, statt das ursprüngliche Ereignis umzuschreiben. Halten Sie Schätzung und Ergebnis getrennt. Eine Schätzung von 2.000 Objekten bleibt eine Schätzung, auch wenn der Anbieter Erfolg meldet. Die meisten Erfolgsantworten bedeuten, dass der Anbieter einen Selektor angenommen hat, nicht dass er genau so viele Cache-Objekte gefunden hat. Prüfer müssen unterscheiden können, welche Aussagen aus lokaler Schlussfolgerung und welche vom CDN stammen. Laut CloudFront-Dokumentation lässt sich eine Invalidierung nach dem Absenden nicht abbrechen, weil Edge-Standorte schnell mit ihrer Verarbeitung beginnen. Das macht den Datensatz vor der Ausführung besonders wichtig. Eine Widerrufsschaltfläche kann einen zukünftigen Agentenaufruf verhindern, aber keine bereits an die Edges verteilte Bereinigung zurückholen. Die Audit-Oberfläche darf nichts anderes suggerieren. Für eine Untersuchung sollten sich diese Fragen ohne Chatprotokoll beantworten lassen: - Welcher signierte Agentenprozess schlug die Aktion vor? - Welche Person genehmigte welchen kanonischen Digest? - Stufte die Karte die Aktion als gezielt oder als vollständig ein? - Welche Hosts, Pfade und Tags standen auf der Karte? - Was wusste der Reichweitenschätzer zu diesem Zeitpunkt? Die Gesprächsbegründung des Agenten liefert unterstützenden Kontext, aber keine Autorität. Chats können gekürzt, zusammengefasst oder durch nicht vertrauenswürdige Inhalte beeinflusst werden. Das Ausführungsjournal ist der dauerhafte Datensatz der Aktion. Manipulationsnachweise sind wichtig, wenn ein autonomer Prozess die Infrastruktur wiederholt aufrufen kann. Sallyport zeichnet Agentensitzungen und einzelne Aufrufe aus einem verschlüsselten, hashverketteten Audit-Protokoll auf, sodass ein Team die Kette unabhängig vom Lesen ihres Inhalts prüfen kann. Das macht eine falsche Bereinigung nicht umkehrbar, gibt Einsatzteams aber eine belastbare Abfolge aus Vorschlag, Freigabe und Ausführung. ## Ein durchgespielter Fehler zeigt den Wert von vier Feldern Betrachten wir einen Agenten, der eine Shop-Veröffentlichung vorbereitet. Die Aufgabe verlangt, neue Produktressourcen nach der Bereitstellung zu aktualisieren. Der Agent sieht `/products/` in einem Build-Manifest und wählt eine Präfixbereinigung, weil sie einfacher ist als die Aufzählung gehashter Dateien. Die Rohanfrage enthält einen Pfad. Ein schwacher Dialog zeigt „1 Pfad bereinigen?“, und der Betreiber bestätigt. Das CDN interpretiert das Präfix auf jedem konfigurierten Host, darunter der öffentliche Shop, ein regionaler Host und ein Bild-Host. Die Route enthält außerdem Produktseiten, Vorschaubilder, Bestandsfragmente und Ressourcen älterer Veröffentlichungen. Häufig genutzte Objekte verschwinden gemeinsam aus dem Cache und werden anschließend aus derselben Ursprungsgruppe neu befüllt. Eine brauchbare Vorschau ändert die Entscheidung vor der Ausführung. Sie zeigt: 1. **Host:** drei Produktions-Hosts mit sichtbaren Namen. 2. **Pfad:** `/products/*`, beschrieben als rekursives Präfix statt als einzelne Datei. 3. **Tags:** keine, obwohl die aktuelle Veröffentlichung einen eigenen Tag besitzt. 4. **Geschätzte Reichweite:** 38.000 URL-Varianten und 1,2 Millionen jüngste Cache-Treffer-Anfragen, beide mit Quelle und Zeitfenster. Der Betreiber lehnt die Anfrage ab. Anschließend schlägt der Agent nur den Veröffentlichungs-Tag auf dem Ressourcen-Host vor. Das Gateway ermittelt 1.840 indizierte Objekte, weist auf die OR-Verknüpfung zweier Tag-Werte hin und zeigt, dass die Aktion Produkt-HTML und Bestandsantworten ausschließt. Die Ursprungsprüfung bestätigt die Kennung der aktuellen Veröffentlichung. Der Betreiber genehmigt diesen engeren Digest. Die Zahlen in diesem Szenario sind Beispiele; das Fehlermuster ist verbreitet, weil Präfixsyntax billig aussieht. Die Lösung ist keine klügere Agentenanweisung. Die Ausführungsgrenze muss breite Selektoren verständlich machen und dem Menschen eine engere Alternative anbieten. Dasselbe Muster erkennt einen anderen Fehler: Ein Agent verlangt die Bereinigung von Staging, aber ein Dienstalias wird zu Produktion aufgelöst. Steht in der Vorschau nur „Dienst `storefront`“, kann der Betreiber dies übersehen. Beginnt sie mit „Produktion“ und listet die öffentlichen Hosts auf, ist die Abweichung offensichtlich. Das Beispiel erklärt auch, warum die Tag-Anzahl die Reichweite nicht ersetzen kann. Ein Veröffentlichungs-Tag kann 1.840 Objekte kennzeichnen, während zwanzig Tags für genaue URLs nur zwanzig Objekte bezeichnen. Zeigen Sie Selektoranzahl und geschätzte Treffer als getrennte Angaben. Die eine beschreibt die Anfrage. Die andere beschreibt ihre wahrscheinliche Wirkung. ## Liefern Sie die Sicherheitsgrenze als ausführbaren Vertrag Teams sollten die Bereinigungsvorschau als Vertrag zwischen Agentenwerkzeug, Anbieteradapter, Freigabeoberfläche und Audit-Protokoll umsetzen. Der Vertrag ist klein genug für Tests: Normalisierte Eingaben kommen hinein, eine klassifizierte und Digest-gebundene Vorschau kommt heraus, und die Ausführung akzeptiert nur eine nicht abgelaufene Freigabe für diesen Digest. Verlangen Sie mindestens diese Invarianten: - Der gezielte Modus besitzt mindestens einen Selektor außerhalb der Wurzel und eine ausdrückliche Umgebung. - Der Modus für vollständige Bereinigung verwendet eine eigene Aktion und kann nicht aus leeren Feldern entstehen. - Angezeigter Host, Pfad, Tag-Anzahl und Selektorlogik stammen aus kanonischen Parametern. - Die Reichweite ist ein belegter Bereich, eine Obergrenze, ein Verkehrsmesswert oder ausdrücklich unbekannt. - Die Ausführung berechnet den Digest neu und lehnt veränderte Parameter ab. Führen Sie den Adapter für jede unterstützte CDN-Aktion gegen aufgezeichnete Fälle aus. Vergleichen Sie die ausgehende Anfrage mit dem Vorschau-Schnappschuss. Ergänzen Sie einen Testdienst, dessen Ursprung eine Bereinigung verträgt, und prüfen Sie genaue URL, Präfix, Tag-Vereinigung, Host-Einschränkung, umgeschriebenen Pfad und vollständige Bereinigung. Ein Probelauf, der nur die Agenteneingabe wiederholt, beweist nichts; der Test muss Normalisierung und Aufbau der Anbieteranfrage ausüben. Verwenden Sie versionierte Inhalte als normalen Veröffentlichungsweg. Die Google Cloud-Dokumentation empfiehlt passende Ablaufzeiten oder versionierte URLs anstelle routinemäßiger Invalidierungen, und dieser Rat ist gut. Bereinigungen sind für Korrekturen, Rückrufe und Fälle gedacht, in denen das Warten auf die TTL unvertretbar ist. Ein Agent, der bei jeder Bereitstellung bereinigt, macht aus einem Ausnahmeinstrument eine versteckte Abhängigkeit von der Ursprungskapazität. Ist eine Bereinigung gerechtfertigt, sollte die Vorschau eine schnelle Freigabe ermöglichen. Ein Betreiber muss `assets.example.test`, `/releases/842/*`, zwei Tags und geschätzte 1.600 bis 2.300 Objekte sehen, ohne Anbieter-JSON zu entschlüsseln. Bei einer vollständigen Bereinigung muss an derselben Stelle „gesamter Produktionsdienst“ stehen, ohne diese Aussage durch eine kleine Anfragezahl abzuschwächen. Mein Test ist direkt: Kann ein Betreiber eine einzelne Ressourcenaktualisierung innerhalb von zwei Sekunden von der Bereinigung eines ganzen Dienstes unterscheiden, wenn er nur die vertrauenswürdigen Felder über der Freigabeschaltfläche sieht? Falls nicht, ist der Agent für diese CDN-Aktion noch nicht bereit.