在SRE和稳定性工程领域，告警诊断Agent大概是当下AI落地最热门的场景之一了。对于告警应急场景，有一个迅速可靠的Agent做根因分析，通过透出问题链路关键的信息点，可以省掉很多前期的排查精力，帮助线上问题更迅速被解决。
从实现难度上看，写一个能跑的告警诊断Agent或者Skill，门槛其实不高。接几个Tool（查日志、查监控、查变更记录），写一段System Prompt描述诊断流程，大模型就能按照套路给出一个看似合理的分析结论。但如果要把它做到真正好用、能让大家都信赖程度，那难度就完全不一样了。
所以今天这篇文章就聊一下，如何用AI-Native的方式去研发一个高质量的告警诊断Agent。
在非常久远的文章中，我们提到python中实现并行执行程序的方式主要是通过multiprocessing实现的，而并非多线程（Threading）。机理层面，大致是会开一个新的子进程独立执行，主进程维护一个Sentinel（fd），默认通过pickle跟pipe方式和子进程通信。
而现在，python也到了3.14版本，除了multiprocessing与Threading之外，对于多解释器的支持也比较完善。多解释器的机理可以参考concurrent.interpreters官方文档，简单来讲就是这类并发不像多线程受GIL的约束，一个进程里执行多套解释器，每个解释器有自己的GIL，有点类似于Golang的机制。以下是一些典型用法：
近期笔者因为工作原因，开始大规模使用Vibe Coding的方式来编写后端项目。说实话，笔者目前大概99%的代码都是通过Vibe Coding生成的，已经基本不手写代码了。
在先前的文章里，笔者也聊到了用Vibe Coding写前端原型的经验，而这篇文章则聚焦后端侧，也是更加偏重于业务工程的研发场景，今天这篇文章，笔者让AI列举了一些后端项目Vibe Coding场景下，各位开发者都比较关心的问题，然后做一些简练的回答。
在先前的一篇文章里，笔者聊到了从内部变更风险防控转向ToB客户稳定性保障的一些思考，主要聚焦在角色转变和业务场景的差异上。今天这篇文章，就探讨一下笔者对于如何搭建一套客户稳定性系统的一些想法，算是把之前的思考往落地层面再推进一步。
首先，一套客户稳定性系统，从产品角度考虑，需要体现对客的属性。也就是说，这套系统不是单独去关联很多能力，而是结合这些能力的执行表现，去抽象出一套客户风险大盘的视图。从这个角度来讲，我们这套系统可能就需要有以下核心的内容：
近两天最火爆的事情莫过于《置身钉内》了，一篇离职复盘写了7万多字，熟稔的笔锋之间也夹杂了很多深度的思考，堪比互联网行业里头的《活着》。
笔者也有幸拜读了全篇文章，从作者的文风可以稍微推断其人物画像，某些特征也和笔者刚毕业那会儿比较相似，稍有一些学生思维，但不失理性的思考。不仅如此，作为同行业的工作者，同时也是一名坚持手写个人博客的作者，笔者对这篇文章里想要真实表达的情绪跟内容，也是比较有感触的。所以今天这篇文章，也简单写一下自己的感想。
AI Native是大势所趋，AI Coding的技能必不可少。鉴于此，笔者决定新开一个AI Native系列，记录自己后续在All-In-AI路程上的点滴，分享自己通过AI提升日常工作跟研发效率的思考和经验。
先前的文章也讨论到，因为工作的原因，笔者已经开始在做ToB稳定性治理的事情，所以近期也一直在通过Vibe Coding的方式，设计相关平台能力要做些什么，产品形式上需要如何呈现。从效果上看，AI写前端原型的能力还是比较OK的，能够很快速满足笔者的工作需要。今天这篇文章，就简单聊一下这个过程中的经验。
笔者用的工具是Qoder，通过Quest模式去快速搭建前端原型，整一个过程是这样的：
近期因为工作调整的原因，笔者从以前面向内部研发团队的变更风险防控和稳定性建设，逐渐转向面向ToB客户的云服务稳定性保障。虽然本质上都是在做SRE稳定性相关的工作，但从服务对象、技术架构到运营方式，都有非常大的差异。今天这篇文章，就结合自己以前做变更风险防控和稳定性建设的实践经验，聊一下从云服务角度做ToB客户稳定性保障的一些思考和对比。
一块是服务对象的转变，以前做变更风险防控平台，服务对象是公司内部的研发和SRE团队，包括公司内部整体的架构也比较扁平，技术栈比较统一，所以沟通成本比较低，需求沟通起来也比较直接。在这样的场景下，变更风险防控平台的建设就会更加趋向于产品化，因为会有无数不了解稳定性业务或技术的同学来平台做咨询或者提需求，所以每项功能都做的比较细致体贴。最终呈现出来的平台不仅是功能齐全，在用户友好度上也有比较优质的体验。
不知不觉在质量技术领域也走过了七八年之久，从最早的覆盖率测试工具，UE4游戏客户端自动化，到后续的数据变更风险防控，再到变更风险防控平台架构建设，期间做过很多思考，也沉淀了许多技术文章。随着业务测试->质量提效->技术风险SRE->稳定性架构师的工作内容变化，笔者也自觉自己未来的工作从垂类角度，也会逐渐独立于质量技术，转而更加深入做SRE稳定性和后端架构领域。所以今天这篇博客，也决定和自己多年来的【测试人生】做一个暂时的道别，当然也借着这个机会，聊一下自己对于质量技术的现状和未来发展的思考。
首先聊一聊现状，坦白来讲因为AI时代的到来，质量技术又再一次焕发了生机。主要体现在以下几点：
近期AI编程的新概念层出不穷，从最简单的Code Completion，到NEXT预测，再到现在什么Vibe Coding、OpenClaw，外加Spec Coding、Harness Engineering等Agent工程名词，可以说随着LLM的能力增强，不考虑业务架构，纯考虑编程本身，AI几乎已经可以替代所有人类，对于程序员而言，以前要做亲自编码，现在则需要转化为一个管理者的角色，指导AI完成程序员的工作目的。
为了体验AI编程的强大，近期笔者借助AI Native的开发工具，通过纯Vibe Coding的方式，开发一个基于kubebuilder的operator管理工具。kubebuilder本身提供的命令和功能已经很丰富了，但还是免不了一些小问题，比如在国内某些镜像和依赖拉不下来，或者开发多个operator没有一个工作区做统一管理，这些问题都可以由一个operator-gallery工具去做解决。
换言之，operator-gallery的职责是封装kubebuilder，端到端地处理operator的构建、部署和卸载流程，这样开发者只需要专注在types和controller的实现就可以。
近期因为探索AI编程的缘故，希望给日常生活中多找一个AI-Native的IDE，一方面做纯Vibe Coding的开发，另一方面也能够兼顾日常手动微调编码的需要。当然由于众所周知的原因，也希望这个IDE可以照顾国内用户，不是说总是要搭梯子编程，这样编程之外的冲浪需求就不方便了。
经过一番探索，在Trae、Cursor以及Claude Code等一系列候选名单中，笔者选择了Qoder。并不算是打广告，主要是基于以下的理由：