Zurück zum Blog
Engineering10 Min. Lesezeit
Wie man Dutzende Antidetect-Browser parallel ausführt, ohne die Synchronisierung zu verlieren
Wir erklären gruppierte Vision-Analyse, Status-Recovery und Concurrency-Kontrollen, die große Browser-Batches wie ein einziges System arbeiten lassen.
1. Apr. 2026Die Herausforderung der parallelen Browserautomatisierung
Einen Browser auszuführen ist einfach. 50 Browser gleichzeitig das Gleiche tun zu lassen, ist ein völlig anderes Problem. Seiten laden mit unterschiedlichen Geschwindigkeiten, CAPTCHAs erscheinen in einigen Sitzungen, aber nicht in anderen, und die Netzwerkbedingungen unterscheiden sich zwischen Profilen. Ohne Koordination wird ein paralleles Batch schnell zu 50 unabhängigen Skripten, die auseinanderdriften.
Ornold behandelt einen Batch von Browsern als ein einziges koordiniertes System. Jede Aktion — Navigation, Formularausfüllung, Klicks, CAPTCHA-Lösung — wird in allen aktiven Sitzungen gleichzeitig ausgeführt, mit integrierter Behandlung von Abweichungen und Fehlern.
Wie die parallele Ausführung in Ornold funktioniert
Wenn Sie einem KI-Agenten sagen "öffne google.com in allen Browsern", durchläuft Ornold nicht Sitzung für Sitzung. Es sendet den Navigationsbefehl parallel über CDP (Chrome DevTools Protocol) an alle aktiven Sitzungen. Das Gleiche gilt für Klicks, Formularausfüllungen, Screenshots und alle anderen Browseraktionen.
// This navigates ALL active sessions simultaneously
await browser_parallel_navigate({ url: "https://target.example/signup" });
// This fills the email field in ALL sessions at once
// Each session can get a different value
await browser_parallel_fill({
ref: "email",
values: profiles.map(p => p.email)
});
Das Präfix "parallel" in Werkzeugnamen ist nicht nur eine Namenskonvention — es spiegelt das tatsächliche Ausführungsmodell wider. Befehle werden an alle Sitzungen verteilt, gleichzeitig ausgeführt und Ergebnisse werden vor dem nächsten Schritt gesammelt.
Gruppierte Bildanalyse
Der schwierigste Teil der parallelen Automatisierung ist zu wissen, was auf jedem Bildschirm angezeigt wird. In einem Batch von 30 Browsern können einige das Anmeldeformular anzeigen, andere haben ein CAPTCHA und einige sind auf einem Ladebildschirm steckengeblieben. Sie müssen den Status jeder Sitzung kennen, bevor Sie entscheiden, was als Nächstes zu tun ist.
Die gruppierte Bildanalyse von Ornold löst dies, indem Screenshots von allen Sitzungen gemacht, als Batch analysiert und Sitzungen nach ihrem visuellen Status gruppiert werden:
// Analyze all sessions at once
const analysis = await browser_parallel_vision_analyze_grouped();
// Results are grouped by page state:
// group "signup_form": [session1, session2, ... session25]
// group "captcha": [session26, session27, session28]
// group "error_page": [session29]
// group "loading": [session30]
Dies unterscheidet sich grundlegend von der Überprüfung jeder Sitzung einzeln. Ein API-Aufruf gibt Ihnen das vollständige Bild. Der KI-Agent kann dann die Logik verzweigen: CAPTCHAs für die Sitzungen lösen, die es benötigen, Navigation für die fehlgeschlagenen wiederholen und den Fluss für die bereiten fortsetzen.
Gruppierte Analyse ist besonders wertvoll, wenn Seiten aufgrund von A/B-Tests, Geo-Targeting oder Bot-Erkennung auseinanderdriften. Anstatt anzunehmen, dass alle Sitzungen im gleichen Status sind, sehen Sie die tatsächliche Realität jeder einzelnen.
Begrenzte Parallelität
Das Ausführen von 50 Browsern in echter Parallelität klingt gut, bis Sie auf Ressourcengrenzen stoßen. Jede Browsersitzung verbraucht CPU, Speicher und Netzwerkbandbreite. Bildanalyseanrufe haben API-Ratenlimits. CAPTCHA-Lösungsdienste drosseln gleichzeitige Anfragen.
Ornold verwendet begrenzte Parallelität — es verarbeitet Sitzungen in kontrollierten Batches, anstatt alles auf einmal zu starten:
- Browseraktionen (Navigation, Klick, Ausfüllung) — Werden in allen Sitzungen gleichzeitig ausgeführt. Dies sind leichte CDP-Befehle, die keine Ressourcen belasten.
- Bildanalyse — In Gruppen verarbeitet (Standard: 12 auf einmal). Screenshots werden parallel aufgenommen, aber Analyseanrufe werden gebündelt, um innerhalb der API-Limits zu bleiben.
- CAPTCHA-Lösung — Anfragen werden parallel gesendet, aber der Lösungsdienst drosselt natürlich basierend auf Kapazität. Ornold verwaltet die Warteschlange.
- Screenshots — Gleichzeitig von allen Sitzungen erfasst. Bilddaten werden gestreamt, nicht im Speicher gepuffert.
// Control concurrency for vision analysis
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 12 });
// For very large batches, you can lower concurrency
// to reduce memory pressure
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 6 });
Statusverfolgung und Wiederherstellung
Bei jeder Batch-Operation schlagen einige Sitzungen fehl. Eine Seite lädt möglicherweise nicht, ein CAPTCHA läuft möglicherweise ab oder eine Formularübermittlung gibt möglicherweise einen Fehler zurück. Die Frage ist: Wie erkennen Sie Fehler und stellen wieder her, ohne den gesamten Batch neu zu starten?
Ornold bietet Echtzeit-Statusverfolgung für jede aktive Sitzung:
// Check the state of all sessions
const status = await browser_status();
// Returns per-session info:
// { id: "session-1", url: "https://target.example/dashboard", state: "ready" }
// { id: "session-2", url: "https://target.example/signup", state: "ready" }
// { id: "session-3", url: "about:blank", state: "error" }
Mit Statusdaten kann der KI-Agent Wiederherstellungsentscheidungen treffen:
- Sitzungen auf der falschen Seite — Erneut zur Ziel-URL navigieren
- Sitzungen mit CAPTCHA — CAPTCHA-Löser nur für diese Sitzungen ausführen
- Sitzungen mit Fehlern — Screenshot zur Diagnose machen, dann wiederholen oder überspringen
- Sitzungen, die voraus sind — Warten, bis langsamere Sitzungen aufgeholt haben, bevor die nächste Batch-Aktion
Sitzungen synchronisieren
Die größte Herausforderung bei der parallelen Automatisierung ist nicht, 50 Browser zu starten — es ist, sie synchron zu halten, während der Workflow fortschreitet. Verschiedene Seiten laden mit unterschiedlichen Geschwindigkeiten. Einige Sitzungen treffen auf Ratenlimits. Andere werden umgeleitet.
Ornold verwendet Wait-for-All-Semantik: Nach jeder parallelen Aktion wartet es, bis alle Sitzungen abgeschlossen sind (oder das Timeout abgelaufen ist), bevor es zum nächsten Schritt übergeht. Dies verhindert, dass schnelle Sitzungen langsame überholen.
// Navigate all sessions
await browser_parallel_navigate({ url: "https://target.example/signup" });
// Wait until all sessions show the signup form
await browser_parallel_wait_for({
text: "Create Account",
timeoutMs: 15000
});
// Only proceeds when ALL sessions are ready (or timed out)
// Now fill forms — all sessions are on the same page
await browser_parallel_fill({ ref: "email", values: emails });
Das Timeout in `wait_for` fungiert als Sicherheitsventil. Wenn eine Sitzung den erwarteten Status nicht innerhalb des Timeouts erreichen kann, wird sie gekennzeichnet, anstatt den gesamten Batch für immer zu blockieren.
Pro-Profil-Daten in Batch-Operationen
Parallel bedeutet nicht identisch. Jedes Browserprofil benötigt typischerweise eindeutige Daten — unterschiedliche E-Mail-Adressen, Namen, Passwörter oder andere Formularwerte. Ornold unterstützt Pro-Sitzungs-Werte in Batch-Befehlen:
// Each session gets its own email
await browser_parallel_fill({
ref: "email",
values: [
"user1@mail.com",
"user2@mail.com",
"user3@mail.com",
// ... one per active session
]
});
// Each session gets its own password
await browser_parallel_fill({
ref: "password",
values: profiles.map(p => p.password)
});
Das Werte-Array wird 1:1 auf aktive Sitzungen in Reihenfolge abgebildet. Wenn Sie 30 aktive Sitzungen haben, stellen Sie 30 Werte bereit. Dies behält das parallele Ausführungsmodell bei, während vollständige Pro-Profil-Anpassung ermöglicht wird.
Ein vollständiger paralleler Workflow
Hier ist ein realistischer End-to-End-Fluss für die Registrierung von Konten auf 30 Anti-Detect-Browser-Profilen:
// 1. Start sessions and navigate
await browser_list(); // See available profiles
await browser_parallel_navigate({ url: "https://target.example/signup" });
await browser_parallel_wait_for({ text: "Create Account", timeoutMs: 15000 });
// 2. Fill forms with per-profile data
await browser_parallel_fill({ ref: "email", values: emails });
await browser_parallel_fill({ ref: "password", values: passwords });
await browser_parallel_fill({ ref: "name", values: names });
// 3. Solve CAPTCHAs (detected and solved across all sessions)
await browser_solve_captcha();
// 4. Submit
await browser_parallel_click({ ref: "submit" });
// 5. Verify results
await browser_parallel_wait_for({ text: "Welcome", timeoutMs: 20000 });
const status = await browser_status();
// Check which sessions succeeded and which need recovery
Skalierungstipps
- Beginnen Sie mit 5-10 Sitzungen, um den Workflow zu validieren, dann skalieren Sie. Das Debuggen ist mit einem kleinen Batch viel einfacher.
- Verwenden Sie `browser_status()` nach jedem wichtigen Schritt. Nehmen Sie nicht an, dass alle Sitzungen im gleichen Status sind.
- Legen Sie angemessene Timeouts fest. Zu kurz und Sie erhalten falsche Fehler. Zu lang und steckengebliebene Sitzungen blockieren den gesamten Batch.
- Für Batches über 30, erwägen Sie, sie in Gruppen aufzuteilen und sequenziell auszuführen. Dies reduziert die Spitzenressourcennutzung.
- Überwachen Sie die Ressourcennutzung Ihres Anti-Detect-Browsers. Jedes Profil verbraucht RAM — 50 Chromium-Instanzen können leicht 16+ GB verwenden.
- Halten Sie die Proxy-Qualität konsistent. Gemischte Proxy-Qualität führt zu gemischten Seitenladezeiten, was Synchronisierungsprobleme verursacht.
Häufige Fallstricke
- Annahme, dass alle Sitzungen die gleiche Seite sehen — Das tun sie nicht. A/B-Tests, Geo-Targeting und Bot-Erkennung erzeugen Abweichungen. Überprüfen Sie immer mit `browser_status()` oder gruppierter Analyse.
- Keine Wiederherstellungslogik — Wenn Sie Fehler nicht behandeln, kann eine steckengebliebene Sitzung den gesamten Batch blockieren. Bauen Sie Wiederholungen und Skip-Logik ein.
- Ressourcenlimits ignorieren — 50 Browser + Bildanalyse + CAPTCHA-Lösung können einen Computer überlasten. Verwenden Sie begrenzte Parallelität.
- Sequenzielles Denken in einem parallelen System — Durchlaufen Sie Sitzungen nicht einzeln. Verwenden Sie die `browser_parallel_*`-Tools, um auf alle Sitzungen gleichzeitig zu wirken.
- Ergebnisse nicht validieren — Eine erfolgreiche Formularübermittlung bedeutet nicht, dass das Konto erstellt wurde. Validieren Sie immer den Endzustand.