工作和生活里，遇到问题先问AI，已经成了习惯，但它默认给出的回复，质量可能不符合预期，很多回答根本不是在说人话，可读性非常差，什么A3B4C5D6，还有一大堆简写，看起来跟汇编代码一样。从AI的角度可以强行解析，但人根本没法判断。在先前的文章里，笔者也聊过Agent和Skill工程化的一些思考，但是面向通用的问答场景，还是无法系统性解决。
所以，今天这篇文章，提出一类系统性解决这类问题，并且保证AI工程可持续迭代的方法，那就是构建一套自己专属的AI Native Harness。AI回复的内容，与其回一段汇编代码，还不如一直闷头执行下去。靠换一个更强的模型，或者多写几句prompt，很难系统性解决。只有构建一套自己的AI Native Harness，把日常的经验、规则、资料和工具沉淀下来，才能够让AI的交付成果符合自己的预期。
在稳定性风险治理工作中，风险来源比较分散，如果只靠团队每个人自顾自处理，很多潜藏的风险容易漏掉，处理进度也不好跟进。面向这类难题，从组织层面一般的解法是立横向专项，派专人牵头治理。那么具体治理的执行怎么做，其实是有一套通用的方法论SOP的。
今天笔者就讲讲这个稳定性风险治理的通用SOP，简单来说，就是风险发现、根因诊断、解决闭环、数据运营四步曲。不同业务场景下的治理动作其实是相通的，这四个action可以很方便复用到各类场景上，区别只在每一步的具体实现。如果熟练掌握这套SOP的话，相信不管是什么风险治理的工作，你都可以有足够的信心。
恰逢中秋十一假期，想到自己的个人博客已经很久没有做前端优化了，趁着这段时间决定借助AI Coding的力量，把博客的前端样式整体优化一下，调整到自己预期内的效果。不得不说现在即便是很廉价的模型，最终都能够达成这个目标，因此打算写这篇博客，记录一下自己优化的历程。
先说结果，新的博客前端，主要优化了下面一些事情：
具体执行时，还是踩了一些坑，最终也都得到解决。
笔者的这台老土机器，超频折腾从第一次上手到后来靠降压加Process Lasso的优化，最终发现只能给CPU上到4.5GHz比较稳定，再上去散热就扛不住了，烤鸡直接到90度。
最近两天索性把主机拆了开来排查，另买了一套帝王引擎重新组装了风扇水冷，最终终于解决了散热问题，把老土机器的性能拉满。特此写一篇文章，分享一些经验。
在先前治理后端稳定性的一些实战经验这篇文章里，笔者聊过稳定性治理的大致路径，先定指标，再保证可监控可观测，之后才是解决具体的技术问题。今天这篇文章就聚焦在可观测跟止损这两个环节，简单聊一下端到端的告警应该怎么梳理，以及严重告警的处理预案应该怎么做。这两块做扎实了，稳定性保障才算是有底子的，说到底目的还是稳定性本身，而不是把监控大盘做得多好看。
在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的机制。以下是一些典型用法：