阿里云公开 PolarDB-X 缺陷修复 Agent（智能体）实践：以告警为起点，先复现再修改
阿里云公开 PolarDB-X 团队一项内部 Agent 工程实践：让智能体从告警或工单出发，自主收集日志与监控信息、复现问题、修改代码并跑回归测试，再将结果交开发者审核。
团队称可稳定复现超过 70% 的缺陷，并把“可靠复现”而非写代码本身作为可靠性关键； 该比例为阿里云单方口径，未见独立评测。
文章由阿里云作者盛涛涛（花名无木）撰写，节选自开源项目 Alibaba Cloud AI Agent Handbook（阿里云 AI（人工智能） Agent 手册）。 团队将开发任务分为两类：新功能开发仍由开发者主导方案设计与关键决策，智能体主要辅助编码和测试；
工单、告警与缺陷修复因问题定义相对明确、改动小、结果可测试，交由智能体自主完成，开发者负责审核交付物。 端到端流程为：接收告警或工单→自行查询实例管理平台的拓扑、配置、任务流，查询监控指标与 SLS（阿里云日志服务）日志平台日志，查看代码仓库实现与变更→复现问题→修改代码并把复现步骤转为测试用例→通过回归测试后提交代码与验证结果。
团队提出三项关键要求：事故信息完整、问题可靠复现、修复经测试验证。 为让智能体自主取数，团队用约一周时间把监控、日志、实例拓扑等常用功能封装为一套 CLI（命令行接口）工具；
因原有 Java 调试工具 JDB（Java 调试器）面向人工交互，团队基于 Java 调试接口重写了适配智能体的调试 CLI，支持会话保持、结构化返回与线程级断点，用以控制线程交替执行、复现低频并发问题； 内存分析则通过集中加载 Heap Dump（堆内存快照）并提供查询接口完成。
复现环境分两种：轻量的 PolarDB-X Zero 可在数秒内创建临时实例，适合 SQL 报错等简单问题； 涉及特定历史版本、拓扑或复杂并发时，在 K8s（Kubernetes 容器编排系统）上构建与故障实例同版本同拓扑的完整集群。
文中提到一次低概率并发问题的经历：智能体几分钟内给出看似专业的分析报告，但人工验证约两小时后被推翻，多轮迭代后仍未定位原因； 补充调试与内存分析工具后，智能体最终自行识别触发条件，复现出与原始问题相同的 MDL（元数据锁）锁泄漏状态。
这篇文章的价值不在“AI（人工智能） 写代码”，而在把智能体的可靠性前移到可复现性：没有可执行的复现，静态代码分析产出的结论可能“专业但错误”，文中那次数小时被推翻的分析报告就是例证。
另一个值得注意的工程判断是，团队把工具适配当作核心投入——把监控、日志、调试器、堆内存分析改造成结构化、可被程序调用、支持会话与断点的接口，本质是在为智能体搭建可验证的执行环境，而非仅优化提示词或技能。 这提示企业级编码智能体的落地瓶颈可能更多在可观测性系统与调试基础设施的接口化程度。
需注意，缺陷修复任务相对明确、改动小、可测试，是团队主动选择的适用边界； 新功能开发仍由人主导，这一分工不应被推广为智能体可端到端替代开发。
后续观察信号
- 70% 以上复现率的样本来源与统计方法
- 智能体提交的修复在代码评审中的实际通过率
- 开发者审核环节的耗时变化