Microsoft Foundry Realtime Voice Agent: Sprich mit deinem Bildschirm

In diesem Blogpost zeige ich, wie ich mit einem Microsoft Foundry Realtime Voice Agent über Informationen spreche, die gerade auf meinem Bildschirm zu sehen sind. Ich teile eine Azure-Seite, stelle meine Frage per Sprache und erhalte direkt eine gesprochene Antwort. Ich muss keinen Text kopieren und keinen Screenshot in einen anderen Chat hochladen.

Der praktische Mehrwert entsteht aus der Kombination beider Eingaben. Der Agent hört meine Frage und sieht die von mir ausgewählte Oberfläche. Anschließend kann ich in derselben Unterhaltung direkt nachfragen. Das vollständige Beispiel findest du in meinem Microsoft Foundry Examples Repository.

Was kann der Agent mit aktuellen Bildschirminformationen machen?

Ein normaler Voice Agent kennt nur das, was ich ihm sage. Ein Screen-Aware Voice Agent erhält zusätzlich die Informationen, die ich ihm in diesem Moment zeige.

Ich kann zum Beispiel den Microsoft Foundry Modellkatalog öffnen und fragen:

Welche der sichtbaren Modelle könnte ich für ein Voice-Szenario verwenden?

Der Agent kann seine Antwort auf die aktuelle Seite beziehen. Ich muss die Modellnamen nicht vorlesen und keinen Screenshot in ein anderes Tool kopieren. Ist die erste Antwort zu allgemein, frage ich direkt weiter:

Welches davon würdest du für eine Browser-Anwendung auswählen?

Die zweite Frage verwendet den Kontext der laufenden Unterhaltung. Dadurch fühlt es sich an, als würde ich einen Kollegen fragen, der auf denselben Bildschirm schaut.

Dieses Muster funktioniert nicht nur mit einem Modellkatalog. Ich kann eine Azure-Konfigurationsseite, ein Dashboard, einen Setup-Assistenten, eine Fehlermeldung oder schwer verständliche Dokumentation öffnen.

Wie stelle ich das Beispiel bereit und konfiguriere es?

Bevor ich die Sprachunterhaltung starten kann, benötige ich eine Microsoft Foundry Resource und ein Realtime Model Deployment. Das Model Deployment kann ich direkt im Foundry Portal erstellen.

1. Das Microsoft Foundry Projekt öffnen.
2. Build auswählen und Models öffnen.
3. Auf Deploy a base model klicken.
4. Nach einem unterstützten GPT Realtime Modell suchen, das in der Projektregion verfügbar ist.
5. Einen eindeutigen Deployment-Namen sowie den verfügbaren Deployment-Typ und die Kapazität auswählen.
6. Das Deployment starten und warten, bis der Status Succeeded angezeigt wird.

Das lokale Beispiel benötigt Python 3.11 oder neuer und die Azure CLI. Die mit az login verwendete Identität braucht auf der Foundry Resource die Rolle Cognitive Services User.

Hint: Owner oder Contributor auf der Subscription enthält nicht automatisch den Zugriff auf die Modelldaten. Kann die Voice Session nicht erstellt werden, prüfe ich zuerst die Zuweisung Cognitive Services User. Neue Rollenzuweisungen können einige Minuten benötigen, bevor sie funktionieren.

Danach klone ich das Beispiel und erstelle die lokale Konfiguration:

git clone https://github.com/JayRHa/microsoft-foundry-examples.git
cd microsoft-foundry-examples/examples/realtime-voice-screen-share
cp .env.example .env

In der .env-Datei trage ich den Namen der Foundry Resource und den Namen des Model Deployments ein:

AZURE_OPENAI_RESOURCE=YOUR-FOUNDRY-RESOURCE
AZURE_OPENAI_REALTIME_DEPLOYMENT=YOUR-REALTIME-DEPLOYMENT
REALTIME_VOICE=marin

AZURE_OPENAI_RESOURCE enthält nur den Ressourcennamen und keine URL. Der Server erstellt daraus den GA Endpoint. Auch die Azure-Zugangsdaten bleiben auf dem Server. Der Browser erhält weder das Azure-CLI-Token noch einen langlebigen API Key.

Anschließend installiere und starte ich die kleine FastAPI-Anwendung:

python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
az login
uvicorn app:app --host 127.0.0.1 --port 8000

Die Seite ist danach unter http://127.0.0.1:8000 erreichbar. Möchte ich sie außerhalb von localhost hosten, muss ich HTTPS verwenden. Browser benötigen für Mikrofon- und Bildschirmzugriff einen sicheren Kontext.

