Python | The .NET Blog

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Es gibt diesen Moment in jedem Agenten-Projekt, wo man auf den Trace schaut und denkt: „Warum dauert das so lange?" Das Modell ist gut. Die Tools funktionieren. Aber es gibt sieben Round Trips für ein Ergebnis, das man in einem Schritt berechnen könnte.

Genau dieses Problem löst CodeAct — und das Agent Framework Team hat soeben Alpha-Unterstützung dafür veröffentlicht mit dem neuen Paket agent-framework-hyperlight.

Was ist CodeAct?

Das CodeAct-Muster ist elegant einfach: Statt dem Modell eine Liste von Tools zu geben und sie einzeln aufrufen zu lassen, gibst du ihm ein einziges execute_code-Tool und lässt es den gesamten Plan als kurzes Python-Programm ausdrücken. Der Agent schreibt den Code einmal, die Sandbox führt ihn aus, und du erhältst ein einziges konsolidiertes Ergebnis zurück.

Ein Fünf-Schritte-Plan, der früher fünf Modell-Turns benötigte, wird zu einem einzigen execute_code-Turn mit einem Python-Script, das deine Tools über call_tool(...) aufruft.

Verdrahtung	Zeit	Tokens
Traditionell	27,81s	6.890
CodeAct	13,23s	2.489
Verbesserung	52,4%	63,9%

Die Sicherheitskomponente: Hyperlight Micro-VMs

Das Paket agent-framework-hyperlight verwendet Hyperlight Micro-VMs. Jeder execute_code-Aufruf erhält eine eigene frisch erstellte Micro-VM — mit eigenem Speicher, ohne Zugriff auf das Host-Dateisystem außer dem, was du explizit mountest. Der Start wird in Millisekunden gemessen. Die Isolierung ist im Grunde kostenlos.

Deine Tools laufen weiterhin auf dem Host. Der modellgenerierte Klebecode läuft in der Sandbox. Das ist die richtige Aufteilung.

Einrichtung

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

Wann CodeAct verwenden (und wann nicht)

CodeAct verwenden, wenn:

Die Aufgabe viele kleine Tool-Aufrufe verkettet (Lookups, Joins, Berechnungen)
Latenz und Token-Kosten wichtig sind
Du starke Isolierung für modellgenerierten Code willst

Beim traditionellen Tool-Calling bleiben, wenn:

Der Agent nur ein oder zwei Tool-Aufrufe pro Turn macht
Jeder Aufruf Nebeneffekte hat, die einzeln genehmigt werden sollen
Tool-Beschreibungen spärlich oder mehrdeutig sind

Jetzt ausprobieren

pip install agent-framework-hyperlight --pre

Den vollständigen Beitrag findest du im Agent Framework Blog.

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Beim Aufbau eines KI-Agenten investierst du die meiste Energie in Modell, Tools und Prompts. Die Frage, wo der Gesprächsverlauf lebt, scheint ein Implementierungsdetail — ist aber eine der wichtigsten Architekturentscheidungen, die du treffen wirst.

Sie bestimmt, ob Nutzer Gespräche verzweigen, Antworten rückgängig machen, Sitzungen nach einem Neustart fortsetzen können und ob deine Daten deine Infrastruktur jemals verlassen.

Zwei grundlegende Muster

Service-managed: Der KI-Dienst speichert den Gesprächszustand. Deine App hält eine Referenz und der Dienst fügt automatisch den relevanten Verlauf in jede Anfrage ein.

Client-managed: Deine App verwaltet den vollständigen Verlauf und sendet relevante Nachrichten mit jeder Anfrage. Der Dienst ist zustandslos. Du kontrollierst alles.

Wie Agent Framework das abstrahiert

// C# — funktioniert gleich, unabhängig vom Provider
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mein Name ist Alice.", session);
var second = await agent.RunAsync("Wie ist mein Name?", session);

# Python
session = agent.create_session()
first = await agent.run("Mein Name ist Alice.", session=session)
second = await agent.run("Wie ist mein Name?", session=session)

