Python 2026 – Leitfaden für wichtige Änderungen

Dieses Dokument listet alle wichtigen Änderungen in Python-Versionen seit Anfang 2026 auf, darunter wichtige Änderungen und wichtige Verbesserungen, die sich auf Ihren Code auswirken können. Jede Änderung wird markiert als:

• 🔴 Kompatibilitätsbruch – Erfordert Codeänderungen für das Upgrade
• 🟡 Verbesserung — Neue Funktion oder Verbesserung; Vorhandener Code funktioniert weiterhin

In diesem Dokument werden die bedeutenden Python-Änderungen im Übergang von 2026 preview-to-1.0.0 nachverfolgt. Bitte lesen Sie es also beim Upgrade zwischen Versionen, um sicherzustellen, dass Sie keine wichtigen Änderungen verpassen. Detaillierte Upgradeanweisungen zu bestimmten Themen (z. B. Optionenmigration) finden Sie in den verknüpften Upgradeleitfäden oder den verknüpften PR.

python-1.0.0

In diesem Abschnitt werden die signifikanten Python-Änderungen erfasst, die nach python-1.0.0rc6 erfolgten und die jetzt Teil von python-1.0.0 sind.

🔴 Message(..., text=...) Konstruktion ist nun vollständig entfernt

PR:#5062

PR #5062 schließt die frühere Python-Nachrichtenmodellbereinigung ab, indem die letzten frameworkseitigen Codepfade entfernt werden, die nach wie vor Message-Objekte mit text=... konstruierten.

• Erstellen von Textnachrichten als Message(role="user", contents=["Hello"]) anstatt Message(role="user", text="Hello").
• Dies gilt überall, wo Sie Nachrichten direkt erstellen, einschließlich Workflowanforderungen, benutzerdefinierte Middleware-Antworten, Orchestrierungshilfsprogramme und Migrationscode.
• Einfache Zeichenfolgen innerhalb contents=[...] werden immer noch automatisch in Textinhalte normalisiert, sodass contents=["Hello"] die einfachste Nur-Text-Form bleibt.

Before:

message = Message(role="assistant", text="Hello")

After:

message = Message(role="assistant", contents=["Hello"])

🟡 Veröffentlichte Python-Pakete sind nicht mehr erforderlich --pre

PR:#5062

PR #5062 aktualisiert die wichtigsten Python-Pakete auf 1.0.0 und aktualisiert die Installationsanleitungen, um zwischen veröffentlichten Paketen und Paketen, die noch als Vorabversion verfügbar sind, zu unterscheiden.

• agent-framework, agent-framework-core, agent-framework-openai und agent-framework-foundry sind jetzt freigegebene Pakete und erfordern kein --pre mehr.
• Beta-Connectors wie agent-framework-ag-ui, agent-framework-azurefunctions, agent-framework-copilotstudio, agent-framework-foundry-local, agent-framework-github-copilot, agent-framework-mem0 und agent-framework-ollama erfordern immer noch --pre.
• Wenn ein einzelner Installationsbefehl ein Betapaket enthält, behalten Sie diesen Befehl --pre bei.

🔴 Foundry besitzt jetzt Python-Einbettungen und Modelle-Endpunkteinstellungen

PR:#5056

PR #5056 entfernt das eigenständige agent-framework-azure-ai Paket und verschiebt die Python-Einbettungsoberfläche auf agent-framework-foundry und agent_framework.foundry.

• Verwenden Sie FoundryEmbeddingClient, FoundryEmbeddingOptions, und FoundryEmbeddingSettings von agent_framework.foundry.
• Installieren Sie agent-framework-foundry für den Foundry-Chat, vom Dienst verwaltete Agenten, Speicheranbieter und Einbettungen.
• agent_framework.azure exportiert AzureAIInferenceEmbeddingClient nicht mehr, AzureAIInferenceEmbeddingOptions, AzureAIInferenceEmbeddingSettings oder AzureAISettings.
• Gießereieinbettungen verwenden jetzt FOUNDRY_MODELS_ENDPOINT, FOUNDRY_MODELS_API_KEY, FOUNDRY_EMBEDDING_MODEL und optional FOUNDRY_IMAGE_EMBEDDING_MODEL.
• FoundryChatClient und FoundryAgent verwenden weiterhin Projekteinstellungen für Endpunkte, z.B. FOUNDRY_PROJECT_ENDPOINT und FOUNDRY_MODEL.

Before:

import os

from agent_framework.azure import AzureAIInferenceEmbeddingClient

client = AzureAIInferenceEmbeddingClient(
    endpoint=os.environ["AZURE_AI_SERVICES_ENDPOINT"],
    model=os.environ["AZURE_AI_EMBEDDING_NAME"],
    credential=credential,
)

After:

import os

from agent_framework.foundry import FoundryEmbeddingClient

client = FoundryEmbeddingClient(
    endpoint=os.environ["FOUNDRY_MODELS_ENDPOINT"],
    api_key=os.environ["FOUNDRY_MODELS_API_KEY"],
    model=os.environ["FOUNDRY_EMBEDDING_MODEL"],
)

🔴 Workflows leiten jetzt Laufzeit-Kwargs über explizite Buckets weiter.

PR:#5010

PR #5010 aktualisiert Python workflow.run(...), sodass Laufzeit-Kwargs explizit als function_invocation_kwargs= und client_kwargs= und nicht als generisch weitergeleitete **kwargs übergeben werden.

• Eine flache Abbildung wird als global behandelt und an jeden passenden Agent-Executor im Workflow weitergeleitet.
• Wenn ein oder mehrere Top-Level-Schlüssel mit den Executor-IDs übereinstimmen, wird die gesamte Zuordnung als auf individuelle Executor ausgerichtet behandelt, und jeder Executor erhält nur seinen eigenen Eintrag.
• Benutzerdefinierte AgentExecutor(id="...") und andere explizite Workflowausführer-IDs sind die Schlüssel, auf die Sie abzielen.
• Die gleichen Regeln für globale vs. gezielte Anwendungen gelten sowohl für function_invocation_kwargs als auch für client_kwargs.

Before:

await workflow.run(
    "Draft the report",
    db_config={"connection_string": "..."},
    user_preferences={"format": "markdown"},
)

After:

await workflow.run(
    "Draft the report",
    function_invocation_kwargs={
        "researcher": {
            "db_config": {"connection_string": "..."},
        },
        "writer": {
            "user_preferences": {"format": "markdown"},
        },
    },
)

🟡 GitHubCopilotAgent führt jetzt um jeden Aufruf herum Kontextanbieter aus.

PR:#5013

PR #5013 behebt eine Python-Verhaltenslücke, bei der GitHubCopilotAgent zwar context_providers akzeptiert wurde, jedoch nicht tatsächlich aufgerufen wurden.

• before_run() wird jetzt ausgeführt, bevor die Copilot-Eingabeaufforderung gesendet wird.
• Vom Anbieter hinzugefügte Nachrichten und Anweisungen sind in der Eingabeaufforderung enthalten, die die Copilot CLI erreicht.
• after_run() wird jetzt ausgeführt, nachdem die endgültige Antwort, einschließlich des Streaming-Pfads, zusammengestellt wurde.

Wenn Sie bereits context_providers an GitHubCopilotAgent übergeben haben, ist keine Migration erforderlich – die Hooks verhalten sich jetzt konsistent mit der restlichen Python-Agentenoberfläche.

🟡 Strukturierte Ausgabe akzeptiert jetzt zusätzlich zu Pydantischen Modellen JSON-Schemazuordnungen.

PR:#5022

PR #5022 erweitert Python Structured-Output-Parsing, sodass response_format entweder ein Pydantic-Modell oder eine JSON-Schema-Zuordnung sein kann.

• Pydantic-Modelle werden weiterhin in typisierte Modellinstanzen auf response.value geparst.
• JSON-Schemazuordnungen werden jetzt zu JSON-kompatiblen Python-Werten verarbeitet auf response.value (in der Regel dict oder list).
• Die gleichen Analyseregeln gelten, wenn Sie die endgültige Antwort eines Datenstroms sammeln.

Dies ist eine Verbesserung anstatt eine grundlegende Änderung, aber es ist nützlich zu wissen, ob Sie Schemas bereits als JSON-ähnliche Wörterbücher speichern.

python-1.0.0rc6

In diesem Abschnitt werden die signifikanten Python-Änderungen erfasst, die mit python-1.0.0rc6 ausgeliefert oder für python-1.0.0rc6 verfolgt wurden.

🔴 Die Modellauswahl ist standardisiert auf model

PR:#4999

PR #4999 schließt die Python-seitige Modellauswahlbereinigung für Konstruktoren, typierte Optionen, Agentstandardwerte, Antwortobjekte und Umgebungsvariablen ab.

• Verwenden Sie model überall, wo Sie zuvor verwendet haben model_id.
• Agent.default_options und options={...} pro Lauf erwarten jetzt "model" und nicht "model_id".
• Oberfläche response.modelvon Antwortobjekten , nicht response.model_id.
• OpenAI-Einstellungen verwenden jetzt OPENAI_MODEL, OPENAI_CHAT_MODEL, OPENAI_CHAT_COMPLETION_MODEL und OPENAI_EMBEDDING_MODEL.
• Azure OpenAI-Einstellungen verwenden jetzt AZURE_OPENAI_MODEL, AZURE_OPENAI_CHAT_MODEL, AZURE_OPENAI_CHAT_COMPLETION_MODEL und AZURE_OPENAI_EMBEDDING_MODEL.
• Anthropic verwendet ANTHROPIC_CHAT_MODELjetzt , und Foundry Local verwendet FOUNDRY_LOCAL_MODEL.
• Das Anthropic-Paket fügt auch vom Anbieter gehostete Wrapper wie AnthropicFoundryClient, AnthropicBedrockClient, und AnthropicVertexClient.

Before:

from agent_framework.anthropic import AnthropicClient

