把 AIOps 操作经验带进浏览器

AIOps缺的不是一个单纯的聊天入口，而是一个运行在浏览器扩展里的智能执行助手：能理解当前页面，能根据自然语言任务操作控制台，能在不确定或高风险时把控制权交还给人，也能把一次成功的操作沉淀成可复放脚本和可追踪记录。

AI控制页面演示: PG恢复

这篇文章介绍 aiops page ext 的设计思路、核心架构和它如何与 AIOps 场景结合。

AIOps 为什么需要浏览器扩展

很多 AIOps 系统已经具备告警聚合、异常检测、根因分析和知识库问答能力。但一旦进入处理阶段，工程师仍然会面对大量浏览器操作：

• 打开告警详情，确认影响范围、服务名、集群、实例和时间窗口。
• 跳到日志平台，用 traceId、requestId、podName 或错误码筛选日志。
• 切到监控大盘，对比 QPS、错误率、延迟、资源水位和依赖状态。
• 查 CMDB 或服务拓扑，确认负责人、上下游依赖和最近变更。
• 进入发布平台，查看发布批次、回滚入口和变更记录。
• 更新工单或故障群，把排查过程和结论同步给团队。

这些动作并不总是复杂，但它们高度依赖页面上下文，而且分散在多个系统中。传统脚本难以覆盖所有页面变化；单纯的聊天机器人又无法直接操作控制台。aiops page ext 的切入点是：让 Agent 直接站在工程师所在的浏览器里，围绕页面完成可解释、可确认、可复放的操作。

核心定位：AIOps 的页面执行层

aiops page ext 可以理解为 AIOps 平台和浏览器控制台之间的“页面执行层”。

上层可以是告警平台、ChatOps、MCP 客户端、故障协同系统或人工输入的自然语言任务；下层是真实浏览器页面。扩展负责把页面状态转成模型能理解的文本结构，再把模型的计划转成点击、输入、滚动、选择、等待、询问用户等可控动作。

典型任务可能是：

帮我排查 prod 集群 checkout-service 过去 30 分钟 5xx 升高的原因，
先看告警详情，再查相关日志和最近变更，不要执行回滚。

在这个任务里，Agent 不只是回答“你应该怎么查”，而是可以逐步打开页面、筛选条件、读取结果、总结发现，并在涉及危险动作时停下来让人确认。

技术路线：用文本化 DOM 理解控制台

aiops page ext 默认不依赖截图识别页面，而是读取浏览器里的 DOM 结构，将当前页面抽取成模型可读的文本化状态。

这个选择对 AIOps 场景很重要：

• 运维控制台通常信息密度高，DOM 中有大量按钮、表格、筛选器和链接。
• 文本化页面状态更容易记录和复盘，便于故障后审计。
• 动作可以绑定到交互元素 index，而不是不稳定的屏幕坐标。
• 不需要把截图作为默认输入，降低权限、成本和敏感信息暴露面。

每次执行动作前，扩展都会重新观察当前页面，得到最新的 URL、标题、滚动位置、页面尺寸和交互元素列表。这样可以避免在动态页面中复用过期元素位置。

flowchart LR
    A["AIOps task"] --> B["Observe current page"]
    B --> C["Text-based DOM state"]
    C --> D["LLM reasoning"]
    D --> E["Tool action"]
    E --> F["Browser operation"]
    F --> B

这条闭环让 aiops page ext 更适合处理真实控制台：页面加载、弹窗、筛选结果刷新、表格分页、跳转新 tab，都可以通过持续 observe 来修正下一步动作。

架构：浏览器执行内核 + AIOps 增强层

aiops page ext 从一开始就按“浏览器执行内核 + AIOps 增强层”的方式设计。浏览器执行内核负责页面观察、动作规划、多标签页调度和 DOM 操作；AIOps 增强层负责知识库、人机确认、操作录制、脚本导出和外部 Agent 接入。这样既能保证页面操作链路稳定，又能把运维场景里的知识、风险和审计能力放到合适的位置。

整体链路可以概括为：

flowchart TD
    U["User / AIOps platform / MCP client"] --> S["Extension side panel or external API"]
    S --> A["Multi-page agent"]
    A --> K["Knowledge context provider"]
    A --> I["WebOps interaction layer"]
    A --> R["Session recorder"]
    A --> C["Remote page controller"]
    C --> P["Target consoles"]
    R --> X["Playwright exporter"]

