Python | The .NET Blog

CodeAct no Agent Framework: Como Reduzir a Latência do seu Agente pela Metade

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Existe aquele momento em todo projeto de agentes em que você olha para o trace e pensa: “por que isso está demorando tanto?” O modelo está ótimo. As ferramentas funcionam. Mas há sete round trips para obter um resultado que poderia ser calculado de uma só vez.

Esse é exatamente o problema que o CodeAct resolve — e a equipe do Agent Framework acabou de lançar suporte alpha via o novo pacote agent-framework-hyperlight.

O que é CodeAct?

O padrão CodeAct é elegantemente simples: em vez de dar ao modelo uma lista de ferramentas para chamar uma por uma, você dá a ele uma única ferramenta execute_code e deixa-o expressar o plano completo como um curto programa Python. O agente escreve o código uma vez, o sandbox o executa, e você recebe de volta um único resultado consolidado.

Fiação	Tempo	Tokens
Tradicional	27,81s	6.890
CodeAct	13,23s	2.489
Melhoria	52,4%	63,9%

A peça de segurança: Micro-VMs do Hyperlight

O pacote agent-framework-hyperlight usa micro-VMs do Hyperlight. Cada chamada execute_code obtém sua própria micro-VM recém-criada. A inicialização é medida em milissegundos. O isolamento é essencialmente gratuito.

Suas ferramentas continuam sendo executadas no host. O código de cola gerado pelo modelo é executado no sandbox. Essa é a divisão correta.

Configuração mínima

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 usar o CodeAct (e quando não usar)

Use o CodeAct quando:

A tarefa encadeia muitas chamadas pequenas de ferramentas (lookups, joins, cálculos)
A latência e o custo de tokens importam
Você quer isolamento forte por chamada no código gerado pelo modelo

Fique com o tool-calling tradicional quando:

O agente só faz uma ou duas chamadas de ferramentas por turno
Cada chamada tem efeitos colaterais a serem aprovados individualmente
As descrições de ferramentas são esparsas ou ambíguas

Experimente agora

pip install agent-framework-hyperlight --pre

Confira o post completo no blog do Agent Framework para uma cobertura mais profunda.

Onde seu Agente se Lembra das Coisas? Guia Prático de Armazenamento do Histórico de Chat

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Ao criar um agente IA, você gasta a maior parte da energia no modelo, nas ferramentas e nos prompts. A pergunta de onde vive o histórico de conversa parece um detalhe de implementação — mas é uma das decisões arquiteturais mais importantes que você tomará.

Ela determina se usuários podem bifurcar conversas, desfazer respostas, retomar sessões após uma reinicialização e se seus dados saem da sua infraestrutura. A equipe do Agent Framework publicou uma análise aprofundada.

Dois padrões fundamentais

Gerenciado pelo serviço: o serviço IA armazena o estado da conversa. Seu app mantém uma referência e o serviço inclui automaticamente o histórico relevante em cada requisição.

Gerenciado pelo cliente: seu app mantém o histórico completo e envia mensagens relevantes com cada requisição. O serviço é stateless. Você controla tudo.

Como o Agent Framework abstrai isso

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Meu nome é Alice.", session);
var second = await agent.RunAsync("Qual é o meu nome?", session);

session = agent.create_session()
first = await agent.run("Meu nome é Alice.", session=session)
second = await agent.run("Qual é o meu nome?", session=session)

Referência rápida de provedores

Provedor	Armazenamento	Modelo	Compactação
OpenAI/Azure Chat Completions	Cliente	N/A	Você
Foundry Agent Service	Serviço	Linear	Serviço
Responses API (padrão)	Serviço	Ramificável	Serviço
Anthropic Claude, Ollama	Cliente	N/A	Você

Como escolher

Precisa de ramificação ou “desfazer”? → Responses API gerenciado pelo serviço
Precisa de soberania de dados? → Gerenciado pelo cliente com provedor de banco de dados
É um chatbot simples? → Gerenciado pelo serviço linear está ótimo

Leia o post completo para a árvore de decisão completa.

Hooks do azd em Python, TypeScript e .NET: chega de scripts shell

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

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Se você já teve um projeto completamente em .NET e mesmo assim precisou escrever scripts Bash para os hooks do azd, conhece bem essa dor. Por que mudar para sintaxe de shell num passo de pré-provisioning quando tudo o mais no projeto é C#?

Essa frustração agora tem uma solução oficial. A CLI do Azure Developer acaba de lançar suporte a múltiplos idiomas para hooks, e é exatamente tão bom quanto parece.

Hooks, brevemente

Hooks são scripts que rodam em pontos-chave do ciclo de vida do azd — antes do provisioning, após o deployment e mais. São definidos no azure.yaml e permitem injetar lógica customizada sem modificar a CLI.

Antes, apenas Bash e PowerShell eram suportados. Agora você pode usar Python, JavaScript, TypeScript ou .NET — e o azd cuida do resto automaticamente.

Como funciona a detecção

Basta apontar o hook para um arquivo e o azd infere o idioma pela extensão:

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

Sem configuração extra. Se a extensão for ambígua, você pode adicionar kind: python (ou o que for) para especificar explicitamente.

Detalhes por linguagem

Python

Coloque um requirements.txt ou pyproject.toml ao lado do script (ou em um diretório pai). O azd cria automaticamente um ambiente virtual, instala dependências e executa o script.

JavaScript e TypeScript

Mesmo padrão — coloque um package.json perto do script e o azd executará npm install primeiro. Para TypeScript, usa npx tsx sem etapa de compilação e sem tsconfig.json.

.NET

Dois modos disponíveis:

Modo projeto: Se houver um .csproj ao lado do script, o azd executa dotnet restore e dotnet build automaticamente.
Modo single-file: No .NET 10+, arquivos .cs independentes executam diretamente via dotnet run script.cs. Sem arquivo de projeto.

Configuração por executor

Cada linguagem suporta um bloco config opcional:

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

Por que isso importa para desenvolvedores .NET

Os hooks eram o último lugar num projeto baseado em azd que forçava uma troca de linguagem. Agora todo o pipeline de deployment pode viver em um único idioma. Você pode reutilizar utilitários .NET existentes em hooks, referenciar bibliotecas compartilhadas e abandonar a manutenção de scripts shell.

Conclusão

Um desses mudanças que parecem pequenas, mas que removem muita fricção do dia a dia com azd. O suporte multi-linguagem para hooks já está disponível — confira o post oficial para a documentação completa.