Guide des modifications significatives de Python 2026

Ce document répertorie tous les changements importants apportés aux versions de Python depuis le début de 2026, y compris et notamment les modifications cassantes et les améliorations importantes susceptibles d’affecter votre code. Chaque modification est marquée comme suit :

🔴 Rupture : nécessite des modifications de code pour la mise à niveau
🟡 Amélioration : nouvelle capacité ou amélioration ; le code existant continue de fonctionner

Ce document suit les modifications significatives de Python dans la transition 2026 preview-to-1.0.0. Veuillez donc vous y référer lors de la mise à niveau entre les versions pour vous assurer que vous ne manquez pas les modifications importantes. Pour obtenir des instructions détaillées sur la mise à niveau de sujets spécifiques (par exemple, la migration d’options), reportez-vous aux guides de mise à niveau ou aux pull requests associés.

python-1.0.0

Cette section capture les modifications significatives de Python qui ont atterri après python-1.0.0rc6 et font désormais partie .python-1.0.0

🔴 `Message(..., text=...)` la construction a maintenant été entièrement supprimée

PR :#5062

Pr #5062 termine le nettoyage du modèle de message Python précédent en supprimant les derniers chemins de code côté framework qui ont encore construit des Message objets avec text=....

Générez des messages texte comme Message(role="user", contents=["Hello"]) au lieu de Message(role="user", text="Hello").
Cela s’applique partout où vous construisez des messages directement, notamment les demandes de flux de travail, les réponses d’intergiciels personnalisés, les assistances d’orchestration et le code de migration.
Les chaînes simples à l’intérieur contents=[...] sont toujours normalisées automatiquement dans le contenu du texte. Il reste donc contents=["Hello"] le formulaire texte uniquement le plus simple.

Before:

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

After:

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

🟡 Les packages Python publiés ne nécessitent plus `--pre`

PR :#5062

Pr #5062 promeut les principaux packages Python vers 1.0.0 et met à jour les instructions d’installation pour distinguer les packages libérés des packages qui sont toujours en préversion.

agent-framework, agent-framework-core, agent-framework-openai et agent-framework-foundry sont maintenant des packages publiés et ne nécessitent plus --pre.
Connecteurs bêta tels que agent-framework-ag-ui, , agent-framework-azurefunctions, agent-framework-copilotstudioagent-framework-foundry-local, agent-framework-github-copilot, , agent-framework-mem0, et agent-framework-ollama nécessitent --pretoujours .
Si une commande d’installation unique inclut un paquet bêta, conservez --pre pour cette commande.

🔴 Foundry possède désormais des embeddings Python et des paramètres d'endpoint des modèles

PR :#5056

La requête de tirage #5056 supprime le package autonome agent-framework-azure-ai et déplace la surface d'intégration Python sur agent-framework-foundry et agent_framework.foundry.

Utilisez FoundryEmbeddingClient, FoundryEmbeddingOptionset FoundryEmbeddingSettings à partir de agent_framework.foundry.
Installez agent-framework-foundry pour le chat de Foundry, les agents gérés par service, les fournisseurs de mémoire et les embeddings.
agent_framework.azure n’exporte AzureAIInferenceEmbeddingClientplus , AzureAIInferenceEmbeddingOptions, AzureAIInferenceEmbeddingSettingsou AzureAISettings.
Les incorporations de Foundry utilisent désormais FOUNDRY_MODELS_ENDPOINT, FOUNDRY_MODELS_API_KEY, FOUNDRY_EMBEDDING_MODEL, et facultatif FOUNDRY_IMAGE_EMBEDDING_MODEL.
FoundryChatClient et FoundryAgent utilisez toujours les paramètres de point de terminaison de projet tels que FOUNDRY_PROJECT_ENDPOINT et 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"],
)

🔴 Les flux de travail acheminent désormais les kwargs d’exécution via des compartiments explicites

PR :#5010

Met à jour Python workflow.run(...) afin que les kwargs d'exécution soient passés explicitement sous forme de function_invocation_kwargs= et client_kwargs= au lieu d'un **kwargs transfert générique.

