待翻译：Chrome Auto Browse: The Hard Part Isn't the AI

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

The gist Auto Browse, the Gemini 3 agentic mode Google started rolling out in Chrome on 28 January 2026, is rationed: 20 multi-step requests a day on Google AI Pro, 200 a day on AI Ultra. That ration is the most informative fact published about it, which I read as pricing the part that's genuinely expensive: re-deriving the entire plan on every single run. The hard problem in browser automation isn't language understanding, it's target resolution: deciding which node on the page is the button you meant. That problem is identical whether a model picks the node or a recorded macro replays a selector, and most of its failure modes report success rather than failing loudly. Agents and recordings answer the same question with opposite economics. An agent re-derives the target every run, so it needs no setup, handles one-off tasks, and degrades gracefully when a site is redesigned. A recording derives it once and replays for free, instantly and identically, until the page changes underneath it. On this page The model was never the hard part "Click the button" is five operations Four ways I've watched a click fail Two ways to answer the same question The case for Auto Browse, made properly The critic can't see the button What I'd actually want Twenty a day. That's how many multi-step Auto Browse requests a Google AI Pro subscription buys you, according to Google's own support page. AI Ultra gets 200 — on whichever AI Ultra you have. Since I/O in May 2026 there are two plans under that name, one at $99.99 a month and one at $200 after Google cut the old top tier from $250, and the support page quotes the same number for both. Set that against the demos. You type a sentence into Chrome and it goes and does the thing: researching flights across a range of dates, pulling tax documents out of a payroll portal, booking parking for an event, updating the recurring pet food order because the dog got older. Gemini 3 driving a real browser across real tabs, clicking, scrolling, typing into fields. Google started rolling it out in preview on 28 January 2026 on desktop and on 18 August finished bringing Gemini in Chrome to every Android user in the US, auto browse included for Pro and Ultra subscribers. Twenty a day. I don't read that as a billing decision. I read it as a confession, and the most informative thing anyone has published about how agentic browsing works. Something in that loop is expensive enough that Google would rather ration a flagship feature than absorb the cost, and it isn't the sentence you typed. The model was never the hard part Here's the assumption I want to argue with, and nearly everyone holds it: agentic browsing was blocked on the model. That we needed something clever enough to understand "book me parking near the arena," and once that arrived, the rest was integration work. Understanding was never the bottleneck. GPT-3.5 could parse that sentence in 2022. The hard part sits one level down, in the question nobody writes headlines about: which node on this page is the button? It's hard in a way that has nothing to do with intelligence, and a large language model asking it doesn't help. Chrome's Lighthouse audit flags a page's DOM as excessive above roughly 800 nodes in the body, and fails it above 1,400, and the sites you'd want an agent for are comfortably past both. I know the shape of this problem because I've been living in it. I build BumbleTap, a Chrome extension that binds keystrokes to actions on sites that never shipped them. The whole product is a machine for answering that one question, over and over, on pages I've never seen and don't control. The piece I've spent most time on is a resolver that captures a portfolio of representations for an element: id, data-testid, ARIA role, accessible name, a CSS path, an XPath, text content, position among siblings, coordinates. To find that element on a page that has since changed, it re-runs all of them, weights them, and lets them vote. That architecture exists because every one of them fails on its own, routinely. An agent takes a different route. It reads the page — accessibility tree, screenshot, or both, since Google has never said which — reasons over it, picks. Fresh, every run. A real advantage, and I'll defend it later. It is not an escape from the problem. It's an expensive subscription to it. "Click the button" is five operations The phrase hides a pipeline. In order: Find a node that matches the thing you meant. Confirm it's that node and not a lookalike. Confirm it's actionable: visible, in the viewport, not covered, not disabled, not a decorative wrapper around the real control. Act on it in a way the page's own handlers accept. Verify something changed. Five chances to be wrong, and four of them fail silently. That's why this eats months instead of an afternoon. Nothing throws. Your automation reports success and moves on, and the failure surfaces three steps later as something incomprehensible, or doesn't surface at all until a human notices the form was never submitted. Four of the five fail without raising anything. Only step four throws, which makes it the least dangerous place to be wrong. Here's where I lose people: a step that reports success without verifying it did anything is worse than one that fails loudly. Worse, not equivalent. A loud failure costs you five minutes. A false success costs you trust in the entire system, and you pay that bill later, at a worse moment, with less information. Four ways I've watched a click fail All four come from my own codebase. Each is target resolution wearing a different costume, and none of them cares whether a model or a macro is driving. The element changes shape when the window does. You capture a button at 1440px wide. At 900px the site swaps it for an icon button. Same function, same spot in the visual hierarchy, and almost nothing in common at the DOM level: the label text is gone, the class names are different, it may be a different tag inside a different container. Your captured representation matches nothing. And if you fall back to coordinates, they now point at a different control entirely. Worse than matching nothing. Mine was the Post button on X. Docked my side panel, which narrowed the viewport past the breakpoint, and the button collapsed from text to icon. What made it instructive: I'd captured the same button two different ways. The binding, made with the visual picker, kept working. The recorded macro didn't. The difference wasn't the matching algorithm, which was identical for both. It was which node each one had captured. The picker climbs from wherever you clicked to the nearest actionable ancestor, so it had stored the anchor element carrying data-testid and an ARIA label, both of which survive the collapse. The recorder had stored what the mouse was literally over: the inner holding the word "Post". At the narrower width that span doesn't exist. Every representation derived from it broke at once, the vote fell through to a low-weight positional match, and the click went to a hidden node in the collapsed nav. Green checkmarks, nothing happened. This one took me longest to accept as a category rather than a bug. The resolver had returned an element and the click dispatched without error, so every check in the pipeline passed. The element was hidden. Or it was the low-confidence winner of a vote where every candidate scored badly, and the resolver had no notion that "best available" and "correct" are different claims. A better matcher doesn't fix that. What fixes it is a confidence score the resolver has to report, an executor that refuses to act below a floor, and a post-condition check asking whether anything on the page changed. Double activation, which silently reverses every toggle. My favourite: the most time wasted for the dumbest reason. To make a click look real to a page's handlers, you dispatch the full sequence: pointerdown, mousedown, pointerup, mouseup, click. Then, for safety, you also call element.click(). That's two activations. // Vanilla JS, no libraries, running in an MV3 extension content script. function pressLikeAHuman(el) { const opts = { bubbles: true, cancelable: true, view: window }; el.dispatchEvent(new PointerEvent('pointerdown', opts)); el.dispatchEvent(new MouseEvent('mousedown', opts)); el.dispatchEvent(new PointerEvent('pointerup', opts)); el.dispatchEvent(new MouseEvent('mouseup', opts)); el.dispatchEvent(new MouseEvent('click', opts)); // activation 1 el.click(); // activation 2 } On a plain button, harmless. On anything stateful, catastrophic and invisible: the dropdown opens and closes inside the same frame, the checkbox ticks and unticks. Every symptom is identical to "the click didn't work." I spent weeks hunting a click that wasn't landing, when the click was landing twice. Part of what made it hard to see: my code runs in an isolated world with no access to the page's JavaScript, so I can't inspect the site's own handlers to count how many times they fired. I could only see the outcome, and the outcome of two activations looks exactly like the outcome of zero. What finally gave it away was an asymmetry I couldn't explain. A key binding fired on Bing's settings menu and the Appearance row expanded. The same row, same page, same resolver, driven by a recorded action, stayed shut. The screenshot is what did it: the row was wearing a focus ring, so the right element had unmistakably been found and touched, and the chevron was still pointing down. That killed the resolver theory. If two of my own code paths disagree about the same element on the same page, the disagreement can't be in the part they share. So I stopped debugging the click and diffed the two paths. One of them ended with a native element.click() after the full synthetic sequence, as a fallback for elements that ignore synthetic events. The other didn't. That was the whole bug: a fallback that always ran, which is not a fallback. Coordinates measured one call too early. Synthetic mouse events carry clientX and clientY, and some pages read them. So you measure getBoundingClientRect(), then focus the element, then dispatch. Except HTMLElement.focus() scrolls the element into view unless you opt out, so by the time your events fire, your coordinates describe where the element used to be. el.focus({ preventScroll: true }); // preventScroll defaults to false const r = el.getBoundingClientRect(); // measure after anything that shifts layout One boolean. Days to find, because the failure only appears when the element starts off-screen, which in testing it usually doesn't. Two ways to answer the same question Both approaches resolve the same target. They differ in when. An agent derives it fresh on every run. So it handles the responsive collapse without noticing it was a special case: an icon button that means "checkout" is still recognisably checkout to a model reading the page as it is now. It handles a redesign, and a site it has never seen. It degrades gradually instead of snapping. A recording derives it once and replays. So it costs nothing per run, finishes in milliseconds, and does the same thing every time. And it snaps the moment the page changes in a way the captured representations didn't anticipate. The tradeoff is clean, and neither side gets to be smug. What I object to is the framing where the agent has solved something. It hasn't. It pays full price for the answer every single time, which is why it's rationed. The economics push in one direction, permanently: reason as few times as you can get away with. So the interesting product is neither of these. It's the agent that works out the steps once and leaves behind a recording you can replay for free, with the model in reserve to repair the recording when it breaks. Reason once, replay a thousand times, re-reason on failure. Nobody has shipped a good version of that. I should be st [truncated for AI cost control]