AIOps 能帮我们快速识别告警原因，但真正让问题得到解决。却往往落在了“人”与“工具”的接口处——那一连串繁琐且易失误的浏览器操作上。工程师每天得从监控界面跳到日志网站。再切到 CMDB 或发布网站，每一次点击都要确认是否正确；若没做好，就可能触发回滚或重启导致服务不可用。缺少统一可追踪的执行记录，让事故后审计变得困难重重。这些痛点正是推动 aiops page ext 出现的根本原因：让智能助手直接驻留在浏览器内，实现可解释、安全、高效地自动化执行。

AIOps 为什么需要浏览器

• 频繁手动切换界面： 从告警详情→日志查询→监控大盘→CMDB→发布网站，每一步都需手动打开新标签页并定位信息；耗时且容易漏检，
• 高风险命令缺少审核机制： 如回滚部署或资源缩容，一旦被误触会造成严重影响；传统脚本难以嵌入人工确认流程。
• 缺乏统一审计轨迹： 故障排查过程中所有点击和输入没有被程序级别记录，事故后难以追溯具体步骤与责任人。

AI 控制页面演示：PG 恢复案例简述

AioPs Page Ext 能够把自然语言任务转化为一系列可靠点击/输入/滚动等动作。并它会先打开告警详情，接下来根据业务语义自动过滤错误日志，并最终展示一个安全回滚建议，而不会盲目触发生产环境中的重启命令。

aops page ext 就是“AIOps 网站 ↔ 浏览器控制台”之间的一层桥梁，把复杂的人机交互拆解为可由模型理解并转译为 DOM 操作的步骤。在这个层面上，上层可以是 ChatOps 指令或自然语言任务，下层是真实网页内容，通过观察->思考->行动循环完成任务。 从而消除传统脚本对 UI 定位的不稳定性，并将每一步结果实时反馈给使用者或外部程序，以便即时审核和回溯。

从技术方向来看。用文本化 DOM 理解控制台界面

• DOM 中包含丰富按钮、表格及筛选项，可通过文本抽象成结构化状态，而不是图片截图；这样既能保持低权限成本，又避免敏感信息泄露;
• 每次动作前重新观察当前页面可以捕捉弹窗、新标签页还有分页变化，从而保证接下来指令针对最新元素;
• 把元素索引作为动作依据。而非固定坐标，明显提高对动态 UI 的适配能力;
• 整个闭环实现方式如下图所示：

说到架构概览，执行内核 + AIOps 提高层两段式设计

主要模块职责划分:

架构演进路线图:

• Pioneer Stage – Execution Kernel : 确保 Agent 能稳定观察+理解+行动+记录。
• Evolve Stage – AIOps Enhancement Layer : 引入知识库检索、人机确认及敏感信息脱敏，让自动化符合业务语义。
• Mature Stage – Process Assetization : Session Recorder 与 Playwright Exporter 将一次成功排查转成可复放脚本，为日常巡检提供稳定基石。\end{list}

  说到演进原则，