Une cartographie aplatie est traitée comme globale et est acheminée vers chaque exécuteur d'agent correspondant dans le flux de travail.
Si une ou plusieurs clés de niveau supérieur correspondent aux ID d’exécuteur, le mappage entier est traité comme un ciblage par exécuteur et chaque exécuteur reçoit uniquement sa propre entrée.
Les ID d’exécuteur de flux de travail personnalisés AgentExecutor(id="...") et explicites sont les clés que vous ciblez.
Les mêmes règles globales et ciblées s’appliquent aux deux function_invocation_kwargs et 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` exécute désormais des fournisseurs de contexte autour de chaque appel

PR :#5013

La PR #5013 corrige un écart de comportement Python où GitHubCopilotAgent était accepté context_providers mais ne les invoquait pas réellement.

before_run() s’exécute maintenant avant l’envoi de l’invite Copilot.
Les messages et instructions ajoutés par le fournisseur sont inclus dans l’invite qui atteint l’interface CLI Copilot.
after_run() s’exécute maintenant après l’assemblage de la réponse finale, y compris le chemin de diffusion en continu.

Si vous avez déjà passé context_providers à GitHubCopilotAgent, aucune migration n’est requise : les hooks se comportent désormais de manière cohérente avec le reste de la surface de l’agent Python.

🟡 La sortie structurée accepte désormais des mappages de schéma JSON en plus des modèles Pydantic

PR :#5022

Le pull request #5022 étend l'analyse de sortie structurée de Python pour que response_format puisse être soit un modèle Pydantic, soit un mappage de schéma JSON.

Les modèles Pydantic analysent toujours les instances de modèle typées sur response.value.
Les mappages de schéma JSON sont désormais analysés en valeurs Python compatibles JSON ( response.value généralement dict ou list).
Les mêmes règles d’analyse s’appliquent lorsque vous collectez la réponse finale à partir d’un flux.

Il s’agit d’une amélioration plutôt qu’d’un changement cassant, mais il est utile de savoir si vous stockez déjà des schémas en tant que dictionnaires de type JSON.

python-1.0.0rc6

Cette section présente les modifications importantes de Python incluses ou suivies dans python-1.0.0rc6.

🔴 La sélection de modèle est standardisée sur `model`

PR :#4999

Pr #4999 termine le nettoyage de sélection de modèle côté Python entre les constructeurs, les options typées, les valeurs par défaut de l’agent, les objets de réponse et les variables d’environnement.

Utilisez model partout où vous avez déjà utilisé model_id.
Agent.default_options et par exécution options={...} attendent maintenant "model", pas "model_id".
Les objets de réponse apparaissent response.model, et non response.model_id.
Les paramètres OpenAI utilisent OPENAI_MODELdésormais , OPENAI_CHAT_MODEL, OPENAI_CHAT_COMPLETION_MODELet OPENAI_EMBEDDING_MODEL.
Les paramètres Azure OpenAI utilisent AZURE_OPENAI_MODELdésormais , AZURE_OPENAI_CHAT_MODEL, AZURE_OPENAI_CHAT_COMPLETION_MODELet AZURE_OPENAI_EMBEDDING_MODEL.
L’anthropic utilise ANTHROPIC_CHAT_MODELdésormais , et Foundry Local utilise FOUNDRY_LOCAL_MODEL.
Le package anthropic ajoute également des wrappers hébergés par un fournisseur, tels que AnthropicFoundryClient, AnthropicBedrockClientet 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"},
)

🔴 Les fournisseurs de contexte peuvent ajouter des intergiciels et conserver l’historique par appel de modèle

PR :#4992

Pull request #4992 met à jour le pipeline du gestionnaire de contexte Python et la façon dont l’historique géré par le framework peut être conservé pendant les exécutions avec appels multiples.

ContextProvider et HistoryProvider sont maintenant les classes de base Python canoniques.
BaseContextProvider et BaseHistoryProvider restent temporairement en tant qu’alias déconseillés pour la compatibilité, mais le nouveau code doit migrer vers les nouveaux noms.
SessionContext peut désormais collecter les middlewares de conversation ou de fonction ajoutés par le fournisseur et exposer la liste aplatie via get_middleware().
Agent(..., require_per_service_call_history_persistence=True) exécute des gestionnaires d'historique autour de chaque appel de modèle au lieu d'une fois après l'exécution complète de run().
Ce mode est destiné à l’historique local géré par l’infrastructure et ne peut pas être combiné à une conversation gérée par le service existante, telle que session.service_session_id ou options={"conversation_id": ...}.

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

🔴 Surfaces de compatibilité Azure/OpenAI dépréciées supprimées

PR :#4990

PR #4990 complète la migration à la pointe du secteur depuis #4818 en supprimant les surfaces de compatibilité Python obsolètes qui avaient été maintenues disponibles pendant les versions préliminaires précédentes.

agent_framework.azure n'exporte plus AzureOpenAI* ni les anciennes surfaces d'agent/client/fournisseur AzureAI*.
Les types de compatibilité des assistants OpenAI Python ne font plus partie de la surface agent_framework.openai actuelle.
Utilisez OpenAIChatClient, OpenAIChatCompletionClientet OpenAIEmbeddingClient pour des scénarios OpenAI ou Azure OpenAI directs.
Utiliser FoundryChatClient pour l'inférence de projet Foundry et FoundryAgent pour les Prompt Agents ou HostedAgents.
L’espace de noms actuel agent_framework.azure couvre désormais les intégrations Azure restantes telles qu’Azure AI Search, l’historique Cosmos, Azure Functions et les workflows durables. Foundry chat, agent, mémoire et clients embeddings sous agent_framework.foundry.

Si vous migrez du code Python plus ancien, utilisez ces remplacements :

AzureOpenAIResponsesClient → OpenAIChatClient
AzureOpenAIChatClient → OpenAIChatCompletionClient
AzureOpenAIEmbeddingClient → OpenAIEmbeddingClient
AzureAIAgentClient / AzureAIClient / AzureAIProjectAgentProvider / AzureAIAgentsProvider FoundryChatClient→ ouFoundryAgent, selon que votre application possède la définition de l’agent
OpenAIAssistantsClient / OpenAIAssistantProvider OpenAIChatClient→ pour le travail Python OpenAI actuel ou FoundryAgent si vous avez besoin d’un agent géré par le service dans Foundry

🔴 Conception de client et division du paquet par le fournisseur leader

PR :#4818

Pr #4818 réorganise l’aire du fournisseur Python autour de packages et d’espaces de noms spécifiques au fournisseur.

Les clients OpenAI vivent désormais dans le package agent-framework-openai, tout en continuant à importer à partir de l’espace de noms agent_framework.openai.
Les clients Microsoft Foundry vivent désormais dans le agent-framework-foundry paquet et le agent_framework.foundry namespace.
Foundry Local est également exposé à partir de agent_framework.foundry en tant que FoundryLocalClient.
OpenAIResponsesClient est renommé OpenAIChatClient.
OpenAIChatClient est renommé OpenAIChatCompletionClient.
La configuration du client est normalisée sur model, en remplaçant les paramètres plus anciens tels que model_id, deployment_nameet model_deployment_name.
Pour le nouveau code Azure OpenAI, utilisez les agent_framework.openai clients. Les shims de compatibilité antérieurs ont été supprimés plus tard dans AzureOpenAI*#4990.
Pour le nouveau code Foundry, utilisez FoundryChatClient pour l’inférence directe du projet, FoundryAgent pour les "Prompt Agents" et "HostedAgents", et FoundryLocalClient pour les environnements locaux.
AzureAIClient, AzureAIProjectAgentProvider, AzureAIAgentClient, AzureAIAgentsProvider, et la surface de compatibilité des Assistants Python a été déplacée sur les chemins de compatibilité pendant ce refactoring et a été supprimée ultérieurement dans #4990.
La couverture des échantillons a été réorganisée pour correspondre à la nouvelle disposition axée sur le fournisseur, y compris les échantillons Foundry sous samples/02-agents/providers/foundry/.

Mappage de paquet

Scénario	Installez	Espace de noms principal
OpenAI et Azure OpenAI	`pip install agent-framework-openai`	`agent_framework.openai`
Points de terminaison du projet Microsoft Foundry, service d'agent, mémoire et représentations	`pip install agent-framework-foundry`	`agent_framework.foundry`
Fonderie Locale	`pip install agent-framework-foundry-local --pre`	`agent_framework.foundry`

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")

Si vous avez utilisé Azure OpenAI directement, mappez les anciennes classes dédiées aux nouvelles classes OpenAI principales du fournisseur :

AzureOpenAIResponsesClient → OpenAIChatClient
AzureOpenAIChatClient → OpenAIChatCompletionClient
AzureOpenAIEmbeddingClient → OpenAIEmbeddingClient
AzureOpenAIAssistantsClient OpenAIChatClient→ pour la migration directe de l’API Réponses, ou FoundryAgent si vous avez besoin d’un agent Foundry géré par le service

Le changement de code est principalement un déplacement de nom de classe plus deployment_name → model. Pour la compatibilité d’Azure OpenAI, utilisez des entrées Azure explicites sur les nouveaux clients OpenAI. credential= est désormais l'interface d'authentification Azure préférée, tandis qu'un api_key appelable reste un chemin de compatibilité :

Avant (AzureOpenAIResponsesClient) :

from agent_framework.azure import AzureOpenAIResponsesClient

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

Après (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,
)

Avant (AzureOpenAIChatClient) :

from agent_framework.azure import AzureOpenAIChatClient

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

Après (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,
)

Si vous souhaitez passer des points de terminaison Azure OpenAI à un point de terminaison de projet Microsoft Foundry, utilisez plutôt l’interface orientée Foundry :

Avant (point de terminaison Azure OpenAI) :

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

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

Après (projet Foundry) :

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)

Pour les runtimes Microsoft Foundry locaux, utilisez l’espace de noms Foundry et le connecteur local :

from agent_framework.foundry import FoundryLocalClient

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

Si vous omettez model, définissez FOUNDRY_LOCAL_MODEL dans votre environnement.

Mettez également à jour les noms d’environnement/de configuration, le cas échéant :

Utilisez OPENAI_CHAT_MODEL pour OpenAIChatClient, OPENAI_CHAT_COMPLETION_MODEL pour OpenAIChatCompletionClient, avec OPENAI_MODEL comme secours partagé.
Azure OpenAI utilise désormais AZURE_OPENAI_CHAT_MODEL pour OpenAIChatClient, AZURE_OPENAI_CHAT_COMPLETION_MODEL pour OpenAIChatCompletionClient, et AZURE_OPENAI_MODEL comme solution par défaut partagée.
Utiliser azure_endpoint pour les URL de ressource Azure OpenAI, ou base_url si vous avez déjà une URL complète .../openai/v1 et défini api_version pour la surface d’API Azure OpenAI que vous utilisez
Adopter des paramètres spécifiques à Foundry, tels que FOUNDRY_PROJECT_ENDPOINT, FOUNDRY_MODEL, FOUNDRY_AGENT_NAMEet FOUNDRY_AGENT_VERSION pour les clients Foundry cloud
Utilisez ANTHROPIC_CHAT_MODEL pour Anthropic et FOUNDRY_LOCAL_MODEL pour Foundry Local

Ce changement a d’abord été introduit pendant le python-1.0.0rc6 cycle.

🔴 Les dépendances de base sont désormais intentionnellement minces

PR :#4904

La requête d'extraction #4904 suit le découpage du package de fournisseur à partir de #4818, en réduisant agent-framework-core et en supprimant les dépendances transitives de fournisseur du package central.

agent-framework-core est maintenant intentionnellement minimal.
Si vous importez agent_framework.openai, installez agent-framework-openai.
Si vous importez agent_framework.foundry, installez agent-framework-foundry pour l’inférence de projet Foundry, les agents gérés par le service, les fournisseurs de mémoire et les incorporations. Utiliser agent-framework-foundry-local --pre pour les runtimes locaux.
Si vous utilisez des outils MCP, Agent.as_mcp_server()ou d’autres intégrations MCP sur une installation minimale, installez mcp --pre manuellement. Pour la prise en charge de WebSocket MCP, installez mcp[ws] --pre.
Si vous souhaitez l’expérience globale « tout inclus », installez le méta package agent-framework.

Cela ne redessine pas la surface du fournisseur ; il modifie ce qui est installé par défaut lorsque vous ne faites qu'intégrer le noyau.

Avant (les installations principales uniquement ont souvent apporté davantage de fonctionnalités de fournisseur transitivement) :

pip install agent-framework-core

Après (installez le package fournisseur que vous utilisez réellement) :

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

ou :

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

Si vous mettez à jour un projet existant qui dépendait précédemment de core et d’importations différées des fournisseurs, auditez vos importations et rendez les paquets de fournisseurs explicites dans votre environnement ou vos fichiers de dépendance. Faites de même pour les dépendances MCP si vous vous appuyez sur les outils MCP ou l’hébergement de serveur MCP.

🔴 Les clients OpenAI génériques préfèrent désormais les signaux de routage explicites

PR :#4925

La demande de pull #4925 change la façon dont les clients standards agent_framework.openai décident entre OpenAI et Azure OpenAI.

Les clients OpenAI génériques ne basculent plus vers Azure, car AZURE_OPENAI_* les variables d’environnement sont présentes.
S’il OPENAI_API_KEY est configuré, les clients génériques restent sur OpenAI, sauf si vous transmettez un signal de routage Azure explicite tel que credential ou azure_endpoint.
Si seuls les paramètres AZURE_OPENAI_* sont présents, les clients génériques peuvent toujours recourir au routage basé sur l’environnement Azure.
Le modèle Azure OpenAI préféré consiste maintenant à passer des paramètres Azure explicites plus credential=AzureCliCredential() sur OpenAIChatClient, OpenAIChatCompletionClient, et le client d'intégration.
Les wrappers dépréciés AzureOpenAI* conservent leur comportement de compatibilité. Par conséquent, le code basé sur des wrappers existants ne suit pas les nouvelles règles de priorité du client générique.

Avant que OpenAIChatClient puisse acheminer vers Azure, car les variables d'environnement Azure étaient présentes :

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")

Après (OpenAI générique reste sur OpenAI ; passez des entrées Azure explicites pour forcer le routage Azure) :

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

Si votre environnement contient à la fois des valeurs OPENAI_* et AZURE_OPENAI_*, auditez toute construction de client générique agent_framework.openai et rendez explicite le choix du fournisseur. L'exemple de fournisseur Azure a été mis à jour pour transmettre directement les entrées Azure pour cette raison.

Les incorporations Azure suivent désormais le même modèle de routage :

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

Pour les scénarios d’incorporation, mappez :

AzureOpenAIEmbeddingClient → OpenAIEmbeddingClient
AZURE_OPENAI_EMBEDDING_MODEL → model
OPENAI_EMBEDDING_MODEL reste la variable d’environnement d’incorporation côté OpenAI

python-1.0.0rc5 / python-1.0.0b260319 (19 mars 2026)

🔴 Pipeline du client de chat réorganisé : FunctionInvocation enveloppe désormais ChatMiddleware

PR :#4746

L’ordre des pipelines ChatClient a changé. FunctionInvocation est désormais la couche la plus externe et encapsule ChatMiddleware, ce qui signifie que l’intergiciel de conversation s’exécute par appel de modèle (y compris chaque itération de la boucle d’appel d’outil) au lieu d’une fois autour de la séquence d’appel de fonction entière.

Ancien ordre de pipeline :

ChatMiddleware → FunctionInvocation → RawChatClient

Nouvel ordre de pipeline :

FunctionInvocation → ChatMiddleware → ChatTelemetry → RawChatClient

Si vous avez un intergiciel de conversation personnalisé qui a supposé qu’il n’a été exécuté qu’une seule fois par appel d’agent (encapsulant l’intégralité de la boucle d’appel de l’outil), mettez-le à jour pour qu’il soit sécurisé pour une exécution répétée. L’intergiciel de conversation est désormais appelé pour chaque requête LLM individuelle, y compris les demandes qui envoient les résultats de l’outil au modèle.

En outre, ChatTelemetry est désormais une couche distincte de ChatMiddleware dans le pipeline, fonctionnant au plus près de RawChatClient.

🔴 kwargs du public runtime divisés en compartiments explicites

PR :#4581

L'agent Python public et les API de conversation ne considèrent plus le transfert public **kwargs comme le principal mécanisme de gestion des données à l'exécution. Les valeurs de temps d’exécution sont maintenant séparées selon leur objectif :

Utilisez function_invocation_kwargs pour les valeurs que seuls les outils ou les intergiciels de fonction doivent voir.
Utiliser client_kwargs pour les kwargs de couche client et la configuration du middleware client.
Accéder aux données d’outil/runtime via FunctionInvocationContext (ctx.kwargs et ctx.session).
Définissez des outils avec un paramètre de contexte injecté au lieu de **kwargs ; les paramètres de contexte injectés ne sont pas affichés dans le schéma que le modèle voit.
Lors de la délégation à un sous-agent en tant qu’outil, utilisez agent.as_tool(propagate_session=True) si l’agent enfant doit partager la session de l’appelant.

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",
    },
)

Si vous implémentez des méthodes publiques run() ou get_response() personnalisées, ajoutez function_invocation_kwargs et client_kwargs à ces signatures. Pour les outils, préférez un paramètre annoté comme FunctionInvocationContext : il peut être nommé ctx, contextou tout autre nom annoté. Si vous fournissez un modèle de schéma/d’entrée explicite, un paramètre non annoté simple nommé ctx est également reconnu. Le même objet de contexte est disponible pour l’intergiciel de fonction, et c’est là que la fonction runtime kwargs et l’état de session sont désormais en direct. Les définitions d’outils qui s’appuient toujours sur **kwargs utiliser uniquement un chemin de compatibilité hérité et seront supprimées.

python-1.0.0rc4 / python-1.0.0b260311 (11 mars 2026)

Notes de publication :python-1.0.0rc4

🔴 Les intégrations Azure AI ciblent désormais la version 2.0 en disponibilité générale `azure-ai-projects`

PR :#4536

Les intégrations Python Azure AI supposent désormais la surface GA 2.0 azure-ai-projects.

La plage de dépendances prise en charge est maintenant azure-ai-projects>=2.0.0,<3.0.
foundry_features la fonctionnalité passthrough a été supprimée de la création d'agents Azure AI.
Le comportement d’aperçu utilise allow_preview=True désormais sur les clients/fournisseurs pris en charge.
Des shims de compatibilité bêta/GA mixtes ont été supprimés. Veuillez donc mettre à jour les importations et les noms de types à l'interface du SDK GA 2.0.

🔴 Les gestionnaires d’outils GitHub Copilot utilisent `ToolInvocation` / `ToolResult` désormais et Python 3.11+

PR :#4551

agent-framework-github-copilot suit maintenant github-copilot-sdk>=0.1.32.

Les gestionnaires d’outils reçoivent une ToolInvocation classe de données au lieu d’une classe de données brute dict.
Retournez ToolResult en utilisant des champs snake_case tels que result_type et text_result_for_llm.
Le agent-framework-github-copilot package nécessite désormais 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 mars 2026)

Notes de publication :python-1.0.0rc3

🔴 Fournisseur de compétences finalisé autour du code défini `Skill` / `SkillResource`

PR :#4387

Les compétences de l’agent Python prennent désormais en charge les objets définis par le code, tels que Skill et SkillResource, ainsi que les compétences basées sur des fichiers, et l'interface publique du fournisseur est standardisée sur SkillsProvider.

Si vous importez toujours l’ancienne préversion/interne FileAgentSkillsProvider, basculez vers SkillsProvider.
La recherche de ressources basée sur des fichiers ne s’appuie plus sur les références entre guillemets backtick dans SKILL.md; les ressources sont découvertes à partir du répertoire de compétences à la place.

Si vous aviez un aperçu ou un code interne qui importait FileAgentSkillsProvider, basculez vers l’interface publique actuelle :

from agent_framework import Skill, SkillResource, SkillsProvider

python-1.0.0rc2 / python-1.0.0b260226 (26 février 2026)

Notes de publication :python-1.0.0rc2

🔴 Les flux de travail déclaratifs remplacent `InvokeTool` par `InvokeFunctionTool`

PR :#3716

Les flux de travail Python déclaratifs n’utilisent plus l’ancien InvokeTool type d’action. Remplacez-le par InvokeFunctionTool et enregistrez les objets appelables Python avec 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 février 2026)

Version :agent-framework-core et agent-framework-azure-ai promu(e) à 1.0.0rc1. Tous les autres packages mis à jour vers 1.0.0b260219.

🔴 Gestion unifiée des informations d’identification Azure sur tous les packages

PR :#4088

Les ad_token, ad_token_provideret get_entra_auth_token les paramètres/helpers ont été remplacés par un paramètre unifié credential sur tous les packages Python liés à Azure. La nouvelle approche utilise azure.identity.get_bearer_token_provider pour la mise en cache et l’actualisation automatiques des jetons.

Classes affectées :AzureOpenAIChatClient, , AzureOpenAIResponsesClient, , AzureOpenAIAssistantsClientAzureAIClient, AzureAIAgentClientAzureAIProjectAgentProviderAzureAIAgentsProviderAzureAISearchContextProviderPurviewClientPurviewPolicyMiddleware. PurviewChatPolicyMiddleware

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(),
    ...
)

Le credential paramètre accepte TokenCredential, AsyncTokenCredentialou un fournisseur de jetons pouvant être appelé. La mise en cache et l’actualisation des jetons sont gérées automatiquement.

🔴 Hiérarchie des exceptions Python repensée

PR :#4082

La famille plate ServiceException a été remplacée par des branches d’exception délimitées par un domaine sous une seule AgentFrameworkException racine. Cela donne aux appelants des cibles précises except et une sémantique d’erreur claire.

Nouvelle hiérarchie :

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

Exceptions supprimées :ServiceException, , ServiceInitializationError, , ServiceResponseExceptionServiceContentFilterExceptionServiceInvalidAuthErrorServiceInvalidExecutionSettingsErrorServiceInvalidRequestErrorServiceInvalidResponseErrorAgentExecutionExceptionAgentInvocationErrorAgentInitializationErrorAgentSessionException, . ChatClientInitializationErrorCheckpointDecodingError

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
    ...

Note

Les erreurs de validation d'initialisation utilisent désormais des exceptions intégrées ValueError/TypeError au lieu d’exceptions personnalisées. Les exceptions du framework d’agent sont réservées aux échecs au niveau du domaine.

🔴 État du fournisseur délimité par `source_id`

PR :#3995

Les hooks de fournisseur reçoivent maintenant un dictionnaire d'état spécifique au fournisseur (state.setdefault(provider.source_id, {})) au lieu de l'état complet de la session. Cela signifie que les implémentations de fournisseur qui ont déjà accédé à l’état imbriqué via state[self.source_id]["key"] doivent désormais accéder state["key"] directement.

En outre, InMemoryHistoryProvider la valeur par défaut a été modifiée de source_id à "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")

🔴 Alignement des messages de chat/agent (`run` vs `get_response`)

PR :#3920

Les implémentations du client get_response de conversation reçoivent Sequence[Message]désormais de manière cohérente . agent.run(...) reste flexible (str, Content, ou Message, séquences de celles-ci) et normalise les entrées avant d’appeler des clients de messagerie.

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]` configuration générique supprimée pour la transmission de schéma