client = AnthropicClient(model_id="claude-sonnet-4-5-20250929")
response = await client.get_response(
    "Hello!",
    options={"model_id": "claude-sonnet-4-5-20250929"},
)

After:

from agent_framework.anthropic import AnthropicClient

client = AnthropicClient(model="claude-sonnet-4-5-20250929")
response = await client.get_response(
    "Hello!",
    options={"model": "claude-sonnet-4-5-20250929"},
)

🔴 Kontextanbieter können Middleware hinzufügen und den Verlauf pro Modellaufruf beibehalten

PR:#4992

PR #4992 aktualisiert die Python-Kontext-Provider-Pipeline und wie die frameworkverwaltete Historie während mehrfacher Ausführungen beibehalten wird.

• ContextProvider und HistoryProvider sind jetzt die kanonischen Python-Basisklassen.
• BaseContextProvider und BaseHistoryProvider bleiben vorübergehend als veraltete Aliase zur Kompatibilität, aber neuer Code sollte zu den neuen Namen migriert werden.
• SessionContext kann jetzt vom Anbieter hinzugefügte Chats oder Funktions-Middleware über extend_middleware() sammeln und die flache Liste über get_middleware() verfügbar machen.
• Agent(..., require_per_service_call_history_persistence=True) führt Verlaufsanbieter bei jedem einzelnen Modellaufruf aus, statt einmalig nach dem vollständigen run()-Aufruf.
• Dieser Modus ist für den vom Framework verwalteten lokalen Verlauf vorgesehen und kann nicht mit einer vorhandenen, vom Dienst verwalteten Unterhaltung wie session.service_session_id oder options={"conversation_id": ...} kombiniert werden.

Before:

from agent_framework import BaseHistoryProvider

class CustomHistoryProvider(BaseHistoryProvider):
    ...

After:

from agent_framework import Agent, HistoryProvider

class CustomHistoryProvider(HistoryProvider):
    ...

agent = Agent(
    client=client,
    context_providers=[CustomHistoryProvider()],
    require_per_service_call_history_persistence=True,
)

🔴 Veraltete Azure/OpenAI-Kompatibilitätsoberflächen wurden entfernt

PR:#4990

PR #4990 schließt die von Anbietern angeführte Migration ab, indem die verbleibenden veralteten Python-Kompatibilitätsschnittstellen entfernt werden, die in früheren Vorschauversionen verfügbar waren.

• agent_framework.azure exportiert weder AzureOpenAI* noch die älteren AzureAI* Agent-/Client-/Anbieteroberflächen.
• Python OpenAI Assistants-Kompatibilitätstypen sind nicht mehr Teil der aktuellen agent_framework.openai Oberfläche.
• Verwenden Sie OpenAIChatClient, OpenAIChatCompletionClient und OpenAIEmbeddingClient für direkte OpenAI- oder Azure OpenAI-Szenarien.
• Verwenden Sie FoundryChatClient für Inferenz im Foundry-Projekt und FoundryAgent für Prompt Agents oder gehostete Agents.
• Der aktuelle agent_framework.azure Namespace umfasst jetzt die verbleibenden Azure-Integrationen wie Azure AI Search, Cosmos-Verlauf, Azure-Funktionen und dauerhafte Workflows. Foundry-Chats, Agenten, Speicher und Einbettungsclients befinden sich unter agent_framework.foundry.

Wenn Sie älteren Python-Code migrieren, nutzen Sie die folgenden Alternativen:

• AzureOpenAIResponsesClient → OpenAIChatClient
• AzureOpenAIChatClient → OpenAIChatCompletionClient
• AzureOpenAIEmbeddingClient → OpenAIEmbeddingClient
• AzureAIAgentClient / AzureAIClient / AzureAIProjectAgentProvider / AzureAIAgentsProvider FoundryChatClient→ oder FoundryAgent, je nachdem, ob Ihre App die Agentdefinition besitzt
• OpenAIAssistantsClient / OpenAIAssistantProvider OpenAIChatClient→ für aktuelle Python OpenAI-Arbeit, oder FoundryAgent wenn Sie einen vom Dienst verwalteten Agent in Foundry benötigen

🔴 Anbieterführendes Clientdesign und Paketteilung

PR:#4818

PR #4818 organisiert die Python-Anbieteroberfläche neu in anbieterspezifische Pakete und Namespaces.

• OpenAI-Clients befinden sich jetzt im agent-framework-openai-Paket, während sie weiterhin aus dem agent_framework.openai-Namespace importiert werden.
• Microsoft Foundry-Clients befinden sich jetzt im agent-framework-foundry Paket und im agent_framework.foundry Namespace.
• Foundry Local wird auch von agent_framework.foundry als FoundryLocalClient bereitgestellt.
• OpenAIResponsesClient wird umbenannt in OpenAIChatClient.
• OpenAIChatClient wird umbenannt in OpenAIChatCompletionClient.
• Die Clientkonfiguration ist auf model standardisiert, wobei ältere Parameter wie model_id, deployment_name und model_deployment_name ersetzt werden.
• Verwenden Sie für den neuen Azure OpenAI-Code die agent_framework.openai Clients. Die früheren AzureOpenAI* Kompatibilitätsshims wurden später in #4990 entfernt.
• Verwenden Sie FoundryChatClient für neuen Foundry-Code zur direkten Projekterschließung, FoundryAgent für Prompt Agents und HostedAgents und FoundryLocalClient für lokale Laufzeitumgebungen.
• AzureAIClient, AzureAIProjectAgentProvider, AzureAIAgentClient, AzureAIAgentsProvider, und die Python-Assistenten-Kompatibilitätsoberfläche wurden während dieser Umgestaltung auf Kompatibilitätspfade verschoben und später in #4990 entfernt.
• Die Stichprobenabdeckung wurde neu organisiert, um dem neuen anbieterführenden Layout zu entsprechen, einschließlich der Foundry-Beispiele unter samples/02-agents/providers/foundry/.

Paketzuordnung

Before:

from agent_framework.openai import OpenAIResponsesClient

client = OpenAIResponsesClient(model_id="gpt-5.4")

After:

from agent_framework.openai import OpenAIChatClient

client = OpenAIChatClient(model="gpt-5.4")

Wenn Sie Azure OpenAI zuvor direkt verwendet haben, ordnen Sie die alten dedizierten Klassen den neuen anbieterführenden OpenAI-Klassen zu:

• AzureOpenAIResponsesClient → OpenAIChatClient
• AzureOpenAIChatClient → OpenAIChatCompletionClient
• AzureOpenAIEmbeddingClient → OpenAIEmbeddingClient
• AzureOpenAIAssistantsClient → OpenAIChatClient für die direkte Migration der Antworten-API, oder FoundryAgent wenn Sie einen vom Dienst verwalteten Foundry-Agenten benötigen

Die Codeänderung ist hauptsächlich eine Verschiebung des Klassennamens plus deployment_name → model. Verwenden Sie für die Azure OpenAI-Kompatibilität explizite Azure-Eingaben auf den neuen OpenAI-Clients. credential= ist jetzt die bevorzugte Azure-Authentifizierungsoberfläche, während ein aufrufbarer api_key Pfad weiterhin ein Kompatibilitätspfad ist:

Vor (AzureOpenAIResponsesClient):

from agent_framework.azure import AzureOpenAIResponsesClient

client = AzureOpenAIResponsesClient(
    endpoint=azure_endpoint,
    deployment_name=deployment_name,
    credential=credential,
)

Nach (OpenAIChatClient):

from agent_framework.openai import OpenAIChatClient
from azure.identity import AzureCliCredential

api_version = "your-azure-openai-api-version"

client = OpenAIChatClient(
    azure_endpoint=azure_endpoint,
    model=deployment_name,
    credential=AzureCliCredential(),
    api_version=api_version,
)

Vor (AzureOpenAIChatClient):

from agent_framework.azure import AzureOpenAIChatClient

client = AzureOpenAIChatClient(
    endpoint=azure_endpoint,
    deployment_name=deployment_name,
    credential=credential,
)

Nach (OpenAIChatCompletionClient):

from agent_framework.openai import OpenAIChatCompletionClient
from azure.identity import AzureCliCredential

api_version = "your-azure-openai-api-version"

client = OpenAIChatCompletionClient(
    azure_endpoint=azure_endpoint,
    model=deployment_name,
    credential=AzureCliCredential(),
    api_version=api_version,
)

Wenn Sie von Azure OpenAI-Endpunkten zu einem Microsoft Foundry-Projektendpunkt wechseln möchten, verwenden Sie stattdessen die Foundry-orientierte Oberfläche:

Vor (Azure OpenAI-Endpunkt):

from agent_framework.azure import AzureOpenAIResponsesClient
from azure.identity import AzureCliCredential

client = AzureOpenAIResponsesClient(
    deployment_name="gpt-4.1",
    credential=AzureCliCredential(),
)

After (Foundry-Projekt):

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

client = FoundryChatClient(
    project_endpoint="https://your-project.services.ai.azure.com",
    model="gpt-4.1",
    credential=AzureCliCredential(),
)

agent = Agent(client=client)

Verwenden Sie für lokale Microsoft Foundry-Laufzeiten den Foundry-Namespace sowie den lokalen Connector:

from agent_framework.foundry import FoundryLocalClient

client = FoundryLocalClient(model="phi-4-mini")

Wenn Sie model weglassen, setzen Sie FOUNDRY_LOCAL_MODEL in Ihrer Umgebung fest.

Aktualisieren Sie ggf. auch Umgebungs-/Konfigurationsnamen:

