← All Articles

Resolve AI:为什么 AI SRE 领域有望诞生下一代 Datadog

海外独角兽 / Daniel · Original

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 取代。

关键事实

产品架构(精读重点)

三层结构:中央记忆(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

工程要点

  1. 把系统”读”进来而不是靠记忆:代码库、deployment YAML、历史日志、Runbook 索引成动态知识图谱
  2. 多个专职 Agent 并行:不是串行排队,规划器决定调查策略 → 专门化 Sub-Agent 并行 → 汇总推理。编排层是核心工程壁垒
  3. 像侦探一样对假设打分排名:同时维护多个假设,用新证据持续更新置信度
  4. 数据飞轮:每次事故根因写回 Resolve.md,用得越久越准——护城河
  5. 读自主 / 写人审批:查日志查代码全自主;生成 PR、回滚、重启必须人工确认

Satellite 模式(部署层):客户数据中心内部部署本地节点,数据不离开客户环境,仅脱敏元数据回传。Coinbase 连日志都不对外开放、靠 traces+metrics 就能 debug,是这个设计赢来的单。

Resolve vs Traversal

维度 Resolve Traversal
创始团队 工程团队,连续创业老兵 学术团队,因果 ML 研究员
部署架构 Satellite(数据不出环境) 集中式云端,Agent 侵入业务服务器
技术路线 传统 ML 相关性匹配,“症状识别” 针对 SRE 训练的推理模型,跨系统因果溯源
客户锚点 Coinbase 等金融客户(要数据主权) -

作者判断:Resolve 更保守务实、符合企业安全要求;Traversal 根因推断”被认为”走得更深(无一手证据)。

作者核心观点

  1. AI SRE 可能是下一代可观测性基建。Datadog observe+store → AI SRE observe+analyze+act。Datadog 自己的 Bits AI 受限于存储计费模式和 context 缺失,时间窗口给了创业公司
  2. SRE 独立于 coding agent 的理由:Always-on proactive agent 需要编排引擎 + 状态管理 + 权限控制,当前 coding 工具还没到这一层;运维 know-how(事件记忆、runbook、故障模式库)需要专门数据架构沉淀
  3. 难点不在”读日志”而在”破案”:长 chain-of-thought + long horizon 规划 + 并行 sub-agent 协同
  4. Context 是核心工程问题:runbook 分散过时、tribal knowledge 在老员工脑里、监控数据 noisy。这比模型智能更重要
  5. AI SRE 是会变强的资产:每次 debug 成功失败都是 reward signal,系统级认知资产难以迁移
  6. 天花板取决于软件价值分布:如果 AI 生成的短生命周期软件占主导,运维价值会被稀释

亮点 / 槽点

亮点

槽点

关键引用

“许多人认为 AI SRE 的技术瓶颈在于’读懂日志’。事实上…真正的难点在于’如何破案’:一个真正成熟的 SRE 工程师需要从一个 alert 出发,在海量 noisy 数据中追溯完整的因果链条,像侦探小说一样一步步逼近真相。”

“即便推理能力过关,模型智能也只占整个 SRE 瓶颈的一部分。更大的挑战来自 context 的组织与提取。”

Discussion 补充(2026-04-21)

讨论沿着两条线推进:

一、架构同构 vs 护城河同构(Q1)

提问:Resolve 的”编排层壁垒 + 数据飞轮护城河”放到个人 agent harness(cc-remote / teammate mode)上是否成立?

Justin 回应:个人 vs 企业根本不同,并反问”Resolve 自身有啥数据壁垒?“——把话题引向更锋利的角度。

结论:架构形状是同构的,护城河叙事是虚的。“中央记忆 × 并行专职 agent × 读自主 / 写审批”这套 shape 在个人 harness 工程上可直接借鉴;但护城河层在两种场景下都值得怀疑——企业侧真实存在 tribal knowledge 采购痛点但护城河结构被夸大,个人侧根本没有供应商这个角色可以做飞轮。

二、Resolve 真实壁垒的分档拆解(Q2-Q3)

Justin 的判断框架:壁垒强度排序 数据壁垒(网络效应) > 规模效应 > 先发优势。拆法是把公司现有优势归类到这三档,不混淆、不被叙事带偏。数据壁垒最硬,先发优势也是优势但重要性有量级差。

套回 Resolve:

档位 是否有 证据
数据壁垒 Satellite 模式结构性切断 Resolve 侧跨客户数据聚合;Resolve.md 积累在客户侧,产生的是 switching cost 不是数据网络效应。跨客户泛化与 Satellite 的安全承诺互斥
规模效应 非双边市场,无”用户越多产品越好”的传导
先发优势 OTel 创始人分销 + Greylock+Lightspeed 资源 + Coinbase/Zscaler reference customer + enterprise 采购周期的 18-24 个月窗口

结论:Resolve 基本全靠先发优势撑着。作者”下一代 Datadog”的叙事在壁垒结构上不成立——Datadog 的壁垒恰恰是数据(observe+store 模式让客户日志沉淀在 Datadog 侧),Resolve 的 Satellite 架构主动放弃了这条路。产品形态可以接近 Datadog,但壁垒结构是两回事

三、“赛道 narrative 被错安到单公司头上”的偏差机制

Justin:这个现象普遍 = 自媒体造势需求 + 新兴行业头部公司先发优势被放大。自己的拆法是深度研究真实壁垒,评估优势归哪档——坚持数据壁垒的价值,先发优势也不容忽视但重要性不同

延伸判断钩子:看到”X 可能是下一代 Y”时问——(1) X 当前优势归哪档?(2) Y 巨头的真壁垒在哪档?(3) X 是否主动 / 被动放弃了 Y 那档壁垒路径?错位就是叙事泡沫。

Writeback

discussion_added: “2026-04-21”