Python | The .NET Blog

CodeAct in Agent Framework: Come Dimezzare la Latenza del tuo Agente

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

C’è quel momento in ogni progetto di agenti in cui guardi il trace e pensi: “perché ci vuole così tanto?” Il modello funziona bene. Gli strumenti funzionano. Ma ci sono sette round trip per ottenere un risultato che potresti calcolare in una sola volta.

Questo è esattamente il problema che CodeAct risolve — e il team di Agent Framework ha appena pubblicato il supporto alpha tramite il nuovo pacchetto agent-framework-hyperlight.

Cos’è CodeAct?

Il pattern CodeAct è elegantemente semplice: invece di dare al modello una lista di strumenti da chiamare uno alla volta, gli dai un unico strumento execute_code e lo lasci esprimere l’intero piano come un breve programma Python. L’agente scrive il codice una volta, la sandbox lo esegue, e ottieni un singolo risultato consolidato.

Approccio	Tempo	Token
Tradizionale	27,81s	6.890
CodeAct	13,23s	2.489
Miglioramento	52,4%	63,9%

La componente di sicurezza: Micro-VM Hyperlight

Il pacchetto agent-framework-hyperlight utilizza micro-VM di Hyperlight. Ogni chiamata execute_code ottiene la propria micro-VM appena creata. L’avvio si misura in millisecondi. L’isolamento è praticamente gratuito.

I tuoi strumenti continuano a girare sull’host. Il codice collante generato dal modello gira nella sandbox. Questa è la divisione giusta.

Configurazione minima

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],
)

Quando usare CodeAct (e quando no)

Usa CodeAct quando:

Il task concatena molte piccole chiamate a strumenti (lookup, join, calcoli)
La latenza e il costo dei token contano
Vuoi un isolamento forte per chiamata sul codice generato dal modello

Resta con il tool-calling tradizionale quando:

L’agente fa solo una o due chiamate a strumenti per turno
Ogni chiamata ha effetti collaterali da approvare individualmente
Le descrizioni degli strumenti sono scarse o ambigue

Provalo ora

pip install agent-framework-hyperlight --pre

Leggi il post completo sul blog di Agent Framework per una copertura più approfondita.

Dove il tuo Agente Ricorda le Cose? Guida Pratica all'Archiviazione della Cronologia Chat

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Quando costruisci un agente IA, dedichi la maggior parte dell’energia al modello, agli strumenti e ai prompt. La domanda su dove vive la cronologia della conversazione sembra un dettaglio di implementazione — ma è una delle decisioni architetturali più importanti che prenderai.

Determina se gli utenti possono ramificare le conversazioni, annullare le risposte, riprendere le sessioni dopo un riavvio e se i tuoi dati escono mai dalla tua infrastruttura. Il team di Agent Framework ha pubblicato un’analisi approfondita.

Due pattern fondamentali

Gestito dal servizio: il servizio IA archivia lo stato della conversazione. La tua app mantiene un riferimento e il servizio include automaticamente la cronologia rilevante in ogni richiesta.

Gestito dal client: la tua app mantiene la cronologia completa e invia messaggi rilevanti con ogni richiesta. Il servizio è stateless. Tu controlli tutto.

Come Agent Framework astrae questo

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mi chiamo Alice.", session);
var second = await agent.RunAsync("Come mi chiamo?", session);

session = agent.create_session()
first = await agent.run("Mi chiamo Alice.", session=session)
second = await agent.run("Come mi chiamo?", session=session)

Riferimento rapido ai provider

Provider	Archiviazione	Modello	Compattazione
OpenAI/Azure Chat Completions	Client	N/A	Tu
Foundry Agent Service	Servizio	Lineare	Servizio
Responses API (default)	Servizio	Ramificabile	Servizio
Anthropic Claude, Ollama	Client	N/A	Tu

Come scegliere

Hai bisogno di ramificazione o “annulla”? → Responses API gestito dal servizio
Hai bisogno di sovranità dei dati? → Gestito dal client con provider di database
È un semplice chatbot? → Gestito dal servizio lineare va benissimo

Leggi il post completo per l’albero decisionale completo.

Hook azd in Python, TypeScript e .NET: basta script shell

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

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai mai avuto un progetto completamente in .NET e ti sei ritrovato a scrivere script Bash solo per gli hook di azd, conosci bene quella sensazione. Perché passare alla sintassi shell per un passaggio di pre-provisioning quando tutto il resto del progetto è in C#?

Quella frustrazione ha ora una soluzione ufficiale. La CLI di Azure Developer ha appena introdotto il supporto multi-linguaggio per gli hook, ed è esattamente buono come sembra.

Gli hook, in breve

Gli hook sono script eseguiti in punti chiave del ciclo di vita di azd — prima del provisioning, dopo il deployment, e altro ancora. Definiti in azure.yaml, permettono di iniettare logica personalizzata senza modificare la CLI.

Prima erano supportati solo Bash e PowerShell. Ora si può usare Python, JavaScript, TypeScript o .NET — e azd si occupa del resto automaticamente.

Come funziona il rilevamento

Basta puntare l’hook verso un file e azd deduce il linguaggio dall’estensione:

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

Nessuna configurazione aggiuntiva. Se l’estensione è ambigua, si può aggiungere kind: python (o il linguaggio appropriato) per specificarlo esplicitamente.

Dettagli per linguaggio

Python

Inserire un requirements.txt o pyproject.toml vicino allo script (o in una directory padre). azd crea automaticamente un ambiente virtuale, installa le dipendenze ed esegue lo script.

JavaScript e TypeScript

Stesso schema — un package.json vicino allo script e azd esegue prima npm install. Per TypeScript, usa npx tsx senza step di compilazione né tsconfig.json.

.NET

Due modalità disponibili:

Modalità progetto: Se c’è un .csproj vicino allo script, azd esegue automaticamente dotnet restore e dotnet build.
Modalità single-file: Con .NET 10+, i file .cs autonomi vengono eseguiti direttamente via dotnet run script.cs. Nessun file di progetto richiesto.

Configurazione per executor

Ogni linguaggio supporta un blocco config opzionale:

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

Perché è importante per gli sviluppatori .NET

Gli hook erano l’ultimo posto in un progetto basato su azd che costringeva a cambiare linguaggio. Ora l’intera pipeline di deployment può vivere in un unico linguaggio. È possibile riutilizzare le utility .NET esistenti negli hook, referenziare librerie condivise ed eliminare la manutenzione di script shell.

Conclusione

Uno di quei cambiamenti che sembrano piccoli ma che riducono concretamente la frizione quotidiana con azd. Il supporto multi-linguaggio per gli hook è disponibile ora — tutti i dettagli nel post ufficiale.