Skyvern (YC S23) – Open-Source-KI-Agent für Browser-Automatisierung

 (github.com/Skyvern-AI)
4 Punkte von GN⁺ 2024-10-25 | 1 Kommentare | Auf WhatsApp teilen
  • Skyvern automatisiert LLM- und Computer-Vision-gestützte manuelle Workflows auf Websites und bietet zugleich ein Playwright-kompatibles SDK sowie einen No-Code-Workflow-Builder
  • Während klassische Browser-Automatisierung oft auf DOM-Parsing und XPath setzt und dadurch anfällig für Layout-Änderungen ist, versteht Skyvern Bildschirmelemente mit einem Vision LLM und plant bzw. führt die nötigen Aktionen aus
  • Skyvern gibt an, auch auf unbekannten Websites visuelle Elemente Aktionen zuordnen und denselben Workflow ohne vordefinierte XPaths oder Selektoren auf mehrere Websites anwenden zu können
  • Das SDK bietet die Befehle page.act, page.extract, page.validate, page.prompt und page.agent und ergänzt bestehende Playwright-Aktionen um eine Natural-Language-Prompt-basierte Elementsuche
  • Ebenfalls genannt werden lokale Ausführung, Docker Compose, Skyvern Cloud, Steuerung vorhandener Chrome-Instanzen, Browser-Tunneling, 64,4 % Genauigkeit in WebBench, die AGPL-3.0-Lizenz sowie eine Ausnahme für Anti-Bot-Funktionen der Managed Cloud

Das Problem, das Skyvern lösen will

  • Skyvern ist ein Projekt zur Automatisierung browserbasierter Workflows mit LLMs und Computer Vision
  • Es bietet ein Playwright-kompatibles SDK, das Playwright um KI-Funktionen erweitert
  • Außerdem gibt es einen No-Code-Workflow-Builder, damit technische und nichttechnische Nutzer manuelle Workflows auf beliebigen Websites automatisieren können
  • Klassische Browser-Automatisierung beruhte häufig auf websitespezifischen Custom Scripts, DOM-Parsing und XPath-basierten Interaktionen und konnte bei Änderungen am Website-Layout brechen
  • Skyvern verwendet nicht nur in Code definierte XPath-Interaktionen, sondern lernt und interagiert mit Websites über ein Vision LLM

Funktionsweise und Design

  • Skyvern ist vom Design aufgabengetriebener autonomer Agenten inspiriert, das durch BabyAGI und AutoGPT populär wurde
  • Ergänzt wird dies um die Fähigkeit, mit Websites über Browser-Automatisierungsbibliotheken wie Playwright zu interagieren
  • Um Websites zu verstehen, Aktionen zu planen und sie auszuführen, nutzt Skyvern einen Schwarm mehrerer Agenten
  • Die Vorteile dieses Ansatzes lassen sich in drei Punkten zusammenfassen
    • Ohne Custom Code können visuelle Elemente den nötigen Aktionen zugeordnet werden, sodass Skyvern auch auf unbekannten Websites funktionieren kann
    • Da beim Navigieren keine vordefinierten XPaths oder Selektoren gesucht werden, ist es robuster gegenüber Änderungen am Website-Layout
    • Ein einzelner Workflow kann auf mehrere Websites angewendet werden, wobei Skyvern die jeweils nötigen Interaktionen pro Site ableiten kann
  • Der technische Bericht zu Skyvern 2.0 ist unter Skyvern 2.0: State-of-the-art web navigation with 85.8 on WebVoyager eval verfügbar

Ausführungsarten

  • Skyvern Cloud ist die Managed-Cloud-Version, mit der Skyvern ohne eigene Infrastrukturverwaltung ausgeführt werden kann
  • Skyvern Cloud kann mehrere Skyvern-Instanzen parallel ausführen und umfasst Mechanismen gegen Anti-Bot-Erkennung, ein Proxy-Netzwerk und CAPTCHA-Solver
  • Lokal lässt sich Skyvern nach pip install "skyvern[all]" mit skyvern quickstart starten
  • skyvern quickstart und skyvern run server verwenden standardmäßig eine SQLite-Datenbank unter ~/.skyvern/data.db
    • Für einen lokalen Postgres-Container wird --postgres übergeben
    • Für eine vorhandene Datenbank wird --database-string übergeben
    • Docker Compose nutzt den mitgelieferten Postgres-Service
  • Die Ausführung mit Docker Compose containerisiert Postgres, API und UI vollständig; nach dem Eintragen der LLM-API-Keys in .env startet man mit docker compose up -d
  • Die UI ist standardmäßig unter http://localhost:8080 erreichbar

