WeWorker explains its tool-based browser-agent architecture
WeWorker’s team describes moving from screenshot-based computer use to schema-defined browser tools after finding that pixel-driven failures were difficult to diagnose and sensitive to interface changes. The open-source project uses a unified Adapter contract with Chrome extension and Playwright/CDP execution backends, while placing write-operation confirmation policies in versioned manifests rather than model-supplied parameters. It also explores generating and validating read-only site adapters automatically, while retaining manual adapters for difficult sites.
The first-party architecture account offers practical guidance for browser-agent developers on structured errors, adapter discovery, execution backends, routing, and package-level safety controls, although its comparisons and performance claims have not been independently validated.
引子
「让 AI 操作浏览器」基本收敛成两条路线。
一条是像素派：截图喂给多模态模型，模型输出坐标，点下去。代表是各种 computer-use 方案。
另一条是工具派：把网站能力封装成带 schema 的确定性工具，模型只负责选工具、填参数。
我们做 WeWorker 时选了第二条。不是因为它更新，而是因为在真实场景里跑了一个月之后，像素派的三个问题没有一个能靠模型升级解决。
这篇文章讲清楚：为什么换路线、Adapter 到底是什么、以及我们为一个「写操作」的安全边界返工了三次。
#WeWorker#WebCLI#Adapter#Chrome Extension#Playwright#Chrome DevTools Protocol#Electron#TypeScript