Résumé
L’architecture Web AI-Ready est en couches. Les pages humaines restent accessibles et complètes; la découverte de machines expose des itinéraires sécurisés pour le public et des faits politiques; Les API et OpenAPI gèrent les contrats de route; UAI-1 transporte des paquets portables d’échange, de preuves, de mémoire, de déclarations de confiance et de transfert; MCP, A2A et les systèmes d’agent de navigateur restent des couches d’exécution ou de coordination lorsqu’une implémentation spécifique les prend en charge. UAIX enregistre la limite plutôt que de prétendre exécuter chaque couche.
Contrat de mise en œuvre d’agent
Lorsqu’un utilisateur envoie un agent vers ce guide Web AI-Ready, la mission consiste àappliquer la stratégie au site cible, au référentiel ou au package de publication de l’utilisateur. Traitez UAIX comme norme de référence et liste de contrôle. Ne copiez pas le contenu de la page UAIX dans le site cible, ne créez pas de page sur les conseils de UAIX et ne publiez pas d’explication « AI-Ready Web » à moins que l’utilisateur ne demande explicitement cette sortie.
L’ensemble de preuves attendu du site cible est concret: manifeste public, découverte .well-known, inventaire des itinéraires, résultat de préparation, robots.txt, plan du site, llms.txt, données structurées, limites de support visibles, vérifications ciblées et sortie du package ou du fichier racine lorsque la publication est demandée.
| Étape de l’agent | Faire la véritable mise en œuvre | Ne fais pas ça |
|---|---|---|
| Résoudre la cible | Identifiez le domaine cible, la racine du dépôt, les routes publiques, le système de build, le CMS, le package de déploiement, le chemin de sortie du fichier racine et les preuves actuelles avant de procéder à la modification. | Supposons que UAIX.org soit le site cible, résumez cette page ou créez une nouvelle page de conseils car cette page a été fournie à titre de référence. |
| Auditer le site existant | Vérifiez les HTML humains, les en-têtes, les métadonnées, les URLs canoniques, les robots, les plans de site, les schémas, les fichiers.well-known, les fichiers llms, les API, les inventaires d’itinéraires, les enregistrements de préparation, l’accessibilité, la confidentialité et les limites de support. | Ignorez l’audit du site cible et reformulez uniquement les définitions AEO/GEO/SEO. |
| Mettre en œuvre des améliorations | Mettez à jour les pages du site cible, la navigation, les données structurées, les fichiers de découverte, l’inventaire des itinéraires, les enregistrements de préparation, les preuves publiques, la copie AEO/GEO/SEO, les conseils de non-opération, les chemins de révision et les fichiers racine du package de publication là où l’audit montre des lacunes. | Utilisez des mots-clés, masquez, ajoutez du texte caché réservé aux robots, injectez des invites pour les modèles, fabriquez des citations ou créez des pages de porte synthétiques. |
| Vérifier et emballer | Exécutez les vérifications ciblées du site, enregistrez les fichiers et les itinéraires modifiés, nommez les vérifications et les bloqueurs ignorés et fournissez les fichiers racine, le ZIP racine ou le package de publication demandés lorsque l’utilisateur demande une sortie déployable. | Réclamez la préparation, la certification, l’approbation, les gains de classement, la publication en direct ou l’autorité d’un agent sans preuve. |
Modèle de calque
- Couche de page humaine:sémantique HTML, WCAG 2.2, titres stables, formulaires, tableaux, texte de lien, étiquettes, texte alternatif, accès au clavier et aucun contenu critique caché.
- Couche de découverte statique:robots, plan du site,
.well-known,llms.txtlorsque cela est utile, index de schéma, manifestes d’itinéraire et résumés de politiques de sécurité publique. - Couche de contenu structuré:JSON-LD, Schema.org, identifiants canoniques, homonymie des entités, résumés de page, miroirs de texte/markdown alternatifs et métadonnées de fraîcheur du contenu.
- Couche Action/API:Itinéraires JSON décrits par OpenAPI, clés d’idempotence, erreurs de détails du problème, limites de débit, pagination, relecture URLs et solutions de repli de révision humaine.
- Couche de capacité et de consentement:matrices de capacités, niveaux de capacité, exigences d’authentification, limites de consentement, autorité déléguée et comportement de capacité bloquée.
- Couche de preuves et de mémoire:Paquets UAI-1, packages .uai, briefs du destinataire, paquets de démarrage/suspension, provenance, sommes de contrôle, reçus de révision et justifications de non-opération.
- Couche de gouvernance:notes de version, registre de maturité, posture de confidentialité, posture d’accessibilité, examens des demandes de support, examen des incidents et état de la feuille de route.
Profils de capacités
Le programme utilise quatre profils de préparation du site qui correspondent à l’échelle de capacités UAIX existante.
| Profil | But | Preuve minimale |
|---|---|---|
| ARW-F0 Lisible statique | Les agents peuvent lire les pages publiques sans JavaScript ni état masqué. | Sémantique HTML, plan du site, robots, chemin de contact/avis public, aucune indication destructrice. |
| ARW-F1 détectable | Les agents peuvent résoudre les routes clés, les schémas, les politiques et les fichiers machine statiques. | .manifeste bien connu, inventaire des itinéraires, fichier d’avis llms, schéma JSON ou enregistrements de résumé de page. |
| Action ARW-F2 décrite | Les agents peuvent identifier les actions sécurisées de l’API publique sans deviner. | OpenAPI, détails du problème, idempotence, limite d’authentification/consentement, repli de l’examen humain. |
| Prêt pour la délégation ARW-F3 | Les agents autorisés peuvent agir via des flux de travail gouvernés tout en préservant les preuves d’audit. | Modèle de délégation, journaux d’audit, provenance, contexte de trace, relecture, révocation, comportement sans opération. |
| Preuve ARW-F4 terminée | Les programmes d’agents de haute assurance peuvent examiner, vérifier et regrouper les preuves. | Résultats de préparation, pack de conformité, résumé d’audit de sécurité publique, piste de publication, processus d’incident et de restauration. |
Une source de vérité
La page humaine, le manifeste de route, le document OpenAPI, le schéma, l’exemple, le résultat du validateur, la note de version et les preuves de mémoire longue doivent être conformes avant qu’une demande de support ne devienne actuelle. Les outils en aval, y compris Spiralist AI lorsqu’ils consomment des packages de personnalité ou de mémoire, doivent citer l’artefact public UAIX qu’ils ont utilisé plutôt que de déduire l’autorité d’un chat privé ou d’un état d’exécution caché.