PR :#3907

Les chemins d’accès des outils basés sur un schéma ne reposent plus sur le comportement générique précédent FunctionTool[Any] . Utilisez FunctionTool directement et fournissez soit un BaseModel Pydantic, soit des schémas explicites si nécessaire (par exemple, avec @tool(schema=...)).

Before:

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

After:

placeholder: FunctionTool = FunctionTool(...)

🔴 Paramètres Pydantic remplacés par `TypedDict` + `load_settings()`

PRs :#3843, #4032

La classe pydantic-settings basée sur AFBaseSettings a été remplacée par un système de paramètres léger fonctionnant avec TypedDict et load_settings(). La pydantic-settings dépendance a été entièrement supprimée.

Toutes les classes de paramètres (par exemple, OpenAISettings, AzureOpenAISettings, AnthropicSettings) sont désormais des définitions TypedDict, et les valeurs de paramètres sont accessibles via la syntaxe du dictionnaire au lieu d’accéder aux attributs.

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"]

Important

Agent Framework ne charge pas automatiquement les valeurs à partir de .env fichiers. Vous devez opter explicitement pour .env le chargement en effectuant les opérations suivantes :

Appel load_dotenv() depuis le paquet python-dotenv au démarrage de votre application
Passage env_file_path=".env" à load_settings()
Définition de variables d’environnement directement dans votre interpréteur de commandes ou votre IDE

L'ordre load_settings de résolution est : remplacements explicites → .env valeurs de fichier (lorsque env_file_path est fourni) → variables d'environnement → valeurs par défaut. Si vous spécifiez env_file_path, le fichier doit exister ou un FileNotFoundError est déclenché.

