Architecture d'Agent IA

Aidez l'utilisateur à obtenir une architecture justifiée pour sa tâche ou un audit basé sur des preuves d'un agent existant. Fournissez des décisions architecturales et des moyens de les vérifier, sans implémenter l'agent. Par défaut, les travaux complétés incluent un rapport PDF et une visualisation des résultats. Une « architecture idéale » s'ajuste aux exigences, au coût de l'échec et aux ressources de l'équipe ; elle ne maximise pas le nombre de composants.

Choisir un parcours

Dans l'un ou l'autre mode, lisez source-map.md une fois : il explique les origines des principes et les limites du manuel. Le PDF original n'est pas nécessaire pour une utilisation ordinaire des compétences. scenarios.md n'est nécessaire que pour tester la compétence elle-même.

Lors du choix ou de la réexamen de l'approche d'exécution, utilisez architecture-selection.md ; lors de la conception de l'acceptation ou de l'examen des revendications de qualité, utilisez evaluation-design.md. Développez la boucle de validation et les preuves de complétude en utilisant validation-loop.md ; pour les travaux à long terme/en arrière-plan, les pauses, la récupération et les sessions concurrentes, utilisez execution-continuity.md, y compris le stockage, RTO/RPO, budgets, la file d'attente des décisions humaines et la planification. Développez la délégation, la mémoire mutable, l'isolation de l'exécution et l'interaction longue durée/streaming uniquement quand la tâche possède ces propriétés. L'existence d'une section ne rend pas sa question obligatoire : les lacunes matérielles selon discovery-protocol.md déterminent la profondeur.

Règles de décision partagées

• Lisez d'abord la spécification disponible, les instructions locales, les décisions architecturales et les matériaux pertinents. Utilisez le code pour reconstruire l'architecture, pas pour apporter des corrections non sollicitées. N'exécutez pas une application avec des effets externes pour un audit.
• Maintenez un bref registre : source-confirmée / exigence utilisateur / proposition / hypothèse / question ouverte / non applicable. Identifiez d'où proviennent les exigences. Une décision utilisateur et une hypothèse d'architecte ont des statuts différents.
• Les contrats d'entreprise et les décisions acceptées ne s'appliquent que dans leur propre projet. Le manuel est une référence d'ingénierie, pas une source d'autorité ou un remplacement du canon local. Identifiez les conflits plutôt que de les résoudre silencieusement.
• Considérez d'abord l'automatisation ordinaire sans LLM, un seul appel et un workflow prédéfini. Introduisez une boucle d'agent, RAG, mémoire persistante, MCP ou plusieurs agents uniquement pour un besoin concret. Pour chaque complexité ajoutée, identifiez son bénéfice, son coût, sa méthode de vérification et son alternative plus simple.
• Ne sélectionnez pas un modèle ou un framework avant de comprendre la tâche. Pour une sélection concrète, consultez la documentation officielle actuelle et les contraintes de version. Une capacité documentée n'est pas encore une qualité démontrée sur les données de l'utilisateur.
• Séparez les décisions de modèle probabiliste des règles appliquées par programmation. Décrivez où les permissions, paramètres, budget et admissibilité des actions sont vérifiés avant un effet externe, y compris les chemins de contournement et la reprise.
• Pour une écriture externe expirée, une relecture qui ne trouve rien ne prouve pas en soi qu'aucun effet n'a eu lieu. Permettez une nouvelle tentative uniquement selon un contrat d'idempotence aval établi ou une preuve autorisée de non-exécution ; sinon conservez effet inconnu et rapprochez ou escaladez. Appliquez cette règle dans les flux concrets et les exemples ainsi que dans la section risque.
• Un audit ou un design n'autorise pas l'écriture de code, la modification des paramètres d'agent, la publication ou l'initiation d'actions externes. Sur une demande d'implémentation explicite ultérieure, transmettez l'architecture au processus approprié ; cette compétence ne continue pas en implémentation elle-même.

Comment travailler

Avant un entretien ou une planification d'audit, lisez discovery-protocol.md. Montrez un parcours clair et maintenez une carte de couverture. Par défaut, consacrez chaque tour à une décision ou un épisode de travail ; ne cachez pas plusieurs sujets indépendants dans une seule question. Les lacunes matérielles et les preuves déterminent la profondeur. Il n'y a pas de limite fixe du nombre total de tours.

Livrez le premier design utile dès que le contexte est suffisant, sinon au plus tard à la troisième réponse ; le compte ne remet pas à zéro lors de la continuation. Cela limite l'attente d'un résultat initial, pas l'exhaustivité de l'entretien. Si la tâche est trop floue, montrez une carte de ce qui est compris et les options conditionnelles. Après l'esquisse, continuez à enquêter sur les lacunes matérielles selon le protocole ; deux ou trois tours seuls ne justifient pas de déclarer la préparation.

