在先前的文章里，笔者聊了怎么用AI-Native的方式编写一个告警诊断Agent和Skill，那篇更多是单点视角，怎么把一个Agent做好的问题。这篇文章接续上篇的内容，从一个更加完备的工程角度，简单聊一下怎么把Agent和Skill跟自己日常做的工作做更深度的集成，让人退到工程后面去，而不是把AI当做一个外挂的提效工具。
首先是第一条原则，深度放权，核心就是承认模型的智商比自己高，而且不是高一点半点。不管知识面、编码熟练度还是干活性价比，人跟模型比哪哪都差。所以能让Agent做的事情，尽量让Agent生成，Agent做不了的，才由人来做。
在先前治理后端稳定性的一些实战经验这篇文章里，笔者聊过稳定性治理的大致路径，先定指标，再保证可监控可观测，之后才是解决具体的技术问题。今天这篇文章就聚焦在可观测跟止损这两个环节，简单聊一下端到端的告警应该怎么梳理，以及严重告警的处理预案应该怎么做。这两块做扎实了，稳定性保障才算是有底子的，说到底目的还是稳定性本身，而不是把监控大盘做得多好看。
在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时代的到来，质量技术又再一次焕发了生机。主要体现在以下几点：