Resolve AI：为什么 AI SRE 领域有望诞生下一代 Datadog
Whole Picture
一篇海外独角兽对 AI SRE 赛道和 Resolve AI 的深度拆解。核心判断：运维（SRE）是继 coding 之后下一个被 AI 颠覆的环节，但渗透节奏会慢得多——因为 SRE 直接面对生产环境，写操作风险极高。Resolve AI 出 stealth 仅 16 个月、$150M 融资、$1B 估值，用”环境记忆 × Multi-Agent”的工程务实路线切入，对手 Traversal 则走学术因果推理路线。作者判断 AI SRE 可能是下一代可观测性基建，Datadog 的 observe+store 模式会被 observe+analyze+act 取代。
关键事实
- 融资：种子轮 2024.10 Greylock 领投 $35M；A 轮 2025.12 Lightspeed 领投 $125M，估值 $1B。Greylock 跟投。天使：Jeff Dean、Fei-Fei Li、AWS CEO、Snowflake CEO、前 GitHub CEO
- 商业：ARR ~$400 万，20+ 企业客户，120 人。客户：Coinbase / Zscaler / Salesforce / MongoDB / MSCI / Toast / DataStax / DoorDash（multi-vendor 测试）
- 创始人：Spiros Xanthos（CEO）+ Mayank Agarwal（CTO），UIUC 博士同窗，第三次联合创业，代表作 OpenTelemetry（CNCF 活跃度第二）
- 落地效果：Coinbase 告警根因调查时间 -72%；Zscaler 每次事故所需工程师数 -30%
产品架构（精读重点）
三层结构：中央记忆（Resolve.md 动态知识文档） + 四个并行专职 Agent + 广泛工具集成
| Sub-Agent | 负责什么 | 回答的问题 | 集成工具 |
|---|---|---|---|
| Knowledge Agent | 结构化知识 | “我们之前遇到过类似问题吗？” | PagerDuty / Azure DevOps / Slack / Notion |
| Telemetry Agent | 可观测性数据 | “现在的指标异常在哪？” | Grafana / Datadog / APM |
| Code Agent | 代码仓库 | “哪个 commit 引入了问题？” | GitHub / GitLab |
| Infra Agent | 基础设施 | “基础设施有没有异常？” | AWS / Azure / GCP / DNS |
工程要点：
- 把系统”读”进来而不是靠记忆：代码库、deployment YAML、历史日志、Runbook 索引成动态知识图谱
- 多个专职 Agent 并行：不是串行排队，规划器决定调查策略 → 专门化 Sub-Agent 并行 → 汇总推理。编排层是核心工程壁垒
- 像侦探一样对假设打分排名：同时维护多个假设，用新证据持续更新置信度
- 数据飞轮：每次事故根因写回 Resolve.md，用得越久越准——护城河
- 读自主 / 写人审批：查日志查代码全自主；生成 PR、回滚、重启必须人工确认
Satellite 模式（部署层）：客户数据中心内部部署本地节点，数据不离开客户环境，仅脱敏元数据回传。Coinbase 连日志都不对外开放、靠 traces+metrics 就能 debug，是这个设计赢来的单。
Resolve vs Traversal
| 维度 | Resolve | Traversal |
|---|---|---|
| 创始团队 | 工程团队，连续创业老兵 | 学术团队，因果 ML 研究员 |
| 部署架构 | Satellite（数据不出环境） | 集中式云端，Agent 侵入业务服务器 |
| 技术路线 | 传统 ML 相关性匹配，“症状识别” | 针对 SRE 训练的推理模型，跨系统因果溯源 |
| 客户锚点 | Coinbase 等金融客户（要数据主权） | - |
作者判断：Resolve 更保守务实、符合企业安全要求；Traversal 根因推断”被认为”走得更深（无一手证据）。
作者核心观点
- AI SRE 可能是下一代可观测性基建。Datadog observe+store → AI SRE observe+analyze+act。Datadog 自己的 Bits AI 受限于存储计费模式和 context 缺失，时间窗口给了创业公司
- SRE 独立于 coding agent 的理由：Always-on proactive agent 需要编排引擎 + 状态管理 + 权限控制，当前 coding 工具还没到这一层；运维 know-how（事件记忆、runbook、故障模式库）需要专门数据架构沉淀
- 难点不在”读日志”而在”破案”：长 chain-of-thought + long horizon 规划 + 并行 sub-agent 协同
- Context 是核心工程问题：runbook 分散过时、tribal knowledge 在老员工脑里、监控数据 noisy。这比模型智能更重要
- AI SRE 是会变强的资产：每次 debug 成功失败都是 reward signal，系统级认知资产难以迁移
- 天花板取决于软件价值分布：如果 AI 生成的短生命周期软件占主导，运维价值会被稀释
亮点 / 槽点
亮点：
- 场景拆解（Kafka 健康检查、限流设计、成本优化、事故响应、自动 PR）颗粒度合适，能看到 AI agent 在企业生产环境的真实姿态
- “读操作自主 / 写操作人审批”这个边界描述很清楚，是现阶段 enterprise 真正愿意采购的形态
- Resolve vs Traversal 的对比揭示了”工程务实 vs 学术深度”的路线分歧，延伸到所有 AI agent 商业化都成立
槽点：
- Traversal 技术评价”被认为走得更深”没有一手证据
- 融资和客户段落带宣传腔（豪华天使名单、数据飞轮都是模板叙事）
- 没讨论失败案例 / 客户流失 / 替换难度的实际数据
关键引用
“许多人认为 AI SRE 的技术瓶颈在于’读懂日志’。事实上…真正的难点在于’如何破案’：一个真正成熟的 SRE 工程师需要从一个 alert 出发，在海量 noisy 数据中追溯完整的因果链条，像侦探小说一样一步步逼近真相。”
“即便推理能力过关，模型智能也只占整个 SRE 瓶颈的一部分。更大的挑战来自 context 的组织与提取。”