• Wird OPENAI_CHAT_MODEL für OpenAIChatClient und OPENAI_CHAT_COMPLETION_MODEL für OpenAIChatCompletionClient verwendet, mit OPENAI_MODEL als allgemeine Rückfallebene.
• Azure OpenAI verwendet AZURE_OPENAI_CHAT_MODEL jetzt für OpenAIChatClient, AZURE_OPENAI_CHAT_COMPLETION_MODEL für OpenAIChatCompletionClientund AZURE_OPENAI_MODEL als freigegebenen Fallback.
• Verwenden Sie azure_endpoint für Azure OpenAI-Ressourcen-URLs, oder base_url, wenn Sie bereits eine vollständige .../openai/v1-URL haben, und setzen Sie api_version für die Azure OpenAI API-Oberfläche, die Sie verwenden.
• Übernehmen Von Foundry-spezifischen Einstellungen wie FOUNDRY_PROJECT_ENDPOINT, FOUNDRY_MODEL, , FOUNDRY_AGENT_NAMEund FOUNDRY_AGENT_VERSION für Cloud Foundry-Clients
• Verwendung ANTHROPIC_CHAT_MODEL für Anthropic und FOUNDRY_LOCAL_MODEL für Foundry Local

Diese Änderung wurde zuerst während des python-1.0.0rc6 Zyklus eingeführt.

🔴 Kernabhängigkeiten sind jetzt absichtlich schlanker

PR:#4904

PR #4904 folgt der Aufteilung des Anbieterpakets von #4818, indem agent-framework-core verkleinert und weitere transitive Anbieterabhängigkeiten aus dem Kernpaket entfernt werden.

• agent-framework-core ist jetzt absichtlich minimal gehalten.
• Wenn Sie importieren agent_framework.openai, installieren Sie agent-framework-openai.
• Wenn Sie agent_framework.foundry importieren, installieren Sie agent-framework-foundry für die Inferenz des Foundry-Projekts, dienstverwaltete Agents, Speicheranbieter und Einbettungen. Verwenden Sie agent-framework-foundry-local --pre für lokale Laufzeiten.
• Wenn Sie MCP-Tools oder Agent.as_mcp_server()andere MCP-Integrationen bei einer minimalen Installation verwenden, installieren Sie diese mcp --pre manuell. Installieren Sie mcp[ws] --prefür die WebSocket MCP-Unterstützung.
• Wenn Sie das umfassende Erlebnis "mit allem Drum und Dran" möchten, installieren Sie das Metapaket agent-framework.

Dadurch wird die Anbieteroberfläche nicht erneut neu gestaltet; es ändert, was standardmäßig installiert ist, wenn Sie nur den Kern verwenden.

Vorher (core-only Installationen bringen häufig transitiv mehr Anbieterfunktionalität mit):

pip install agent-framework-core

Danach (installieren Sie das anbieterpaket, das Sie tatsächlich verwenden):

pip install agent-framework-core
pip install agent-framework-openai

oder:

pip install agent-framework-core
pip install agent-framework-foundry

Wenn Sie ein vorhandenes Projekt aktualisieren, das zuvor von core plus faulen Anbieterimporten abhängig war, überwachen Sie Ihre Importe, und machen Sie die Anbieterpakete in Ihrer Umgebung oder Abhängigkeitsdateien explizit. Führen Sie die gleichen Schritte für MCP-Abhängigkeiten aus, wenn Sie auf MCP-Tools oder MCP-Serverhosting angewiesen sind.

🔴 Generische OpenAI-Clients bevorzugen jetzt explizite Routingsignale

PR:#4925

PR #4925 ändert, wie sich die generischen agent_framework.openai Clients zwischen OpenAI und Azure OpenAI entscheiden.

• Generische OpenAI-Clients wechseln nicht mehr zu Azure, nur weil AZURE_OPENAI_* Umgebungsvariablen vorhanden sind.
• Wenn OPENAI_API_KEY konfiguriert ist, bleiben die generischen Clients auf OpenAI, es sei denn, Sie übergeben ein explizites Azure-Routingsignal wie credential oder azure_endpoint.
• Wenn nur AZURE_OPENAI_* Einstellungen vorhanden sind, können die generischen Clients weiterhin auf das umgebungsbasierte Azure-Routing zurückgreifen.
• Das bevorzugte Azure OpenAI-Muster besteht nun darin, explizite Azure-Einstellungen sowie den Einbettungsclient auf credential=AzureCliCredential(), OpenAIChatClient und OpenAIChatCompletionClient zu übergeben.
• Veraltete AzureOpenAI* Wrapper behalten ihr Kompatibilitätsverhalten bei, sodass bestehender Wrapper-basierter Code nicht den neuen Regeln der generischen Clientrangfolge entspricht.

Bevor (OpenAIChatClient konnte zu Azure geleitet werden, da Azure-Env-Vars vorhanden waren):

import os
from agent_framework.openai import OpenAIChatClient

os.environ["OPENAI_API_KEY"] = "sk-openai"
os.environ["AZURE_OPENAI_ENDPOINT"] = "https://your-resource.openai.azure.com"
os.environ["AZURE_OPENAI_CHAT_MODEL"] = "gpt-4o-mini"

client = OpenAIChatClient(model="gpt-4o-mini")

Nach (generisches OpenAI bleibt bei OpenAI; übergeben Sie explizite Azure-Eingaben, um Azure-Routing zu erzwingen):

import os
from agent_framework.openai import OpenAIChatClient
from azure.identity import AzureCliCredential

client = OpenAIChatClient(
    model=os.environ["AZURE_OPENAI_CHAT_MODEL"],
    azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
    api_version=os.getenv("AZURE_OPENAI_API_VERSION"),
    credential=AzureCliCredential(),
)

Wenn Ihre Umgebung sowohl OPENAI_*- als auch AZURE_OPENAI_*-Werte enthält, überprüfen Sie die generische agent_framework.openai-Clientkonstruktion und machen die Anbieterwahl explizit. Die Azure-Anbieterbeispiele wurden aktualisiert, um Azure-Eingaben direkt zu übergeben.

Azure-Einbettungen folgen jetzt demselben Routingmodell:

import os
from agent_framework.openai import OpenAIEmbeddingClient
from azure.identity import AzureCliCredential

client = OpenAIEmbeddingClient(
    model=os.environ["AZURE_OPENAI_EMBEDDING_MODEL"],
    azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
    api_version=os.getenv("AZURE_OPENAI_API_VERSION"),
    credential=AzureCliCredential(),
)

Karten für Einbettungsszenarien:

• AzureOpenAIEmbeddingClient → OpenAIEmbeddingClient
• AZURE_OPENAI_EMBEDDING_MODEL → model
• OPENAI_EMBEDDING_MODEL bleibt die OpenAI-seitige Einbettungsumgebungsvariable

python-1.0.0rc5 / python-1.0.0b260319 (19. März 2026)

🔴 Neuanordnung der Chatclientpipeline: FunctionInvocation umschließt jetzt ChatMiddleware

PR:#4746

Die Pipeline-Sortierung von ChatClient hat sich geändert. FunctionInvocation ist jetzt die äußerste Ebene und umschließt ChatMiddleware, was bedeutet, dass Chat-Middleware pro Modellaufruf (einschließlich jeder Iteration der Toolaufrufschleife) statt einmal um die gesamte Funktionsaufrufsequenz ausgeführt wird.

Alte Pipeline-Reihenfolge:

ChatMiddleware → FunctionInvocation → RawChatClient

Neuer Pipelineauftrag:

FunctionInvocation → ChatMiddleware → ChatTelemetry → RawChatClient

Wenn Sie über eine benutzerdefinierte Chat-Middleware verfügen, die ursprünglich dafür ausgelegt war, nur einmal pro Agentenaufruf ausgeführt zu werden (dabei die gesamte Werkzeugsaufrufschleife umfassend), aktualisieren Sie sie, damit sie auch bei wiederholter Ausführung sicher bleibt. Chat-Middleware wird jetzt für jede einzelne LLM-Anforderung aufgerufen, einschließlich Anforderungen, die Toolergebnisse zurück an das Modell senden.

Darüber hinaus ist ChatTelemetry jetzt eine separate Ebene von ChatMiddleware in der Pipeline und läuft am nächsten zu RawChatClient.

🔴 Öffentliche Laufzeit-Parameter werden in explizite Buckets aufgeteilt

PR:#4581

Öffentliche Python-Agent- und Chat-APIs behandeln keine allgemeine öffentliche **kwargs Weiterleitung mehr als primären Laufzeitdatenmechanismus. Laufzeitwerte werden jetzt nach Zweck aufgeteilt:

• Verwenden Sie function_invocation_kwargs für Werte, die nur von Tools oder Funktions-Middleware gesehen werden sollten.
• Verwenden Sie client_kwargs für Client-Schichten-Kwargs und die Konfiguration von Client-Middleware.
• Zugreifen auf Tool-/Laufzeitdaten über FunctionInvocationContext (ctx.kwargs und ctx.session).
• Definieren Sie Tools mit einem eingefügten Kontextparameter anstelle von **kwargs; eingefügte Kontextparameter werden nicht im Schema angezeigt, das das Modell sieht.
• Verwenden Sie agent.as_tool(propagate_session=True) beim Delegieren an einen Unteragenten als Werkzeug, wenn der untergeordnete Agent die Sitzung des Anrufers teilen muss.

Before:

from typing import Any

from agent_framework import tool


@tool
def send_email(address: str, **kwargs: Any) -> str:
    return f"Queued email for {kwargs['user_id']}"


response = await agent.run(
    "Send the update to finance@example.com",
    user_id="user-123",
    request_id="req-789",
)

After:

from agent_framework import FunctionInvocationContext, tool


@tool
def send_email(address: str, ctx: FunctionInvocationContext) -> str:
    user_id = ctx.kwargs["user_id"]
    session_id = ctx.session.session_id if ctx.session else "no-session"
    return f"Queued email for {user_id} in {session_id}"


response = await agent.run(
    "Send the update to finance@example.com",
    session=agent.create_session(),
    function_invocation_kwargs={
        "user_id": "user-123",
        "request_id": "req-789",
    },
)

