最近我看完 Neubird 这家公司，感受挺强烈。
它和 incident.io、Rootly 不太一样。incident.io 和 Rootly 更像是从事故协作、Slack/Teams、On-call、复盘这些场景切进去。Neubird 则更像是直接盯住了 AI SRE 里最硬的一块：自动调查。
它不是想重新做一个 Datadog、Splunk、Grafana 或 New Relic，也不是简单给可观测性平台加一个聊天框。
它想做的是一个 Production Ops Agent：当告警来了，AI 自动去查指标、日志、链路、事件、配置、代码、云资源、历史事故和 runbook，然后给出证据链、候选根因、影响面和下一步动作。
这件事听起来还是 AI RCA，但我觉得更准确的说法是：它在尝试把 SRE 的排障过程产品化。
这对国内做监控、可观测性、AIOps、AI RCA 的厂商很有参考价值。
因为很多 AI RCA 产品现在最大的问题不是“不够会总结”，而是“没有真的调查”。
AI RCA 不能只是 dashboard copilot
现在很多产品做 AI RCA，路线大概是这样的：
拿一条告警。
截几张指标图。
拉几段日志。
把这些上下文塞给大模型。
让模型生成一段“疑似根因分析”。
Demo 时看起来不错。
但真实生产环境里，这种东西很容易不够用。
一线工程师不会因为 AI 说“可能是数据库连接池耗尽”就相信它。他会继续问：
哪个数据库？
哪个连接池？
哪个服务打满的？
什么时候开始的？
是不是发布引起的？
日志里有什么证据？
trace 里有没有下游超时？
有没有类似历史事故？
如果重启会不会更糟？
还有哪些方向已经排除了？
这些问题不是靠一段总结能解决的。
所以真正有价值的 AI RCA，不应该只是 dashboard copilot，而应该是 investigation engine。
Neubird 的公开资料里最值得研究的地方，就是它把 RCA 拆成了一个完整调查流程，而不是简单让 LLM 读日志写小作文。
它把 RCA 拆成了一个 7 步调查系统
Neubird 官方文档和技术博客里讲了一个比较清晰的 7 步调查架构。
第一步，不是直接给答案，而是先找相似历史事故和调查模式。
这点很重要。一个资深 SRE 之所以快，很多时候不是因为他现场推理能力比别人强十倍，而是因为他见过类似问题。他知道上次这个服务因为哪个配置出过事，知道某个告警通常是连锁反应，知道哪个 dashboard 真正有用。
Neubird 用向量数据库去查历史相似事故和有效调查路径，把它们作为当前调查的起点。
第二步，生成动态调查计划。
它会根据当前告警、已连接的数据源、客户架构、历史模式和当前证据，决定先查什么、后查什么。
这和传统 runbook 不一样。传统 runbook 是固定步骤，适合标准问题。但真实事故经常会在调查过程中改变方向。你以为是数据库，查着查着发现是下游重试风暴；你以为是新发布，最后发现是云资源配额或证书问题。
好的 AI SRE 不能死跑固定流程，它要能根据证据调整调查路径。
第三步，是 Neubird 最有意思的地方：它不把原始 telemetry 直接丢给 LLM，而是让 LLM 生成 telemetry retrieval program。
也就是说，LLM 不是直接读一大堆日志和指标，然后凭语感总结。它先根据 schema、字段、时间范围、数据源 metadata 生成查询和分析程序，然后在隔离 runtime 里执行。
这条路线很关键。
它把 LLM 从“直接看敏感数据并发表意见”，变成“生成查询计划和分析程序”。真正的数据查询、过滤、计算和聚合发生在受控环境里。
第四步，进入安全的数据处理环境。
Neubird 反复强调 zero data storage、read-only access、temporary credentials、ephemeral runtime、no telemetry data on disk、no LLM training on customer data。
简单说，原始 telemetry 只在 investigation 期间以内存方式处理，session 结束后清理，不进入外部 LLM，不长期存储。
这不是技术细节，而是企业客户能不能接受 AI SRE 的前提。
安全架构会决定 AI SRE 能不能进生产
很多 AI 运维产品在 demo 环境里都很好看。
因为 demo 环境里什么数据都能看，什么权限都能给，什么日志都能发给模型。
但到了真实客户现场，问题马上来了：
日志能不能出内网？
trace 里有没有敏感字段？
代码能不能发给外部模型？
云资源拓扑能不能被 SaaS 读取？
AI 查了什么能不能审计？
它有没有生产写权限？
模型会不会用客户数据训练？
这些问题不解决，AI RCA 很容易停在 POC。
Neubird 的 metadata-only LLM 思路，对国内市场尤其有参考价值。
它让 LLM 只看到字段名、schema、数据结构、时间范围、可用工具这些 metadata。原始日志、trace、指标、配置和代码不直接进入模型。查询和计算在隔离环境里执行。
这条路线比“把日志截断后塞进 prompt”更适合企业级场景。
国内金融、运营商、能源、制造、政企客户只会更敏感。很多客户连日志出内网都不允许，更不用说把生产数据发给一个外部大模型。
所以我觉得，AI SRE 产品从第一天就应该把安全架构当成主线，而不是等客户问了再补。
默认只读、最小权限、数据脱敏、工具调用审计、本地执行、私有化部署、客户自有模型，这些不是企业版锦上添花功能，而是进生产的门票。
Neubird 的关键不是存数据，而是会查数据
Neubird 不强调自己存储所有 metrics、logs、traces。
它连接客户已有工具：Datadog、Splunk、Dynatrace、Grafana、Prometheus、New Relic、CloudWatch、Azure Monitor、GCP Logging、OpenSearch、OpenTelemetry、PagerDuty、ServiceNow、GitHub、GitLab、ArgoCD、Jenkins 等。
这和 Resolve AI 有点像：不替换可观测性栈，而是在现有工具之上做调查层。
但 Neubird 的表达更“工程化”。它讲 MELT+。
传统可观测性常讲 MELT：Metrics、Events、Logs、Traces。
Neubird 在后面加了两个非常重要的东西：Config 和 Code。
这点我很认同。
很多真实事故，根因不在 metrics、logs、traces 里，而在 config 和 code 里。
哪个 Kubernetes manifest 改了？
哪个 deployment config 变了？
哪个 PR 刚 merge？
哪个 CI/CD pipeline 推了版本？
哪个 Terraform 改了云资源？
哪个 feature flag 改变了流量路径？
哪个 runbook 其实已经过期？
如果 AI RCA 只看 telemetry，它最多能告诉你“这个服务从 10:03 开始错误率上升”。但工程师真正想知道的是：“10:03 前后到底发生了什么变化？”
所以 AI SRE 必须把 telemetry 和 change context 连起来。
这也是国内很多 RCA 产品需要补的一课。
我们过去太习惯把故障定位理解成指标、日志、链路的相关性分析。但生产事故经常是代码、配置、发布、依赖、团队流程共同作用的结果。只看机器数据，RCA 的上限会很明显。
自动调查比聊天框更接近真实工作流
Neubird 的产品入口也很值得研究。
它不是只做一个 Web 聊天框，而是提供 Platform、Desktop CLI 和 MCP Server 三个入口。
Platform 适合团队配置 connections、projects、instructions、runbooks，设置 PagerDuty、Datadog、AWS、CloudWatch 等告警触发自动 investigation。
Desktop CLI 更像 SRE 日常工具。它有 /health、/cost、/handoff、/changes、/timeline、/pir、/slo、/blast-radius、/sentinel 这些命令。
这说明 Neubird 不想只在大事故时被打开。
它想进入日常运维工作：
值班交接。
健康巡检。
变更前后对比。
成本分析。
SLO burn rate。
证书风险。
事故时间线。
复盘生成。
后台持续监控。
这个方向很重要。
如果 AI RCA 只在重大事故时使用，频率太低，用户很难建立信任。一个团队一年也许没几次严重事故，但每天都有 handoff、health check、SLO、cost、change review。
真正有粘性的 AI SRE，应该先在这些高频低风险场景里变得有用。
MCP 会把 AI SRE 带进 IDE 和 coding agent
Neubird 还有 MCP Server，可以接 Claude Code、Cursor、GitHub Copilot、OpenAI Codex、Gemini CLI 等工具。
这件事我觉得会越来越重要。
未来很多工程师不会只在可观测性控制台里排障。他们可能在 IDE 里，让 coding agent 修一个线上问题；可能在 terminal 里查一个服务；可能在 GitHub PR 里问“这个改动有没有线上风险”。
如果 AI agent 只能看代码，看不到生产上下文，它就很容易写出“编译正确但线上危险”的改动。
而如果 Neubird 这样的工具能通过 MCP 把 production investigation、recent changes、historical incidents、RCA reports 暴露给 coding agent，AI coding 和 AI SRE 就会开始合流。
这会带来一个很大的变化：RCA 不再只是事故后的分析，而会进入开发过程。
开发者写代码时，agent 可以问：这个服务最近有没有类似事故？这个配置过去有没有出过问题？这个 API 的 SLO 最近怎么样？这个变更会影响哪些下游？
这才是生产经验真正反哺研发。
Runbook 不能只是文档，要变成调查图
Neubird 的 System Runbook 思路也值得借鉴。
很多公司都有 runbook，但大多是文档。
文档的问题是，它依赖人读、理解、执行、判断。事故现场压力很大，runbook 过期也很常见。
Neubird 的思路是把 runbook 拆成可执行的调查步骤：
这一步要回答什么问题。
需要查哪些数据源。
依赖上一步什么结果。
如果证据不支持当前假设，下一步该转向哪里。
最后哪些 evidence 进入 RCA。
这比“把 runbook 文档塞进知识库做 RAG”更进一步。
它不是让 AI 读文档后自由发挥，而是把团队经验变成可执行的 investigation graph。
国内厂商可以从高频故障做起。
Pod CrashLoopBackOff。
API 延迟升高。
数据库连接池耗尽。
MQ 堆积。
磁盘满。
证书过期。
发布后错误率升高。
Kubernetes 节点异常。
缓存命中率骤降。
这些场景都有比较稳定的排查路径。先把它们结构化，再让 AI 根据实时证据动态调整，比空泛地让模型“分析一下故障原因”可靠得多。
按 investigation 收费是一个有意思的商业信号
Neubird 的定价也挺有意思。
它不按 ingest、不按 storage 收费，而是按 investigation 收费。公开价格里，pay-as-you-go 是每次 investigation 25 美元，Starter 是每月 20 次 investigation。
这个模式很聪明。
可观测性市场里，客户对 ingest 和 storage 成本已经很敏感了。日志量一涨，账单就涨；trace 一开，成本就难控；AI 再来扫描大量数据，客户很容易担心费用爆炸。
按 investigation 收费，把价值锚点从“你有多少数据”转成“我帮你调查了多少问题”。
一次 investigation 如果能节省一两个小时 SRE 时间，25 美元看起来就很容易解释。
当然，这个模式也有挑战。
什么算一次 investigation？
follow-up 算不算？
自动触发太多怎么办？
低价值告警会不会浪费额度？
客户会不会为了省钱减少使用？
所以按 investigation 收费的前提，是产品必须有很强的告警过滤、分组、路由和噪音控制。不然客户会担心每个小告警都变成一次收费调查。
但这个方向值得国内厂商研究。
AI RCA 如果继续按日志扫描量或 token 用量收费，很容易让客户不敢用。按“调查一次问题”收费，更接近用户感知到的业务价值。
Neubird 和 Rootly、incident.io、Resolve AI 的差异
看完这几家公司后，我觉得它们代表了几条不同路线。
incident.io 和 Rootly 是 incident-native。
它们的强项是事故协作、Slack/Teams、On-call、状态更新、会议、复盘、follow-up、组织记忆。它们提醒我们：AI RCA 不能只看机器数据，还要进入事故现场。
Resolve AI 是 production-context-native。
它强调多 agent、生产上下文、代码、云资源、Kubernetes、runbook、历史事故和自动调查。它提醒我们：AI SRE 要像一个会用工具的生产工程师。
Neubird 更像 investigation-native。
它把重点放在如何安全、自动、跨工具地查询数据，如何生成调查计划，如何用 evidence chain 支撑 RCA。
Splunk 则是 observability-native。
它拥有自己的数据底座、SPL、APM、ITSI、Evidence tab、告警页面和 AI Troubleshooting Agent。
这些路线没有绝对优劣。
但它们共同说明一件事：未来 AI RCA 的竞争，不会只发生在“模型会不会总结日志”这个层面。
真正的竞争会发生在更底层的东西上：
谁能拿到完整生产上下文。
谁能把告警组织成事故。
谁能跨工具查询原始证据。
谁能把历史事故变成组织记忆。
谁能让 AI 在 ChatOps、CLI、IDE、工单里自然工作。
谁能在安全、权限、审计、成本上让企业客户放心。
对国内监控和 AIOps 厂商的启发
如果我们要借鉴 Neubird，我觉得重点不是照搬它的产品名或页面，而是借鉴它的系统思路。
第一，AI RCA 要从“聊天总结”升级成“自动调查”。
告警来了，不是等用户问一句“帮我分析一下”，而是自动启动 investigation，先查相关指标、日志、trace、事件、变更、代码、历史事故和 runbook。
第二，RCA 输出要是调查包，不是一段小作文。
里面至少应该有候选根因、证据链、时间线、影响面、近期变更、相似历史事故、已排除假设、下一步验证动作。
第三，数据范围要从 MELT 扩展到 MELT+。
Metrics、Events、Logs、Traces 之外，还要有 Config 和 Code。没有配置和代码上下文，很多 RCA 只能停在症状层。
第四，安全架构要前置。
默认只读、本地执行、原始数据不进外部模型、敏感字段脱敏、工具调用审计、私有化部署、客户自有模型，这些是国内企业客户最关心的问题。
第五，runbook 要结构化。
不要只做文档 RAG。把高频故障的排查经验拆成可执行调查图，让 AI 按证据动态推进。
第六，入口不能只有 Web 控制台。
国内客户需要飞书、企微、钉钉里的 ChatOps，也需要 CLI、API、MCP、IDE、CI/CD、工单系统入口。事故在哪里发生，AI 就应该在哪里工作。
第七，商业模式要控制客户的成本焦虑。
AI 调查不能让日志账单、查询成本、模型 token 失控。按 investigation、按案例、按团队席位，或者在客户内网资源池里运行，都比黑盒消耗更容易被接受。
最后的判断
Neubird 给我的最大启发是：AI SRE 最难的不是回答问题，而是完成一场可信调查。
回答问题很容易。
看几段日志，写一段分析，生成一个看起来合理的根因，这些今天的大模型都能做到。
难的是：
知道该查什么。
知道不该查什么。
知道哪些证据支持当前假设。
知道哪些证据推翻了旧假设。
知道如何跨工具拿到原始数据。
知道如何保护客户敏感信息。
知道如何把调查过程留痕。
知道如何把结果变成下一步动作。
这才是 AI RCA 和普通聊天机器人的分水岭。
Neubird 不一定是这个方向的最终答案，但它把一个重要信号讲清楚了：
AI RCA 不是 prompt engineering，而是生产系统工程。
它需要数据访问层、安全执行环境、调查计划、证据链、历史记忆、runbook、工作流入口和企业信任。
如果说可观测性让我们看见系统，AI SRE 要做的就是帮助我们调查系统、理解系统，并把每一次事故变成下一次更快恢复的经验。
这件事，远比“更会聊天”难，也更值钱。
参考资料：Neubird 官网、官方文档、How It Works、Security & Trust、Desktop、MCP Server、Connections、Projects、System Runbook、Pricing、官方集成页、官方博客和 TechCrunch 报道。