Microsoft beschreibt die aktuellen Voraussetzungen und den unterstützten Deployment-Ablauf im offiziellen Realtime WebRTC Guide.

Wie nutze ich den Voice Agent?

Der Ablauf ist bewusst kurz. Ich muss keine Datei hochladen und keinen besonderen Prompt vorbereiten.

1 — Die Sprachunterhaltung starten

Ich klicke auf Start voice session und erlaube den Zugriff auf das Mikrofon. Der Call-Dialog zeigt mir, sobald die Verbindung bereit ist. Danach kann ich normal sprechen und muss nicht für jede Frage einen Aufnahme-Button gedrückt halten.

Der Agent antwortet mit Sprache. Meine Frage und die Antwort erscheinen zusätzlich als Text im Transkript. Das hilft mir, wenn ich während des Gesprächs einen Produktnamen, einen Befehl oder eine Einstellung genau prüfen möchte.

2 — Den aktuellen Bildschirm nur bei Bedarf teilen

Ich öffne die Seite, zu der ich Hilfe benötige, und klicke auf Share screen. Der Browser zeigt den bekannten Auswahl-Dialog. Dort wähle ich einen einzelnen Tab, ein Fenster oder einen vollständigen Monitor aus.

Die ausgewählte Oberfläche bleibt während des Calls sichtbar. Ich weiß deshalb immer, was der Agent im Moment sehen kann. Bevor ich eine andere Seite mit sensiblen Informationen öffne, kann ich die Freigabe sofort beenden.

Im Screenshot habe ich den Microsoft Foundry Modellkatalog geteilt. Der Agent erhielt die sichtbare Seite als Bildkontext. Er bekam keine Kontrolle über meinen Browser und konnte nicht selbst auf Schaltflächen klicken.

3 — Natürlich fragen und direkt nachfragen

Jetzt kann ich dieselben Fragen stellen, die ich auch einem Kollegen stellen würde:

• Was sehe ich gerade?
• Welche Option passt zu meinem Szenario?
• Was sollte ich als Nächstes konfigurieren?
• Kannst du mir diesen Fehler einfach erklären?
• Was ist der Unterschied zwischen den beiden sichtbaren Modellen?

Ich muss nicht jedes Label auf der Seite beschreiben. Der Bildschirm liefert diesen Kontext. Meine Sprache erklärt, was ich wissen möchte.

Der Agent antwortet außerdem in der Sprache meiner letzten gesprochenen Frage. Frage ich auf Deutsch, kommt die Antwort auf Deutsch. Wechsle ich zu Englisch, folgt die nächste Antwort auf Englisch. So kann dieselbe Anwendung ohne zusätzlichen Sprachschalter von unterschiedlichen Benutzern verwendet werden.

Welche Antwort kam von der Azure-Seite zurück?

Ich habe die Anwendung mit der Microsoft Foundry Modellübersicht ausprobiert. Meine deutsche Frage war, welche sichtbaren Modelle für einen Realtime Voice Agent relevant sind.

Der Agent antwortete:

Du siehst die Microsoft Foundry Modellübersicht im Bereich „Models“ mit Filteroptionen und einer nach „Featured“ sortierten Liste verfügbarer Modelle im Projekt. Für einen Realtime-Voice-Agent sind zum Beispiel „gpt-realtime-2.1“ und „MAI-Transcribe-1.5“ relevant.

Die Antwort bezog sich auf die geteilte Seite. Der Agent erkannte die Modellübersicht, die Filter und die sichtbaren Modellnamen. Noch wichtiger war für mich, dass die Antwort als Sprache und Text zurückkam. Ich konnte sofort weiterfragen, warum eines dieser Modelle zu meinem Szenario passt.

Genau diese Erfahrung wollte ich erreichen. Ich bleibe bei meiner aktuellen Aufgabe, stelle eine kurze Frage und bekomme eine Antwort zu den Informationen vor mir.

Warum ist Sprache hier hilfreich?

Ein Text-Chat ist weiterhin die bessere Wahl, wenn ich einen langen Befehl benötige oder viel Text vergleichen möchte. Sprache ist besonders hilfreich, wenn ich bereits in einer anderen Anwendung arbeite.

Situation	Wie Sprache und Bildschirmkontext helfen
Azure-Konfiguration	Ich frage nach den sichtbaren Optionen, ohne die Seite zu verlassen
Fehlermeldung	Ich lasse mir den Fehler erklären, während er geöffnet bleibt
Dashboard	Ich spreche über den aktuellen Status, ohne jeden Wert beschreiben zu müssen
Geführtes Setup	Ich frage während des Assistenten nach dem nächsten Schritt
Training	Ein Benutzer fragt genau zu der Oberfläche, die gerade gezeigt wird

