数据库生产故障排查最难沉淀的能力，是资深 DBA 的判断顺序。
同样面对一个 timeout，经验丰富的工程师会先定位问题可能出现在哪一段链路：查询、导入、RPC、Compaction，还是下游对象存储。
当 FE 内存持续上涨时，他们会检查 Query Planning、元数据操作、MV Refresh、GC 等可能原因，再根据证据逐步收窄范围。
这类判断决定了排障效率，也影响团队处理复杂生产问题的稳定性。
大多数通用 AI 工具缺少集群的实时拓扑、监控指标和日志上下文。它们可以提供通用建议，却难以基于现场证据持续推进排查。
镜舟在 Manager 中构建了 DevOps Agent，它将 DBA 的排障过程沉淀为一套可执行、可验证、可审查的工程能力：感知现场 → 建立假设 → 获取证据 → 交叉验证 → 收窄范围 → 安全执行。
先来看一次真实排障。
一、从真实的 FE 异常排查开始
用户输入："FE 状态异常了，帮我排查一下。"DevOps Agent 随即开始工作。
阶段一：感知拓扑，加载排障路径
Agent 先读取集群拓扑，获取 FE 节点列表、角色信息、存活状态和基础指标。
它发现：
-
FE-01（Leader）：在线
-
FE-02（Follower）：离线
-
FE-03（Follower）：在线
Agent 确认故障集中在单个 FE 节点后，自动加载 node Skill，随后检查 FE Crash、JVM 内存和 GC 异常等方向。
阶段二：并行采集基础证据
Agent 同时执行多项只读诊断操作：第一组，查询最近一小时的 FE 核心指标：
-
查询
SHOW FRONTENDS，确认 FE-02 的离线时间和最后心跳； -
拉取 FE-02 最近 30 分钟的 JVM Heap 使用曲线；
-
读取最新 GC 日志，检查 Full GC 的频率和停顿时间；
-
检查 FE 进程、节点内存和 OOM Killer 记录。
阶段三：交叉验证，收窄排查重点
结果显示：
-
FE-02 的进程已退出；
-
/var/log/messages中没有 OOM Killer 记录； -
节点剩余内存超过 60%；
-
进程退出前约两分钟，GC 日志连续记录了多次 Full GC，单次停顿超过 15 秒。
这些证据显示，Linux OOM 并非主要排查方向。
Agent 将排查重点收窄至 JVM 内存持续增长和 Full GC 回收失效，并继续检查最后存活期间的运行状态：
-
SHOW PROC '/current_queries'未发现异常大查询； -
物化视图任务中存在多个高频刷新任务；
-
高峰刷新时间与内存上涨时间窗口高度重合。
Agent 给出当前结论：
FE-02 的异常可能与高频 MV 刷新任务引发的元数据操作内存积累有关。建议先暂停异常 MV 任务，重启 FE-02，持续观察内存曲线，并审查相关物化视图的刷新频率。
整个过程中，用户无需手动执行诊断命令。
Agent 自动执行符合只读规则的排查操作。涉及修复或写入的动作，系统会进入独立审批流程。
二、通用 AI 为何难以完成生产排障
通用 AI 可以回答数据库知识问题，也可以提供排查建议。
生产环境排障还需要更多能力：实时感知、证据采集、递进推理、工具约束和安全控制。
AI Copilot 可以给出建议。DevOps Agent 可以感知环境、调用工具、验证证据，并在受控条件下推进执行。
三、重新定义生产级 DevOps Agent
MirrorShip DevOps Agent 面向数据库生产排障场景。它能够感知实时集群状态，调用受控诊断工具，基于现场证据推进多轮分析，并在独立安全机制的约束下执行操作。
用四个词概括：懂现场 · 会排查 · 能执行 · 有边界。
懂现场
Agent 从 MirrorShip Manager 获取实时集群信息，包括节点拓扑、角色状态、监控指标、日志和系统元数据。
这些实时上下文让 Agent 可以从实际运行状态出发，而非只依赖一句问题描述。
会排查
Agent 按照结构化 Skill 中定义的诊断路径推进排查。
每一步都有明确目标：验证一个假设、排除一个方向，或收集下一轮分析所需的证据。
能执行
Agent 可以调用监控、日志、系统表、节点命令和诊断脚本等工具。
它会根据当前证据选择下一步操作，并持续更新排查计划。
有边界
Agent 能够参与生产排障，但必须在明确的权限和安全规则内运行。
后端独立校验操作类型、目标节点、审批状态和执行内容。系统据此限制 Agent 的执行范围。
四、用结构化 Skill 沉淀专家经验
要让 Agent 稳定参与排障，团队需要把专家经验沉淀成可复用的工程单元。镜舟使用结构化 Skill 组织这些能力。
每个 Skill 聚焦一个明确的问题域，并定义：
-
适用场景与触发条件；
-
排除条件与退出边界；
-
需要采集的证据；
-
从症状到候选根因的决策路径；
-
可调用的工具与命令模板；
-
操作权限和安全约束。
当前，MirrorShip 已沉淀首批 17 个结构化 Skill，覆盖查询、导入、Compaction、节点、物化视图、数据湖、资源隔离和存算分离等高频场景。
Skill 的价值来自清晰的工程结构。每个 Skill 都让 Agent 知道：
-
什么时候应该介入；
-
先查什么；
-
如何判断证据是否充分；
-
哪些工具可以调用；
-
哪些动作需要审批；
-
哪些高危操作必须拒绝。
这套机制让团队持续吸收 DBA Know-how，并将其沉淀为可复用的 Agent 工程体系。
生产排障类 Skill
开发与设计治理类 Skill
五、从单点问题扩展到跨 Skill 故障链
真实生产故障往往会跨越多个系统模块。
-
一次慢查询可能与 Compaction 积压、Tablet 版本数膨胀有关。
-
一次 FE 内存异常可能同时受到高频 MV 刷新、大查询规划和元数据操作的影响。
-
一次导入超时也可能涉及 BE 负载、MemTable Flush、RPC 队列与对象存储响应。
DevOps Agent 可以根据排查结果联动多个 Skill。当 query Skill 发现版本数异常时，Agent 可以继续加载 compaction Skill；当 node Skill 发现 FE 内存异常时，Agent 也可以调用 materialized-view 或 high-concurrency Skill 继续验证。
这种跨 Skill 的故障链能力，帮助 Agent 从单点症状逐步定位系统级问题。
六、安全闸门：安全边界不由模型决定
生产环境需要明确的权限边界和执行规则。
镜舟将模型推理与操作授权分开处理。模型可以分析问题、提出操作建议和生成执行计划。后端独立判断操作是否允许执行。
后端会识别命令类型，校验目标节点、操作参数和审批状态，并根据规则执行以下策略：
-
只读操作自动放行；
-
写操作进入人工审批；
-
系统无法确认操作属性时，默认进入审批；
-
高危操作直接拦截，例如删除生产表、清空表或其他不可逆操作。
审批内容与执行内容保持一致
审批页面展示的命令、参数和目标节点，会与最终执行内容逐项校验。
系统使用 SHA-256 固化审批内容。内容发生变化时，校验立即失败，执行请求会被拒绝。
每次审批对应一次执行
每个审批令牌只能使用一次。系统会在执行后消耗审批令牌。后续操作需要重新申请审批。
锁定执行目标
每个操作都绑定目标节点或目标集群。Agent 无法在审批后将操作转移到其他节点执行。
这套机制为 DevOps Agent 划定了清晰的生产边界：Agent 可以参与诊断和操作编排，平台始终掌握最终执行权限。
七、从自然语言到受控执行
当用户发起排查请求时，DevOps Agent 会按照以下过程推进。
1. 意图识别，加载 Skill
每个 Skill 都配置了标准化的 Description、关键词和适用边界。用户不需要记住 Skill 名称，可以直接使用日常语言：
-
"查询突然变慢了"；
-
"机器 CPU 打满了"；
-
"FE 状态异常"；
-
"Broker Load 一直超时"；
-
"MV 反复刷新失败"；
-
"存算分离集群 Compaction Score 降不下来"。
如果用户描述模糊，Agent 会先读取基础拓扑和关键指标，再决定排查方向。
2. 感知现场，获取上下文
与通用 AI 工具不同，DevOps Agent 在进入具体排查前，会通过 Manager 获取当前集群的实时信息，包括：
-
FE、BE/CN 节点及其存活状态；
-
FE 的 LEADER/FOLLOWER 角色；
-
Manager 内部 Agent ID；
-
节点 IP 和实例路径；
-
部署架构与节点类型；
-
可用监控指标；
-
托管 SQL 连接。
这些信息构成排障上下文，也为后续判断提供依据。
3. 建立假设，定义验证方法
Agent 根据 Skill 的决策路径，生成按优先级排序的候选假设。
每个假设都会对应具体的验证动作。例如，Agent 不会停留在"可能是 Compaction 问题"的泛化判断，而会继续查询 Compaction Score、版本数、调度队列和吞吐指标。
4. 多通道采证，持续收窄范围
Agent 可以通过多类通道采集证据：
-
指标查询通道：获取 Prometheus 或内置监控体系中的时序指标；
-
节点命令通道：执行经过授权的只读 OS 级诊断命令；
-
托管 SQL 通道：查询 StarRocks 系统表和诊断视图；
-
诊断脚本通道：运行经过结构化管理的参数化脚本。
Agent 对多来源证据进行交叉验证，然后更新候选根因的优先级。
证据充分时，Agent 会给出结论和下一步建议；证据不足时，Agent 会继续推进下一轮排查。
持续扩展排障能力，让专家经验持续积累
DevOps Agent 当前已经覆盖一批高频数据库运维场景，团队也在持续完善相关能力。
下一阶段，团队将重点推进三个方向：
-
扩展知识覆盖：将更多长尾故障、版本差异和行业场景沉淀为可复用 Skill；
-
增强跨域编排：提升多个 Skill 在复合故障中的协同、排序和决策能力；
-
优化超大规模上下文管理：通过增量拓扑、上下文压缩和分层检索，降低大规模集群的分析开销。
团队会将真实故障的排查结果、复盘结论和规则修正持续纳入 Skill 与知识库。每一次排障、复盘和工程校验，都会帮助镜舟完善知识库、工具规则与安全机制。
镜舟希望构建一套可持续演进的数据库运维工程体系。
团队可以将资深 DBA 的判断路径沉淀为结构化 Skill，将排障过程沉淀为可验证的证据链，并将真实故障的复盘结果持续纳入知识库、工具规则和安全机制。
这种积累会让团队逐步形成三类能力：
-
用统一方法处理高频故障；
-
用可审计流程管理生产操作；
-
用真实案例持续完善 Agent 的知识与执行能力。
随着部署、升级、诊断、优化和故障处理能力持续结构化，MirrorShip Manager 将不断扩展其数据库运维能力。
它将逐步承载 Agent 的感知、推理、工具调用、权限控制和执行审计，并演进为数据库基础设施的 Agent Runtime。
镜舟 DevOps Agent 是这一演进的重要起点。它让 AI 能够进入真实生产现场，并在清晰、可信、可治理的边界内参与数据库运维。