1. 项目概览
| 项目 | 信息 |
|---|---|
| GitHub | alibaba/page-agent |
| 官方 Demo / 文档 | https://alibaba.github.io/page-agent/ |
| 项目定位 | JavaScript in-page GUI agent,用自然语言控制 Web 界面 |
| 开源协议 | MIT |
| 主要语言 | TypeScript |
| npm 包 | page-agent |
| 最新 npm 版本 | 1.10.0,检查日期:2026-06-27 |
| 最新 GitHub Release | v1.10.0,发布于 2026-06-15,检查日期:2026-06-27 |
| GitHub 热度 | 约 20.3k stars、1.75k forks,检查日期:2026-06-27 |
| 关键组件 | page-agent、@page-agent/core、@page-agent/page-controller、@page-agent/llms、@page-agent/ui、@page-agent/mcp、Chrome Extension |

2. 一句话解释
Page Agent 可以理解为“嵌入你网页里的 AI 操作员”:开发者在网页里引入一段 JS 或 npm 包,配置支持 tool call 的 LLM 后,用户就可以输入“帮我打开设置并修改通知方式”“填写这张报销单”“搜索某个订单并导出结果”等自然语言指令,由 Agent 读取页面 DOM、规划动作并完成点击、输入、选择、滚动等操作。
它与传统浏览器自动化工具的区别在于:
| 维度 | Page Agent | 传统浏览器自动化 / RPA / browser-use 类工具 |
|---|---|---|
| 面向对象 | 网站开发者、SaaS 产品团队 | 自动化脚本开发者、爬虫/Agent 开发者 |
| 部署方式 | 嵌入页面内运行,也可配 Chrome 扩展 | 通常在浏览器外部、服务端或自动化运行时执行 |
| 主要目的 | 增强产品用户体验,把网页变成可自然语言操作的应用 | 自动执行任务、采集数据、控制浏览器 |
| 感知方式 | 主要基于 DOM 文本和结构,不依赖截图 | 可能使用 DOM、截图、多模态、浏览器控制协议 |
| 基础范围 | 当前页面;多页面能力需要 Chrome Extension | 可控制整个浏览器上下文 |
3. 关键截图
Demo 首页

这张图适合放在售前材料里说明 Page Agent 的产品感知:用户在当前网页中输入自然语言任务,页面内 Agent 帮用户完成操作。截图中也能直接看到官方强调的卖点:纯前端方案、支持私有模型、无需脱敏、MIT 开源。
Chrome 扩展能力

Chrome Extension 是可选增强能力。PageAgent.js 本身负责页面内自动化;扩展额外提供多页面任务、浏览器级控制,以及从浏览器外部发起任务的能力。
模型配置与支持

