跪拜 Guibai
← All articles
Frontend · JavaScript · AI Programming

How AI Agents Actually Drive a Browser: Accessibility Trees, Not Pixels

By 谭sir ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Understanding that agents drive browsers through accessibility trees — not pixels or raw DOM — explains why semantic HTML suddenly matters for AI reachability, why pure-text models can still automate the web, and where the real token costs hide in multi-step browser tasks.

Summary

Most AI agent CLIs default to a text-tree approach: the browser's built-in accessibility tree is pruned, numbered, and serialized into a compact YAML snapshot. The LLM reads that snapshot and issues tool calls referencing stable `ref=eNN` IDs, which Playwright resolves back to real DOM elements. Screenshot-and-coordinate mode is reserved for canvas, games, and visually-dependent targets where the tree is empty.

The loop is snapshot → select ref → operate → auto-return new snapshot. Old snapshots are collapsed to placeholders to keep token costs from ballooning across multi-step tasks. Browser tools are isolated in a sub-agent so the main agent's system prompt stays cacheable, and the MCP server starts lazily, reusing one browser instance per CLI session.

Visual fallback splits by provider: Anthropic gets inline images; other providers get a text caption generated by a borrowed vision model. Pure text models like DeepSeek work fine with the tree alone, making browser use viable without a multimodal model.

Takeaways
AI agents operate browsers in two modes: text tree with ref IDs (default) and screenshot with (x,y) coordinates (fallback).
The text tree is the browser's own accessibility tree, pruned of invisible and decorative nodes, then serialized to YAML with stable ref numbers.
Only visible, interactive elements get a ref; the LLM calls tools like `browser_click` using that ref, and Playwright resolves it to the real DOM element via an internal mapping table.
After any page-mutating operation, a fresh snapshot is automatically returned — the LLM never manually re-requests it.
Old snapshots and screenshots are replaced with a placeholder line before each LLM turn, keeping token usage flat instead of linear with step count.
Browser tools are isolated in a sub-agent so the main agent's system prompt stays byte-stable and hits provider prefix caches.
The MCP server starts lazily on first use; the connection and browser instance are cached for the CLI session.
Screenshots reach Anthropic models as inline images; for other providers, a separate vision model converts the screenshot to a text description first.
Canvas, WebGL, games, and div-based controls without ARIA produce empty or generic accessibility trees and require visual fallback.
CAPTCHAs, slider verifications, and MFA prompts still block automation — the LLM cannot solve them.
Conclusions

Browser automation for AI didn't require new infrastructure; it piggybacks on the accessibility tree that browsers have maintained for screen readers for over a decade.

The ref-numbering scheme is a clever indirection: the LLM operates on stable logical IDs while Playwright handles the messy DOM reality underneath, including detecting when an element has disappeared.

Sub-agent isolation isn't just architectural hygiene — it's a token-cost optimization. Keeping browser tools out of the main agent prevents system-prompt churn that would break prefix caching and raise per-request costs.

The split between Anthropic's inline-image path and the caption path for other providers reveals a real API fragmentation problem: most LLM APIs still can't handle images in tool results, forcing awkward workarounds.

Semantic HTML is now an AI-integration concern, not just an accessibility one. A div-based button without ARIA is invisible to an LLM driving the browser through the accessibility tree.

Token costs in browser use come primarily from snapshot size and accumulation, not from screenshots. A single dense page snapshot can be thousands of tokens, and multi-step tasks multiply that unless old snapshots are aggressively pruned.

Concepts & terms
Accessibility Tree
A semantic structure maintained by every major browser kernel, derived from the DOM, computed CSS, and ARIA attributes. Originally built for screen readers, it represents the page as a tree of roles (button, link, textbox) with names and states. AI agents reuse it as a clean, structured view of the page.
MCP (Model Context Protocol)
A unified protocol for exposing external tools to LLMs. An MCP server wraps capabilities (like Playwright's browser automation) into tools the LLM can call. @playwright/mcp is one such server that turns browser control into MCP tools.
CDP (Chrome DevTools Protocol)
The debugging protocol Chrome exposes to external tools. DevTools' own Inspect Element and Network panels run on CDP. Playwright uses CDP's Accessibility.getFullAXTree method to read the page's complete accessibility tree.
Prefix Cache
A provider-side optimization where repeated prompt prefixes are cached and subsequent requests are billed at a fraction of the original token cost. Dynamic tool registration can break prefix caching by altering the byte sequence of the system prompt.
Ref Numbering
Playwright's computeAriaRef function assigns stable e1, e2, e3 IDs to visible interactive elements during snapshot generation. A bidirectional mapping table (ref→DOM and DOM→ref) lets the LLM reference elements by logical ID while Playwright resolves them to real DOM nodes.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