SDK und KI-basierte Playwright-Erweiterung

  • Das Skyvern SDK ist eine Erweiterung, die Playwright um KI-basierte Browser-Automatisierung ergänzt
  • Die Installation unterscheidet sich je nach Nutzungsform
    • Python SDK / Cloud API: pip install skyvern
    • Lokaler Server und paketierte UI: pip install "skyvern[all]" und danach skyvern quickstart
    • Lokaler Server und UI mit Postgres: pip install "skyvern[all]" und danach skyvern quickstart --postgres
    • Paketierte UI mit Verbindung zu einer vorhandenen API: pip install "skyvern[ui]" und danach skyvern run ui --api-url <api-url> --api-key <api-key>
    • TypeScript: npm install @skyvern/client
  • Dem Page-Objekt werden vier KI-Befehle hinzugefügt
    • page.act(prompt): führt Aktionen in natürlicher Sprache aus, etwa „Login-Button anklicken“
    • page.extract(prompt, schema): extrahiert strukturierte Daten mit optionalem JSON-Schema
    • page.validate(prompt): prüft den Seitenzustand und gibt bool zurück
    • page.prompt(prompt, schema): sendet beliebige Prompts mit optionalem Antwortschema an das LLM
  • page.agent bietet Workflow-Befehle auf höherer Ebene
    • page.agent.run_task(prompt): führt komplexe mehrstufige Aufgaben aus
    • page.agent.login(credential_type, credential_id): authentifiziert mit in Skyvern, Bitwarden oder 1Password gespeicherten Zugangsdaten
    • page.agent.download_files(prompt): navigiert und lädt anschließend Dateien herunter
    • page.agent.run_workflow(workflow_id): führt einen zuvor erstellten Workflow aus
  • Bestehende Playwright-Aktionen unterstützen über den optionalen Parameter prompt eine KI-basierte Elementsuche
    • Statt page.click("#btn"): page.click(prompt="Click login button")
    • Statt page.fill("#email", "a@b.com"): page.fill(prompt="Email field", value="a@b.com")
    • Statt page.select_option("#country", "US"): page.select_option(prompt="Country dropdown", value="US")
    • Statt page.upload_file("#file", "doc.pdf"): page.upload_file(prompt="Upload area", files="doc.pdf")
  • Es gibt drei Interaktionsmodi
    • Klassisches Playwright: Verwendung von CSS-/XPath-Selektoren
    • KI-basiert: Verwendung natürlicher Sprache
    • KI-Fallback: erst Selektor versuchen, bei Fehlschlag auf KI ausweichen

Erweiterte Browser-Steuerung

  • Skyvern kann den vorhandenen Chrome-Browser des Nutzers steuern
  • Dabei wird der bestehende Browser mit seinen Cookies, Logins und Erweiterungen unverändert verwendet
  • Chrome Remote Debugging kann unter chrome://inspect/#remote-debugging aktiviert werden
  • Der Befehl skyvern init browser öffnet die Remote-Debugging-Seite, wartet, bis der Nutzer sie aktiviert, und kann anschließend die Konfiguration speichern
  • Auch Skyvern Cloud kann eine auf dem lokalen Rechner laufende Chrome-Instanz steuern
    • Der Befehl skyvern browser serve --tunnel übernimmt Chrome-Start und Aufbau eines Tunnels zu Skyvern Cloud in einem Schritt
    • Das ist nützlich, wenn bereits eingeloggte Websites oder Websites hinter einem VPN automatisiert werden sollen
  • Beim Freigeben eines Browsers über einen Tunnel sollte immer --api-key verwendet werden

