Python | The .NET Blog

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Il y a ce moment dans tout projet d’agents où vous regardez la trace et pensez : « pourquoi est-ce que ça prend autant de temps ? » Le modèle est bien. Les outils fonctionnent. Mais il y a sept allers-retours pour obtenir un résultat qu’on pourrait calculer en une seule fois.

C’est exactement le problème que CodeAct résout — et l’équipe Agent Framework vient de publier un support alpha via le nouveau paquet agent-framework-hyperlight.

Qu’est-ce que CodeAct ?

Le pattern CodeAct est élégamment simple : au lieu de donner au modèle une liste d’outils à appeler un par un, vous lui donnez un seul outil execute_code et le laissez exprimer le plan complet comme un court programme Python. L’agent écrit le code une fois, le sandbox l’exécute, et vous récupérez un seul résultat consolidé.

Câblage	Temps	Tokens
Traditionnel	27,81s	6 890
CodeAct	13,23s	2 489
Amélioration	52,4%	63,9%

Sécurité : Micro-VMs Hyperlight

Le paquet agent-framework-hyperlight utilise des micro-VMs Hyperlight. Chaque appel execute_code obtient sa propre micro-VM fraîchement créée. Le démarrage se mesure en millisecondes. L’isolation est pratiquement gratuite.

Vos outils continuent de s’exécuter sur l’hôte. Le code de collage généré par le modèle s’exécute dans le sandbox. C’est le bon découpage.

Configuration minimale

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Utilisez CodeAct quand :

La tâche enchaîne de nombreux petits appels d’outils (lookups, jointures, calculs)
La latence et le coût en tokens comptent
Vous voulez une isolation forte par appel pour le code généré par le modèle

Restez avec le tool-calling traditionnel quand :

L’agent ne fait qu’un ou deux appels d’outils par tour
Chaque appel a des effets secondaires à approuver individuellement
Les descriptions d’outils sont peu détaillées

Essayez maintenant

pip install agent-framework-hyperlight --pre

Consultez le post complet sur le blog Agent Framework pour une couverture approfondie.

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Lors de la création d’un agent IA, vous consacrez la majeure partie de votre énergie au modèle, aux outils et aux prompts. La question de l’endroit où vit l’historique des conversations semble être un détail d’implémentation — mais c’est l’une des décisions architecturales les plus importantes que vous prendrez.

Elle détermine si les utilisateurs peuvent bifurquer des conversations, annuler des réponses, reprendre des sessions après un redémarrage, et si vos données quittent jamais votre infrastructure. L’équipe Agent Framework a publié une analyse approfondie.

Deux modèles fondamentaux

Géré par le service : le service IA stocke l’état de la conversation. Votre application tient une référence et le service inclut automatiquement l’historique pertinent dans chaque requête.

Géré par le client : votre application maintient l’historique complet et envoie les messages pertinents avec chaque requête. Le service est sans état. Vous contrôlez tout.

Comment Agent Framework abstrait cela

// C# — fonctionne pareil quel que soit le fournisseur
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Je m'appelle Alice.", session);
var second = await agent.RunAsync("Quel est mon nom ?", session);

# Python
session = agent.create_session()
first = await agent.run("Je m'appelle Alice.", session=session)
second = await agent.run("Quel est mon nom ?", session=session)

Référence rapide des fournisseurs

Fournisseur	Stockage	Modèle	Compaction
OpenAI/Azure Chat Completions	Client	N/A	Vous
Foundry Agent Service	Service	Linéaire	Service
Responses API (défaut)	Service	Bifurquant	Service
Anthropic Claude, Ollama	Client	N/A	Vous

Comment choisir

Besoin de bifurcation ou « annuler » ? → Responses API géré par service
Besoin de souveraineté des données ? → Géré par client avec fournisseur base de données
Simple chatbot ? → Géré par service linéaire suffit

Lisez le post complet pour l’arbre de décision complet.

Hooks azd en Python, TypeScript et .NET : fini les scripts shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Vous avez déjà eu un projet entièrement en .NET et vous avez quand même dû écrire des scripts Bash pour les hooks azd ? Vous connaissez la douleur. Pourquoi basculer vers la syntaxe shell pour une étape de pré-provisioning quand tout le reste du projet est en C# ?

Cette frustration a maintenant une solution officielle. La CLI Azure Developer vient de publier la prise en charge multi-langages pour les hooks, et c’est exactement aussi bien que ça en a l’air.

Les hooks, en bref

Les hooks sont des scripts qui s’exécutent à des moments clés du cycle de vie d’azd — avant le provisioning, après le déploiement, etc. Définis dans azure.yaml, ils permettent d’injecter de la logique personnalisée sans modifier la CLI.

Avant, seuls Bash et PowerShell étaient supportés. Maintenant, on peut utiliser Python, JavaScript, TypeScript ou .NET — et azd s’occupe du reste automatiquement.

Comment fonctionne la détection

Il suffit de pointer le hook vers un fichier et azd déduit le langage à partir de l’extension :

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Pas de configuration supplémentaire. Si l’extension est ambiguë, on peut ajouter kind: python (ou le langage correspondant) pour le préciser.

Détails par langage

Python

Placer un requirements.txt ou pyproject.toml à côté du script (ou dans un répertoire parent). azd crée automatiquement un environnement virtuel, installe les dépendances et exécute le script.

JavaScript et TypeScript

Même principe — un package.json près du script, et azd exécute d’abord npm install. Pour TypeScript, il utilise npx tsx sans étape de compilation et sans tsconfig.json.

.NET

Deux modes disponibles :

Mode projet : Si un .csproj est présent à côté du script, azd exécute automatiquement dotnet restore et dotnet build.
Mode single-file : Sur .NET 10+, les fichiers .cs autonomes s’exécutent directement via dotnet run script.cs. Aucun fichier de projet requis.

Configuration par exécuteur

Chaque langage supporte un bloc config optionnel :

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Pourquoi c’est important pour les développeurs .NET

Les hooks étaient le dernier endroit dans un projet azd qui forçait à changer de langage. Maintenant, l’intégralité du pipeline de déploiement peut vivre dans un seul langage. Il devient possible de réutiliser les utilitaires .NET existants dans les hooks, de référencer des bibliothèques partagées et d’abandonner la maintenance de scripts shell.

Conclusion

Un de ces changements qui paraissent anodins mais qui réduisent concrètement la friction au quotidien avec azd. Le support multi-langages pour les hooks est disponible maintenant — tous les détails dans le post officiel.