Computer-Use-Agenten scheitern an Pixeln: wie Sie auf stabile UI-Referenzen über Accessibility Trees umstellen und fehleranfällige Desktop-Automatisierung nicht mehr ständig reparieren

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und bei DennisCraft AI Studio setze ich produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres um. Die teuersten Fehler in der Desktop-Automatisierung entstehen im Alltag meist nicht durch das Modell, sondern dadurch, dass ein Agent weiterhin auf dieselben Pixel klickt, obwohl sich die Oberfläche geringfügig verschoben hat.

Genau dort liegt das strukturelle Problem vieler Computer-Use-Ansätze. Das Bild auf dem Bildschirm wird als Schnittstelle behandelt. Tatsächlich ist es nur die Darstellung. Wenn Ihr Agent primär mit Bildschirmfotos, Koordinaten und visuellen Vermutungen arbeitet, steuern Sie über die instabilste Ebene des Systems.

Warum pixelbasierte Steuerung im Produktivbetrieb ausfällt

In einer Vorführung funktioniert pixelbasierte Automatisierung oft erstaunlich gut: ein Gerät, eine Auflösung, eine Sprache, ein bekanntes Fensterlayout. Im Produktivbetrieb gelten andere Bedingungen. Fenster werden verschoben, Hinweise eingeblendet, die Skalierung steht auf 125 % oder 150 %, die Sprache wechselt, und ein kleines Update verschiebt eine Schaltfläche um wenige Pixel.

Koordinaten sind keine Referenzen

Eine Koordinate bezeichnet einen Ort auf dem Bildschirm, aber kein UI-Objekt. Das ist der Kernfehler. Sobald sich eine Seitenleiste ausklappt oder eine Statuszeile eingeblendet wird, zeigt dieselbe x/y-Position auf ein anderes Element. Im Protokoll sieht der Schritt dennoch oft formal korrekt aus.

Bildschirmfotos enthalten Erscheinung, nicht Bedeutung

Ein Bildschirmfoto zeigt, wie etwas aussieht. Es sagt aber nicht verlässlich, ob es sich um ein Eingabefeld, eine deaktivierte Schaltfläche, ein Auswahlmenü oder statischen Text handelt. Ein Accessibility Tree enthält dagegen Rolle, Bezeichnung, Zustand, teilweise den aktuellen Wert sowie Beziehungen zwischen Eltern- und Kindelementen. Für die Automatisierung ist das ein erheblicher Unterschied.

Lokalisierung und Darstellung verschärfen das Problem

Im DACH-Markt laufen dieselben Abläufe häufig in deutscher und englischer Sprache, teils mit unterschiedlichen Systemeinstellungen. OCR und Computer Vision helfen als Beobachtungskanal, bleiben aber eine Wahrscheinlichkeitsinterpretation einer gerenderten Oberfläche. Für verlässliche Ausführung reicht das allein selten aus.

Auch Dokumentation von Anbietern wie Anthropic zu Tool Use und Computer Use folgt demselben Grundsatz: Wenn strukturierte Interaktionsflächen vorhanden sind, sollten sie gegenüber rein visueller Steuerung bevorzugt werden. Vergleichbar ist das mit Browser-Automatisierung, wo rollenbasierte Selektoren deutlich stabiler sind als Positionsangaben.

Was sich durch UI-Referenzen über den Accessibility Tree ändert

Die Umstellung ist konzeptionell einfach: Der Agent arbeitet primär mit semantischen Referenzen auf UI-Elemente. Bildschirmfotos bleiben für Bestätigung, Nachvollziehbarkeit oder als Rückfallweg erhalten. Ihr Agent sollte also nicht „unten rechts auf die blaue Fläche klicken“, sondern „die Schaltfläche Save im Fenster Invoice Editor auswählen“.

Der Gewinn liegt also nicht primär in „besserem Sehen“ des Modells, sondern in einer anderen Steuerungsoberfläche. Das Modell arbeitet mit beständigen Objekten statt mit gerenderten Vermutungen.

Ein Muster für den Produktivbetrieb

Ich setze dafür eine dünne Adapter-Schicht zwischen Agent und Desktop-Anwendung ein. Diese Schicht liest den Accessibility Tree aus, normalisiert ihn, löst Referenzen auf, führt Aktionen aus und schreibt strukturierte Ereignisse nach Postgres. Das passt gut zu Anforderungen aus ISO 27001, BSI Grundschutz und dem EU AI Act, weil Nachvollziehbarkeit und kontrollierte Ausführung leichter abbildbar sind.

1. UI-Elemente in stabile Referenzen überführen

from dataclasses import dataclass
from typing import Optional

@dataclass
class UIRef:
    app: str
    window: str
    role: str
    name: str
    path: str
    enabled: bool
    value: Optional[str] = None

def can_act(ref: UIRef) -> bool:
    return ref.enabled and ref.role in {
        "button", "textbox", "checkbox", "menuitem", "link"
    }

2. Aktionen semantisch statt über Positionen auflösen

def resolve_target(ax_tree: list[dict], role: str, name: str) -> dict | None:
    matches = [
        node for node in ax_tree
        if node.get("role") == role and node.get("name") == name
    ]
    enabled = [node for node in matches if node.get("enabled", True)]
    return enabled[0] if enabled else None