Leistung und Evaluation

  • Skyvern gibt an, im WebBench-Benchmark mit 64,4 % Genauigkeit SOTA-Leistung erreicht zu haben
  • Technischer Bericht und Evaluation sind unter Web Bench: A new way to compare AI browser agents verfügbar
  • Skyvern gibt außerdem an, der leistungsstärkste Agent für WRITE-Aufgaben zu sein
    • Beispiele für WRITE-Aufgaben sind das Ausfüllen von Formularen, Logins und Dateidownloads
    • Diese Kategorie wird hauptsächlich für RPA-nahe Aufgaben verwendet

Tasks und Workflows

  • Eine Task ist die grundlegende Baueinheit innerhalb von Skyvern
  • Jede Task ist eine einzelne Anforderung, eine Website zu navigieren und ein bestimmtes Ziel zu erreichen
  • Eine Task benötigt url und prompt
  • Optional können data schema und error codes enthalten sein
    • data schema wird verwendet, wenn die Ausgabe einem bestimmten Schema folgen soll
    • error codes werden verwendet, um die Ausführung von Skyvern in bestimmten Situationen zu stoppen
  • Ein Workflow verbindet mehrere Tasks zu einer Arbeitseinheit
  • Beispiel-Workflows
    • Um alle Rechnungen seit dem 1. Januar herunterzuladen, kann ein Workflow aus dem Aufrufen der Rechnungsseite, dem Filtern nach Datum, dem Extrahieren der Ziel-Rechnungsliste und dem Herunterladen jeder Rechnung bestehen
    • Eine Automatisierung für E-Commerce-Käufe kann aus Produktnavigation, Hinzufügen zum Warenkorb, Prüfung des Warenkorbs und Checkout bestehen
  • Zu den unterstützten Workflow-Funktionen gehören Browser Task, Browser Action, Data Extraction, Validation, For Loops, File parsing, Sending emails, Text Prompts, HTTP Request Block, Custom Code Block sowie Datei-Upload in Block Storage
  • Conditionals sind als „Coming soon“ gekennzeichnet

Wichtige Funktionen

  • Livestreaming überträgt den Browser-Viewport in Echtzeit auf den lokalen Rechner, damit sichtbar ist, was Skyvern im Web tut
    • Das ist nützlich für Debugging, Verständnis der Interaktionen und Eingreifen bei Bedarf
  • Form Filling kann Formulareingaben auf Websites grundsätzlich ausfüllen
    • Wenn Informationen über navigation_goal übergeben werden, versteht Skyvern den Inhalt und füllt das Formular aus
  • Data Extraction extrahiert Daten aus Websites
    • Wird data_extraction_schema im Hauptprompt im jsonc-Format angegeben, folgt die Ausgabe der Struktur dieses Schemas
  • File Downloading lädt Dateien von Websites herunter
    • Heruntergeladene Dateien werden automatisch hochgeladen, wenn Block Storage eingerichtet ist, und sind über die UI zugänglich
  • Authentication unterstützt mehrere Authentifizierungsmethoden, um die Automatisierung von Aufgaben hinter einem Login zu erleichtern
  • 2FA-Unterstützung wird auf mehrere Arten angeboten
    • QR-basierte 2FA, z. B. Google Authenticator, Authy
    • E-Mail-basierte 2FA
    • SMS-basierte 2FA
    • Die zugehörige Dokumentation steht unter 2FA support
  • Status der Passwortmanager-Integrationen
    • Unterstützt: Bitwarden
    • Unterstützt: Custom Credential Service, HTTP API
    • Nicht unterstützt: 1Password
    • Nicht unterstützt: LastPass

