想让 Agent 在一个 ERP 里完成“筛出逾期订单，把华东区负责人改成李明”，常见方案是从页面外部控制浏览器：截图、识别界面、规划点击，再把动作回放到坐标或 DOM。
Alibaba Page Agent 换了站位。它把 Agent 运行时直接放进网页，让页面通过 JavaScript 暴露自己的结构与动作。用户表达目标，Agent 在同一个前端环境里读取 DOM、定位元素并执行交互。
这条路线不是更轻量的浏览器自动化而已。它改变了能力归属：Agent 从外挂工具变成产品内部的一层交互接口。
In-page 到底省掉了什么
Page Agent 的公开定位很明确：
- 页面内 JavaScript 集成；
- 以文本化 DOM 为主要输入，不依赖截图和多模态模型；
- 支持接入自有模型；
- 可选 Chrome 扩展处理多页面任务；
- 也提供从外部控制的 MCP Server。
对于自己拥有的 Web 应用，这能省掉外部浏览器运行器、截图传输和像素定位链路。Agent 与页面共享当前状态，不需要从一张图片猜测某个按钮背后的属性。
最小调用也保持前端库的形态：
tsconst agent = new PageAgent({ model: "your-model", baseURL: "your-endpoint", apiKey: "your-key" }) await agent.execute("Open the latest unpaid invoice")
这段代码展示的是接入方式，不是生产安全模板。真实产品不应把长期有效的敏感密钥直接暴露在浏览器端。
它最适合复杂但可控的产品
企业后台经常有大量低频流程。每一项都做成快捷按钮，界面会继续膨胀；每一条都写死自动化规则，维护成本又会快速上升。
页面内 Agent 提供了第三种接口：保留现有 GUI，同时允许用户用目标语言触发一段操作。它尤其适合：
- 操作对象和状态都在当前产品内；
- DOM 语义相对稳定；
- 用户需要完成筛选、录入、跳转等多步任务；
- 产品方能控制权限、审计与确认流程。
这里真正的产品价值不是“少点几次鼠标”，而是把低频复杂路径从记忆负担变成意图表达。
DOM-first 也有看不见的地方
不用截图是优势，也定义了盲区。若界面的关键信息主要存在于 canvas、图像、复杂可视化或缺少语义的自定义控件中，文本化 DOM 未必能完整表达用户看见的状态。
页面结构也不等于业务含义。一个按钮叫“提交”，Agent 仍需要知道它会触发什么副作用、是否可撤销、当前用户有没有权限。仅靠元素文本，无法替代产品领域规则。
因此，in-page Agent 更依赖前端质量：
- 可交互元素要有稳定语义和可访问名称；
- 状态变化要能被读取，而不是只靠颜色表达；
- 关键动作要有明确的确认与结果反馈；
- 组件重构后要有 Agent 任务回归测试。
Agent 不会自动修复混乱的 DOM。它往往会放大页面原有的语义质量。
权限近了，风险也近了
运行在页面里意味着 Agent 更容易读取当前状态和调用现有交互，也意味着它离用户数据和业务动作更近。
产品至少需要区分三类动作：
- 只读：查询、定位、解释；
- 可撤销写入：填写草稿、调整筛选；
- 高风险提交：付款、删除、审批、发送。
高风险动作不应该只靠模型“判断用户大概想做”。应在执行层使用确定性的权限检查、参数预览、二次确认和审计日志。模型负责把自然语言转成候选计划，产品负责决定哪些步骤可以真正落地。
这也是页面内路线与外部自动化共同的底线：Agent 的便利不能绕过原有授权模型。
它不是无障碍能力的替代品
项目把 Accessibility 列为使用场景，这个方向确实有价值。自然语言入口可以减少复杂鼠标路径，也可能与语音交互结合。
但它不能替代语义 HTML、键盘可用性、焦点管理和屏幕阅读器支持。Agent 服务不可用时，产品仍必须可访问；用户也需要知道系统将执行什么，而不是把所有控制权交给不透明的自动化。
更合理的定位是增强层，而不是为不合格界面提供补丁。
与页面外 Agent 不是替代关系
Page Agent 官方明确把自己定位为 client-side web enhancement，而不是 server-side automation。若任务要跨陌生网站、长时间无人值守运行，或操作浏览器外部文件和系统，外部自动化仍然更合适。
两条路线解决不同问题：
| 路线 | 更适合 |
|---|---|
| 页面内 Agent | 自有产品、当前会话、深度集成、低延迟交互 |
| 页面外 Agent | 跨站任务、测试与采集、无人值守编排、通用浏览器控制 |
Page Agent 的扩展与 MCP 能力让边界可以延伸，但核心优势仍来自“产品方控制页面”这一前提。
我的判断
Page Agent 最值得关注的不是它能点击按钮，而是它把 Agent 设计问题交还给了产品团队：页面应该暴露什么语义，哪些动作需要确认，失败后如何恢复，用户怎样保持控制。
把 Agent 放进页面，会减少截图和外部控制的距离；它不会减少业务规则、安全与可用性的工作。相反，这些责任会更直接地落在页面内部。
对于复杂 SaaS，这是一条可信的产品化路线。前提是把它当作新的交互层来设计，而不是在现有页面上贴一个“AI 自动操作”按钮。