Der Agent wird zu einer zusätzlichen Ebene über der geöffneten Anwendung. Er ersetzt die Anwendung nicht. Er hilft mir zu verstehen, was ich sehe, und den nächsten Schritt auszuwählen.

Was bedeutet „live“ in diesem Beispiel?

Die Unterhaltung ist live, weil Audio mit geringer Verzögerung in beide Richtungen übertragen wird. Während ich weiter spreche, kann der Agent außerdem aktualisierte Bilder der geteilten Oberfläche erhalten. Microsoft dokumentiert WebRTC als Browser-Verbindung für Realtime Audio und unterstützt Bild-Eingaben innerhalb derselben Unterhaltung.

Die zugrunde liegenden Funktionen findest du im offiziellen WebRTC Guide und in der Realtime Audio Dokumentation.

Der Agent kennt dadurch aber nicht automatisch jede Änderung in Azure. Er kennt nur die von mir geteilten Bildschirminformationen und unsere Unterhaltung. Benötige ich aktuelle Tenant-Daten, die nicht auf der Seite sichtbar sind, muss ich dafür ein separates Tool oder eine API anbinden.

Diese Unterscheidung ist wichtig:

• Sichtbare aktuelle Informationen: Die geteilte Seite, ein Status, Diagramm, Fehler oder sichtbare Optionen.
• Gesprächskontext: Meine gesprochenen Fragen und die vorherigen Antworten im Call.
• Verbundene Unternehmensdaten: Nur verfügbar, wenn ich bewusst eine API, einen MCP Server oder ein anderes Tool ergänze.

Der Bildschirm liefert Kontext. Er ist kein unbegrenzter Zugriff auf die Umgebung.

Wie funktioniert der vollständige Ablauf?

Die Anwendung besteht aus einem Browser-Teil, einem kleinen FastAPI Service und dem Realtime-Modell in Microsoft Foundry. Jeder Teil hat eine klare Aufgabe.

1. Beim Start der Voice Session ruft der Browser den lokalen Token Endpoint auf.
2. Der FastAPI Service authentifiziert sich mit Microsoft Entra ID an Azure.
3. Der Service erzeugt ein kurzlebiges Realtime Client Secret für das ausgewählte Deployment.
4. Der Browser öffnet mit diesem Secret eine direkte WebRTC-Verbindung zum Realtime Service.
5. Mein Mikrofon-Audio und die gesprochene Antwort laufen über diese Live-Verbindung.
6. Transkripte, Status-Ereignisse und ausgewählte Bildschirmbilder laufen über den WebRTC Data Channel.

Im Diagramm ist der vollständige Weg zu sehen. FastAPI wird nur benötigt, um die kurzlebige Sitzung zu erzeugen. Danach laufen Audio und Bildschirmkontext direkt zwischen dem Browser und Microsoft Foundry.

Der Browser verwaltet die Berechtigungen für Mikrofon und Bildschirm. Im normalen Browser-Dialog entscheide ich selbst, welche Oberfläche ich freigebe. Diese Auswahl bleibt im Call sichtbar.

Die Anwendung sendet kein permanentes Bildschirmvideo an das Modell. Sie erzeugt ausgewählte Standbilder aus der freigegebenen Oberfläche und ergänzt diese als input_image in derselben Unterhaltung. Das Modell erhält damit meine gesprochene Frage zusammen mit dem aktuellen visuellen Kontext. Die Antwort kommt als Audio und Transkript zurück.

Die Session Instructions sagen dem Agent, dass er nur den ausdrücklich freigegebenen Bildschirm verwenden und in der Sprache meiner letzten gesprochenen Frage antworten soll. Deshalb kann ich auf Deutsch fragen, eine deutsche Antwort erhalten und danach im selben Call auf Englisch weitersprechen.

Die Azure-Zugangsdaten bleiben im FastAPI Service. Der Browser sieht nur das kurzlebige Realtime Client Secret. Für mich gilt hier derselbe Grundsatz wie bei anderen Browser-Anwendungen: Dauerhafte Azure-Zugangsdaten gehören nicht in die Seite.

Wenn Microsoft Foundry für dich neu ist, erklärt mein Guide zum ersten Microsoft Foundry Agent die grundlegende Projekteinrichtung. In meinem Beitrag zu sicheren Microsoft Foundry Deployments gehe ich genauer auf Identity- und Datengrenzen ein.

