最近科技圈传得比较热闹的一条消息是 Meta 被曝光的超级应用项目 “Project Hatch”。按照外媒和社区的讨论它不只是做一个普通 App而是想通过浏览器和电脑操控能力把拍照、聊天、办公、内容消费等服务装进同一套界面里。换句话说浏览器不再只是“看网页的工具”而可能变成超级应用的入口电脑操控也不再是远程桌面那套老玩法而是由 AI 理解屏幕、理解意图、自动执行任务。这条消息对普通用户来说可能只是“又一个大厂战略”但对开发者来说它直接把一个很现实的问题推到了台前如何用技术让浏览器和应用被别人、被代码、被 AI 操控我在之前的几次项目里也踩过不少类似的坑从浏览器自动化脚本到 AI 辅助操作踩过环境不兼容、元素定位不稳定、安全校验拦截等一系列问题。这篇文章打算把“超级应用、浏览器、电脑操控”这条线索拆开结合可运行的代码示例讲清楚 AI 操控电脑和浏览器的实现思路、工程落地方法以及上线前必须注意的安全边界。无论你是想做自动化办公、爬取数据还是研究 AI Agent这篇文章都值得收藏备用。1. Project Hatch 与“超级应用”背后的技术逻辑1.1 什么是超级应用超级应用Super App这个概念最早在海外被广泛讨论是因为微信、支付宝这类产品把社交、支付、小程序、生活服务全部装进了一个应用里。用户不需要为了打车单独装 App不需要为了点外卖再切换应用所有能力都可以在同一个平台内完成。Meta 的 Project Hatch 之所以被关注是因为它可能把超级应用的思路搬到浏览器上。浏览器天然跨平台不需要用户下载多个客户端网页标准又足够开放适合承载第三方能力。这样一来“超级应用”就不再局限于移动端而是可以在 PC、移动设备甚至未来 AR 设备上共用一套入口。不过“超级应用”听起来很美好工程难度却很大。它至少需要解决三个问题应用框架要能承载多种业务模块。浏览器要能安全地暴露系统能力比如文件系统、摄像头、桌面窗口。开发者需要一套可扩展的插件/权限机制避免第三方模块变成安全漏洞。这也是为什么很多团队在讨论“Project Hatch”时会把重点放在浏览器和电脑操控这两个词上。1.2 为什么浏览器是超级应用的最佳载体浏览器有一个其他客户端很难替代的优势标准统一。HTML、CSS、JavaScript 是事实上的 Web 标准无论用户用 Chrome、Edge 还是 Firefox核心渲染逻辑都一致。在这个基础上浏览器又通过 WebAssembly、WebRTC、File System Access API、Web Serial 等新特性把应用能力延伸到本地硬件和系统层面。这里需要注意浏览器能力越强权限系统就越复杂。比如 File System Access API 允许网页读写本地文件但必须经过用户授权Web Serial 允许网页访问串口设备也要明确提示用户。这些都说明超级应用不是“把网页堆在一起”而是围绕浏览器建立一套完整的权限和交互体系。开发者如果现在就开始布局不需要等 Meta 正式发布 Project Hatch。你可以把浏览器当成一个“超级应用容器”通过浏览器自动化技术让网页应用具备被外部程序调度的能力这就是后面要讲的 AI 操控电脑的基础。1.3 “电脑操控”在 AI 时代意味着什么传统意义上的电脑操控我们通常会想到远程桌面、TeamViewer、向日葵这类工具。它们的核心是“人通过网络控制另一台电脑”由人观察屏幕、作出判断、操作鼠标键盘。这种模式有几个痛点依赖人工判断、操作延迟明显、没法批量执行复杂任务。AI 时代的“电脑操控”则完全换了一套逻辑。AI 先通过截图或 DOM 数据“看”到屏幕内容再把用户的自然语言指令拆解成操作步骤最后自动调用浏览器 API 或无头浏览器接口去执行。比如“打开网页把今天的订单导出来整理成 Excel 发到内部群”这套动作完全可以由 AI Agent 配合浏览器自动化来完成。这也是为什么“怎么用 AI 操控电脑每天干一些固定的活”会成为热门搜索词。很多重复性工作其实都发生在浏览器里登录后台、查询数据、填写表单、下载报表。只要把浏览器自动化能力和 AI 决策能力结合起来就能实现真正的“无人值守”。2. AI 操控电脑的核心技术拆解2.1 从 RPA 到 GUI AgentRPARobotic Process Automation机器人流程自动化大家应该不陌生。传统 RPA 工具通过录制鼠标键盘动作把固定的操作流程保存下来然后循环执行。比如每天早上去某个系统下载报表再填到另一个系统里。传统 RPA 的短板很明显流程一旦写死页面结构稍有变动就会失灵。今天按钮的位置变了或者验证码多了一道脚本就崩了。AI Agent 则把“识别环境”和“执行动作”分开感知层通过截图、DOM 树、无障碍树获取页面状态。决策层由大模型理解用户意图生成下一步动作点击、输入、滚动、等待。执行层调用浏览器自动化框架把动作落到实际页面上。这种架构的容错能力比传统 RPA 强因为 AI 可以根据页面反馈动态调整下一步。但代价是每次执行都可能有推理延迟而且对成本控制要求更高。所以实际工程里通常会把高频固定操作固化成脚本把需要灵活判断的部分交给 AI。2.2 浏览器自动化的常用技术选择要做电脑操控逃不开浏览器自动化。目前社区里最常用的三套方案框架定位适用场景Selenium老牌浏览器自动化Web 端自动化测试兼容性好Playwright新一代自动化框架多浏览器、多标签页、AI Agent 场景PuppeteerChrome/Chromium 专用Node.js 环境轻量、快速我个人更推荐 Playwright原因有三个支持 Chromium、Firefox、WebKit一套代码覆盖多个浏览器。自动等待机制完善页面元素出现之前不会盲目点击。能同时操作多个页面和多个上下文非常适合 AI Agent 这类需要平行任务的场景。下面各个示例会以 Python Playwright 为主。如果你更熟悉 Node.js思路完全一样只是 API 换一层皮。2.3 AI 决策层怎么接入AI 决策层负责两件事理解用户指令、拆解操作步骤。常见的做法有两种调用大模型 API把页面截图、DOM 摘要和用户指令一起发给模型让模型返回 JSON 格式的“下一步动作”。本地规则引擎把常见的任务模板写成配置文件命中模板后直接执行固定步骤。第一种灵活但昂贵第二种稳定但僵化。比较好的工程方案是混合式固定流程走规则引擎异常分支交给 AI 判断。需要特别提醒的是不要把 API Key 硬编码在脚本里。正式项目建议使用环境变量或配置中心管理避免密钥泄露。这也是很多自动化项目上线后被安全团队打回的主要原因。3. 环境准备与版本说明3.1 基础环境下面的示例以常见环境为例具体版本你按自己电脑实际情况调整操作系统Windows 10/11 或 macOS 均可Python3.9 及以上浏览器Google Chrome推荐使用 Chrome 稳定版版本号与驱动自动匹配开发工具VS Code 或 PyCharm如果你的浏览器是 Edge、Firefox也可以直接替换 Playwright 的 browser_type整体思路不受影响。3.2 安装 Python 依赖建议先创建一个虚拟环境避免污染全局 Python 环境python -m venv venv venv\Scripts\activate # Windows # source venv/bin/activate # macOS / Linux然后安装核心依赖pip install playwright playwright install chromium这里解释一下两个命令的区别。第一条命令是安装 Playwright 的 Python 包第二条命令是下载 Playwright 自带的 Chromium 浏览器内核。如果你希望用系统里的 Chrome可以跳过第二条命令在代码里指定 executable_path 指向本机 Chrome。3.3 项目结构规划为了后面扩展方便我建议按这样的目录组织项目ai_agent_demo/ ├── main.py # 程序入口 ├── agents/ │ ├── __init__.py │ ├── planner.py # AI 决策层负责解析指令 │ └── executor.py # 执行层封装浏览器操作 ├── core/ │ ├── browser.py # 浏览器实例管理 │ └── config.py # 配置读取 ├── tasks/ │ └── daily_report.py # 固定任务示例 ├── logs/ │ └── app.log └── requirements.txt这种分层的好处是页面变化只改 executor任务逻辑只改 tasksAI 接口切换只改 planner。即使不接入真正的 AI 模型也能用规则先跑通整条链路。4. 实战用 AI 与浏览器自动化操控电脑完成固定任务接下来进入本文最核心的部分。我们做一个具体的例子通过 AI 指令操控浏览器自动打开一个内部表格页面读取数据再生成一份汇总文件。这个场景非常接近“AI 操控电脑干固定活”的典型需求。4.1 创建项目结构先在项目目录里创建基础文件mkdir -p ai_agent_demo/{agents,core,tasks,logs} touch ai_agent_demo/main.py touch ai_agent_demo/agents/__init__.py touch ai_agent_demo/agents/planner.py touch ai_agent_demo/agents/executor.py touch ai_agent_demo/core/__init__.py touch ai_agent_demo/core/browser.py touch ai_agent_demo/core/config.py touch ai_agent_demo/tasks/daily_report.py touch ai_agent_demo/requirements.txtWindows CMD 下如果没有 touch 命令可以手动创建这些文件。4.2 编写浏览器管理模块先来看core/browser.py。这个模块负责创建浏览器实例和页面对象后续所有任务都从这里获取页面。# 文件路径ai_agent_demo/core/browser.py from playwright.sync_api import sync_playwright class BrowserManager: 统一管理浏览器生命周期 def __init__(self, headless: bool True): self.headless headless self._playwright None self.browser None def start(self): self._playwright sync_playwright().start() # 这里用 chromium也可以换成 firefox 或 webkit self.browser self._playwright.chromium.launch( headlessself.headless, args[ --disable-blink-featuresAutomationControlled, --no-sandbox, ], ) return self def new_page(self): context self.browser.new_context( viewport{width: 1280, height: 800}, localezh-CN, ) page context.new_page() return page def stop(self): if self.browser: self.browser.close() if self._playwright: self._playwright.stop()这里有几个点需要解释headlessTrue表示无头模式浏览器不显示界面适合服务端跑定时任务。本地调试建议改成False方便观察操作过程。--disable-blink-featuresAutomationControlled可以降低网站检测自动化脚本的概率但它不能保证完全绕过检测正式爬取或自动化需要遵守网站规则和法律法规。每次调用new_page都创建新的上下文上下文之间互相隔离适合多任务并行。4.3 配置管理模块core/config.py负责读取环境变量和配置文件。这里我以读取系统环境变量为主# 文件路径ai_agent_demo/core/config.py import os def get_env(key: str, default: str ): 读取环境变量避免把敏感信息硬编码到代码里 value os.getenv(key, default) if not value and not default: raise ValueError(f缺少环境变量: {key}) return value def get_page_url(): 示例任务的目标页面地址。 你可以替换成自己内部系统的真实地址。 return get_env(TARGET_PAGE_URL, https://example.com/data)实际项目里建议把 URL、账号、API Key 放在.env文件里用python-dotenv加载而不是直接写在代码中。这里为了示例简单就不引入额外库了。4.4 编写执行层封装浏览器操作agents/executor.py是执行层负责把“动作”落到真实页面上。它不关心用户指令是什么只关心“点击”“输入”“提取”这些基础能力。# 文件路径ai_agent_demo/agents/executor.py from playwright.sync_api import Page class Executor: 浏览器操作执行器 def __init__(self, page: Page): self.page page def open(self, url: str): self.page.goto(url, wait_untildomcontentloaded) self.page.wait_for_timeout(1000) def click(self, selector: str, timeout: int 10000): 点击匹配的元素。 如果元素被遮挡可以先滚动到可见区域。 element self.page.locator(selector).first element.scroll_into_view_if_needed(timeouttimeout) element.click(timeouttimeout) def fill(self, selector: str, value: str): self.page.locator(selector).first.fill(value) def extract_text(self, selector: str): return self.page.locator(selector).first.text_content() def extract_table(self, table_selector: str table): 提取页面表格数据并转成列表。 这个代码假设页面是一个标准 HTML table。 rows self.page.locator(f{table_selector} tr).all() result [] for row in rows: cells row.locator(th, td).all_text_contents() result.append([cell.strip() for cell in cells]) return result def screenshot(self, path: str): self.page.screenshot(pathpath, full_pageTrue)这里特别说明一下wait_for_timeout(1000)。强制等待在真实项目中应该尽量少用推荐用 Playwright 的内置自动等待。但有些页面有比较复杂的异步渲染先加一个兜底等待能避免早期调试阶段频繁踩空。4.5 编写 AI 决策层Planneragents/planner.py是 AI 决策层。我们先写一个“规则版”的 planner它根据指令关键词返回动作列表。这样做的好处是即使没有大模型 API也可以先把整条链路跑通。# 文件路径ai_agent_demo/agents/planner.py import json class RulePlanner: 基于规则的任务规划器。 真实项目里可以替换成 LLM API 调用。 planner 的职责是把用户自然语言指令转换成一个 JSON 动作列表。 def __init__(self, rules: dict): self.rules rules def plan(self, user_instruction: str) - dict: # 简单的关键词匹配 for keyword, action in self.rules.items(): if keyword in user_instruction: return action return {action: unknown} # 示例规则表 DEFAULT_RULES { 提取表格: { action: extract_table, selector: table, }, 点击查询: { action: click, selector: #query-btn, }, 打开页面: { action: open, url: None, # 运行时从 config 补充 }, } def build_planner(): return RulePlanner(DEFAULT_RULES)如果要接入真实大模型可以把plan方法改成调用大模型 API并让大模型返回固定格式的 JSON。例如让模型输出{ action: fill, selector: #keyword, value: 笔记本 }这样 executor 就能直接消费这个 JSON。接入大模型后决策能力会更强但一定要控制好返回格式避免模型输出无法解析的文本。4.6 固定任务模块tasks/daily_report.py是固定任务示例。我们把它拆成几步打开页面 → 点击查询 → 提取表格 → 保存数据。# 文件路径ai_agent_demo/tasks/daily_report.py import csv from agents.executor import Executor def run_daily_report(executor: Executor, page_url: str): 每日报表提取任务 1. 打开目标数据页 2. 点击查询按钮 3. 提取表格数据 4. 写入 CSV 文件 print([任务开始] 打开页面:, page_url) executor.open(page_url) print([任务开始] 点击查询按钮) executor.click(#query-btn) print([任务开始] 提取表格) table_data executor.extract_table(table) if not table_data: print([警告] 表格没有返回数据请检查页面是否正常渲染) return output_file output.csv with open(output_file, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerows(table_data) print(f[任务完成] 数据已保存至 {output_file})这里有几个工程细节使用utf-8-sig编码可以让 Excel 直接打开 CSV 时不乱码。如果表格为空不应该直接生成空文件最好先告警或者重试。真实系统中建议把输出文件统一放到output/目录并按日期命名方便归档。4.7 主入口 main.pymain.py负责编排所有模块。这里我提供了一个双层模式如果没有 AI 指令就执行固定任务如果传入 AI 指令就走 planner → executor 的链路。# 文件路径ai_agent_demo/main.py import sys from agents.executor import Executor from agents.planner import build_planner from core.browser import BrowserManager from core.config import get_page_url from tasks.daily_report import run_daily_report def main(): # 支持两种运行方式: # 1. python main.py - 执行固定任务 # 2. python main.py 提取表格 - 按 AI 指令执行 user_instruction sys.argv[1] if len(sys.argv) 1 else manager BrowserManager(headlessFalse) manager.start() try: page manager.new_page() executor Executor(page) page_url get_page_url() if user_instruction: planner build_planner() plan planner.plan(user_instruction) print([Planner] 动作计划:, plan) if plan.get(action) extract_table: executor.open(page_url) executor.click(#query-btn) data executor.extract_table(plan.get(selector, table)) print(提取到数据条数:, len(data)) else: run_daily_report(executor, page_url) # 调试时保留窗口方便观察正式环境可以去掉 input(按回车键关闭浏览器...) except Exception as exc: print(执行出错:, exc) finally: manager.stop() if __name__ __main__: main()运行命令python main.py如果要按 AI 指令运行python main.py 提取表格预期结果浏览器自动打开目标页面点击查询按钮提取表格数据并在控制台输出条数。如果你想观察页码渲染过程可以把headless改成False然后手动确认浏览器每一步是否正常。4.8 结果说明上面这个示例虽然还不算真正的“AI Agent”但它已经具备了 AI 操控电脑的基本骨架决策层planner 决定动作。执行层executor 操作真实浏览器。任务层daily_report 定义固定流程。如果后面要接大模型你只需要替换 planner 的内部实现让模型根据用户输入生成动作序列。比如用户说“打开订单管理页面搜索昨天的订单下载 excel”模型输出一个包含 open、fill、click、download 的动作列表executor 按顺序执行即可。这也是目前很多主流 AI 电脑操控产品的底层逻辑。5. 安全边界与合规提示5.1 “远程操控”提示是什么意思有时候你正在用自动化工具电脑忽然弹出“企业微信提示电脑上有远程操控”或者浏览器提示“您的浏览器由贵单位管理”。这通常是因为安全软件检测到了鼠标键盘事件被外部进程接管或者浏览器证书、策略被修改。这种提示本身不代表你的电脑被入侵但它说明一个事实任何对浏览器的自动化操控本质上都是在模拟人工操作很容易触发安全机制。在做自动化项目时一定要提前和公司安全团队沟通明确哪些系统允许自动化哪些系统禁止自动化。不要在自己没有权限的系统上跑这类脚本否则可能涉及合规风险。5.2 权限最小化原则我自己踩过的坑是一开始图省事直接给脚本赋了管理员权限结果后期不管跑什么都要弹 UAC而且脚本一旦被恶意改动影响面非常大。正确的做法是使用非管理员账号运行自动化脚本。只给浏览器授权必要的站点权限不要全局开放。涉及文件读写时把脚本限制在指定目录内。生产环境使用独立虚拟机或容器运行自动化服务。5.3 登录态与账号安全自动化项目通常会遇到登录态问题。很多系统的登录态有设备绑定和风控策略脚本频繁切换 IP 或频繁操作可能触发账号异常。建议优先使用测试账号不要拿核心业务账号当自动化脚本的“小白鼠”。使用 Playwright 的 storage_state 机制保存登录态而不是每次重复输入密码。密码不要硬编码在脚本里使用环境变量或密钥管理服务。范例# 保存登录态 context.storage_state(pathstate.json) # 之后恢复登录态 context browser.new_context(storage_statestate.json)这个方案可以显著降低自动化的登录失败率。6. 常见问题与排查思路6.1 常见报错合集问题现象常见原因解决思路Playwright 报 chromium 未安装只安装了 Python 包没有下载浏览器内核执行playwright install chromium页面元素定位不到页面是 iframe 或 Shadow DOM使用 frame_locator 或遍历 shadow root点击按钮没有反应按钮处于禁用状态或页面加载未完成增加等待条件检查元素状态控制台报“浏览器由贵单位管理”浏览器策略被系统接管改用本地开发浏览器或使用独立用户数据目录CSV 打开乱码编码用了 utf-8改用 utf-8-sig 写文件脚本被风控拦截操作频率过高或设备指纹明显降低频率、随机延迟、使用真实浏览器内核6.2 定位元素不稳定怎么办这是浏览器自动化最让人头疼的问题。页面结构一变selector 就失效。我的建议是按照下面的优先级选择定位方式语义化属性#id、[data-testidsubmit]、name。文本内容text登录。结构关系.form内部的.button。最后才用绝对路径html body div ...。不要一上来就复制 XPath 绝对路径那种写法非常脆弱。推荐优先请前端工程师在页面上埋># tasks/query.yaml name: 查询任务 steps: - action: open url: https://example.com/data - action: wait time: 1000 - action: click selector: #query-btn - action: extract_table selector: table output: output.csv然后在代码里写一个通用的配置执行器。这样新增一个任务只需要新增一份 YAML不需要重新写 Python 逻辑。后续如果想接入 AI 决策只需要让模型输出类似结构的 YAML 或 JSON执行引擎完全复用。7.2 日志与可观测性自动化脚本是典型的“无人值守系统”日志就是唯一的眼睛。我觉得至少要做到三件事每个关键步骤输出日志。异常发生时保留页面截图。任务结束发送通知邮件、企业微信机器人、钉钉机器人。截图在排查定位问题时价值极高。你可以在异常分支里加一句except Exception as exc: page.screenshot(pathlogs/error.png, full_pageTrue) logger.error(任务失败: %s, exc)7.3 异常重试与幂等设计自动化任务经常遇到网络抖动、页面渲染慢、接口超时等问题。最简单可靠的策略是“重试”但重试必须考虑幂等性。比如“下载报表”这个操作重试一次可能生成两份报表业务上可能无法接受。我的建议是把任务拆成“无副作用准备动作”和“有副作用提交动作”。准备动作可以随意重试提交动作需要加上唯一任务 ID在服务端做去重。这样即使任务中断也不会产生脏数据。7.4 生产环境的隔离部署如果你准备把 AI 操控电脑的能力部署到服务器上而不是只在本地跑我强烈建议使用容器或虚拟机隔离避免脚本影响宿主机。给脚本分配独立用户禁止使用 root/Administrator。限制网络访问范围只允许访问必要域名。监控 CPU、内存、网络流量防止脚本失控。8. 总结与下一步学习方向这篇文章从 Meta “Project Hatch”超级应用曝光入手梳理了“浏览器 电脑操控”背后的技术逻辑并带你完成了一个 AI 操控浏览器的雏形项目。你至少应该掌握以下关键能力理解超级应用与浏览器自动化的关系。掌握 Playwright 的基本用法打开页面、定位元素、提取数据、保存登录态。理解 AI Agent 的感知、决策、执行三层架构。能够用“规则 planner executor”搭建最小可用自动化项目。知道在真实项目中如何设计异常重试、日志留痕和权限隔离。如果你对下一步学习方向还拿不准我建议按这个顺序深入先巩固浏览器自动化把 Playwright 官方文档里的例子多跑几遍。再研究 AI 决策层试着接入一个大模型 API把 RulePlanner 替换成 LLM Planner。然后做工程化加入定时调度、通知、日志、错误恢复。最后考虑多机分布式让多台机器分工执行不同的浏览器任务。实际项目里安全合规永远要排在效率前面。不要拿自动化脚本挑战没有授权的系统也不要为了“看起来智能”而让 AI 直接操作生产环境。把稳定的部分用规则固化把灵活的部分交给 AI这是目前最务实的落地方式。希望这篇文章能帮你少走一些弯路。如果你在配置或者运行过程中遇到问题可以参考文中的排查表格逐项比对。收藏备用需要的时候直接查。