官方文档强调支持符合 OpenAI API 规范且支持 tool call 的模型,包含公有云和本地/私有部署路径。售前沟通时要注意:模型是否支持稳定 tool call、上下文长度是否足够、是否需要企业侧代理转发 LLM 请求,会直接影响落地效果。
4. 它主要能做什么
| 能力 | 说明 | 售前价值 |
|---|---|---|
| 自然语言操作网页 | 用户输入任务,Agent 自动点击、输入、选择、滚动、提交表单 | 降低复杂系统学习成本,减少培训和客服压力 |
| DOM 文本理解 | 通过 DOM 结构和页面文本理解界面,不依赖截图和多模态模型 | 成本更可控,适合业务系统、表单系统、管理后台 |
| 页面内嵌 AI Copilot | 通过 CDN 或 npm 集成到 Web 应用 | 对既有 SaaS 或内部系统改造成本较低 |
| 自带 UI Panel | 可以展示任务执行、进度和交互面板 | 更容易做产品化演示和用户体验闭环 |
| 自备 LLM | 支持 OpenAI-compatible API,包括百炼 Qwen、OpenAI、Claude、DeepSeek、Gemini、本地 Ollama/LM Studio 等路线 | 可适配客户已有模型资源和私有化诉求 |
| 数据脱敏 | 支持对页面内容做 masking 后再发给模型 | 适合对隐私、合规较敏感的企业场景 |
| 自定义指令和知识注入 | 可通过系统级/页面级 instruction 约束 Agent 行为 | 可把业务规则、操作规范、权限边界固化进 Agent |
| 自定义工具 | 可扩展 Agent 可调用能力 | 可对接业务 API、校验逻辑、审计动作 |
| Chrome Extension | 支持多页面、多标签和浏览器级控制 | 适合跨系统、跨页面流程,但安全授权要求更高 |
| MCP Server Beta | 让本地 Agent 客户端通过 MCP 向 Page Agent Ext 发起浏览器任务 | 适合把浏览器控制能力接入 Claude Desktop、Copilot、企业 Agent 平台等 |
5. 典型适用场景
| 场景 | 客户痛点 | Page Agent 可以怎么切入 |
|---|---|---|
| SaaS AI Copilot | 产品功能多、页面复杂,新用户不会用,高频咨询集中在“怎么操作” | 在页面内加入自然语言入口,让 AI 直接带用户完成操作 |
| ERP / CRM / OA / HR / 财务系统 | 表单多、流程长、字段多,用户容易填错或漏填 | 用户描述目标,Agent 自动定位字段、填写、提交或提示确认 |
| 管理后台智能化改造 | 老系统 UI 改造成本高,但一线希望提升体验 | 通过页面嵌入方式先做 Copilot 层,不必立即重构核心业务系统 |
| 客服机器人升级 | 机器人只能回答“请点击某某按钮”,用户仍要自己操作 | 将答疑机器人和 Page Agent 结合,从“告诉用户怎么做”升级为“帮用户现场做” |
| 产品教学 / Onboarding | 新功能上线后需要培训、录屏、文档维护 | 让 AI 现场演示完整流程,例如“演示如何提交报销申请” |
| 无障碍交互 | 老年用户、视障用户、低数字化熟练用户使用复杂页面困难 | 通过自然语言、语音助手、屏幕阅读器等入口降低操作门槛 |
| 内部运营提效 | 运营人员需要重复在后台检索、筛选、录入、导出 | 让 Agent 完成可控的半自动操作,减少重复点击 |
| 企业 Agent 平台连接浏览器 | 企业已有 Agent 能问答和调用 API,但缺少网页 GUI 操作能力 | 通过 Chrome Extension + MCP Server 把浏览器任务纳入 Agent 工具链 |
6. 不太适合的场景
| 场景 | 原因 |
|---|---|
| 大规模网页爬取、服务端自动化 | 官方明确 Page Agent 面向客户端网页增强,不是服务端自动化工具 |
| 主要依赖图片、Canvas、WebGL、SVG 视觉识别的页面 | Page Agent 不使用多模态模型和截图,主要基于 DOM 文本结构理解页面 |
| 需要拖拽、悬停、右键菜单、键盘快捷键、坐标级控制的流程 | 官方限制中说明这些交互不属于当前主要支持范围 |
| 复杂跨域 iframe、嵌套 iframe 场景 | 官方文档仅强调同源单层 iframe 支持,跨域/嵌套 iframe 是边界 |
| 强监管、强资金风险的全自动交易/审批 | 可以作为辅助入口,但必须加确认、权限、审计、风控和回滚机制 |
| 页面语义化很差的老系统 | DOM ��构、可访问性和页面语义会直接影响 Agent 成功率,需要先做页面治理 |
| 无法提供稳定 tool call 模型的客户环境 | Agent 依赖模型稳定地产生工具调用,小模型或 tool call 能力弱的模型效果通常不佳 |
7. 架构和组件理解
官方开发指南显示 Page Agent 是 npm workspaces monorepo,核心包可以这样理解:
| 包 / 模块 | 作用 |
|---|---|
page-agent | 主入口,包含内置 UI Panel,面向应用集成 |
@page-agent/core | 不带 UI 的核心 Agent 逻辑,适合自定义 UI 或程序化调用 |
@page-agent/llms | LLM 客户端,封装 OpenAI-compatible 调用、重试、tool call 等 |
@page-agent/page-controller | DOM 操作、页面结构提取、视觉反馈,与 LLM 解耦 |
@page-agent/ui | Panel、国际化等 UI 能力 |
@page-agent/mcp | MCP Server,用于让本地 Agent 客户端通过扩展控制浏览器 |
packages/extension | Chrome Extension,基于 WXT + React |
packages/website | 官网、文档和开发 playground |
简化工作流
扩展与 MCP 的关系
售前解释时可以这样讲:基础版是在客户自己的 Web 应用里嵌一个页面内 AI 操作员;如果要跨页面、跨标签或让外部 Agent 控制浏览器,就需要引入 Chrome Extension 和 MCP Server。
8. 怎么用
方式一:Demo CDN 快速体验
官方提供一行脚本方式用于技术评估:
中国镜像:
注意:官方 Demo CDN 使用免费测试 LLM API,仅适合技术评估和研发测试,不应直接用于生产环境,也不应输入个人身份信息或敏感数据。
方式二:npm 集成
npm install page-agent
import { PageAgent } from 'page-agent'
const agent = new PageAgent({
model: 'qwen3.5-plus',
baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
apiKey: 'YOUR_API_KEY',
language: 'zh-CN',
})
await agent.execute('点击登录按钮')
方式三:生产环境建议
如果要集成到企业 Web 应用,官方文档建议不要把真实 LLM API Key 放到前端代码中,更合理的方式是由企业后端代理转发 LLM 请求,并在代理层做鉴权、审计、限流、脱敏和模型路由。
const agent = new PageAgent({
baseURL: '/api/llm-proxy',
model: 'gpt-5.1',
customFetch: (url, init) =>
fetch(url, { ...init, credentials: 'include' }),
})
方式四:MCP Server Beta
如果客户已有本地 Agent 客户端,可以通过 @page-agent/mcp 接入:
{
"mcpServers": {
"page-agent": {
"command": "npx",
"args": ["-y", "@page-agent/mcp"],
"env": {
"LLM_BASE_URL": "https://api.openai.com/v1",
"LLM_API_KEY": "sk-xxx",
"LLM_MODEL_NAME": "gpt-5.2"
}
}
}
}
官方说明 MCP Server 仍是 Beta,售前演示可以用,但生产落地要特别关注安全授权、稳定性和版本兼容。
9. 售前可以怎么讲
面向业务方
| 客户关注点 | 推荐话术 |
|---|---|
| 用户不会用复杂系统 | “它不是再做一个问答机器人,而是让 AI 直接在系统里帮用户操作,把培训文档和操作步骤变成可执行的交互。” |
| 填表/审批流程很长 | “适合把 20 次点击和多字段填写压缩成一句自然语言指令,尤其适合 ERP、CRM、OA、财务报销这类表单密集场景。” |
| 不想大改旧系统 | “它是页面内嵌式方案,可以先在现有 Web 应用上加一层智能操作入口,降低重构成本。” |
| 客服压力大 | “传统客服机器人只能告诉用户怎么点,Page Agent 可以让机器人进一步帮助用户完成操作。” |
| 需要国产模型或私有模型 | “它支持 OpenAI-compatible 接口和本地模型路径,理论上可以对接客户已有大模型平台,但要验证 tool call、上下文长度和 CORS/代理配置。” |
面向技术方
| 技术问题 | 推荐说明 |
|---|---|
| 怎么集成 | “CDN 可快速体验,生产建议 npm 包集成,并通过后端代理 LLM 请求。” |
| 是否需要浏览器插件 | “当前页面内自动化不需要插件;跨页面、多标签、外部 Agent 调用才需要 Chrome Extension。” |
| 是否依赖截图/视觉模型 | “不依赖截图和多模态,主要走 DOM 文本结构,因此对语义化 HTML 和可访问性要求更高。” |
| 安全怎么做 | “需要结合操作白名单、数据脱敏、用户确认、权限控制、后端代理、审计日志一起设计。” |
| 模型怎么选 | “优先选 tool call 稳定、速度快、上下文足够的模型。小模型或 tool call 弱的模型通常不适合复杂页面操作。” |
10. PoC 建议
推荐 PoC 目标
选择一个客户熟悉、痛点明确、风险可控的流程,例如:
| PoC 流程 | 验证价值 |
|---|---|
| CRM 新建客户并补全字段 | 验证表单填写、字段定位、业务规则提示 |
| OA 提交请假/报销申请 | 验证多步骤流程、确认动作、用户交互 |
| 后台搜索订单并导出 | 验证检索、筛选、点击、下载前确认 |
| 产品教学“演示如何配置某功能” | 验证边做边教和培训降本 |
| 客服机器人代操作 | 验证从问答到执行的体验升级 |
PoC 范围控制
| 项目 | 建议 |
|---|---|
| 页面选择 | 优先选择 DOM 语义清晰、表单结构标准、交互路径稳定的页面 |
| 任务数量 | 先做 3-5 个高频流程,不要一开始覆盖全系统 |
| 模型选择 | 先用强 tool call 模型打通效果,再评估国产/私有模型替换 |
| 安全边界 | 高风险动作必须加入二次确认,例如提交、删除、转账、审批通过 |
| 指标 | 成功率、平均完成时间、人工点击次数减少、用户满意度、失败原因分布 |
| 数据 | 使用脱敏测试数据,避免在 Demo CDN 中输入敏感信息 |
验收指标示例
| 指标 | 建议目标 |
|---|---|
| 任务完成率 | 选定流程达到 80% 以上,再进入下一轮优化 |
| 操作步骤减少 | 相比人工点击/录入减少 50% 以上 |
| 人工接管率 | 失败或不确定时能清晰提示并交给用户 |
| 风险动作确认 | 删除、提交、审批等动作 100% 需要确认 |
| 日志可追溯 | 能记录任务、动作、结果、失败原因和用户确认 |
11. 风险和注意事项
| 风险 | 说明 | 建议 |
|---|---|---|
| 前端暴露 API Key | 直接在前端配置真实 LLM Key 有泄露风险 | 生产必须走后端代理 |
| 页面 DOM 质量影响效果 | 语义不清、按钮无文本、动态元素不稳定会降低成功率 | 做页面可访问性和语义化治理 |
| 模型输出不稳定 | tool call 格式错误或规划不稳定会导致失败 | 选择强 tool call 模型,设置重试和错误恢复 |
| 敏感数据外发 | 页面内容可能进入 LLM 请求 | 数据脱敏、字段屏蔽、私有模型或私有网关 |
| 越权操作 | Agent 可能尝试用户无意授权的动作 | 权限、白名单、二次确认、审计 |
| 跨页面能力权限更大 | Chrome Extension 权限更广,若被滥用会带来隐私风险 | Token 授权、可信应用列表、最小权限、用户可见确认 |
| Beta 能力成熟度 | MCP Server 标注 Beta | 先用于演示和内部 PoC,生产谨慎评估 |
| 交互边界 | 不支持拖拽、悬停、右键、复杂视觉操作等 | 选流程时避开这些交互或改造页面 |
12. 与相关方案的关系
| 类别 | 代表 | 与 Page Agent 的关系 |
|---|---|---|
| browser-use 类浏览器 Agent | browser-use | Page Agent 借鉴了其 DOM 处理和 prompt 思路,但目标是客户端网页增强 |
| 传统 RPA | UiPath、影刀等 | RPA 更偏跨应用流程自动化;Page Agent 更适合嵌入 Web 产品做用户体验增强 |
| 多模态浏览器 Agent | 视觉截图 + 模型 | 多模态能理解视觉内容,但成本和权限更高;Page Agent 更轻量,但受 DOM 语义限制 |
| SaaS 内置 Copilot | Salesforce Copilot、Microsoft Copilot 类 | Page Agent 可作为自研 SaaS Copilot 的底层 GUI 操作能力 |
| 企业 Agent 平台 | Dify、Coze、LangGraph、MCP 客户端等 | 可通过 MCP/扩展把浏览器 GUI 操作接入现有 Agent 工具链 |
13. 我的售前判断
Page Agent 的价值在于它把“AI 问答”往“AI 可执行操作”推进了一步,尤其适合 B 端 Web 系统。很多企业系统的问题不是没有功能,而是功能太多、路径太深、用户不知道怎么用。Page Agent 的页面内嵌模式非常适合把复杂操作包装成自然语言入口,用较低改造成本验证 AI Copilot 的实际价值。
它最适合的售前切入点不是“全自动替代人工”,而是“辅助用户完成复杂页面操作”。在方案表达上,应强调可控、可审计、可确认、可接管。对客户承诺时也要明确边界:它不擅长视觉识别,不适合大规模服务端爬虫,不适合无防护地执行高风险动作。
建议售前 Demo 选择一个客户熟悉的高频流程,例如“创建客户资料”“提交报销单”“配置产品参数”“搜索订单并生成报告”。演示时先让用户看到自然语言入口,再展示 Agent 如何理解页面、逐步操作、必要时请用户确认。这样比单纯讲技术架构更容易让业务方理解价值。
14. 可复用客户 Q&A
| 客户问题 | 回答建议 |
|---|---|
| 这个是不是 RPA? | “不完全是。它更像嵌入 Web 应用里的 AI 操作员,重点是增强用户体验和操作效率;如果要跨系统、跨浏览器大规模自动化,仍要结合扩展、MCP 或 RPA 能力评估。” |
| 需要改后端吗? | “快速体验不需要;生产落地建议后端提供 LLM 代理、鉴权、审计、脱敏和模型路由。” |
| 能不能私有化? | “项目本身开源 MIT,模型侧支持 OpenAI-compatible 接口和本地运行时路径。但具体私有化效果取决于客户模型的 tool call 能力、上下文长度、延迟和页面复杂度。” |
| 能不能操作任意网站? | “基础 PageAgent.js 需要网站集成后在当前页面运行;通过 Chrome Extension 可以扩展到任意网页和多标签,但权限和安全要求更高。” |
| 它会不会乱点? | “需要用操作白名单、系统指令、风险动作确认、用户接管、审计日志来治理。售前 PoC 不应把它设计成完全无人监督。” |
| 能识别图片或图表吗? | “它主要基于 DOM 文本和结构,不依赖截图和多模态模型。图片、Canvas、WebGL、纯视觉提示不是它的强项。” |
| 哪些页面效果最好? | “语义化 HTML 好、按钮/字段标签清楚、表单结构规范、流程稳定的页面效果最好。” |
15. 后续跟进建议
- 选一个客户真实流程做 1-2 周 PoC,优先表单密集、高频重复、风险可控的页面。
- 梳理页面 DOM 和可访问性质量,补充按钮文本、表单 label、ARIA 属性。
- 确定模型路线:公有云、百炼 Qwen、OpenAI-compatible 网关、本地 Ollama/LM Studio 或客户已有模型平台。
- 设计安全策略:后端代理、数据脱敏、操作白名单、二次确认、审计日志、异常接管。
- 若涉及跨页面或外部 Agent 平台,再评估 Chrome Extension 和 MCP Server。