Was habe ich bewusst nicht in das Beispiel eingebaut?

Ich wollte ein kleines Beispiel, das leicht zu verstehen und zu prüfen ist. Deshalb habe ich mehrere Produktionsfunktionen bewusst nicht in das Lab eingebaut.

Das Beispiel enthält:

• Keine Browser-Automatisierung und keine Steuerung der geteilten Seite
• Keine dauerhaften Azure-Zugangsdaten im Browser
• Keine versteckte Bildschirmaufnahme ohne den Browser Picker
• Keine Speicherung von Bildschirmbildern oder Transkripten
• Keine Schreibberechtigungen für Microsoft Graph oder Microsoft Intune
• Keine Benutzerdatenbank oder öffentliche Anmeldung

Dadurch bleibt der Ablauf klar. Die Seite öffnet eine Realtime Session, sendet den ausdrücklich ausgewählten visuellen Kontext und liefert Sprache plus Transkript zurück. Im Hintergrund passiert nichts Weiteres.

Note: Wenn ich das Beispiel für andere Benutzer hoste, würde ich Authentifizierung, Rate Limiting, Audit Events und eine klare Retention-Konfiguration um den Token Endpoint ergänzen. Das sind Hosting-Aufgaben und keine Voraussetzung für das lokale Lab.

Wie kann ich den vollständigen Ablauf selbst testen?

Das vollständige Beispiel findest du hier:

github.com/JayRHa/microsoft-foundry-examples/tree/main/examples/realtime-voice-screen-share

Nachdem der lokale Server läuft, teste ich den echten Benutzerablauf im Browser. Dafür benötige ich keinen automatisierten Testmodus.

Das Visual zeigt die fünf praktischen Schritte. Ich stelle das Modell bereit, konfiguriere den lokalen Service, starte die Seite, spreche und teile eine Oberfläche. Danach prüfe ich, ob die Antwort den sichtbaren Inhalt verwendet.

1. http://127.0.0.1:8000 öffnen.
2. Start voice session auswählen und den Mikrofonzugriff erlauben.
3. Warten, bis der Call-Status die erfolgreiche Verbindung anzeigt.
4. Eine kurze Frage stellen. Die Antwort sollte hörbar sein und beide Seiten sollten im Transkript erscheinen.
5. Share screen auswählen und einen nicht sensiblen Azure- oder Browser-Tab freigeben.
6. Fragen: „Was kannst du auf meinem Bildschirm sehen?“ Die Antwort sollte tatsächlich sichtbare Informationen nennen.
7. Eine Anschlussfrage stellen, ohne den Seitenkontext erneut zu erklären.
8. Die nächste Frage auf Deutsch stellen. Die gesprochene Antwort und das Transkript sollten auf Deutsch wechseln.
9. Die Bildschirmfreigabe im Call-Dialog beenden. Die Vorschau sollte stoppen und es sollte kein neuer Bildschirmkontext gesendet werden.

Ich verwende dafür diese kurze Ergebnis-Checkliste:

Prüfung	Erwartetes Ergebnis
Voice-Verbindung	Ich kann sprechen und den Agent hören, ohne einen Aufnahme-Button zu drücken
Transkript	Meine Frage und die Antwort des Agent erscheinen als Text
Bildschirmbezug	Die Antwort nennt sichtbare Labels, Werte oder Modellnamen
Anschlussfrage	Der Agent behält den Kontext der laufenden Unterhaltung
Sprache	Eine deutsche Frage erhält eine deutsche gesprochene Antwort
Freigabe beenden	Die sichtbare Vorschau endet und der Bildschirm wird nicht mehr aktualisiert

Für meinen ersten Versuch würde ich eine Seite mit klaren, aber nicht sensiblen Informationen verwenden. Ein Microsoft Foundry Katalog, ein öffentliches Dashboard oder eine öffentliche Dokumentation eignet sich gut. So lässt sich leicht erkennen, ob die Antwort wirklich auf den sichtbaren Inhalt eingeht.

Das wichtige Ergebnis ist nicht noch ein Voice Chatbot. Es ist eine Unterhaltung über die Arbeit, die bereits auf meinem Bildschirm geöffnet ist. Sprache macht die Interaktion schnell. Die geteilte Seite liefert dem Agent den fehlenden Kontext. Zusammen machen beide Eingaben die Antwort deutlich hilfreicher.

Ich hoffe, das hilft dir ein wenig bei deinem eigenen Microsoft Foundry Projekt.

Stay healthy, Cheers Jannik