Aside vs Claude Desktop vs Playwright: 브라우저 제어 방식은 어떻게 다를까?
LLM이 웹사이트를 읽는 단계를 넘어 직접 클릭하고 입력하며 업무를 수행하는 Browser Agent가 빠르게 발전하고 있습니다. 대표적인 접근법으로는 Aside 공식 웹사이트, Claude Desktop 공식 다운로드 페이지, 그리고 Playwright 공식 웹사이트를 들 수 있습니다.
겉으로 보면 모두 “브라우저를 자동으로 조작한다”는 점에서 비슷합니다. 그러나 실제 차이는 브라우저를 누가 소유하는지, 판단을 어디에서 하는지, 실행 절차가 자연어에서 만들어지는지 코드로 고정되는지에 있습니다.
2026년 9월 4일 기준으로 세 영역은 이전보다 더 가까워졌습니다. Aside는 Playwright 계열 인터페이스를 내부 실행 언어로 사용하고, Claude는 사용자의 Chrome과 별도 내장 브라우저를 모두 다룰 수 있으며, Playwright도 CLI와 MCP를 통해 AI 에이전트 워크플로를 공식 지원합니다. 따라서 세 가지를 단순한 경쟁 제품보다 서로 다른 자동화 계층으로 보는 편이 정확합니다.
| 구분 | Aside | Claude Desktop 브라우저 제어 | Playwright |
|---|---|---|---|
| 중심 | 브라우저 중심 Agent | 범용 Agent 중심 | 자동화 실행 계층 |
| 주 입력 | 자연어 | 자연어 | 코드·CLI·MCP |
| 판단 주체 | 내장 LLM Agent | Claude | 개발자 또는 외부 Agent |
| 브라우저 세션 | Aside 안의 사용자 세션 | 사용 중인 Chrome 또는 별도 내장 브라우저 | 보통 자동화용 브라우저 컨텍스트 |
| 강점 | 로그인된 웹 업무 위임 | 웹·파일·코드·도구를 잇는 복합 업무 | 재현 가능한 테스트와 정형 자동화 |
1. Aside: 브라우저 자체가 AI Agent
Aside의 가장 큰 특징은 AI 기능을 기존 브라우저 옆에 붙인 것이 아니라, 처음부터 사람과 Agent가 함께 사용하는 브라우저로 제품을 설계했다는 점입니다. Aside는 스스로를 “people and agents를 위해 다시 만든 브라우저”라고 설명하며, 사용자가 로그인해 둔 이메일, 대시보드, 내부 도구, 문서와 스프레드시트를 Agent가 직접 다루는 경험을 앞세웁니다.
예를 들어 다음과 같이 결과 중심으로 요청할 수 있습니다.
“지난주 주문 내역을 찾아서 표로 정리해 줘.”
Agent는 필요한 페이지를 이동하고, 요소를 찾고, 데이터를 읽어 결과물을 만듭니다. 사용자는 브라우저 세션을 다른 자동화 서버로 옮기기보다 평소 웹을 쓰던 환경 안에서 업무를 위임합니다.
Aside 공식 홈페이지의 공개 제품 화면. AI 입력창이 브라우저 인터페이스 안에 통합된 구성을 보여 줍니다. (출처: Aside 공식 홈페이지, 2026-09-04 캡처)
Asidewright, 접근성 트리, 시각적 Computer Use
내부 구조도 일반적인 좌표 클릭 Agent와는 다릅니다. Aside의 기술 설명에 따르면 LLM은 JavaScript 실행 환경에서 Playwright와 호환되는 자체 계층인 Asidewright를 사용합니다. Asidewright는 CDP 위에 얇은 래퍼를 두고, LLM이 이미 익숙한 Playwright 형태의 인터페이스를 제공합니다.
페이지를 읽을 때는 불필요한 중간 요소를 줄인 접근성 트리(a11y tree)를 사용합니다. DOM이나 접근성 정보만으로 처리하기 어려운 화면에서는 스크린샷을 보고 좌표를 선택하는 Computer Use 방식으로 전환합니다.
사용자 요청
↓
Aside Agent의 계획과 판단
↓
Asidewright + 접근성 트리
↓ DOM 제어가 어렵거나 시각 판단이 필요할 때
스크린샷 기반 Computer Use
↓
실제 브라우저 세션즉 Aside는 다음 요소를 한 제품 안에 묶은 형태입니다.
Browser + Playwright 계열 자동화 + 접근성 트리 + 시각적 Computer Use + LLM Agent
로그인 상태, 로컬 메모리, 패스워드 매니저도 같은 브라우저 안에 통합되어 있습니다. 이 결합이 Aside의 장점인 동시에 중요한 경계이기도 합니다. Agent가 로그인된 페이지를 볼 수 있다는 것은 개인 정보와 조직 데이터에도 접근할 수 있다는 뜻이므로, 읽기 전용 작업부터 시작하고 게시·결제·삭제 같은 행동은 사람의 승인을 남겨 두는 편이 안전합니다.
2. Claude Desktop: 범용 Agent에게 브라우저라는 도구를 제공
Claude Desktop은 중심축이 다릅니다. 브라우저가 주인공이라기보다 Claude가 주인공이고, 브라우저는 Claude가 사용할 수 있는 여러 도구 중 하나입니다.
2026년 9월 4일 기준 Claude Cowork의 브라우저 제어 방식은 크게 두 가지입니다.
- Claude in Chrome: Chrome 확장 프로그램을 통해 사용자가 보고 있는 탭과 이미 로그인한 계정을 그대로 사용합니다. 페이지 읽기, 클릭, 입력, 폼 작성, 탭 이동이 가능합니다.
- Claude Cowork의 내장 브라우저: Claude Desktop의 사이드 패널에서 별도의 브라우저를 엽니다. 개인 브라우저의 탭과 로그인 상태는 기본적으로 분리되며, 사용자가 선택한 사이트의 쿠키를 가져오거나 내장 브라우저에서 직접 로그인할 수 있습니다.
Anthropic의 내장 브라우저 안내에 따르면 이 기능은 당시 Pro, Max, Team과 허용된 Enterprise 환경에 순차 배포 중입니다. 기존에 Claude in Chrome을 쓰고 있었다면 Chrome이 기본값으로 유지되고, 그렇지 않으면 기능이 도착한 뒤 내장 브라우저가 기본값이 됩니다. 설정의 Preferred browser에서 두 방식을 바꿀 수 있습니다.
Anthropic 공식 도움말의 공개 비교 화면. 별도 내장 브라우저와 로그인된 사용자 Chrome이라는 두 세션 모델을 설명합니다. (출처: Anthropic Help Center, 2026-09-04 캡처)
Claude in Chrome 공식 안내는 Claude가 페이지를 읽고 클릭하고 이동하며 폼을 작성할 수 있다고 설명합니다. Chrome 방식은 사람이 보고 있는 페이지에서 함께 작업할 때 자연스럽고, 내장 브라우저는 웹 작업을 별도 공간에 맡기고 사용자가 자기 브라우저에서 계속 일하고 싶을 때 적합합니다.
개념적으로 정리하면 다음과 같습니다.
- Aside = Agent 사용을 전제로 만든 Browser
- Claude Desktop = Browser를 사용할 수 있는 범용 Agent
Claude는 브라우저뿐 아니라 파일, 코드, 커넥터, MCP와 데스크톱 앱을 함께 다룰 수 있습니다. 예를 들어 웹에서 자료를 찾고, 로컬 문서를 읽고, 스프레드시트를 만든 뒤 결과를 요약하는 하나의 작업 흐름을 구성할 수 있습니다.
또한 Browser Use의 공식 MCP 안내처럼 별도의 브라우저 자동화 서버를 Claude Desktop에 연결할 수도 있습니다. 이 경우 Claude는 목표와 판단을 담당하고, MCP 서버가 브라우저 실행 계층을 제공합니다.
3. Playwright: 판단이 아니라 실행을 담당하는 자동화 프레임워크
Playwright는 근본적으로 실행 계층입니다. Playwright 코어에는 사용자의 목표를 해석하고 다음 행동을 스스로 고르는 LLM이 없습니다. 개발자 또는 외부 Agent가 동작을 명시하면 Playwright가 브라우저를 정확하게 제어합니다.
await page.goto('https://example.com');
await page.getByRole('button', { name: 'Login' }).click();Playwright 브라우저 문서에 따르면 Chromium, Firefox, WebKit을 지원하고, TypeScript·JavaScript뿐 아니라 Python, .NET, Java에서도 사용할 수 있습니다. Playwright locator 문서는 getByRole, getByLabel, getByText처럼 사용자가 인식하는 의미에 가까운 선택자를 우선하도록 권장합니다. 이러한 locator에는 자동 대기와 재시도 기능이 결합되어 있습니다.
Playwright 공식 홈페이지의 공개 화면. 하나의 API로 테스트·스크립트·Agent 워크플로에서 Chromium, Firefox, WebKit을 제어한다고 설명합니다. (출처: Playwright 공식 웹사이트, 2026-09-04 캡처)
2026년의 Playwright는 AI Agent와도 연결된다
“Playwright는 AI가 아니다”와 “Playwright는 AI Agent에 쓰이지 않는다”는 다른 말입니다. 전자는 맞지만 후자는 더 이상 맞지 않습니다.
현재 Playwright 공식 사이트는 세 가지 사용면을 함께 제시합니다.
- Playwright Test: 자동 대기, assertion, trace, 병렬 실행을 포함한 E2E 테스트 러너
- Playwright CLI: 코딩 Agent가 브라우저를 효율적으로 제어하기 위한 명령줄 인터페이스
- Playwright MCP: 구조화된 접근성 스냅샷과 브라우저 제어 도구를 Agent에 제공하는 MCP 서버
중요한 차이는 판단 계층이 Playwright 바깥에 남아 있다는 점입니다. 사람이 테스트 코드를 작성할 수도 있고, Claude 같은 Agent가 MCP 도구를 호출하거나 Playwright 코드를 실시간으로 만들 수도 있습니다. 어느 경우든 Playwright는 목표를 정하는 제품이 아니라 정해진 행동을 실행하고 검증하는 기반입니다.
결정론적 자동화와 상황 판단의 차이
매일 같은 관리자 페이지에 접속해 같은 버튼을 누르고 결과를 확인하는 업무라면 Playwright 스크립트가 대체로 더 예측 가능하고 비용도 낮습니다. 입력과 검증 조건이 코드에 남기 때문에 실패 지점을 재현하고 CI에서 반복하기 쉽습니다.
반대로 다음 요청은 상황에 따라 후보를 찾고 비교하고 선택해야 합니다.
“이 사이트에서 조건에 맞는 상품을 찾아 비교한 뒤 가장 나은 것을 골라 줘.”
이런 작업을 Playwright만으로 구현하려면 선택 기준, 예외 처리, 페이지 변화, 결과 해석을 모두 코드로 작성해야 합니다. Aside나 Claude는 LLM이 그 판단을 담당하고, 필요한 브라우저 동작을 실행 계층에 요청합니다.
다만 Agent의 “유연함”이 항상 더 높은 신뢰성을 뜻하지는 않습니다. 모호한 페이지에서는 판단을 잘못할 수 있고, prompt injection이나 과도한 권한 같은 위험도 생깁니다. 정형 업무는 코드로 고정하고, 비정형 판단이 필요한 구간만 Agent에 맡기는 혼합 방식이 실무에서 가장 현실적입니다.
한눈에 비교하기
| 구분 | Aside | Claude Desktop 브라우저 제어 | Playwright |
|---|---|---|---|
| 기본 개념 | AI-native Browser | 범용 AI Agent + Browser | Browser Automation Framework |
| 사용 방식 | 자연어 | 자연어 | 코드·CLI·MCP |
| LLM 내장 | O | O | 코어에는 X |
| 기존 로그인 활용 | 브라우저 안에서 직접 활용 | Chrome은 직접 활용, 내장 브라우저는 선택적 가져오기 | 저장 상태·프로필을 별도 구성 |
| 상황 판단 | 강함 | 강함 | 외부 로직 또는 Agent 필요 |
| 반복 작업 재현성 | Agent 실행에 따라 달라짐 | Agent 실행에 따라 달라짐 | 매우 높음 |
| 테스트 자동화 | 탐색적 QA에 유용 | 탐색적 QA와 디버깅에 유용 | E2E·회귀 테스트에 가장 적합 |
| 개발 지식 | 낮음 | 낮음 | 코드 사용 시 높음 |
| 예외 상황 대응 | 실행 중 판단 | 실행 중 판단 | 사전 구현 또는 외부 Agent 필요 |
| 적합한 용도 | 로그인된 일상 웹 업무 | 웹·파일·코드를 잇는 복합 업무 | E2E·크롤링·정형 자동화 |
무엇을 선택해야 할까?
선택 기준은 제품 이름보다 업무의 변동성과 재현성 요구에 있습니다.
- 정해진 절차를 100번 반복하고 결과를 검증해야 한다면 Playwright가 적합합니다.
- 로그인된 웹 업무를 자연어로 위임하고 브라우저 자체에서 끝내고 싶다면 Aside가 편리합니다.
- 브라우저 작업을 파일·코드·추론·커넥터와 하나의 흐름으로 묶고 싶다면 Claude Desktop이 잘 맞습니다.
- 판단이 필요한 앞부분과 반복 실행이 필요한 뒷부분이 함께 있다면 LLM Agent + Playwright 조합이 좋습니다.
결론
세 도구의 차이는 “브라우저를 클릭할 수 있는가”가 아니라 누가 판단하고, 어디에서 실행하며, 무엇이 반복 가능한 자산으로 남는가에 있습니다.
Aside는 브라우저와 Agent를 하나의 제품으로 묶습니다. Claude Desktop은 범용 Agent가 사용자의 Chrome 또는 별도 내장 브라우저를 도구로 선택하게 합니다. Playwright는 판단을 외부에 두고 테스트와 자동화를 위한 정밀한 실행 계층을 제공합니다.
앞으로의 Browser Agent는 세 접근법을 더 많이 섞을 가능성이 큽니다. LLM이 목표를 해석하고, DOM과 접근성 트리로 요소를 찾고, Playwright 계열 코드나 도구로 행동하며, 필요한 순간에만 시각적 Computer Use로 전환하는 구조입니다. 결국 가장 실용적인 질문은 “어떤 제품이 이기는가?”보다 “이 업무에서 판단과 실행을 어디까지 분리할 것인가?”에 가깝습니다.
LLMs are moving beyond reading websites: they can now click, type, and complete work directly in the browser. Three representative approaches are Aside’s official website, the official Claude Desktop download page, and the official Playwright website.
At first glance, all three “automate the browser.” The real differences are who owns the browser, where decisions are made, and whether the execution procedure is generated from natural language or fixed in code.
As of September 4, 2026, these areas are closer than they used to be. Aside uses a Playwright-style interface as its internal execution language; Claude can operate both a user’s Chrome session and a separate built-in browser; and Playwright officially supports AI-agent workflows through its CLI and MCP. It is therefore more accurate to view them as different layers of automation than as simple competing products.
| Dimension | Aside | Claude Desktop browser control | Playwright |
|---|---|---|---|
| Center of gravity | Browser-first agent | General-purpose agent | Automation execution layer |
| Primary input | Natural language | Natural language | Code, CLI, or MCP |
| Decision maker | Built-in LLM agent | Claude | Developer or external agent |
| Browser session | User session inside Aside | Existing Chrome or separate built-in browser | Usually an automation browser context |
| Strength | Delegating work on authenticated sites | Multi-tool work across web, files, and code | Reproducible tests and structured automation |
1. Aside: the browser itself is the AI agent
Aside’s defining feature is that it was designed from the start as a browser shared by people and agents, rather than as an AI feature added beside an existing browser. Aside describes itself as a browser rebuilt for “people and agents,” emphasizing an agent that can work directly with authenticated email, dashboards, internal tools, documents, and spreadsheets.
You can give it an outcome-oriented request such as:
“Find last week’s orders and organize them into a table.”
The agent navigates the necessary pages, locates elements, reads data, and produces the result. Instead of moving a browser session to a separate automation server, the user delegates work inside the environment where they already use the web.
Public product view on Aside’s official homepage. It shows the AI input area integrated directly into the browser interface. (Source: Aside official website, captured 2026-09-04)
Asidewright, the accessibility tree, and visual Computer Use
Its internal architecture also differs from a simple coordinate-clicking agent. According to Aside’s technical explanation, the LLM uses Asidewright, a proprietary Playwright-compatible layer, from a JavaScript execution environment. Asidewright places thin wrappers over CDP and exposes an interface in the Playwright form that LLMs already know.
To read pages, it uses a modified accessibility tree that removes unnecessary intermediate elements. When DOM or accessibility information is not enough, it falls back to Computer Use, looking at a screenshot and selecting coordinates.
User request
↓
Planning and judgment by the Aside agent
↓
Asidewright + accessibility tree
↓ when DOM control is difficult or visual judgment is needed
Screenshot-based Computer Use
↓
Real browser session
In other words, Aside bundles the following into one product:
Browser + Playwright-style automation + accessibility tree + visual Computer Use + LLM agent
Login state, local memory, and a password manager are integrated into the same browser. That combination is both a strength and an important boundary. If an agent can see authenticated pages, it may also reach personal or organizational data. A safer rollout starts with read-only work and keeps human approval for publishing, payments, deletion, and other consequential actions.
2. Claude Desktop: give a general-purpose agent a browser tool
Claude Desktop has a different center of gravity. The browser is not the main product; Claude is, and the browser is one of several tools Claude can use.
As of September 4, 2026, Claude Cowork has two main browser-control options:
- Claude in Chrome: a Chrome extension that works with the tab the user is viewing and accounts that are already signed in. It can read pages, click, type, fill forms, and move between tabs.
- Claude Cowork’s built-in browser: a separate browser in the Claude Desktop side panel. It is isolated from the user’s personal tabs and logins by default; users can import cookies for selected sites or sign in directly inside the built-in browser.
According to Anthropic’s built-in browser guide, the feature was rolling out at the time to Pro, Max, Team, and enabled Enterprise environments. Existing Claude in Chrome users keep Chrome as the default, while new users get the built-in browser after it reaches their account. The two options can be switched under Preferred browser in settings.
Public comparison in Anthropic’s official help center. It explains the two session models: a separate built-in browser and the user’s authenticated Chrome. (Source: Anthropic Help Center, captured 2026-09-04)
The official Claude in Chrome guide says Claude can read, click, navigate, and fill forms on pages. Chrome is natural for working alongside the user on the page already in front of them; the built-in browser is better when the user wants to hand off the web portion of a task and continue working in their own browser.
Conceptually, the distinction is:
- Aside = a browser built for an agent
- Claude Desktop = a general-purpose agent that can use a browser
Claude can combine browser work with files, code, connectors, MCP, and desktop apps. A single workflow might research material on the web, read local documents, create a spreadsheet, and summarize the result.
It is also possible to connect a separate browser automation server to Claude Desktop, as shown in Browser Use’s official MCP integration guide. In that setup, Claude handles the goal and decision-making while the MCP server provides the browser execution layer.
3. Playwright: an automation framework for execution, not judgment
Playwright is fundamentally an execution layer. Its core does not include an LLM that interprets a user’s goal and independently chooses the next action. A developer or external agent specifies the behavior, and Playwright controls the browser precisely.
await page.goto('https://example.com');
await page.getByRole('button', { name: 'Login' }).click();
The Playwright browser documentation lists support for Chromium, Firefox, and WebKit, with bindings for Python, .NET, and Java in addition to TypeScript and JavaScript. The Playwright locator guide recommends selectors such as getByRole, getByLabel, and getByText, which align with how users perceive the interface. These locators include automatic waiting and retry behavior.
Public view of the official Playwright homepage. It describes one API for controlling Chromium, Firefox, and WebKit in tests, scripts, and agent workflows. (Source: Playwright official website, captured 2026-09-04)
In 2026, Playwright also connects to AI agents
“Playwright is not AI” and “Playwright is not used with AI agents” are different statements. The first is true; the second is no longer true.
Playwright’s current official site presents three surfaces:
- Playwright Test: an E2E test runner with auto-waiting, assertions, traces, and parallel execution
- Playwright CLI: a command-line interface for efficient browser control by coding agents
- Playwright MCP: an MCP server that gives agents structured accessibility snapshots and browser-control tools
The important distinction is that the decision layer remains outside Playwright. A person may write the test code, or an agent such as Claude may call MCP tools or generate Playwright code in real time. In either case, Playwright is the foundation that executes and verifies specified actions, not the product that decides the goal.
Deterministic automation versus situational judgment
If a task visits the same admin page every day, clicks the same button, and checks the same result, a Playwright script is generally more predictable and less expensive. Inputs and assertions remain in code, so failures are easier to reproduce and the workflow can run repeatedly in CI.
This request, however, requires finding candidates, comparing them, and making a context-dependent choice:
“Find products on this site that match my conditions, compare them, and choose the best one.”
Implementing that with Playwright alone requires the selection criteria, exceptions, page changes, and interpretation of results to be encoded in advance. Aside or Claude lets an LLM handle that judgment and ask the execution layer for the necessary browser actions.
Still, an agent’s “flexibility” does not automatically mean greater reliability. It can misjudge ambiguous pages, and browser agents introduce risks such as prompt injection and excessive permissions. In practice, the most realistic pattern is to encode structured work and let an agent handle only the portions that genuinely require open-ended judgment.
Comparison at a glance
| Dimension | Aside | Claude Desktop browser control | Playwright |
|---|---|---|---|
| Basic concept | AI-native browser | General AI agent + browser | Browser automation framework |
| Usage | Natural language | Natural language | Code, CLI, or MCP |
| Built-in LLM | Yes | Yes | No in the core |
| Existing login reuse | Directly inside the browser | Direct in Chrome; optional import for built-in browser | Configure saved state or a profile separately |
| Situational judgment | Strong | Strong | Requires external logic or an agent |
| Repeatability | Varies by agent execution | Varies by agent execution | Very high |
| Test automation | Useful for exploratory QA | Useful for exploratory QA and debugging | Best fit for E2E and regression testing |
| Development knowledge | Low | Low | High when writing code |
| Exception handling | Decides while executing | Decides while executing | Must be pre-implemented or delegated to an external agent |
| Best fit | Everyday work on authenticated sites | Complex work spanning web, files, and code | E2E, crawling, and structured automation |
Which should you choose?
The right choice depends less on the product name than on how variable the work is and how much reproducibility it requires.
- Choose Playwright when you need to repeat a defined procedure 100 times and verify the result.
- Choose Aside when you want to delegate authenticated web work in natural language and finish it inside the browser.
- Choose Claude Desktop when browser work must join files, code, reasoning, and connectors in one flow.
- Choose an LLM agent + Playwright combination when the first part requires judgment and the second part requires repeatable execution.
Conclusion
The difference between these tools is not whether they can click a browser. It is who makes decisions, where actions run, and what remains as a repeatable asset.
Aside combines the browser and the agent in one product. Claude Desktop lets a general-purpose agent choose between the user’s Chrome and a separate built-in browser. Playwright keeps judgment outside and provides a precise execution layer for testing and automation.
Future browser agents will probably combine these approaches even more. An LLM will interpret the goal, identify elements through the DOM and accessibility tree, act through Playwright-style code or tools, and switch to visual Computer Use only when needed. The practical question is therefore less “Which product wins?” and more “Where should this workflow separate judgment from execution?”
LLM 正从“读取网页”进一步发展为直接点击、输入并完成浏览器中的工作。具有代表性的三种方案是 Aside 官方网站、Claude Desktop 官方下载页面 和 Playwright 官方网站。
乍看之下，三者都在“自动操作浏览器”。真正的差异在于：谁拥有浏览器、判断发生在哪里，以及执行步骤是根据自然语言动态生成，还是被固定在代码中。
截至 2026 年 9 月 4 日，这三个领域已经比过去更加接近。Aside 在内部把 Playwright 风格的接口作为执行语言；Claude 既能操作用户正在使用的 Chrome，也能使用独立的内置浏览器；Playwright 也通过 CLI 和 MCP 正式支持 AI Agent 工作流。因此，与其把它们看成单纯的竞品，不如理解为不同的自动化层级。
| 维度 | Aside | Claude Desktop 浏览器控制 | Playwright |
|---|---|---|---|
| 核心 | 以浏览器为中心的 Agent | 以通用 Agent 为中心 | 自动化执行层 |
| 主要输入 | 自然语言 | 自然语言 | 代码、CLI、MCP |
| 判断主体 | 内置 LLM Agent | Claude | 开发者或外部 Agent |
| 浏览器会话 | Aside 中的用户会话 | 现有 Chrome 或独立内置浏览器 | 通常是自动化专用浏览器上下文 |
| 优势 | 委托已登录网站上的工作 | 串联网页、文件与代码的复合任务 | 可复现的测试与结构化自动化 |
1. Aside：浏览器本身就是 AI Agent
Aside 最大的特点，不是在现有浏览器旁边附加 AI 功能，而是从一开始就把产品设计成由人和 Agent 共同使用的浏览器。Aside 称自己是为“people and agents”重新构建的浏览器，并强调 Agent 可以直接处理用户已经登录的邮箱、仪表板、内部工具、文档和电子表格。
例如，可以直接给出以结果为导向的请求：
“找出上周的订单，并整理成表格。”
Agent 会浏览所需页面、定位元素、读取数据并产出结果。用户无需把浏览器会话迁移到独立的自动化服务器，而是在日常使用网页的环境中直接委托任务。
Aside 官方首页的公开产品画面，展示了 AI 输入区直接集成在浏览器界面中的结构。(来源：Aside 官方网站，截图日期：2026-09-04)
Asidewright、无障碍树与视觉 Computer Use
其内部架构也不同于简单的坐标点击 Agent。根据 Aside 的技术说明，LLM 在 JavaScript 执行环境中使用自有的 Playwright 兼容层 Asidewright。Asidewright 在 CDP 之上提供轻量封装，并暴露 LLM 已熟悉的 Playwright 风格接口。
读取页面时，它会使用经过修改的无障碍树（a11y tree），删减不必要的中间元素。当 DOM 或无障碍信息不足时，则切换到 Computer Use，通过截图进行视觉判断并选择坐标。
用户请求
↓
Aside Agent 的计划与判断
↓
Asidewright + 无障碍树
↓ 当 DOM 控制困难或需要视觉判断时
基于截图的 Computer Use
↓
真实浏览器会话
也就是说，Aside 把以下元素整合进一个产品：
Browser + Playwright 风格自动化 + 无障碍树 + 视觉 Computer Use + LLM Agent
登录状态、本地记忆和密码管理器也集成在同一个浏览器中。这种结合既是优势，也是重要的权限边界。Agent 能看到登录后的页面，也就可能接触个人或组织数据。因此，更安全的方式是先从只读任务开始，并为发布、支付、删除等高影响操作保留人工批准。
2. Claude Desktop：为通用 Agent 提供浏览器工具
Claude Desktop 的中心不同。浏览器并不是主角，Claude 才是；浏览器只是 Claude 可以使用的多种工具之一。
截至 2026 年 9 月 4 日，Claude Cowork 主要有两种浏览器控制方式：
- Claude in Chrome：通过 Chrome 扩展使用用户正在查看的标签页和已经登录的账号，可读取页面、点击、输入、填写表单和切换标签页。
- Claude Cowork 内置浏览器：在 Claude Desktop 侧边面板中打开独立浏览器。默认与个人浏览器的标签页和登录状态分离；用户可以按网站导入 Cookie，或直接在内置浏览器中登录。
根据 Anthropic 的内置浏览器指南，当时该功能正逐步推送给 Pro、Max、Team 以及已启用的 Enterprise 环境。已经使用 Claude in Chrome 的用户会继续以 Chrome 为默认方式；新用户在功能到达账号后默认使用内置浏览器。两者可在设置的 Preferred browser 中切换。
Anthropic 官方帮助中心的公开对比画面，说明了独立内置浏览器与用户已登录 Chrome 这两种会话模型。(来源：Anthropic Help Center，截图日期：2026-09-04)
Claude in Chrome 官方指南说明，Claude 可以读取、点击、跳转网页并填写表单。Chrome 方式适合与用户共同处理眼前页面；内置浏览器则适合把网页部分单独委托给 Claude，让用户继续在自己的浏览器中工作。
从概念上可以这样区分：
- Aside = 为 Agent 构建的 Browser
- Claude Desktop = 可以使用 Browser 的通用 Agent
Claude 不仅能操作浏览器，还可以结合文件、代码、连接器、MCP 和桌面应用。一个工作流可以先在网页上检索资料，再读取本地文档、创建电子表格，最后总结结果。
此外，还可以按照 Browser Use 的官方 MCP 集成指南，把独立的浏览器自动化服务器接入 Claude Desktop。在这种结构中，Claude 负责目标与判断，MCP 服务器提供浏览器执行层。
3. Playwright：负责执行而非判断的自动化框架
Playwright 从根本上说是执行层。它的核心并不包含能够理解用户目标并自行选择下一步的 LLM。开发者或外部 Agent 明确指定行为后，Playwright 精确控制浏览器。
await page.goto('https://example.com');
await page.getByRole('button', { name: 'Login' }).click();
根据 Playwright 浏览器文档，它支持 Chromium、Firefox 和 WebKit，除 TypeScript、JavaScript 外，还提供 Python、.NET 和 Java 绑定。Playwright locator 文档建议优先使用 getByRole、getByLabel、getByText 等更接近用户认知方式的选择器，并为这些 locator 提供自动等待与重试。
Playwright 官方首页的公开画面，说明同一套 API 可在测试、脚本和 Agent 工作流中控制 Chromium、Firefox 与 WebKit。(来源：Playwright 官方网站，截图日期：2026-09-04)
2026 年的 Playwright 也与 AI Agent 相连
“Playwright 不是 AI”和“Playwright 不用于 AI Agent”是两句话。前者正确，后者已经不再正确。
当前 Playwright 官方网站同时展示三种使用方式：
- Playwright Test：包含自动等待、断言、Trace 和并行执行的 E2E 测试运行器
- Playwright CLI：让编码 Agent 高效控制浏览器的命令行接口
- Playwright MCP：向 Agent 提供结构化无障碍快照与浏览器控制工具的 MCP 服务器
关键差异在于：判断层仍然位于 Playwright 之外。人可以编写测试代码，Claude 等 Agent 也可以调用 MCP 工具或实时生成 Playwright 代码。无论哪种方式，Playwright 都是执行和验证既定动作的基础，而不是决定目标的产品。
确定性自动化与情境判断的差异
如果任务是每天进入同一个管理页面、点击同一个按钮并检查同一个结果，Playwright 脚本通常更可预测，成本也更低。输入和断言都保留在代码中，因此更容易复现失败，并可在 CI 中反复运行。
但下面的请求需要寻找候选项、比较并根据情境作出选择：
“在这个网站上找到符合条件的商品，比较后选出最好的一个。”
如果只用 Playwright 实现，就必须提前把选择标准、异常处理、页面变化和结果解释全部写入代码。Aside 或 Claude 则让 LLM 负责判断，再向执行层请求所需的浏览器动作。
不过，Agent 的“灵活性”并不自动等于更高的可靠性。它可能误判模糊页面，也会带来 prompt injection 和权限过度等风险。在实践中，更现实的做法是把结构化任务固化为代码，只把真正需要开放式判断的部分交给 Agent。
一览对比
| 维度 | Aside | Claude Desktop 浏览器控制 | Playwright |
|---|---|---|---|
| 基本概念 | AI-native Browser | 通用 AI Agent + Browser | Browser Automation Framework |
| 使用方式 | 自然语言 | 自然语言 | 代码、CLI、MCP |
| 内置 LLM | 是 | 是 | 核心中没有 |
| 复用现有登录 | 直接在浏览器中使用 | Chrome 直接使用；内置浏览器可选择导入 | 需单独配置保存状态或 Profile |
| 情境判断 | 强 | 强 | 需要外部逻辑或 Agent |
| 重复任务可复现性 | 随 Agent 执行而变化 | 随 Agent 执行而变化 | 很高 |
| 测试自动化 | 适合探索式 QA | 适合探索式 QA 与调试 | 最适合 E2E 与回归测试 |
| 开发知识 | 低 | 低 | 编写代码时较高 |
| 异常处理 | 执行中判断 | 执行中判断 | 需预先实现或交给外部 Agent |
| 适用场景 | 已登录网站上的日常工作 | 串联网页、文件和代码的复合任务 | E2E、抓取与结构化自动化 |
应该选择哪一个？
选择标准与其说是产品名称，不如说是工作的变化程度和对可复现性的要求。
- 如果要把明确的流程重复 100 次并验证结果，选择 Playwright。
- 如果想用自然语言委托已登录网站上的工作，并在浏览器中完成，选择 Aside。
- 如果要把浏览器任务与文件、代码、推理和连接器串成一个流程，选择 Claude Desktop。
- 如果前半段需要判断、后半段需要稳定重复执行，选择 LLM Agent + Playwright 的组合。
结论
三者的差异不在于“能否点击浏览器”，而在于谁负责判断、动作在哪里执行，以及什么会被保留下来成为可重复使用的资产。
Aside 把浏览器与 Agent 整合进一个产品。Claude Desktop 让通用 Agent 在用户的 Chrome 与独立内置浏览器之间选择。Playwright 把判断留在外部，为测试和自动化提供精确的执行层。
未来的 Browser Agent 很可能进一步融合这三种方式：LLM 解释目标，通过 DOM 与无障碍树定位元素，使用 Playwright 风格的代码或工具执行动作，只在必要时切换到视觉 Computer Use。因此，更实用的问题不是“哪个产品会胜出”，而是“在这个工作流中，判断与执行应该分离到什么程度”。
LLMはWebサイトを読むだけでなく、ブラウザ上で直接クリックや入力を行い、業務を実行する段階へ進んでいます。代表的なアプローチとして、Aside公式サイト、Claude Desktop公式ダウンロードページ、Playwright公式サイトがあります。
一見すると、いずれも「ブラウザを自動操作する」点では同じです。しかし本当の違いは、誰がブラウザを所有するのか、どこで判断するのか、そして実行手順が自然言語から生成されるのか、コードとして固定されるのかにあります。
2026年9月4日時点で、これら三つの領域は以前よりも接近しています。AsideはPlaywright系のインターフェースを内部の実行言語として使い、ClaudeはユーザーのChromeと独立した内蔵ブラウザの両方を操作できます。PlaywrightもCLIとMCPを通じてAIエージェントのワークフローを公式にサポートしています。そのため、単純な競合製品ではなく、異なる自動化レイヤーとして捉える方が正確です。
| 観点 | Aside | Claude Desktopのブラウザ制御 | Playwright |
|---|---|---|---|
| 中心 | ブラウザ中心のAgent | 汎用Agent中心 | 自動化の実行レイヤー |
| 主な入力 | 自然言語 | 自然言語 | コード・CLI・MCP |
| 判断主体 | 内蔵LLM Agent | Claude | 開発者または外部Agent |
| ブラウザセッション | Aside内のユーザーセッション | 既存のChromeまたは独立した内蔵ブラウザ | 通常は自動化用ブラウザコンテキスト |
| 強み | ログイン済みWeb業務の委任 | Web・ファイル・コードをつなぐ複合作業 | 再現可能なテストと定型自動化 |
1. Aside：ブラウザ自体がAI Agent
Asideの最大の特徴は、既存ブラウザの横にAI機能を追加したのではなく、最初から人とAgentが共同で使うブラウザとして設計された点です。Asideは自らを「people and agents」のために作り直したブラウザと説明し、ログイン済みのメール、ダッシュボード、社内ツール、文書、スプレッドシートをAgentが直接扱う体験を前面に出しています。
たとえば、結果を中心に次のように依頼できます。
「先週の注文履歴を探して、表にまとめて。」
Agentは必要なページを移動し、要素を探し、データを読み取って成果物を作ります。ユーザーはブラウザセッションを別の自動化サーバーへ移すのではなく、普段Webを使っている環境の中で仕事を委任します。
Aside公式サイトの公開製品画面。AI入力欄がブラウザインターフェース内に直接統合された構成を示しています。(出典：Aside公式サイト、2026-09-04キャプチャ)
Asidewright、アクセシビリティツリー、視覚的Computer Use
内部構造も、単純な座標クリック型Agentとは異なります。Asideの技術解説によると、LLMはJavaScript実行環境から、Playwright互換の独自レイヤーであるAsidewrightを使用します。AsidewrightはCDP上に薄いラッパーを置き、LLMがすでに理解しているPlaywright形式のインターフェースを提供します。
ページの読み取りには、不要な中間要素を削減したアクセシビリティツリー（a11y tree）を使います。DOMやアクセシビリティ情報だけでは扱いにくい画面では、スクリーンショットを見て座標を選ぶComputer Use方式へ切り替えます。
ユーザーの依頼
↓
Aside Agentによる計画と判断
↓
Asidewright + アクセシビリティツリー
↓ DOM制御が難しい、または視覚判断が必要な場合
スクリーンショットベースのComputer Use
↓
実際のブラウザセッション
つまりAsideは、次の要素を一つの製品にまとめた形です。
Browser + Playwright系自動化 + アクセシビリティツリー + 視覚的Computer Use + LLM Agent
ログイン状態、ローカルメモリ、パスワードマネージャーも同じブラウザに統合されています。この結合はAsideの強みであると同時に、重要な境界でもあります。Agentがログイン済みページを見られるということは、個人情報や組織データにも届き得るということです。まず読み取り専用の仕事から始め、公開・決済・削除など影響の大きな操作には人の承認を残す方が安全です。
2. Claude Desktop：汎用Agentにブラウザという道具を与える
Claude Desktopは中心軸が異なります。主役はブラウザではなくClaudeであり、ブラウザはClaudeが使える複数の道具の一つです。
2026年9月4日時点で、Claude Coworkのブラウザ制御には主に二つの選択肢があります。
- Claude in Chrome：Chrome拡張機能を通じて、ユーザーが見ているタブとログイン済みアカウントをそのまま使います。ページの読み取り、クリック、入力、フォーム記入、タブ移動が可能です。
- Claude Coworkの内蔵ブラウザ：Claude Desktopのサイドパネルで独立したブラウザを開きます。個人ブラウザのタブやログイン状態とは初期状態で分離され、選んだサイトのCookieを取り込むか、内蔵ブラウザ内で直接ログインできます。
Anthropicの内蔵ブラウザガイドによると、この機能は当時、Pro・Max・Teamと有効化されたEnterprise環境へ段階的に展開中でした。すでにClaude in Chromeを使っている場合はChromeが既定のまま維持され、新しいユーザーには機能が届いた後、内蔵ブラウザが既定になります。設定のPreferred browserで両者を切り替えられます。
Anthropic公式ヘルプセンターの公開比較画面。独立した内蔵ブラウザと、ユーザーがログイン済みのChromeという二つのセッションモデルを説明しています。(出典：Anthropic Help Center、2026-09-04キャプチャ)
Claude in Chrome公式ガイドは、Claudeがページを読み、クリックし、移動し、フォームを記入できると説明しています。Chrome方式は目の前のページでユーザーと並んで作業するときに自然で、内蔵ブラウザはWeb作業を別の空間に任せ、ユーザーが自分のブラウザで作業を続けたいときに向いています。
概念的には次のように整理できます。
- Aside = Agentのために作られたBrowser
- Claude Desktop = Browserを使える汎用Agent
Claudeはブラウザだけでなく、ファイル、コード、コネクタ、MCP、デスクトップアプリも組み合わせられます。Webで資料を探し、ローカル文書を読み、スプレッドシートを作り、結果を要約するまでを一つのワークフローにできます。
また、Browser Useの公式MCP統合ガイドのように、別のブラウザ自動化サーバーをClaude Desktopへ接続することも可能です。この構成ではClaudeが目標と判断を担当し、MCPサーバーがブラウザの実行レイヤーを提供します。
3. Playwright：判断ではなく実行を担う自動化フレームワーク
Playwrightは本質的に実行レイヤーです。Playwrightのコアには、ユーザーの目標を解釈して次の行動を自律的に選ぶLLMはありません。開発者または外部Agentが動作を指定すると、Playwrightがブラウザを正確に制御します。
await page.goto('https://example.com');
await page.getByRole('button', { name: 'Login' }).click();
Playwrightのブラウザ文書によると、Chromium・Firefox・WebKitをサポートし、TypeScript・JavaScriptに加えてPython、.NET、Javaからも利用できます。Playwrightのlocatorガイドは、getByRole、getByLabel、getByTextなど、ユーザーの認識に近いセレクターを優先するよう勧めています。これらのlocatorには自動待機と再試行が組み込まれています。
Playwright公式サイトの公開画面。テスト、スクリプト、AgentワークフローでChromium、Firefox、WebKitを一つのAPIから制御できると説明しています。(出典：Playwright公式サイト、2026-09-04キャプチャ)
2026年のPlaywrightはAI Agentともつながる
「PlaywrightはAIではない」と「PlaywrightはAI Agentで使われない」は別の話です。前者は正しい一方、後者はもはや正しくありません。
現在のPlaywright公式サイトは三つの利用面を示しています。
- Playwright Test：自動待機、assertion、trace、並列実行を備えたE2Eテストランナー
- Playwright CLI：コーディングAgentが効率よくブラウザを制御するためのコマンドラインインターフェース
- Playwright MCP：構造化されたアクセシビリティスナップショットとブラウザ制御ツールをAgentに提供するMCPサーバー
重要なのは、判断レイヤーがPlaywrightの外部に残ることです。人がテストコードを書く場合もあれば、ClaudeのようなAgentがMCPツールを呼び出したり、Playwrightコードをリアルタイムで生成したりする場合もあります。どちらの場合も、Playwrightは目標を決める製品ではなく、指定された行動を実行し検証する基盤です。
決定論的な自動化と状況判断の違い
毎日同じ管理画面を開き、同じボタンを押し、同じ結果を確認する仕事なら、一般にPlaywrightスクリプトの方が予測しやすく、コストも低くなります。入力と検証条件がコードに残るため、失敗箇所を再現しやすく、CIで繰り返し実行できます。
一方、次の依頼は候補を探し、比較し、状況に応じて選ぶ必要があります。
「このサイトで条件に合う商品を探し、比較して最適なものを選んで。」
これをPlaywrightだけで実装するには、選択基準、例外処理、ページの変化、結果の解釈をすべて事前にコード化する必要があります。AsideやClaudeではLLMがその判断を行い、必要なブラウザ操作を実行レイヤーに依頼します。
ただしAgentの「柔軟性」が常に高い信頼性を意味するわけではありません。曖昧なページで判断を誤ることがあり、prompt injectionや過剰な権限といったリスクも生まれます。定型作業はコードで固定し、本当に非定型な判断が必要な部分だけをAgentに任せる混合方式が、実務では最も現実的です。
一覧比較
| 観点 | Aside | Claude Desktopのブラウザ制御 | Playwright |
|---|---|---|---|
| 基本概念 | AI-native Browser | 汎用AI Agent + Browser | Browser Automation Framework |
| 使い方 | 自然言語 | 自然言語 | コード・CLI・MCP |
| LLM内蔵 | あり | あり | コアにはなし |
| 既存ログインの利用 | ブラウザ内で直接利用 | Chromeは直接利用、内蔵ブラウザは選択的に取り込み | 保存済み状態やプロファイルを別途設定 |
| 状況判断 | 強い | 強い | 外部ロジックまたはAgentが必要 |
| 反復作業の再現性 | Agentの実行により変動 | Agentの実行により変動 | 非常に高い |
| テスト自動化 | 探索的QAに有用 | 探索的QAとデバッグに有用 | E2E・回帰テストに最適 |
| 開発知識 | 低い | 低い | コード利用時は高い |
| 例外対応 | 実行中に判断 | 実行中に判断 | 事前実装または外部Agentが必要 |
| 適した用途 | ログイン済みWeb上の日常業務 | Web・ファイル・コードをつなぐ複合作業 | E2E・クローリング・定型自動化 |
何を選ぶべきか
選択基準は製品名よりも、仕事の変動性と再現性への要求にあります。
- 決められた手順を100回繰り返し、結果を検証するなら Playwright が適しています。
- ログイン済みのWeb業務を自然言語で委任し、ブラウザ内で完結させたいなら Aside が便利です。
- ブラウザ作業をファイル・コード・推論・コネクタと一つの流れにまとめたいなら Claude Desktop が合います。
- 前半に判断が必要で、後半に反復実行が必要なら LLM Agent + Playwright の組み合わせが有効です。
結論
三つの違いは「ブラウザをクリックできるか」ではなく、誰が判断し、どこで実行し、何が再利用可能な資産として残るかにあります。
AsideはブラウザとAgentを一つの製品にまとめます。Claude Desktopは汎用Agentに、ユーザーのChromeか独立した内蔵ブラウザかを選ばせます。Playwrightは判断を外部に置き、テストと自動化のための精密な実行レイヤーを提供します。
今後のBrowser Agentは、三つの方式をさらに組み合わせる可能性が高いでしょう。LLMが目標を解釈し、DOMとアクセシビリティツリーで要素を見つけ、Playwright系のコードやツールで操作し、必要なときだけ視覚的Computer Useへ切り替える構造です。実用上の問いは「どの製品が勝つか」より、「この業務では判断と実行をどこまで分けるべきか」に近いのです。
Los LLM están pasando de leer sitios web a hacer clic, escribir y completar tareas directamente en el navegador. Tres enfoques representativos son el sitio oficial de Aside, la página oficial de descarga de Claude Desktop y el sitio oficial de Playwright.
A primera vista, los tres “automatizan el navegador”. La diferencia real está en quién controla el navegador, dónde se toman las decisiones y si el procedimiento de ejecución se genera desde lenguaje natural o queda fijado en código.
A 4 de septiembre de 2026, estos ámbitos están más cerca que antes. Aside usa internamente una interfaz del estilo de Playwright; Claude puede controlar tanto el Chrome del usuario como un navegador integrado independiente; y Playwright admite oficialmente flujos de agentes de IA mediante CLI y MCP. Por eso es más preciso entenderlos como capas distintas de automatización que como simples productos rivales.
| Dimensión | Aside | Control del navegador en Claude Desktop | Playwright |
|---|---|---|---|
| Centro | Agente centrado en el navegador | Agente de propósito general | Capa de ejecución de automatización |
| Entrada principal | Lenguaje natural | Lenguaje natural | Código, CLI o MCP |
| Quién decide | Agente LLM integrado | Claude | Desarrollador o agente externo |
| Sesión del navegador | Sesión del usuario dentro de Aside | Chrome existente o navegador integrado separado | Normalmente un contexto de navegador para automatización |
| Ventaja | Delegar trabajo en sitios autenticados | Tareas complejas entre web, archivos y código | Pruebas reproducibles y automatización estructurada |
1. Aside: el propio navegador es el agente de IA
La característica distintiva de Aside es que se diseñó desde el principio como un navegador compartido por personas y agentes, en lugar de añadir una función de IA junto a un navegador existente. Aside se describe como un navegador reconstruido para “people and agents” y destaca que el agente puede trabajar directamente con correo, paneles, herramientas internas, documentos y hojas de cálculo donde el usuario ya inició sesión.
Por ejemplo, se le puede pedir un resultado de esta forma:
“Busca los pedidos de la semana pasada y organízalos en una tabla.”
El agente recorre las páginas necesarias, localiza elementos, lee datos y produce el resultado. El usuario delega el trabajo dentro del entorno donde ya usa la web, sin trasladar la sesión a un servidor de automatización separado.
Vista pública del producto en la página oficial de Aside. Muestra el área de entrada de IA integrada directamente en la interfaz del navegador. (Fuente: sitio oficial de Aside, captura del 2026-09-04)
Asidewright, árbol de accesibilidad y Computer Use visual
Su arquitectura interna también difiere de un agente que solo hace clic por coordenadas. Según la explicación técnica de Aside, el LLM usa Asidewright, una capa propia compatible con Playwright, desde un entorno de ejecución JavaScript. Asidewright coloca envoltorios ligeros sobre CDP y ofrece una interfaz con la forma de Playwright que los LLM ya conocen.
Para leer las páginas, usa un árbol de accesibilidad modificado que elimina elementos intermedios innecesarios. Cuando el DOM o la información de accesibilidad no bastan, pasa a Computer Use: observa una captura de pantalla y selecciona coordenadas.
Solicitud del usuario
↓
Planificación y decisión del agente de Aside
↓
Asidewright + árbol de accesibilidad
↓ cuando el DOM resulta difícil o hace falta juicio visual
Computer Use basado en capturas
↓
Sesión real del navegador
En otras palabras, Aside reúne en un solo producto:
Browser + automatización estilo Playwright + árbol de accesibilidad + Computer Use visual + agente LLM
La sesión iniciada, la memoria local y el gestor de contraseñas también están integrados en el mismo navegador. Esta combinación es una ventaja y, a la vez, un límite importante. Si el agente puede ver páginas autenticadas, también puede alcanzar datos personales o de la organización. Es más seguro empezar con tareas de solo lectura y mantener la aprobación humana para publicaciones, pagos, eliminaciones y otras acciones con consecuencias.
2. Claude Desktop: dar una herramienta de navegador a un agente general
Claude Desktop tiene otro centro de gravedad. El navegador no es el producto principal; Claude lo es, y el navegador es una de las herramientas que puede usar.
A 4 de septiembre de 2026, Claude Cowork ofrece dos opciones principales de control del navegador:
- Claude in Chrome: una extensión de Chrome que trabaja con la pestaña visible y las cuentas donde el usuario ya inició sesión. Puede leer páginas, hacer clic, escribir, completar formularios y cambiar de pestaña.
- Navegador integrado de Claude Cowork: un navegador independiente dentro del panel lateral de Claude Desktop. Por defecto queda separado de las pestañas y sesiones personales; el usuario puede importar cookies de sitios concretos o iniciar sesión dentro de ese navegador.
Según la guía del navegador integrado de Anthropic, en ese momento la función se estaba desplegando gradualmente en Pro, Max, Team y entornos Enterprise habilitados. Quienes ya usaban Claude in Chrome mantenían Chrome como opción predeterminada; los nuevos usuarios recibían el navegador integrado cuando llegaba a su cuenta. Ambas opciones se pueden cambiar en Preferred browser.
Comparación pública en el centro de ayuda oficial de Anthropic. Explica dos modelos de sesión: un navegador integrado independiente y el Chrome autenticado del usuario. (Fuente: Anthropic Help Center, captura del 2026-09-04)
La guía oficial de Claude in Chrome explica que Claude puede leer, hacer clic, navegar y completar formularios. Chrome resulta natural para trabajar junto al usuario en la página que ya tiene delante; el navegador integrado encaja mejor cuando se quiere delegar la parte web y seguir trabajando en el navegador personal.
En términos conceptuales:
- Aside = un Browser creado para un Agent
- Claude Desktop = un Agent general capaz de usar un Browser
Claude puede combinar el navegador con archivos, código, conectores, MCP y aplicaciones de escritorio. Un solo flujo puede investigar en la web, leer documentos locales, crear una hoja de cálculo y resumir el resultado.
También se puede conectar un servidor de automatización aparte a Claude Desktop, como muestra la guía oficial de integración MCP de Browser Use. En esa configuración, Claude se encarga del objetivo y las decisiones, mientras el servidor MCP aporta la capa de ejecución del navegador.
3. Playwright: un framework de automatización para ejecutar, no para decidir
Playwright es, en esencia, una capa de ejecución. Su núcleo no incluye un LLM que interprete el objetivo del usuario y elija por sí mismo la siguiente acción. Un desarrollador o un agente externo especifica el comportamiento y Playwright controla el navegador con precisión.
await page.goto('https://example.com');
await page.getByRole('button', { name: 'Login' }).click();
La documentación de navegadores de Playwright indica compatibilidad con Chromium, Firefox y WebKit, con enlaces para Python, .NET y Java además de TypeScript y JavaScript. La guía de locators de Playwright recomienda selectores como getByRole, getByLabel y getByText, cercanos a la forma en que las personas perciben la interfaz. Estos locators incorporan espera automática y reintentos.
Vista pública del sitio oficial de Playwright. Explica que una sola API controla Chromium, Firefox y WebKit en pruebas, scripts y flujos de agentes. (Fuente: sitio oficial de Playwright, captura del 2026-09-04)
En 2026, Playwright también se conecta con agentes de IA
“Playwright no es IA” y “Playwright no se usa con agentes de IA” son afirmaciones distintas. La primera es correcta; la segunda ya no lo es.
El sitio oficial actual de Playwright presenta tres superficies:
- Playwright Test: runner E2E con espera automática, assertions, trazas y ejecución paralela
- Playwright CLI: interfaz de línea de comandos para que los agentes de código controlen el navegador de forma eficiente
- Playwright MCP: servidor MCP que ofrece a los agentes capturas estructuradas de accesibilidad y herramientas de control del navegador
La diferencia importante es que la capa de decisión permanece fuera de Playwright. Una persona puede escribir el código de prueba, o un agente como Claude puede llamar herramientas MCP o generar código Playwright en tiempo real. En ambos casos, Playwright es la base que ejecuta y verifica acciones especificadas, no el producto que decide el objetivo.
Automatización determinista frente a juicio situacional
Si una tarea entra cada día en el mismo panel, pulsa el mismo botón y comprueba el mismo resultado, un script de Playwright suele ser más predecible y barato. Las entradas y assertions quedan en el código, por lo que es más fácil reproducir fallos y repetir el flujo en CI.
Esta solicitud, en cambio, exige encontrar candidatos, compararlos y elegir según el contexto:
“Busca en este sitio los productos que cumplan mis condiciones, compáralos y elige el mejor.”
Implementarlo solo con Playwright exige codificar de antemano los criterios, las excepciones, los cambios de página y la interpretación de los resultados. Aside o Claude permiten que el LLM tome esas decisiones y pida a la capa de ejecución las acciones necesarias.
Aun así, la “flexibilidad” de un agente no implica automáticamente mayor fiabilidad. Puede interpretar mal páginas ambiguas y añade riesgos como prompt injection o permisos excesivos. En la práctica, el patrón más realista es fijar en código el trabajo estructurado y delegar al agente solo las partes que requieren juicio abierto.
Comparación rápida
| Dimensión | Aside | Control del navegador en Claude Desktop | Playwright |
|---|---|---|---|
| Concepto básico | AI-native Browser | Agent de IA general + Browser | Browser Automation Framework |
| Forma de uso | Lenguaje natural | Lenguaje natural | Código, CLI o MCP |
| LLM integrado | Sí | Sí | No en el núcleo |
| Reutilizar sesiones | Directamente dentro del navegador | Directo en Chrome; importación opcional en el integrado | Configurar estado guardado o perfil aparte |
| Juicio situacional | Fuerte | Fuerte | Requiere lógica externa o un Agent |
| Repetibilidad | Varía según la ejecución del Agent | Varía según la ejecución del Agent | Muy alta |
| Automatización de pruebas | Útil para QA exploratorio | Útil para QA exploratorio y depuración | La mejor opción para E2E y regresión |
| Conocimientos técnicos | Bajos | Bajos | Altos al escribir código |
| Gestión de excepciones | Decide durante la ejecución | Decide durante la ejecución | Debe preimplementarse o delegarse a un Agent externo |
| Uso ideal | Trabajo cotidiano en sitios autenticados | Trabajo complejo entre web, archivos y código | E2E, crawling y automatización estructurada |
¿Cuál conviene elegir?
La elección depende menos del nombre del producto que de cuánto varía el trabajo y cuánta reproducibilidad necesita.
- Elige Playwright si debes repetir 100 veces un procedimiento definido y verificar el resultado.
- Elige Aside si quieres delegar trabajo web autenticado en lenguaje natural y terminarlo dentro del navegador.
- Elige Claude Desktop si el trabajo del navegador debe combinarse con archivos, código, razonamiento y conectores.
- Elige un agente LLM + Playwright si la primera parte requiere juicio y la segunda ejecución repetible.
Conclusión
La diferencia no es si estas herramientas pueden hacer clic en un navegador, sino quién decide, dónde se ejecutan las acciones y qué queda como activo reutilizable.
Aside reúne navegador y agente en un producto. Claude Desktop permite que un agente general elija entre el Chrome del usuario y un navegador integrado independiente. Playwright deja el juicio fuera y ofrece una capa precisa para pruebas y automatización.
Es probable que los futuros Browser Agents mezclen aún más estos enfoques: un LLM interpreta el objetivo, identifica elementos mediante el DOM y el árbol de accesibilidad, actúa con código o herramientas del estilo de Playwright y pasa a Computer Use visual solo cuando hace falta. La pregunta práctica no es tanto “¿qué producto gana?”, sino “¿hasta dónde conviene separar decisión y ejecución en este flujo?”.