几个关键模块分别承担不同职责：

模块	职责
Multi-page agent	负责跨标签页任务规划、执行和历史管理
Remote page controller	在目标页面执行 DOM 抽取和点击、输入、滚动等动作
WebOps interaction layer	在页面内展示高亮、确认、交接、输入等人机协作组件
Knowledge context provider	检索项目知识库、运维手册、页面说明和操作规则
Session recorder	记录一次任务中的关键操作、选择器和脱敏数据
Playwright exporter	将成功流程导出为可复放的 Playwright 项目
MCP bridge	允许外部 Agent 客户端触发浏览器任务

这种拆分适合 AIOps：自动化可以往前走，但人、知识库、审计和复放能力都能在明确位置接入。

架构演进

围绕 AIOps 的真实处理链路设计。设计过程可以拆成三个阶段。

第一阶段是浏览器执行内核。目标是让 Agent 能可靠地观察页面、理解任务、生成动作、执行点击输入滚动，并把每一步结果记录下来。这个阶段确定了几个基础能力：文本化 DOM、Observe-Think-Act 循环、工具调用协议、多标签页调度、可停止的任务生命周期和结构化历史。

第二阶段是 AIOps 增强层。仅有页面操作还不够，运维场景需要业务语义和风险控制。因此设计中加入了知识库检索、页面高亮、就地确认、人工交接、敏感信息处理和外部 Agent 入口。这些能力不直接侵入执行内核，而是通过明确接口参与任务执行。

第三阶段是流程资产化。自然语言 Agent 适合处理变化和探索，但高频运维流程需要被固化。Session Recorder 和 Playwright Exporter 的引入，让一次成功的自然语言操作可以转成可复放资产，后续由脚本承担稳定流程，由 Agent 处理变化和例外。

这条演进路径背后的原则是：不把 AIOps 做成只能回答问题的孤立系统，而是把它设计成能进入浏览器现场、协助执行、沉淀流程的工程系统。

flowchart LR
    A["Browser execution kernel"] --> B["Text DOM observe"]
    A --> C["Tool action protocol"]
    A --> D["Multi-tab orchestration"]
    B --> E["AIOps knowledge context"]
    C --> F["Human confirmation layer"]
    D --> G["Session recorder"]
    G --> H["Playwright replay assets"]
    E --> I["aiops page ext"]
    F --> I
    H --> I

模块边界：哪些能力放在哪里

aiops page ext 的模块边界遵循一个简单规则：执行内核只负责“稳定地看页面和操作页面”，AIOps 增强层负责“让操作符合运维语义、风险要求和审计要求”。

边界	负责什么	不负责什么
Agent runtime	任务生命周期、Observe-Think-Act 循环、历史、工具协议、上下文拼装	不直接渲染页面组件，不内置具体运维规则
Page controller	DOM 抽取、元素索引、点击输入滚动等页面动作	不关心 LLM、知识库和多 tab 调度
LLM client	OpenAI-compatible 调用、tool schema、重试和错误类型	不关心页面结构和业务流程
Extension orchestrator	多 tab 调度、远程页面控制、扩展任务生命周期	不直接承载知识库、录制和页面交互组件实现
Interaction layer	页面高亮、确认气泡、交接提示、输入提示	不执行 Agent 规划，不直接改业务页面状态
Knowledge layer	知识库检索、格式化、注入 Agent 上下文	不直接决定页面动作
Recorder	记录动作、目标、知识命中和脱敏信息	不生成脚本模板
Replay exporter	把录制会话导出为 Playwright 项目	不参与在线 Agent 执行
External bridge	把浏览器任务暴露给外部 Agent 或 ChatOps 系统	不理解具体 AIOps 业务规则

这个边界能避免一个常见问题：所有能力都堆进 Agent 主循环。Agent 主循环越复杂，越难测试、越难复用，也越难判断错误来自模型、页面、知识库还是 UI。拆开以后，每个模块都有自己的输入输出，排查问题时可以更快定位。

例如，知识库不可用时，Agent 仍然可以按页面 DOM 执行；录制失败时，不应该影响当前故障排查；页面交互组件渲染失败时，也不应该破坏 RemotePageController 的基础点击和输入能力。AIOps 系统最需要的不是“每次都装作成功”，而是失败边界清楚、风险可见、能继续降级。

工程实践：渐进增强、可测试、可追踪