target = resolve_target(ax_tree, role="button", name="Save")
if target is None:
    raise RuntimeError("Target not found")
perform_click(target["path"])

3. Referenzauflösung und Ausführung getrennt protokollieren

Viele Teams verlieren hier die Transparenz. „Agent fehlgeschlagen“ ist keine brauchbare Fehlerklasse. Sie benötigen mindestens: Referenz nicht gefunden, falsches Element aufgelöst, korrektes Element betätigt, aber fachliche Aktion abgelehnt. Erst dann lassen sich Ursachen sauber eingrenzen.

4. Bildschirmfotos als Nachweis, nicht als alleinige Wahrheit

Bildschirmfotos bleiben nützlich. Sie helfen zu prüfen, ob ein Dialog geöffnet wurde, ein Warnhinweis erschien oder ein Zustandswechsel sichtbar ist. Für menschliche Prüfung und Vorfallanalyse sind sie wertvoll. Als einziges Adressierungsmittel sollten sie jedoch nicht dienen.

Minimale Orchestrierung mit Claude, n8n und Postgres

Ein praxistauglicher Ablauf sieht so aus: Accessibility Tree erfassen, Aufgabe plus UI-Kontext an das Modell geben, das ausgewählte Ziel im aktuellen Tree auflösen, Aktion ausführen, Ereignisse speichern. n8n eignet sich dabei gut für die Orchestrierung, Postgres für Sitzungszustand und Prüfspur.

version: "1"
steps:
  - name: snapshot_ui
    tool: ui-adapter
    action: get_accessibility_tree
  - name: decide
    tool: claude
    input: ax_tree + task + history
  - name: resolve_ref
    tool: ui-adapter
    action: resolve_and_validate
  - name: execute
    tool: ui-adapter
    action: click_or_type
  - name: persist
    tool: postgres
    action: write_event

Gerade in regulierten Umgebungen ist das ein Vorteil. Statt nur Bildschirmfotos abzulegen, speichern Sie strukturierte Ereignisse: Sitzungs-ID, Schritt, beabsichtigte Aktion, aufgelöste Rolle, aufgelöster Name, Fenstertitel, Ergebnis und sichtbarer Folgezustand. Das unterstützt Nachvollziehbarkeit, interne Kontrollen und Datenschutzanforderungen nach DSGVO deutlich besser als unstrukturierte Bildsammlungen.

Wo auch dieser Ansatz an Grenzen stößt

Accessibility Trees sind kein Allheilmittel. Ältere Desktop-Anwendungen liefern teils unvollständige Metadaten. Eigene Bedienelemente verbergen Rollen. Virtualisierte Listen ändern ihre Struktur zwischen zwei Aufnahmen. Deshalb bevorzuge ich einen hybriden Ansatz: semantische Referenzen als primärer Selektor, Bildprüfung nach der Aktion und Übergabe an einen Menschen, wenn der erwartete Zustand nach 2 oder 3 Versuchen nicht eintritt.

Wenn eine Anwendung schwache Accessibility-Daten liefert, sollten Sie das nicht mit mehr Prompt-Logik überdecken. Sinnvoller ist eine lokale Normalisierungsschicht mit Aliasen für Labels, einer Positivliste erlaubter Aktionen und Regeln zur Zustandsprüfung. Das ist im Betrieb günstiger, als fortlaufend fehleranfällige Automatisierung zu reparieren.

FAQ

Wann ist pixelbasierte Steuerung noch vertretbar?

Wenn weder ein Accessibility Tree noch eine Automatisierungs-API verfügbar sind und der Prozess selten läuft sowie leicht manuell korrigiert werden kann. Selbst dann sollte der Einsatzbereich eng begrenzt bleiben.

Ersetzt OCR den Accessibility Tree?

Nein. OCR ist als Beobachtungskanal nützlich, etwa bei PDFs, Bildern oder canvasbasierten Oberflächen. Für die Auswahl und Ausführung von Aktionen ist semantische UI-Metadaten in der Regel verlässlicher.

Benötigen Sie dafür ein anderes Modell?

Meist nicht. Wenn die Hauptursache in instabiler Zieladressierung liegt, bringt die Änderung der Steuerungsebene oft mehr als ein Modellwechsel.

Wie sollten UI-Referenzen in Postgres gespeichert werden?

Ich speichere Schnappschüsse des Trees meist als JSONB und Aktionen in einer separaten Tabelle mit session_id, step_id, target_ref und result. Das erleichtert Wiederholung, Vorfallanalyse und Vergleich verschiedener UI-Stände.

Was tun bei mehrsprachigen Labels?

Arbeiten Sie mit Aliasen und mehreren Merkmalen zugleich: Rolle, lokalisierter Name, Elterngruppe und Pfad. In mehrsprachigen DACH-Abläufen reicht ein einzelnes Textlabel selten aus.

Wenn Sie bereits Computer-Use-Agenten gegen Desktop-Software betreiben: An welcher Stelle entstehen Ihre meisten Vorfälle heute — bei der Zielauflösung, bei der Zustandsbestätigung oder erst bei der manuellen Analyse nach dem Fehler? Das würde ich gern mit meinen Beobachtungen aus produktiven DACH-Systemen abgleichen. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.