Was ist „Computer Use“?
Computer Use gibt Devin direkten Zugriff auf eine grafische Desktop-Umgebung mit Maus und Tastatur. Das geht über Browserautomatisierung hinaus — Devin kann mit jeder Anwendung interagieren, die auf dem Bildschirm dargestellt wird, darunter:- Webanwendungen in Chrome (Klicken von Schaltflächen, Ausfüllen von Formularen, Navigieren durch Seiten)
- Desktop-Anwendungen, die auf der Plattform der Sitzung (Linux, Windows oder macOS) laufen, darunter Electron-Apps, IDEs und plattformnative GUIs
- Terminalbasierte UIs (TUI-Programme, interaktive CLIs)
- Jede visuelle Benutzeroberfläche, die auf dem Desktop angezeigt werden kann
Unterstützte Plattformen
Die Nutzung von Computer Use ist auf allen Plattformen identisch: Devin verwendet Maus und Tastatur, erstellt Screenshots, nutzt Chrome für Web-Apps und kann Testsitzungen aufzeichnen. Unter Windows kann Devin zusätzlich Windows-native Desktopanwendungen testen (z. B. WPF, WinForms und andere Apps, die nur unter Windows ausgeführt werden); unter macOS kann Devin Mac-Apps und iOS-Apps im Simulator testen. Um Sitzungen auf einer anderen Plattform auszuführen, konfigurieren Sie ein Blueprint wie im Abschnitt Windows-Support oder macOS-Support beschrieben. Ein durchgängiges Beispiel finden Sie unter Eine iOS-App mit Devin entwickeln.
Unter macOS verwendet Devin die Command-Taste für Tastenkombinationen (⌘C, ⌘V) anstelle von Control.
So aktivieren Sie es
Computer Use wird über den Schalter Computer use in den Devin-Einstellungen Ihrer Organisation gesteuert.- Gehen Sie zu Settings > Devin
- Aktivieren Sie im Abschnitt Sessions den Schalter Computer use
- Devin verwendet nun während Sitzungen seine Desktop-Umgebung
Der Desktop-Modus ist in allen Tarifen verfügbar. Nur Organisationsadministratoren können diese Einstellung ändern.
Wann Computer Use ausgeführt wird
Sobald der Desktop-Modus aktiviert ist, steht Computer Use in jeder Sitzung zur Verfügung. Es gibt drei Situationen, in denen es ausgeführt wird:Nach dem Erstellen eines Pull Requests (PR)
Wenn Devin einen Pull Request (PR) erstellt, wird die Schaltfläche Test the app angezeigt. Ein Klick darauf löst den vollständigen Test-Workflow aus — Devin startet deine App, verwendet Computer Use, um mit dem Desktop zu interagieren, testet die Änderungen und sendet dir eine Aufzeichnung.
Auf Anfrage während einer Sitzung
Du kannst Devin jederzeit während einer Sitzung zum Testen auffordern – keine spezielle Syntax erforderlich, nur natürliche Sprache. Zum Beispiel:- „Teste die Änderungen, die du gerade vorgenommen hast, und schick mir eine Aufnahme.“
- „Öffne die App im Browser und überprüfe, ob die Anmeldeseite funktioniert.“
- „Starte die Desktop-App und prüfe, ob der neue Menüpunkt erscheint.“
Wenn es sinnvoll ist, autonom
Devin entscheidet selbst, wann die Interaktion mit dem Desktop das richtige Mittel für eine Aufgabe ist. Wenn eine Aufgabe das Klicken auf UI-Elemente, das Navigieren in einer App, das Ausfüllen von Formularen oder das visuelle Überprüfen von Inhalten umfasst, verwendet Devin Computer Use, ohne dass Sie es ausdrücklich dazu auffordern müssen. Sie müssen Devin nicht sagen, wie es mit dem Bildschirm interagieren soll — sagen Sie ihm einfach, was es erreichen soll.Was Devin bei der Computernutzung leisten kann
Webanwendungen end-to-end testen
Devin kann Ihre App lokal starten, sie in Chrome öffnen und vollständige User-Flows durchklicken – Login, Navigation, Formularabsendung, Checkout – und so überprüfen, ob alles wie erwartet funktioniert.Desktop-Anwendungen testen
Jede Anwendung, die auf Devins Sitzungsplattform ausgeführt wird, kann getestet werden. In Linux-Sitzungen umfasst dies Electron-Apps, Java-Swing-/AWT-Anwendungen, GTK-/Qt-Apps und mehr. In Windows-Sitzungen kann Devin auch nativ für Windows entwickelte Anwendungen wie WPF- und WinForms-Apps testen. Devin startet die App, interagiert mit ihrer GUI und überprüft ihr Verhalten.Visuelle Überprüfung
Devin kann während des Testens an bestimmten Punkten Screenshots aufnehmen, um zu überprüfen, ob Layouts, Styling und UI-Elemente korrekt dargestellt werden. Es kann den Bildschirminhalt mit dem erwarteten Verhalten vergleichen und visuelle Probleme markieren.Mit komplexen UI-Abläufen interagieren
Einige Testszenarien erfordern mehrstufige GUI-Interaktionen, die über einfache API-Aufrufe oder Browserautomatisierung hinausgehen – etwa Drag-and-Drop, Kontextmenüs, Tastenkombinationen oder das Navigieren zwischen mehreren Fenstern. Computer Use beherrscht all dies.Testsitzungen aufzeichnen
Devin kann seinen Bildschirm während der Tests aufzeichnen und wichtige Momente im Video kommentieren. Die Aufzeichnung wird anschließend verarbeitet und an Sie gesendet, damit Sie sehen können, wie Devin mit Ihrer App interagiert und bestätigen können, dass die Änderungen wie erwartet funktionieren. Ausführliche Informationen zum Aufzeichnungsworkflow finden Sie unter Testing & Video Recordings.Wie Computer Use funktioniert
Wenn Devin während einer Sitzung Computer Use verwendet, folgt Devin dabei diesem Ablauf:- Erstellt einen Screenshot des aktuellen Bildschirms, um zu erfassen, was angezeigt wird
- Identifiziert interaktive Elemente – Buttons, Textfelder, Menüs, Links – und entscheidet, mit welchen Elementen interagiert werden soll
- Führt eine Aktion aus – klickt, tippt, scrollt oder verwendet Tastenkombinationen
- Wartet und beobachtet – erstellt einen weiteren Screenshot, um das Ergebnis der Aktion zu sehen
- Wiederholt den Vorgang, bis die Aufgabe abgeschlossen ist
Computer Use und Tests
Computer Use ist die Grundlage von Devins Workflow für Tests und Aufzeichnungen. Wenn Devin Ihre Anwendung nach dem Erstellen eines Pull-Requests (PR) testet:- Einrichtung — Devin installiert Abhängigkeiten, startet Ihre App und bereitet die Umgebung vor
- Testplanung — Devin liest das Diff und erstellt einen zielgerichteten Testplan
- Ausführung über Computer Use — Devin verwendet seinen Desktop, um mit Ihrer App zu interagieren und folgt dem Testplan Schritt für Schritt
- Aufzeichnung — Der gesamte Prozess wird als Video mit Annotationen aufgezeichnet und Ihnen anschließend zur Überprüfung gesendet
Computer Use auf Outposts
Auf Outposts laufen Sitzungen auf Maschinen, die Sie verwalten. Daher verwendet Devin die auf der Maschine bereits vorhandene Desktop-Umgebung, statt eine eigene bereitzustellen. Das Toolcomputer ist in jeder Sitzung im Desktop-Modus verfügbar. Wenn die Maschine eine Aktion nicht unterstützt, schlägt diese mit einer klaren, umsetzbaren Fehlermeldung fehl, anstatt dass das Tool stillschweigend nicht verfügbar ist.
Anforderungen nach Plattform
Linux: Der Worker muss Zugriff auf eine grafische Sitzung haben —DISPLAY muss in der Umgebung des Workers gesetzt sein und auf einen laufenden X-Server verweisen. Auf einer Maschine ohne grafische Oberfläche können Sie selbst einen starten (z. B. Xvfb :0 mit einem Fenstermanager) und DISPLAY exportieren, bevor Sie den Worker starten. Ohne Anzeige geben Computeraktionen einen Fehler zurück, der erklärt, dass kein grafischer Desktop verfügbar ist und wie Sie einen bereitstellen können.
macOS: Devin verwendet die vorhandene Desktop-Sitzung der Maschine. Für den Prozess, der den Devin-Worker ausführt, sind zwei separate macOS-Berechtigungen (TCC) erforderlich:
- Bildschirmaufzeichnung — erforderlich für Screenshots.
- Bedienungshilfen — erforderlich für synthetische Maus- und Tastatureingaben.
Teilweise Funktionalität ist vorgesehen
Die einzelnen Funktionen werden unabhängig geprüft. Daher bleibt Devin auch bei eingeschränkten Berechtigungen funktionsfähig, statt das gesamte Tool unbrauchbar zu machen:- Wenn Bildschirmaufzeichnung gewährt wurde, Bedienungshilfen jedoch nicht (eine häufige Standardeinstellung), funktionieren Screenshots, während Klick-/Eingabe-/Scroll-Aktionen einen Fehler zurückgeben, der genau angibt, welche Berechtigung erteilt werden muss.
- Wenn überhaupt keine Anzeige verfügbar ist, gibt jede Computeraktion den Grund zurück (z. B.
DISPLAYnicht gesetzt) und was geändert werden muss.
ffmpeg auf der Maschine installiert sein – siehe Maschinenabhängigkeiten.
Tipps für optimale Ergebnisse
Geben Sie genau an, was getestet werden soll
- “Öffnen Sie die App, klicken Sie oben rechts auf die Schaltfläche Einstellungen, aktivieren Sie den Dark Mode und prüfen Sie, ob der gesamte Text weiterhin lesbar ist”
- “Starten Sie die Electron-App, erstellen Sie ein neues Dokument, geben Sie etwas Text ein und prüfen Sie, ob es gespeichert wird, wenn Sie das Fenster schließen”
Teilen Sie Devin mit, wie Erfolg aussieht
- “Das Dashboard sollte drei Diagramme ohne Fehlermeldungen anzeigen”
- “Nach dem Absenden des Formulars sollte oben auf der Seite ein grünes Erfolgsbanner erscheinen”
Zugriff vorab konfigurieren
Wenn Ihre App eine Authentifizierung erfordert, richten Sie Secrets im Voraus ein, damit Devin sich anmelden kann, ohne Sie während der Sitzung fragen zu müssen. Schließen Sie die Umgebungskonfiguration ab, um sicherzustellen, dass Devin Abhängigkeiten installieren und Ihre App ohne Probleme starten kann.Test-Skills erstellen
Für Apps, die Sie häufig testen, erstellen Sie einen Skill, der Devin genau vorgibt, wie Ihre Anwendung eingerichtet und getestet werden soll. Das spart Zeit bei wiederkehrenden Sitzungen und sorgt für konsistente Tests. Beispiele finden Sie unter Tests & Videoaufzeichnungen — Skill-Vorschläge.Skriptgesteuerte Browsernutzung über Playwright
Devins Chrome-Browser stellt einen Chrome DevTools Protocol (CDP)-Endpunkt bereit, zu dem Playwright eine Verbindung herstellen kann. Devin kann Playwright-Skripte schreiben und ausführen, um Browserinteraktionen in seinem eigenen laufenden Browser zu automatisieren — etwa Anmeldeabläufe oder systematische Dateneingaben. Sie können diese Skripte auch selbst schreiben und in Ihr Repo einchecken. Für die meisten anderen Browseraktionen sind Devins native Computer Use-Funktion oder seine Browser-Tools die bessere Wahl.So funktioniert es
Devins Chrome-Instanz lauscht auf Port 29229 auf CDP-Verbindungen. Ein Playwright-Skript kann sich mit diesem Browser verbinden, Aktionen ausführen (Formulare ausfüllen, auf Schaltflächen klicken, Weiterleitungen folgen) und die Verbindung anschließend wieder trennen. Da sich das Skript mit dem bestehenden Browser verbindet, anstatt einen neuen zu starten, bleiben alle Zustandsänderungen — Cookies, localStorage, Auth-Token — auch nach dem Beenden des Skripts erhalten. Das bedeutet, dass Devin die authentifizierte Sitzung sofort nutzen kann: Seiten aktualisieren, navigieren und normal mit der App interagieren.Beispiel: Verbindung zu Devins Browser herstellen
Wann Sie dies verwenden sollten
SSO-/OAuth-Flows
Automatisieren Sie mehrstufige Anmeldeabläufe (z. B. Okta, Auth0, Google SSO), bei denen es mühsam wäre, sich in jeder Sitzung manuell durchzuklicken.
Authentifizierung beim Umgebungs-Setup
Fügen Sie Ihrem Umgebungs-Setup ein Anmeldeskript hinzu, damit Devin jede Sitzung bereits authentifiziert startet.
Skill-basierte Automatisierung
Speichern Sie Anmelde- oder Dateneingabeskripte in einem Skill, damit Devin sie bei Bedarf automatisch ausführen kann.
Systematische Dateneingabe
Erstellen Sie Skripte für wiederholte Formularübermittlungen oder Massendateneingaben, die per Point-and-Click langsam und fehleranfällig wären.
Tipps
- Speichere Anmeldeskripte im Verzeichnis
.agents/skills/deines Repo, damit sie über Sitzungen hinweg erhalten bleiben - Verwende Secrets, um Zugangsdaten zu speichern — greife in deinen Skripten über Umgebungsvariablen darauf zu
- Der CDP-Endpunkt ist immer
http://localhost:29229— es ist derselbe Port, unabhängig davon, ob der Desktop-Modus aktiviert ist oder nicht - Nachdem das Skript ausgeführt wurde, kann Devin entweder Computer Use oder Browser-Tools verwenden, um mit der authentifizierten Sitzung zu interagieren
In Kombination mit Secrets, die als Umgebungsvariablen verfügbar gemacht werden, kann ein Skript in
.agents/skills/ zu Beginn jeder Sitzung jeden Zustand auf Browser-Ebene einrichten — nicht nur Cookies. Zum Beispiel kann ein Skript page.evaluate() aufrufen, um aus Umgebungsvariablen gelesene localStorage-Schlüssel (Feature-Flags, API-Tokens, Mandantenauswahl) zu schreiben, sodass Devins Browser immer in dem Zustand startet, den deine App erwartet. Informationen dazu, wie du manuell erfassten Zustand statt per Skript dauerhaft speicherst, findest du unter Browser-Authentifizierung.