上一篇《数据库监控简史》从专家规则、AIOps讲到大模型与智能体——AI走进数据库运维。我们沿着经验进入软件的路径，讨论了AI如何解释告警、组织诊断并调用工具。但真实运维很少在一次回答后结束：故障处置要等发布负责人确认，参数调整要经过审批，迁移可能持续数周。作为系列终篇，本文再往前走一步：当AI走出问答窗口，它怎样接住一项工作，持续推进，并交付可验证的结果？

等待事件、ASH与AAS带来的变化，是性能问题终于可以按时间归因：DBA知道数据库的时间花在CPU执行、I/O等待还是锁等待上，并能进一步关联到具体SQL、会话与对象。以时间衡量负载与损失，也让不同瓶颈有了可以比较的尺度。

到了如今大家经常讨论的AI-DBA阶段，时间又多了一层含义。机器慢了多少是一条证据；DBA为寻找资产、补齐上下文、观察变更和整理复盘花了多久，则是一项工作的成本。《数据库监控简史》的前八篇主要讨论怎样留下现场、理解现场和组织处置，这一篇则要追问：现场之后的工作，能否少一些重复交接，多一些可靠推进？

2016年出版、汇集Google SRE实践的《Site Reliability Engineering》将具有手工、重复、可自动化、缺乏持久价值、随服务规模增长等特征的运维劳动概括为toil，主张持续减少这类负担。这给AI-DBA提供了另一把标尺：除了缩短数据库等待，还要减少人的重复劳动；省下的时间，应当回到架构改进、风险判断和业务保障中。

两种时间不能简单相加。数据库时间刻画请求在执行与等待上花了多久，工作耗时还包括取证、跨团队确认和变更窗口等待。某条SQL的耗时减半，不代表故障已经恢复；把审批取消，也不代表效率提高。要减少的是无效搬运和反复解释，让必要的判断更快得到充分证据。

设想核心交易库突然出现抖动。大模型根据监控数据给出初步判断：连接数上升，某类等待突出，可能与当天发布有关。接下来还要核对发布记录，找研发确认调用变化，形成处置方案，申请窗口，执行后观察一段时间，最后提交复盘。任何一步都可能等待、退回或变更。

对话以回答为一个阶段的结束，工作则以结果为结束。后者必须知道任务由谁发起、当前卡在哪里、使用过哪些证据、谁批准了高风险动作，以及最终交付物是什么。所谓“数字同事”，首先意味着系统能持续承接工作，而不能只靠拟人化的称呼。

2024年发表于PVLDB的D-Bot研究¹，已把文档知识提取、工具检索、多步诊断与多专家协作结合起来，并用539个异常开展实验。它说明数据库诊断正在从生成答案走向组织调查，但研究中的诊断报告，仍不能直接等同于生产处置完成。

到2026年3月31日，AWS DevOps Agent²进入正式可用阶段；它把监控、代码和部署记录纳入事件调查，并保留调查时间线。这不是数据库专用产品，却显示出共同方向：AI运维需要围绕持续任务组织证据，而非停在一次问答。

这也改变了验收方式：一次建议是否合理，要看依据；一项工作是否完成，还要看授权是否有效、约定步骤是否落实、验收目标是否达成。对于故障处置，还须验证业务是否恢复。系统既要记录做了什么，也要说清哪些步骤尚未完成，不能把“已经给出方案”当成“故障已经解决”。

图1：一次回答与持续任务的区别。

¹ D-Bot是一项利用大语言模型（LLM）实现数据库自动故障诊断与根因分析的研究，目标是让AI像资深DBA一样，面对数据库性能异常时，能够自主收集证据、分析问题、定位根因并提出解决方案，而不只是根据固定规则报警。论文由清华大学研究团队等共同完成，发表于2024年的数据库顶级学术期刊Proceedings of the VLDB Endowment（PVLDB）。

 

² AWS DevOps Agent是亚马逊云科技（AWS）推出的AI驱动的DevOps/SRE智能体。它不是单纯的聊天机器人，也不只是监控告警工具，而是能够连接监控系统、代码仓库、部署流水线和事件管理平台，综合多种证据开展故障调查。其运维界面支持创建和跟踪事件调查，并提供缓解方案和预防建议。

 

图2：工单保存目标、对象与环境、约束、状态、证据与结果、责任。

在数据库运维场景下，工单承载工作，团队负责人分派专业智能体（Agent），技能库提供巡检、诊断、调优和迁移等方法，记忆机制沉淀经验，权限与审计控制动作边界。

但Mopheus并不只服务于数据库运维。真正决定这个工作空间能做什么的，不是Agent的数量，而是它能调用什么技能、技能是否可靠。技能（Skill）定义了智能体可以处理的任务、能够使用的工具以及必须遵守的边界。在具备可信数据、受控连接和相应授权的前提下，装入数据库技能的智能体可以承担AI-DBA任务；装入其他专业技能，也可以处理相应业务工作。