Wenn Sie benutzerdefinierte öffentliche run()- oder get_response()-Methoden implementieren, fügen Sie function_invocation_kwargs und client_kwargs zu diesen Signaturen hinzu. Bevorzugen Sie für Tools einen mit Anmerkungen versehenen Parameter wie FunctionInvocationContext, der ctx, context oder einen anderen kommentierten Namen tragen kann. Wenn Sie ein explizites Schema-/Eingabemodell angeben, wird auch ein unanmerkter Parameter ctx erkannt. Dasselbe Kontextobjekt ist für die Funktion Middleware verfügbar, und dort befinden sich jetzt Laufzeitfunktions-Kwargs und Sitzungszustand. Tooldefinitionen, die weiterhin nur auf **kwargs setzen, verwenden einen Kompatibilitätspfad für Legacy-Systeme und werden entfernt.

python-1.0.0rc4 / python-1.0.0b260311 (11. März 2026)

Versionshinweise:python-1.0.0rc4

🔴Azure AI-Integrationen zielen jetzt auf 2.0 GA ab azure-ai-projects

PR:#4536

Die Python Azure AI-Integrationen gehen jetzt von der GA 2.0-Oberfläche azure-ai-projects aus.

• Der unterstützte Abhängigkeitsbereich ist jetzt azure-ai-projects>=2.0.0,<3.0.
• foundry_features Passthrough wurde aus der Erstellung des Azure AI-Agents entfernt.
• Das Vorschauverhalten nutzt jetzt allow_preview=True auf den unterstützten Clients/Anbietern.
• Die gemischten Beta-/GA-Kompatibilitäts-Shims wurden entfernt. Daher sollten alle Importe und Typnamen auf die 2.0 GA SDK-Schnittstelle aktualisiert werden.

🔴 GitHub Copilot-Toolhandler verwenden jetzt ToolInvocation / ToolResult und Python 3.11+

PR:#4551

agent-framework-github-copilot verfolgt jetzt github-copilot-sdk>=0.1.32.

• Toolhandler empfangen eine ToolInvocation Datenklasse anstelle einer unformatierten dict.
• Geben Sie ToolResult zurück, indem Sie snake_case Felder wie result_type und text_result_for_llm verwenden.
• Das agent-framework-github-copilot Paket erfordert jetzt Python 3.11+.

Before:

from typing import Any


def handle_tool(invocation: dict[str, Any]) -> dict[str, Any]:
    args = invocation.get("arguments", {})
    return {
        "resultType": "success",
        "textResultForLlm": f"Handled {args.get('city', 'request')}",
    }

After:

from copilot.types import ToolInvocation, ToolResult


def handle_tool(invocation: ToolInvocation) -> ToolResult:
    args = invocation.arguments
    return ToolResult(
        result_type="success",
        text_result_for_llm=f"Handled {args.get('city', 'request')}",
    )

python-1.0.0rc3 / python-1.0.0b260304 (4. März 2026)

Versionshinweise:python-1.0.0rc3

🔴 Der Fachkompetenz-Anbieter wurde basierend auf Code-Definition abgeschlossen Skill / SkillResource

PR:#4387

Python-Agenten-Skills unterstützen jetzt code-definierte Skill- und SkillResource-Objekte zusammen mit dateibasierten Fähigkeiten, und die öffentliche Anbieteroberfläche wird auf SkillsProvider standardisiert.

• Wenn Sie weiterhin die ältere Vorschau/interne FileAgentSkillsProvider importieren, sollten Sie zu SkillsProvider wechseln.
• Dateibasierte Ressourcensuche basiert nicht mehr auf backtick-zitierten Verweisen in SKILL.md; Ressourcen werden stattdessen aus dem Qualifikationsverzeichnis ermittelt.

Wenn Sie Vorschau-/internen Code hatten, der FileAgentSkillsProvider importierte, wechseln Sie zur aktuellen öffentlichen API:

from agent_framework import Skill, SkillResource, SkillsProvider

python-1.0.0rc2 / python-1.0.0b260226 (26. Februar 2026)

Versionshinweise:python-1.0.0rc2

🔴 Deklarative Workflows ersetzen InvokeTool durch InvokeFunctionTool

PR:#3716

Deklarative Python-Workflows verwenden nicht mehr die alte InvokeTool Aktionsart. Ersetzen Sie es durch InvokeFunctionTool und registrieren Sie Python-Aufrufables mit WorkflowFactory.register_tool().

Before:

actions:
  - kind: InvokeTool
    toolName: send_email

After:

factory = WorkflowFactory().register_tool("send_email", send_email)

actions:
  - kind: InvokeFunctionTool
    functionName: send_email

python-1.0.0rc1 / python-1.0.0b260219 (19. Februar 2026)

Release:agent-framework-core und agent-framework-azure-ai höhergestuft zu 1.0.0rc1. Alle anderen Pakete wurden aktualisiert auf 1.0.0b260219.

🔴 Einheitliche Azure-Anmeldeinformationsverarbeitung für alle Pakete

PR:#4088

Die Parameter ad_token, ad_token_provider und get_entra_auth_token beziehungsweise Hilfsprogramme wurden in allen Azure-bezogenen Python-Paketen durch einen einheitlichen credential-Parameter ersetzt. Der neue Ansatz nutzt azure.identity.get_bearer_token_provider für das automatische Zwischenspeichern und die Aktualisierung von Token.

Betroffene Klassen:AzureOpenAIChatClient, AzureOpenAIResponsesClient, , AzureOpenAIAssistantsClient, AzureAIClientAzureAIAgentClient, AzureAIProjectAgentProvider, AzureAIAgentsProvider, AzureAISearchContextProviderPurviewClient, . PurviewPolicyMiddlewarePurviewChatPolicyMiddleware

Before:

from azure.identity import AzureCliCredential, get_bearer_token_provider

token_provider = get_bearer_token_provider(
    AzureCliCredential(), "https://cognitiveservices.azure.com/.default"
)

client = AzureOpenAIResponsesClient(
    azure_ad_token_provider=token_provider,
    ...
)

After:

from azure.identity import AzureCliCredential

client = AzureOpenAIResponsesClient(
    credential=AzureCliCredential(),
    ...
)

Der credential Parameter akzeptiert TokenCredential, AsyncTokenCredentialoder ein aufrufbarer Tokenanbieter. Tokenzwischenspeicherung und -aktualisierung werden automatisch behandelt.

🔴 Neu gestaltete Python-Ausnahmehierarchie

PR:#4082

Die flache ServiceException-Familie wurde durch domänenbezogene Ausnahmeverzweigungen unter einem einzigen AgentFrameworkException-Stamm ersetzt. Dadurch erhalten Anrufer präzise except Ziele und klare Fehlersemantik.

Neue Hierarchie:

AgentFrameworkException
├── AgentException
│   ├── AgentInvalidAuthException
│   ├── AgentInvalidRequestException
│   ├── AgentInvalidResponseException
│   └── AgentContentFilterException
├── ChatClientException
│   ├── ChatClientInvalidAuthException
│   ├── ChatClientInvalidRequestException
│   ├── ChatClientInvalidResponseException
│   └── ChatClientContentFilterException
├── IntegrationException
│   ├── IntegrationInitializationError
│   ├── IntegrationInvalidAuthException
│   ├── IntegrationInvalidRequestException
│   ├── IntegrationInvalidResponseException
│   └── IntegrationContentFilterException
├── ContentError
├── WorkflowException
│   ├── WorkflowRunnerException
│   ├── WorkflowValidationError
│   └── WorkflowActionError
├── ToolExecutionException
├── MiddlewareTermination
└── SettingNotFoundError

Entfernte Ausnahmen:ServiceException, ServiceInitializationError, ServiceResponseException, ServiceContentFilterException, ServiceInvalidAuthError, ServiceInvalidExecutionSettingsError, ServiceInvalidRequestError, ServiceInvalidResponseError, AgentExecutionException, AgentInvocationError, AgentInitializationError, AgentSessionException, ChatClientInitializationError, CheckpointDecodingError

Before:

from agent_framework.exceptions import ServiceException, ServiceResponseException

try:
    result = await agent.run("Hello")
except ServiceResponseException:
    ...
except ServiceException:
    ...

After:

from agent_framework.exceptions import AgentException, AgentInvalidResponseException, AgentFrameworkException

try:
    result = await agent.run("Hello")
except AgentInvalidResponseException:
    ...
except AgentException:
    ...
except AgentFrameworkException:
    # catch-all for any Agent Framework error
    ...

🔴 Anbieterstatus im Bereich source_id

PR:#3995

Anbieter-Hooks erhalten jetzt ein anbieterbezogenes Statuswörterbuch (state.setdefault(provider.source_id, {})) statt des vollständigen Sitzungszustands. Dies bedeutet, dass Anbieterimplementierungen, die zuvor auf den geschachtelten Zustand über state[self.source_id]["key"] zugegriffen haben, jetzt direkt auf state["key"] zugreifen müssen.

Darüber hinaus InMemoryHistoryProvider wurde die Standardeinstellung source_id von "memory" zu "in_memory".

Before:

# In a custom provider hook:
async def on_before_agent(self, state: dict, **kwargs):
    my_data = state[self.source_id]["my_key"]

# InMemoryHistoryProvider default source_id
provider = InMemoryHistoryProvider("memory")

After:

# Provider hooks receive scoped state — no nested access needed:
async def on_before_agent(self, state: dict, **kwargs):
    my_data = state["my_key"]

# InMemoryHistoryProvider default source_id changed
provider = InMemoryHistoryProvider("in_memory")

🔴 Ausrichtung der Chat-/Agent-Nachrichteneingabe (run vs get_response)

PR:#3920

Chat-Client-Implementierungen get_response empfangen Sequence[Message] jetzt einheitlich. agent.run(...) bleibt flexibel (str, Content, Messageoder Sequenzen dieser) und normalisiert Eingaben vor dem Aufrufen von Chatclients.

Before:

async def get_response(self, messages: str | Message | list[Message], **kwargs): ...

After:

from collections.abc import Sequence
from agent_framework import Message

async def get_response(self, messages: Sequence[Message], **kwargs): ...