🟡 Corriger le transfert du flux de travail du modèle de raisonnement et la sérialisation de l’historique

PR :#4083

Corrige plusieurs échecs lors de l’utilisation de modèles de raisonnement (par exemple, gpt-5-mini, gpt-5.2) dans les flux de travail multi-agents. Les éléments de raisonnement de l’API Réponses sont désormais correctement sérialisés et uniquement inclus dans l’historique lorsqu’un function_call élément est également présent, empêchant les erreurs d’API. Le contenu chiffré/masqué du raisonnement est désormais correctement émis et le format du summary champ est corrigé. Il service_session_id est également effacé lors du transfert pour empêcher les fuites de l'état entre agents.

🟡 Bedrock ajouté à `core[all]` et valeurs par défaut de choix d’outils corrigées

PR :#3953

Amazon Bedrock est désormais inclus dans les agent-framework-core[all] extras et est disponible via la agent_framework.amazon surface d’importation différée. Le comportement de choix des outils a également été résolu : les valeurs de choix d’outils non définies restent désormais non définies afin que les fournisseurs utilisent leurs valeurs par défaut de service, tandis que les valeurs définies explicitement sont conservées.

from agent_framework.amazon import BedrockClient

🟡 AzureAIClient alerte sur les surcharges d’exécution non prises en charge

PR :#3919

Au moment de cette modification, AzureAIClient a enregistré un avertissement lorsque tools ou structured_output différaient de la configuration au moment de la création de l’agent. Cette surface Python a été supprimée depuis. Pour le code Python actuel, utilisez FoundryChatClient quand vous avez besoin d’une configuration d’outil/runtime appartenant à l’application ou OpenAIChatClient pour les scénarios d’API Réponses directes nécessitant des remplacements dynamiques.

🟡 `workflow.as_agent()` utilise désormais l’historique local par défaut lorsque les fournisseurs ne sont pas définis

PR :#3918

Lorsqu’on crée workflow.as_agent() sans context_providers, workflow.as_agent() ajoute désormais par défaut. Si les fournisseurs de contexte sont explicitement fournis, cette liste est conservée inchangée.

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

🟡 Contexte de trace OpenTelemetry propagé aux requêtes MCP

PR :#3780

Lorsque OpenTelemetry est installé, le contexte de trace (par exemple, W3C traceparent) est automatiquement injecté dans les requêtes MCP via params._meta. Cela permet le suivi distribué de bout en bout lors des appels depuis l'agent vers le serveur MCP. Aucune modification du code n’est nécessaire : il s’agit d’un comportement additif qui s’active lorsqu’un contexte d’étendue valide existe.

🟡 Prise en charge durable des flux de travail pour Azure Functions

PR :#3630

Le package agent-framework-azurefunctions prend désormais en charge l'exécution de graphes Workflow sur Azure Durable Functions. Transmettez un paramètre workflow à AgentFunctionApp pour enregistrer automatiquement les entités d'agents, les fonctions d'activité et les points de terminaison HTTP.

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

Prend en charge les modèles fan-out/fan-in, état partagé et human-in-the-loop avec un délai d’expiration configurable et un rejet automatique à l'expiration.

python-1.0.0b260212 (12 février 2026)

Notes de publication :python-1.0.0b260212

🔴 `HostedTool`classes remplacées par les méthodes clientes `get__tool()`

PR :#3634

Les classes d’outils hébergées ont été supprimées en faveur des méthodes d’usine à portée du client. Cela rend la disponibilité explicite de l’outil par fournisseur.

Classe supprimée	Replacement
`HostedCodeInterpreterTool`	`client.get_code_interpreter_tool()`
`HostedWebSearchTool`	`client.get_web_search_tool()`
`HostedFileSearchTool`	`client.get_file_search_tool(...)`
`HostedMCPTool`	`client.get_mcp_tool(...)`
`HostedImageGenerationTool`	`client.get_image_generation_tool(...)`

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

🔴 Pipeline de fournisseur de session/contexte finalisé (`AgentSession`, `context_providers`)

PR :#3850

La migration de session et de fournisseur de contexte Python a été terminée. AgentThread et les anciens types de fournisseurs de contexte ont été supprimés.

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= les modèles sont remplacés par 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)

🔴 Modèle de point de contrôle et comportement de stockage refactorisé

PR :#3744

Les éléments internes de point de contrôle ont été repensés, ce qui affecte la compatibilité des points de contrôle persistants et les implémentations de stockage personnalisées :

WorkflowCheckpoint stocke désormais les objets vivants (la sérialisation se produit dans le stockage de checkpoint)
FileCheckpointStorage utilise désormais la sérialisation pickle
workflow_id a été supprimé et previous_checkpoint_id a été ajouté
Les crochets de point de contrôle déconseillés ont été supprimés

Si vous conservez des points de contrôle entre les versions, régénérez ou migrez des artefacts de point de contrôle existants avant de reprendre les flux de travail.

🟡 Points de terminaison de projet trouvés à l’origine présentés via `AzureOpenAIResponsesClient`

PR :#3814

Cette fonctionnalité d'aperçu permettait initialement à AzureOpenAIResponsesClient de se connecter aux points de terminaison des projets Foundry. Les instructions Python actuelles utilisent FoundryChatClient pour l’inférence de projet Foundry ou FoundryAgent pour les agents Foundry gérés par le service, au lieu de l’élément supprimé 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` n’accepte plus `context`

PR :#3829

La continuation du middleware ne prend désormais aucun argument. Si votre intergiciel appelle call_next(context)toujours , mettez-le à jour vers 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 février 2026)

Notes de publication :python-1.0.0b260210

🔴 Méthodes de fabrique de flux de travail supprimées de `WorkflowBuilder`

PR :#3781

register_executor() et register_agent() ont été supprimés de WorkflowBuilder. Toutes les méthodes du générateur (add_edge, , add_fan_out_edges, add_fan_in_edgesadd_chain, add_switch_case_edge_group, add_multi_selection_edge_group) et start_executor n’acceptent plus les noms de chaînes , elles nécessitent directement des instances d’exécuteur ou d’agent.

Pour l'isolation de l'état, encapsulez l'instanciation des exécuteurs/agents et la conception du flux de travail à l'intérieur d'une méthode auxiliaire afin que chaque appel produise de nouvelles instances.

`WorkflowBuilder` avec exécuteurs de tâches

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` avec des agents

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()

Isolation de l’état avec les méthodes auxiliaires

Pour les flux de travail qui ont besoin d’un état isolé par invocation, encapsuler la construction dans une méthode d’assistance.

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()

🔴 `ChatAgent` renommé en `Agent`, `ChatMessage` renommé en `Message`

PR :#3747

Les types Python principaux ont été simplifiés en supprimant le préfixe redondant Chat . Aucun alias de rétrocompatibilité n’est fourni.

Avant	Après
`ChatAgent`	`Agent`
`RawChatAgent`	`RawAgent`
`ChatMessage`	`Message`
`ChatClientProtocol`	`SupportsChatGetResponse`

Mettre à jour les importations

Before:

from agent_framework import ChatAgent, ChatMessage

After:

from agent_framework import Agent, Message

Mettre à jour les références de type

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

Note

ChatClient, ChatResponse, ChatOptionset ChatMessageStore ne sont pas renommés par cette modification.

🔴 Types d'API mise à jour des avis à travers les modèles de réponse/message

PR :#3647

Cette version inclut un vaste nettoyage perturbateur du typage des messages/réponses et des API auxiliaires.

Role et FinishReason sont maintenant des wrappers NewType sur str pour les valeurs connues RoleLiteral/FinishReasonLiteral. Traitez-les comme des chaînes (aucune utilisation de .value).
Message la construction est standardisée sur Message(role, contents=[...]); les chaînes dans contents sont automatiquement converties en contenu texte.
ChatResponse et AgentResponse constructeurs se focalisent désormais sur messages= (une Message ou séquence) ; l’utilisation du constructeur hérité text= a été retirée des réponses.
ChatResponseUpdate et AgentResponseUpdate n’accepte text=plus ; utilisez contents=[Content.from_text(...)].
Les noms des assistants de combinaison de mises à jour ont été simplifiés.
try_parse_value a été supprimé de ChatResponse et AgentResponse.

Renommage de la méthode Helper

Avant	Après
`ChatResponse.from_chat_response_updates(...)`	`ChatResponse.from_updates(...)`
`ChatResponse.from_chat_response_generator(...)`	`ChatResponse.from_update_generator(...)`
`AgentResponse.from_agent_run_response_updates(...)`	`AgentResponse.from_updates(...)`

Mise à jour de la configuration de response-update

Before:

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

After:

from agent_framework import AgentResponseUpdate, Content

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

Remplacer `try_parse_value` par `try/except` on `.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}")

🔴 Modèle unifié `run`/`get_response` et `ResponseStream` utilisation

PR :#3379

Les API Python ont été consolidées autour de agent.run(...) et client.get_response(...), avec le streaming représenté par ResponseStream.

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)

🔴 Renommages de type de contexte/protocole de base

PRs :#3714, #3717

Avant	Après
`AgentRunContext`	`AgentContext`
`AgentProtocol`	`SupportsAgentRun`

Mettez à jour les importations et les annotations de type en conséquence.

🔴 Paramètre de continuation de middleware renommé à `call_next`

PR :#3735

Les signatures d’intergiciels doivent maintenant être utilisées call_next au lieu de 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)

🔴 Noms typeVar standardisés (`TName` → `NameT`)

PR :#3770

Le codebase suit maintenant un style de nommage TypeVar cohérent où le suffixe T est utilisé.

Before:

TMessage = TypeVar("TMessage")

