Fonctions et tests
Une fonction exécute du code avec des schémas JSON d’entrée et de sortie déclarés. Elle peut renvoyer des artefacts et des propositions à traiter par l’hôte. Proposer une action n’autorise pas son exécution.
Tester une fonction localement
Depuis une copie du code source d’AgentKit, créez le projet Python de démarrage intégré :
make build
./dist/agentkit init --name my-agent /tmp/my-agent
./dist/agentkit test /tmp/my-agent
./dist/agentkit integration /tmp/my-agent
./dist/agentkit build /tmp/my-agent
Python doit être installé. Le projet initial ne nécessite ni clé de modèle, ni SDK, ni identifiants de production. Sa suite d’intégration vérifie sorties, artefacts, règles d’admission et rejeu via le contrat partagé de l’hôte.
Après avoir modifié un fichier, actualisez le verrouillage et relancez les vérifications :
./dist/agentkit lock /tmp/my-agent
./dist/agentkit integration /tmp/my-agent
./dist/agentkit build /tmp/my-agent
L’exécution native facilite le développement avec accès à votre machine. Pour le profil de conteneur Python pris en charge, démarrez Docker et récupérez l’image avant d’exécuter :
docker pull python:3.12-slim
./dist/agentkit integration --executor docker /tmp/my-agent
Cela vérifie un conteneur sans réseau et aux ressources limitées. Cela ne qualifie ni ne publie un kit hébergé.
Adios Sandbox
Adios Sandbox est le projet d’exécution locale distinct qui lance des applications dans un environnement Linux proche de l’hébergement Adios. L’exécution native, un conteneur Docker de développement et Adios Sandbox sont des environnements de test distincts.
L’adaptateur Sandbox propre à AgentKit reste à raccorder. En attendant, adios up --local teste les manifestes d’application pris en charge ; cette commande ne fournit pas à elle seule un exécuteur de fonctions AgentKit ni la résolution d’identifiants hébergés.
Le modèle d’exécution visé permet de choisir séparément l’emplacement des agents et des fonctions, en conservant le contrat de requête, réponse et politique des fonctions. Vérifiez les versions réelles et les limites appliquées dans chaque environnement avant d’affirmer la parité.
Vérifier par étapes
| Stade | Éléments à recueillir |
|---|---|
| Workflow enregistré | Ordre des étapes, schémas de sortie, attentes d’approbation, reprise et contenu des artefacts |
| Fonction native | Rejet des entrées, validation des sorties, délai maximal, artefacts et rejeu |
| Isolation locale | Version du runtime, filtrage de l’environnement, politique réseau et limites de ressources |
| Test hébergé | Même version du kit et jeux de test, connexions à portée limitée, sorties, artefacts et événements d’audit |
Comparez les résultats normalisés plutôt que les identifiants ou horodatages. Notez les effets simulés. Testez un identifiant manquant, une approbation refusée, une nouvelle tentative et l’annulation avant d’activer des actions sur des services réels.
Pour les workflows d’agents, utilisez le démarrage rapide comme première comparaison entre exécution locale et hébergée. Ajoutez vos propres jeux de test avant d’activer des effets réels.