aiops page ext 的工程实践可以概括为三句话：内核稳定、增强可插拔、证据优先。

内核稳定，指的是把页面观察、动作执行、模型调用和任务历史做成清晰的基础能力。它们承担的是 aiops page ext 的执行可靠性，任何 AIOps 场景增强都不应该破坏这条主链路。

增强可插拔，指的是每个能力都能独立开关和降级。知识库默认可以关闭；页面交互组件只在需要确认、交接或提示时出现；录制和导出依赖会话历史，不阻塞在线任务；外部 bridge 是额外入口，不改变侧边栏的基本使用方式。这样可以先上线低风险能力，再逐步扩大自动化范围。

证据优先，指的是每一步都要留下可追踪信息。Agent history 记录 reflection、action、tool output 和错误；Session Recorder 记录动作目标、选择器快照、知识库命中和脱敏输入；Playwright 导出把成功流程变成可复查资产。对 AIOps 来说，自动化做了什么，比自动化声称自己做了什么更重要。

仓库层面采用 npm workspaces 的 monorepo 组织方式，按执行内核、浏览器扩展、AIOps 增强模块、外部连接模块拆分目录。workspaces 按依赖拓扑排列，避免底层能力反向依赖上层应用。常用质量门禁包括 typecheck、lint、单元测试和面向真实浏览器的验收测试。

这套实践让 aiops page ext 能保持两个方向的弹性：向下保持浏览器执行内核稳定，向上承载越来越具体的 AIOps 业务流程。

知识库增强：让 Agent 知道“这个页面在运维里意味着什么”

仅靠页面 DOM，Agent 可以知道“这里有一个输入框”和“这里有一个按钮”，但不一定知道这些控件在具体业务里的含义。AIOps 场景尤其如此：同一个“重启”“回滚”“确认”“屏蔽”按钮，在不同系统里的风险完全不同。

aiops page ext 通过 Knowledge Context Provider 接入项目知识库。它可以根据当前任务、URL、页面标题和可见内容检索相关材料，例如：

• 服务负责人、业务域、SLO 和依赖关系。
• 告警处理手册、Runbook、升级路径。
• 日志平台字段含义和常用查询模板。
• 发布平台操作规范和回滚条件。
• 特定页面的筛选方式、字段解释和注意事项。

检索结果会被格式化后加入模型上下文，让 Agent 在操作页面前先拿到业务语义。例如，当页面出现“屏蔽告警”按钮时，知识库可以告诉 Agent：这类操作只能在确认误报或维护窗口内执行，并且需要填写原因。

这让 aiops page ext 不只是“会点页面”，而是能把组织内部的运维经验带进页面操作过程。

页面交互组件：自动化必须让人看得懂

AIOps 自动化最怕两件事：一是悄悄做了危险动作，二是失败后没人知道它刚才做了什么。aiops page ext 在目标页面内注入一层轻量交互组件，让用户在关键时刻能看见、确认和接管。

主要组件包括：

• Action Spotlight：高亮 Agent 准备操作的目标元素。
• Anchor Bubble：当页面上存在多个相似目标时，就地询问用户“是不是这个”。
• Handover Banner：遇到登录、MFA、验证码、密码、风控等场景时暂停，并提示用户手动完成。
• Input Prompt：需要用户补充信息时，在当前页面收集输入。
• Progress Toast：用轻量提示说明 Agent 当前动作和结果。

这些组件不是为了“炫 UI”，而是为了让运维自动化具备可观察性和可控性。尤其在生产控制台里，用户需要知道 Agent 正在看哪里、准备做什么、为什么停下来。

操作录制与复放：从一次排查沉淀成可重复流程

AIOps 里的很多流程具有重复性：每天巡检、故障初筛、容量检查、发布前检查、告警处理、工单更新。自然语言 Agent 可以帮助探索第一次流程，但稳定流程不应该永远依赖 LLM。

aiops page ext 的 Session Recorder 会记录任务中的关键步骤，包括动作类型、目标元素、页面信息、选择器快照和必要的脱敏输入。成功执行后，Playwright Exporter 可以把这些步骤生成一个可复放项目。

这带来两个价值：

第一，探索阶段用 Agent 提升效率；沉淀阶段用脚本提升稳定性。

第二，故障处理过程可以被审计和复盘。团队可以看到 Agent 做过哪些页面操作、在哪一步遇到人工确认、哪些信息被用于判断。