After:

MessageT = TypeVar("MessageT")

Si vous conservez des wrappers personnalisés autour des génériques de l’infrastructure, alignez vos noms TypeVar locaux avec la nouvelle convention pour réduire l’évolution des annotations.

🔴 Modifications de sortie et de diffusion en continu de flux de travail en tant qu’agent

PR :#3649

workflow.as_agent() le comportement a été mis à jour pour aligner la sortie et le streaming avec des modèles de réponse d’agent standard. Passez en revue les consommateurs de flux de travail agissant comme agents qui dépendent de la gestion des sorties/mises à jour héritées et mettez-les à jour au flux actuel AgentResponse/AgentResponseUpdate.

🔴 Méthodes Fluent Builder déplacées vers les paramètres du constructeur

PR :#3693

Les méthodes Fluent à configuration unique sur 6 générateurs (WorkflowBuilder, SequentialBuilder, ConcurrentBuilder, GroupChatBuilder, MagenticBuilder, HandoffBuilder) ont été migrées vers des paramètres de constructeur. Les méthodes Fluent qui étaient le seul chemin de configuration d’un paramètre sont supprimées en faveur des arguments du constructeur.

`WorkflowBuilder`

set_start_executor(), with_checkpointing()et with_output_from() sont supprimés. Utilisez plutôt des paramètres de constructeur.

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()et with_intermediate_outputs() sont supprimés. Utilisez plutôt des paramètres de constructeur.

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(), et with_intermediate_outputs() sont supprimés. Utilisez plutôt des paramètres de constructeur.

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()et with_intermediate_outputs() sont supprimés. Utilisez plutôt des paramètres de constructeur.

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() et with_termination_condition() sont supprimés. Utilisez plutôt des paramètres de constructeur.

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()
)

Modifications de validation

WorkflowBuilder nécessite start_executor désormais en tant qu’argument de constructeur (précédemment défini via la méthode Fluent)
SequentialBuilder, ConcurrentBuilder, GroupChatBuilder et MagenticBuilder maintenant nécessitent soit participants soit participant_factories au moment de la construction — ne passer ni l'un ni l'autre ValueError

Note

HandoffBuilder déjà accepté participants/participant_factories comme paramètres de constructeur et n’a pas été modifié à cet égard.

🔴 Événements de flux de travail unifiés en un seul `WorkflowEvent` avec `type` discriminateur

PR :#3690

Toutes les sous-classes d’événements de flux de travail individuelles ont été remplacées par une seule classe générique WorkflowEvent[DataT] . Au lieu d’utiliser isinstance() les vérifications pour identifier les types d’événements, vous vérifiez maintenant la event.type chaîne littérale (par exemple, "output", "request_info", "status"). Cela suit le même modèle que la Content consolidation de classe à partir de python-1.0.0b260123.

Classes d’événements supprimées

Les sous-classes d’événements exportées suivantes n’existent plus :

Ancienne Classe	Nouvelle `event.type` valeur
`WorkflowOutputEvent`	`"output"`
`RequestInfoEvent`	`"request_info"`
`WorkflowStatusEvent`	`"status"`
`WorkflowStartedEvent`	`"started"`
`WorkflowFailedEvent`	`"failed"`
`ExecutorInvokedEvent`	`"executor_invoked"`
`ExecutorCompletedEvent`	`"executor_completed"`
`ExecutorFailedEvent`	`"executor_failed"`
`SuperStepStartedEvent`	`"superstep_started"`
`SuperStepCompletedEvent`	`"superstep_completed"`

Mettre à jour les importations

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

Mettre à jour les vérifications de type d’événement

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}")

Diffusion en continu avec `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}")

Annotations de type

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

Note

WorkflowEvent est générique (WorkflowEvent[DataT]), mais pour les collections d’événements mixtes, utilisez WorkflowEvent[Any] ou des non paramétré WorkflowEvent.

🔴 `workflow.send_responses*` Enlevé; Utiliser `workflow.run(responses=...)`

PR :#3720

send_responses() et send_responses_streaming() ont été supprimés de Workflow. Continuez les flux de travail suspendus en transmettant directement des réponses à 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` renommé en `State`; les API d’état du flux de travail sont synchrones

PR :#3667

Les API d’état ne nécessitent awaitplus et le nommage a été normalisé :

Avant	Après
`ctx.shared_state`	`ctx.state`
`await ctx.get_shared_state("k")`	`ctx.get_state("k")`
`await ctx.set_shared_state("k", v)`	`ctx.set_state("k", v)`
`checkpoint.shared_state`	`checkpoint.state`

🔴 Générateurs d’orchestration déplacés vers `agent_framework.orchestrations`

PR :#3685

Les générateurs d’orchestration se trouvent désormais dans un espace de noms de package dédié.

Before:

from agent_framework import SequentialBuilder, GroupChatBuilder

After:

from agent_framework.orchestrations import SequentialBuilder, GroupChatBuilder

🟡 Réponses en arrière-plan de longue durée et jetons de continuation

PR :#3808

Les réponses en arrière-plan sont désormais prises en charge pour les exécutions d'agents Python via options={"background": True} et continuation_token.

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})

🟡 Types de préversion de fournisseur de session/contexte ajoutés côte à côte

PR :#3763

De nouveaux types de pipeline de session/contexte ont été introduits en même temps que les API héritées pour la migration incrémentielle, notamment SessionContext et BaseContextProvider.

🟡 Le streaming de l’interpréteur de code inclut désormais des deltas de code incrémentiels

PR :#3775

L'interpréteur de code en streaming exécute désormais les mises à jour delta du code dans le contenu en streaming, permettant aux interfaces utilisateur de rendre le code généré de manière progressive.

🟡 `@tool` prend en charge la gestion explicite des schémas

PR :#3734

Les définitions d’outils peuvent désormais utiliser la gestion explicite des schémas lorsque la sortie de schéma déduit a besoin de personnalisation.

python-1.0.0b260130 (30 janvier 2026)

Notes de publication :python-1.0.0b260130

🟡 `ChatOptions` et `ChatResponse`/`AgentResponse` maintenant générique pour le format de réponse

PR :#3305

ChatOptions, ChatResponseet AgentResponse sont désormais des types génériques paramétrés par le type de format de réponse. Cela permet une meilleure inférence de type lors de l’utilisation de sorties structurées avec 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!)

Conseil / Astuce

Il s’agit d’une amélioration sans rupture. Le code existant sans paramètres de type continue de fonctionner. Vous n’avez pas besoin de spécifier les types dans l’extrait de code ci-dessus pour les options et la réponse ; ils sont présentés ici pour plus de clarté.

🟡 `BaseAgent` prise en charge ajoutée pour le Kit de développement logiciel (SDK) Claude Agent

PR :#3509

Le Kit de développement logiciel (SDK) Python inclut désormais une implémentation pour le SDK Claude Agent, ce qui permet une utilisation de première classe basée sur des adaptateurs au sein de l'Agent Framework.

python-1.0.0b260128 (28 janvier 2026)

Notes de publication :python-1.0.0b260128

🔴 `AIFunction` renommé en `FunctionTool` et `@ai_function` renommé en `@tool`

PR :#3413

La classe et le décorateur ont été renommés pour plus de clarté et de cohérence avec la terminologie du secteur.

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)

🔴 Modèle d’usine ajouté à GroupChat et Magentic ; Renommages d’API

PR :#3224

Ajout d'une fabrique de participants et d'une fabrique d'orchestrateurs à la discussion de groupe. Inclut aussi des renommages :

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` renommé en `GitHub`

PR :#3486

Noms de classes et de paquets mis à jour afin d'utiliser une casse appropriée.

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 janvier 2026)

Notes de publication :python-1.0.0b260127

🟡 `BaseAgent` prise en charge ajoutée pour le Kit de développement logiciel (SDK) GitHub Copilot

PR :#3404

Le Kit de développement logiciel (SDK) Python inclut désormais une BaseAgent implémentation pour les intégrations du Kit de développement logiciel (SDK) Copilot GitHub.

python-1.0.0b260123 (23 janvier 2026)

Notes de publication :python-1.0.0b260123

🔴 Types de contenu simplifiés en une seule classe avec des constructeurs classmethod

PR :#3252

Remplace tous les anciens types de contenu (dérivés de BaseContent) par une classe unique Content avec des classmethods pour créer des types spécifiques.

Référence complète pour la migration

Ancien type	Nouvelle méthode
`TextContent(text=...)`	`Content.from_text(text=...)`
`DataContent(data=..., media_type=...)`	`Content.from_data(data=..., media_type=...)`
`UriContent(uri=..., media_type=...)`	`Content.from_uri(uri=..., media_type=...)`
`ErrorContent(message=...)`	`Content.from_error(message=...)`
`HostedFileContent(file_id=...)`	`Content.from_hosted_file(file_id=...)`
`FunctionCallContent(name=..., arguments=..., call_id=...)`	`Content.from_function_call(name=..., arguments=..., call_id=...)`
`FunctionResultContent(call_id=..., result=...)`	`Content.from_function_result(call_id=..., result=...)`
`FunctionApprovalRequestContent(...)`	`Content.from_function_approval_request(...)`
`FunctionApprovalResponseContent(...)`	`Content.from_function_approval_response(...)`

Nouvelles méthodes supplémentaires (aucun prédécesseur direct) :

Content.from_text_reasoning(...) — Pour le raisonnement/le contenu réflexif
Content.from_hosted_vector_store(...) — Pour les références de stockage de vecteurs
Content.from_usage(...) — Pour les informations sur l'utilisation/le token
Content.from_mcp_server_tool_call(...) / Content.from_mcp_server_tool_result(...) — Pour les outils de serveur MCP
Content.from_code_interpreter_tool_call(...) / Content.from_code_interpreter_tool_result(...) — Pour l’interpréteur de code
Content.from_image_generation_tool_call(...) / Content.from_image_generation_tool_result(...) — Pour la génération d’images

Vérification de type

Au lieu de isinstance() vérifications, utilisez type propriété :

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)

Exemple de base

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")

🔴 Types d’annotation simplifiés vers `Annotation` et `TextSpanRegion` TypedDicts

PR :#3252

Types d’annotations basés sur des classes remplacés par des définitions plus simples TypedDict .

Ancien type	Nouveau type
`CitationAnnotation` (classe)	`Annotation` (TypedDict avec `type="citation"`)
`BaseAnnotation` (classe)	`Annotation` (TypedDict)
`TextSpanRegion` (classe avec `SerializationMixin`)	`TextSpanRegion` (TypedDict)
`Annotations` (alias de type)	`Annotation`
`AnnotatedRegions` (alias de type)	`TextSpanRegion`

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"
}

Note

Depuis Annotation et TextSpanRegion sont maintenant TypedDict, vous les créez en tant que dictionnaires plutôt que des instances de classe.

🔴 `response_format` erreurs de validation désormais visibles par les utilisateurs

PR :#3274

ChatResponse.value et AgentResponse.value déclenchent désormais ValidationError lorsque la validation du schéma échoue au lieu de retourner None silencieusement.

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)

🔴 Logique d'exécution AG-UI simplifiée ; correctifs pour les clients MCP et Anthropic

PR :#3322

La signature et le run comportement de la méthode dans AG-UI ont été simplifiés.

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
)

🟡 Le client anthropic prend désormais en charge `response_format` les sorties structurées

PR :#3301

Vous pouvez désormais utiliser l’analyse de sortie structurée avec des clients Anthropic via response_format, comme les clients OpenAI et Azure.

🟡 Configuration Azure AI développée (`reasoning`, `rai_config`)

PRs :#3403, #3265

La prise en charge d’Azure AI a été élargie pour inclure la configuration du raisonnement et rai_config pendant la création de l’agent.

python-1.0.0b260116 (16 janvier 2026)

Notes de publication :python-1.0.0b260116

🔴 `create_agent` renommé en `as_agent`

PR :#3249

Méthode renommée pour une meilleure clarté sur son objectif.

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` renommé en `executor_id`

