凌晨两点，Redis集群报错，你的值班手机响了。这时候打开AI助手，它却调了个最贵的推理模型去解析三行nginx日志——这种事发生过一次，你就知道问题在哪了。

不是AI不行，是"每次盲目调用同一个模型"这个假设本身有问题。贵，而且慢。在实时故障响应场景里，慢就是致命伤。

打开网易新闻 查看精彩图片

这是IncidentOS诞生的背景。它是一个面向SRE团队的AI运维记忆系统，核心要解决的不是监控问题，是记忆问题。

Datadog和Grafana擅长告诉你"现在发生了什么"。但它们不会说"这个模式八个月前出现过，原因是这个，当时这么修好的"。这是另一类问题，需要另一类工具。

IncidentOS的系统分两层：

记忆层——由Hindsight驱动。每个经过系统的故障都会被记录：症状、根因、受影响服务、部署版本、修复步骤、修复是否有效。新故障进来时，Hindsight做语义搜索找历史相似案例。不是关键词匹配，是语义相似度——所以"Prisma连接超时"和"数据库连接池耗尽"能被正确归到同一类模式。

运行时智能层——由cascadeflow驱动。每个AI请求被路由到适合该任务的模型：简单日志解析走快而便宜的模型，故障摘要走中端模型，需要综合多个历史案例的复杂根因推理才升级到高级推理模型。路由逻辑是显式的、可审计的、可配置的。

技术栈很务实：后端FastAPI（Python 3.11+），前端React 18 + Vite，向量存储用ChromaDB，整套Docker一键启动。它只做决策支持，不碰基础设施，工程师始终掌握最终决策权。

cascadeflow是这个系统能用起来的关键。它让"该用什么模型"这个判断从隐式变成显式，从固定变成动态。一次请求可能经过多轮模型协作：先快速分类，再按需升级，最后汇总输出。每一轮的输入输出都被记录，方便事后复盘为什么走了这条路径。

这套机制解决了一个真实痛点：推理成本。不是每个故障都需要最强模型，但你需要在需要时能调到它。路由的本质是效率——用对的资源解决对的问题。

IncidentOS目前聚焦在故障记忆的沉淀和复用。它的价值假设是：工程团队反复解决同样的故障，只是不知道之前已经解过。把隐性经验变成可检索的结构化记忆，这是它想验证的命题。