Below is an organized overview of open-source options for browser automation, split into "general-purpose browser automation libraries" and "wrappers/environments closer to Agent (LLM) browser operation", with scenario-based recommendations.
1) General, mature open-source browser automation libraries (common foundations for Agents)
Playwright (recommended as an Agent foundation)
- Languages: Node.js / Python / Java / .NET
- Features: Cross-browser over Chromium/Firefox/WebKit; friendlier waiting and concurrency; strong locating (text/role/aria, etc.); supports trace, video, HAR.
- Agent-friendly points:
- Can access the DOM, take screenshots (for visual agents), and use ARIA/role for more stable locating (more robust than pure CSS).
- Common uses: web task automation, Agent tool calls, end-to-end flows.
- Languages: nearly full coverage (Python/Java/C#/JS/...)
- Features: based on the WebDriver standard; strong compatibility with various browsers/enterprise environments.
- Agent-friendly points: mature with abundant resources; but for modern SPAs and waiting/stability, it is usually less convenient than Playwright.
- Language: Node.js (community Python ports exist, but Node is the mainstay)
- Features: Chromium/Chrome first, via CDP; quick to get started.
- Agent-friendly points: very direct Chrome control; but cross-browser capability is weaker than Playwright.
- Features: rich plugins/ecosystem, suited to Node stacks; can integrate with Selenium Grid, etc.
- Agent-friendly points: a good choice if your Agent runs on Node and you want to reuse WebDriver infrastructure.
- Features: keyword-driven, suitable for wrapping "browser operations" into readable flows.
- Agent-friendly points: Agents generate/modify keyword scripts, which can be more controllable than writing code directly (depends on team preference).
- Positioning: gives LLMs/Agents a wrapper that "understands web pages and executes actions" (usually Playwright underneath).
- Strengths: closer to the "let the model browse the web itself" usage (automatic page information extraction, generating executable actions).
- Caveats: such projects iterate fast; stability/anti-scraping resistance depends on the specific version and site.
- Positioning: provide standardized environments/tasks/evaluation for "web task agents" (usually with browser control scripts).
- Strengths: well suited if you are doing Agent capability evaluation, training, benchmarks.
- Caveats: more research/environment-oriented, not necessarily production-grade RPA.
- Positioning: wrap Playwright/Selenium as Tools (e.g., "navigate / click / extract") for Agent calls.
- Strengths: quick to adopt if you already use these Agent frameworks; composable with other tools (search, databases, APIs, etc.).
- Caveats: quality varies across versions/components; many are still "thin wrappers" — core stability still depends on Playwright/Selenium.
- chrome-remote-interface (Node)
- pychrome (Python)
- Playwright/Puppeteer themselves already build heavily on CDP capabilities, so you generally don't need to add another layer.
- Want stability, generality, easy concurrency: prefer Playwright (then wrap it into your Agent's tool layer as needed).
- Already have Selenium infrastructure / strong enterprise browser compatibility requirements: choose Selenium/WebDriver.
- Chrome-only, CDP-based, Node stack: choose Puppeteer or CDP directly.
- Want an "out-of-the-box LLM browser Agent" experience: look at high-level wrappers like browser-use (but expect maintenance costs / site adaptation work).
Selenium (largest ecosystem)
Puppeteer
WebdriverIO (Node framework on WebDriver)
Robot Framework + SeleniumLibrary (RPA/test orchestration oriented)
2) Open-source wrappers/environments closer to "Agent operating a browser" (higher-level action abstractions)
> These usually sit on top of Playwright/Selenium and provide: higher-level actions (click/type/find element), page state extraction (DOM/accessibility tree/screenshots), and even tool interfaces prepared for LLMs.