因此，对AI-DBA来说，关键问题是怎样把资深DBA的经验转化为智能体能够执行的技能。一句“请像资深DBA一样分析”，只给出了角色期待，没有说明执行前提、所需权限、失败处理和验收标准。要支撑长期生产，这些要求必须成为可维护的操作规范，并由执行系统落实。

可复用技能更像一份可执行的Runbook（运维操作手册）。以慢SQL周报为例：它要规定数据库和时间窗如何输入，先检查哪些视图与权限，怎样采集AAS、等待事件和执行计划，如何区分一次性批处理与持续性性能问题并判断其业务影响，如何保证采集过程只读，报告需要包含哪些证据，采集失败时又该怎样退出。任务完成后，还要核对分析结论能否与原始数据相互印证。

微软在2026年9月29日的官方文章中介绍了面向Azure SQL的SQL智能体技能库³，将数据库连接、连接池、模式设计与迁移、查询排障等指引提供给编程智能体按任务加载。这还不是完整的AI-DBA，却说明专业经验正从散落的文档，变成可维护、可复用的任务资产。技能内容仍须由权限系统和执行工具落实约束。

Mopheus则把落地拆成三部分：智能体管理平台、智能业务资产集与FDE⁴现场专家服务。平台提供协作与治理，资产集沉淀行业模板，现场服务负责业务梳理、系统集成与调优。这也解释了为什么装好软件只是开始：企业自己的审批链、数据库版本和异常处理方式，仍须落到具体技能与流程里。

因此，Agent负责理解任务和处理分支，Skill提供操作方法，运行时接通真实环境，权限系统决定动作边界。DBA经验由此成为可执行、可复核、可修订的工程资产。

图3：从DBA经验到受控交付。

³ SQL智能体技能库（Microsoft SQL Agent Skills）是微软SQL产品团队为AI编程智能体准备的一套可安装、可复用的数据库专业技能包。它的目标是让GitHub Copilot、Claude Code、OpenAI Codex、Cursor等AI工具更准确地开发和运维Azure SQL等数据库，而不是仅凭大模型自身的通用知识来猜测。

 

⁴ FDE（Forward Deployed Engineer），指贴近客户业务与现场环境开展方案适配、系统集成和落地调优的工程师。这里指与平台、业务资产配套的现场交付服务。

 

记忆与安全必须进入同一个闭环

一次任务结束后，值得留下的通常不是整段对话，而是可复用的部分：哪个版本有已知问题，哪种拓扑下某一步会失败，专家为什么否决一个方案，最后用什么证据确认恢复。Mopheus将这套过程称为跨工单记忆：从已完成工单中提炼经验，写入持久化记忆，在相似任务中召回。

这种机制要带着克制使用。经验必须绑定数据库类型、版本、拓扑和时间，最好还有人工修订记录。去年的最佳实践可能是今年的错误建议；跨工单记忆只能提供候选路径，当前现场仍须重新取证。被否决的方案和适用限制，也应随成功经验一起留下，否则“越用越聪明”可能变成“越用越固执”。历史经验也不能连同当时的生产权限一起继承；每项新任务仍须核对当前授权和审批条件。

Mopheus支持本地部署、统一工作区RBAC（基于角色的访问控制）权限控制、过程审计与运行时异常熔断，并通过统一数据库访问层SwissQL（内置安全网关与规则引擎）对数据库操作实施高危命令拦截与全量审计。这些措施需要在实际环境中配置和验证；生产变更仍应遵守企业的审批与回退制度，不能由模型自行扩大授权。对DBA而言，这意味着采集慢SQL的工具只需获得必要的读取权限；终止会话、修改参数等动作，要另行走变更控制。

这些控制是AI-DBA本身的组成部分，不应被当作外围的“保险丝”。一个会从历史工单中学习的系统，如果没有最小权限、人工审批、执行超时、结果验证和回退，学习得越快，错误也可能传播得越快。安全的自治，要把人放在生产决策和最终责任的位置。

图4：记忆的复用需要当前证据，工作完成需要结果与安全共同验证。

沿着本系列建立的视角，三类产品可以放在不同层次理解：Bethune X侧重监控、巡检与诊断，提供数据库现场；zCloud把异构群库的资产、权限、流程与生命周期组织起来，提供统一运维控制面；Mopheus则围绕任务连接人员、智能体与执行环境，关注工作怎样走到交付。

这几层能力可以协作。没有可信资产和监控数据，数字同事无从下手；没有审批、工具与执行环境，再聪明的推理也落不到生产。试点应先确定一项明确的工作，再决定需要连接哪些能力，以及谁对交付负责。

DBA的工作也会向上移动：定义什么才算完成，设计技能与回退路径，按组织制度管理生产权限，复核跨系统证据，在性能、稳定性和业务窗口之间做取舍。重复取证、标准检查和报告初稿，可以逐步交给智能体，生产责任仍由人和组织承担。

企业落地时更稳妥的起点是结构清晰、频率高、读操作为主的任务，例如日常健康检查、慢SQL周报或迁移前核查。先把输入、证据、交付物和人工检查点定清楚，再统计按验收标准完成的任务比例、计划外人工接管次数，以及误判和回退情况。评价时还应检查证据是否完整、处置后是否复验。