agent-browser

エージェントブラウザって何？ ego lite・Claude・agent-browserを比べてみた こんにちは！ 私はAIスタートアップでカスタマーサクセスとして働いています。 最近、「エージェントブラウザ」という言葉をよく見かけるようになりました。会社では同僚のエンジニアの方にego liteを勧められ、提供しているサービスの検証をしたい時などに使用しています。爆速で検証が終わるのでとても便利でした。 lite.ego.app ただ、普段Claudeのデスクトップアプリを使用しているのですが、そこでClaude in Chromeが使えたり、Claudeアプリの中のもブラウザがあったので、同僚の方が結構な勢いでego liteを進める理由がわかりませんでした。 そこで調べてみることにしました。 1. エージェントブラウザって何？ AIエージェントが操作するためのブラウザだそうです。 ego liteや、Claudeアプリの中のブラウザがここに入ります。 Claude in Chromeはエージェントブラウザそのものではなく、ふだんのChromeをAIで操作できる拡張機能です。 AIが操作するためのブラウザとは ふつうのブラウザは、人が目で見てマウスで操作する前提ですが、エージェントブラウザには、AIが使いやすいように次のような工夫がされているそうです。 ページを文字の一覧にする：入力欄やボタンを抜き出して、AIが読める形で渡す 番号で操作できる：「e3 に入力」のように指示でき、座標やセレクタが要らない 外から命令できる：Claude Codeなどのエージェントが操作の指示を送れる 人の作業と分ける：AI用の作業場所を別に用意して、人のタブを動かさない 人が見張れる：操作中の画面を見たり、途中で止めたりできる なお、どこに何を入力するかを判断するのは、ブラウザではなくAIエージェント側です。 2. 4つのエージェントブラウザ等を比べてみた ツール 正体 操作するAI 動かすブラウザ ログイン状態 人の作業との関係 ego lite ブラウザ本体 外部のエージェント （Claude Code、Codexなど） ego lite内の別の作業場所（Space） Chromeから引き継げる 自分のタブとは分かれて並行 Claude in Chrome Chromeの拡張機能 Claude ふだんのChrome そのまま使える 同じChromeを使う Claudeアプリ内のブラウザ Claudeアプリの機能 Claude アプリ専用のブラウザ アプリ側で別に持つ アプリの中で見ながら代われる agent-browser コマンドで動く部品 外部のエージェント 別に立ち上がるブラウザ 基本は別 裏で動く Claude in Chrome：ふだんのChromeを、Claudeが操作する ふだんのChromeを使うので、ログイン済みのサービスもそのまま操作できます。 Claudeアプリ内のブラウザ：アプリの中の専用ブラウザ Claudeデスクトップアプリの地球儀アイコンから開くブラウザです。ふだんのChromeとは別のブラウザで、ログイン状態もアプリ側で別に持ちます。 Claudeが操作している画面を横で見られて、途中で自分が代わることもできます。人が頼む点ではClaude in Chromeと同じで、ふだんのブラウザと切り離して動く点ではagent-browserに近い、中間の位置づけです。 agent-browser：AIエージェントが使う部品 人が直接使うものではなく、Claude Codeなどのエージェントが作業の途中で呼び出す部品です。たとえばClaude Codeにアプリを作らせて、そのアプリが画面上で正しく動くかを確かめる、といった使い方をします。 ふだんのブラウザとは切り離して、基本は画面を出さずに裏で動きます。そのぶん、ログインが必要なサービスは、agent-browser側で改めてログインしてから操作します。 ego lite：ふだんのブラウザの中で、エージェントと並行作業 ego liteは、citrolabsという開発元が作っているブラウザです。Google Chromeと同じ仕組みを土台にしているので、見た目や使い心地はChromeに近いです。無料で使えて、中身（プログラム）も公開されています。今のところMac専用で、Windowsでは使えません。 ふだんのブラウザとして使いながら、Claude CodeやCodexなどの外部エージェントにも操作させられます。エージェントは「Space」という分かれた作業場所で動くので、自分が開いているタブには触りません。Chromeのログイン状態やCookie、拡張機能も引き継げるので、エージェントのために再ログインする必要がありません。複数のSpaceで、別々の作業を同時に進めることもできます。 つまりego liteは、「ログイン済みの環境は使いたい、でも自分のタブは邪魔されたくない」という悩みに向けたツールです。agent-browserは別ブラウザなのでログインし直しが必要で、Claude in Chromeは自分と同じChromeを使います。ego liteは、その間を埋める位置づけだとわかりました。 3. 結局、どう使い分ければいいの？ 違いがわかったところで、自分の仕事に当てはめて使い分けを考えてみました。 こんなとき 向いているもの 理由 ログイン済みの管理画面で、目の前の作業を手伝ってほしい Claude in Chrome ふだんのChromeをそのまま使える ふだんのChromeとは分けて、ログインが必要な作業も任せたい Claudeアプリ内のブラウザ 一度ログインすれば状態が残り、ふだんのChromeとぶつからない 開発中の画面が動くか、エージェント自身に確かめさせたい agent-browser エージェントがコマンドで呼び出せる ログインが必要な自社サービスの検証を、何パターンも並行して進めたい ego lite ログインを引き継いだまま、Spaceごとに並行で動かせる Claude in Chrome：ふだんの作業の延長で頼みたいとき たとえば、ログイン済みの管理画面からお客様の利用状況を集めてまとめてもらう、といった使い方です。自分が見ている前で1つずつ進めてもらう作業に向いています。 ただし、自分と同じChromeを使うので、Claudeが操作している間はそのChromeで別の作業をしにくくなります。 Claudeアプリ内のブラウザ：ふだんのChromeと分けて頼みたいとき たとえば、お客様の会社のWebサイトを調べて整理してもらったり、ログインが必要な管理画面で作業してもらったりする使い方です。ふだんのChromeとは別なので、自分の作業を邪魔されません。 ログイン状態はアプリ側で持つので、最初に一度アプリのブラウザでログインしておけば、次からはそのまま作業を頼めます。 agent-browser：エンジニアが開発の中で使うとき Claude Codeに画面を作らせて、そのままエージェント自身に動作確認までさせる、といった使い方です。人がチャットで頼む道具ではないので、CSの私が直接使う場面は少なそうです。 ego lite：ログインが必要な検証を、まとめて任せたいとき たとえば、自社サービスのテスト環境で「新規登録の流れ」「設定変更の流れ」「エラー時の表示」を、それぞれ別のSpaceでエージェントに同時に確かめてもらう、といった使い方です。Chromeのログイン状態を引き継げるので、エージェントのために毎回ログインする必要もありません。その間、自分は自分のタブで別の作業を続けられます。 ここで、同僚がego liteを勧めてくれた理由がわかった気がしました。私の使い方は、ログインが必要なサービスの検証です。この使い方だと、ログインを引き継げることと、複数の検証を並行して進められることが、そのまま「爆速で終わる」につながっていたのだと思います。 ! ego liteやClaude in Chromeのように、ログイン済みの環境をAIに操作させる場合は、誤操作したときの影響も大きくなります。本番環境ではなくテスト環境で使う、操作を任せるサイトを絞るなど、任せる範囲には注意が必要です！！ 4. agent-browserを例に、AIがブラウザを動かす流れを見てみる ところでエージェントブラウザは、どこにどのボタンがあるというのをどのように判断しているのでしょうか。 中の動きが一番わかりやすかったのが、agent-browserです。 結論からいうと、AIは画面を人間のように目で見ているわけではないそうです。agent-browserはHTMLをもとに画面の部品の一覧表を作り、そこに番号を振って、AIとの共通の認識を揃えているみたいな感じらしいです。AIは番号で「どこを操作するか」を伝え、agent-browserはその番号の部品を操作します。画面が変わったら一覧表を作り直し、番号も振り直します。 たとえばお問い合わせフォームにメールアドレスを入れて送信するとき、AIは裏でこんな命令を順番に送っています。 agent-browser open example.com agent-browser snapshot -i agent-browser fill @e3 "test@example.com" agent-browser click @e5 よくわからないのですが！！！！！やっていることは4つだけということです。 ページを開く（open） ページの部品の一覧表をもらう（snapshot） 一覧表を読んで、メールアドレス欄に入力する（fill） 送信ボタンを押す（click） 2で受け取る一覧表は、イメージとしてはこんな形です。入力欄やボタンに、e2 e3 のような番号が振られています。 - 入力欄「会社名」 → e2 - 入力欄「メールアドレス」 → e3 - ボタン「送信」 → e5 AIはこの一覧表を読んで、「メールアドレス欄は e3 だな」「送信ボタンは e5 だな」と判断します。あとは「e3 にこれを入力して」「e5 を押して」と番号で指示するだけです。 レストランにたとえると、agent-browserは番号付きのメニューを渡してくれる店員さんで、AIはメニューを読んで「3番ください」と注文するお客さんです。何を選ぶかを決めるのはお客さん（AI）で、店員さん（agent-browser）は注文どおりに動きます。 つまり、agent-browser自体が「ここはメールアドレス欄だ」と判断しているわけではありません。 agent-browserの役割：ページを一覧表にしてAIに渡すことと、AIが選んだ操作を実行すること AIエージェントの役割：一覧表を読んで、どこに何を入れるかを判断すること この役割分担は、ego liteやClaude in Chromeでも変わりません。 ５.終わりに エージェントブラウザのことがわかったので、業務に活用していこうと思います！！ 主に検証での使用が多いのですが、活用方法を広げていければと思います。 それとブラウザではなくパソコンをちょくで触れると最近流行りのagent-desktopも使ってみたいです！ 参考 citrolabs/ego-lite vercel-labs/agent-browser lilting.ch