Integrationen und unterstützte LLMs

  • Skyvern unterstützt das Model Context Protocol (MCP), sodass LLMs genutzt werden können, die MCP unterstützen
  • Die MCP-Dokumentation findet sich in der MCP server documentation
  • Integrationen mit Zapier, Make.com und N8N werden unterstützt
  • Unterstützte LLM-Anbieter sind:
    • OpenAI: GPT-5.5, GPT-5.4, GPT-5, GPT-4.1, o3, o4-mini
    • Anthropic: Claude 4.7 Opus, Claude 4.6 Sonnet/Opus, Claude 4.5 Haiku/Sonnet/Opus
    • Azure OpenAI: alle GPT-Modelle, die in einem Azure-Abonnement bereitgestellt sind
    • AWS Bedrock: Claude 4.7, Claude 4.6 Sonnet/Opus, Claude 4.5 Sonnet/Opus
    • Gemini: Gemini 3.1 Pro, Gemini 3 Flash, Gemini 2.5 Pro/Flash
    • Ollama: lokal gehostete Modelle über Ollama
    • OpenRouter: Modellzugriff über OpenRouter
    • OpenAI-compatible: Custom-API-Endpunkte im OpenAI-API-Format über liteLLM
  • Details zur LLM-Konfiguration stehen in den LLM Configuration docs

Praxisbeispiele

  • Automatisierung des Rechnungsdownloads über mehrere Websites hinweg
  • Automatisierung von Bewerbungsprozessen
  • Automatisierung der Materialbeschaffung in Fertigungsunternehmen
  • Kontoerstellung oder Formularausfüllung auf Behörden-Websites
  • Ausfüllen zufälliger Contact-us-Formulare
  • Suche nach Versicherungsangeboten auf Versicherer-Websites in mehreren Sprachen

Fehlerbehebung und Betriebsbefehle

  • Ein bekannter Bug in pip install skyvern==1.0.31 kann zu (sqlite3.OperationalError) table organizations already exists führen
    • Die verbleibende SQLite-Datei ~/.skyvern/data.db löschen, mit pip install --upgrade skyvern auf Version 1.0.32 oder neuer aktualisieren und anschließend skyvern quickstart ausführen
    • Wenn 1.0.31 beibehalten werden muss, kann uv pip install skyvern verwendet werden
  • Wenn pip install skyvern mit ResolutionImpossible fehlschlägt, kann dies an einem Konflikt bei der Auflösung der Abhängigkeiten litellm / fastmcp in Version 1.0.31 liegen
    • Auf 1.0.32 oder neuer aktualisieren oder uv pip install skyvern verwenden
  • Nützliche Befehle fürs Debugging
    • skyvern run server: Skyvern-Server separat ausführen
    • skyvern run ui: Skyvern-UI ausführen
    • skyvern status: Dienststatus prüfen
    • skyvern stop all: alle Dienste stoppen
    • skyvern stop ui: UI stoppen
    • skyvern stop server: Server stoppen

Lizenz und Telemetrie

  • Skyvern sammelt standardmäßig Nutzungsstatistiken, um die Nutzungsweise besser zu verstehen
  • Um Telemetrie zu deaktivieren, wird die Umgebungsvariable SKYVERN_TELEMETRY auf false gesetzt
  • Das Open-Source-Repository von Skyvern wird durch eine Managed Cloud unterstützt
  • Die Kernlogik wird in diesem Open-Source-Repository unter der AGPL-3.0-Lizenz bereitgestellt
  • Anti-Bot-Maßnahmen, die im Managed-Cloud-Angebot enthalten sind, werden ausdrücklich als Ausnahme von der Kernlogik des Open-Source-Repositorys genannt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-25
