Page-Agent：把大模型放进前端 DOM 里的新做法
传统自动化脚本还在费劲找节点时，Page-Agent 已经能在网页里直接读懂表单、填字段，然后把最后一步留给人确认。
Page-Agent 这类项目真正有意思的地方，不是'又一个浏览器自动化工具'，而是它把智能体放回了浏览器里。它不靠单独的后端服务跑任务，也不要求你先搭一套 Python、Node.js 或无头浏览器环境；多数情况下，直接在页面里引一段 JavaScript，就能让它开始工作。
这听起来像是把很多复杂问题都省掉了，但代价也很明确：它更适合接管当前页面内的交互，尤其是那些登录态已经在浏览器里、操作又比较重复的业务系统。做 ERP、CRM、报销、后台报表这类场景时，省事得很；要是想做跨系统、跨标签页的完整流程，就得再加浏览器扩展配合。
它到底是什么
如果把传统的 Playwright、Puppeteer 看作'远端脚本控制浏览器'，Page-Agent 更像是'住在页面里的操作层'。它运行在当前网页环境中，能直接拿到 DOM、用户会话和当前页面状态，然后把自然语言意图翻成具体的点击、输入、滚动动作。
这套思路最大的变化，不是自动化能力本身，而是感知方式和运行位置。以前常见做法是把页面截图给多模态模型，让模型找坐标；Page-Agent 走的是另一条路：先把 DOM 做一次压缩，只保留可交互节点，再把这份轻量结构交给大模型推理。对很多网页来说，这比盯着截图找按钮稳定得多，也便宜得多。
| 维度 | 传统自动化（Puppeteer / RPA） | Page-Agent |
|---|---|---|
| 运行环境 | 通常依赖 Node.js、Python 或独立浏览器进程 | 直接跑在当前页面的 JavaScript 环境里 |
| 识别方式 | 常见是截图或视觉模型识别 | 读取并压缩 DOM，再交给大模型 |
| 交互位置 | 多在后台，用户看不到执行过程 | 直接在页面里浮层交互，支持人工确认 |
它的架构，拆开看并不复杂
Page-Agent 大致可以分成三层：页面内的执行核心、DOM 解析层、可插拔的大模型客户端。组合起来以后，页面负责给上下文，模型负责决策，执行核心负责落地动作。
用户输入自然语言
-> Page-Agent UI（浮层面板）
-> DOM Parser（提取可交互节点并脱敏）
-> LLM Client（根据任务做决策）
-> Agent Core（在页面里执行 click / input / scroll）
Agent Core 负责真正的页面操作。它直接调用浏览器原生 API，模拟点击、输入、滚动，也能借助当前页面已经有的 Cookie、Local Storage 和 Session。这个点很实用，因为很多企业系统最麻烦的不是'怎么点'，而是'怎么登录后还能点'。
DOM Parser 干的活更像整理现场。它不会把整页乱七八糟的结构都扔给模型，而是过滤掉大量纯展示节点，只留下按钮、输入框、链接这些真正能操作的元素，再把文本、aria-label 之类的信息压成更短的结构。页面越大，这一步越值钱。
LLM Client 则保持模型无关。你可以接 Claude 3.5 Sonnet、GPT-4o，也可以切到通义千问、DeepSeek-V3；如果企业对数据边界要求比较严，接 Ollama 这类本地模型也说得通。Page-Agent 本身更像一层执行框架，不把模型绑死，后面换大脑不会太痛。
为什么它和传统自动化不一样
我更愿意把它理解成一种'网页级 Copilot'，而不是单纯的自动化脚本。原因很简单：它没有试图把所有流程都做成后台任务，也没有假装自己比用户更懂业务；它只是把人类在网页上的重复动作接过来，尤其是在表单、列表、筛选、导出这些场景里。
它的几个关键点比较实际：
- 接入成本低，很多时候一行脚本就够了。
- 不依赖视觉模型，操作速度和成本都更友好。
- 由于在页面内运行，天然继承登录态，少了不少鉴权折腾。
- 支持人机协同，高风险动作可以停在提交前，让人来拍板。
这里面最值得保留的是'停一下'的设计。自动填表、自动筛选、自动准备数据都可以交给它，但最后提交、发送、删除这种动作最好还是留给人。这个边界不优雅，却很管用。
适合什么场景
Page-Agent 最容易落地的地方，还是那些'页面复杂但流程重复'的系统。