Vercel's agent-desktop Lets Coding Agents Click Native Apps Without Moving Your Mouse - Book: AI Agents Pocket Guide - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- Your coding agent can now open Finder, read every button in the window as JSON, and click one by its ID, while your own pointer stays exactly where you left it. That is the pitch of agent-desktop, which Vercel Labs released as version 1.0.2 on October 30. The README calls it "Computer use for AI agents: read and operate desktop apps through the OS accessibility tree." It is a Rust CLI plus a C library, Apache-2.0, and it runs on macOS, Windows and Linux. It contains no model. It is pitched as computer use for any coding agent, and the agent drives it by running shell commands. What shipped, and when The builder's launch post went up on X at 23:48 UTC on October 30, according to CellCog. Vercel's Chris Tate then described it as "agent-browser, for your whole computer," a nod to Vercel's agent-browser, which does the same thing for web pages. Vercel CEO Guillermo Rauch shared it with "An agent on every desktop." The project is older than the launch: it started in February and later moved under the Vercel Labs organization, per ShiftDelete. Windows 10 1809+ support arrived in v0.10.0 on October 18, and v1.0.2 on October 30 added a docs site and made AGENTS.md the single instructions file for agents. MarkTechPost and AlexTech covered it the next day. The repo had about 6,900 stars on November 2, per its GitHub page. The docs list the floors: macOS 13 or later (Intel or Apple Silicon) through the AX API, Windows 10 1809 or later through UI Automation, and Ubuntu 24.04 or later through AT-SPI, on x64 and ARM64. How the loop works The tool does one step per call. Each command prints one JSON envelope and exits. The observe, act, verify loop lives in your agent. Adapted from the README: # setup npm install -g agent-desktop agent-desktop status agent-desktop skills get desktop # look: interactive elements, each with a ref agent-desktop snapshot --app Finder -i # act on a ref from that snapshot agent-desktop click @s8f3k2p9:e8 # look again to check it worked agent-desktop snapshot --app Finder -i The ref values above are the README's examples. Yours come from your own snapshot. Refs are tied to the snapshot that produced them: v0.10.0 removed bare refs like @e8, and the README says they now fail with INVALID_ARGS. If the UI changed, the call returns STALE_REF and the agent should snapshot again. If several windows match, AMBIGUOUS_TARGET lists candidate window IDs to pass with --window-id. Every error carries a disposition, and the README says to retry only when error.disposition.retry is safe. Put that rule in your agent's AGENTS.md or system prompt. Calls are headless by default. Per the README, ref actions go through the accessibility API "without moving the pointer or taking focus." A global --headed flag allows physical mouse and keyboard input when an app needs it. With several agents at once, each subagent gets its own colored overlay cursor, ShiftDelete reports, and actions that need the one physical pointer take turns. !An editorial illustration of a branching tree of interface nodes rising out of a desktop window, a small robot hand tapping one glowing orange node while a real mouse pointer rests untouched to the side The agent reads the app's accessibility tree and acts on one node by ref. Your pointer isn't part of it. The token numbers are the builder's own The project's headline argument against screenshot-based computer use is cost. Every figure for that so far comes from the project itself. The builder's posts report 273 tokens per look at Apple Maps when you snapshot one region, against 3,811 for the whole window, and a simulated 52-step task dropping from 198k tokens to 31k, as summarised by CellCog. AlexTech puts the skeleton mode's saving at 78% to 96% against full-tree dumps in Slack, VS Code and Notion, and calls these "self-reported figures not verified by third parties." CellCog also points out that there is no shared yardstick for these numbers yet. The technique behind the saving is in the README. You map a dense app shallowly first, then drill into the part you care about: agent-desktop snapshot --skeleton --app Slack -i --compact agent-desktop snapshot --root @s8f3k2p9:e3 -i --compact I haven't run agent-desktop myself, so I can only relay these numbers. If you try it, count tokens on your own app. Slack and Notion are not your internal Electron tool. What it can't see The docs are blunt about the limits. It reads accessibility trees and does not match pixels, so a UI that publishes no accessibility tree is invisible to it. How well it works depends on how well each app's interface is built. It also does not automate web pages. For those, use agent-browser. For web content inside a Chromium or Electron app, agent-desktop opens a DevTools port that agent-browser can connect to. The CLI has 60 command names, the same on every platform. Four of them (key-down, key-up, mouse-down, mouse-up) fail closed everywhere. And a successful action does not prove the UI changed, which is why the docs recommend a follow-up read such as wait --element ... --predicate value. !An editorial illustration of a magnifying glass over a desktop window split in two: the left half shows a neat tree of nodes, the right half is a blank black panel with no structure for the lens to find No accessibility tree, no view. Pixel-only UIs stay out of reach. Before you hand it to an agent A few things in the docs are worth settling before the first run. Who gets the permission. On macOS the Accessibility permission goes to the app that runs agent-desktop. If your agent runs in a terminal, that terminal is the app asking, so decide on purpose which one gets it. agent-desktop permissions --guide walks you through it, and the README also requires TMPDIR to be owned by you with mode 0700. On Windows no grant is needed for apps at your terminal's integrity level. What ends up in transcripts. The README warns that "Snapshots, clipboard reads, screenshots, command output and debug artifacts can contain private desktop content." The FAQ goes further: "redaction does not make a screenshot safe to publish." Your agent's transcript now holds whatever was on screen, so treat it like a log with secrets in it. What leaves the machine. The FAQ says the native CLI "does not require a remote model service." The optional JEV helper is different: it sends goals and screen descriptions to the model provider you configure. What git won't show you. A click in Finder leaves no diff. Keep desktop actions on a short leash: name the app, name the task, and use --headed only when headless fails. I build Hermes IDE, so weigh this with that in mind. Hermes runs each agent in a real terminal, so an agent there can call agent-desktop like any other CLI. But Hermes, by its README, "observes what agents report on purpose and what git shows." Its Review Desk can show you every file an agent changed, turn by turn. It cannot show you what the agent clicked in another app. Would you give it your desktop? A cheap first test: point your agent at one app, let it run snapshot only, and read what comes back before it gets to click anything. Which native app would you trust an agent to drive first, and which one would you never hand over? Tell me in the comments. --- If this was useful agent-desktop is a tool, and the interesting design work sits in the loop around it: when to look again, when a retry is safe, when to stop and ask. That loop is what the AI Agents Pocket Guide is about, from tool calling to guardrails for agents that act on their own. If you run more than one coding agent, Hermes IDE is free, source-available and on macOS, Windows and Linux, and the code is on GitHub. 

