Python | The .NET Blog

CodeAct w Agent Framework: Jak zmniejszyć opóźnienie agenta o połowę

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

Ten post został przetłumaczony automatycznie. Aby zobaczyć oryginalną wersję, kliknij tutaj.

W każdym projekcie agentów przychodzi moment, gdy patrzysz na ślad i myślisz: „Dlaczego to tak długo trwa?" Model działa dobrze. Narzędzia działają. Ale jest siedem rund komunikacji, żeby uzyskać wynik, który można obliczyć za jednym razem.

To właśnie problem, który rozwiązuje CodeAct — a zespół Agent Framework właśnie wydał wsparcie alfa przez nowy pakiet agent-framework-hyperlight.

Czym jest CodeAct?

Wzorzec CodeAct jest elegancko prosty: zamiast dawać modelowi listę narzędzi do wywoływania jedno po drugim, dajesz mu jedno narzędzie execute_code i pozwalasz wyrazić cały plan jako krótki program w Pythonie.

Podejście	Czas	Tokeny
Tradycyjne	27,81s	6 890
CodeAct	13,23s	2 489
Poprawa	52,4%	63,9%

Bezpieczeństwo: Mikro-VM Hyperlight

Pakiet agent-framework-hyperlight używa mikro-VM Hyperlight. Każde wywołanie execute_code otrzymuje własną, świeżo utworzoną mikro-VM. Uruchomienie mierzone jest w milisekundach. Izolacja jest praktycznie bezpłatna.

Twoje narzędzia nadal działają na hoście. Kod kleju wygenerowany przez model działa w piaskownicy. To właściwy podział.

Minimalna konfiguracja

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

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

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

Kiedy używać CodeAct (a kiedy nie)

Używaj CodeAct, gdy:

Zadanie łączy wiele małych wywołań narzędzi (wyszukiwania, łączenia, obliczenia)
Ważne są opóźnienie i koszt tokenów
Potrzebujesz silnej izolacji dla kodu generowanego przez model

Zostań przy tradycyjnym wywołaniu narzędzi, gdy:

Agent robi tylko jedno lub dwa wywołania na turę
Każde wywołanie ma skutki uboczne wymagające indywidualnego zatwierdzenia
Opisy narzędzi są skąpe lub niejednoznaczne

Wypróbuj teraz

pip install agent-framework-hyperlight --pre

Przeczytaj pełny post na blogu Agent Framework.

Gdzie Twój Agent Pamięta Rzeczy? Praktyczny Przewodnik po Przechowywaniu Historii Czatu

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

Ten post został automatycznie przetłumaczony. Aby zobaczyć oryginalną wersję, kliknij tutaj.

Budując agenta AI, większość energii poświęcasz na model, narzędzia i prompty. Pytanie gdzie żyje historia rozmowy wydaje się szczegółem implementacyjnym — ale jest jedną z najważniejszych decyzji architektonicznych, jakie podejmiesz.

Decyduje o tym, czy użytkownicy mogą rozgałęziać rozmowy, cofać odpowiedzi, wznawiać sesje po restarcie oraz czy Twoje dane kiedykolwiek opuszczają Twoją infrastrukturę. Zespół Agent Framework opublikował szczegółową analizę.

Dwa podstawowe wzorce

Zarządzane przez usługę: usługa AI przechowuje stan rozmowy. Twoja aplikacja trzyma referencję, a usługa automatycznie dołącza odpowiednią historię do każdego żądania.

Zarządzane przez klienta: Twoja aplikacja utrzymuje pełną historię i wysyła odpowiednie wiadomości z każdym żądaniem. Usługa jest bezstanowa. Kontrolujesz wszystko.

Jak Agent Framework to abstrahuje

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mam na imię Alice.", session);
var second = await agent.RunAsync("Jak mam na imię?", session);

session = agent.create_session()
first = await agent.run("Mam na imię Alice.", session=session)
second = await agent.run("Jak mam na imię?", session=session)

Szybki przegląd dostawców

Dostawca	Przechowywanie	Model	Kompaktowanie
OpenAI/Azure Chat Completions	Klient	N/A	Ty
Foundry Agent Service	Usługa	Liniowy	Usługa
Responses API (domyślnie)	Usługa	Rozgałęziający	Usługa
Anthropic Claude, Ollama	Klient	N/A	Ty

Jak wybrać

Potrzebujesz rozgałęzień lub „cofnij"? → Responses API zarządzane przez usługę
Potrzebujesz suwerenności danych? → Zarządzane przez klienta z backendem DB
Prosty chatbot? → Liniowe zarządzane przez usługę wystarczy

Przeczytaj pełny post po kompletne drzewo decyzyjne.

Hooki azd w Python, TypeScript i .NET: koniec ze skryptami shell

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

Ten artykuł został przetłumaczony automatycznie. Aby zobaczyć oryginalną wersję, kliknij tutaj.

Jeśli kiedykolwiek miałeś projekt w całości napisany w .NET i mimo to musiałeś pisać skrypty Bash dla hooków azd — znasz ten ból. Po co przełączać się na składnię shell w kroku pre-provisioning, skoro reszta projektu to C#?

Ta frustracja ma teraz oficjalne rozwiązanie. Azure Developer CLI właśnie wprowadził obsługę wielu języków dla hooków, i jest dokładnie tak dobre, jak brzmi.

Czym są hooki

Hooki to skrypty wykonywane w kluczowych punktach cyklu życia azd — przed provisioningiem, po deploymencie i nie tylko. Definiuje się je w azure.yaml i pozwalają na wstrzyknięcie własnej logiki bez modyfikowania CLI.

Wcześniej obsługiwane były tylko Bash i PowerShell. Teraz można używać Pythona, JavaScript, TypeScript lub .NET — resztą zajmuje się azd automatycznie.

Jak działa wykrywanie

Wystarczy wskazać hook na plik, a azd wywnioskuje język z rozszerzenia:

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

Bez dodatkowej konfiguracji. Jeśli rozszerzenie jest niejednoznaczne, można jawnie podać kind: python (lub odpowiedni język).

Ważne szczegóły według języka

Python

Umieść requirements.txt lub pyproject.toml obok skryptu (lub w dowolnym katalogu nadrzędnym). azd automatycznie tworzy środowisko wirtualne, instaluje zależności i uruchamia skrypt.

JavaScript i TypeScript

Ten sam wzorzec — package.json blisko skryptu, a azd najpierw wykona npm install. Dla TypeScript używa npx tsx bez etapu kompilacji i bez tsconfig.json.

.NET

Dwa dostępne tryby:

Tryb projektu: jeśli obok skryptu jest .csproj, azd automatycznie uruchamia dotnet restore i dotnet build.
Tryb single-file: na .NET 10+ samodzielne pliki .cs uruchamiają się bezpośrednio przez dotnet run script.cs. Plik projektu nie jest wymagany.

Konfiguracja dla konkretnego executora

Każdy język obsługuje opcjonalny blok config:

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

Dlaczego to ważne dla programistów .NET

Hooki były ostatnim miejscem w projekcie opartym na azd, które wymuszało zmianę języka. Teraz cały pipeline deploymentu — od kodu aplikacji po hooki cyklu życia — może żyć w jednym języku. Można ponownie wykorzystywać istniejące narzędzia .NET w hookach, referencować współdzielone biblioteki i porzucić utrzymywanie skryptów shell.

Podsumowanie

Jedna z tych zmian, które wydają się drobne, ale naprawdę redukują codzienne tarcia w pracy z azd. Obsługa wielu języków dla hooków jest dostępna teraz — pełna dokumentacja w oficjalnym poście.