Fallstudie: Einen browsergestützten Karriere-Crawler für Beyond Tabs bauen
Beyond Tabs versucht nicht, jeden Job im Internet zu indexieren.
Die Seite ist absichtlich enger: eine kuratierte Sammlung für Nischen-Programmiersprachen und angrenzende technische Communities. Dadurch wird das Crawling-Problem interessanter. Ein nützliches Ergebnis lautet nicht nur “diese Firma hat Jobs”, sondern “diese Quelle könnte Jobs enthalten, die für die Menschen relevant sind, die zu Beyond Tabs kommen”.
Die aktuelle Herausforderung ist die Karriere-Pipeline. Hunderte Firmen haben Karriereportale. Manche nutzen bekannte Applicant-Tracking-Systeme. Manche verstecken eine gemeinsame Plattform hinter einer gebrandeten Seite. Manche haben individuelle Websites mit wenigen Links. Manche sind Aggregatoren, die übersprungen werden sollten. Manche zeigen ihre echte Struktur erst nach JavaScript, Cookie-Banner, Altersprüfung oder länderspezifischer Weiterleitung.
Für diese Art Arbeit wurde Guida gebaut.
Das Problem war nicht nur Scraping
Wenn jede Firma dasselbe ATS nutzen würde, wäre die Lösung simpel: Plattform erkennen, API aufrufen, Ergebnisse normalisieren und weiter.
Das echte Web ist anders.
In einem Triage-Lauf enthielt ein Karrierebericht hunderte Portale in groben Kategorien: bekannte ATS-Abdeckung, dedizierte Unternehmensworkflows, generische unbekannte Sites und Aggregatoren. Der unbequeme Bereich war “generisch unbekannt”: kleine statische Karriereseiten, globale Recruiting-Plattformen hinter gebrandeten URLs und alles dazwischen.
Eine URL allein reichte nicht. Manche Seiten sahen wie First-Party-Karriereportale aus, renderten nach einer Prüfung aber SuccessFactors oder jobs2web. Andere zeigten eine polierte Unternehmensseite, deren Joblinks zu Lever führten. Wieder andere betteten BambooHR ein oder verlinkten Details an HR-ON.
Diese Unterschiede entscheiden, welcher Crawler geschrieben werden sollte. Eine gemeinsame Plattform gehört in wiederverwendbare Infrastruktur. Eine echte First-Party-Site braucht einen firmenspezifischen Worker. Ein Aggregator sollte ignoriert werden. Ein Fehler in den Quelldaten sollte korrigiert werden, bevor jemand Code schreibt.
Warum WebView2 den Ablauf änderte
Die Abkürzung wäre, alles mit HTTP-Anfragen und URL-Heuristiken zu klassifizieren.
Das wäre schneller gewesen. Es wäre aber oft genug falsch gewesen, um später Zeit zu verschwenden.
Guida nutzt WebView2 als Automatisierungsoberfläche. Agent und Benutzer sehen also dieselbe Browserrealität. Seiten rendern mit normaler Browserengine. JavaScript läuft. Cookie-Banner erscheinen. Weiterleitungen passieren. Der Benutzer kann Domains bei Bedarf freigeben. Der Agent kann gerenderten DOM, sichtbare Links, Skripte, iframes und finale URL aus einem Live-Tab prüfen, statt aus Roh-HTML zu raten.
Der Arbeitszyklus wurde:
- Mit dem Crawler-Lückenbericht beginnen.
- Die nächsten unklassifizierten Portale aus dem Arbeitsbereichsspeicher wählen.
- Vier Browser-Tabs wiederverwenden.
- Quad-Layout und Full-HD-Viewports setzen.
- Jeden Tab zu einer echten Karriereseite navigieren.
- Gerenderten Inhalt, Links, Skripte, iframes und Plattformhinweise prüfen.
- Eine strukturierte Feststellung unter dem Portal-Key speichern.
- Mit dem nächsten Batch fortfahren.
Der Punkt war nicht Vollautonomie, sondern beaufsichtigte Automatisierung. Der Benutzer konnte sehen, welche Seiten offen waren, wo Navigation stockte und ob der Agent das Richtige klassifizierte.
Der Store wurde Arbeitsgedächtnis
Die ersten Triage-Notizen lagen in Textdateien. Das hielt nicht lange.
Sobald sich die Arbeit über hunderte Portale und mehrere Sitzungen erstreckte, mussten Notizen abfragbarer Zustand werden. Der Arbeitsbereichsspeicher von Guida wurde zum Arbeitsgedächtnis.
Der Crawler-Bericht wurde in eine Collection mit stabilem Portal-Identifier importiert. Browsergestützte Findings wurden in einer zweiten Collection mit demselben Identifier und einheitlichem Schema gespeichert. Dadurch ließen sich Fragen beantworten:
- Welche Portale sind noch untriagiert?
- Welche sind gemeinsame Plattformen?
- Welche brauchen individuelle Crawler?
- Welche Findings stammen aus echter Browser-Evidenz?
- Was hat der Agent gesehen, als er die Entscheidung traf?
Der Prozess konnte aus Daten fortgesetzt werden, statt sich auf Gesprächsgedächtnis oder manuelle Notizen zu verlassen.
Das Ledger zählt, weil Crawling operative Arbeit ist
Karriere-Crawling ist kein einmaliges Skript. Es ist ein Workflow.
Portale reihen Job-URLs ein. Fetch-Worker besuchen Seiten. Parse-Worker extrahieren und indexieren Listings. Manche Items sind fertig. Manche werden übersprungen. Manche scheitern temporär. Manche landen in Fehlerwarteschlangen. Manche Leases laufen ab und brauchen Wiederherstellung.
Darum wurde das Workflow Ledger wichtig. Eine Crawler-Pipeline ohne operative Sichtbarkeit lässt Benutzer raten. Das Nachverfolgungsregister erklärt, was passiert ist: Runs, Items, States, Stages, Events, Wiederholungen, Fehler und verknüpfte Ausgaben.
Dieser Druck führte später zur dedizierten Workflow Ledger Console. Für Beyond Tabs sollte niemand raten müssen, ob ein Crawler fertig, blockiert, am Wiederholen oder still kaputt ist. Die Anwendung soll es direkt zeigen.
Was Guida gut machte
Guida machte die Arbeit prüfbar.
Das Quad-Layout ließ vier echte Sites gleichzeitig sichtbar bleiben. Die MCP History zeigte Werkzeugaufrufe. Das Store-Panel zeigte strukturierte Findings. Die Browser-Tabs zeigten die tatsächlich gerenderten Seiten. Diese Kombination ist nützlicher als ein headless Logstrom, weil der Benutzer eingreifen kann, wenn das Web sich wie das Web verhält.
Guida machte die Arbeit auch wiederaufnehmbar. Sobald Findings im Arbeitsbereichsspeicher lagen, konnten Batches über Sitzungen hinweg fortgesetzt werden.
Am wichtigsten: Guida hielt den Agenten geerdet. Er klassifizierte nicht nach Bauchgefühl oder alten Annahmen, sondern sah gerenderte Evidenz und schrieb auf, warum eine Entscheidung getroffen wurde.
Was noch Arbeit braucht
Reibungslos war es nicht.
Navigation kann noch Fehler melden, obwohl die Seite tatsächlich geladen hat; Workflows brauchen daher Folgeprüfungen mit aktueller URL und DOM. Der Vier-Tab-Triage-Ablauf verdient außerdem eine höhere Steuerung: “Diesen Batch vorbereiten, diese Tabs im Quad-Layout halten und das Layout stabil lassen” sollte eine Operation sein, nicht eine Folge kleiner Tab- und Layoutaufrufe.
Zustimmungsdialoge und Allowlisting sind menschlich getaktet, was richtig ist. Die UI muss ausstehende Freigaben und blockierte Seiten aber klar zeigen. Das zeigt sich bereits in Guida: Das MCP Approval Center macht ausstehende Anfragen sichtbar, und dedizierte Workflow- und Queue-Konsolen verschieben operative Wiederherstellung aus engen Seitenpanelen.
Die Lehre
Der Beyond-Tabs-Crawler liegt genau zwischen manuellem Browsen und industriellem Scraping.
Er braucht Automatisierung, aber keine blinde Automatisierung. Er braucht KI-Unterstützung, aber keinen unsichtbaren Agenten. Er braucht Datenpipelines, aber auch menschliches Urteil. Er muss skalieren, aber erst nachdem Klassifikationen vertrauenswürdig sind.
Guidas Rolle ist, diesen Zwischenbereich praktikabel zu machen.
Für Beyond Tabs bedeutet das: mit einem browsergestützten Workflow entscheiden, welche Crawler gebaut werden, welche Plattformen wiederverwendbar unterstützt werden, welche Quellen übersprungen werden und welche Fehler Aufmerksamkeit brauchen. Für Guida ist es eine echte Fallstudie dafür, warum sichtbare, lokale, beaufsichtigte Browserautomatisierung etwas anderes ist als noch ein headless Scraper.