🔴 FunctionTool[Any] generisches Setup für Schema-Passthrough entfernt

PR:#3907

Schemabasierte Toolpfade basieren nicht mehr auf dem vorherigen generischen FunctionTool[Any] Verhalten. Verwenden Sie FunctionTool direkt und geben Sie entweder ein pydantic BaseModel oder bei Bedarf explizite Schemas an (z. B. mit @tool(schema=...)).

Before:

placeholder: FunctionTool[Any] = FunctionTool(...)

After:

placeholder: FunctionTool = FunctionTool(...)

🔴 Pydantische Einstellungen ersetzt durch TypedDict + load_settings()

PRs:#3843, #4032

Die auf pydantic-settings basierende AFBaseSettings-Klasse wurde durch ein leichtgewichtiges, funktionsbasiertes Einstellungssystem ersetzt, das TypedDict und load_settings() verwendet. Die pydantic-settings Abhängigkeit wurde vollständig entfernt.

Alle Einstellungsklassen (z. B. OpenAISettings, , AzureOpenAISettingsAnthropicSettings) sind jetzt TypedDict Definitionen, und auf Einstellungswerte wird über die Wörterbuchsyntax anstelle des Attributzugriffs zugegriffen.

Before:

from agent_framework.openai import OpenAISettings

settings = OpenAISettings()  # pydantic-settings auto-loads from env
api_key = settings.api_key
model_id = settings.model_id

After:

from agent_framework.openai import OpenAISettings, load_settings

settings = load_settings(OpenAISettings, env_prefix="OPENAI_")
api_key = settings["api_key"]
model = settings["model"]

🟡 Beheben der Workflow-Übergabe des Reasoning-Models und der Serialisierung der Historie

PR:#4083

Behebt mehrere Fehler bei der Verwendung von Argumentationsmodellen (z. B. gpt-5-mini, gpt-5.2) in Multiagenten-Workflows. Die Abschätzungen aus der Responses-API werden jetzt korrekt serialisiert und nur in den Verlauf aufgenommen, wenn auch ein function_call vorhanden ist, um API-Fehler zu verhindern. Verschlüsselter/ausgeblendeter Begründungsinhalt wird jetzt ordnungsgemäß ausgegeben, und das summary Feldformat wird korrigiert. Zusätzlich wird service_session_id auch beim Handover gelöscht, um ein Leck des agentenübergreifenden Zustands zu verhindern.

🟡 Bedrock zum core[all] hinzugefügt und Standardeinstellungen für die Werkzeugauswahl korrigiert

PR:#3953

Amazon Bedrock ist jetzt in den agent-framework-core[all] Extras enthalten und über die agent_framework.amazon Lazy-Import-Schnittstelle verfügbar. Das Toolauswahlverhalten wurde ebenfalls behoben: Nicht festgelegte Toolauswahlwerte bleiben jetzt nicht festgelegt, sodass Anbieter ihre Dienststandardwerte verwenden, während explizit festgelegte Werte beibehalten werden.

from agent_framework.amazon import BedrockClient

🟡 AzureAIClient bei nicht unterstützten Laufzeitüberschreibungen gewarnt

PR:#3919

Zum Zeitpunkt dieser Änderung wurde eine Warnung protokolliert, wenn die Laufzeit tools oder structured_output sich von der Erstellungszeitkonfiguration des Agents unterscheidet. Diese Python-Oberfläche wurde seitdem entfernt. Verwenden Sie FoundryChatClient für aktuellen Python-Code, wenn Sie eine App-eigene Tool-/Laufzeitkonfiguration benötigen, oder OpenAIChatClient für direkte Responses-API-Szenarien, die dynamische Überschreibungen erfordern.

🟡 workflow.as_agent() Jetzt wird standardmäßig der lokale Verlauf verwendet, wenn Anbieter nicht festgelegt sind.

PR:#3918

Wenn workflow.as_agent() ohne context_providers erstellt wird, wird InMemoryHistoryProvider("memory") jetzt standardmäßig hinzugefügt. Wenn Kontextanbieter explizit angegeben werden, wird diese Liste unverändert beibehalten.

workflow_agent = workflow.as_agent(name="MyWorkflowAgent")
# Default local history provider is injected when none are provided.

🟡 OpenTelemetry-Ablaufverfolgungskontext an MCP-Anforderungen weitergegeben

PR:#3780

Wenn OpenTelemetry installiert ist, wird der Trace-Kontext (z. B. W3C traceparent) automatisch in MCP-Anforderungen über params._meta eingefügt. Dies ermöglicht die Verfolgung des gesamten Ablaufs von Agenten bis zu Aufrufen des MCP-Servers in einer verteilten Umgebung. Es sind keine Codeänderungen erforderlich – dies ist ein additives Verhalten, das aktiviert wird, wenn ein gültiger Span-Kontext vorhanden ist.

🟡 Dauerhafte Workflowunterstützung für Azure Functions

PR:#3630

Das agent-framework-azurefunctions Paket unterstützt jetzt das Ausführen von Workflow Diagrammen in Azure Durable Functions. Übergeben Sie einen workflow Parameter an AgentFunctionApp, um Agententitäten, Aktivitätsfunktionen und HTTP-Endpunkte automatisch zu registrieren.

from agent_framework.azurefunctions import AgentFunctionApp

app = AgentFunctionApp(workflow=my_workflow)
# Automatically registers:
#   POST /api/workflow/run          — start a workflow
#   GET  /api/workflow/status/{id}  — check status
#   POST /api/workflow/respond/{id}/{requestId} — HITL response

Unterstützt Fan-Out/Fan-In-, Zustandsteilungs- und Human-in-the-Loop-Muster mit konfigurierbarem Timeout und automatischer Ablehnung bei Ablauf.

python-1.0.0b260212 (12. Februar 2026)

Versionshinweise:python-1.0.0b260212

🔴 Hosted*Tool Durch Clientmethoden get_*_tool() ersetzte Klassen

PR:#3634

Die gehosteten Toolklassen wurden zugunsten von klientenspezifischen Factory-Methoden entfernt. Dadurch wird die Verfügbarkeit des Tools vom Anbieter explizit festgelegt.

Before:

from agent_framework import HostedCodeInterpreterTool, HostedWebSearchTool

tools = [HostedCodeInterpreterTool(), HostedWebSearchTool()]

After:

from agent_framework.openai import OpenAIResponsesClient

client = OpenAIResponsesClient()
tools = [client.get_code_interpreter_tool(), client.get_web_search_tool()]

🔴 Die Pipeline des Sitzungs-/Kontextanbieters wurde abgeschlossen (AgentSession, context_providers)

PR:#3850

Die Python-Sitzung und die Kontextanbietermigration wurden abgeschlossen. AgentThread und die alten Kontextanbietertypen wurden entfernt.

• AgentThread → AgentSession
• agent.get_new_thread() → agent.create_session()
• agent.get_new_thread(service_thread_id=...) → agent.get_session(service_session_id=...)
• context_provider= / chat_message_store_factory= Muster werden durch context_providers=[...]

Before:

thread = agent.get_new_thread()
response = await agent.run("Hello", thread=thread)

After:

session = agent.create_session()
response = await agent.run("Hello", session=session)

🔴 Prüfpunktmodell und Speicherverhalten umgestaltet

PR:#3744

Prüfpunktinsinterne wurden neu gestaltet, was sich auf die permanente Kompatibilität von Prüfpunkten und benutzerdefinierte Speicherimplementierungen auswirkt:

• WorkflowCheckpoint speichert jetzt Liveobjekte (Serialisierung geschieht im Prüfpunktspeicher)
• FileCheckpointStorage verwendet jetzt Pickle-Serialisierung
• workflow_id wurde entfernt und previous_checkpoint_id hinzugefügt.
• Veraltete Prüfpunkthaken wurden entfernt.

Wenn Sie Prüfpunkte zwischen Versionen beibehalten, generieren oder migrieren Sie vorhandene Prüfpunktartefakte, bevor Sie Workflows fortsetzen.

🟡 Endpunkte des Foundry-Projekts, die ursprünglich durch AzureOpenAIResponsesClient

PR:#3814

Diese Vorschaufunktion erlaubte AzureOpenAIResponsesClient ursprünglich die Verbindung mit Foundry-Projektendpunkten. Die aktuelle Python-Anleitung verwendet FoundryChatClient für die Inferenz im Foundry-Projekt oder FoundryAgent für dienstverwaltete Foundry-Agenten anstelle der entfernten AzureOpenAIResponsesClient.

from azure.identity import DefaultAzureCredential
from agent_framework.foundry import FoundryChatClient

client = FoundryChatClient(
    project_endpoint="https://<your-project>.services.ai.azure.com",
    model="gpt-4o-mini",
    credential=DefaultAzureCredential(),
)

🔴 Middleware call_next akzeptiert nicht mehr context

PR:#3829

Middleware-Fortsetzung akzeptiert jetzt keine Argumente. Wenn Ihre Middleware weiterhin aufruft call_next(context), aktualisieren Sie sie auf call_next().

Before:

async def telemetry_middleware(context, call_next):
    # ...
    return await call_next(context)

After:

async def telemetry_middleware(context, call_next):
    # ...
    return await call_next()

python-1.0.0b260210 (10. Februar 2026)

Versionshinweise:python-1.0.0b260210

🔴 Workflow-Factory-Methoden entfernt von WorkflowBuilder

PR:#3781

register_executor() und register_agent() wurden aus WorkflowBuilderentfernt. Alle Generatormethoden (add_edge, add_fan_out_edges, , add_fan_in_edgesadd_chain, add_switch_case_edge_group, add_multi_selection_edge_group) und start_executor akzeptieren keine Zeichenfolgennamen mehr – sie erfordern Executor- oder Agentinstanzen direkt.

Um die Isolation des Zustands zu gewährleisten, sollten Sie die Instanziierung von Executor/Agent und den Aufbau von Workflows in einer Hilfsmethode kapseln, sodass jeder Aufruf neue Instanzen erzeugt.