PR :#3166

Propriété renommée pour la cohérence des API.

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 prend en charge la continuité des sessions gérées par le service

PR :#3136

AG-UI conserve désormais l'identité de conversation gérée par le service (par exemple, les sessions/threads gérés par Foundry) pour maintenir la continuité des échanges sur plusieurs tours.

python-1.0.0b260114 (14 janvier 2026)

Notes de publication :python-1.0.0b260114

🔴 Orchestrations refactorisées

PR :#3023

Refactorisation et simplification étendues des orchestrations dans les flux de travail Agent Framework :

Discussion de groupe : Diviser l'exécuteur orchestrateur en modèles basés sur agents dédiés et basés sur des fonctions (BaseGroupChatOrchestrator, GroupChatOrchestrator, AgentBasedGroupChatOrchestrator). Simplifié en une topologie en étoile avec un modèle de diffusion.
Transfert : Suppression de la prise en charge de l'architecture mononiveau, du coordinateur et de l'exécuteur personnalisé. Déplacé vers le modèle de diffusion avec HandoffAgentExecutor.
Séquentiel & Simultané : mécanisme d’informations de requête simplifié pour s’appuyer sur les sous-workflows via AgentApprovalExecutor et 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]
)

🔴 Options introduites en tant que TypedDict et Generic

PR :#3140

Les options sont désormais typées avec TypedDict pour une meilleure sécurité de type et une saisie semi-automatique plus efficace dans l'IDE.

📖 Pour obtenir des instructions de migration complètes, consultez le Guide des options typées.

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` Retiré; `context_provider` au singulier ; `middleware` doit être une liste

PR :#3139

display_name paramètre supprimé des agents
context_providers (pluriel, acceptation de la liste) remplacé par context_provider (singulier, seulement 1 autorisé)
middleware nécessite désormais une liste (n’accepte plus une seule instance)
AggregateContextProvider supprimé du code (utilisez l’exemple d’implémentation si nécessaire)

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` renommé en `AgentResponse`

PR :#3207

AgentRunResponse et AgentRunResponseUpdate ont été renommés en AgentResponse et AgentResponseUpdate.

Before:

from agent_framework import AgentRunResponse, AgentRunResponseUpdate

After:

from agent_framework import AgentResponse, AgentResponseUpdate

🟡 Runtime de flux de travail déclaratif ajouté pour les flux de travail définis par YAML

PR :#2815

Un runtime basé sur des graphiques a été ajouté pour l’exécution de flux de travail YAML déclaratifs, ce qui permet l’orchestration multi-agent sans code d’exécution personnalisé.

🟡 Améliorations du chargement/de la fiabilité MCP

PR :#3154

Les intégrations MCP ont bénéficié d'une meilleure gestion des pertes de connexion, du support de la pagination lors du chargement et de nouvelles options de contrôle de représentation.

🟡 Foundry `A2ATool` prend désormais en charge les connexions sans URL cible

PR :#3127

A2ATool peut maintenant résoudre les connexions A2A soutenues par Foundry via des métadonnées de connexion de projet, même lorsqu’une URL cible directe n’est pas configurée.

python-1.0.0b260107 (7 janvier 2026)

Notes de publication :python-1.0.0b260107

Aucune modification significative de cette version.

python-1.0.0b260106 (6 janvier 2026)

Notes de publication :python-1.0.0b260106

Aucune modification significative de cette version.

Tableau récapitulatif

