Cloudflare Durable Objects für KI helfen, wenn ein Assistent einen stabilen Ort zur Koordination einer Sitzung oder Aufgabe benötigt. Die schwierige Entwurfsfrage betrifft die Bedeutung dieses Zustands. Gesprächsprotokoll, laufende Aufgabe und freigegebene Geschäftsänderung sollten nicht derselbe Datensatz werden, nur weil sie zu einem Assistenten gehören.
Verwenden Sie Durable Objects zur Koordination klar identifizierter Anwendungszustände. Trennen Sie Gesprächsverlauf, Aufgabenstatus und externe Geschäftsergebnisse. Rekonstruieren Sie Arbeit nach Unterbrechungen aus gespeicherten Nachweisen, prüfen Sie aktuelle Berechtigungen bei Wiederverbindung und trennen Sie Modellkontext vom maßgeblichen Zustand. Dauerhafte Speicherung ist ein Baustein, keine vollständige Wiederherstellungsrichtlinie.
Denken Sie an einen Wartungsassistenten, der einen Servicebericht vorbereitet. Er sammelt Notizen, entwirft eine Empfehlung und wartet auf einen Vorgesetzten. Währenddessen kann der Browser die Verbindung verlieren. Der Vorgesetzte kann die Aufgabe anderswo öffnen und der zugrunde liegende Anlagendatensatz sich vor der Freigabe ändern.
Dieser Leitfaden erklärt dafür einen vorgeschlagenen Zustandsentwurf. Er behauptet weder die notwendige Aufbewahrung jeder Gesprächsnachricht noch die automatische Übereinstimmung einer Objektidentität mit Ihren organisatorischen Zugriffsgrenzen.
Cloudflare Durable Objects für KI brauchen ein Identitätsmodell
Cloudflare beschreibt Durable Objects als Plattform zur Koordination zustandsbehafteter Anwendungen. Definieren Sie vor der Zuordnung zu einer KI-Funktion, was das Objekt darstellt: Gespräch, angenommene Aufgabe, gemeinsame Ressource oder eine andere begrenzte Einheit.
Ein Objekt je Gespräch kann die Interaktion vereinfachen. Ein Servicebericht benötigt womöglich eine Identität über dieses Gespräch hinaus. Arbeiten mehrere Kollegen gemeinsam daran, erschwert die ausschließliche Bindung an die erste Browsersitzung spätere Zugriffe und Übergaben.
Leiten Sie Routingkennungen aus vertrauenswürdigem Anwendungskontext ab. Wer die Kennung einer anderen Aufgabe errät, darf dadurch keinen Inhaltszugriff erhalten. Objektrouting und Anwendungsautorisierung sind getrennte Verantwortlichkeiten.
| Zustandsidentität | Sinnvoller Zweck | Zu klärende Frage |
|---|---|---|
| Gespräch | Nachrichten und Interaktionskontext | Wer darf es erneut öffnen? |
| Geschäftsaufgabe | Angenommene Arbeit und aktuelle Stufe | Wer verantwortet sie über Sitzungen hinweg? |
| Quelldatensatz | Anlagen- oder Kundenkontext | Welche Revision wurde verwendet? |
| Externe Operation | Spur einer angeforderten Änderung | Wie wird ihr Ergebnis festgestellt? |
Maßgebliche Fakten außerhalb von Gesprächszusammenfassungen halten
Eine Modellzusammenfassung hilft bei der Gesprächsfortsetzung, darf aber nicht der einzige Nachweis einer vom Vorgesetzten freigegebenen Empfehlung werden. Speichern Sie das Freigabeereignis bei Berichtsversion und authentifiziertem Prüfer.
Halten Sie ebenso die aktuelle Aufgabenstufe ausdrücklich fest. „Wartet auf Prüfung“ sollte Anwendungszustand sein, kein Satz, an den sich der Assistent aus einem früheren Austausch erinnert. Eine spätere Modellantwort darf keinen Übergang erfinden, weil das Protokoll einen wahrscheinlichen Abschluss nahelegt.
Cloudflares Leitfaden zu Gesprächszustand und Gedächtnis unterscheidet gespeicherten Verlauf von dem Modell gelieferten Kontext. Das ist für die Umsetzung wichtig: Nicht jede gespeicherte Information muss in den nächsten Prompt.
Beim Bericht könnte der Assistent eine kompakte Aufgabenzusammenfassung und ausgewählte erlaubte Belege erhalten. Maßgebliche Quellen und Ereignisnachweise kann die Anwendung getrennt unter eigenen Zugriffs- und Aufbewahrungsregeln speichern.
Übergänge entwerfen, die veraltete Entscheidungen ablehnen
Geben Sie jedem prüfbaren Bericht eine Revision. Die Freigabe eines Vorgesetzten sollte diese benennen. Treffen nach Öffnen der Prüfseite neue Notizen ein, muss die Anwendung entscheiden, ob sie den Vorschlag ungültig machen oder getrennt behandelt werden können.
Prüfen Sie den aktuellen Aufgabenstatus beim Eingang einer Aktion. Ein veralteter Browsertab darf keinen abgebrochenen Bericht freigeben, ein wiederholter Klick keine zweite Geschäftsoperation erzeugen. Liefern Sie ein festgestelltes Ergebnis, wenn die Aktion bereits angenommen wurde.
| Eingehende Aktion | Aktueller Zustand | Erwartete Behandlung |
|---|---|---|
| Aktuellen Bericht freigeben | Prüfung ausstehend | Befugnis prüfen und Übergang annehmen |
| Alte Revision freigeben | Bericht ersetzt | Aktuelle Version prüfen lassen |
| Angenommene Freigabe wiederholen | Bereits freigegeben | Erfasstes Ergebnis zurückgeben |
| Notizen nach Abschluss ergänzen | Aufgabe abgeschlossen | Ausdrückliche Änderungsregel anwenden |
| Aufgabe anderen Teams öffnen | Aufrufer außerhalb des Umfangs | Zugriff verweigern |
Dies sind Anwendungsregeln. Die Zustandsplattform stellt einen Ort für ihre Umsetzung bereit. Sie entscheidet nicht, ob eine geänderte Wartungsnotiz geschäftlich wichtig ist oder welcher Vorgesetzte die Befugnis hat.
Aus Nachweisen statt Prozessgedächtnis wiederherstellen
Behandeln Sie Arbeitsspeicherwerte als vorübergehenden Arbeitszustand. Erfassen Sie zur Fortsetzung nötige Fakten und identifizieren Sie bereits erfolgte externe Anfragen. Ein Neustart sollte die aktuelle Stufe rekonstruieren, ohne das ganze Gespräch erneut durch ein Modell zu schicken.
Bewahren Sie für den Wartungsbericht Quellrevisionen, Entwurfsrevision, Freigabestatus und Zieloperationsreferenz auf. Hat das Ziel den Bericht trotz verlorener Antwort angenommen, ist diese Referenz wertvoller als eine weitere generierte Erklärung.
Unterscheiden Sie nie gestartete Arbeit von Arbeit mit unbekanntem Ergebnis. Nur erstere lässt sich offensichtlich sicher starten. Prüfen Sie bei letzterer das Ziel oder verwenden Sie dessen unterstützte Duplikatvermeidung vor erneuter Übermittlung.
Testen Sie Wiederherstellung durch Unterbrechungen zwischen bedeutsamen Stufen. Lassen Sie danach einen anderen Entwickler die Aufgabe identifizieren und aus gespeicherten Belegen den nächsten Schritt bestimmen. Das deckt fehlenden Zustand auf, den eine normale Erfolgsdemonstration nicht zeigt.
Unter aktuellen Befugnissen wieder verbinden
Authentifizieren Sie einen zurückkehrenden Kollegen gemäß Sitzungsregeln erneut und prüfen Sie seine aktuellen Aufgabenberechtigungen. Der Besitz einer alten Gesprächskennung erhält den Zugriff nicht automatisch unbegrenzt.
Laden Sie erfassten Status und Beobachtungszeit der Aufgabe. Erklären Sie Warten, Verarbeitung, Fehler oder ausstehenden Abgleich. Lässt sich Fortschritt nicht feststellen, zeigen Sie die Unsicherheit, statt das Modell eine beruhigende Antwort liefern zu lassen.
Nützliches Gedächtnis und Ablauf festlegen
Gesprächsverlauf, Quelldokumente und Betriebsnachweise können unterschiedliche Aufbewahrungsbedürfnisse haben. Definieren Sie sie vor automatischem Gedächtnis. Dauerhafte Speicherung jeder Eingabe erschwert spätere Löschung und Zugriffsprüfung.
Trennen Sie wiederverwendbare Vorlieben von Aufgabenfakten. Ein bevorzugtes Berichtsformat kann über Sitzungen hinweg helfen. Ein temporäres Zugriffstoken oder zurückgezogenes Kundendetail sollte kein dauerhafter Assistentenspeicher werden.
Berücksichtigen Sie bei Quellenlöschung oder Zugriffsentzug auch abgeleiteten Zustand. Eine Zusammenfassung kann denselben sensiblen Fakt enthalten wie die Quelle. Die Anwendung benötigt Regeln für gespeicherte Entwürfe, gefundene Textstellen und modellseitigen Kontext.
Unser RAG-Leitfaden zur Datenaktualität behandelt bei suchlastigem Gedächtnis Aktualisierungen und Löschungen im Index. Ein Vektorsuchergebnis ist keine maßgebliche Aussage über die aktuelle Aufgabenstufe.
Betreibbare Zustandsgrenzen wählen
Machen Sie nicht jedes Anliegen zu einem eigenen Objekt, bevor die Last das rechtfertigt. Zu viele Grenzen erschweren die Nachverfolgung einfacher Aufgaben. Ebenso erzeugt ein undifferenzierter gemeinsamer Zustand für sämtliche Kunden und Aufgaben Zugriffs- und Verantwortungsprobleme.
Beginnen Sie mit einem Diagramm: Wie erreicht eine authentifizierte Anfrage die Aufgabe, welche Nachweise sind maßgeblich und wo tritt externe Geschäftswirkung ein? Identifizieren Sie für jeden Fehler die erklärende Komponente.
Cloudflares Agents-Überblick liefert den breiteren Laufzeitkontext. Verwenden Sie dokumentierte APIs Ihrer gewählten Version und prüfen Sie experimentelle Schnittstellen, bevor sie Teil einer Supportzusage werden.
Die Abnahme sollte gleichzeitige Prüfer, wiederholte Aktionen, Quellenrevision, Wiederverbindung und nicht verfügbares Ziel enthalten. Entscheidend ist nicht bloß gespeicherter Zustand, sondern die Fortsetzung richtiger Arbeit mit richtigen Befugnissen.
Zustandsentwurf und Übergabe schätzen
Der Aufwand hängt von Aufgabenübergängen, Zusammenarbeit, Quellenbeziehungen und Wiederherstellung ab. Ein Protokollspeicher ist wesentlich kleiner als ein koordiniertes Aufgabensystem mit Freigaben und Zielabgleich.
Fordern Sie ein Angebot in GBP mit ausdrücklicher Zustandsverantwortung, Zugriffsregeln, Aufbewahrung und Wiederherstellungstests. Planen Sie die Weiterentwicklung gespeicherter Datensätze bei Codeänderungen. Bestehende Aufgaben dürfen nach Bereitstellung nicht unlesbar werden.
| Arbeitsbereich | Übergabenachweis |
|---|---|
| Identität und Routing | Dokumentierte Zuordnungen und Ablehnung außerhalb des Umfangs |
| Aufgabenübergänge | Zustandsdiagramm und Behandlung veralteter Aktionen |
| Wiederherstellung | Unterbrochener Lauf und Zielabgleich belegt |
| Aufbewahrung | Definierter Löschumfang und Umgang mit abgeleiteten Daten |
| Betrieb | Betriebshandbuch für einen anderen Entwickler |
Ein begrenzter KI-Integrationspilot kann diese Verträge an einer nützlichen Aufgabe festlegen. Fordern Sie ein Angebot für zustandsbehaftete Assistenten an , mit Aufgabenlebenszyklus, Prüfern und angebundenen Systemen. So folgt der Speicherentwurf Ihrer Arbeit, statt versehentlich durch ein Chatprotokoll definiert zu werden.
Häufig gestellte Fragen
Ist KI-Gedächtnis dasselbe wie dauerhafte Speicherung? Nein. Dauerhafte Speicherung bewahrt Anwendungsinformationen; Modellkontext sind die Informationen für eine bestimmte Inferenz. Entscheiden Sie, welche gespeicherten Fakten maßgeblich sind und welche für den Assistenten ausgewählt oder zusammengefasst werden.
Sollte jedes Gespräch eine eigene Aufgabe haben? Nur wenn das zum Geschäftsprozess passt. Ein Gespräch kann mehrere mögliche Aufgaben behandeln; eine angenommene Aufgabe kann mehrere Gespräche überdauern. Geben Sie angenommener Arbeit eine Identität unabhängig von ihrer ursprünglichen Oberfläche.
Beweist eine Objektkennung, dass der Aufrufer die Daten besitzt? Nein. Prüfen Sie authentifizierte Identität und aktuelle Berechtigungen vor Zustandsausgabe oder Aktionsannahme. Eine erratene oder wiederverwendete Routingkennung darf Zugriff nicht erweitern.
Was sollte einen Neustart überstehen? Speichern Sie Fakten zur Aufgabenstufe, Quellen- und Entwurfsrevisionen, Freigabe und externen Operationsreferenzen. Temporärer Prozessspeicher darf nicht der einzige Nachweis angenommener Arbeit sein.
Kann eine Gesprächszusammenfassung eine Freigabe erfassen? Sie kann sie beschreiben. Halten Sie die maßgebliche Freigabe jedoch als authentifiziertes Anwendungsereignis zur genauen Vorschlagsversion fest. Ein modellarzeugter Satz darf keine Geschäftsänderung erlauben.
Was sollte mit veralteten Browseraktionen geschehen? Prüfen Sie sie gegen aktuellen Zustand und Revision. Ablehnen oder aktualisieren Sie veraltete Entscheidungen und liefern Sie gegebenenfalls das gespeicherte Ergebnis angenommener Aktionen. Ein erneuter Klick darf keine weitere Wirkung erzeugen.
Was macht einen nützlichen Piloten für zustandsbehaftete Assistenten aus? Er sollte Identitätsgrenzen, gleichzeitige Aktionen, Unterbrechung, Wiederverbindung und Zielunsicherheit vorführen. Ein anderer Entwickler sollte die Aufgabe aus gespeicherten Nachweisen wiederherstellen können, ohne das Modell das Geschehen rekonstruieren zu lassen.