Cloudflare Durable Objects pour l'IA : état et reprise

Cloudflare Durable Objects pour l’IA est utile lorsqu’un assistant a besoin d’un point stable pour coordonner une session ou une tâche. La difficulté de conception est de définir le sens de cet état. Historique de conversation, tâche en cours et changement métier approuvé ne doivent pas devenir le même dossier simplement parce qu’ils appartiennent au même assistant.

Utilisez Durable Objects pour coordonner un état applicatif clairement identifié, puis distinguez historique, statut de tâche et résultats métier externes. Reconstituez le travail depuis les traces persistées après interruption, contrôlez les permissions à la reconnexion et séparez contexte du modèle et état de référence. Le stockage durable est un composant, pas une politique complète de reprise.

Imaginez un assistant de maintenance préparant un rapport d’intervention. Il collecte des notes, rédige une recommandation et attend un responsable. Le navigateur peut se déconnecter pendant l’attente. Le responsable peut ouvrir la tâche ailleurs, et la fiche de l’équipement peut changer avant l’approbation.

Ce guide propose une conception d’état pour cette situation. Il ne prétend ni qu’il faille conserver chaque message ni que l’identité d’un objet corresponde automatiquement aux frontières d’accès de votre organisation.

Cloudflare Durable Objects pour l’IA exige un modèle d’identité

Cloudflare décrit Durable Objects comme une plateforme de coordination d’applications avec état. Avant d’attribuer un objet à une fonction IA, définissez ce qu’il représente : conversation, tâche acceptée, ressource partagée ou autre unité limitée.

Un objet par conversation peut simplifier l’interaction. Un rapport d’intervention peut nécessiter une identité qui lui survive. Si plusieurs collègues collaborent, rattacher le rapport exclusivement à la première session de navigateur rend accès ultérieur et transmission confus.

Déduisez les identifiants de routage d’un contexte applicatif fiable. Un appelant devinant l’identifiant d’une autre tâche ne doit pas accéder à son contenu. Routage d’objet et autorisation applicative sont des responsabilités distinctes.

Garder les faits de référence hors des résumés

Un résumé généré aide l’assistant à poursuivre une conversation, mais ne doit pas être la seule preuve d’une recommandation approuvée. Stockez l’événement d’approbation avec la version du rapport et le réviseur authentifié.

Gardez aussi l’étape courante explicite. « En attente de révision » doit être un état applicatif enregistré, pas une phrase mémorisée d’un échange antérieur. Une réponse ultérieure du modèle ne doit pas inventer une transition parce que l’historique suggère une probable fin de travail.

Le guide de l’état conversationnel et de la mémoire distingue historique persisté et contexte fourni au modèle. Cette distinction compte : toutes les données stockées n’ont pas à entrer dans le prochain prompt.

Pour le rapport, l’assistant pourrait recevoir une synthèse compacte de tâche et quelques preuves autorisées. L’application peut garder séparément sources et événements de référence, selon leurs propres règles d’accès et de conservation.

Concevoir des transitions rejetant les décisions périmées

Attribuez une révision à chaque rapport soumis à examen. L’approbation doit identifier cette révision. Si des notes arrivent après ouverture de la page, l’application doit décider si elles invalident la proposition ou peuvent être traitées séparément.

Vérifiez l’état courant à l’arrivée d’une action. Un onglet périmé ne doit pas approuver un rapport annulé ; un clic répété ne doit pas créer une seconde opération métier. Renvoyez le résultat établi quand l’action a déjà été acceptée.

Ce sont des règles applicatives. La plateforme d’état permet de les réaliser ; elle ne décide pas si une note modifiée est commercialement importante ni quel responsable possède l’autorité.

Reprendre depuis les dossiers plutôt que la mémoire du processus

Traitez les valeurs en mémoire comme un état temporaire de travail. Enregistrez les faits nécessaires à la reprise et identifiez toute requête externe déjà effectuée. Un redémarrage doit reconstruire l’étape courante sans rejouer toute la conversation dans le modèle.

Pour le rapport de maintenance, conservez révisions sources, révision du brouillon, approbation et référence d’opération de destination. Si le rapport a été accepté mais sa réponse perdue, cette référence est plus utile qu’une nouvelle explication générée.

Distinguez travail jamais commencé et résultat inconnu. Seul le premier peut clairement être démarré sans risque. Pour le second, inspectez la destination ou utilisez son mécanisme pris en charge de prévention des doublons avant une nouvelle soumission.

Testez la reprise en interrompant l’application entre étapes significatives. Demandez ensuite à un autre ingénieur de retrouver la tâche et de choisir l’action depuis les preuves stockées. Cela révèle l’état manquant qu’une démonstration de réussite ordinaire masque.

Se reconnecter avec l’autorité actuelle

