瀏覽器 Agent 是甚麼?Browser Use 解説其運作方式及適用情境
What Is a Browser Agent? How It Works and When to Use One
瀏覽器 Agent 透過 AI 模型讀取網頁、選擇及執行操作,並檢查結果,循環完成指定目標。文章建議有合用 API 時使用 API、流程可預測時用腳本,需靈活判斷時用 Agent。
A browser agent is software that uses an AI model to operate a web browser toward a goal. You describe the task, and the agent automatically opens the page, navigates, chooses actions, and checks the results before continuing. Agents are especially useful for unpredictable workflows because they can adapt to unexpected changes and recover from errors.
TL;DR
- Use an agent when the task requires flexibility and decision-making. Use an API when available, or a script when the workflow is predictable.
- A browser agent consists of three components: a model (decides what to do), a harness (provides the context, tools, and the loop), and a browser (holds the website session).
- Agents are a versatile tool; they can be used for data extraction, research, form filling, and automating other mundane browser tasks.
- The main downsides of agents are inconsistent results, task failures, website blocks, prompt injection, and unpredictable costs.
How Does a Browser Agent Work?
A browser agent is basically just a fancy loop.
It opens the page, observes it, picks an action, executes it, and checks the result. It repeats these steps until it reaches the goal. Some tasks might require human intervention. For example, the agent may pause for you to sign in, provide missing information, or approve an action before continuing.
The harness should also stop the run when it reaches a time, step, or cost limit.
Here's the basic idea in pseudocode:
while (!goalReached) {
page = observe()
action = pickAction(page)
result = execute(action)
goalReached = checkResult(result)
}The Model, Harness, and Browser
A typical browser agent consists of three main components: a model, a harness, and a browser.
The model chooses what to do next based on the task and the current page. Browser tools provide that page information as text, structured data, or screenshots.
The agent harness keeps the loop running. It gives the model context, runs the tools it requests, and passes the results back so the model can decide what to do next. Browser Use's Browser Harness gives an existing coding agent browser access and lets it write missing helpers during a run. The coding agent's runtime still manages the loop.
The browser loads websites and tracks tabs, cookies, and login state. Browser tools let the agent read pages, click buttons, fill forms, and navigate between them. The browser is typically controlled via a browser protocol, such as the Chrome DevTools Protocol (CDP) or WebDriver BiDi.
An agent can also call browser tools through a Model Context Protocol (MCP) server. The server uses browser automation underneath; for example, Playwright MCP exposes Playwright through tools the agent can call.
For server-based workflows, agents often run browsers in headless mode, without a visible browser window. This lets them run without a display. The browser still renders pages and can capture screenshots for the model.
How the Agent Reads a Page
An agent needs a useful representation of the page before it can decide what to do. There are two common approaches, and an agent can use both.
With structured page data, tools read the Document Object Model (DOM) or an accessibility tree. The DOM represents the page's elements and text. The accessibility tree describes elements through names, roles, and states, such as a button named "Search" or a checked checkbox. This lets the model identify a control without guessing its position in an image.
With screenshots, a vision-capable model reads the rendered page and can choose coordinates to click. This helps with visual content that isn't exposed through useful labels or page structure, such as a canvas-based interface. Small controls can make precise clicks harder, especially if the screenshot loses detail when resized.
Either way, the agent needs a fresh observation after the page changes. A menu may open, a dialog may cover the form, or new results may replace the content it just read.
Browser Agent vs Script vs API
You can automate browser workflows in three ways: a browser agent, a script, or an API. Each has its own pros and cons.
- Use an API if the service provides one that supports your task. For example, you can fetch orders directly without navigating a dashboard.
- Use a script if there's no suitable API and the workflow is predictable. You can write it in Playwright, Selenium, or Puppeteer. Downloading the same report every Monday is a good example. You control the steps, but site changes may require updates.
- Use an agent if the workflow is unpredictable or you can't define the exact steps. It can find reports across unfamiliar websites or handle differently structured forms, though results and model costs can vary.
Scripts and conventional API workflows use deterministic rules: the same inputs and state produce the same decisions. Agent decisions are stochastic (probabilistic), so the same task can take different paths. Agents also make great prototyping tools because you can try a workflow without coding every interaction.
Browser Agent Use Cases
Browser agents use the web much like humans do, so they can handle many of the same tasks. You can use them for anything from collecting product prices to testing a web application.
Our published Browser Use Cloud usage data covers V2, V3, and V4 agents. In the snapshot checked on October 18, 2026, these tasks and workflow steps accounted for the following rounded shares of runs:
- Extracting structured data (14% of runs): converting page content into tables, JSON, CSV, or other records.
- Researching open questions (6%): searching across websites and combining findings into a sourced answer.
- Getting past a login (18%): completing sign-in challenges such as one-time codes, multi-factor setup, and identity checks.
- Applying for jobs (6%): filling application forms, uploading documents, and completing application steps.
- Finding filings and reports (5%): locating annual reports, earnings materials, and recurring filings.
- Booking and buying (3%): navigating availability, selecting options, and working through reservations or checkout.
Each share is the number of runs assigned to that category divided by all runs in the dataset, including the 15% left unclassified. The breakdown includes both end tasks, such as extraction, and supporting steps, such as login handling. These figures describe what people run, not how often the tasks succeed.
Browser Agent Limitations
Browser agents have limitations that affect which workflows they can handle and how reliably they complete them. Results, speed, and costs can vary between agents and even within the same agent across runs.
Website Restrictions
Websites can deliberately make it harder for agents to access them. Bot-management systems can challenge or block automated traffic, while rate limits restrict how quickly requests can be made. A site may allow public browsing but apply stricter checks at login or checkout.
A better model won't resolve every access restriction. If you're curious how different cloud browsers avoid getting blocked, check out our stealth benchmark.
Authentication & Access
Sessions expire, and multi-factor authentication can require human input. An agent may need to pause until you provide a code or approve the login.
Reusing authenticated sessions reduces repeated logins, but your workflow still needs to handle expired sessions.
Incorrect or Incomplete Results
An agent can select the wrong product, miss a required field, or report completion before saving a form. A run that finishes without errors doesn't necessarily mean the task succeeded. Retrying can also create duplicate orders or applications if the previous attempt actually went through.
Check the saved record or confirmation before retrying. For extraction, compare the returned values with the source page; valid JSON alone doesn't prove the data is correct.
Prompt Injection
A page can contain instructions that try to redirect the agent away from your task. This is called prompt injection. Treat page content as untrusted input, limit the accounts and actions the agent can access, and enforce approval for sensitive actions in your application. These controls reduce risk, but don't eliminate it.
Variable Running Costs
Because browser agents run on LLMs, their costs are hard to predict. You can't be sure whether a task will take one step, two steps, or many more. With usage-based billing, additional model calls and browser time increase the cost.
A run might also fail, requiring you to run it again and pay for another attempt. The cost of completing a task can therefore exceed the cost of a single run.
To compare costs, divide the total spend across all attempts, including failures and retries, by the number of verified successful tasks. Track human review time separately.
Getting Started with Browser Agents
Start with one read-only task, such as collecting product prices. Define which pages the agent can visit, what fields it should return, and what counts as a successful result. Set a time, step, or cost limit before running it.
You can send the task to a hosted agent or run one yourself. The open-source Browser Use library lets you build a browser agent in Python with your choice of model and a local or cloud browser. Hosted agents handle the execution for you, while your application supplies the goal and checks the output.
If you already use a coding agent, adding browser tools may be enough. Its existing runtime can manage the reasoning loop. A remote browser on its own only provides the browser environment; your agent or script still needs to control it.
Repeat the task and compare the results with the source pages. Track verified completion, elapsed time, total cost, and human corrections. Only expand to more sites or tasks once you understand where the agent needs help.
Wrapping Up
A browser agent uses an AI model to read pages, choose actions, and work toward a goal. You can use one to research websites, extract data, complete forms, and handle other tasks where the next step depends on what appears.
Use an API when it supports the task, or a script when the steps are predictable. An agent is useful when the next step needs judgment, but its results still need checking.
The Browser Use Cloud quickstart lets you send a task to a hosted web browser agent. Eligible sign-ups with Google, GitHub, or Microsoft include $1 in one-time free credits.
來源:Browser Use · browser-use.com