Limites d'exécution et protections de l'agent

  • 5 minutes

Les agents peuvent effectuer des actions dans des dépôts, mais ces actions s’exécutent dans les limites de la plateforme et sous des protections. Sur GitHub, Copilot agent cloud fonctionne dans un environnement GitHub Actions, crée des modifications sur une branche et prépare ces modifications à examiner.

Elle ne finalise pas les modifications par elle-même. Vous décidez si ces modifications doivent devenir un pull request.

Dans cette unité, vous allez apprendre :

  • Quelles sont les limites placées sur les actions de l’agent
  • Comment les restrictions de branche et de référentiel protègent les bases de code
  • Comment les contrôles de flux de travail et d’environnement affectent les modifications pilotées par l’agent
  • Comment l’examen humain fait partie du processus

Limites de référentiel et de branche

Copilot agent cloud a uniquement accès au référentiel où il fonctionne. Il ne peut pas accéder à d’autres référentiels.

Ses modifications sont apportées sur une branche distincte, et non directement sur la branche par défaut, comme la branche principale. Cela garantit que toutes les modifications sont isolées avant révision.

Contrôle des pull requests

Lorsque l'agent cloud Copilot termine son travail, il prépare les modifications à réviser, mais il ne crée pas ni ne fusionne automatiquement une pull request.

Vous décidez s’il faut :

  • Créer une pull request
  • Passer en revue les modifications générées
  • Demander des mises à jour ou ignorer le travail

Cela maintient la décision finale dans le contrôle humain.

Contrôles de flux de travail

Le travail de l’agent s’exécute dans des flux de travail alimentés par GitHub Actions.

Les paramètres du référentiel et de l’organisation peuvent contrôler :

  • Quels flux de travail sont autorisés
  • Quelles actions peuvent être exécutées
  • Ce que le GITHUB_TOKEN est autorisé à faire

Ces contrôles limitent ce que l’agent peut exécuter par le biais de flux de travail.

Les modèles de résilience et de protection de l’exécution.

Outre les limites au niveau de la plateforme, les flux de travail pilotés par l’agent doivent inclure des protections pour gérer les défaillances, empêcher les erreurs répétées et garantir la responsabilité.

Gestion des erreurs

Les flux de travail doivent gérer explicitement les échecs lors de l’exécution de l’agent.

Cela peut inclure :

  • Échouer rapidement lorsqu'une étape rencontre des erreurs
  • Journalisation des messages d’erreur significatifs
  • Prévention des modifications partielles ou incohérentes

Exemple :

```
- run: | 
        npx @github/copilot-cli -p "Run task" 
continue-on-error: false
```

Cela garantit que les erreurs arrêtent l’exécution au lieu de continuer en mode silencieux.

Nouvelle tentatives

Les réessais aident à gérer des pannes temporaires telles que des problèmes réseau ou des erreurs transitoires.

Vous pouvez implémenter des réessais en :

  • Réexécuter les étapes ayant échoué
  • Utilisation de la logique de nouvelle tentative dans les scripts
  • Structurer les flux de travail pour permettre une réexécution sécurisée

Exemple de modèle :

```
- name: Run agent task with retry 
run: | 
        for i in 1 2 3; 
            do npx @github/copilot-cli -p "Run task" && break 
            sleep 5 
        done
```

Cela permet au flux de travail de récupérer des problèmes temporaires sans intervention manuelle.

Annulations

Si un agent produit des modifications incorrectes ou dangereuses, les mécanismes de restauration garantissent que ces modifications n’affectent pas la base de code principale.

Le retour en arrière est naturellement supporté par :

  • Isolation basée sur les branches
  • Révision de pull request avant la fusion

Les stratégies de restauration supplémentaires sont les suivantes :

  • Fermeture ou abandon de la pull request
  • Annulation des commits si les modifications sont fusionnées

Chemins d’escalade

Lorsqu'un agent ne peut pas terminer une tâche ou rencontre une incertitude, l'escalade garantit qu'un humain puisse intervenir.

Cela peut être implémenté par :

  • Exiger une révision des pull requests
  • Affectation automatique des réviseurs
  • Utilisation des étapes de flux de travail pour notifier les responsables

L’escalade garantit que les décisions critiques sont toujours gérées par les humains.

Traçabilité et responsabilité

Toutes les actions de l’agent doivent être traçables et auditables.

GitHub fournit ceci par le biais des éléments suivants :

  • Journaux de flux de travail
  • Historique des commits
  • Discussions sur les demandes de tirage

Pour améliorer la traçabilité :

  • Utilisez des messages de validation clairs
  • Gardez les modifications dans le champ d’application d’une branche
  • Passer en revue toutes les actions via des pull requests

Cela garantit que chaque action de l’agent peut être inspectée, comprise et attribuée.

Nous avons discuté ces garanties pour garantir que l’exécution de l’agent soit :

  • Résilient : peut gérer les échecs et les nouvelles tentatives
  • Contrôlé : empêche les modifications non sécurisées
  • Auditable : toutes les actions sont visibles et traceables
  • Géré par l’homme : l’escalade garantit la surveillance

Protections de l’environnement

Si les modifications générées par l’agent sont utilisées dans les déploiements, les environnements fournissent des protections supplémentaires.

Les environnements peuvent :

  • Exiger des approbations avant que les travaux continuent
  • Restreindre l’accès aux secrets
  • Contrôler les cibles de déploiement

Cela garantit que les opérations sensibles ne sont pas exécutées automatiquement.

Visibilité de session

L’exécution de l’agent est visible pendant l’exécution.

Vous pouvez :

  • Surveiller la progression dans les journaux
  • Inspecter les actions de l’agent
  • Fournir des invites de suivi pour ajuster le comportement

Cette visibilité vous permet de rester en contrôle tout au long du processus.

Comportement de déclenchement et limites du flux de travail

Les flux de travail déclenchés à l’aide du GITHUB_TOKEN ont des restrictions.

La plupart des actions effectuées avec ce jeton ne déclenchent pas d’exécutions de flux de travail supplémentaires, ce qui permet d’empêcher les boucles involontaires ou l’exécution répétée.

D’autres méthodes d’authentification, telles que des jetons d’application GitHub ou des jetons d’accès personnels (PAT), peuvent déclencher des exécutions de flux de travail supplémentaires en fonction de la configuration. Bien que cela permet des modèles d’automatisation plus flexibles, il nécessite également une conception minutieuse pour éviter les exécutions récursives ou les boucles d’automatisation involontaires.

Activation des actions de l’agent en toute sécurité

Les agents peuvent effectuer des actions telles que :

  • Création de branches
  • Mise à jour du code
  • Préparation des modifications pour révision
  • Déclenchement de flux de travail par le biais d’événements de référentiel

Ces actions sont contrôlées par le biais des éléments suivants :

  • Isolation basée sur les branches
  • Validation du flux de travail
  • Examen des pull requests
  • Autorisations de workflow

En combinant ces contrôles, les actions de l’agent peuvent être activées sans autoriser l’accès illimité au référentiel ou à l’environnement d’exécution.

À retenir

L’exécution de l’agent sur GitHub est contrôlée par le biais de l’étendue du référentiel, de l’isolation des branches, des autorisations de flux de travail, des protections de l’environnement et des points de décision humains. Les agents préparent les modifications, mais vous restez responsable de leur révision et de leur finalisation.