Provider-Schnellreferenz

Provider	Speicherort	Modell	Komprimierung
OpenAI/Azure Chat Completions	Client	N/A	Du
Foundry Agent Service	Service	Linear	Service
Responses API (Standard)	Service	Verzweigend	Service
Anthropic Claude, Ollama	Client	N/A	Du

Wie du die Wahl triffst

Brauchst du Verzweigung oder „Rückgängig"? → Responses API service-managed
Brauchst du vollständige Datensouveränität? → Client-managed mit datenbankgestütztem Provider
Ist es ein einfacher Chatbot? → Service-managed linear reicht
Brauchst du Portabilität zwischen Providern? → Client-managed bietet Portabilität

Lies den vollständigen Beitrag für den vollständigen Entscheidungsbaum.

azd-Hooks in Python, TypeScript und .NET: Schluss mit Shell-Skripten

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Wer schon einmal ein vollständig in .NET geschriebenes Projekt hatte und trotzdem Bash-Skripte für azd-Hooks schreiben musste, kennt den Schmerz. Warum in Shell-Syntax wechseln für einen Pre-Provisioning-Schritt, wenn der Rest des Projekts C# ist?

Diese Frustration hat jetzt eine offizielle Lösung. Die Azure Developer CLI hat Multi-Sprachen-Unterstützung für Hooks eingeführt, und es ist genauso gut wie es klingt.

Was sind Hooks?

Hooks sind Skripte, die an wichtigen Punkten im azd-Lebenszyklus ausgeführt werden — vor dem Provisioning, nach dem Deployment und mehr. Sie werden in azure.yaml definiert und ermöglichen die Injektion von benutzerdefinierter Logik ohne Änderungen an der CLI.

Bisher wurden nur Bash und PowerShell unterstützt. Jetzt kann man Python, JavaScript, TypeScript oder .NET verwenden — und azd erledigt den Rest automatisch.

Wie die Erkennung funktioniert

Man verweist den Hook auf eine Datei, und azd leitet die Sprache aus der Dateiendung ab:

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

Keine zusätzliche Konfiguration. Bei mehrdeutigen Endungen kann man kind: python (oder die entsprechende Sprache) explizit angeben.

Sprachspezifische Details

Python

Eine requirements.txt oder pyproject.toml neben dem Skript ablegen (oder in einem übergeordneten Verzeichnis). azd erstellt automatisch eine virtuelle Umgebung, installiert Abhängigkeiten und führt das Skript aus.

JavaScript und TypeScript

Dasselbe Muster — eine package.json in der Nähe des Skripts, und azd führt zuerst npm install aus. Für TypeScript wird npx tsx verwendet, ohne Kompilierungsschritt und ohne tsconfig.json.

.NET

Zwei Modi verfügbar:

Projektmodus: Liegt eine .csproj neben dem Skript, führt azd automatisch dotnet restore und dotnet build aus.
Single-File-Modus: Ab .NET 10+ können eigenständige .cs-Dateien direkt via dotnet run script.cs ausgeführt werden. Kein Projektdatei erforderlich.

Executor-spezifische Konfiguration

Jede Sprache unterstützt einen optionalen config-Block:

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

Warum das für .NET-Entwickler wichtig ist

Hooks waren der letzte Ort in einem azd-basierten Projekt, der einen Sprachwechsel erzwang. Jetzt kann die gesamte Deployment-Pipeline — App-Code, Infrastrukturskripte und Lifecycle-Hooks — in einer einzigen Sprache leben. Bestehende .NET-Utilities lassen sich in Hooks wiederverwenden, gemeinsame Bibliotheken referenzieren, und Shell-Skript-Pflege entfällt.

Fazit

Einer dieser Änderungen, die klein klingen, aber täglich Reibung aus dem azd-Workflow nehmen. Multi-Sprachen-Hook-Unterstützung ist jetzt verfügbar — alle Details im offiziellen Post.