Browser agent screenshots can be hard to match to actions. In Chrome, agent-browser's screenshot --annotate numbers interactive controls. Label [2] maps to @e2 in its commands, so the image and action use the same reference. vercel-labs/agent-browser

Playwright docs say dispatch_event('click') equals element.click(). On a disabled button it didn't. --- title: "Playwright docs say dispatch_event('click') equals element.click(). On a disabled button it didn't." published: true description: "Four ways to click from a Playwright script, run against a disabled, a hidden and an off-screen button. On the disabled one, dispatch_event ran the onclick and element.click() did not." tags: playwright, testing, ai, webdev series: Agents vs the Web --- We gave a script one simple task: press three buttons on a tiny signup form. A disabled "Continue", a "Create account" pushed 5000px off-screen, and a "Next" with visibility:hidden. A mouse user can press none of them. Playwright's Locator docs say dispatch_event("click") "is equivalent to calling element.click()". On the disabled button they behaved differently. dispatch_event ran the button's onclick. element.click() did not. In our run (playwright-python 1.64.0, Chromium 156), the four calls gave three different outcomes on the same disabled button, and two of them returned normally while its onclick never ran. If a test or an agent tool counts "no exception" as "the click worked", it can pass when nothing happened, and pass when a handler ran that no user could trigger. Why this matters for agent tools An agent tool that clicks through dispatch_event or a JavaScript element.click() hands the model whatever that call does. We have not checked which tools use which. We did see the effect in one of them earlier the same day: agent-browser (its package.json calls it a "Browser automation CLI for AI agents"), driven by fixed commands, which makes that run a script. Version 0.39.1 printed ✓ Done with exit code 0 on all three buttons, and document.title stayed empty, so no onclick ran. Version 0.39.2 refused all three with a reason, for example Element '#cont' is disabled, so the click would not reach it. That change came in PR #2173. An agent that reads "Done" plans its next step on a page that never changed. So we checked what plain Playwright does with the same buttons. The setup The test page. Save it as exp3-page.html, since the script loads it by that name: <!doctype html><html><body><h1>Sign up</h1> <form onsubmit="return false"><input aria-label="Email" value="a@b.co"> <button id="cont" disabled onclick="document.title='clicked-disabled'">Continue</button> <button id="off" style="position:absolute;left:-5000px" onclick="document.title='clicked-off'">Create account</button> <button id="hid" style="visibility:hidden" onclick="document.title='clicked-hidden'">Next</button></form></body></html> Every onclick writes to document.title, so an empty title after the call means the handler did not run. The script opens a fresh page for each button and method, tries one click with a 2 second timeout, and records whether the call raised and what the title became. There is no LLM in the loop. This is the exact file we ran: # exp6: same 3 unclickable buttons (exp3-page.html), 4 ways to "click" in Playwright (Python). # For each: did the call report success (no exception) and did the onclick actually run (document.title)? import json, pathlib, datetime, playwright from playwright.sync_api import sync_playwright page_url = pathlib.Path("exp3-page.html").resolve().as_uri() methods = { "click()": lambda l: l.click(timeout=2000), "click(force=True)": lambda l: l.click(force=True, timeout=2000), "dispatch_event('click')": lambda l: l.dispatch_event("click", timeout=2000), "evaluate(el.click())": lambda l: l.evaluate("e => e.click()", timeout=2000), } res=[] with sync_playwright() as p: b=p.chromium.launch() for bid in ["cont","off","hid"]: for name,fn in methods.items(): pg=b.new_page(); pg.goto(page_url) err=None try: fn(pg.locator("#"+bid)) except Exception as e: err=str(e).splitlines()[0][:160] title=pg.title() res.append({"button":bid,"method":name,"reported_success":err is None,"onclick_ran":title.startswith("clicked"),"title":title,"error":err}) pg.close() ver=b.version; b.close() out={"run_at":datetime.datetime.now().astimezone().isoformat(),"tool":"playwright-python "+__import__("importlib.metadata").metadata.version("playwright"),"chromium":ver,"page":"exp3-page.html","kind":"SCRIPT, no LLM","results":res} json.dump(out,open("exp6-results.json","w"),indent=1) for r in res: print(r["button"],"|",r["method"],"| success:",r["reported_success"],"| onclick ran:",r["onclick_ran"],"|",r["error"] or "") We ran it twice and got identical results both times. Results | Button | click() | click(force=True) | dispatch_event("click") | evaluate(e => e.click()) | |---|---|---|---|---| | disabled | timeout, no run | returned, no run | returned, ran | returned, no run | | off-screen (left:-5000px) | timeout, no run | error: outside of the viewport | returned, ran | returned, ran | | visibility:hidden | timeout, no run | returned, no run | returned, ran | returned, ran | "Returned" means the call finished without an exception. "Ran" means the onclick changed the title. We measured only the onclick, not which input events reached the page. What each column shows click() waits for Playwright's actionability checks (visible, stable, receives events, enabled). It raised Timeout 2000ms exceeded on all three buttons. click(force=True) disables what the docs call the non-essential actionability checks. On the disabled and hidden buttons it returned normally and nothing ran, which is what a real user would also get from those buttons. A test that only checks for "no exception" passes here. On the off-screen button force still raised Element is outside of the viewport. dispatch_event("click") fires a DOM event at the element. The docs say it is dispatched regardless of visibility, which matches the hidden and off-screen rows. The disabled row is the one that contradicts "equivalent to element.click()": the onclick ran. evaluate(e => e.click()) is plain JavaScript run through Playwright's evaluate. It ran the handler on the hidden and off-screen buttons and did nothing on the disabled one. Limitations - The off-screen button is still focusable, so a keyboard user could probably Tab to it. We did not test that. The disabled and hidden buttons are the ones no user can press. - We only detected the onclick through document.title. Form submission and other side effects were not checked. - Playwright's dispatch_event creates the event and dispatches it on the element. Whether a disabled button's listeners then fire is up to the browser, so Firefox and WebKit may give a different disabled row. We only ran Chromium. - One synthetic page, one Chromium build, one Playwright version. - There is no test runner and no assertions in this run, only calls that did or did not raise. FAQ Does Playwright force=True click a disabled button? The call returned without an error in our run, and the button's onclick did not run. Is dispatch_event("click") the same as a user click? Not on a disabled button in Chromium: it ran an onclick that no user could trigger, and element.click() on the same button ran nothing. What we changed in our own checks 1. Assert on what the click should cause: a URL, a title, a network request, a new element. With Playwright's expect, for example expect(page).to_have_title("Welcome"), or page.wait_for_url(...). 2. Treat force=True, dispatch_event and evaluate(... .click()) in a user-flow test as a review question. Each one removes part of what makes the test mean "a person could do this". 3. If you build tools for agents, return what changed on the page after the action. agent-browser 0.39.2 refuses the click and gives the reason, and that reason is something the model can act on. The page and script above are the full repro. If your browser or Playwright version gives a different table, we'd like to see it in the comments. --- I write these while building BotFumble, a tool for seeing where AI agents get stuck on real signup and checkout flows. It is not live yet.

