Migrieren von Agentenanwendungen zur neuen Agentenschnittstelle und zum neuen Veröffentlichungserlebnis

In diesem Handbuch wird erläutert, wie sich die Agent-Veröffentlichungserfahrung in Microsoft Foundry geändert hat. Es vergleicht das Legacymodell (das eine separate Agent-Anwendungsressource erstellt hat) mit dem neuen Agentobjektmodell und führt Sie durch die Migration Ihrer vorhandenen Agents und veröffentlichten Anwendungen.

Übersicht über die Änderung

Das neue Agent-Objektmodell reduziert Agentanwendungen und Agentbereitstellungen in das Agent-Objekt selbst. Früher wurde für eine Veröffentlichung eine separate Agent-Anwendungsressource mit eigener Identität, eigenem Endpunkt und eigener Bereitstellung erstellt. Jetzt verfügt jeder Agent über diese Funktionen, sobald er erstellt wurde.

Vorher (Legacy-Modell)

1. Ressourcenmodell: Ein Agent (Datenebene), Agent-Anwendung (Kontrollebene) und Die Bereitstellung (Steuerungsebene) sind separate Objekte.
2. Agent-Objekteigenschaften: id (eindeutiger Bezeichner für den Agent), nameund versions (die neueste Agent-Version).
3. Identität: Unveröffentlichte Agents in einem Foundry-Projekt teilen eine Entra-Agent-Identität und einen Entra-Agent-Blueprint. Bei Veröffentlichung erhält ein Agent eine eindeutige Identität und eine Blaupause mit Gültigkeit für die Agent-Anwendungsressource.
4. Veröffentlichung: Zwei Gesten. Zuerst erstellt die Veröffentlichung eines Agents eine Agentanwendungsressource und eine Bereitstellung, bei der die Bereitstellung auf die veröffentlichte Agent-Version verweist. Die Agentanwendung bietet ein stabiles Endpunktrouting an, das 100% des Datenverkehrs zu dieser Version leitet. Eine Bereitstellung unterstützt die Start-/Stopp-Lebenszyklusverwaltung. Die zweite Geste besteht darin, dass die Agentanwendung dann in Microsoft 365 und Teams veröffentlicht werden kann.

After (neues Modell)

1. Ressourcenmodell: Nur Agent-Objekte sind vorhanden (Datenebene und Kontrollebene). Sie übernehmen die Verantwortung, die zuvor im Besitz von Agent-Anwendung und -Bereitstellung waren.
2. Agent-Objekteigenschaften: id, name, versions, agent_endpoint (stabilen Endpunkt), protocols, authorization_schemes, version_selector, blueprint, instance_identity und agent_card (zeigt Agentendetails und Funktionen für Verbraucher und A2A).
3. Identität: Alle Agents erhalten standardmäßig einen eindeutigen Entra-Agent-Identitäts- und Entra-Agent-Blueprint. Bring-your-own Entra Agent Blueprint wird unterstützt, ist jedoch nicht die Standardeinstellung.
4. Veröffentlichung: Zwei entsprechende Gesten. Wählen Sie zunächst eine Agentversion aus, die über den stabilen Endpunkt verfügbar gemacht werden soll. Veröffentlichen Sie zweitens den stabilen Endpunkt des Agents in M365/Teams.

Die Schlüsselverschiebung: Das Erstellen eines Agents ist der einzige Schritt, der erforderlich ist , um einen stabilen Endpunkt und eine eindeutige Agentidentität zu erhalten. Es gibt keinen separaten Veröffentlichungsschritt für den Endpunkt. Die Veröffentlichung bezieht sich jetzt speziell auf die Verteilung des Agenten über Microsoft 365- und Microsoft Teams-Kanäle.

Agenttypen während des Übergangs

Während des Übergangszeitraums treten möglicherweise drei Arten von Agents auf:

Der agent.identity Wert unterscheidet neue Agenten von Altagenten: null bedeutet alt, nicht-null bedeutet neu.

Was weiter funktioniert

• Vorhandene Agentanwendungen dienen weiterhin dem Datenverkehr über ihre Endpunkte.
• Agents, die über Agent-Anwendungen in M365/Teams veröffentlicht wurden, funktionieren weiterhin.
• Der Projektendpunkt bleibt aus Gründen der Abwärtskompatibilität verfügbar (obwohl er nicht mehr der empfohlene Pfad ist).
• Legacy-Agents bleiben für die Entwicklung und Tests im Foundry-Projekt voll funktionsfähig.

Migrationspfade

Pfad 1: Neue Agents (keine Aktion erforderlich)

Wenn Sie Agents nach der Aktualisierung des Objektmodells erstellen, erhalten sie automatisch das neue Modell mit eindeutiger Identität, stabilem Endpunkt und allen neuen Features. Es ist keine Migration erforderlich.

Pfad 2: Upgrade eines Legacy-Agents

Legacy-Agents (erstellt vor dem Update) verwenden die freigegebene Projektidentität und können nicht über das neue Modell veröffentlicht werden. So führen Sie ein Upgrade durch:

1. Überprüfen Sie, ob Ihr Agent ein Legacy-Agent ist:

   GET {endpoint}/agents/{agent_name}?api-version=2025-11-15-preview
   Authorization: Bearer {{token}}
   Foundry-Features: AgentEndpoints=V1Preview
   

   Wenn instance_identity null in der Antwort ist, handelt es sich um einen Legacy-Agent.

