Foundry Copilot Harness und Browser Automation: Die Portal-Demo

Jannik Reinhard · 3. November 2026

Einen Foundry-Agenten mit Copilot Harness erstellen, Playwright verbinden und Browser-Aufrufe in den Traces prüfen. Die Schritte aus meiner Video-Demo.

Mein Agent sollte die letzten Beiträge meines Blogs lesen. Schon bei dieser kleinen Aufgabe musste ich den Umfang nach zwei Timeouts reduzieren. In der erfolgreichen Antwort standen anschließend drei Artikel. In den Traces konnte ich nachvollziehen, dass der Agent Browser Automation und zusätzlich Web Fetch verwendet hatte.

Genau diesen Ablauf zeige ich in der neuen Foundry-Folge: einen Prompt-Agenten mit Microsoft Copilot Harness erstellen, Browser Automation anbinden und danach prüfen, wie die Antwort entstanden ist. Die Aufnahme stammt aus meinem Modern-Device-Management-Projekt vom 2. November 2026.

Das Video

Foundry-Agenten im Browser: Copilot Harness & Browser Automation

Die zwei Bausteine auseinanderhalten

Der Copilot Harness ist eine optionale, von Foundry betriebene Laufzeit für Prompt-Agenten. Der Agent bleibt ein Prompt-Agent; die Laufzeit koordiniert Modell und unterstützte Fähigkeiten. Du betreibst dafür keinen eigenen Harness-Prozess. In der aktuellen Public Preview wählst du ihn bei der Erstellung eines neuen Agenten. Ein bestehender Agent lässt sich in dieser ersten Preview nicht nachträglich umstellen. Harness im Foundry-Portal

Browser Automation bindet dagegen einen verwalteten Browser als Tool an. Dafür kommt ein Azure-Playwright-Workspace hinzu. Dieser Browser läuft außerhalb meines lokalen Rechners. Der Agent kann damit beispielsweise eine Webseite öffnen und ihren Inhalt untersuchen. Browser Automation in Foundry

Die eingebauten Web-Fähigkeiten des Harness und ein Browser-Aufruf können also im selben Ablauf vorkommen. Eine Antwort mit Links allein sagt mir noch nicht, welcher Weg tatsächlich verwendet wurde.

Einen neuen Agenten mit Harness erstellen

Ich öffne im neuen Foundry-Portal Build > Agents, erstelle einen neuen Agenten und gebe ihm den Namen Youtube-Demo-Agent. Der Interaction Mode bleibt auf Text. Darunter aktiviere ich Use the Microsoft Copilot harness und öffne den Playground.

Foundry-Dialog zur Erstellung von Youtube-Demo-Agent mit Text als Interaction Mode und ausgewähltem Microsoft Copilot Harness. — Bild aus der Aufnahme: Der Harness wird bei der Erstellung ausgewählt.

Der Playground enthält danach bereits die Harness Tools. In Edit sehe ich File system read, File system write, Web, Shell und Subagents. Die Aufnahme zeigt diese Auswahl aktiviert. Für einen betrieblichen Agenten würde ich die Liste einzeln durchgehen und auf die Aufgabe begrenzen.

Ein Agent, der öffentliche Artikel zusammenfasst, braucht zunächst keine Shell für beliebige Befehle. Lese- und Schreibzugriff auf Dateien sind ebenfalls eigene Entscheidungen. Die Modellwahl und die Rechte auf angebundene Ressourcen bleiben zusätzlich zu prüfen.

Harness-Tools-Dialog mit Dateilesen, Dateischreiben, Web, Shell und Subagents. — Die in der Demo sichtbare Tool-Auswahl. Prüfe vor einem eigenen Einsatz, welche Fähigkeiten deine Aufgabe benötigt.

Als Instruction verwende ich in der Aufnahme einen sehr kurzen Satz für einen Daily Support Agent. Damit lässt sich die Oberfläche zeigen. Für wiederholbare Tests würde ich Aufgabe und Ergebnisformat genauer festlegen, etwa so:

Öffne https://jannikreinhard.com und ermittle die letzten drei
veröffentlichten Artikel. Gib jeweils Titel, Datum und direkten Link an.
Lies ausschließlich öffentliche Seiten. Melde keine E-Mail-Adresse an
und ändere keine Inhalte. Kennzeichne Informationen, die du nicht
zuverlässig ermitteln kannst.

Das ist ein engerer Testvorschlag, nicht der Wortlaut meines ersten Demo-Prompts.

Einen Playwright-Workspace verbinden

Über Add ergänze ich Browser Automation. Im Verbindungsdialog brauche ich einen Playwright-Workspace. Ich öffne deshalb die Ressourcenerstellung, wähle Subscription und Resource Group, vergebe einen eindeutigen Namen und prüfe die Region.

