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 d’IA modernes ne sont souvent pas limités par la qualité du modèle, mais par la surcharge liée à l’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 gourmandes en outils, cette modification peut réduire matériellement la latence de bout en bout et l’utilisation des jetons tout en conservant le plan compact et auditable dans un bloc de code. Consultez l’intégration d’Hyperlight CodeAct pour une comparaison de câblage côte à côte.

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

Restez avec les appels directs aux outils lorsque :

  • la tâche ne nécessite qu’un ou deux appels d’outils, il y a donc peu de surcharge d’orchestration à éliminer
  • 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

Warning

La combinaison de FIDES avec les fournisseurs CodeAct actuels n’est pas prise en charge. FIDES est actuellement uniquement disponible pour Python et n'est pas disponible dans les fournisseurs CodeAct pour .NET.

Les appels de l’outil hôte géré par le fournisseur à l’intérieur du code généré ne passent pas par le pipeline d’intergiciel par fonction de l’agent. Les vérifications sur les outils d’agent direct ou l’appel externe execute_code n’établissent pas d’application FIDES pour les appels imbriqués ou les valeurs intermédiaires internes du code. Ils ne couvrent pas non plus les capacités liées aux fichiers ou au réseau.

Les outils hôtes doivent appliquer leurs propres contrôles d’autorisation et de destination. Conservez les outils dépendants de FIDES en tant qu’outils d’agent direct, pas les outils gérés par CodeAct ou laissez CodeAct désactivé pour les flux de travail qui nécessitent ces garanties. Cette limite de compatibilité est une limitation d’intégration actuelle, et non une limitation inhérente du modèle CodeAct. Consultez Sécurité de l’agent avec FIDES.

CodeAct est un bon ajustement pour les flux de travail gourmands en outils, mais gardez à l’esprit les contraintes suivantes :

  • Hyperlight CodeAct prend en charge Python et .NET. Monty est Python-only ; Local CodeAct est .NET uniquement.
  • 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 être utile.
  • 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

Pour .NET, Hyperlight CodeAct est fourni sous forme de Microsoft.Agents.AI.Hyperlight package NuGet. Local CodeAct exécute du code Python généré dans un sous-processus et s’appuie sur l’isolation externe.

Le package Hyperlight fournit les éléments suivants :

  • HyperlightCodeActProvider — un AIContextProvider qui injecte execute_code et les instructions CodeAct à chaque exécution
  • HyperlightExecuteCodeFunction — un composant autonome AIFunction pour un câblage statique ou manuel lorsque la configuration de la sandbox est fixe
  • outils gérés par un fournisseur qui restent disponibles à l’intérieur du bac à sable via call_tool(...)
  • Intégration de CodeActApprovalMode et de ApprovalRequiredAIFunction pour les approbations
  • configuration facultative du système de fichiers (FileMounts, HostInputDirectory) et du réseau sortant (AllowedDomains) pour le runtime de bac à sable

Important

Le package .NET est en préversion et dépend de Hyperlight.HyperlightSandbox.Api NuGet, qui n'est pas encore publié sur nuget.org. Consultez Hyperlight CodeAct pour connaître les mises en garde d’installation et les exigences de plateforme actuelles.

Consultez Hyperlight CodeAct pour obtenir des conseils spécifiques à l’installation, aux exemples et au runtime.

Get started

Pour Python, utilisez Hyperlight CodeAct pour un bac à sable isolé ou Monty pour un interpréteur restreint multiplateforme.

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.

Note

La prise en charge de cette fonctionnalité dans Go sera disponible prochainement. Consultez le référentiel Agent Framework Go pour connaître l’état le plus récent.

Étapes suivantes

Sécurité de l’agent

Contenu connexe

  • Dernière mise à jour :