WorkflowBuilder mit Executoren

Before:

workflow = (
    WorkflowBuilder(start_executor="UpperCase")
    .register_executor(lambda: UpperCaseExecutor(id="upper"), name="UpperCase")
    .register_executor(lambda: ReverseExecutor(id="reverse"), name="Reverse")
    .add_edge("UpperCase", "Reverse")
    .build()
)

After:

upper = UpperCaseExecutor(id="upper")
reverse = ReverseExecutor(id="reverse")

workflow = WorkflowBuilder(start_executor=upper).add_edge(upper, reverse).build()

WorkflowBuilder mit Agenten

Before:

builder = WorkflowBuilder(start_executor="writer_agent")
builder.register_agent(factory_func=create_writer_agent, name="writer_agent")
builder.register_agent(factory_func=create_reviewer_agent, name="reviewer_agent")
builder.add_edge("writer_agent", "reviewer_agent")

workflow = builder.build()

After:

writer_agent = create_writer_agent()
reviewer_agent = create_reviewer_agent()

workflow = WorkflowBuilder(start_executor=writer_agent).add_edge(writer_agent, reviewer_agent).build()

Zustandsisolation mit Hilfsmethoden

Für Workflows, die einen isolierten Zustand pro Aufruf benötigen, umschließen Sie die Konstruktion in einer Hilfsmethode:

def create_workflow() -> Workflow:
    """Each call produces fresh executor instances with independent state."""
    upper = UpperCaseExecutor(id="upper")
    reverse = ReverseExecutor(id="reverse")

    return WorkflowBuilder(start_executor=upper).add_edge(upper, reverse).build()

workflow_a = create_workflow()
workflow_b = create_workflow()

🔴 ChatAgentumbenannt in , Agent umbenannt in ChatMessageMessage

PR:#3747

Core Python-Typen wurden durch Entfernen des redundanten Chat Präfixes vereinfacht. Es werden keine abwärtskompatiblen Aliasnamen bereitgestellt.

Importe aktualisieren

Before:

from agent_framework import ChatAgent, ChatMessage

After:

from agent_framework import Agent, Message

Aktualisieren von Typverweisen

Before:

agent = ChatAgent(
    chat_client=client,
    name="assistant",
    instructions="You are a helpful assistant.",
)

message = ChatMessage(role="user", contents=[Content.from_text("Hello")])

After:

agent = Agent(
    client=client,
    name="assistant",
    instructions="You are a helpful assistant.",
)

message = Message(role="user", contents=[Content.from_text("Hello")])

🔴 Typen-API-Überprüfungsupdates über Antwort-/Nachrichtenmodelle hinweg

PR:#3647

Diese Version enthält eine umfassende, unterbrechende Bereinigung von Nachrichten-/Antworteingaben und Hilfs-APIs.

• Role und FinishReason sind jetzt NewType Wrapper über str mit RoleLiteral/FinishReasonLiteral für bekannte Werte. Behandeln Sie sie als Zeichenfolgen (keine .value Verwendung).
• Message Die Konstruktion ist standardisiert Message(role, contents=[...]); Zeichenfolgen werden contents automatisch in Textinhalte konvertiert.
• ChatResponse und AgentResponse Konstruktoren fokussieren sich jetzt auf messages= (einzelnes Message oder Sequenzen); die Verwendung des Legacy-Konstruktors text= wurde aus den Antworten entfernt.
• ChatResponseUpdate und AgentResponseUpdate akzeptieren text= nicht mehr; verwenden Sie contents=[Content.from_text(...)].
• Die Bezeichnungen für die Zusammenführung von Updates wurden vereinfacht.
• try_parse_value wurde aus ChatResponse und AgentResponseentfernt.

Die Hilfsmethode wird umbenannt.

Aktualisieren der Antwortaktualisierungskonstruktion

Before:

update = AgentResponseUpdate(text="Processing...", role="assistant")

After:

from agent_framework import AgentResponseUpdate, Content

update = AgentResponseUpdate(
    contents=[Content.from_text("Processing...")],
    role="assistant",
)

Ersetzen Sie try_parse_value durch try/except auf .value.

Before:

if parsed := response.try_parse_value(MySchema):
    print(parsed.name)

After:

from pydantic import ValidationError

try:
    parsed = response.value
    if parsed:
        print(parsed.name)
except ValidationError as err:
    print(f"Validation failed: {err}")

🔴Einheitliches run/get_response Modell und Verwendung ResponseStream

PR:#3379

Python-APIs wurden um agent.run(...) und client.get_response(...) konsolidiert, wobei Streaming durch ResponseStream dargestellt wird.

Before:

async for update in agent.run_stream("Hello"):
    print(update)

After:

stream = agent.run("Hello", stream=True)
async for update in stream:
    print(update)

🔴 Kernkontext/Protokolltyp-Umbenennungen

PRs:#3714, #3717

Aktualisieren Sie Importe und Typanmerkungen entsprechend.

🔴 Middleware-Fortsetzungsparameter umbenannt in call_next

PR:#3735

Middleware-Signaturen sollten jetzt call_next anstelle von next.

Before:

async def my_middleware(context, next):
    return await next(context)

After:

async def my_middleware(context, call_next):
    return await call_next(context)

🔴 TypeVar-Namen standardisiert (TName → NameT)

PR:#3770

Die Codebasis folgt nun einem konsistenten TypeVar-Benennungsstil, in dem Suffix T verwendet wird.

Before:

TMessage = TypeVar("TMessage")

After:

MessageT = TypeVar("MessageT")

Wenn Sie benutzerdefinierte Wrapper um Framework-Generika verwalten, richten Sie Ihre lokalen TypeVar-Namen an der neuen Konvention aus, um die Änderung von Anmerkungen zu reduzieren.

🔴 Workflow-as-agent-Output und Streaming-Änderungen

PR:#3649

workflow.as_agent() Das Verhalten wurde aktualisiert, um die Ausgabe und das Streaming mit standard-Agent-Antwortmustern auszurichten. Überprüfen Sie Workflow-as-Agent-Consumer, die von der Verarbeitung von Legacyausgabe/Aktualisierungen abhängig sind, und aktualisieren Sie sie auf den aktuellen AgentResponse/AgentResponseUpdate Fluss.

🔴 Fluent Builder-Methoden werden in Konstruktorparameter verschoben

PR:#3693

Fließende Methoden mit einer einzigen Konfiguration über 6 Builder (WorkflowBuilder, SequentialBuilder, ConcurrentBuilder, GroupChatBuilder, MagenticBuilder, HandoffBuilder) wurden zu Konstruktorparametern migriert. Fluent-Methoden, die der einzige Konfigurationspfad für eine Einstellung waren, werden zugunsten von Konstruktorargumenten entfernt.

WorkflowBuilder

set_start_executor(), with_checkpointing()und with_output_from() werden entfernt. Verwenden Sie stattdessen Konstruktorparameter.

Before:

upper = UpperCaseExecutor(id="upper")
reverse = ReverseExecutor(id="reverse")

workflow = (
    WorkflowBuilder(start_executor=upper)
    .add_edge(upper, reverse)
    .set_start_executor(upper)
    .with_checkpointing(storage)
    .build()
)

After:

upper = UpperCaseExecutor(id="upper")
reverse = ReverseExecutor(id="reverse")

workflow = (
    WorkflowBuilder(start_executor=upper, checkpoint_storage=storage)
    .add_edge(upper, reverse)
    .build()
)

SequentialBuilder / ConcurrentBuilder

participants(), register_participants(), with_checkpointing()und with_intermediate_outputs() werden entfernt. Verwenden Sie stattdessen Konstruktorparameter.

Before:

workflow = SequentialBuilder().participants([agent_a, agent_b]).with_checkpointing(storage).build()

After:

workflow = SequentialBuilder(participants=[agent_a, agent_b], checkpoint_storage=storage).build()

GroupChatBuilder

participants(), register_participants(), with_orchestrator(), with_termination_condition(), with_max_rounds(), with_checkpointing()und with_intermediate_outputs() werden entfernt. Verwenden Sie stattdessen Konstruktorparameter.

Before:

workflow = (
    GroupChatBuilder()
    .with_orchestrator(selection_func=selector)
    .participants([agent1, agent2])
    .with_termination_condition(lambda conv: len(conv) >= 4)
    .with_max_rounds(10)
    .build()
)

After:

workflow = GroupChatBuilder(
    participants=[agent1, agent2],
    selection_func=selector,
    termination_condition=lambda conv: len(conv) >= 4,
    max_rounds=10,
).build()

MagenticBuilder

participants(), register_participants(), with_manager(), with_plan_review(), with_checkpointing()und with_intermediate_outputs() werden entfernt. Verwenden Sie stattdessen Konstruktorparameter.

Before:

workflow = (
    MagenticBuilder()
    .participants([researcher, coder])
    .with_manager(agent=manager_agent)
    .with_plan_review()
    .build()
)

After:

workflow = MagenticBuilder(
    participants=[researcher, coder],
    manager_agent=manager_agent,
    enable_plan_review=True,
).build()

HandoffBuilder

with_checkpointing() und with_termination_condition() werden entfernt. Verwenden Sie stattdessen Konstruktorparameter.

Before:

workflow = (
    HandoffBuilder(participants=[triage, specialist])
    .with_start_agent(triage)
    .with_termination_condition(lambda conv: len(conv) > 5)
    .with_checkpointing(storage)
    .build()
)

After:

workflow = (
    HandoffBuilder(
        participants=[triage, specialist],
        termination_condition=lambda conv: len(conv) > 5,
        checkpoint_storage=storage,
    )
    .with_start_agent(triage)
    .build()
)

Validierungsänderungen

• WorkflowBuilder erfordert start_executor jetzt als Konstruktorargument (zuvor über fluent-Methode festgelegt)
• SequentialBuilder, ConcurrentBuilder, GroupChatBuilder und MagenticBuilder erfordern jetzt entweder participants oder participant_factories bei der Erstellung — keins von beidem führt dazu, dass ValueError

