引言
AI Agent 在网页上完成任务，需要先读懂页面，再操作控件，并根据结果决定下一步。它需要知道哪些内容已经显示、哪些控件可以操作，以及一次点击后发生了什么。浏览器在渲染页面和处理交互时，已经掌握了不少这样的信息。
ACE Protocol 的出发点，就是让 Agent 更直接地使用这些信息。它是一套实现在 Chromium 内部的浏览器原生协议，利用浏览器计算好的布局、绘制和控件状态，向 Agent 提供紧凑的页面语义，并把动作执行与结果观察关联起来。
为什么浏览器 Agent 还在“猜”
比如，找到一位联系人的资料，将职位改为高级软件工程师、所在地改为纽约，再确认修改已保存。
完成这项任务，Agent 至少需要知道四件事：
- 页面上现在有什么？
- 页面是否已经稳定，可以开始操作？
- 该操作哪个控件，怎样点击或输入？
- 操作之后发生了什么？
截图保留了页面外观，Agent 需要从中识别文字、位置和控件关系，再决定怎样操作。读取页面结构可以直接拿到文本和节点身份，但仍有缺口：DOM 中的节点可能尚未显示，页面文字没变时，浏览器也可能已经开始下载。
现有自动化框架已经有定位器、动作检查和自动等待等能力。ACE Protocol 关注的是如何将浏览器掌握的状态整理成模型能直接使用的信息，并把一次观察、就绪判断、动作执行和结果关联起来。
协议约定了四类信息：
- Observation（观察）：当前渲染状态下，页面有哪些有用的内容和可执行的动作。
- Readiness（就绪）：当前文档是否曾达到协议定义的稳定条件。
- Action（动作）：如何通过浏览器原生的交互和编辑机制执行动作。
- Effect（结果变化）：动作带来了导航、页面变化、焦点变化或下载，还是没有观察到可见结果。
Agent 仍然决定要找什么、点什么，以及结果是否满足任务要求。浏览器负责提供它能观察到的事实。
协议如何组织一次交互
一次交互通常按这个顺序进行：
读取页面 → 选择动作节点 → 执行动作 → 获取变化 → 按需重新观察这里用到三个接口：Page.getAIPageContent 读取页面，Page.performDOMAction 执行动作，Page.getAIPageActionChanges 获取动作后的变化。客户端通过 Chromium 的调试协议 CDP 调用它们。
这些信息来自两个地方。渲染进程负责页面内容、控件状态和交互，浏览器进程负责导航、新标签页和下载。协议将两侧的观察关联起来，让 Agent 能查到一次动作在页面内外产生的结果。
Observation：从渲染结果中提取可行动语义
先理解 DOM、Layout 和 Paint 的区别
DOM 描述文档结构，例如一个标题、一段文字和一个按钮属于同一个容器。它记录内容与节点的关系，但仅凭这些结构，还不知道文字会在哪里换行、元素占多大面积，以及哪些内容会被挡住。
Layout（布局）结合样式，计算内容的大小、位置和换行。DOM 节点与最终布局并非一一对应：隐藏元素可能不参与布局，一段文字也可能排成多行。
图 1：同一份文档结构会随样式和容器宽度形成不同布局，同色对象表示相同的内容来源。
Paint（绘制）确定背景、文字和前景内容的绘制顺序，判断遮挡时就会用到这些信息。到了这一步，内容之间的结构关系仍然保留着，还没有变成截图中的像素。
ACE Protocol 会用到这三层信息：从 DOM 获取内容与身份，从 Layout 获取位置与排版，再借助 Paint 判断遮挡。读取前，协议会更新布局和绘制状态，尽量避免把新内容与旧位置混在一起。
过滤确定不可见的内容，保留不确定的信息
提取文本、控件和动作信息时，ACE Protocol 会先过滤没有有效显示区域、样式不可见或完全透明的内容，再结合绘制顺序判断遮挡。
遮挡判断比较保守。只有能确定内容被后绘制的不透明区域完整覆盖，协议才会剔除它。遇到半透明、部分覆盖或复杂视觉效果，无法确定是否被完全遮挡时，就保留相关内容。
图 2：在覆盖物静止、没有动画等不确定因素时，完整不透明覆盖会使目标被剔除；半透明或部分覆盖则保留目标。
这份输出保留了无法确定是否被遮挡的内容，因此可能与肉眼看到的页面有所不同。这样可以减少误删有用信息的情况。
滚动可达性：观察不必改变滚动位置
当前屏幕通常只显示文档的一部分。如果每次读取屏幕外的内容都要先滚动页面，就可能触发滚动事件、懒加载或虚拟列表更新。只是想看看页面，却改变了页面状态。
ACE Protocol 会判断已经渲染的内容能否通过正常滚动到达，并在读取时保留这些信息，无需改变滚动位置。判断仍受页面自身的裁剪规则限制。
这个范围只包括已渲染的内容。尚未生成的虚拟列表项、未加载的数据都不在其中。返回的节点可能分布在不同滚动位置，无法同时出现在一张截图里。
压缩结构，保留内容与动作的关系
网页为了布局和样式，常常嵌套多层容器。ACE Protocol 会折叠没有独立含义的包裹层，合并属于同一内容的文字片段，并将按钮名称直接放在按钮节点上。这能减少 Agent 需要读取的上下文。
图 3：合并文字片段、折叠冗余容器后，语义树仍保留必要的内容层级与动作。
压缩时，协议会保留表格层次、业务分组，以及内容与操作按钮之间的关系。例如，同一张卡片里的文字和“编辑”按钮必须保持关联，否则 Agent 就可能改错对象。
输入框、文本域和下拉框采用统一的表示方式，返回名称、实时值、选项和可用动作，省去浏览器内部的控件结构。部分未显示的输入控件也可能返回表单信息，所以读到一个字段后，还要确认它当前能否操作。
默认输出省略坐标、调试信息和空字段；需要链接地址等信息时，可以按需请求。
简化后的返回结果如下：
{
"url": "https://example.test/reports",
"ready": true,
"content": {
"role": "main",
"children": [
{"role": "heading", "text": "资料中心"},
{"text": "页面内容会随着容器\n宽度自动换行"},
{"id": 42, "role": "button", "text": "查看报告", "action": ["click"]}
]
}
}这里的 42 是临时节点 ID，供本次观察后的动作使用。页面导航、显著重建或节点失效后，需要重新读取页面。这个 ID 不能用作长期有效的业务标识。
Readiness：判断文档是否曾达到稳定条件
页面加载完成后，异步组件可能还没准备好，后台请求也可能一直持续。固定等待几秒很难兼顾不同页面：快页面白等，慢页面又可能等得不够。
ACE Protocol 会结合网络活动、页面结构变化和待执行脚本等信号，判断文档是否在一段时间内达到稳定条件。慢资源也有等待上限，避免就绪判断一直卡在单个资源上。
ready=true 表示当前文档曾经达到过协议定义的稳定条件。这个值在同一文档内会保持为真，后续局部更新不会让它自动变回 false；文档被替换或重新打开后才重新判断。
Readiness 可以帮助选择观察时机，但不能保证业务数据已经出现，也不能说明页面此刻完全静止。Agent 还要检查任务所需的内容，例如联系人表单是否已经加载。
Action：在浏览器内部执行并重新验证目标
Agent 将观察中的节点 ID 和动作类型交给 Page.performDOMAction，例如 {"id":42,"action":"click"}。执行时，浏览器会重新解析并验证节点，检查之前读到的目标是否仍然可用。
ACE Protocol 当前支持六类动作：
| 动作 | 主要用途 |
|---|---|
click | 点击按钮、链接和控件 |
input | 在输入框、文本域或受支持的可编辑区域填写文本 |
input_submit | 输入文本并提交表单 |
hover | 触发悬停菜单、提示等状态 |
press_key | 发送 Enter、方向键或快捷键 |
select | 选择原生下拉框中的单个或多个选项 |
动作会复用浏览器原生的交互和编辑机制。以输入为例，除了修改字段值，还要触发相应的编辑事件，页面才有机会进行校验或更新状态。
从观察到执行，页面可能已经发生变化。浏览器会在执行时检查目标是否还存在、是否禁用或只读，以及是否满足对应动作的条件。如果页面取消了编辑，协议也会遵循这一结果。
这些动作使用原生交互机制，但与真实硬件输入仍有区别，也不能保证支持所有自定义控件。某些点击路径允许向初始被遮挡的目标分发事件，所以协议报告点击成功时，真人鼠标未必能点到它。
Effect：把页面内外的变化归入同一次动作
performDOMAction 返回 ok=true，只说明动作分发过程成功运行了。Agent 还需要知道这次操作带来了什么变化。
ACE Protocol 会比较动作前后的页面状态，结合浏览器侧的观察，返回导航、新标签页、页面内容、字段值、焦点或下载等变化。如果未发现变化或动作失败，也会在结果中报告。
例如，点击“下载报告”后，页面文字可能完全没变，但浏览器已经检测到下载。协议可以将下载归入本次动作，Agent 就有了页面文字之外的判断依据。
Effect 返回变化类型与相关状态，不一定包含完整的内容差异。要知道页面具体改了什么，还得重新读取页面。客户端需要先为预期变化留出等待时间，再获取本次动作的结果。每次动作的结果只消费一次，不能反复读取来持续轮询。
业务结果需要单独确认：download 不证明文件已经下载完成，no_op 也不证明服务器没有处理请求。回到修改联系人的例子，Agent 最后还要确认职位和所在地已经保存。
把协议接进 Agent 工作流
只要客户端能够发送自定义 CDP 命令，就可以连接 ACE Protocol 浏览器，直接调用这些接口。配套的参考客户端负责管理连接和动作顺序，也提供了减少模型与浏览器往返的能力。
先明确操作的页面，再按顺序观察和执行。 参考客户端用 Target ID 标识目标，避免把不同页面的观察和动作混在一起。一次内容读取不会自动汇总所有 iframe 子页面；如果要操作可独立连接的子页面，需要切换到对应目标，再重新观察。
将已经确定的连续动作一起提交。 例如，联系人表单中的职位、所在地和保存按钮都已明确，就可以依次填写两个字段，再点击保存，省去逐步调用的开销。会导航或重建页面的动作应放在最后。如果后续操作依赖新状态，就要先重新观察。
批量动作按顺序执行，遇到失败就停止，已经完成的操作不会回滚。因此，失败后不能直接整批重试。返回的 Effect 对应最后执行的动作，各步的执行结果会另行保留；整个任务是否完成，要看最终页面状态。
只把任务需要的信息交给模型。 参考客户端还可以把语义树转成大纲，或只保留任务相关的节点与字段。修改联系人时，交给模型的内容就可以集中在资料表单上，减少无关导航占用的上下文。
性能数据：更少的推理轮数与 Token 成本
评测设置
本轮评测比较 ACE Protocol、Browser Use 和 agent-browser 三种完整的 Agent 工作流，覆盖消息发送、表单更新、内容编辑和跨页面状态操作等 10 项结构化 Web 任务。每项任务、每种方案选取一份运行记录，共 30 条轨迹。三组使用相同的任务定义、gpt-5.6-sol 模型和 medium 推理档位，推理轮数按模型响应次数统计。
总体结果
本轮三组结果中，ACE Protocol 的推理轮数、总 Token 用量和估算成本都最低。ACE Protocol、Browser Use 和 agent-browser 的推理轮数分别为 158、200 和 188 轮。与 Browser Use 和 agent-browser 相比，ACE Protocol 的推理轮数分别减少 21.0% 和 16.0%，估算成本分别减少 19.8% 和 29.2%。图中数值经过四舍五入，降幅按原始精确值计算。
结果分析与边界
语义观察将控件状态、可用动作和页面就绪信息放在一起，供 Agent 直接读取。已确定的动作可以批量提交，动作后的观察也可以限定范围，这些机制都有助于减少模型往返。本轮的推理轮数和输入 Token 确实更少，但评测比较的是完整工作流，无法单独判断每项能力贡献了多少。
找到按钮后，还要确认它对应的是哪个业务对象。保留正文、层级和操作按钮之间的关系，有助于做这个判断。如果页面语义里缺少对象身份，使用 ACE Protocol 的 Agent 也可能需要多次观察和导航才能找到目标。这部分往返仍有优化空间。
这组数据来自模拟应用，每项任务、每种方案只选取一个样本，尚未固定模型快照，也没有进行随机交错的重复实验。初始化偏差和应用状态都会影响方案之间的比较。目前的结果只能说明这些完整工作流在本轮环境中的表现，收益能否稳定复现，还需要在统一条件下重复评测。
什么时候仍然需要视觉
ACE Protocol 适合结构、状态和操作语义比较明确的页面。表单密集的企业应用、多步骤内容管理、运营后台、项目看板和支付流程，都需要反复读取控件状态、填写字段、执行动作并检查结果。由浏览器直接提供这些信息，可以省去一部分从像素或站点脚本中还原状态的工作。
跨多个页面和窗口的任务也可以用到这些能力。需要确认导航、下载、新窗口或页面内变化时，Agent 可以通过 Observation、Action 和 Effect 获取相关信息，减少从截图、DOM 探针、等待逻辑和后续验证中单独拼接信息的工作。
Canvas 绘图、地图、游戏、远程桌面和图片编辑器则经常需要判断像素内容。颜色、造型、相对位置或整体构图无法仅靠语义树表达时，仍要使用截图和视觉模型。语义树可以补充部分结构信息，但无法替代这些视觉判断。
实际接入时，可以先用 ACE Protocol 读取结构化状态、执行动作，遇到语义树无法表达的内容，再补充截图和视觉判断。这样仍能处理依赖视觉的界面，也能减少普通表单和按钮操作中的图像理解开销。
结语
浏览器 Agent 过去常常站在页面之外工作：先猜页面现在是什么状态，再猜哪个元素能够操作，最后还要猜一次动作究竟带来了什么。截图和 DOM 脚本都能完成任务，但它们把大量本应由浏览器回答的问题留给了模型。
ACE Protocol 做的是另一种选择：从已经完成布局和绘制的页面中提取可行动语义，用明确的稳定条件为观察时机提供依据，让动作进入浏览器原生交互管线，再以 Effect 返回浏览器真正观察到的结果。Agent 仍然负责理解目标和做出业务决策，浏览器则负责把事实说清楚。
我们希望浏览器能把已经掌握的页面状态直接交给 Agent：哪些内容可用，动作能否执行，执行后观察到了哪些变化。ACE Protocol 围绕这些问题组织接口，任务目标和业务结果仍由 Agent 判断。
真正的目标，不是让 AI Agent 更像人一样辛苦地操作浏览器，而是让浏览器成为 AI 可以直接理解、执行和验证的环境。