Meinungen auf Hacker News

  • Mich würde interessieren, wie ihr die kürzlich von Anthropic angekündigte computer use-Funktion von Claude einschätzt.
    Da Claudes computer use noch relativ neu ist, würde ich gern wissen, was Skyverns wichtigste Differenzierungsmerkmale sind.

    • Ich arbeite in diesem Bereich, und Claudes Fähigkeit, Pixel zu zählen und mit dem Bildschirm über exakte Koordinaten zu interagieren, wirkt wie eine ziemlich nützliche Innovation, die bestehende Ansätze verbessern kann.
      Bisherige Ansätze zeichnen meist Bounding Boxes um interaktive Elemente, lassen das LLM einen Tool-Aufruf wie click('A12') ausgeben und mappen A12 dann auf das tatsächliche HTML-Element, um Selenium-/JS-Aktionen auszuführen. Solche Bounding Boxes heuristisch zu zeichnen ist schon knifflig, und wenn ein Click-Handler an einem anderen DOM-Element hängt, kann es ebenfalls schwierig sein, die richtige Aktion auszuführen.
      Hochwertige Aktionen wie click(x, y) oder type("foo") direkt auf dem Bildschirm auszuführen, ohne visuelle Elemente wieder auf HTML-Elemente zurückzumappen, könnte für Automatisierungsfälle deutlich effektiver sein. Allerdings zeigt sich derzeit auch, dass die Leistung tendenziell besser ist, wenn man dem LLM HTML als Kontext gibt, statt nur rein visuelles Reasoning zu nutzen. Deshalb bin ich gegenüber dem Claude-Ansatz optimistischer, besonders wenn sich visuelles Reasoning weiter verbessert.
    • Anthropics Produkt und Launch sind wirklich beeindruckend, und es ist bemerkenswert, wie viel sich allein mit Tool-Nutzung + Mikro-Agenten + Screenshots + Koordinaten bei der Interaktion mit Websites erledigen lässt.
      Allerdings ist fraglich, ob die Konkurrenz einfach untätig bleibt, statt Ähnliches zu bauen. Die Teams von xAI, Gemini, OpenAI, Mistral und MetaAI werden nicht einfach abwarten, und dieser Bereich dürfte künftig eine große Achse werden, sodass vermutlich nicht ein Unternehmen alles für sich beanspruchen wird.
      Wichtig ist außerdem, wo in solchen Systemen der tatsächliche Wert entsteht. Demos und ein schickes, brauchbares Produkt werden wahrscheinlich nicht ausreichen; die meisten wollen echte Workflow-Automatisierung. Für den persönlichen Gebrauch mag das genügen, aber Unternehmen werden vermutlich Komplexeres erwarten.
      Entscheidend ist schließlich auch, ob das nur für Claude optimiert sein wird. Wenn man es mit einem eigenen Open-Source-LLM betreiben oder laufend auf das jeweils beste Modell am Markt wechseln möchte, dürfte es schwer sein, diese Flexibilität in einer Lösung eines großen Anbieters zu bekommen. Anthropic hat schließlich einen Anreiz, intern Claude nutzen zu lassen.
      Dieser letzte Punkt stimmt hoffnungsvoll. Skyvern-Nutzer im Open-Source-Bereich können das gewünschte Modell wählen und sind nicht an Claude gebunden. Es lässt sich auch mit Gemini, GPT-4O oder Open-Source-Modellen wie Llama 3.2 betreiben.

  • Es dürfte nicht der erste AI-Wrapper auf Playwright sein, der diese Woche erschienen ist, und vermutlich nicht einmal der erste in diesem Monat.
    Der Einsatz aus Sicht der Geschäftsprozessautomatisierung wirkt überzeugender als Testautomatisierung. Bei Testautomatisierung sind die Genauigkeit und Wiederholbarkeit des Ablaufs viel wichtiger; bei Geschäftsautomatisierung ist es oft weitgehend egal, ob ein seltsamer Weg genommen wird, solange das Ergebnis stimmt.
    Im Beispielvideo musste allerdings ein ziemlich großer Prompt geschrieben werden, damit es funktionierte, und einige KB Payload-Daten mussten ebenfalls als Klartext statt als CSV eingegeben werden. Wenn die Erwartung ist, damit Menschen zu ersetzen, denen die direkte Nutzung des Playwright-Codegenerators zu technisch und schwierig ist, bin ich nicht sicher, ob es so viele Menschen gibt, die das eine können, das andere aber nicht.
    Zudem sieht es so aus, als müssten Nutzer ihre Login-Zugangsdaten für Websites und sogar Kreditkarteninformationen im Klartext übergeben. Um schwerwiegende Folgen zu vermeiden, falls das Skyvern-Konto eines Nutzers kompromittiert wird, muss der Umgang mit sensiblen Daten sehr robust sein.
    Ich denke auch, dass Anbieter von LLM-basierten Playwright-Wrappern dazu neigen, die Häufigkeit von Website-Redesigns zu übertreiben. Das gilt besonders bei älteren Websites oder Regierungsseiten. Ich habe zum Beispiel seit Jahren ein langes Bündel von Playwright-Browserautomatisierungen für die Interaktion mit Regierungsseiten betrieben und musste es nur einmal warten, als sich der Geschäftsprozess der Behörde änderte. Selbst mit Skyvern hätte man Prompt und Payload ändern müssen, weil sich der Ablauf geändert hatte.
    Der Unterschied zu Playwright-Automatisierung besteht darin, dass man Erfolg/Fehlschlag jedes Schritts und die Korrektheit der Datenerfassung mit Assertions prüfen kann und so merkt, dass der Ablauf aktualisiert werden muss. Bei Skyvern sehe ich diese Option nicht, und ich mache mir Sorgen, dass man Ablaufänderungen übersieht und dann anfängt, falsche Daten einzugeben oder Schritte auszulassen.

    • Es stimmt, dass die aktuelle Prompt- und Payload-Struktur eher komplex ist, aber wir konnten Nutzern mithilfe eines LLM dabei helfen, diese Payload zu erzeugen.
      Technische Nutzer wollen mehr lernen und die Payload selbst erstellen; nichttechnische Nutzer bitten ein LLM, ihnen bei der Erstellung des finalen Skyvern-Prompts zu helfen, und starten so. Das war unerwartet, fühlte sich aber überraschend natürlich an.
      Schritt 1 ist, es auf komplexe Weise zu bauen, also Playwright; Schritt 2 ist die aktuelle Phase, in der man mit einem komplexen Prompt etwas Playwright-Äquivalentes baut; Schritt 3 ist, etwas zu bauen, das mit einem einfacheren Prompt etwas Playwright-Äquivalentes erzeugt. Jeder Schritt senkt die technische Hürde, die für den Bau von Automatisierung nötig ist.
      Die Häufigkeit von Website-Änderungen sehe ich als kleineres Wertversprechen LLM-basierter Automatisierung. Der größte Wert liegt darin, sehr dynamische Situationen handhaben zu können. Wenn man zum Beispiel eine E-Commerce-Website automatisiert, deren Popup-Angebote sich jede Woche ändern, kümmert Skyvern sich kaum darum, während ein Playwright-Skript kaputtgehen kann.
      Ich mag das Geico-Beispiel, weil es gut zeigt, was früher sehr schwer zu automatisieren war. Das Formular ändert sich bei jeder Ausführung, aber Skyvern kommt problemlos durch.
      Was Datengenauigkeit angeht, veröffentlichen wir gerade eine Workflow-Funktion, mit der mehrere Aufgaben verkettet werden können. Das Interessante daran ist, dass man Schritte hinzufügen kann, in denen Skyvern seine Ergebnisse selbst überprüft, bevor es weitermacht. Zum Beispiel kann es n Produkte in den Warenkorb legen, dann zum Warenkorb gehen und den Zustand des Warenkorbs verifizieren.
      Wie zu erwarten, schafft das die Grundlage dafür, dass andere Agenten mit solchen Tools eigenständig Workflows aus einfacheren Prompts erstellen können. Kurz gesagt: Es ist der erste Schritt einer langen Reise, um Geschäftsprozessautomatisierung mit LLMs immer einfacher zu machen.

  • Zum jetzigen Zeitpunkt ein Startup auf Basis eines Drittanbieter-LLM zu bauen, wirkt entweder sehr wagemutig – oder man braucht ein Geschäftsmodell, das auf kurzfristige Erlöse aus ist.
    Wenn der Zeithorizont nicht Monate, sondern Jahre beträgt, ist das riskant. Anthropic ist gestern in diesen Bereich eingestiegen, und OpenAI und Google dürften wahrscheinlich bald nachziehen.

    • Viele Unternehmen wie Vercel und Supabase haben große Geschäfte aufgebaut, indem sie AWS „umhüllt“ haben.
      Sie konkurrieren im wörtlichen Sinn mit AWS und nutzen zugleich AWS, um ihre eigenen Produkte bereitzustellen. Dieser Markt ist groß, und es gibt Raum für unterschiedliche Ansätze.
      OpenAI, Anthropic und Google werden in diesem Bereich sicher große Geschäfte aufbauen, aber ich sehe keinen Grund, warum nicht auch jemand anderes eine gute Idee haben und sie in Abhängigkeit von großen Infrastruktur-Anbietern umsetzen sollte.
    • Ich weiß nicht, was „eingestiegen“ bedeuten soll. Ich weiß nicht genau, was passiert ist.

  • Interessant, dass es unter AGPL als Open Source veröffentlicht wurde.
    Vielleicht steht die Antwort schon in der Doku, aber bei einer kurzen Suche im Source sah es so aus, als würden sie LangChain nicht verwenden und eher eine Integration planen, um künftig etwas zu dessen Community beizutragen. Mich würde interessieren, was Skyvern beim Aufbau der Thought/Action-Chain-Logik verwendet hat und ob sie, wenn sie heute neu anfangen würden, eine Richtung wie LangChain/Graph in Betracht ziehen würden.

    • Anfangs haben wir das AutoGPT-Framework verwendet.
      Davon sind noch viele Spuren in Dingen wie Tasks und Steps übrig, aber als wir weiter skalieren und komplexere Dinge tun wollten, stellten wir fest, dass das Framework sehr einschränkend ist.
      Zum Beispiel verwenden wir derzeit eine Multi-Agent-Architektur, in der Micro-Agents laufen, die etwa SVGs analysieren oder dynamische Autovervollständigungen ausfüllen; so eine Struktur wäre mit bestehenden Frameworks wirklich schwierig gewesen.
      Frameworks wie LangChain sind gut für frühes Prototyping, aber wenn man die Grenzen ausreizen will, schränken sie zu stark ein.

  • Falls „Browser-Automatisierung“ verwirrend ist: Gemeint ist, dass ein Programm eine Ziel-Website ähnlich wie mit Selenium steuert.
    Üblicherweise werden auf einer Ziel-Website, die jemand anderem gehört, Tastatureingaben sowie Mausbewegungs- und Klickereignisse ausgelöst, damit diese Website etwas tut. Wenn man das weiß, versteht man den Rest der Beschreibung.

  • Jedes Mal, wenn ich solche LLM-Workflow-Automatisierungstools sehe, stellen sich mir einige Fragen zu den jeweiligen Anwendungsfällen und den langfristigen Folgen.
    Erstens frage ich mich, ob damit Reibung umgangen wird, die durch mangelnde Interoperabilität zwischen Tools entsteht. Wäre es zum Beispiel effizienter gewesen, wenn der Website-Betreiber einen REST-Service angeboten hätte? Werden Unternehmen wegen solcher Tools vielleicht auch dann keine Service-Endpunkte mehr anbieten, wenn es sinnvoll wäre?
    Zweitens: Wenn es berechtigte Gründe gibt, aus Sicherheitsgründen oder Ähnlichem keinen Service-Endpunkt zu haben, kann ein automatisierter Workflow dazu verwendet werden, diese Sicherheitsmaßnahmen zu umgehen. Kann ein böswilliger Akteur das Tool nutzen, um wichtige Dienste lahmzulegen? Kann der Hersteller des Tools selbst zu so einem Akteur werden? Können Reseller es nutzen, um stark nachgefragte Waren normalen Verbrauchern vorzuenthalten?
    Drittens: Wenn es dazu genutzt wird, aufgeschobene Wartung interner Tools und Prozesse zu umgehen, kann die Existenz solcher Tools dem Management einen Vorwand liefern, Wartung noch weiter aufzuschieben. Am Ende könnten sie zu einer zentralen Abhängigkeit im Workflow des Support-Personals werden.
    Viertens: Wenn sie wohlmeinend genutzt werden, um Antipatterns im Website-Design zu umgehen, hat der Website-Betreiber dann einen Anreiz, diesen Workflow zu brechen? Ist das am Ende nur eine weitere Stufe in einem Wettrüsten?
    Diese Gedanken kommen mir jedes Mal, wenn ich sehe, wie Software auf komplexe Prozesse gesetzt wird und man, statt den zugrunde liegenden Prozess zu vereinfachen, einfach eine weitere Schicht Komplexität darüberlegt. Dass das Projekt nützlich sein wird, ist klar, aber ich frage mich nach den langfristigen Effekten.

    • Websites ohne API gibt es normalerweise aus einem von zwei Gründen. Entweder möchten sie ihre Daten schützen, wie LinkedIn, oder sie haben keine Ressourcen oder keine Lust, eine API zu bauen, wie kleine Websites oder Behördenportale.
      Skyvern löst dieses Problem, könnte aber, wenn LLM-Kosten sinken, auch dafür sorgen, dass solche Websites keine API mehr bauen müssen.
      Wir möchten nicht, dass Skyvern auf Websites eingesetzt wird, die ein solches Verhalten untersagen. LinkedIn ist das klassische Beispiel. Insbesondere haben wir Code rund um Anti-Bot-Maßnahmen oder Captchas nicht als Open Source veröffentlicht, weil wir Anfragen wie „Reddit-Empfehlungen manipulieren“ bekommen. Solche böswilligen Akteure wollen wir nicht unterstützen.
      Insgesamt sehe ich bei AI-Browser-Automatisierung einen positiven Nettoeffekt. Wenn der Bedarf an APIs sinkt, muss man nicht mehr sowohl API als auch UI pflegen, die Experience wird einfacher, es gibt weniger Code, und das System wird insgesamt simpler.
      Beim letzten Teil bin ich mir nicht zu 100 % sicher. Normalerweise gehe ich davon aus, dass Unternehmen keine APIs bauen, weil sie kein Budget dafür haben. Also nicht aus böswilligen Gründen. Unternehmen wie LinkedIn werden versuchen, Automatisierungsversuche zu blockieren, aber an so einem Katz-und-Maus-Spiel wollen wir nicht teilnehmen.

  • Ich frage mich, ob Skyvern Daten von mehreren Websites mit unterschiedlicher Struktur scrapen und zu strukturierten Daten in einer einzigen CSV- oder JSON-Datei zusammenführen kann.
    Zum Beispiel: Kann es von mehreren Bank-Websites die Zinssätze für Sparkonten scrapen, für jedes Konto Bankname, Banklogo, Produktname und Zinssatz extrahieren und gespeicherte Queries täglich oder wöchentlich nach einem Zeitplan ausführen?

    • Theoretisch ist das möglich. Man müsste es über die Workflow-Funktion einrichten und mehrere Tasks zum Sammeln der Informationen miteinander verketten.

  • Ich frage mich, ob jemand Erfahrung damit hat, Skyvern auf Airline-Websites laufen zu lassen.
    Zum Beispiel, um die Verfügbarkeit von Prämienplätzen für Meilenflüge von Punkt A nach Punkt B zu extrahieren. Airlines ändern ständig ihre Oberflächen und scheinen auch starke Anti-Scraping-Maßnahmen zu haben.

    • Genau bei diesem Anwendungsfall haben wir bisher noch nicht geholfen, aber wir integrieren gerade mit einem Unternehmen, das den Kauf von Alaska- und Southwest-Flugtickets im Namen echter Menschen automatisieren will.
      Das soll eine Möglichkeit sein, Kreditkartentransaktionen beta-zu-testen und die Zuverlässigkeit zu verifizieren.

  • Ich baue etwas Ähnliches in kleinerem Maßstab, und dieser Bereich wirkt ziemlich vielversprechend.
    Nachdem wir den Problemumfang auf Interaktion/Scraping auf einer einzelnen Seite begrenzt hatten, war es im Unternehmen sehr stabil und nützlich. Agentenbasierte Automatisierung sieht allerdings auch spannend aus.

    • Besonders nützlich war es in sehr dynamischen Situationen.
      Zum Beispiel ist es mit normalem Code wirklich schwierig, die Vielfalt beim Ausfüllen von Kontaktformularen auf Hunderten Websites zu handhaben, aber für einen AI-Agenten ist das kein großes Problem.

  • Ich frage mich, ob es Zahlen zu WebArena(https://webarena.dev) oder VisualWebArena(https://jykoh.com/vwa) gibt.

    • Noch nicht. Unser interner Datensatz ist zu stark verzerrt, deshalb haben wir ihn nicht öffentlich geteilt, aber in ein paar Wochen soll etwas kommen.