Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Ein Hersteller entwickelt eine Kundendienstlösung, bei der drei Geschäftseinheiten – PERSONAL, IT und Finanzen – ihre eigenen Verfahren pflegen und ihre Agentenkomponenten unabhängig voneinander weiterentwickeln müssen. Welches Merkmal dieses Szenarios rechtfertigt eine Multi-Agent-Architektur?
Unabhängige Teambesitz in drei Geschäftsdomänen bedeutet, dass jedes Team seine Agentkomponente erstellen, aktualisieren und freigeben kann, ohne dass sich dies auf die anderen auswirkt.
Drei Domänenteams bedeuten, dass dreimal so viele Aktionen erforderlich sind, wodurch der Schwellenwert für die Routing-Genauigkeit von 30 bis 40 Aktionen automatisch überschritten wird.
Die Verfahren des IT-Teams sind komplexer als HR oder Finance, was eine separate KI-Modellkonfiguration für diese Komponente erfordert.
Ein Beschaffungsteam muss Lieferantenverträge durch drei obligatorische Complianceprüfungen in definierter Reihenfolge validieren und dann genehmigte Verträge an einen juristischen Prüfer weiterleiten, bevor die endgültige Freigabe erfolgt. Es kann kein Schritt übersprungen oder neu angeordnet werden. Welches Orchestrierungsmuster ist am besten geeignet?
Orchestrator/untergeordneter Agent – der Orchestrator kann die Ausgabe jedes Compliance-Agents auswerten und entscheiden, welcher Agent als Nächstes aufgerufen werden soll.
Workfloworientiert – der Prozess ist deterministisch mit strikter Schrittordnung und einem menschlichen Genehmigungsgater.
Ein hybrides Muster: gleichzeitige Überprüfungen der Einhaltung von Vorschriften hinsichtlich Geschwindigkeit, gefolgt von dynamischem Routing zum rechtlichen Prüfer.
Ein Team von Orchestrator-Agenten muss seiner Lösung eine Abrechnungsfunktion hinzufügen. Die Funktion ist noch nicht vorhanden, dasselbe Team erstellt und verwaltet es und muss nur über diesen spezifischen Orchestrator verfügbar sein. Welchen Agenttyp sollte das Team verwenden?
Ein untergeordneter Agent, der im Orchestrator erstellt wurde.
Ein vorhandener Copilot Studio-Agent, der aus derselben Umgebung verbunden ist.
Ein Microsoft Foundry-Agent zum Konfigurieren spezieller Modellgründe für die Abrechnungsworkflows.
Ein Logistikpartner macht eine Sendungsverfolgungsfunktion als separat gehosteter Agent verfügbar, der sein eigenes Reasoning auf einer Nicht-Microsoft-Plattform verwaltet. Welche Verbindungsoption eignet sich am besten beim Hinzufügen dieser Funktion zu einem Copilot Studio Orchestrator?
Bestehender Copilot Studio-Agent: Der Agent des Partners kann in derselben Copilot Studio-Umgebung erneut veröffentlicht werden.
A2A-Protokoll-Agent: Der offene Agent2Agent-Standard ermöglicht plattformübergreifende Agentkommunikation, ohne dass der Partner seinen Agent in Copilot Studio neu erstellen muss.
Microsoft Foundry-Agent: Azure AI Foundry kann die externe Begründungskonfiguration des Partners darstellen.
Ein Hersteller, der eine Multi-Agent-Lösung erstellt, ist besorgt darüber, dass das Hinzufügen verbundener Agents die Endbenutzererfahrung negativ beeinflusst, indem die Antworten langsamer wirken. Welches Merkmal von Multi-Agent-Architekturen ist für dieses Anliegen am unmittelbarsten relevant?
Die Governanceoberfläche wird mit jedem verbundenen Agent erweitert, wodurch die Test- und Sicherheitsüberprüfungsauslastung des Herstellers erhöht wird.
Jeder angeschlossene Agent fügt Latenz durch Orchestrierungsschritte hinzu, wenn der Hauptagent delegiert, auf die Antwort des angeschlossenen Agents wartet und diese integriert, bevor er antwortet.
Multi-Agent-Architekturen erfordern eine komplexere Wissensquellkonfiguration, wodurch die Zeit erhöht wird, die jeder Agent zum Auflösen einer Abfrage benötigt.
Sie müssen alle Fragen beantworten, bevor Sie Ihre Arbeit überprüfen können.
War diese Seite hilfreich?
Benötigen Sie Hilfe zu diesem Thema?
Möchten Sie versuchen, Ask Learn zu verwenden, um Sie durch dieses Thema zu klären oder zu leiten?