一个可复放流程可以变成：

• 每天自动打开核心服务大盘并检查关键指标。
• 告警触发后自动收集日志、链路、变更记录。
• 发布前自动检查灰度状态和错误率。
• 工单关闭前自动补充排查证据和处理结论。

这正是 AIOps 从“智能问答”走向“智能执行”的关键一步。

风险控制：高权限场景必须可确认、可停止、可追踪

浏览器扩展天然拥有较强页面访问能力，AIOps 又经常连接生产系统，所以风险控制是基础能力，而不是附加项。

aiops page ext 在设计上遵循几个原则：

• 当前页面状态是事实来源，历史摘要不能直接作为可执行元素索引。
• 遇到登录、验证码、密码和敏感凭证时交给用户处理。
• 涉及回滚、删除、重启、屏蔽、扩缩容等高风险动作时应触发确认。
• 每一步动作要记录输入、输出、耗时和错误信息。
• 用户可以随时停止当前任务。
• 敏感字段进入录制和导出前需要脱敏。

这套机制不会让自动化变慢很多，却能避免 AIOps 系统从“帮忙处理问题”变成“制造新问题”。

与 MCP 和外部 Agent 的连接

aiops page ext 不只能从扩展侧边栏启动，也可以通过 MCP bridge 接入外部 Agent 客户端。这样，故障协同系统或桌面 AI 助手可以把浏览器任务交给扩展执行。

flowchart LR
    A["ChatOps / MCP client"] --> B["Local MCP bridge"]
    B --> C["Extension hub"]
    C --> D["aiops page ext"]
    D --> E["Monitoring / logs / CMDB / ticket consoles"]

例如，ChatOps 中收到告警后，可以让外部 Agent 调用浏览器扩展：

打开告警详情，收集 checkout-service 最近 30 分钟的日志错误样例、
相关 trace 和最近发布记录，生成初步排查摘要。

扩展执行完成后，结果可以回到对话上下文，也可以落到工单或故障记录里。这样，AIOps 的“分析”和“执行”不再割裂。

适合的 AIOps 场景

aiops page ext 特别适合这些场景：

• 告警初筛：打开告警详情，收集影响面、指标趋势和异常样例。
• 日志排查：根据服务名、traceId、错误码、时间窗口生成查询并阅读结果。
• 巡检：按固定清单检查大盘、资源水位、发布状态和错误率。
• 变更核查：查询最近发布、配置变更、扩缩容记录和关联工单。
• 工单辅助：补充排查证据、处理过程和结论摘要。
• 跨系统操作：在监控、日志、链路、CMDB、发布平台之间串联上下文。
• 流程沉淀：把高频排查路径导出为 Playwright 脚本。

它不适合无边界地替代人做生产决策。更合理的定位是：让 Agent 完成信息收集、页面跳转、重复操作和初步总结，让人负责风险判断、授权和最终动作。

工程落点：为什么它能在现有系统里落地

aiops page ext 的工程优势在于低侵入。

它不要求各个运维系统立即改造后端 API，也不要求把所有控制台统一重建。只要工程师能在浏览器里访问这些系统，扩展就有机会读取页面结构、理解任务并执行操作。

同时，它又不是一次性脚本：

• 通过文本化 DOM 保持可解释。
• 通过知识库增强补充业务语义。
• 通过页面交互组件保持人机协作。
• 通过录制和导出沉淀稳定流程。
• 通过 MCP bridge 接入更大的 Agent 生态。

这使它适合作为 AIOps 平台的一层渐进式增强：先帮助工程师减少重复操作，再沉淀高频流程，最后把成熟流程接入自动化和故障协同。

小结

aiops page ext 的价值可以用一句话概括：把 AIOps 从“会分析”推进到“能在浏览器控制台里协助执行”。

它用文本化 DOM 理解页面，用扩展能力连接多个运维系统，用知识库补足业务语义，用交互组件保留人工控制，用录制和 Playwright 导出沉淀可复放流程。对于已经有监控、日志、告警和工单体系，但仍然被大量浏览器操作拖慢的团队来说，这是一条务实的 AIOps 落地路径。

真正有用的 AIOps 不应该停在答案里。它应该能进入工程师每天工作的页面，帮忙收集证据、减少重复动作、留下过程记录，并在关键节点把决定权交还给人。aiops page ext 要做的，就是这一层连接。