À la reconnexion d’un collègue, réauthentifiez-le selon les règles de session et vérifiez ses droits actuels. Posséder un ancien identifiant de conversation ne préserve pas indéfiniment l’accès.

Chargez statut consigné et heure d’observation. Expliquez attente, traitement, échec ou rapprochement nécessaire. Si l’avancement est impossible à établir, montrez cette incertitude plutôt que demander au modèle une réponse rassurante.

Décider quelle mémoire est utile et ce qui doit expirer

Historique, sources et preuves opérationnelles peuvent avoir des besoins de conservation différents. Définissez-les avant d’ajouter une mémoire automatique. Garder toutes les entrées pour toujours complique suppression et contrôle d’accès ultérieurs.

Séparez préférences réutilisables et faits de tâche. Un format de rapport préféré peut servir entre sessions. Un token temporaire ou un détail client retiré ne doit pas devenir une mémoire permanente de l’assistant.

Lors d’une suppression de source ou révocation d’accès, examinez aussi l’état dérivé. Un résumé peut contenir le même fait sensible que la source. Il faut une politique pour brouillons, passages récupérés et contexte du modèle.

Pour une mémoire fortement fondée sur la recherche, notre guide de fraîcheur des données RAG couvre mises à jour et suppressions dans l’index. Un résultat vectoriel n’est pas une déclaration faisant autorité sur l’étape actuelle de la tâche.

Choisir des frontières d’état exploitables

Ne faites pas de chaque préoccupation un objet distinct avant que la charge le justifie. Trop de frontières compliquent le suivi d’une tâche simple. À l’inverse, un état partagé indifférencié pour tous les clients et tâches crée des problèmes d’accès et de responsabilité.

Commencez par un schéma montrant comment une requête authentifiée rejoint une tâche, quels dossiers font autorité et où se produit l’effet métier externe. Identifiez le composant capable d’expliquer chaque échec.

La présentation d’Agents donne le contexte d’exécution général. Utilisez les API documentées de votre version et testez les interfaces expérimentales avant de les inclure dans une promesse de support.

L’acceptation doit comprendre réviseurs simultanés, actions répétées, changement de révision source, reconnexion et destination indisponible. Le résultat utile n’est pas seulement la persistance : c’est la reprise du bon travail sous la bonne autorité.

Estimer conception d’état et transmission

Le coût dépend des transitions, de la collaboration, des relations sources et de la reprise. Un stockage d’historique représente un périmètre bien plus petit qu’un système coordonné avec approbations et rapprochement de destination.

Demandez un devis en GBP précisant propriétaire de l’état, accès, conservation et tests de reprise. Prévoyez l’évolution des dossiers stockés avec le code. Les tâches existantes ne doivent pas devenir illisibles après déploiement.

Un pilote d’intégration IA limité peut établir ces contrats sur une tâche utile. Demandez une proposition d’assistant avec état avec cycle de vie, réviseurs et systèmes connectés. La conception du stockage suivra ainsi votre travail plutôt qu’un historique de chat qui la définirait par accident.

Questions fréquentes

La mémoire IA équivaut-elle au stockage persistant ? Non. Le stockage conserve les informations applicatives ; le contexte du modèle est l’information fournie à une inférence précise. Décidez quels faits stockés font autorité et lesquels sont sélectionnés ou résumés pour l’assistant.

Chaque conversation doit-elle avoir sa tâche ? Seulement si cela correspond au processus. Une conversation peut discuter plusieurs tâches possibles, et une tâche acceptée peut traverser plusieurs conversations. Donnez au travail accepté une identité survivant à son interface de départ.

Un identifiant d’objet prouve-t-il que l’appelant possède les données ? Non. Vérifiez identité authentifiée et droits actuels avant de retourner l’état ou accepter une action. Un identifiant deviné ou réutilisé ne doit pas élargir l’accès.

Que doit-il rester après redémarrage ? Les faits permettant d’établir étape, révisions sources et brouillons, approbation et références d’opérations externes. La mémoire temporaire ne doit pas être la seule preuve du travail accepté.

Un résumé peut-il enregistrer une approbation ? Il peut la décrire, mais gardez l’approbation de référence comme événement applicatif authentifié lié à la version exacte. Une phrase générée ne doit pas autoriser un changement métier.

Que faire des actions de navigateur périmées ? Comparez-les à l’état et la révision actuels. Rejetez ou actualisez les décisions obsolètes et retournez, si approprié, le résultat enregistré d’une action acceptée. Un nouveau clic ne doit pas créer un nouvel effet.

Qu’est-ce qu’un pilote utile d’assistant avec état ? Il montre frontières d’identité, actions simultanées, interruption, reconnexion et destination incertaine. Un autre ingénieur doit reprendre depuis les preuves stockées sans demander au modèle de reconstruire les événements.