BrowserPilot：一个 Web Agent 的架构设计

Fri, 22 May 2026 15:29:33 +0800

嫌投简历太耗时间，于是开始研究浏览器自动化。

GitHub 上有个著名的开源自动投简历项目，体验很差——拿源码编译、配一堆依赖，跑起来各种报错。不喜欢，自己动手做了 JobPilot：找 CSS 选择器写死自动化流程，把抓到的数据丢给 AI 判断 JD 是否匹配、生成打招呼语。勉强能用。

后来 Boss 直聘升级了 antbot 反爬机制，检测到 Playwright 连接就直接关网页或者无限刷新。写死选择器的路子彻底失效——你精心调试的定位逻辑，对方一个更新就全废了。

再后来用了 Comet——Perplexity 做的浏览器，思路打开了：不用写死选择器，让 AI 直接看着网页操作。Comet 是包月的，有用量额度，但没筛几个简历，日/周用量就没了。每一步操作都是 AI 在做视觉推断：看截图，想一下该点什么，点完再看截图，再想下一步。一个完整的投简历流程跑几十步，每一步都在消耗用量。

单模型方案在面对网页时必须选择旗舰模型，成本高，而且慢。

于是，我想到了把“思考”和“执行”拆开，用两个 AI 来分别负责。

主管-执行器双层架构 Link to heading

主管层（Workspace / Supervisor）用的是旗舰级推理模型，比如 GLM 5.1、Gemini 3 Pro。它不负责具体操作，只负责理解用户意图，与用户对话，拆解任务，派发任务给执行器。调用频率低，但每次调用都做重要决策。

执行器层（ExecutionTask / Executor）用的是足够便宜的模型。对它的要求不高——能看明白 snapshot，能在网页截图里找到应该点哪个按钮就行。它不关心全局目标，只拿着主管给的指令，看着网页，一步步执行点击、输入、滚动这些动作。调用频率高，但每次调用的成本很低。

中间还有一层 UI 交互层，接收用户的模糊意图，实时展示 AI 的执行步骤和截图。做 Agent 不能做成黑盒——用户得能看到它在看什么、在想什么，否则出了问题无从排查。

这个分层源于对成本的现实妥协。在单模型方案下，每步交互都用旗舰模型进行视觉推理，成本完全不可控。

拆分后，高频、重复的执行步骤交由廉价模型，而低频的主管层仅做关键决策。两三次的旗舰模型调用配合几十次的廉价模型调用，将总成本拉回了合理区间。

廉价模型的现实 Link to heading

执行层必须用便宜模型，因为网页交互要不断抓 snapshot、做判断——如果每一步都用旗舰模型，每一步都在烧钱。但便宜模型到底能不能用？

AI on Nexus

BrowserPilot：一个 Web Agent 的架构设计

主管-执行器双层架构 Link to heading

廉价模型的现实 Link to heading