PolarDB-X Loop 工程實踐：從報警到自動修復

2026-11-05 4

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文介绍PolarDB-X团队在2026云栖大会分享的AI工程实践：构建能自主完成报警分析、稳定复现、代码修复与验证的AI Agent。通过CLI工具集成监控/日志/拓扑系统、增强调试与内存分析能力、提供轻量及集群复现环境，并以“可复现用例”为交付门槛，实现70%以上缺陷自动修复并进入评审，显著提升研发效率。（239字）

引言

本文为 2026 年云栖大会 《AI 原生研发组织论坛》的相关分享内容整理

年初，我修过一个让我印象深刻的 Bug。最后真正要改的代码，其实只有两行，但前面查日志、看监控和分析问题，就花了我一整天时间。为了复现问题，我只能在各种会议的间隙中抽空反复调试，前后接近一周才完成。之后还要补测试用例、跟进代码评审，直到把代码合进去。

现在，AI 已经能帮我们写代码了。但如果只是帮我写那两行代码，其实也没省下什么时间。那些真正费时的工作，能不能也交给它？

这次分享的，就是我们在 PolarDB-X 团队做的一些工程实践：让 Agent 从一条报警或工单出发，自主完成排查、复现、修复和验证，再把结果交给研发评审。

一、背景

PolarDB-X 是一款分布式数据库。数据库承载着大量用户的业务，一旦出问题，可能影响业务运行，甚至造成数据损坏。因此，我们对正确性和可靠性的要求非常高。

分布式系统本身也很复杂。它拥有多个组件和模块，线上还会有多个版本并存。一处修改可能影响其他功能，这增加了编码、问题排查和回归验证的难度。让 Agent 参与研发，同样需要面对这些要求。

经过一段时间的实践，我们将研发任务分成两类，采取不同的协作方式。

第一类是新功能开发，或者已有功能的优化迭代，比如优化分布式事务、实现新的数据压缩能力。这类任务涉及的组件较多，很多实现细节需要在开发过程中不断调整。研发仍然需要主导方案设计和关键决策，Agent 主要协助完成编码和测试。

第二类是处理工单、报警以及缺陷修复。这类工作对系统稳定性很重要，也是团队长期的痛点。相对而言，它们要解决的问题比较明确，代码修改通常较小，处理结果也可以通过测试来验证。因此，我们尝试让 Agent 自主完成这类任务，研发负责审核交付结果。

二、从报警到自动修复

围绕这类任务，我们建立了一套端到端的修复流程。Agent 接到报警或工单后，先获取现场信息，分析可能的原因，再准备环境尝试复现，验证自己的判断。等问题能够稳定复现以后，它才修改代码，并把复现过程固化成测试用例。通过回归测试后，再将代码和验证结果交给研发审查。

要让 Agent 自主完成这套流程，我们首先得保证它产出的结果可靠。

说到可靠性，大家往往更关注编码阶段，希望通过特定的 Skills 或者约束来保证代码的正确性。但在缺陷修复中，稳定复现是最重要的一步。如果没有把问题复现出来，就很难确认分析结论是否正确。分析本身出了错，即使代码写得再规范，也可能没有解决真正的问题。

因此，我们设置了三个关键门槛：现场信息要完整，问题要能稳定复现，修复结果必须经过测试验证。后面的工具和环境建设，都是围绕这些要求展开的。

三、从报警和工单中还原完整现场

报警和工单通常只记录了问题现象。要形成完整的修复需求，还需要补充现场信息，弄清楚发生了什么，并判断它是否属于缺陷。

早期，这些工作都由研发完成。我们需要看监控、查日志，再结合源码分析问题。确认是缺陷以后，才整理成修复需求交给 Agent。

后来，我们尝试把收集到的现场信息直接交给 Agent，让它自己分析问题、整理需求。实际用下来，我们发现它在这些工作上往往做得比人更好：它能把问题发生前后的时间线梳理得更清楚，也擅长从海量日志中检索和分析数据，还能注意到一些人工排查时遗漏的关键线索。

于是，我们又进一步让 Agent 直接接收报警和工单，自己收集信息。它可以根据分析需要，查询实例管控平台中的拓扑、配置和任务流，查看监控指标和日志，再结合代码仓库中的实现和变更继续分析。

例如，一条 SQL 执行报错后，Agent 可以根据报警中已有的实例 ID 和报错信息，到日志系统找到对应的错误堆栈，再结合源码分析可能的原因。最终，它整理出问题现象、现场证据和原因假设，为后续的复现和修复提供依据。