Azure-Formular zur Erstellung eines Playwright-Workspaces mit Region und Reporting-Einstellungen. — Die Ressourcenauswahl aus der Aufnahme. Workspace und Foundry-Ausführungsweg müssen regional zusammenpassen.

Reporting lasse ich in der gezeigten Demo deaktiviert. Bei der Netzwerkauswahl verwende ich öffentlichen Zugriff. Daraus würde ich keine allgemeine Empfehlung für interne Anwendungen ableiten: Für deren Erreichbarkeit und Zugriffsgrenzen braucht es eine eigene Planung.

Zurück in Foundry aktualisiere ich die Workspace-Auswahl. Der erstellte Workspace erscheint im Dialog. Die Oberfläche zeigt als Auth Type Agent Identity und eine Option für Browser Session Recordings. Ich lasse die Aufzeichnung aus und wähle Connect.

Foundry-Dialog Add Browser Automation tool mit ausgewähltem Playwright-Workspace, Agent Identity und ausgeschalteter Session-Aufzeichnung. — Die Verbindung im Video. Die Auswahl der Verbindungsidentität ersetzt keine Prüfung ihrer effektiven Rechte.

Ob die Verbindung auf den Workspace zugreifen darf, muss zur gewählten Identität passen. Die aktuelle Anleitung unterscheidet Projektidentität, Agent-Identität und schlüsselbasierte Verbindungen. Übernimm dafür nicht pauschal eine breite Subscription-Rolle. Prüfe Identität, unterstützten Verbindungstyp und benötigten Scope gemeinsam. Authentifizierung und Workspace-Zugriff

Speichern, ausführen und das Ergebnis eingrenzen

Nach der Tool-Änderung speichere ich den Agenten. Der erste Auftrag war breiter: alle Beiträge auflisten und zusätzlich eine Newsletter-Anmeldung ausführen. Nach zwei Timeouts ändere ich die Aufgabe auf die letzten drei Beiträge.

Das gezeigte Ergebnis ist diese Artikelliste. Eine erfolgreiche Newsletter-Anmeldung ist in der Aufnahme nicht belegt. Für einen ersten Test würde ich Recherche und eine solche schreibende Aktion ohnehin trennen. So lässt sich erkennen, ob das Lesen funktioniert, bevor der Agent einen weiteren Vorgang auslösen soll.

Foundry liefert außerdem einen Live-View-Link zur Browser-Sitzung. Für die veröffentlichte Aufnahme ist dieser Sitzungslink ausgeblendet. Solche Links gehören nicht in öffentliche Screenshots oder kopierte Chatprotokolle.

Die Traces lesen, bevor du die Demo bewertest

In den Traces öffne ich den Agent-Aufruf und die nachgelagerten Tool-Aufrufe. Zu sehen sind Browser-Operationen sowie ein zusätzlicher Web-Fetch-Schritt. Die Artikelliste entstand damit in einem Ablauf mit mehreren Fähigkeiten.

Foundry-Trace mit Agent-Aufruf, Browser-Automation-Operationen und weiteren Tool-Schritten. — Trace-Ansicht aus der Aufnahme. Sie zeigt den Ausführungsweg; die Antwort allein hätte diese Details nicht geliefert.

Für meinen nächsten Test würde ich dieselbe Aufgabe mit unverändertem Modell und einer engeren Tool-Auswahl wiederholen. Ich möchte wissen, welche Fähigkeit nötig war, wie viele Aufrufe anfielen und ob das Ergebnis wieder stimmt. Das ist eine konkretere Grundlage als ein einzelner gelungener Chat.

Ein Code-basierter Aufruf kann Orchestrierung und Fehlerbehandlung kontrollierbarer machen. Er verhindert Timeouts aber nicht automatisch. Wiederholungen, Sitzungsgrenzen und die Erreichbarkeit der Zielseite müssen auch dort berücksichtigt werden.

Prüfe zum Schluss die drei ausgegebenen Links selbst: Gehören Titel und Datum wirklich zum jeweils geöffneten Artikel? Für diesen Recherche-Agenten ist das mein Abnahmeschritt. Bei späteren Änderungen in einer Fachanwendung muss zusätzlich der dort gespeicherte Zustand geprüft werden.

Wenn du die Auswertung vertiefen möchtest, findest du in meiner Folge zu Foundry Tracing und Evaluation den nächsten Schritt. Die Grundlagen für dein Projekt stehen im Foundry-Setup-Guide. Beide verlinkten Begleitartikel sind auf Englisch; die Videos darin sind auf Deutsch.