🔴Workflow-Ereignisse mit WorkflowEvent-Diskriminator zu einem einzigen type-Ereignis zusammengeführt

PR:#3690

Alle einzelnen Workflow-Ereignis-Unterklassen wurden durch eine generische WorkflowEvent[DataT]-Klasse ersetzt. Anstatt isinstance() Checks zur Identifizierung von Ereignistypen zu verwenden, überprüfen Sie nun das event.type Zeichenfolgenliteral (z. B. "output", "request_info", "status"). Dies folgt demselben Muster wie die Content Klassenkonsolidierung aus python-1.0.0b260123.

Entfernte Ereignisklassen

Die folgenden exportierten Ereignisunterklassen sind nicht mehr vorhanden:

Importe aktualisieren

Before:

from agent_framework import (
    WorkflowOutputEvent,
    RequestInfoEvent,
    WorkflowStatusEvent,
    ExecutorCompletedEvent,
)

After:

from agent_framework import WorkflowEvent
# Individual event classes no longer exist; use event.type to discriminate

Aktualisieren von Ereignistypüberprüfungen

Before:

async for event in workflow.run_stream(input_message):
    if isinstance(event, WorkflowOutputEvent):
        print(f"Output from {event.executor_id}: {event.data}")
    elif isinstance(event, RequestInfoEvent):
        requests[event.request_id] = event.data
    elif isinstance(event, WorkflowStatusEvent):
        print(f"Status: {event.state}")

After:

async for event in workflow.run_stream(input_message):
    if event.type == "output":
        print(f"Output from {event.executor_id}: {event.data}")
    elif event.type == "request_info":
        requests[event.request_id] = event.data
    elif event.type == "status":
        print(f"Status: {event.state}")

Streaming mit AgentResponseUpdate

Before:

from agent_framework import AgentResponseUpdate, WorkflowOutputEvent

async for event in workflow.run_stream("Write a blog post about AI agents."):
    if isinstance(event, WorkflowOutputEvent) and isinstance(event.data, AgentResponseUpdate):
        print(event.data, end="", flush=True)
    elif isinstance(event, WorkflowOutputEvent):
        print(f"Final output: {event.data}")

After:

from agent_framework import AgentResponseUpdate

async for event in workflow.run_stream("Write a blog post about AI agents."):
    if event.type == "output" and isinstance(event.data, AgentResponseUpdate):
        print(event.data, end="", flush=True)
    elif event.type == "output":
        print(f"Final output: {event.data}")

Typanmerkungen

Before:

pending_requests: list[RequestInfoEvent] = []
output: WorkflowOutputEvent | None = None

After:

from typing import Any
from agent_framework import WorkflowEvent

pending_requests: list[WorkflowEvent[Any]] = []
output: WorkflowEvent | None = None

🔴 workflow.send_responses* entfernt; verwenden workflow.run(responses=...)

PR:#3720

send_responses() und send_responses_streaming() wurden aus Workflowentfernt. Setzen Sie angehaltene Workflows fort, indem Sie Antworten direkt an run().

Before:

async for event in workflow.send_responses_streaming(
    checkpoint_id=checkpoint_id,
    responses=[approved_response],
):
    ...

After:

async for event in workflow.run(
    checkpoint_id=checkpoint_id,
    responses=[approved_response],
):
    ...

🔴 SharedState umbenannt in State; Workflowstatus-APIs sind synchron

PR:#3667

Status-APIs erfordern awaitnicht mehr, und die Benennung wurde standardisiert:

🔴 Orchestrierungsentwickler wurden nach agent_framework.orchestrations

PR:#3685

Orchestrierungs-Generatoren befinden sich jetzt in einem dedizierten Paketnamespace.

Before:

from agent_framework import SequentialBuilder, GroupChatBuilder

After:

from agent_framework.orchestrations import SequentialBuilder, GroupChatBuilder

🟡 Lang andauernde Hintergrundantworten und Fortsetzungstokens

PR:#3808

Hintergrundantworten werden jetzt für die Ausführung von Python-Agenten durch options={"background": True} und continuation_token unterstützt.

response = await agent.run("Long task", options={"background": True})
while response.continuation_token is not None:
    response = await agent.run(options={"continuation_token": response.continuation_token})

🟡 Vorschautypen für Sitzungs-/Kontextanbieter, die nebeneinander hinzugefügt wurden

PR:#3763

Neue Sitzungs-/Kontextpipelinetypen wurden zusammen mit älteren APIs für die inkrementelle Migration eingeführt, einschließlich SessionContext und BaseContextProvider.

🟡 Code-Interpreter-Streaming umfasst jetzt inkrementelle Code-Deltas

PR:#3775

Streaming-Code-Interpreter führt jetzt Aktualisierungen von Codedelta in den gestreamten Inhalten aus, damit UIs generierten Code schrittweise rendern können.

🟡 @tool unterstützt die explizite Schemabehandlung

PR:#3734

Tooldefinitionen können jetzt die explizite Schemabehandlung verwenden, wenn die abgeleitete Schemaausgabe Anpassungen benötigt.

python-1.0.0b260130 (30. Januar 2026)

Versionshinweise:python-1.0.0b260130

🟡 ChatOptions und ChatResponse/AgentResponse jetzt standardisiert im Hinblick auf das Antwortformat

PR:#3305

ChatOptions, ChatResponseund AgentResponse sind jetzt generische Typen parametrisiert durch den Antwortformattyp. Dies ermöglicht eine bessere Typinferenz beim Verwenden strukturierter Ausgaben mit response_format.

Before:

from agent_framework import ChatOptions, ChatResponse
from pydantic import BaseModel

class MyOutput(BaseModel):
    name: str
    score: int

options: ChatOptions = {"response_format": MyOutput}  # No type inference
response: ChatResponse = await client.get_response("Query", options=options)
result = response.value  # Type: Any

After:

from agent_framework import ChatOptions, ChatResponse
from pydantic import BaseModel

class MyOutput(BaseModel):
    name: str
    score: int

options: ChatOptions[MyOutput] = {"response_format": MyOutput}  # Generic parameter
response: ChatResponse[MyOutput] = await client.get_response("Query", options=options)
result = response.value  # Type: MyOutput | None (inferred!)

🟡 BaseAgent Unterstützung für Claude Agent SDK hinzugefügt

PR:#3509

Das Python SDK enthält jetzt eine BaseAgent Implementierung für das Claude Agent SDK und ermöglicht eine erstklassige, Adapter-basierte Nutzung im Agent Framework.

python-1.0.0b260128 (28. Januar 2026)

Versionshinweise:python-1.0.0b260128

🔴 AIFunction umbenannt in FunctionTool und @ai_function umbenannt in @tool

PR:#3413

Die Klasse und der Dekorateur wurden für Klarheit und Konsistenz mit der Branchenterminologie umbenannt.

Before:

from agent_framework.core import ai_function, AIFunction

@ai_function
def get_weather(city: str) -> str:
    """Get the weather for a city."""
    return f"Weather in {city}: Sunny"

# Or using the class directly
func = AIFunction(get_weather)

After:

from agent_framework.core import tool, FunctionTool

@tool
def get_weather(city: str) -> str:
    """Get the weather for a city."""
    return f"Weather in {city}: Sunny"

# Or using the class directly
func = FunctionTool(get_weather)

🔴 Fabrikmuster zu GroupChat und Magentic hinzugefügt; API-Umbenennungen

PR:#3224

Teilnehmerfabrik und Orchestratorfabrik zum Gruppenchat hinzugefügt. Enthält auch Umbenennungen:

• with_standard_manager → with_manager
• participant_factories → register_participant

Before:

from agent_framework.workflows import MagenticBuilder

builder = MagenticBuilder()
builder.with_standard_manager(manager)
builder.participant_factories(factory1, factory2)

After:

from agent_framework.workflows import MagenticBuilder

builder = MagenticBuilder()
builder.with_manager(manager)
builder.register_participant(factory1)
builder.register_participant(factory2)

🔴 Github umbenannt in GitHub

PR:#3486

Klassen- und Paketnamen wurden aktualisiert, um die korrekte Groß-/Kleinschreibung widerzuspiegeln.

Before:

from agent_framework_github_copilot import GithubCopilotAgent

agent = GithubCopilotAgent(...)

After:

from agent_framework_github_copilot import GitHubCopilotAgent

agent = GitHubCopilotAgent(...)

python-1.0.0b260127 (27. Januar 2026)

Versionshinweise:python-1.0.0b260127

🟡 BaseAgent Unterstützung für GitHub Copilot SDK hinzugefügt

PR:#3404

Das Python SDK enthält jetzt eine BaseAgent Implementierung für GitHub Copilot SDK-Integrationen.

python-1.0.0b260123 (23. Januar 2026)

Versionshinweise:python-1.0.0b260123

🔴 Inhaltstypen, die in eine einzelne Klasse mit Klassenmethodkonstruktoren vereinfacht wurden

PR:#3252

Alle alten Inhaltstypen (abgeleitet von BaseContent) durch eine einzelne Content Klasse durch Klassenmethoden ersetzt, um bestimmte Typen zu erstellen.

Vollständige Migrationsreferenz

Zusätzliche neue Methoden (kein direkter Vorgänger):

• Content.from_text_reasoning(...) — Zum Nachdenken anregende Inhalte
• Content.from_hosted_vector_store(...) — Für Vektorspeicherverweise
• Content.from_usage(...) — Für Nutzungs-/Tokeninformationen
• Content.from_mcp_server_tool_call(...) / Content.from_mcp_server_tool_result(...) — Für MCP-Servertools
• Content.from_code_interpreter_tool_call(...) / Content.from_code_interpreter_tool_result(...) — Für Codedolmetscher
• Content.from_image_generation_tool_call(...) / Content.from_image_generation_tool_result(...) — Für die Bildgenerierung