要做到这一点，Agent 必须能够自主获取这些系统的数据。

以监控平台为例，以前我们会把截图发给 AI，让它帮忙分析。监控曲线便于人观察变化，但 Agent 还需要能够按需查询、解析和比较原始数据。

阿里云已经提供了官方命令行工具，也就是 CLI。Agent 可以通过图中的命令查询 PolarDB-X 监控，拿到指定时间范围、指定节点的结构化数据，继续开展分析。

其他常用系统也需要提供类似的能力。比如日志，最好先汇集到 SLS 这样的日志平台，再通过查询接口或者 CLI 工具提供给 Agent。这样，分析过程中缺少什么信息，Agent 就可以自己去查，而不必等研发补充材料。

有些存量平台缺少维护，可能也没人来提供适合 Agent 使用的工具。遇到这种情况，我们能不能自己做？

阿里内部有一个很受欢迎的“抢会议室”CLI。通过一条命令就能预订会议室，还可以让 Agent 设置定时任务，到点自动去抢。后来我们发现，作者是一位普通研发同学，并没有会议室平台的源码。

这给了我们一个直接的启发：常用平台上需要的功能，也可以由我们自己封装成 CLI。

具体做法是，让 Agent 参考已有 CLI 的实现和认证方式，再操作网页，分析背后的接口请求，最后把需要的功能封装出来。用这种方式，我们大概花了一周时间，就把常用功能集成到了一套 CLI 工具中。监控指标、日志和实例拓扑等信息，都可以通过命令获取。

信息获取走通以后，Agent 就能够自己往下分析。但它给出的分析，是否一定正确？

四、让 Agent 用实际运行验证分析

我们遇到过一个低概率并发问题。它在线上存在了很长时间，因为触发概率低、很难复现，一直没能查清原因。

Agent 拿到现场信息后，只花了几分钟就给出了一份分析报告。代码位置、执行过程和可能出问题的地方都写得很完整，看起来专业，也很有说服力。但我们花了大概两个小时验证，发现这个解释并不成立。

把结果反馈给它以后，它很快又给出一版新的分析。我们再验证，还是不对。来回几次，留下了一堆报告，问题却没有弄清楚。下面展示的就是当时的分析及报告列表，其中的原因解释后来都被实际验证推翻了。

其实，无论是自己排查问题，还是验证 Agent 的分析，我们都需要准备环境，尝试复现。必要时，还要打断点调试，控制线程的执行时序，甚至检查内存数据。

当时的 Agent 缺少这些手段，只能靠静态代码分析，给出的解释与真实运行情况对不上，也无法独立完成验证。

为了让 Agent 能够自己动手验证，我们补充了调试和内存分析两类工具。

把调试和内存分析工具交给 Agent

我们的核心组件用 Java 编写，所以一开始尝试的是 JDK 自带的调试工具 JDB。它主要面向人设计，需要在终端中持续交互。Agent 使用时，要维护一个交互进程，再通过进程通信发送命令、读取输出，使用起来比较麻烦。

于是，我们基于 Java 调试接口重新实现了 JDB CLI，让它更适合 Agent 调用。

这个工具负责会话管理，在后台持续保留调试进程和现场。前台每条命令执行完就可以退出，下一次调用仍能接着操作同一个会话。结果以结构化形式返回，Agent 可以解析和检查，也可以等待断点命中，再获取相关线程、栈帧和变量信息。

另一个关键能力是指定线程断点：只让目标线程触发断点，命中后也只暂停这个线程，其他线程继续运行。再配合恢复操作，就可以控制相关线程按特定时序交替执行。

前面那个低概率并发问题的复现，就用到了这项能力。

除了调试运行中的程序，我们还需要检查锁泄漏时的内存现场。通过分析 Java 程序的堆内存快照，也就是 Heap Dump，可以查看相关对象的字段值、引用关系和内存占用。

Heap Dump 文件通常很大，我们把文件放到大内存云服务器上集中加载和处理，并专门为 Agent 提供查询接口。Agent 通过接口查询所需的内存数据，根据结果继续分析，无需自行在本地处理整个大文件。

分析完成后，Agent 还可以把分析记录和最终报告上传到平台，方便研发后续查阅。这样，内存现场就成为 Agent 可以直接检查和引用的证据。

根据问题需要准备复现环境