@AlexReibman vercel-labs/agent-browser is the meta.

@mykhailhe agent-browser has screenshot diffs against a saved baseline. that gives the runbook a before and after image to review without bringing back a full e2e suite vercel-labs/agent-browser

@apoorvdarshan @0xSero depends which setup you mean browser use offers a full agent loop and a cli while agent-browser is a browser cli for an existing agent i would compare the same model on the same tasks browser-use/browser-use vercel-labs/agent-browser

agent-browser: Browser automation CLI for AI agents (44k stars) What it does All text below is quoted directly from the project README. >Browser automation CLI for AI agents. Fast native Rust CLI. Security: - Authentication Vault: Store credentials locally (always encrypted), reference by name. The LLM never sees passwords. - Plugin System: Extend agent-browser with external executable plugins. - Content Boundary Markers: Wrap page output in delimiters so LLMs can distinguish tool output from untrusted content: --content-boundaries - Domain Allowlist: Restrict navigation to trusted domains (wildcards like *.example.com also match the bare domain): --allowed-domains "example.com,*.example.com". - Action Policy: Gate destructive actions with a static policy file: --action-policy ./policy.json - Action Confirmation: Require explicit approval for sensitive action categories: --confirm-actions eval,download - Output Length Limits: Prevent context flooding: --max-output 50000 >Installs the native Rust binary: npm install -g agent-browser then agent-browser install (Download Chrome from Chrome for Testing, first time only) Repository vercel-labs/agent-browser Repository stats |Metric|Value| |:-|:-| |Stars|44,065| |Forks|2,991| |Last release|v0.39.1 (2026-10-13)| |Languages|Rust 89.3%, TypeScript 8%, JavaScript 1.5%| |Contributors|152| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|Copilot: 2, claude: 49| |AI co-authored commits|Claude: 50, Copilot: 3| Main contributor |Field|Value| |:-|:-| |Name|Chris Tate| |GitHub|@ctate| |Commits to this repo|423 (top contributor)| |Bio|Dev @Vercel| |Company / Location|Vercel / Austin, TX| |Website|ctate.dev| |X / Twitter|@ctatedev| |Followers|2515| |Public repos|154| |On GitHub since|2010-08-16| --------------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free

