CodeAct

CodeAct permet à un agent de résoudre une tâche en écrivant du code et en l’exécutant via un execute_code outil. Au lieu de demander au modèle d’émettre un appel d’outil à la fois, CodeAct lui donne un emplacement bac à sable pour combiner le flux de contrôle, la transformation de données et l’orchestration d’outils à l’intérieur d’une seule étape d’exécution.

Dans Agent Framework, CodeAct est exposé via des packages spécifiques au back-end plutôt qu’un seul type de cœur intégré. Un connecteur peut ajouter l’outil execute_code , injecter des instructions d’exécution et éventuellement exposer des outils appartenant à un fournisseur pouvant être appelé à partir du bac à sable.

Pourquoi CodeAct

Les agents IA modernes ne sont souvent pas limités par la qualité du modèle, mais par la surcharge opérationnelle d'orchestration. Lorsqu’un agent regroupe de nombreux petits appels d’outils, chaque étape nécessite généralement un autre tour de modèle, ce qui augmente à la fois la latence et l’utilisation des jetons.

CodeAct réduit ce modèle -> outil -> boucle de modèle. Au lieu de demander au modèle de choisir un outil à la fois, Agent Framework peut exposer un seul execute_code outil et laisser le modèle exprimer le plan complet sous la forme d’un programme court. Les outils restent identiques, le modèle reste le même, et la modification principale est que le plan s’exécute une fois à l’intérieur d’un bac à sable au lieu d’être dispersé sur plusieurs tours d’appel d’outil.

Pour les charges de travail intensives en outils, cela peut réduire de manière significative la latence de bout en bout et l'utilisation des jetons, tout en gardant le plan compact et auditable dans un seul bloc de code. L’exemple de benchmark Hyperlight compare directement cette forme.

Quand CodeAct est bien adapté

Utilisez CodeAct lorsqu’une tâche tire parti des avantages suivants :

  • combinaison de plusieurs appels d’outils avec des boucles, un branchement, un filtrage ou une agrégation
  • transformation des résultats de l’outil avant de retourner une réponse finale
  • génération de sorties structurées ou d’artefacts informatiques plus volumineux au cours d'un processus
  • conserver certains outils disponibles uniquement à l’intérieur d’un environnement d’exécution contrôlé
  • réduction de nombreuses petites requêtes enchaînables ou calculs légers en une seule étape d’exécution

Privilégiez l’appel direct de l’outil quand :

  • la tâche n’a besoin que d’un ou deux appels d’outil, il n’y a donc que peu de surcharge d’orchestration à supprimer
  • chaque appel a des effets secondaires qui doivent rester visibles individuellement au modèle et à l’utilisateur
  • vous avez besoin d’invites d’approbation par appel au lieu d’une seule décision d’approbation pour toute l'exécution de execute_code

Comment CodeAct s’adapte à Agent Framework

Un connecteur CodeAct effectue généralement quatre opérations pour une exécution :

  1. Ajoute un execute_code outil à la surface de l'outil côté modèle.
  2. Fournit des instructions pour le runtime de bac à sable configuré.
  3. Expose éventuellement les outils appartenant au fournisseur via call_tool(...).
  4. Applique des limites de capacité telles que l’accès au système de fichiers ou les listes d’autorisation de réseau sortant.

Étant donné que le connecteur possède la configuration du runtime, les détails exacts de l’installation dépendent du serveur principal que vous choisissez.

Limitations actuelles

CodeAct est bien adapté aux flux de travail intensifs en outils, mais il existe quelques contraintes actuelles à garder à l'esprit.

  • Le connecteur Agent Framework documenté aujourd’hui est Python-first via Hyperlight CodeAct. La documentation .NET sera bientôt disponible.
  • Les approbations s’appliquent actuellement à l’appel execute_code dans son ensemble. Si vous avez besoin d’opérations individuelles pour être approuvées une par une, conservez ces opérations en tant qu’outils d’agent direct au lieu de vous appuyer sur call_tool(...).
  • Les outils accessibles via call_tool(...) sont toujours exécutés dans le processus hôte. Utilisez des outils hôtes étroits et examinés pour les E/S sensibles au lieu d’élargir inutilement l’accès au bac à sable.
  • CodeAct fonctionne mieux lorsque la surcharge d’orchestration domine. Pour les petites tâches avec seulement un ou deux appels d’outils, l’abstraction ajoutée peut ne pas vous apporter grand-chose.
  • Les noms d’outils, les métadonnées de paramètre et les formes de retour sont plus importantes ici, car le modèle écrit du code en conformité avec ce contrat plutôt que de choisir parmi un appel direct d’outil à la fois.

Get started

À venir.

Get started

Pour Python, le connecteur documenté aujourd’hui est Hyperlight CodeAct.

Le package Hyperlight fournit les éléments suivants :

  • HyperlightCodeActProvider pour les exécutions basées sur un fournisseur de contexte
  • HyperlightExecuteCodeTool lorsque vous souhaitez connecter execute_code directement
  • outils gérés par un fournisseur qui restent disponibles à l’intérieur du bac à sable via call_tool(...)
  • configuration facultative du système de fichiers et du réseau sortant pour l'environnement d'exécution en bac à sable

Consultez Hyperlight CodeAct pour l’installation, des exemples, des conseils spécifiques au runtime, tels que le moment où utiliser print(...) et /output/, et les limitations actuelles spécifiques à Hyperlight.

Étapes suivantes