有了工具，还需要运行环境，Agent 才能真正动手尝试复现问题。我们提供了轻量环境和完整集群两种选择。

第一类是 PolarDB-X Zero。Agent 可以在几秒内创建一个临时实例，用来快速尝试复现简单问题，比如 SQL 报错或者功能异常，用完以后立即释放。它提供固定版本的实例，适合先做快速验证。

如果问题需要特定的历史版本、拓扑，或者涉及复杂的并发场景，就使用 K8s 中的完整复现环境。Agent 可以按照问题实例的版本和拓扑搭建集群，再配合调试工具尝试复现。

代码修改完成后，Agent 还可以将修复后的版本部署到这个环境中，用同样的方法检验原来的问题是否已经解决。

让偶发问题可以稳定复现

有了这些工具和环境，我们再回到前面的并发问题。

这次，Agent 能自己尝试复现，并根据实际运行结果继续分析和调试。经过几轮迭代，它找到了关键触发条件，复现出了与原问题相同的 MDL 锁泄漏现场。

关键在于，Agent 通过调试工具，让两个线程按特定时序交替执行，把原来很难碰到的偶发问题主动构造出来了。调试结果还可以与内存现场相互印证，检查复现出的是否就是同一个问题。

这时，我们既有根因分析，也有可以重复执行的操作步骤，还能观察到这些步骤确实触发了原问题。Agent 的分析结果有了实际运行的证据支撑。

稳定复现的价值，还在于让后续修复有了明确的验证依据。这些步骤可以进一步固化成测试用例，用于检查代码修改后的效果。

五、把稳定复现用例作为交付门槛

在实际交付中，我们将稳定复现用例设为进入代码评审的一道关键门禁。Agent 补了测试、测试运行通过，还不足以说明原问题已经解决，首先要确认用例确实触发过那个问题。

同一个用例，在修复前的版本上必须能够稳定复现原问题，在修复后的版本上必须验证问题不再出现。完成这组对照验证，并通过完整的回归测试后，代码才能进入评审。

Agent 提交合并请求时，会一并交付代码、用例和验证结果。研发先检查有没有对应的复现用例，再对照最初的问题描述，确认用例复现的确实是原问题，然后才继续审查代码改动。审查通过后，按流程合并。

前面那个低概率并发问题，最终也由 Agent 完成了修复，并通过了验证。

六、让流程持续运行，进入日常研发

要让这套修复流程承担日常工作，还需要一个能够持续运行的环境。

早期，我们把它跑在笔记本上，结果屏幕一合上，整个流程就断了。要让 Agent 持续处理报警、分析问题和修复缺陷，运行环境也需要独立于研发的本地电脑。

为此，我们基于云端沙箱构建了 PolarDB-X Agent，让前面介绍的流程能够 7×24 小时持续运行。

云端沙箱还能与本地开发环境隔离，避免执行任务时影响研发电脑。我们也可以限制沙箱内工具的访问和操作权限，让执行过程更加安全、可控。

截至本次演讲，这套流程已经承担了日常报警处理和缺陷修复中的实际工作。

所有报警都会先由 Agent 完成首轮分析和处理，首轮覆盖率达到 100%。半年内，我们从上万次报警处理中识别并记录了 200 多个缺陷。其中，超过 70% 的缺陷能够稳定复现，并由 Agent 完成修复后进入代码评审。

对研发来说，原来需要花大量时间排查、复现和修复的问题，现在可以先由 Agent 自己处理，再将问题描述、代码修改及验证结果交给研发审查。

七、三条可以借鉴的工程启发

回顾这套流程，我们总结了三条工程启发。

第一，让研发系统可以被 Agent 调用。可以先从团队常用的系统入手，给它们配上 CLI 工具，或者开放 API 接口，让 Agent 能够自主获取信息、操作这些系统。分析过程中缺少材料时，它可以自己补齐。

第二，让研发过程可以验证。给 Agent 提供调试工具和运行环境，让它能够自己复现问题，检验分析结果。实际运行的反馈，才能帮助它发现错误、调整分析，并继续完成修复。

第三，让任务流能够持续运行。将流程放到云端，让 Agent 可以持续执行任务，不再依赖研发的本地电脑。

其他团队也可以先选一个目标明确、结果可验证的任务，为 Agent 准备好所需的工具和环境，把流程跑起来，再根据实际遇到的问题逐步完善。

这就是我们在 PolarDB-X 的 Loop 工程实践。谢谢大家。