Libération	Notes de publication	Type	Change	PR
1.0.0	Demande de tirage uniquement	🔴Dernière Minute	`Message(..., text=...)` la construction est entièrement supprimée ; créer des messages texte avec `contents=[...]` à la place	#5062
1.0.0	Demande de tirage uniquement	🟡 Amélioration	Les packages Python publiés (`agent-framework`, `agent-framework-core`, `agent-framework-openai`, `agent-framework-foundry`) ne nécessitent plus `--pre`, mais les connecteurs bêta le nécessitent toujours.	#5062
1.0.0	Demande de tirage uniquement	🔴Dernière Minute	Incorporations Python déplacées vers `agent_framework.foundry`; utiliser `agent-framework-foundry`, `FoundryEmbeddingClient`et `FOUNDRY_MODELS_*` paramètres au lieu du package supprimé `agent-framework-azure-ai`	#5056
1.0.0	Demande de tirage uniquement	🔴Dernière Minute	`workflow.run()` utilise désormais des ID d’exécuteur explicites `function_invocation_kwargs` / `client_kwargs`, avec le ciblage global et par exécuteur déterminé par les ID d’exécuteur	#5010
1.0.0	Demande de tirage uniquement	🟡 Amélioration	`GitHubCopilotAgent` appelle désormais les hooks du fournisseur de contexte `before_run` / `after_run` et inclut le contexte de saisie ajouté par le fournisseur	#5013
1.0.0	Demande de tirage uniquement	🟡 Amélioration	La sortie structurée Python accepte désormais les mappages de schéma JSON sous la forme `response_format`, avec le JSON analysé disponible sur `response.value`	#5022
1.0.0rc6	Demande de tirage uniquement	🔴Dernière Minute	Les surfaces de compatibilité Azure/OpenAI dépréciées ont été supprimées ; il est recommandé d'utiliser à la place les clients OpenAI proposés par le fournisseur ou les clients Python de Foundry.	#4990
1.0.0rc6	Demande de tirage uniquement	🔴Dernière Minute	Refactorisation principale du fournisseur : fractionnement `agent-framework-openai`, `agent-framework-foundry` et `agent-framework-foundry-local` ; renommer les clients OpenAI ; déplacer Foundry vers `agent_framework.foundry` ; rendre obsolètes les parcours de compatibilité Azure AI et Assistants	#4818
1.0.0rc6	Demande de tirage uniquement	🔴Dernière Minute	`agent-framework-core` est maintenant intentionnellement mince ; installer des packages de fournisseur explicites tels que `agent-framework-openai` ou `agent-framework-foundry`, et installer `mcp` manuellement pour les outils MCP sur des installations minimales, ou utiliser le méta package pour l’expérience `agent-framework` par défaut plus large	#4904
1.0.0rc6	Demande de tirage uniquement	🔴Dernière Minute	Les clients génériques `agent_framework.openai` préfèrent désormais les signaux de routage explicites ; OpenAI reste OpenAI lorsque `OPENAI_API_KEY` est défini, et les scénarios Azure doivent passer des entrées de routage Azure explicites telles que `credential` ou `azure_endpoint`, puis configurer `api_version`	#4925
1.0.0rc5 / 1.0.0b260318	N/A (planifié)	🔴Dernière Minute	Les kwargs d’exécution publique sont divisés en `function_invocation_kwargs` et `client_kwargs`; les outils utilisent désormais `FunctionInvocationContext` / `ctx.session`	#4581
1.0.0rc4 / 1.0.0b260311	Remarques	🔴Dernière Minute	Les intégrations Azure AI ciblent désormais la version générale 2.0 ; `azure-ai-projects` a été supprimée et `foundry_features` est la version préliminaire accessible sur inscription.	#4536
1.0.0rc4 / 1.0.0b260311	Remarques	🔴Dernière Minute	L’intégration de GitHub Copilot utilise `ToolInvocation` / `ToolResult`désormais ; `agent-framework-github-copilot` nécessite Python 3.11+	#4551
1.0.0rc3 / 1.0.0b260304	Remarques	🔴Dernière Minute	Le fournisseur de compétences ajoute du code défini `Skill` / `SkillResource`; les anciennes `FileAgentSkillsProvider` importations et les références de ressources backtick doivent être mises à jour	#4387
1.0.0rc2 / 1.0.0b260226	Remarques	🔴Dernière Minute	Les flux de travail déclaratifs remplacent `InvokeTool` et `InvokeFunctionToolWorkflowFactory.register_tool()`	#3716
1.0.0rc1 / 1.0.0b260219	Remarques	🔴Dernière Minute	Gestion unifiée des informations d’identification Azure dans les packages Azure	#4088
1.0.0rc1 / 1.0.0b260219	Remarques	🔴Dernière Minute	Hiérarchie des exceptions Python repensée sous `AgentFrameworkException`	#4082
1.0.0rc1 / 1.0.0b260219	Remarques	🔴Dernière Minute	L’état du fournisseur est désormais limité par `source_id`	#3995
1.0.0rc1 / 1.0.0b260219	Remarques	🔴Dernière Minute	Les implémentations personnalisées `get_response()` doivent accepter `Sequence[Message]`	#3920
1.0.0rc1 / 1.0.0b260219	Remarques	🔴Dernière Minute	`FunctionTool[Any]` shim de passage de schéma supprimé	#3907
1.0.0rc1 / 1.0.0b260219	Remarques	🔴Dernière Minute	Paramètres déplacés de `AFBaseSettings` / pydantic-settings vers `TypedDict` + `load_settings()`	#3843, #4032
1.0.0rc1 / 1.0.0b260219	Remarques	🟡 Amélioration	Correction du transfert de flux de travail de modèle de raisonnement et de la sérialisation de l'historique	#4083
1.0.0rc1 / 1.0.0b260219	Remarques	🟡 Amélioration	Bedrock ajouté à `core[all]`; les paramètres par défaut pour le choix des outils ont été corrigés	#3953
1.0.0rc1 / 1.0.0b260219	Remarques	🟡 Amélioration	`AzureAIClient` prévient des substitutions au moment de l’exécution non prises en charge	#3919
1.0.0rc1 / 1.0.0b260219	Remarques	🟡 Amélioration	`workflow.as_agent()` injecte l’historique local lorsque les fournisseurs ne sont pas définis	#3918
1.0.0rc1 / 1.0.0b260219	Remarques	🟡 Amélioration	Le contexte de trace OpenTelemetry se propage aux requêtes MCP	#3780
1.0.0rc1 / 1.0.0b260219	Remarques	🟡 Amélioration	Prise en charge durable des flux de travail ajoutée pour Azure Functions	#3630
1.0.0b260212	Remarques	🔴Dernière Minute	`HostedTool`classes supprimées ; créer des outils hébergés via des méthodes clientes `get__tool()`	#3634
1.0.0b260212	Remarques	🔴Dernière Minute	Pipeline de fournisseur de session/contexte finalisé : `AgentThread` supprimé, utilisez `AgentSession` + `context_providers`	#3850
1.0.0b260212	Remarques	🔴Dernière Minute	Modèle de point de contrôle/refactorisation du stockage (`workflow_id` supprimé, `previous_checkpoint_id` ajouté, comportement de stockage modifié)	#3744
1.0.0b260212	Remarques	🟡 Amélioration	`AzureOpenAIResponsesClient` peut être créé à partir du point de terminaison du projet Foundry ou `AIProjectClient`	#3814
1.0.0b260212	Remarques	🔴Dernière Minute	La continuation du middleware n’accepte plus `context` ; mettez à jour `call_next(context)` vers `call_next()`	#3829
1.0.0b260210	Remarques	🔴Dernière Minute	`send_responses()` / `send_responses_streaming()` Enlevé; Utiliser `workflow.run(responses=...)`	#3720
1.0.0b260210	Remarques	🔴Dernière Minute	`SharedState` → `State`; les API d’état du flux de travail sont synchrones et le champ d’état du point de contrôle a été renommé.	#3667
1.0.0b260210	Remarques	🔴Dernière Minute	Générateurs d’orchestration déplacés vers le `agent_framework.orchestrations` package	#3685
1.0.0b260210	Remarques	🟡 Amélioration	Réponses en arrière-plan et prise en charge de `continuation_token` ajoutées aux réponses de l’agent Python	#3808
1.0.0b260210	Remarques	🟡 Amélioration	Types d’aperçu de session/contexte ajoutés côte à côte (`SessionContext`, `BaseContextProvider`)	#3763
1.0.0b260210	Remarques	🟡 Amélioration	Les mises à jour de l’interpréteur de code de streaming incluent désormais des deltas de code incrémentiels	#3775
1.0.0b260210	Remarques	🟡 Amélioration	`@tool` décorateur ajoute une prise en charge explicite de la gestion des schémas	#3734
1.0.0b260210	Remarques	🔴Dernière Minute	`register_executor()` / `register_agent()` supprimé de `WorkflowBuilder` ; utilisez directement des instances, méthodes utilitaires pour l’isolation de l’état	#3781
1.0.0b260210	Remarques	🔴Dernière Minute	`ChatAgent` → `Agent`, `ChatMessage` → `Message`, `RawChatAgent` → `RawAgent`, `ChatClientProtocol` → `SupportsChatGetResponse`	#3747
1.0.0b260210	Remarques	🔴Dernière Minute	Révision de l’API Types : `Role`/`FinishReason` modifications de type, renforcement du constructeur pour la réponse/mise à jour, renommage des assistants `from_updates` et suppression de `try_parse_value`	#3647
1.0.0b260210	Remarques	🔴Dernière Minute	API unifiées autour `run`/`get_response` et `ResponseStream`	#3379
1.0.0b260210	Remarques	🔴Dernière Minute	`AgentRunContext` renommé en `AgentContext`	#3714
1.0.0b260210	Remarques	🔴Dernière Minute	`AgentProtocol` renommé en `SupportsAgentRun`	#3717
1.0.0b260210	Remarques	🔴Dernière Minute	Paramètre middleware `next` renommé en `call_next`	#3735
1.0.0b260210	Remarques	🔴Dernière Minute	Nommage TypeVar standardisé (`TName` → `NameT`)	#3770
1.0.0b260210	Remarques	🔴Dernière Minute	Comportement de sortie/flux du flux de travail en tant qu'agent correspondant au flux de réponse de l'agent actuel	#3649
1.0.0b260210	Remarques	🔴Dernière Minute	Méthodes Fluent Builder déplacées vers des paramètres de constructeur sur 6 générateurs	#3693
1.0.0b260210	Remarques	🔴Dernière Minute	Événements de flux de travail unifiés en un seul `WorkflowEvent` avec `type` discriminateur ; `isinstance()` → `event.type == "..."`	#3690
1.0.0b260130	Remarques	🟡 Amélioration	`ChatOptions` / `ChatResponse` / `AgentResponse` générique sur le format de réponse	#3305
1.0.0b260130	Remarques	🟡 Amélioration	`BaseAgent` prise en charge ajoutée pour les intégrations du Kit de développement logiciel (SDK) Claude Agent	#3509
1.0.0b260128	Remarques	🔴Dernière Minute	`AIFunction` → `FunctionTool`, `@ai_function` → `@tool`	#3413
1.0.0b260128	Remarques	🔴Dernière Minute	Modèle d’usine pour GroupChat/Magentic ; `with_standard_manager` → `with_manager`, `participant_factories` → `register_participant`	#3224
1.0.0b260128	Remarques	🔴Dernière Minute	`Github` → `GitHub`	#3486
1.0.0b260127	Remarques	🟡 Amélioration	`BaseAgent` prise en charge ajoutée pour les intégrations du Kit de développement logiciel (SDK) GitHub Copilot	#3404
1.0.0b260123	Remarques	🔴Dernière Minute	Types de contenu consolidés à une classe unique `Content` avec classmethods	#3252
1.0.0b260123	Remarques	🔴Dernière Minute	`response_format` maintenant, les erreurs de validation déclenchent `ValidationError`	#3274
1.0.0b260123	Remarques	🔴Dernière Minute	La logique d'exécution de l'AG-UI simplifiée	#3322
1.0.0b260123	Remarques	🟡 Amélioration	Le client Anthropic ajoute la prise en charge `response_format` des sorties structurées	#3301
1.0.0b260123	Remarques	🟡 Amélioration	La configuration Azure AI étendue avec la prise en charge de `reasoning` et `rai_config`	#3403, #3265
1.0.0b260116	Remarques	🔴Dernière Minute	`create_agent` → `as_agent`	#3249
1.0.0b260116	Remarques	🔴Dernière Minute	`source_executor_id` → `executor_id`	#3166
1.0.0b260116	Remarques	🟡 Amélioration	AG-UI prend en charge la continuité des threads/sessions gérés par le service	#3136
1.0.0b260114	Remarques	🔴Dernière Minute	Orchestrations refactorisées (GroupChat, Handoff, Séquentiel, Simultané)	#3023
1.0.0b260114	Remarques	🔴Dernière Minute	Options comme TypedDict et Generic	#3140
1.0.0b260114	Remarques	🔴Dernière Minute	`display_name` Enlevé; `context_providerscontext_provider` → (singulier) ; `middleware` doit être listé	#3139
1.0.0b260114	Remarques	🔴Dernière Minute	`AgentRunResponse` / `AgentRunResponseUpdate` renommé en `AgentResponse`/`AgentResponseUpdate`	#3207
1.0.0b260114	Remarques	🟡 Amélioration	Runtime de flux de travail déclaratif ajouté pour les flux de travail définis par YAML	#2815
1.0.0b260114	Remarques	🟡 Amélioration	Améliorations du chargement/de la fiabilité MCP (gestion des pertes de connexion, pagination, contrôles de représentation)	#3154
1.0.0b260114	Remarques	🟡 Amélioration	Foundry `A2ATool` prend en charge les connexions sans URL cible explicite	#3127
1.0.0b260107	Remarques	—	Aucune modification significative	—
1.0.0b260106	Remarques	—	Aucune modification significative	—

