本地 LLM + Playwright：能不能讓 gemma4 自己瀏覽網頁？Local LLM Drives the Browser: Can gemma4 Navigate the Web?

This article uses Playwright + local Ollama gemma4 to build two versions of "extract verdicts from Resonance Stack": v1 hardcodes CSS selectors, v2 lets the LLM infer the selectors. Then I deliberately break the DOM and see which version still works.

Why Not Use the browser-use Framework?

browser-use is the most popular open-source framework right now, but it's overkill for a task as simple as "extract 6 cards" — it needs LangChain, LLM provider config, action space management.

I used the minimal approach: Playwright directly queries the DOM, Ollama steps in only when needed. Three layers:

1. Task: natural language ("extract all verdicts from Resonance Stack")
2. LLM reasoning: feed gemma4 an HTML snippet, ask it to infer CSS selectors
3. Playwright execution: use the LLM's selectors to extract data

The LLM here isn't the decision-maker — it's a translator, converting an uncertain DOM into Playwright-compatible selectors.

Two Versions: Hardcoded vs LLM-driven

Task: extract verdict, tag, and signature from 6 article cards into a markdown table.

v1 (scraper-style, ~100 lines):

cards = page.evaluate("""() => {
    return Array.from(document.querySelectorAll('article.card')).map(c => ({
        href: c.querySelector('a')?.getAttribute('href'),
        tag:  c.querySelector('.card__tag')?.textContent.trim(),
    }));
}""")

CSS selectors .card, .card__tag are hardcoded. Runs in 0.01 seconds.

v2 (LLM-driven, ~150 lines):

Feed the HTML snippet to gemma4: "Identify the CSS selectors for article cards. Return JSON." LLM returns {"card_selector": ".card", "link_selector": ".card__title a", "tag_selector": ".card__tag"}. Then Playwright uses those.

LLM reasoning takes 15–30 seconds, but every run looks at the current HTML — no hardcoded values.

What the v2 LLM Reasoning Looks Like

Feed the homepage .grid HTML (~3500 chars) to gemma4, with the instruction "Identify article card CSS selectors, return pure JSON."

After breaking the DOM, gemma4's response is particularly interesting:

{
  "card_selector": "article.tile-v2",
  "link_selector": ".card__title a",
  "tag_selector": ".pill"
}

Note: I renamed .card → .tile-v2 and .card__tag → .pill, but .card__title stayed. gemma4 correctly identifies which classes changed and which didn't — that's the LLM's common-sense reasoning at work.

Extracted Results

Both versions extracted 6/6 on the original DOM. The markdown table is directly usable:

Written to outputs/verdicts.md — directly usable for internal article references, social sharing, SEO summaries.

DOM Change Test: Speed vs Resilience

Using page.evaluate to inject JS, I renamed .card → .tile-v2 and .card__tag → .pill (simulating a real "site refactor" event). Then reran both versions:

The takeaway is clear: v1 is 1500× faster than v2, but dies on DOM changes. v2 is slow but still works the day the site refactors.

This comparison explains why browser agents have been hot: the real pain isn't "I can't extract data" — it's "I can extract data, but every site refactor breaks my code." v2 shifts the cost of "adapting to changes" from "engineer intervenes every time" to "auto-handled every run."

Local Model Comparison: e2b vs 12b

The original v2 experiment used gemma4:e2b (2B-class). When Gemma 4 12B landed I reran the same task — the comparison isn't "local vs cloud," it's "size trade-off within local." Reran on 2026-06-08; the homepage has since grown from 6 cards to 14, but the task shape is identical: feed the grid HTML snippet to the LLM, infer CSS selectors, let Playwright execute.

Two observations worth unpacking.

1. 12B pays a speed cost without a quality payoff

12B is 2.3-3.2× slower than e2b on this task. But both models tie at 100% extraction on both DOM states. For "which local model for a browser agent," the answer is clean: you don't need to upgrade to 12B for this. e2b suffices.

2. 12B picks more discriminating selectors

The link selector each model chose:

e2b used the broadest possible a — works, but would break on any site where cards contain multiple anchors. 12B reflexively added the ancestor qualifier (h3.headline or .card__title), which is robust against multi-link cards.

A genuinely interesting "same hit rate, different quality" case: 14/14 on both, but 12B's code is more durable. For a throwaway experiment (this one), e2b is plenty. For a long-running pipeline that needs to absorb unseen site structures, 12B's extra ~40s may earn its keep.

Takeaway: both work on this task. Don't choose a local LLM based on "browser agent needs" — this is one of the lightest tasks an LLM does. Size choice should be driven by other parts of your workflow (code generation, reasoning, long context).

Full comparison script and outputs: tests/scripts/browser_agent_v2_compare.py, tests/outputs/agent_v2_gemma4_12b_original.json, tests/outputs/agent_v2_gemma4_12b_broken.json.

Decision Framework: When to Use a Browser Agent

Choose v1 (scraper-style) when:

• You control the DOM (own site, internal tool)
• High frequency (daily, hourly) — LLM costs add up fast
• Fixed task (no shifting requirements)

Choose v2 (LLM-driven) when:

• Third-party site you don't control
• Low frequency (weekly, monthly) — slowness is acceptable
• Selectors are expected to change

Hybrid mode (use both):

• Try v1 first, fall back to v2 on failure
• Reasonable for real production systems

Not suitable when:

• Login required / cookie banners / multi-tab state — that's where you need a full agent framework like browser-use
• Multimodal understanding (read image to fill form) — local gemma4's vision isn't there yet