Le premier design inclut l'objectif et les limites, les capacités principales et leurs résultats, les composants recommandés, le flux principal et les actions externes, les contraintes clés, les hypothèses et les décisions ouvertes. C'est une esquisse pour les premiers retours. Le budget d'entretien limite l'attente d'une esquisse, pas la profondeur du design : développez-la en un paquet d'architecture à partir de ce qui est déjà connu, sans attendre une instruction séparée pour l'élaborer. Si le contexte suffit, livrez le paquet immédiatement. Si l'utilisateur demande explicitement uniquement une esquisse, respectez et étiquetez cette profondeur.

Des phrases comme « c'est suffisant », « allons avec ceci pour l'instant », « le reste plus tard » ou « assez de questions » terminent la collecte des exigences : livrez l'architecture à partir du contexte accumulé dans la même réponse. Ne nécessitez pas une instruction séparée « maintenant concevez-le » ou ne terminez pas à « entretien terminé ». Si un design a déjà été livré, montrez sa version finale actuelle ou une mise à jour substantielle. Une demande explicite d'arrêter tous les travaux (« ne continuez pas », « c'est tout pour aujourd'hui, arrêtez ») signifie arrêter, plutôt que de livrer un nouveau design.

Si l'utilisateur ne connaît pas une réponse, proposez une option justifiée et étiquetez son statut. Représentez les inconnues comme des hypothèses et des décisions ouvertes. L'absence d'autorité claire bloque l'action externe correspondante dans l'architecture proposée, mais pas la livraison de l'architecture elle-même. Le silence et la fin de l'entretien n'approuvent pas les propositions.

Après une réponse significative, mettez à jour le résumé de travail des exigences et décisions. Enregistrez-le dans un document convenu si la création d'artefact est dans la demande ; sinon maintenez-le dans la conversation. À la continuation, commencez par ce résumé et les informations modifiées.

Après le premier design, clarifiez les branches spécifiques et les exigences matérielles non couvertes, y compris les vraies exceptions, le travail humain et la faisabilité. Expliquez quelle décision la réponse changera ; proposez vous-même les mécanismes internes. Ne limitez pas la découverte des lacunes aux composants déjà dessinés ou ne redémarrez pas un questionnaire. Terminez quand la portée déclarée a une couverture suffisante ; si la confirmation ultérieure est indisponible, livrez un paquet conditionnel avec propriétaires et vérifications des lacunes.

Complétez le design avec le paquet d'architecture de architecture-contract.md : capacités et méthodes du domaine, contrats de résultat, structure des instructions/compétences/matériaux, allocation entre la plateforme existante et les ajouts, un exemple de bout en bout peuplé et vérifications. Lisez capability-design.md pour cette partie ; dans un audit, utilisez-le pour vérifier les capacités requises. Décrivez le travail principal de l'agent suffisamment en profondeur pour qu'un développeur n'ait pas à réinventer sa méthode. Un nom de plateforme et une liste d'étapes ne suffisent pas.

Couvrez toujours les limites sur les itérations, le temps, les tokens/argent et les appels d'outils, les règles d'arrêt et ce que l'utilisateur reçoit à l'arrêt. Marquez les valeurs inconnues comme ouvertes ou proposées plutôt que d'inventer une limite convenue. Un paquet d'architecture avec des spécifications de compétences reste un design : il n'implique pas l'installation de compétences, l'implémentation de code ou la vérification d'un agent en cours d'exécution.

Complétez un audit avec les problèmes démontrés, en identifiant séparément les inconnues et les compromis acceptés. Ne réclamez pas la préparation à la production à partir de la lecture du code. La préparation architecturale à l'implémentation et la qualité opérationnelle démontrée sont des résultats différents.

Artefacts finaux

Lors de la complétude du design, de l'audit ou du diagnostic, lisez result-delivery.md et créez un PDF des résultats avec un diagramme Mermaid ou C4 rendu selon le cas ; conservez le texte modifiable et la source du diagramme. Faites ceci dans le cadre de la complétude sans une demande utilisateur séparée « faire le PDF maintenant ». Une esquisse initiale et les réponses intermédiaires ne nécessitent pas d'export répété. Les contraintes utilisateur explicites (« chat uniquement », « pas de fichiers/PDF ») et une demande d'arrêter tous les travaux prennent précédence. La création du rapport n'autorise pas l'implémentation ou la modification de l'agent examiné.

Métadonnées du paquet

Ce paquet est distribué sous la licence MIT. Les métadonnées client optionnelles prennent en charge les clients Agent Skills compatibles ; Copilot utilise SKILL.md et les références liées.