OVER\21551
9865a42f7a
- Replace 5 obsolete docs (advanced, architecture, security, sessions, stealth) with 6 new feature-aligned docs (agent-design, anti-blocking, browser-modes, concurrency, headless, remote-assist) - Refresh README.md with four-pillar pitch + And More section, drop outdated phrasing, sync agent compatibility list and security operations - Refresh docs/README.md as concise index aligned with new structure - Translation polish across all docs: remove unverifiable token claims, fix Chinglish phrasings, restore lost technical precision Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.6 KiB
Better Headless
Industry-standard headless browsers have two pain points: easy to detect and must switch back to headed when humans are needed. BrowserAct solves both at once.
Headless by Default — Why
BrowserAct runs headless by default:
- Doesn't disturb the user's current work — no browser windows popping up unexpectedly
- Minimal resource use — no UI rendering overhead, lower CPU/memory
- The way an agent should run — silent in the background, focused on the task
When you need local visualization for debugging, switch on --headed. In production, default headless.
Undetectable Headless
Industry pain point: Standard headless modes are flagged as bots — navigator.webdriver exposed, missing plugins, abnormal Canvas fingerprints, etc. This forces many teams to run headed just to defeat anti-scraping.
BrowserAct's approach: stealth browsers maintain full spoofing in headless mode:
- Fingerprint spoofing remains active in headless
- Navigator properties normalized
- TLS fingerprint matches a real browser
- Passes the common headless detection tests
Result: You don't sacrifice resource efficiency for stealth. Run headless and still pass most anti-scraping checks. Extreme anti-scraping sites may still detect — fall back to headed in that case (see below).
Better Headless: No Need to Switch When a Human Is Needed
Industry convention: Headless can't be seen → must switch to headed for the user → user's current work is disrupted, and production setups can't switch at all.
BrowserAct's approach: Generate a live URL via remote-assist while still in headless. The user opens it in any browser on any device to take over — no headed switch required.
See Remote Assist.
Headed vs. Headless
| Mode | When to use |
|---|---|
| Default headless | Production, autonomous agent runs, headless servers |
--headed |
Local debugging or when active visual observation is needed |
| headless + remote-assist | Best combination for production — silent by default, remote handoff when needed |
When to Use Headed
browser-act --session debug browser open <id> https://example.com --headed
Use cases:
- Anti-scraping detected — fall back to headed for higher fidelity
- Visually debug automation issues
- User completes manual steps, agent handles the rest
- Demos and co-browsing
Next Steps
- Remote Assist — The full handoff story for headless mode
- Anti-Blocking — How the undetectable stealth engine works
- Browser Modes — Pick the right browser