最近我系统看了一下 Datadog 在 AI SRE、AI RCA 方向上的产品动作，感受很明确。
Datadog 可能是目前最值得国内可观测性厂商研究的 AI SRE 样本之一。
不是因为它讲了一个多么新的概念，而是因为它把 AI SRE 做成了一条比较完整的产品链路：
告警来了，AI 自动调查。 调查过程可追溯。 根因要有证据。 事故协作要能接上。 如果是代码问题，还能继续生成 PR。 如果工程师在 IDE 或 CLI 里工作，也能通过 MCP 拿到 Datadog 的生产上下文。
这套东西合在一起，才是真正值得看的地方。
Datadog 的提醒很直接：AI RCA 不应该只是帮人看数据，而应该开始替人查问题。
Datadog 没有把 AI 做成一个聊天框
很多产品做 AI，第一反应是加一个“Ask AI”。
用户问一句，AI 答一句。 用户贴一段日志，AI 总结一下。 用户打开一个 dashboard，AI 解释一下。
这些能力有用，但离 AI SRE 还很远。
Datadog 的 Bits AI 不是一个单一助手，而是一组 agent：
Bits AI SRE 负责生产问题调查。 Bits AI Dev Agent 负责代码修复。 Bits AI Security Analyst 负责安全信号分诊。 Bits Assistant 负责自然语言入口。 Datadog MCP Server 负责把生产上下文开放给外部 AI agent。
这个拆法很重要。
因为“问答”“排障”“修代码”“查安全事件”“给外部 agent 提供上下文”，其实是完全不同的任务。它们需要不同的数据源、权限、输出格式、风险边界和工作流。
如果都塞进一个聊天框里，最后很容易变成一个看起来什么都能问、但真正事故现场不够可靠的助手。
Datadog 的路线更像是：把 AI 拆进具体生产工作流里。
Watchdog RCA 说明：根因不是症状
Datadog 早就有 Watchdog RCA。
这点很值得注意，因为它说明 Datadog 的 RCA 不是从大模型开始的。
Watchdog RCA 会在 APM 异常出现时，自动分析应用性能异常和相关组件之间的关系。它用的数据包括 APM error rate、latency、hit rate、deployment tracking、traces、基础设施指标、AWS instance status、日志模式异常等。
它最值得借鉴的地方，是把 RCA 结果分成三类：
Root cause。 Critical failure。 Impact。
Root cause 是导致问题的状态变化，比如部署、流量突增、AWS instance failure、磁盘耗尽。
Critical failure 是 root cause 最直接造成的性能退化，比如 latency 或 error rate 上升。
Impact 是被间接影响的服务和用户体验。
这个拆分看起来简单，但非常关键。
很多 AI RCA 产品最大的问题，就是把症状说成根因。
CPU 高。 错误率高。 接口慢。 数据库连接多。 下游超时。
这些经常只是结果，不是原因。
Datadog 在产品语义上先把这件事定义清楚：性能退化本身不是 root cause，它是 critical failure 或 impact。
国内厂商做 AI RCA，也应该先补这一课。
不要让大模型自由发挥，把“错误率升高”写成根因。要先在产品里定义什么是触发变化，什么是初始故障，什么是连锁影响，什么是最终用户影响。
没有这个语义层，AI 再会写，也容易写错。
Bits AI SRE 真正做的是 autonomous investigation
Datadog 当前最核心的 AI SRE 产品是 Bits AI SRE。
它不是等用户打开聊天框问“帮我分析一下”，而是可以从 monitor alert、APM latency graph、Watchdog story、Synthetic test、incident、Slack、general prompt 等入口启动调查。
尤其是 monitor alert，可以配置自动调查。
告警一进入 alert state，Bits AI SRE 就能开始工作。等值班工程师打开电脑时，它可能已经查了一圈，给出初步根因、证据和下一步建议。
这和普通 AI 助手的区别很大。
普通助手是被动问答。 AI SRE 应该是主动调查。
Datadog 文档里对 Bits AI SRE 的调查过程有一个很清晰的描述：它会不断形成假设、查询 telemetry、验证或推翻假设，再基于新证据调整方向。
这就是一个调查循环。
不是“一次性把日志塞给模型”。 不是“根据几张图写总结”。 而是持续地观察、推理、行动。
最后，如果证据足够，它会给出 evidence-backed conclusion。如果证据不足，它可以标记 inconclusive。
这一点我觉得特别重要。
AI RCA 不应该每次都被迫给答案。
真实生产环境里，很多事故一开始就是信息不足的。这个时候，一个诚实的“目前证据不足以支持明确根因”，比一个编出来的根因更有价值。
调查过程要能看见
Datadog Bits AI SRE 有两个视图很值得看。
一个叫 Agent Trace。
调查进行中，它会记录 agent 每一步做了什么，包括如何评估证据、如何做决策。
另一个是 Investigation view。
调查完成后，用树形结构展示调查路径，让用户理解 findings 和 conclusions。
这说明 Datadog 明白一个基本事实：一线工程师不会只因为 AI 语气自信就相信它。
他要看证据。
AI 查了哪些数据？ 跑了哪些查询？ 为什么先怀疑这个服务？ 为什么排除了数据库？ 为什么认为是某次部署？ 哪些证据不足？ 哪些结论只是推测？
AI RCA 的可信度，不来自“回答像专家”，而来自“调查过程能被检查”。
国内很多 AI RCA 产品现在还停在最终答案层。
页面上给一段总结：疑似根因为数据库连接池耗尽，建议扩容或重启。
这不够。
要把调查轨迹、证据链、反证、未验证假设都展示出来。否则工程师还是要重新查一遍。
Datadog 的真正优势，是它掌握生产上下文
Bits AI SRE 能查的数据源很广。
Metrics、APM traces、Logs、Dashboards、Events、Change Tracking、Source code、Watchdog、RUM、Network Path、Database Monitoring、Continuous Profiler。
这已经远远超过传统 MELT。
Metrics、Events、Logs、Traces 只是基础。真正让 RCA 可信的，还包括：
用户影响。 数据库查询。 网络路径。 代码版本。 部署记录。 feature flag。 配置变化。 Kubernetes 事件。 服务依赖。 团队 owner。 历史 incident。 runbook。
Datadog 很清楚这一点。
所以它不只是让 AI 看日志和指标，而是把整个 Datadog 平台变成 agent 的工具箱。
这对国内厂商是一个很直接的提醒：
AI RCA 的上限，不取决于你接了哪个大模型，而取决于你能给模型和 agent 提供多少真实、结构化、可查询的生产上下文。
如果你没有变更数据，AI 很难判断是不是发布引起的。 如果你没有服务拓扑，AI 很难判断上下游影响。 如果你没有 trace 和日志关联，AI 很难从症状走到请求级证据。 如果你没有 CMDB 和 owner，AI 很难知道该找谁处理。 如果你没有历史事故和 runbook，AI 每次都只能从零开始。
所以 AI RCA 首先是上下文工程，然后才是模型工程。
Change Tracking 是 RCA 的硬底座
Datadog 的 Change Tracking 很值得单独研究。
它支持很多变化类型：
代码部署。 feature flag。 配置变更。 数据库 schema 变化。 数据库 setting 变化。 Kubernetes scale。 Kubernetes pod crash。 流量突增。 云资源变化。 Watchdog alerts。
这些变化会出现在 monitor status page、service page、dashboard、notebook 等地方。
这意味着 Datadog 把“最近发生了什么变化”做成了平台级数据，而不是事故时临时去问。
真实故障里，最关键的问题往往不是“哪个指标异常”，而是“异常之前发生了什么改变”。
哪个版本发了？ 哪个配置改了？ 哪个 feature flag 开了？ 哪个数据库 schema 变了？ 哪个 Kubernetes deployment scale 了？ 哪个 pod crash 了？ 哪个云资源被改了？
如果 AI 拿不到这些信息，它只能停留在症状层。
国内很多监控产品过去过于关注指标、日志、链路本身，但对变更上下文重视不够。
AI RCA 时代，这会成为短板。
Runbook 不是文档，而是 agent 的调查路线
Datadog Bits AI SRE 有三类知识来源：
Runbooks。 bits.md。 Feedback and memories。
Runbook 可以写在 monitor message 里，也可以链接到 Confluence。Datadog 还建议在 runbook 里加入 telemetry links，比如 dashboard、logs、traces、notebook。
这点很实用。
过去 runbook 是给人看的文档。 现在 runbook 要变成 agent 可以执行和参考的调查路线。
告诉 agent：
这个告警来了先看哪个 dashboard。 再查哪段日志。 哪个 trace 入口最有用。 哪些现象是噪音。 哪些服务名需要做映射。 哪些环境标签不一致。 哪些历史问题容易误判。
Datadog 的 bits.md 更直接。
它就是一个 Markdown 文件，用来告诉 Bits 这个组织的命名规范、环境映射、服务别名、Kubernetes quick checks、已知噪音和 false positives。
这说明 AI SRE 要懂客户现场，不能只懂通用知识。
每个客户的生产系统都有自己的“土话”。
prod、prd、production、blue-prod 可能指同一个环境。 checkout_prd、CHECKOUT、checkout-service 可能指同一个服务。 某些夜间 CPU spike 是正常批处理。 某些 synthetic test 会故意打出 5xx。 某些 canary 发布会短暂增加错误率。
这些东西通用大模型不知道。
必须让客户能显式告诉 agent。
记忆要来自被验证的反馈
Datadog 的 feedback and memories 也值得看。
调查结束后，用户可以反馈 Bits 的结论是否正确。如果不正确，可以给出真正 root cause、相关服务、指标和 telemetry links。
这些反馈会形成 memory，未来类似调查中被动态使用。
这个方向很对，但也很危险。
事故现场里有很多噪音：猜测、误判、临时 workaround、情绪化表达、被推翻的假设。如果 AI 把这些都写进长期记忆，下次很可能复用错误经验。
所以好的 memory 不是“什么都学”，而是只学习被确认过的东西。
Datadog 强调用户反馈要指出 actual root cause，而不是 observed effects 或 symptoms。这和 Watchdog RCA 的语义是一致的。
国内厂商也要注意这一点。
组织记忆不能乱学。 事故群聊天不能直接全量进知识库。 复盘确认过的根因、有效查询、处理动作、误判路径，才应该进入长期记忆。
Incident AI 把调查放进事故现场
Datadog 还有 Incident AI。
它在 Slack 和 Datadog Incident Management 里工作，可以做 incident summary、related incident detection、历史 incident 查询，也可以从 incident channel 里直接启动 Bits AI SRE investigation。
比如在 Slack 事故群里输入 @Datadog investigate，Bits AI SRE 就可以拉取 incident timeline、linked telemetry、traces、metrics、logs，以及用户提供的上下文，然后在 thread 里更新调查进展。
这就是 AI SRE 应该出现的位置。
事故响应不是只发生在监控页面里。
它发生在 Slack、会议、工单、incident timeline、on-call、case、Jira、ServiceNow 里。
国内对应就是飞书、企微、钉钉、ITSM、工单、值班系统、事故群。
AI RCA 如果只留在监控控制台里，价值会被削弱。
它必须进入真实协作流程：告警群里给摘要，事故页面里给证据，工单里写更新，复盘里生成初稿，升级时带上完整上下文。
Dev Agent 说明 RCA 正在走向代码修复
Datadog 的 Bits AI Dev Agent 是另一个很重要的信号。
当 Bits AI SRE 定位到 code-related root cause 时，可以把问题交给 Dev Agent，生成代码修复建议，甚至创建 GitHub PR。
Dev Agent 还可以处理 Error Tracking、APM Recommendations、Cloud Cost、Code Security、Test Optimization、Continuous Profiler、Kubernetes Remediations 等场景。
这说明 RCA 和 AI coding 正在合流。
过去 RCA 是事故后的分析。 未来 RCA 可能直接进入修复链路。
线上错误定位到某个方法。 AI 找到相关代码。 生成修复。 补单测。 开 PR。 根据 CI 失败继续改。 工程师 review 后 merge。
这条链路很有想象力。
但 Datadog 也保持了边界：Bits Dev never auto-merges PRs。
它可以 auto-push，可以开 PR，可以修 CI failure，但不会自动 merge。涉及 telemetry-based workflow 时，还提醒运行时输入可能不可信，需要配置 review。
这个边界值得国内厂商学习。
AI SRE 最危险的不是不会修，而是太早拥有生产写权限。
正确路径应该是：
先调查。 再给建议。 再生成 diff、命令或 PR。 再让人 review。 再通过 CI、灰度、审批进入生产。
不要从自动修复开始。
MCP 会把 Datadog 带进 IDE 和 CLI
Datadog MCP Server 也很关键。
它让 Cursor、Claude Code、OpenAI Codex、Gemini CLI、VS Code、Devin、Goose 等外部 AI agent 能访问 Datadog 数据。
可用工具包括 logs、traces、metrics、monitors、hosts、incidents、dashboards 等。
这说明 Datadog 不只想让用户在 Datadog UI 里使用 AI。
它还想成为外部 AI agent 的 production context provider。
未来工程师可能在 IDE 里问：
这个 PR 影响的服务最近有没有报错？ 这个 trace 哪个 span 最慢？ 当前有没有相关 incident？ 这个 monitor 配置能不能修一下？ 这个服务过去一小时 latency 有没有异常？
如果 AI coding agent 只能看代码，看不到生产系统，它很容易做出脱离现场的判断。
Datadog MCP Server 的意义，就是把生产上下文带到代码和命令行里。
国内厂商也要重视这个方向。
不一定只做 MCP，也可以做 OpenAPI tool schema、IDE 插件、CLI、飞书/企微/钉钉 bot、CI/CD 插件。
但核心判断一样：可观测性平台不能只等用户打开控制台，它要成为 AI agent 的生产上下文供应商。
Datadog 最隐藏的壁垒，是评估体系
这次调研里，我觉得 Datadog 最值得认真看的不是 Bits AI SRE 产品页，而是它的工程博客：怎么为 autonomous SRE agents 构建真实世界评估平台。
这篇文章讲了一个很现实的问题：
一个功能在某类调查里变好，可能会让另一类调查悄悄变差。
工具级测试不够。 单元测试不够。 线上 replay 也不够。
因为 AI SRE 的价值来自它如何链式调用工具、如何跨信号推理、如何在复杂生产上下文里形成结论。
Datadog 为 Bits 建了一个 replayable evaluation platform。
每个 evaluation label 包含两部分：
ground truth root cause。 world snapshot。
world snapshot 保存事故发生时 agent 能看到的信号和查询上下文，而不是直接给它答案。
然后用这些场景回放不同版本的 agent，评估它是否找到了正确根因、是否调查得足够深、是否找到了有价值 telemetry、轨迹是否合理。
这太重要了。
国内很多 AI RCA 产品现在还停在 demo 阶段：找几个案例，演示 AI 分析得不错。
但真正生产化以后，你需要知道：
新模型是不是让 Kubernetes 场景变好了，但数据库场景变差了？ 新增一个工具，会不会让 agent 拉进太多无关信号？ 某个 prompt 改动，会不会让 agent 更容易把症状当根因？ 某类客户环境是不是一直查不准？ 用户纠正过的错误有没有变成回归测试？
没有评估体系，AI RCA 不可能稳定。
Datadog 的经验说明：AI SRE 的壁垒不只是 agent 本身，而是能持续评估 agent 的基础设施。
对国内厂商的启发
如果我们要借鉴 Datadog，我觉得重点不是照抄 Bits AI 的页面，而是学习它背后的产品判断。
第一，AI RCA 要从“回答型”升级成“调查型”。
告警来了，AI 应该自动形成假设、查证据、排除错误路径、收敛根因，而不是等用户问一句。
第二，先定义 RCA 语义。
Root cause、critical failure、impact、symptom、trigger、contributing factor、mitigation、inconclusive，这些概念要在产品里讲清楚。
第三，必须补 change context。
发布、配置、feature flag、数据库、Kubernetes、云资源变化，是 RCA 的硬证据。
第四，要把 runbook 做成 agent 可执行上下文。
不要只做文档 RAG。要把 dashboard、查询、日志过滤器、trace、常见误报、服务别名、环境映射都结构化给 agent。
第五，AI 调查要进入事故协作。
飞书群、企微群、钉钉群、工单、ITSM、值班、事故复盘，都应该是 AI RCA 的入口和出口。
第六，修复动作必须 human-in-the-loop。
AI 可以生成 PR、命令、配置 diff、回滚建议，但不能一上来就自动改生产。
第七，要做 MCP 或类似能力。
未来 AI coding agent、IDE、CLI、CI/CD 都需要生产上下文。可观测性平台应该主动成为 context provider。
第八，评估体系要从第一天开始建。
要有 incident 数据集、ground truth、world snapshot、agent trajectory、evidence score、regression test、user feedback loop。
否则 AI RCA 会一直停在“演示很惊艳，上线不稳定”。
最后的判断
Datadog 给 AI SRE 定了一个很主流、也很现实的模板。
它不是让大模型坐在 dashboard 旁边帮你解释图。
它是把一体化可观测性平台升级成一组会调查、会协作、会生成修复、会被外部 agent 调用的生产系统智能层。
这件事对国内监控和可观测性厂商有很大启发。
过去我们做的是“看见系统”。
指标、日志、链路、告警、dashboard、拓扑，这些帮助客户知道系统发生了什么。
但 AI SRE 时代，客户会继续往前问：
为什么坏了？ 谁应该处理？ 证据是什么？ 有没有类似历史事故？ 最近发生了什么变化？ 现在应该先做什么？ 能不能生成修复建议？ 能不能把这次经验沉淀下来？
谁能回答这些问题，谁就不再只是一个监控平台，而会变成生产系统的默认工作台。
Datadog 的路线不一定能在国内原样复制。国内客户有私有化、本地模型、数据不出域、国产 IM、CMDB、ITSM、等保合规这些现实约束。
但方向是清楚的。
AI RCA 不是 prompt engineering。
它是生产系统工程。
它需要数据、变更、拓扑、runbook、事故流程、权限、审计、评估和行动闭环。
大模型只是其中一部分。
真正值钱的，是让 AI 在正确的生产上下文里，完成一场可追溯、可验证、可协作的调查。
参考资料：Datadog 官方文档、Bits AI / Bits AI SRE / Watchdog RCA / Incident AI / Bits AI Dev Agent / MCP Server / Change Tracking / APM Investigator 相关文档，Datadog 官方博客与工程博客。
