Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Ein Autopilot ist eine Art von Agent, der unter seiner eigenen Identität als dauerhaftes, benanntes Mitglied Ihrer Organisation agiert. Sie hat eine dauerhafte Funktion, anstatt jeweils nur eine Anfrage nach der anderen zu beantworten. Es verfügt über ein eigenes Sicherheitsprofil in Ihrem Mandanten sowie über einen Manager, der dafür verantwortlich ist.
Jeder Foundry-Agent verfügt über eine Microsoft Entra Agentidentität ab dem Moment, an dem Sie ihn erstellen. Was einen Autopilot anders macht, ist, dass er auch über ein Entra-Agent-Benutzerkonto verfügt. Dieses Konto gibt dem Autopilot seine eigene E-Mail, Kalender, OneDrive, Teams-Anwesenheit und einen Ort im Organigramm, und es ermöglicht dem Autopilot, Microsoft 365 Aktionen als sich selbst auszuführen.
Warum Autopiloten vorhanden sind
Ohne ein Agent-Benutzerkonto kann ein Agent Microsoft 365 Aktionen ausführen, z. B. das Senden einer E-Mail oder das Bearbeiten eines Dokuments, nur im Auftrag eines angemeldeten Benutzers. Das funktioniert gut für einen Eins-zu-eins-Assistenten, aber in zwei häufigen Situationen stößt dieser Ansatz an seine Grenzen.
- Kein Benutzer eingebunden. Ein Agent, der durch ein Ereignis ausgelöst wird, hat keinen angemeldeten Benutzer, in dessen Namen er handeln kann, sodass er überhaupt keine Microsoft 365-Aktionen ausführen kann.
- Gruppeneinstellungen. In einem Gruppenchat muss der Agent erraten, in dessen Auftrag gehandelt werden soll, und es gibt keine richtige Antwort. Wen auch immer es auswählt, die Berechtigungen dieser Person gelten für den gesamten Thread. Aktionen werden jemandem zugeschrieben, der nicht darum gebeten hat, und Mitglieder können Inhalte zu sehen bekommen, auf die sie nicht zugreifen können.
Ein Agentbenutzerkonto behebt beide Probleme. Der Autopilot führt Microsoft 365 Aktionen als sich selbst aus, sodass er gleichzeitig mit einem ganzen Team arbeiten und auf einen Trigger reagieren kann, wenn kein Benutzer vorhanden ist.
Was einen Autopiloten nicht ausmacht
Autopiloten werden häufig durch eine Reihe von Funktionen beschrieben: Arbeitsspeicher, Proaktivität, Gründe, Planung und Lernen. Diese Funktionen beschreiben, was ein Autopilot tun kann. Sie legen nicht fest, wer agiert, und sie ändern sich mit jeder Version. Wenn Funktionen die Kategorie definiert haben, würde ein Agent, der Speicher in einer späteren Version hinzufügt, zu einem Autopilot werden, ohne zu ändern, wer es ist, was es tun kann oder wer dafür antwortt. Dies ist eine Featureliste, keine Definition.
Die Autonomie definiert auch keinen Autopilot, und die beiden sind unabhängig. Ein Hintergrunddienst-Agent kann den ganzen Tag eigenständig laufen und arbeitet jedoch nicht im Autopilotmodus. Ein Autopilot muss nicht vollständig autonom sein: Ihre Organisation steuert, wann sie antwortet, mit wem sie interagieren kann, worauf sie zugreifen kann und welche Aktionen sie ausführen können.
Fähigkeiten beschreiben einen Autopiloten. Die Identität begründet es.
Was Autopiloten ermöglichen
Sie führen Arbeiten im Unternehmen nur selten alleine durch. Die meisten Unternehmensarbeit ist zusammenarbeitend und kontinuierlich, verteilt auf Teams, Besprechungen, Dokumente und Gruppenchats. Autopiloten werden für diese Art von Arbeit gebaut. Sie arbeiten mit einem ganzen Team und nicht mit einem Benutzer gleichzeitig zusammen, und sie können handeln, ohne dazu aufgefordert zu werden.
Ein Autopilot übernimmt eine Rolle und die damit verbundenen Aufgaben, und sein Kontext erstreckt sich über alle Interaktionen hinweg – unabhängig von Plattform oder Benutzer. Weisen Sie in Outlook eine Aufgabe zu, und fragen Sie in Teams nach dem Ergebnis. Da seine Rolle dauerhaft festgelegt ist und es über eigene Berechtigungen verfügt, kann es proaktiv arbeiten, wenn Sie das möchten, und bleibt dabei innerhalb eines von Ihnen festgelegten Rahmens.
Verantwortlichkeit kommt mit der Autonomie. Jeder Autopilot hat einen Verantwortlichen, der für ihn geradesteht, und unterliegt den Sicherheits-, Datenschutz- und Governance-Kontrollen, die Sie bereits einsetzen.
Wie Autopiloten mit anderen Foundry Agents vergleichen
Autopiloten und andere Foundry Agents unterscheiden sich in der Identität, die sie halten, wie Sie sie aufbauen und wie sie die Personen erreichen, die sie verwenden.
Das Identitätsmodell
Ein regulärer Foundry-Agent hat eine 1:1-Struktur: ein Agent, ein Blueprint, eine Agentenidentität und kein Agenten-Benutzerkonto. Die Blaupause besteht aus einer Agent-Blaupause-Anwendung und einem Agent-Blaupause-Dienstprinzipal, der den Sicherheitskontext und die Anmeldeinformationen bereitstellt.
Ein Autopilot hat eine Eins-zu-viele-Struktur: eine Vorlage und viele bereitgestellte Instanzen, wobei jede Instanz eine eigene Agent-Identität und ein eigenes Agentenbenutzerkonto erhält.
Die beiden Identitätsobjekte führen unterschiedliche Aufgaben aus und sind niemals austauschbar.
| Object | Was es ist | Inhalt |
|---|---|---|
| Agentidentität | Ein Service Principal | Die Agent-ID, der Agentname, der Sponsor und die Berechtigungen, mit denen der Agent authentifiziert wird. Bei einem Autopilot sichert diese Identität die Infrastruktur, die den Agent ausführt. |
| Agent-Benutzerkonto | Ein Benutzerobjekt | Der Anzeigename, der Manager- und der Benutzerprinzipalname, die den Autopilot in Microsoft 365 repräsentieren. |
Der Unterschied zwischen einem Agent und einem Autopilot ist binär. Ein Agent verfügt entweder über ein eigenes Agent-Benutzerkonto oder nicht, was die Identität zu einer zuverlässigen Definition macht.
Das Erstellen eines der beiden Agenttypen beginnt auf die gleiche Weise: Foundry erstellt einen Agent-Identitäts-Blueprint und eine Agent-Identität. Für einen regulären Agent stellt die Agent-Identität den Agent zur Laufzeit dar. Bei einem Autopilot dient die Agentidentität als Infrastrukturidentität, während das Agentbenutzerkonto den Autopilot darstellt, wenn er Microsoft 365 Aktionen ausführt.
Typen von Agents, die Sie in Foundry erstellen können
Foundry unterstützt drei Agenttypen, und nur eine davon ist ein Autopilot.
| Typ | Identity | Was dies tun kann | Am besten geeignet für: |
|---|---|---|---|
| Unterstützend | Identität des Agenten mit Kontext des angemeldeten Benutzers | Handelt im Namen eines Benutzers. Er kann Nur innerhalb der Berechtigungen dieses Benutzers Aktionen ausführen. | Persönliche Produktivität, z. B. ein Agent zur Besprechungsvorbereitung, der auf Anforderung eine Präsentation entwirft. |
| Hintergrunddienst | Agentidentität | Agiert als eigenständige App über App-Berechtigungen, ohne einen angemeldeten Benutzer oder ein Agent-Benutzerkonto. Sie kann autonom handeln, kann aber keine Microsoft 365 Aktionen ausführen. | App-Automatisierungs- und Back-End-Workflows, z. B. ein Operations-Agent, der einen virtuellen Computer als Reaktion auf eine Warnung neu startet. |
| Autopilot | Agentidentität und Agent-Benutzerkonto | Agiert in Microsoft 365 als sich selbst, auch in Gruppeneinstellungen. Sie kann autonom innerhalb des von Ihnen definierten Bereichs handeln. | Digitale Kollegen, z. B. ein Release-Manager, der die Arbeit in einem Teams-Gruppenchat koordiniert. |
Warum Sie einen Blueprint erstellen, nicht ein Autopilot
Sie erstellen keinen Autopilot. Sie erstellen einen Blueprint, mit dem Teams ihre eigenen Autopilot-Instanzen erstellen, die jeweils eine eigene Identität und einen eigenen teambezogenen Zugriff haben.
Durch die Erstellung des Agents wird dieser direkt an ein Team gebunden, denn die Nutzung und die Sperrung erfolgt über denselben Zugang. Wenn Sie der Sicherheitsgruppe Ihres Teams ein Agentbenutzerkonto hinzufügen und ihm Zugriff auf Ihr Projekt und Ihre SharePoint-Website gewähren, ist genau das der Zweck des Agents. Das ist auch der Grund, warum niemand sonst es wiederverwenden kann: Sie würden Zugriffsrechte übernehmen, die sie nicht haben sollten, also entwickeln sie ihre eigene Lösung. Zehn Teams später verfügt die Organisation über zehn nahezu identische Agents, die jeweils separat geregelt werden. Ihre Steuerelemente weichen voneinander ab, und bei einem kompromittierten Tool muss jeder Agent einzeln überprüft werden.
Ein Blueprint löst dieses Problem. Es definiert zwei Dinge: was der Agent weiß, wie er vorgehen kann, z. B. welche APIs er aufrufen kann, und die Plattforminfrastruktur, die der Agent benötigt, z. B. Speicher für nachverfolgte Elemente und Arbeitsspeicher. Was es niemals gewährt, ist der Zugriff auf die Geschäftsressourcen eines bestimmten Teams. Ein Agent wird mit der Fähigkeit ausgeliefert, Azure-DevOps-Arbeitselemente zu aktualisieren und SharePoint zu lesen, während jeder Manager entscheidet, auf welches Azure-DevOps-Projekt und welche SharePoint-Website die jeweilige Instanz zugreifen kann. Jede instanz, die aus dem Blueprint erstellt wurde, verfügt über eigene Identitäten, Berechtigungen und Zuweisungen.
Diese Trennung bleibt auch zur Laufzeit bestehen. Das Halten eines Tools ist nicht identisch mit dem Halten des Zugriffs auf die daten dahinter. Wenn sie einem Autopilot ein SharePoint Tool geben, erhält er keine SharePoint Website, und ein Postfach gibt ihm nicht die Möglichkeit, E-Mails zu senden.
Eine Richtlinie ist eine separate Ebene der Governance. Konfigurieren Sie die Richtlinie einmal, und jede Instanz erbt sie. Aktualisieren Sie den Blueprint, und alle Instanzen werden aktualisiert. Blockieren Sie den Blueprint, und jede Instanz wird beendet.
Nur in Foundry gehostete Agents können als Autopilot-Blueprints veröffentlicht werden.
Typen von Autopiloten, die Sie erstellen können
Autopiloten lassen sich in drei Muster einteilen, die sich darin unterscheiden, wem sie dienen.
- Group Autopilot – arbeitet für ein Team. Es ist dort verfügbar, wo das Team arbeitet, enthält den gemeinsamen Kontext des gesamten Teams und koordiniert die Zusammenarbeit zwischen Personen, anstatt jeweils nur einer Person zur Verfügung zu stehen.
- Unternehmensweiter Autopilot – bietet eine zentral verwaltete Funktion, die für jeden in der Organisation verfügbar ist, in der Regel als eine Produktionsinstanz pro Geschäftsprozess.
- Persönlicher Autopilot – funktioniert für eine Person, als isolierte Instanz, die von dieser Person erstellt und verwendet wird.
Verwandte Inhalte
- Der Autopilot-Lebenszyklus in Microsoft Foundry deckt die Phasen ab, von der Erstellung eines Blueprints bis zum Beenden einer Instanz.
- Konzepte zur Agentenidentität in Microsoft Foundry behandelt, wie Microsoft Foundry Agentenidentitäten zur Laufzeit bereitstellt und verwendet.
- Microsoft Agent 365-Integration in Foundry umfasst die Registrierungssynchronisierung und welche Agenttypen die Autopilot-Veröffentlichung unterstützen.