Typüberprüfung

Verwenden Sie anstelle von isinstance() Überprüfungen die type Eigenschaft:

Before:

from agent_framework.core import TextContent, FunctionCallContent

if isinstance(content, TextContent):
    print(content.text)
elif isinstance(content, FunctionCallContent):
    print(content.name)

After:

from agent_framework.core import Content

if content.type == "text":
    print(content.text)
elif content.type == "function_call":
    print(content.name)

Einfaches Beispiel

Before:

from agent_framework.core import TextContent, DataContent, UriContent

text = TextContent(text="Hello world")
data = DataContent(data=b"binary", media_type="application/octet-stream")
uri = UriContent(uri="https://example.com/image.png", media_type="image/png")

After:

from agent_framework.core import Content

text = Content.from_text("Hello world")
data = Content.from_data(data=b"binary", media_type="application/octet-stream")
uri = Content.from_uri(uri="https://example.com/image.png", media_type="image/png")

🔴 Anmerkungstypen vereinfacht zu Annotation und TextSpanRegion TypedDicts

PR:#3252

Klassenbasierte Anmerkungstypen wurden durch einfachere TypedDict Definitionen ersetzt.

Before:

from agent_framework import CitationAnnotation, TextSpanRegion

region = TextSpanRegion(start_index=0, end_index=25)
citation = CitationAnnotation(
    annotated_regions=[region],
    url="https://example.com/source",
    title="Source Title"
)

After:

from agent_framework import Annotation, TextSpanRegion

region: TextSpanRegion = {"start_index": 0, "end_index": 25}
citation: Annotation = {
    "type": "citation",
    "annotated_regions": [region],
    "url": "https://example.com/source",
    "title": "Source Title"
}

🔴 response_format Überprüfungsfehler sind jetzt für Benutzer sichtbar

PR:#3274

ChatResponse.value und AgentResponse.value lösen jetzt ValidationError aus, wenn die Schemasvalidierung fehlschlägt, anstatt leise None zurückzugeben.

Before:

response = await agent.run(query, options={"response_format": MySchema})
if response.value:  # Returns None on validation failure - no error details
    print(response.value.name)

After:

from pydantic import ValidationError

# Option 1: Catch validation errors
try:
    print(response.value.name)  # Raises ValidationError on failure
except ValidationError as e:
    print(f"Validation failed: {e}")

# Option 2: Safe parsing (returns None on failure)
if result := response.try_parse_value(MySchema):
    print(result.name)

🔴 AG-UI-Ausführungslogik wurde vereinfacht; MCP- und Anthropic-Client-Fehlerbehebungen.

PR:#3322

Die run Methodensignatur und das Verhalten in AG-UI wurden vereinfacht.

Before:

from agent_framework.ag_ui import AGUIEndpoint

endpoint = AGUIEndpoint(agent=agent)
result = await endpoint.run(
    request=request,
    run_config={"streaming": True, "timeout": 30}
)

After:

from agent_framework.ag_ui import AGUIEndpoint

endpoint = AGUIEndpoint(agent=agent)
result = await endpoint.run(
    request=request,
    streaming=True,
    timeout=30
)

🟡 Anthropic Client unterstützt response_format jetzt strukturierte Ausgaben

PR:#3301

Sie können jetzt die strukturierte Ausgabeverarbeitung mit Anthropic-Clients über response_format verwenden, ähnlich wie OpenAI- und Azure-Clients.

🟡 Azure AI-Konfiguration erweitert (reasoning, rai_config)

PRs:#3403, #3265

Die Azure AI-Unterstützung wurde durch die Unterstützung der Begründungskonfiguration und rai_config während der Agenterstellung erweitert.

python-1.0.0b260116 (16. Januar 2026)

Versionshinweise:python-1.0.0b260116

🔴 create_agent umbenannt in as_agent

PR:#3249

Die Methode wurde umbenannt, um den Zweck besser zu verdeutlichen.

Before:

from agent_framework.core import ChatClient

client = ChatClient(...)
agent = client.create_agent()

After:

from agent_framework.core import ChatClient

client = ChatClient(...)
agent = client.as_agent()

🔴 WorkflowOutputEvent.source_executor_id umbenannt in executor_id

PR:#3166

Eigenschaft wurde für API-Konsistenz umbenannt.

Before:

async for event in workflow.run_stream(...):
    if isinstance(event, WorkflowOutputEvent):
        executor = event.source_executor_id

After:

async for event in workflow.run_stream(...):
    if isinstance(event, WorkflowOutputEvent):
        executor = event.executor_id

🟡 AG-UI unterstützt die dienstverwaltete Sitzungskontinuität.

PR:#3136

AG-UI behält nun die Identität von Dienstverwalteten Unterhaltungen (z. B. von Foundry verwaltete Sessions/Threads) bei, um die Multi-Turn-Kontinuität aufrechtzuerhalten.

python-1.0.0b260114 (14. Januar 2026)

Versionshinweise:python-1.0.0b260114

🔴 Orchestrierungen umgestaltet

PR:#3023

Umfassende Umgestaltung und Vereinfachung von Orchestrierungen in Agent Framework-Workflows:

• Gruppenchat: Orchestrator-Executor in dedizierte agentenbasierte und funktionsbasierte Komponenten aufteilen (BaseGroupChatOrchestrator, GroupChatOrchestrator, AgentBasedGroupChatOrchestrator). Vereinfacht auf Stern-Topologie mit Broadcast-Modell.
• Handoff: Unterstützung für Single-Tier, Koordinator und benutzerdefinierten Executor entfernt. Zum Übertragungsmodell mit HandoffAgentExecutor übergegangen.
• Sequenziell und gleichzeitig: Vereinfachter Anforderungsinformationsmechanismus für die Verwendung von Unterworkflows über AgentApprovalExecutor und AgentRequestInfoExecutor.

Before:

from agent_framework.workflows import GroupChat, HandoffOrchestrator

# Group chat with custom coordinator
group = GroupChat(
    participants=[agent1, agent2],
    coordinator=my_coordinator
)

# Handoff with single tier
handoff = HandoffOrchestrator(
    agents=[agent1, agent2],
    tier="single"
)

After:

from agent_framework.workflows import (
    GroupChatOrchestrator,
    HandoffAgentExecutor,
    AgentApprovalExecutor
)

# Group chat with star topology
group = GroupChatOrchestrator(
    participants=[agent1, agent2]
)

# Handoff with executor-based approach
handoff = HandoffAgentExecutor(
    agents=[agent1, agent2]
)

🔴 Als TypedDict und Generic eingeführte Optionen

PR:#3140

Optionen werden jetzt mit TypedDict typisiert, um eine bessere Typsicherheit und IDE-Autocomplete zu ermöglichen.

📖 Vollständige Migrationsanweisungen finden Sie im Handbuch für typierte Optionen.

Before:

response = await client.get_response(
    "Hello!",
    model_id="gpt-4",
    temperature=0.7,
    max_tokens=1000,
)

After:

response = await client.get_response(
    "Hello!",
    options={
        "model": "gpt-4",
        "temperature": 0.7,
        "max_tokens": 1000,
    },
)

🔴 display_name entfernt; context_provider in den Singular geändert; middleware muss Liste sein

PR:#3139

• display_name Parameter, der von Agenten entfernt wurde
• context_providers (Plural, Akzeptierte Liste) geändert in context_provider (Singular, nur 1 zulässig)
• middleware erfordert jetzt eine Liste (keine einzelne Instanz mehr akzeptiert)
• AggregateContextProvider aus Code entfernt (bei Bedarf Beispielimplementierung verwenden)

Before:

from agent_framework.core import Agent, AggregateContextProvider

agent = Agent(
    name="my-agent",
    display_name="My Agent",
    context_providers=[provider1, provider2],
    middleware=my_middleware,  # single instance was allowed
)

aggregate = AggregateContextProvider([provider1, provider2])

After:

from agent_framework.core import Agent

# Only one context provider allowed; combine manually if needed
agent = Agent(
    name="my-agent",  # display_name removed
    context_provider=provider1,  # singular, only 1
    middleware=[my_middleware],  # must be a list now
)

# For multiple context providers, create your own aggregate
class MyAggregateProvider:
    def __init__(self, providers):
        self.providers = providers
    # ... implement aggregation logic

🔴 AgentRunResponse* umbenannt in AgentResponse*

PR:#3207

AgentRunResponse und AgentRunResponseUpdate wurden umbenannt in AgentResponse und AgentResponseUpdate.

Before:

from agent_framework import AgentRunResponse, AgentRunResponseUpdate

After:

from agent_framework import AgentResponse, AgentResponseUpdate

🟡 Deklarative Workflowlaufzeit für YAML-definierte Workflows hinzugefügt

PR:#2815

Zum Ausführen deklarativer YAML-Workflows wurde eine graphbasierte Laufzeit hinzugefügt, die die Multi-Agent-Orchestrierung ohne benutzerdefinierten Laufzeitcode ermöglicht.

🟡 Verbesserungen bei der Ladezuverlässigkeit von MCP

PR:#3154

MCP-Integrationen haben ein verbessertes Verbindungsverlustverhalten, Paginierungsunterstützung beim Laden und Darstellungssteuerungsoptionen gewonnen.

🟡 Foundry A2ATool unterstützt jetzt Verbindungen ohne Ziel-URL

PR:#3127

A2ATool kann jetzt Foundry-gestützte A2A-Verbindungen über Projektverbindungsmetadaten ermöglichen, auch wenn eine direkte Ziel-URL nicht konfiguriert ist.

python-1.0.0b260107 (7. Januar 2026)

Versionshinweise:python-1.0.0b260107

Keine signifikanten Änderungen in dieser Version.

python-1.0.0b260106 (6. Januar 2026)

Versionshinweise:python-1.0.0b260106

Keine signifikanten Änderungen in dieser Version.

Zusammenfassungstabelle

Nächste Schritte