I forked Chromium with Claude Code to solve my browser automation issues I use Claude Code for a lot of browser work. Mainly tools I need that were never built for agents, smoke-testing my work and searching the web for things I care about. What I struggled with: - chrome-devtools-mcp likes to open throwaway instances and profiles, and rarely cleans them up. - "Allow remote debugging?" prompts on every connect (when using --autoConnect). - "Chrome is being controlled by automated test software" on top of every page. - A dozen windows and no idea which tab belonged to which session, or whether I could close it. - Agents stepping on each other by taking over each other's tabs. --isolated solves that, but doesn't persist logins. - Gigabytes of RAM with multiple chrome-devtools-mcp processes (about 270 MB each) and chrome instances. Often upwards of 4GB. - I tried various Cloud browser services, but most are unreliable and/or expensive. And most sites get blocked by bot detection due to non-residential IP address. I forked Chromium and I call it Shuttle: - Every agent is a named identity (name, color, avatar) with its own storage. My agents log in once, and stay logged in. - Agents get their own control plane: create agent profiles, sessions and tabs over MCP. - MCP server is built in (http, loopback-only by default). So no middle-man needed. - Every agent works in its own tab group in your window, color-coded. This is the biggest UX improvement for me, as I can clearly see what each agent is doing. - No DX friction: no debugging dialog, no automation bar, navigator.webdriver is false, and no window pops up until an agent needs one. - Clean & minimal surface: 12 browser tools + 24 page tools. Vercel's awesome agent-browser is bundled in, so tool calls are directly controlling the browser. - Per-session CDP endpoints for Playwright if needed, e.g. for scripted e2e tests. - Meticulously removed bloat from Chromium: Google sign-in, Profile Sync, Telemetry, Google AI features, Translate, Password manager, Chrome Apps, Bookmarks, and many more. How it was built: - ~43 fork commits over two weeks, mostly written by Claude Code. Chromium itself is well maintained, so most of my own code and review effort went into my own additions (MCP server, agent model, the removal batches). - Five agents (mostly Opus 5.5 and Fable 5.1) across three devices (Mac, Linux, Windows/WSL2), with lead agent curating sessions; handoff workflow keeping sessions mostly under 300k context size (my personal sweet spot). - Removal done as scout → 3–5 surgery sub-agents per batch with a strict keep-list (biggest batch: 5,572 files, 1.18M lines in one commit). - Fable/Astra adversarial reviews before every commit. - Recent Chromium 155 merge was the real test for maintenance: 453 conflicted files, zero after 20 minutes with 5 parallel sub-agents... but then a full day of builds (still painful). Site: shuttlebrowser.com >!Beware: Some humor and easter eggs hidden on this site.!< Code: shuttle-browser/shuttle Regarding Stealth/Bot-detection: Shuttle isn't per se an anti-detection browser. However, it does work closer to a "human operated browser", as Agents are treated like "real human operators". If you're looking for a solution to crawl millions of linkedin profiles or scrape reddit posts at scale, this is not for you. But if you like to operate websites "like reasonable humans", you're good. Disclosure: I'm promoting my own tool. It's free and open source (BSD-3). I hope others use it, like it, and share their feedback and ideas with me.

