为什么需要能力层

Agent 能看见一个按钮，不等于知道这个按钮对应什么业务操作，也不等于有权按下它。真实系统里的失败往往不是“模型不会点”，而是页面没有用机器能够理解的方式，说明自己允许做什么、作用于哪条记录，以及执行后发生了什么。

能力层解决的就是这段缺失的信息。

一次真实业务操作

假设订单后台有三个区域：左侧筛选、中间订单表格、右侧编辑弹窗。用户对 Agent 说：

把 SO-1002 的配送备注改成「周五前送达」，然后保存。

对人来说，这件事很清楚：找到 SO-1002，打开编辑，填写备注，保存，再确认列表里的订单已经更新。

对 Agent 来说，页面首先只是一组 DOM 节点。它能看到 button、input、div，却无法仅凭这些节点确定：

• 哪一行才是 SO-1002，行号变化后目标会不会跟着变；
• 哪个输入框是配送备注，哪个是内部说明；
• 保存按钮是否会提交订单，还是只关闭弹窗；
• 当前用户能否修改这张订单，是否需要审批；
• 保存失败是因为校验、权限、网络，还是业务状态已经变化；
• 返回“成功”以后，订单究竟有没有改变。

如果 Agent 根据截图和 DOM 猜测，它是在推断人的意图；如果直接调用内部接口，它可能绕过页面已经实施的校验和审批；如果每个应用都写一套私有脚本，集成又会退回到一次性工程。

DOM 描述界面，不描述业务能力

下面是一个常见按钮：

<button class="btn btn-danger">删除</button>

这段 HTML 没有说明它删除哪条记录、是否可撤销、是否需要二次确认、当前用户是否有权限，也没有说明执行后应该观察什么。人类依靠业务训练、界面布局和上下文补足这些信息；Agent 没有同样稳定的先验。

因此，问题不是“怎样让 Agent 更会点按钮”，而是：

页面怎样明确告诉 Agent：这里有哪些业务操作，当前允许它在什么条件下执行，以及结果如何验证？

这就是能力层要回答的问题。

能力层包含什么

能力层既不是一份后端 API 文档，也不是一个聊天窗口。它至少包含四类信息。

声明

页面在业务代码旁声明可执行的动作：动作的名称和含义、输入、目标记录、风险等级、是否需要确认。声明属于应用，不属于模型提示词。模型可以读取它，不能凭空创造它。

上下文

Agent 需要知道当前页面的事实：所在路由、可见区域、记录窗口、选中项、可用动作、不可用原因，以及哪些字段只能以掩码或引用形式出现。上下文应当是有界的业务视图，而不是整棵 DOM 或整个前端 store。

控制

“页面声明了这个动作”和“这次允许执行”是两件事。控制还涉及用户身份、Agent 身份、应用与租户、会话范围、用户同意、人工审批、金额或频率限制。页面不能代替业务后端作最终授权。

结果

执行结束后，Agent 需要知道动作是否被接受、作用于哪条记录、页面观察到了哪些变化、失败发生在哪一步。没有可核对的结果，“已完成”只是一句自然语言。

它和其他接入方式是什么关系

直接调用后端

后端接口适合服务与服务之间的稳定集成，但它不是页面能力的完整表达。Agent 需要理解内部 API，而且很容易绕过页面层面的校验、审批和业务约束。后端仍然应当是最终授权与执行者；能力层负责把页面愿意开放的动作准确交给它。

浏览器自动化与视觉识别

CDP、Playwright 和视觉 Agent 解决的是“怎样操作一个像素界面”，适合无法接入的第三方站点。在自有应用里，它们仍有定位不稳定、结果难以解释的问题。能力层不排斥自动化，只是为可控页面提供更准确的路径。

页面内的私有助手

只给页面接一个聊天窗口，背后调用私有接口，可以很快交付。但能力仍被锁在一个客户端里。若同一组动作还要开放给用户自己的 Agent 或第三方客户端，就需要把能力从客户端实现中分离出来。

接入之后发生了什么变化

角色	只有 DOM 或私有接口	有明确的能力层
前端开发者	每个 Agent 接入都重新解释页面	在业务代码旁声明一次，多个客户端复用
应用团队	难以说明 Agent 被允许做什么	有明确能力范围、风险等级和失败边界
Agent	从 DOM、截图和文案推断	读取业务声明并提交参数
用户	只看到最终回复	能看到目标、确认、结果和失败原因
安全与审计	只能检查接口日志	能核对会话、动作、记录和审批关系

一次执行的闭环

业务页面
  │ 声明动作、记录、区域和只读状态
  ▼
能力层
  │ 生成有界的 Agent 上下文
  ▼
模型或 Agent runtime
  │ 选择动作、提交参数
  ▼
页面执行器
  │ 可用性、确认、校验、业务处理
  ▼
结果与可观察变化

关键点不是 Agent 直接操作 DOM，而是它操作页面明确声明的业务能力。DOM 仍然存在，只是不再是 Agent 推断业务含义的主要依据。

能力层不保证什么

• 不会自动让应用变安全。后端授权、租户隔离、密钥管理和数据库规则仍然必须存在。
• 不会阻止拥有浏览器级权限的 Agent 绕过契约。它改善的是经过声明的路径。
• 不会替应用制定风险政策。哪些动作需要确认、审批或双人复核，仍由业务决定。
• 不会消除模型错误。它让错误更容易被限制、观察和纠正。

什么时候值得采用

以下情况通常适合引入能力层：

• 页面操作有明确业务含义，而且会修改真实状态；
• 同一套操作需要被页面助手、外部 Agent 或多个客户端复用；
• 团队需要说明某次操作是谁发起、作用于哪条记录、是否经过确认；
• 现有 DOM 自动化太脆弱，而后端直连又会绕过业务界面。

如果只是一次性演示、目标页面不可控，或者操作没有稳定业务语义，浏览器自动化或人工流程可能更合适。

常见误解

“能力层就是另一套后端 API。” 不是。它描述用户通过界面可以完成的业务动作；后端 API 是实现之一。

“声明了动作，就一定可以执行。” 不是。还要检查当前可用性、会话范围、用户确认和后端授权。

“能力层会取代 Playwright。” 不会。没有接入条件的页面仍可能需要浏览器自动化。

“只要有确认弹窗就安全。” 不够。确认只表达用户当下的意愿，不能替代业务后端对权限和高风险操作的校验。

继续阅读

Pling 是什么，不是什么会进一步拆开 SDK、页面运行时、Agent、Surface 和协议规范，说明它们各自负责什么。