Prochaines étapes

Vue d’ensemble du support

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-04-02

Partager via

Guide des modifications significatives de Python 2026

python-1.0.0

🔴 Message(..., text=...) la construction a maintenant été entièrement supprimée

🟡 Les packages Python publiés ne nécessitent plus --pre

🔴 Foundry possède désormais des embeddings Python et des paramètres d'endpoint des modèles

🔴 Les flux de travail acheminent désormais les kwargs d’exécution via des compartiments explicites

🟡 GitHubCopilotAgent exécute désormais des fournisseurs de contexte autour de chaque appel

🟡 La sortie structurée accepte désormais des mappages de schéma JSON en plus des modèles Pydantic

python-1.0.0rc6

🔴 La sélection de modèle est standardisée sur model

🔴 Les fournisseurs de contexte peuvent ajouter des intergiciels et conserver l’historique par appel de modèle

🔴 Surfaces de compatibilité Azure/OpenAI dépréciées supprimées

🔴 Conception de client et division du paquet par le fournisseur leader

Mappage de paquet

🔴 Les dépendances de base sont désormais intentionnellement minces

🔴 Les clients OpenAI génériques préfèrent désormais les signaux de routage explicites

python-1.0.0rc5 / python-1.0.0b260319 (19 mars 2026)

🔴 Pipeline du client de chat réorganisé : FunctionInvocation enveloppe désormais ChatMiddleware

🔴 kwargs du public runtime divisés en compartiments explicites

python-1.0.0rc4 / python-1.0.0b260311 (11 mars 2026)

🔴 Les intégrations Azure AI ciblent désormais la version 2.0 en disponibilité générale azure-ai-projects

🔴 Les gestionnaires d’outils GitHub Copilot utilisent ToolInvocation / ToolResult désormais et Python 3.11+

python-1.0.0rc3 / python-1.0.0b260304 (4 mars 2026)

🔴 Fournisseur de compétences finalisé autour du code défini Skill / SkillResource

python-1.0.0rc2 / python-1.0.0b260226 (26 février 2026)

🔴 Les flux de travail déclaratifs remplacent InvokeTool par InvokeFunctionTool

python-1.0.0rc1 / python-1.0.0b260219 (19 février 2026)

🔴 Gestion unifiée des informations d’identification Azure sur tous les packages

🔴 Hiérarchie des exceptions Python repensée

🔴 État du fournisseur délimité par source_id

🔴 Alignement des messages de chat/agent (run vs get_response)

🔴 FunctionTool[Any] configuration générique supprimée pour la transmission de schéma

🔴 Paramètres Pydantic remplacés par TypedDict + load_settings()

🟡 Corriger le transfert du flux de travail du modèle de raisonnement et la sérialisation de l’historique

🟡 Bedrock ajouté à core[all] et valeurs par défaut de choix d’outils corrigées

🟡 AzureAIClient alerte sur les surcharges d’exécution non prises en charge

🟡 workflow.as_agent() utilise désormais l’historique local par défaut lorsque les fournisseurs ne sont pas définis

🟡 Contexte de trace OpenTelemetry propagé aux requêtes MCP

🟡 Prise en charge durable des flux de travail pour Azure Functions

python-1.0.0b260212 (12 février 2026)

🔴 Hosted*Toolclasses remplacées par les méthodes clientes get_*_tool()

🔴 Pipeline de fournisseur de session/contexte finalisé (AgentSession, context_providers)

🔴 Modèle de point de contrôle et comportement de stockage refactorisé

🟡 Points de terminaison de projet trouvés à l’origine présentés via AzureOpenAIResponsesClient

🔴 Middleware call_next n’accepte plus context

python-1.0.0b260210 (10 février 2026)

🔴 Méthodes de fabrique de flux de travail supprimées de WorkflowBuilder

WorkflowBuilder avec exécuteurs de tâches

WorkflowBuilder avec des agents

Isolation de l’état avec les méthodes auxiliaires

🔴 ChatAgent renommé en Agent, ChatMessage renommé en Message

Mettre à jour les importations

Mettre à jour les références de type

🔴 Types d'API mise à jour des avis à travers les modèles de réponse/message

Renommage de la méthode Helper

Mise à jour de la configuration de response-update

Remplacer try_parse_value par try/except on .value

🔴 Modèle unifié run/get_response et ResponseStream utilisation

🔴 Renommages de type de contexte/protocole de base

🔴 Paramètre de continuation de middleware renommé à call_next

🔴 Noms typeVar standardisés (TName → NameT)

🔴 Modifications de sortie et de diffusion en continu de flux de travail en tant qu’agent

🔴 Méthodes Fluent Builder déplacées vers les paramètres du constructeur

WorkflowBuilder

SequentialBuilder / ConcurrentBuilder

GroupChatBuilder

MagenticBuilder

HandoffBuilder

Modifications de validation

🔴 Événements de flux de travail unifiés en un seul WorkflowEvent avec type discriminateur

Classes d’événements supprimées

Mettre à jour les importations

Mettre à jour les vérifications de type d’événement

Diffusion en continu avec AgentResponseUpdate

Annotations de type

🔴 workflow.send_responses* Enlevé; Utiliser workflow.run(responses=...)

🔴 SharedState renommé en State; les API d’état du flux de travail sont synchrones

🔴 Générateurs d’orchestration déplacés vers agent_framework.orchestrations

🟡 Réponses en arrière-plan de longue durée et jetons de continuation

🔴 `Message(..., text=...)` la construction a maintenant été entièrement supprimée

🟡 Les packages Python publiés ne nécessitent plus `--pre`

🟡 `GitHubCopilotAgent` exécute désormais des fournisseurs de contexte autour de chaque appel

🔴 La sélection de modèle est standardisée sur `model`

🔴 Les intégrations Azure AI ciblent désormais la version 2.0 en disponibilité générale `azure-ai-projects`

🔴 Les gestionnaires d’outils GitHub Copilot utilisent `ToolInvocation` / `ToolResult` désormais et Python 3.11+

🔴 Fournisseur de compétences finalisé autour du code défini `Skill` / `SkillResource`

🔴 Les flux de travail déclaratifs remplacent `InvokeTool` par `InvokeFunctionTool`

🔴 État du fournisseur délimité par `source_id`

🔴 Alignement des messages de chat/agent (`run` vs `get_response`)

🔴 `FunctionTool[Any]` configuration générique supprimée pour la transmission de schéma

🔴 Paramètres Pydantic remplacés par `TypedDict` + `load_settings()`

🟡 Bedrock ajouté à `core[all]` et valeurs par défaut de choix d’outils corrigées

🟡 `workflow.as_agent()` utilise désormais l’historique local par défaut lorsque les fournisseurs ne sont pas définis

🔴 `HostedTool`classes remplacées par les méthodes clientes `get__tool()`

🔴 Pipeline de fournisseur de session/contexte finalisé (`AgentSession`, `context_providers`)

🟡 Points de terminaison de projet trouvés à l’origine présentés via `AzureOpenAIResponsesClient`

🔴 Middleware `call_next` n’accepte plus `context`

🔴 Méthodes de fabrique de flux de travail supprimées de `WorkflowBuilder`

`WorkflowBuilder` avec exécuteurs de tâches

`WorkflowBuilder` avec des agents

🔴 `ChatAgent` renommé en `Agent`, `ChatMessage` renommé en `Message`

Remplacer `try_parse_value` par `try/except` on `.value`

🔴 Modèle unifié `run`/`get_response` et `ResponseStream` utilisation

🔴 Paramètre de continuation de middleware renommé à `call_next`

🔴 Noms typeVar standardisés (`TName` → `NameT`)

`WorkflowBuilder`

`SequentialBuilder` / `ConcurrentBuilder`

`GroupChatBuilder`

`MagenticBuilder`

`HandoffBuilder`

🔴 Événements de flux de travail unifiés en un seul `WorkflowEvent` avec `type` discriminateur

Diffusion en continu avec `AgentResponseUpdate`

🔴 `workflow.send_responses*` Enlevé; Utiliser `workflow.run(responses=...)`

🔴 `SharedState` renommé en `State`; les API d’état du flux de travail sont synchrones

🔴 Générateurs d’orchestration déplacés vers `agent_framework.orchestrations`

🟡 `@tool` prend en charge la gestion explicite des schémas

🟡 `ChatOptions` et `ChatResponse`/`AgentResponse` maintenant générique pour le format de réponse

🟡 `BaseAgent` prise en charge ajoutée pour le Kit de développement logiciel (SDK) Claude Agent

🔴 `AIFunction` renommé en `FunctionTool` et `@ai_function` renommé en `@tool`

🔴 `Github` renommé en `GitHub`

🟡 `BaseAgent` prise en charge ajoutée pour le Kit de développement logiciel (SDK) GitHub Copilot

🔴 Types d’annotation simplifiés vers `Annotation` et `TextSpanRegion` TypedDicts

🔴 `response_format` erreurs de validation désormais visibles par les utilisateurs

🟡 Le client anthropic prend désormais en charge `response_format` les sorties structurées

🟡 Configuration Azure AI développée (`reasoning`, `rai_config`)

🔴 `create_agent` renommé en `as_agent`

🔴 `WorkflowOutputEvent.source_executor_id` renommé en `executor_id`

🔴 `display_name` Retiré; `context_provider` au singulier ; `middleware` doit être une liste

🔴 `AgentRunResponse` renommé en `AgentResponse`

🟡 Foundry `A2ATool` prend désormais en charge les connexions sans URL cible