agent-browser GitHub Explained: Visual Regression Beyond DOM Checks agent-browser by vercel-labs: vercel-labs/agent-browser Can an AI browser agent tell whether a UI change is acceptable? This overview uses agent-browser as a source-grounded lens on visual regression for QA architects, frontend teams, and builders of AI browser workflows. It contrasts accessibility-tree snapshots with rendered pixels, then maps the conditions for repeatable visual evidence: fixed viewport geometry, full-page capture limits with internal scrolling, semantic readiness signals, RGBA pixel-change ratios, and rendering noise from fonts, hardware compositing, and dynamic content. It also shows why a 1% threshold can filter noise yet miss a 0.5% three-pixel checkout shift, while a 15% intentional color update looks severe. The conclusion is practical: automation can collect and annotate evidence, but human reviewers must decide whether a change matches product intent. TimeStamps: 0:00 Accessibility Trees vs Rendered Reality 1:32 Why Visual Baselines Need Control 2:54 Viewport Geometry and Full-Page Limits 4:08 Semantic Readiness Beats Network Idle 5:20 RGBA Pixel Diffs and Change Ratios 5:43 Rendering Noise and LLM Token Cost 6:28 Thresholding Visual Changes 7:07 Heatmaps Cannot Supply Meaning 7:36 Intentional Color Update vs Hidden Layout Bug 8:27 Automation Ends at Human Review 8:49 Annotated Evidence for QA Teams 9:10 Repeatable Pipelines, Human Decisions 9:36 What agent-browser Can and Cannot Judge 🧭 Accessibility trees show structure, not visual usability 🖼️ Baselines depend on viewport and page readiness 📊 Thresholds reduce rendering noise and token cost 👁️ Human review decides whether changes are acceptable The practical takeaway for visual regression testing is not full autonomy. agent-browser can standardize capture conditions, compare screenshots, suppress low-value noise, and connect anomalies to accessible elements. It still needs product context to separate an approved redesign from a real usability regression. Use the evidence to focus review where it matters, not to replace review. #AgentBrowser #VisualRegression #BrowserAutomation [de-DE] agent-browser GitHub erklärt: Visuelle Regression jenseits von DOM-Prüfungen agent-browser von vercel-labs: vercel-labs/agent-browser Kann ein KI-Browser-Agent beurteilen, ob eine UI-Änderung akzeptabel ist? Diese Übersicht nutzt agent-browser als quelloffene Analysemethode für visuelle Regression und richtet sich an QA-Architekten, Frontend-Teams und Entwickler von KI-Browser-Workflows. Sie vergleicht Momentaufnahmen von Accessibility-Trees mit gerenderten Pixeln und analysiert die Bedingungen für reproduzierbare visuelle Nachweise: feste Viewport-Geometrie, Begrenzung der Vollbildaufnahme mit internem Scrollen, semantische Bereitschaftssignale, RGBA-Pixeländerungsverhältnisse und Rendering-Rauschen durch Schriftarten, Hardware-Compositing und dynamische Inhalte. Außerdem wird gezeigt, warum ein Schwellenwert von 1 % zwar Rauschen filtern kann, aber eine Änderung von 0,5 % (drei Pixel) beim Checkout übersieht, während eine beabsichtigte Farbänderung von 15 % als gravierend wahrgenommen wird. Die Schlussfolgerung ist praxisorientiert: Automatisierung kann zwar Nachweise sammeln und annotieren, aber menschliche Prüfer müssen entscheiden, ob eine Änderung der Produktabsicht entspricht. Zeitstempel: 0:00 Barrierefreiheitsbäume vs. gerenderte Realität 1:32 Warum visuelle Baselines kontrolliert werden müssen 2:54 Viewport-Geometrie und Seitenbegrenzungen 4:08 Semantische Bereitschaft schlägt Netzwerk-Leerlauf 5:20 RGBA-Pixel-Differenzen und Änderungsraten 5:43 Rendering-Rauschen und LLM-Token-Kosten 6:28 Schwellenwertsetzung für visuelle Änderungen 7:07 Heatmaps liefern keine aussagekräftigen Daten 7:36 Gezielte Farbaktualisierung vs. versteckter Layout-Fehler 8:27 Automatisierung endet mit der menschlichen Überprüfung 8:49 Annotierte Nachweise für QA-Teams 9:10 Wiederholbare Pipelines, menschliche Entscheidungen 9:36 Was Agent-Browser beurteilen kann und was nicht 🧭 Barrierefreiheitsbäume zeigen die Struktur, nicht die visuelle Benutzerfreundlichkeit. 🖼️ Baselines hängen von der Viewport- und Seitenbereitschaft ab. 📊 Schwellenwerte reduzieren Rendering-Rauschen und Token-Kosten. 👁️ Die menschliche Überprüfung entscheidet, ob Änderungen relevant sind. Akzeptabel Die wichtigste Erkenntnis aus visuellen Regressionstests ist, dass sie keine vollständige Autonomie bieten. Agent-Browser kann Aufnahmebedingungen standardisieren, Screenshots vergleichen, irrelevante Störungen unterdrücken und Anomalien mit zugänglichen Elementen verknüpfen. Dennoch benötigt er den Produktkontext, um eine genehmigte Überarbeitung von einer tatsächlichen Usability-Regression zu unterscheiden. Nutzen Sie die Ergebnisse, um die Überprüfung auf die relevanten Punkte zu fokussieren, nicht um sie zu ersetzen. #AgentBrowser #VisuelleRegression #Browserautomatisierung [es-US] agent-browser de GitHub explicado: Regresión visual más allá de las comprobaciones del DOM Agent-browser de vercel-labs: vercel-labs/agent-browser ¿Puede un agente de navegador con IA determinar si un cambio en la interfaz de usuario es aceptable? Esta descripción general utiliza Agent-browser como una herramienta basada en el código fuente para analizar la regresión visual, dirigida a arquitectos de control de calidad, equipos de desarrollo frontend y creadores de flujos de trabajo de navegadores con IA. Compara instantáneas del árbol de accesibilidad con píxeles renderizados y, a continuación, describe las condiciones para obtener evidencia visual reproducible: geometría fija de la ventana gráfica, límites de captura de página completa con desplazamiento interno, señales de preparación semántica, índices de cambio de píxeles RGBA y ruido de renderizado proveniente de fuentes, composición de hardware y contenido dinámico. También muestra por qué un umbral del 1 % puede filtrar el ruido, pero pasar por alto un cambio de tres píxeles del 0,5 % en la página de pago, mientras que una actualización de color intencional del 15 % puede parecer excesiva. La conclusión es práctica: la automatización puede recopilar y anotar evidencia, pero los revisores humanos deben decidir si un cambio se ajusta a la intención del producto. Marcas de tiempo: 0:00 Árboles de accesibilidad vs. realidad renderizada 1:32 Por qué es necesario controlar las líneas base visuales 2:54 Geometría de la ventana gráfica y límites de página completa 4:08 La preparación semántica supera la inactividad de la red 5:20 Diferencias de píxeles RGBA y tasas de cambio 5:43 Ruido de renderizado y costo del token LLM 6:28 Umbralización de cambios visuales 7:07 Los mapas de calor no aportan significado 7:36 Actualización de color intencional vs. error de diseño oculto 8:27 La automatización termina con la revisión humana 8:49 Evidencia anotada para equipos de control de calidad 9:10 Pipelines repetibles, decisiones humanas 9:36 Qué puede y qué no puede juzgar el agente-navegador 🧭 Los árboles de accesibilidad muestran la estructura, no la usabilidad visual 🖼️ Las líneas base dependen de la ventana gráfica y la preparación de la página 📊 Los umbrales reducen el ruido de renderizado y el costo del token 👁️ La revisión humana decide si Los cambios son aceptables. La conclusión práctica para las pruebas de regresión visual no es la autonomía total. AgentBrowser puede estandarizar las condiciones de captura, comparar capturas de pantalla, suprimir el ruido de bajo valor y vincular las anomalías con elementos accesibles. Aun así, necesita el contexto del producto para diferenciar un rediseño aprobado de una regresión de usabilidad real. Utilice la evidencia para enfocar la revisión donde importa, no para reemplazarla. #AgentBrowser #VisualRegression #BrowserAutomation [fr-FR] agent-browser GitHub expliqué : régressions visuelles au-delà des contrôles du DOM Agent-browser par vercel-labs : vercel-labs/agent-browser Un agent de navigateur IA peut-il déterminer si une modification d'interface utilisateur est acceptable ? Cet article utilise agent-browser comme outil d'analyse de régression visuelle, basé sur le code source, pour les architectes QA, les équipes front-end et les concepteurs de flux de travail de navigateur IA. Il compare les instantanés de l'arbre d'accessibilité avec les pixels rendus, puis définit les conditions d'une preuve visuelle reproductible : géométrie fixe de la fenêtre d'affichage, limites de capture de la page entière avec défilement interne, signaux de disponibilité sémantique, ratios de changement de pixels RGBA et bruit de rendu provenant des polices, de la composition matérielle et du contenu dynamique. Il explique également pourquoi un seuil de 1 % peut filtrer le bruit tout en ne détectant pas un décalage de trois pixels de 0,5 % au niveau de la page de contrôle, tandis qu'une mise à jour intentionnelle de la couleur de 15 % paraît importante. La conclusion est pratique : l'automatisation peut collecter et annoter les preuves, mais il appartient à des examinateurs humains de décider si une modification est conforme à l'intention du produit. Horodatage : 0:00 Arbres d’accessibilité vs Réalité rendue 1:32 Pourquoi les références visuelles doivent être contrôlées 2:54 Géométrie de la fenêtre d’affichage et limites de la page entière 4:08 La disponibilité sémantique prime sur l’inactivité du réseau 5:20 Différences de pixels RGBA et ratios de changement 5:43 Bruit de rendu et coût des jetons LLM 6:28 Seuil des changements visuels 7:07 Les cartes thermiques ne peuvent pas fournir de sens 7:36 Mise à jour intentionnelle des couleurs vs bug de mise en page caché 8:27 L’automatisation s’arrête à la vérification humaine 8:49 Preuves annotées pour les équipes d’assurance qualité 9:10 Pipelines reproductibles, décisions humaines 9:36 Ce que le navigateur agent peut et ne peut pas juger 🧭 Les arbres d’accessibilité montrent la structure, pas l’utilisabilité visuelle 🖼️ Les références dépendent de la fenêtre d’affichage et de la disponibilité de la page 📊 Les seuils réduisent le bruit de rendu et le coût des jetons 👁️ Humain L'évaluation détermine si les modifications sont acceptables. En pratique, les tests de régression visuelle n'offrent pas une autonomie totale. L'agent-navigateur peut standardiser les conditions de capture, comparer les captures d'écran, supprimer les bruits parasites et relier les anomalies aux éléments accessibles. Il a néanmoins besoin du contexte produit pour distinguer une refonte approuvée d'une véritable régression d'utilisabilité. Utilisez ces éléments pour cibler l'évaluation là où c'est important, et non pour la remplacer. #AgentBrowser #VisualRegression #BrowserAutomation [hi] agent-browser GitHub की व्याख्या: DOM जाँच से परे विज़ुअल रिग्रेशन vercel-labs द्वारा agent-browser: vercel-labs/agent-browser क्या कोई AI ब्राउज़र एजेंट यह बता सकता है कि कोई UI परिवर्तन स्वीकार्य है या नहीं? यह अवलोकन QA आर्किटेक्ट्स, फ्रंटएंड टीमों और AI ब्राउज़र वर्कफ़्लो के निर्माताओं के लिए दृश्य प्रतिगमन पर आधारित एक स्रोत-आधारित लेंस के रूप में agent-browser का उपयोग करता है। यह एक्सेसिबिलिटी-ट्री स्नैपशॉट की तुलना रेंडर किए गए पिक्सेल से करता है, फिर दोहराए जाने योग्य दृश्य प्रमाण के लिए स्थितियों को मैप करता है: निश्चित व्यूपोर्ट ज्यामिति, आंतरिक स्क्रॉलिंग के साथ पूर्ण-पृष्ठ कैप्चर सीमाएँ, सिमेंटिक तत्परता संकेत, RGBA पिक्सेल-परिवर्तन अनुपात, और फ़ॉन्ट, हार्डवेयर कंपोजिटिंग और गतिशील सामग्री से रेंडरिंग शोर। यह यह भी दर्शाता है कि क्यों 1% सीमा शोर को फ़िल्टर कर सकती है लेकिन 0.5% तीन-पिक्सेल चेकआउट शिफ्ट को अनदेखा कर देती है, जबकि 15% जानबूझकर किया गया रंग अपडेट गंभीर दिखता है। निष्कर्ष व्यावहारिक है: स्वचालन साक्ष्य एकत्र और एनोटेट कर सकता है, लेकिन मानव समीक्षकों को यह तय करना होगा कि कोई परिवर्तन उत्पाद के उद्देश्य से मेल खाता है या नहीं। टाइमस्टैम्प: 0:00 एक्सेसिबिलिटी ट्री बनाम रेंडर्ड रियलिटी 1:32 विज़ुअल बेसलाइन को नियंत्रित करना क्यों ज़रूरी है 2:54 व्यूपोर्ट ज्योमेट्री और फुल-पेज लिमिट्स 4:08 सिमेंटिक रेडीनेस नेटवर्क आइडल से बेहतर है 5:20 RGBA पिक्सेल अंतर और परिवर्तन अनुपात 5:43 रेंडरिंग नॉइज़ और LLM टोकन कॉस्ट 6:28 विज़ुअल परिवर्तनों का थ्रेशोल्डिंग 7:07 हीटमैप अर्थ प्रदान नहीं कर सकते 7:36 जानबूझकर किया गया रंग अपडेट बनाम छिपा हुआ लेआउट बग 8:27 ऑटोमेशन का अंत मानवीय समीक्षा पर होता है 8:49 QA टीमों के लिए एनोटेटेड साक्ष्य 9:10 दोहराने योग्य पाइपलाइन, मानवीय निर्णय 9:36 एजेंट-ब्राउज़र क्या जज कर सकता है और क्या नहीं 🧭 एक्सेसिबिलिटी ट्री संरचना दिखाते हैं, दृश्य उपयोगिता नहीं 🖼️ बेसलाइन व्यूपोर्ट और पेज रेडीनेस पर निर्भर करते हैं 📊 थ्रेशोल्ड रेंडरिंग नॉइज़ और टोकन को कम करते हैं लागत 👁️ मानवीय समीक्षा यह तय करती है कि परिवर्तन स्वीकार्य हैं या नहीं। विज़ुअल रिग्रेशन टेस्टिंग का व्यावहारिक निष्कर्ष पूर्ण स्वायत्तता नहीं है। एजेंट-ब्राउज़र कैप्चर स्थितियों को मानकीकृत कर सकता है, स्क्रीनशॉट की तुलना कर सकता है, कम महत्व वाले शोर को दबा सकता है और विसंगतियों को सुलभ तत्वों से जोड़ सकता है। फिर भी, स्वीकृत रीडिज़ाइन को वास्तविक उपयोगिता संबंधी समस्या से अलग करने के लिए इसे उत्पाद संदर्भ की आवश्यकता होती है। साक्ष्य का उपयोग समीक्षा को प्रतिस्थापित करने के बजाय, महत्वपूर्ण बिंदुओं पर केंद्रित समीक्षा के लिए करें। #AgentBrowser #VisualRegression #BrowserAutomation [id] Penjelasan GitHub agent-browser: Regresi Visual di Luar Pemeriksaan DOM agent-browser oleh vercel-labs: vercel-labs/agent-browser Bisakah agen peramban AI menentukan apakah perubahan UI dapat diterima? Tinjauan ini menggunakan agent-browser sebagai lensa berbasis sumber pada regresi visual untuk arsitek QA, tim frontend, dan pembangun alur kerja peramban AI. Tinjauan ini membandingkan cuplikan pohon aksesibilitas dengan piksel yang dirender, kemudian memetakan kondisi untuk bukti visual yang dapat diulang: geometri viewport tetap, batas tangkapan halaman penuh dengan pengguliran internal, sinyal kesiapan semantik, rasio perubahan piksel RGBA, dan noise rendering dari font, komposit perangkat keras, dan konten dinamis. Tinjauan ini juga menunjukkan mengapa ambang batas 1% dapat menyaring noise namun melewatkan pergeseran checkout tiga piksel 0,5%, sementara pembaruan warna yang disengaja sebesar 15% terlihat parah. Kesimpulannya praktis: otomatisasi dapat mengumpulkan dan memberi anotasi bukti, tetapi peninjau manusia harus memutuskan apakah perubahan tersebut sesuai dengan maksud produk. Cap Waktu: 0:00 Pohon Aksesibilitas vs Realitas yang Dirender 1:32 Mengapa Garis Dasar Visual Perlu Dikendalikan 2:54 Geometri Viewport dan Batasan Halaman Penuh 4:08 Kesiapan Semantik Mengalahkan Idle Jaringan 5:20 Perbedaan Piksel RGBA dan Rasio Perubahan 5:43 Kebisingan Rendering dan Biaya Token LLM 6:28 Ambang Batas Perubahan Visual 7:07 Heatmap Tidak Dapat Memberikan Makna 7:36 Pembaruan Warna yang Disengaja vs Bug Tata Letak Tersembunyi 8:27 Otomatisasi Berakhir pada Tinjauan Manusia 8:49 Bukti Beranotasi untuk Tim QA 9:10 Pipeline yang Dapat Diulang, Keputusan Manusia 9:36 Apa yang Dapat dan Tidak Dapat Dinilai oleh Agen-Browser 🧭 Pohon aksesibilitas menunjukkan struktur, bukan kegunaan visual 🖼️ Garis dasar bergantung pada kesiapan viewport dan halaman 📊 Ambang batas mengurangi kebisingan rendering dan biaya token 👁️ Tinjauan manusia Menentukan apakah perubahan dapat diterima Poin praktis untuk pengujian regresi visual bukanlah otonomi penuh. Agent-browser dapat menstandarisasi kondisi pengambilan gambar, membandingkan tangkapan layar, menekan gangguan bernilai rendah, dan menghubungkan anomali dengan elemen yang mudah diakses. Ia masih membutuhkan konteks produk untuk memisahkan desain ulang yang disetujui dari regresi kegunaan yang sebenarnya. Gunakan bukti untuk memfokuskan tinjauan di tempat yang penting, bukan untuk menggantikan tinjauan. #AgentBrowser #VisualRegression #BrowserAutomation [it] agent-browser GitHub spiegato: Regressione visiva oltre i controlli DOM agent-browser di vercel-labs: vercel-labs/agent-browser Un agente browser basato sull'IA può stabilire se una modifica all'interfaccia utente è accettabile? Questa panoramica utilizza agent-browser come strumento di analisi del codice sorgente per la regressione visiva, rivolto ad architetti QA, team frontend e sviluppatori di flussi di lavoro browser basati sull'IA. Vengono confrontate le istantanee dell'albero di accessibilità con i pixel renderizzati, quindi vengono mappate le condizioni per ottenere prove visive ripetibili: geometria fissa del viewport, limiti di acquisizione dell'intera pagina con scorrimento interno, segnali di prontezza semantica, rapporti di variazione dei pixel RGBA e rumore di rendering derivante da font, composizione hardware e contenuti dinamici. Viene inoltre mostrato perché una soglia dell'1% può filtrare il rumore ma non rilevare uno spostamento di tre pixel dello 0,5%, mentre un aggiornamento intenzionale del colore del 15% appare eccessivo. La conclusione è pratica: l'automazione può raccogliere e annotare le prove, ma spetta ai revisori umani decidere se una modifica corrisponde all'intento del prodotto. Indice dei contenuti: 0:00 Alberi di accessibilità vs Realtà renderizzata 1:32 Perché le baseline visive necessitano di controllo 2:54 Geometria del viewport e limiti della pagina intera 4:08 La prontezza semantica ha la meglio sull'inattività della rete 5:20 Differenze di pixel RGBA e rapporti di modifica 5:43 Rumore di rendering e costo del token LLM 6:28 Soglia per le modifiche visive 7:07 Le mappe di calore non possono fornire significato 7:36 Aggiornamento intenzionale del colore vs bug di layout nascosto 8:27 L'automazione termina con la revisione umana 8:49 Prove annotate per i team di QA 9:10 Pipeline ripetibili, decisioni umane 9:36 Cosa può e cosa non può giudicare l'agente-browser 🧭 Gli alberi di accessibilità mostrano la struttura, non l'usabilità visiva 🖼️ Le baseline dipendono dal viewport e dalla prontezza della pagina 📊 Le soglie riducono il rumore di rendering e il costo del token 👁️ La revisione umana decide se le modifiche sono Accettabile L'aspetto pratico dei test di regressione visiva non è la completa autonomia. Agent-Browser può standardizzare le condizioni di acquisizione, confrontare gli screenshot, sopprimere il rumore di scarsa rilevanza e collegare le anomalie agli elementi accessibili. È comunque necessario il contesto del prodotto per distinguere una riprogettazione approvata da una reale regressione di usabilità. Utilizzate le prove per concentrare la revisione dove conta, non per sostituirla. #AgentBrowser #VisualRegression #BrowserAutomation [pt-BR] agent-browser no GitHub Explicado: Regressão Visual Além das Verificações de DOM agent-browser da vercel-labs: vercel-labs/agent-browser Um agente de navegador com IA consegue determinar se uma alteração na interface do usuário é aceitável? Esta visão geral utiliza o agent-browser como uma lente de regressão visual baseada no código-fonte para arquitetos de controle de qualidade, equipes de front-end e desenvolvedores de fluxos de trabalho de navegador com IA. Ela compara snapshots da árvore de acessibilidade com pixels renderizados e, em seguida, mapeia as condições para evidências visuais repetíveis: geometria fixa da viewport, limites de captura de página inteira com rolagem interna, sinais de prontidão semântica, taxas de alteração de pixels RGBA e ruído de renderização proveniente de fontes, composição de hardware e conteúdo dinâmico. Também mostra por que um limite de 1% pode filtrar ruído, mas não detectar uma mudança de três pixels de 0,5% na finalização da compra, enquanto uma atualização intencional de cores de 15% parece grave. A conclusão é prática: a automação pode coletar e anotar evidências, mas os revisores humanos devem decidir se uma alteração corresponde à intenção do produto. Marcadores de tempo: 0:00 Árvores de acessibilidade vs. Realidade renderizada 1:32 Por que as linhas de base visuais precisam de controle 2:54 Geometria da viewport e limites de página inteira 4:08 Prontidão semântica supera ociosidade da rede 5:20 Diferenças de pixels RGBA e taxas de mudança 5:43 Ruído de renderização e custo de token LLM 6:28 Limiarização de mudanças visuais 7:07 Mapas de calor não fornecem significado 7:36 Atualização intencional de cores vs. bug de layout oculto 8:27 A automação termina na revisão humana 8:49 Evidências anotadas para equipes de controle de qualidade 9:10 Pipelines repetíveis, decisões humanas 9:36 O que o agente-navegador pode e não pode julgar 🧭 Árvores de acessibilidade mostram estrutura, não usabilidade visual 🖼️ As linhas de base dependem da viewport e da prontidão da página 📊 Limiares reduzem o ruído de renderização e o custo de token 👁️ Revisão humana Decide se as alterações são aceitáveis. A principal conclusão prática para testes de regressão visual não é a autonomia completa. O agent-browser pode padronizar as condições de captura, comparar capturas de tela, suprimir ruídos de baixo valor e conectar anomalias a elementos acessíveis. Ele ainda precisa do contexto do produto para diferenciar uma reformulação aprovada de uma regressão de usabilidade real. Use as evidências para direcionar a revisão onde ela é importante, e não para substituí-la. #AgentBrowser #RegressãoVisual #AutomaçãoDeNavegador