2. Erstellen Sie einen neuen Agent mit derselben Definition:

   Hinweis

   Es gibt derzeit keine Möglichkeit, einen Legacy-Agent auf eine eindeutige Identität zu aktualisieren. Um eine eindeutige Identität zu erhalten, erstellen Sie einen neuen Agent mit derselben Definition (Anweisungen, Tools, Modellkonfiguration). Der neue Agent empfängt automatisch eine eindeutige Identität und einen stabilen Endpunkt. Ein direkter Upgrade-Pfad ist für ein zukünftiges Update geplant.

3. Nachdem der neue Agent erstellt wurde, verfügt er über eine eindeutige Identität, und Sie können alle neuen Features verwenden, einschließlich der neuen Veröffentlichungsoberfläche, die den Agentendpunkt verwendet.

Pfad 3: Migrieren einer vorhandenen Agentanwendung

Wenn Sie eine Agentanwendung in M365/Teams veröffentlicht haben und zum neuen Modell migrieren möchten, führen Sie die folgenden Schritte aus:

1. Erstellen Sie einen neuen Agent mit derselben Definition wie der Agent hinter Ihrer Agentanwendung (Anweisungen, Tools, Modellkonfiguration). Der neue Agent empfängt automatisch eine eindeutige Identität und einen stabilen Endpunkt. Weitere Informationen finden Sie unter Path 2 .

2. Veröffentlichen Sie den neuen Agent über das Foundry-Portal auf Microsoft 365 und Teams . Die Veröffentlichung ist nur über das Foundry-Portal verfügbar – es gibt keine öffentliche Veröffentlichungs-API. Schritte finden Sie unter Veröffentlichen von Agents in Microsoft 365 Copilot und Microsoft Teams.

3. Überprüfen Sie, ob der neue Agent in M365/Teams mit dem neuen stabilen Endpunkt funktioniert.

4. Setzen Sie die alte Agentanwendung außer Betrieb , nachdem Sie bestätigt haben, dass der neue Agent funktioniert:

   • Löschen Sie die Azure-Ressource der Agentanwendung. Durch das Löschen der Ressource werden Die Agentversionen nicht gelöscht.
   • Um vorhandene Integrationen funktionsfähig zu halten, aktualisieren Sie jeden Code, der auf die alte Anwendungsendpunkt-URL verweist, um die neue stabile Endpunkt-URL des Agents zu verwenden.

Endpunkt-URL-Änderungen

Aktualisieren Sie bei der Migration Code oder Integrationen, die auf das alte Endpunktformat verweisen:

Veröffentlichung von UX während des Übergangsprozesses

Während des Übergangs werden je nach Agenttyp möglicherweise unterschiedliche Veröffentlichungserfahrungen angezeigt.

• Neue Agenten (agent.identity != null): Sie sehen die neue Benutzeroberfläche für die Veröffentlichung mit stabiler Endpunktauswahl, Versionsrouting und direkter Veröffentlichung nach M365/Teams.
• Ältere Agents (agent.identity == null): Die ältere Veröffentlichungs-UX der Agent-Anwendung wird angezeigt. Ein Banner kann darauf hinweisen, dass die neue Oberfläche mit einem Link zum Upgrade verfügbar ist.

Zeitachse und Einstellung

Faqs

Muss ich sofort migrieren?

Nein. Vorhandene Agentanwendungen funktionieren weiterhin. Neue Features (Datenverkehrsteilung, mehrere Protokolle, Deaktivierung/Aktivierung, A2A) stehen jedoch nur im neuen Agentmodell zur Verfügung.

Funktioniert meine Agentanwendung nicht mehr?

Nicht sofort. Agent-Anwendungen werden mit vorheriger Ankündigung und Angabe eines Migrationszeitraums eingestellt. Sie funktionieren bis zum Enddatum des Supports.

Kann ich sowohl über eine Agentanwendung als auch über einen Neuen Modell-Agent für denselben zugrunde liegenden Agent verfügen?

Ja, während des Übergangs. Die Agentanwendung und der neue Agentendpunkt können koexistieren. Sie sind jedoch separate Ressourcen mit separaten Identitäten und Endpunkten.

Was geschieht mit rollenbasierten Azure-Zugriffssteuerungsrollen (RBAC), die ich auf Agentanwendungsressourcen zugewiesen habe?

RBAC für Agent-Anwendungsressourcen wird nicht an das Agent-Objekt übertragen. Sie müssen Rollen (z. B. Foundry Agent Consumer) für die Agentressource für den neuen Endpunkt zuweisen.

Mein Agent verwendet Tools, die sich über die Agentenidentität authentifizieren. Was ändert sich?

Mit dem neuen Modell verfügt der Agent über eine eindeutige Identität aus der Erstellung – daher gibt es zur Veröffentlichungszeit keine Identitätsänderung. Wenn Sie jedoch von einem Legacy-Agent migrieren, erhält der Agent eine neue Identität, die sich von der freigegebenen Projektidentität und jeder Agentanwendungsidentität unterscheidet. Sie müssen RBAC für nachgelagerte Ressourcen neu zuweisen.

Verwandte Inhalte

• Agentanwendungen in Microsoft Foundry
• Veröffentlichen von Agents in Microsoft 365 Copilot und Teams
• Agentidentitätskonzepte in Foundry