Sui Met des Limites de Dépenses Obligatoires au Cœur de la Conception de Son Agent IA

TL;DR : Une note de conception de Sui soutient que les agents ont besoin de permissions appliquées par les systèmes qu'ils utilisent. Les transactions on-chain peuvent soutenir ces contrôles, mais ne peuvent pas établir que l'objectif d'un agent est correct.

Un agent financier utile a besoin de suffisamment d'autorité pour accomplir une tâche sans demander à plusieurs reprises une approbation. Il a également besoin de limites qui restent efficaces s'il malcomprend une instruction ou rencontre des informations trompeuses.

Une note de conception de la Sui Foundation du 28 octobre aborde cette tension en se concentrant sur des permissions et des enregistrements vérifiables. La discussion constitue un cadre pour construire des flux de travail plus sûrs, et non une annonce selon laquelle tous les agents IA sur Sui sont devenus fiables.

Les instructions et les permissions remplissent des rôles différents

La note de la Fondation soutient que les limites devraient être appliquées par les systèmes qu'un agent utilise, plutôt que d'exister uniquement comme des instructions que l'agent est censé se rappeler. Elle souligne également l'importance de termes partagés et d'enregistrements vérifiables lorsque plusieurs organisations participent.

Cette distinction est claire dans un exemple de paiement. Dire à un logiciel de dépenser moins qu'une limite est un contrôle. Lui donner des identifiants qui ne peuvent pas autoriser un paiement au-dessus de cette limite en est un autre.

Le premier dépend de l'interprétation et du respect de la règle par l'agent. Le second peut rejeter une action même lorsque l'agent a commis une erreur. Un déploiement efficace nécessite à la fois un objectif sensé et un mécanisme qui contraint l'exécution.

Les transactions atomiques peuvent réduire les résultats partiels

La documentation sur les transactions programmables de Sui décrit comment plusieurs commandes peuvent être regroupées afin que leurs changements d'état s'appliquent ensemble. Si une commande échoue, le groupe ne laisse pas les changements d'actifs prévus à moitié complétés, bien que les coûts de transaction doivent encore être pris en compte.

Pour un flux de travail automatisé, cela peut aider lorsque plusieurs étapes on-chain dépendent les unes des autres. Un achat et un mouvement subséquent de l'actif acquis peuvent être évalués comme une seule transaction composée plutôt que comme des opérations non liées.

Le bénéfice a des limites. L'exécution atomique n'établit pas que le prix était sensé, que le destinataire était approprié ou que le service externe a livré ce qu'il avait promis. Elle contrôle comment un ensemble d'opérations se termine, pas si le jugement commercial sous-jacent était bon.

La délégation doit préserver la limite originale

Un agent plus complexe peut appeler un autre service ou déléguer une partie d'une tâche. Cela soulève une question d'autorité : le prochain participant peut-il faire uniquement ce que l'utilisateur original a permis, ou la délégation élargit-elle accidentellement le champ d'application ?

Un design robuste rendrait la réponse visible. Les permissions pourraient spécifier un budget, un but approuvé, une date d'expiration et un ensemble limité de contreparties. Le système vérifierait alors ces conditions au moment où une action est autorisée.

C'est un principe de conception analytique, pas une affirmation qu'une blockchain fournit automatiquement chaque contrôle requis. Les développeurs doivent toujours mettre en œuvre les règles correctement et tenir compte des actions qui se produisent en dehors de la chaîne.

Des enregistrements vérifiables aident à résoudre ce qui s'est passé

Lorsque plusieurs entreprises interagissent par le biais d'agents logiciels, un enregistrement partagé peut aider à établir quelle action a été autorisée et quelle transaction a eu lieu. Cela est utile pour la réconciliation et l'enquête, en particulier lorsque chaque participant garde ses propres systèmes internes.

L'enregistrement a toujours besoin de contexte. Une transaction réussie ne prouve pas qu'un client a reçu un bien physique, qu'une facture était authentique ou qu'une entrée off-chain était précise. Ces faits nécessitent leurs propres preuves et processus de contestation.

L'implication la plus forte de la note de conception de Sui est donc pratique : commencez par une autorité définie de manière étroite, appliquez-la à la limite du système et rendez les actions complètes inspectables. Élargissez le champ d'application uniquement lorsque les contrôles et les preuves opérationnelles justifient de le faire.

L'infrastructure blockchain peut contribuer aux règles et aux enregistrements de transaction à cette conception. La qualité de l'agent résultant dépend de l'application complète, y compris de ses permissions, de ses sources d'information et de sa réponse lorsque quelque chose sort du flux de travail attendu.

Rédigé par la rédaction et édité par Samuel Rae.