当人读不懂 AI 代码，Traversal 如何做企业运维的 AI 医生？

代码运维一直是开发者的痛点，AI Coding 的飞速进步放大了运维难度：Claude Code 贡献的代码 push 已经占到了公开 Github 的 4%，但 AI 写的系统逻辑会有人类很难捕捉的问题，开发者将其称为“Claude Hole”现象。传统以 Datadog 为代表的可观测性工具虽能展示指标，却难以解释根本原因并指导修复，工程师仍需依赖经验进行高成本排障，形成明确且持续扩大的行业痛点。

Traversal 这家初创公司由 MIT 和 Berkeley 的教授及量化交易员组成，这种稀缺的背景使他们未陷入传统的日志分析路径，而是从第一性原理出发解决 SRE 问题。公司以因果推断为基础构建自主决策型 SRE Agent，通过仿真与代码级扫描，将问题定位直接映射到具体变更并自动化处理。这一能力已在头部客户的真实生产环境中已验证出显著效果。

如果说上一代软件是 Copilot 型思路，Traversal 代表了新一代 Agentic SRE 的思路，我们看好 AI Coding 会有新的运维基础设施玩家出现。尽管面临传统可观测性巨头与其他 AI SRE 的竞争，如果新公司的归因准确率与自动化修复能力持续兑现，那么很有机会在持续扩张的运维软件和人力预算中，占据比上一代软件更高的价值。

01.

为什么看好 Traversal？

•行业痛点明确

尽管 Datadog 等工具垄断了数据可视化，但它们仅能展示指标波动而无法解释背后的因果，导致工程师面对仪表盘仍需人工猜测。尤其随着 AI coding 的发展导致代码复杂度呈指数级增长，人类往往难以理解 AI 写的系统逻辑（即“Claude Hole”现象），企业急需 Traversal 这样能从“看到现象”直接跨越到“执行修复”的智能大脑。

•技术壁垒较高，商业落地效果显著

Traversal 构建了基于因果推断的 Agent 架构，区别于竞品的“相关性猜测”，它能通过仿真沙盒与 GitHub 深度扫描，精准将故障锁定至具体代码变更。这种自主决策能力已在 American Express 和 Digital Ocean 等财富 100 强客户中得到验证：在数百起高危事故中，Traversal 实现了超过 90% 的归因准确率。

•团队背景好，获得顶级资本加持

创始团队由 MIT 和 Berkeley 的教授及量化交易员组成，这种稀缺的背景使他们未陷入传统的日志分析路径，而是从第一性原理出发解决 SRE 问题。这一顶级团队配置与赛道潜力也已获得资本市场的高度认可，公司于 2025 年 6 月完成了由 Sequoia 和 Kleiner Perkins 领投的 4800 万美元融资。

潜在风险

•Traversal 的因果机器学习是否有效？

在极度复杂的分布式系统中，要证明因果性是很难的。所谓的因果 ML 在业界往往被视为营销术语，Traversal 所谓的“因果”可能在很多时候依然是“高级的相关性”。如果客户发现 Traversal 在复杂场景下的归因准确率不如预期，可能会导致严重的信任危机。

•Traversal 的生存空间受到多方竞争

在竞争上，一方面，Traversal 必须面对 Datadog 等巨头的“够用主义”挑战，后者凭借低廉的成本和庞大的装机量，往往成为企业首选。另一方面，Flip 等竞品凭借更友好的自然语言交互界面（Copilot UI）把持着初级分诊市场，Traversal 需要补齐自身在交互等领域的短板。

•隐私权限与合规门槛

深度集成带来的合规门槛是 Traversal 扩张的最大阻力。Traversal 必须读取核心源代码（GitHub）和内部文档（Wiki/Jira）才能发挥优势，这导致 Traversal 被 Nike 等要求物理隔离或数据主权敏感的客户拒绝。此外，一旦部署 Traversal，替换它预计需要经历 6 到 8 个月的痛苦重构期，这种极高的切换成本使得大型企业在签约决策时也会面临巨大的心理压力。

02.

代码运维是长期存在的明确痛点

软件运维的 TAM 可以从工具支出与人力效能价值两个维度进行测算。如果仅基于企业当前的软件预算，TAM 约为 1100 亿美元；如果基于工具对人力的替代与增效逻辑，仅美国市场，TAM 就能达到 965 亿美元。

•工具层面：增长的核心驱动力在于企业以商业化软件取代自建系统的刚性需求

根据 Canalyst 的测算，全球广义运维市场的 TAM 估计超过 1100 亿美元。这一规模涵盖了从开发规划到测试的全生命周期工具，其中包含受云原生架构推动、预计在 2026 年达到 620 亿美元的可观测性市场，以及预计在 2030 年扩张至 416.6 亿美元的 DevSecOps 赛道。此外，The Business Research Company 在 2025 年报告中指出，专门针对 DevOps 的生成式 AI 市场预计到 2029 年将达到 93.6 亿美元，年复合增长率高达 38%。

•人力层面：TAM 的逻辑聚焦于通过自动化工具释放的人力资源潜在价值

在美国劳工统计局（BLS）的相关职业中，包括软件开发人员（约 207 万）、计算机系统分析师（约 52 万）以及网络与计算机系统管理员（约 33 万），三类职业合计约 290 万人。

需要注意的是，上述三类职业中，仅有一部分岗位从事 DevOps / SRE 相关工作，因此该数字代表“潜在相关职业规模”，而非 DevOps 人员的实际数量。

以美国地区 13.31 万美元的平均年薪作为计算基准，并结合 CircleCI 关于研发人员约 25% 的时间被浪费在非战略性手动任务上的研究数据，可以推导出工具化理论上在美国能够解锁的市场空间：

美国人力总成本≈ 290 万人× 13.31 万美元/年≈ 3,860 亿美元

人力效能 TAM ≈ 3,860 亿美元× 25 %(效率缺口)≈ 965亿美元

CircleCI 进一步对比了成本效率：人工开发的时间成本约为 1.42 美元/分钟，而自动化工具仅为 0.006 美元/分钟。这种巨大的 ROI 缺口，加之每年以 7% 速度增长的技术实施咨询市场，共同构成了人力层面的宏大 TAM。

行业痛点

具体到每个企业，Traversal 表示停机每年会给企业造成约 4000 亿美元损失，重大事故期间每小时损失可达 190 万美元。但代码运维难度其实非常大：

1. 事故数据分散在不同工具中（如 OpenTelemetry、Prometheus、Grafana、Datadog 等），需要频繁切换以提取、处理、可视化和存储数据；

2. 数据量巨大，特别是大型公司。以 DigitalOcean 为例，仅 15 分钟就会在某些索引产生数百万条日志，各区域时间序列可能上亿，总量达到数十亿条。

一个典型事故处理流程如下：

1. 客户发现功能异常，客服确认不是操作问题后上报系统故障。

2. DevOps/SRE 评估影响和严重性，决定是否作为事件处理，并创建 Slack Channel，之后可能会陆续有几十个人加入，团队在 PB 级数据中调查原因。

3. 找到问题后，快速制定临时修复方案恢复服务。

AI Coding 进一步加大了运维难度

当下 AI Coding 正在飞速发展，根据 SemiAnalysis 的一份最新报告，Claude Code 贡献的代码目前约占公开 GitHub 提交（commits）的 4%。报告预测，如果按当前增长速度发展，到 2026 年年底，Claude Code 每日提交量可能将占所有提交的 20% 或更多。

未来代码运维可能有两种趋势。短期来看，一个可能的走向是，在 Cursor、Claude code 等推动下，用户可通过 prompt 快速生成和试用软件，如同快时尚，软件无需维护，代码可靠性也不重要。

但从长期角度来看，另一个更可能的走向是，AI 生成的软件将应用于关键系统（金融支付、身份验证、安全 infra 等），此时即使通过单元测试，也可能因系统复杂交互导致难以预见的问题。一旦出错，排查非常困难：人类开发者缺乏原始 context，系统复杂性可能超出单人理解能力，这被称为 The Claude Hole。

而且当系统崩溃时，工程师往往也是首次阅读这些代码，需依赖 AI 助手解析日志，但通用 LLM 往往缺乏整体上下文，容易出现幻觉，让排查方向错误，甚至扩大故障范围。

为什么需要 AI native SRE？

AI native SRE 与传统 SRE 的区别在于从“扩展数据”向“扩展理解能力”的根本性转变。

传统 SRE 往往陷入“工具越多，负担越重”的困境：尽管仪表盘和报警系统不断增加，但工程师仍需耗费大量精力手动拼凑线索，这也解释了为何根据 IDC 的分析，开发者如今仅有约 16% 的时间用于编写代码，而全球 2000 强企业每年仍面临约 4000 亿美元的宕机成本。

如果说上一代软件是 Copilot 型思路，主要辅助人类处理海量数据，那么以 Traversal 为代表的新一代 Agentic SRE 则代表了机器自主推理的思路，它们利用 agent 自动关联代码、基础设施和遥测数据，像人类专家一样生成事故叙述并尝试修复。

我们认为，随着 AI Coding 的普及，势必会出现新的运维 infra 玩家，尽管面临传统可观测性巨头与其他 AI SRE 的竞争，但如果新一代公司的归因准确率与自动化修复能力能持续兑现，它们将有机会在这一波浪潮中，从持续扩张的运维软件和人力预算里，占据比上一代软件远为更高的价值。

03.

Traversal 是什么？

Traversal 定位于一个能够处理高风险事件的 AI SRE agent，设计初衷是为了能够以一个单一的管理平台，遍历不同来源、PB 级的 MELT 数据，串联起原本需要跨团队、跨工具地反复沟通数小时才能厘清的信息。在 Traversal 帮助下，过去需要 50+ 人参与的应急响应，现在只需 10-15 个有 context 的工程师就可以了。

在可观测性领域，MELT 数据通常指 Metrics、Events、Logs、Traces 四类运行时数据的统称，用来监控、排查和分析系统行为与性能。

但 Traversal 的作用并不局限在系统出现问题、发出警报后，而是在客户登录后，Traversal 就会开始主动监控客户的系统，甚至在问题成为“问题”之前就察觉出来。

Traversal 部署灵活，可本地运行且不对生产环境进行任何操作。为避免企业引入新工具生成数据，Traversal 仅以只读方式通过 API 获取现有的 Datadog、CloudWatch 或 Splunk 数据，Traversal 还会直接摄取原始的 OpenTelemetry 数据，利用这些数据构建基础设施的“数字孪生”和因果关系图，从而能够在不显著增加存储成本的前提下进行故障模拟和预测。

2025 年 6 月，Traversal 完成了由美国红杉和凯鹏华盈领投的 A 轮和种子轮，NFDG 和 Hanabi 跟投，融资总额达 4800 万美元。

Workflow

Traversal 的工作流分为离线和在线两个阶段。

•离线阶段：Traversal 一般需要花费 5-10 个小时去浏览客户的代码库，查看已有的 Observability 系统，从而构建一个动态的、语义丰富的系统依赖图谱 （System Dependency Map）。

1. 利用 LLM 来理解非结构化日志之间的语义关联；

2. 应用统计方法，识别时间序列中的自然波动，从中提取因果关系；

3. 结合自我训练机制，优先识别对 RCA 最有价值的路径。

•在线阶段：当事故发生时，agent 会结合实时数据与关系图，判断并执行相应操作，从而完成 RCA。

1. 事件触发：在 Slack 中，用户创建 incident channel 后，Traversal 会自动加入并在事故发生时主动发起调查；用户也可以通过 @Traversal 直接提问，或发送事故时间和简要描述，甚至可以要求 Traversal 检查系统整体运行状况。

2. 因果分析：Traversal 调度上千个专家型 agent 并行筛查数据、探索假设，取代工程师传统的盲目看 dashboard 的做法。同时，它结合因果机器学习快速定位根因，并通过 RAG、向量搜索和 coding agent 追溯代码变更，甚至给出自动修复建议。

但需要注意的是，Traversal 并不一次性分析所有数据，它采用类似人类排障的方式进行“有目的的跳跃”：例如先检查负载均衡器是否异常，如果一切正常，再逐层深入到应用层或下游服务。各类 agent 可调用现有工具收集和验证证据，如查询 Prometheus 指标、检索 Splunk 日志、检查 GitHub PR，以持续验证或推翻假设。

3. 快速反馈：在 Slack 中，Traversal 可在几分钟内完成原因分析，直接在 channel 中反馈调查结果，并展示 Observability 数据、根因置信度和推理过程，帮助工程师快速确认、回滚。更详细的分析也可在 Traversal UI 查看。

潜在扩展场景

我们研究认为，Traversal 的应用场景远不止于 SRE 故障修复，凭借“实时全栈依赖图谱”与“预测性模拟”两大能力，可以扩展至以下三个高价值场景：

1. 基础设施成本优化（FinOps）：传统的云成本管理往往是在账单出来之后才发现问题，Traversal 利用预测模型，在流量低谷期主动回收非关键资源，并通过“数字孪生”先行模拟不同降本方案对性能的影响。只有当模拟结果确认不会带来任何风险时，系统才会自动执行变更，从而实现真正动态、且安全可控的云成本优化。

2. DevOps 流水线预测：Traversal 能在新代码上线前，利用依赖图谱模拟其对下游服务的影响，提前预测构建失败或 API 兼容性问题，这种机制能生成自动修复剧本并显著减少因代码缺陷导致的回滚，解决开发者在调试 CI/CD 失败上耗时过长的问题。

3. 安全响应（SecOps）：面对安全警报，Traversal 可以将安全警报与系统依赖图谱结合。核心优势在于“微创手术”般的响应能力：系统可以在数字孪生中模拟防御措施的影响范围，例如精准隔离受损的容器以切断攻击，而不是粗暴地关闭整个服务，从而在遏制威胁的同时最大程度保障业务连续性。

04.

技术壁垒

Traversal 的技术护城河建立在因果推理与仿真模拟的深度结合之上，而非单纯依赖目前主流的生成式 AI 或传统的日志相关性分析。

因果推理

为了做好因果推断，Traversal 认为必须要结合三个技术：因果机器学习（Causal Machine Learning）、推理模型（Reasoning Models）、agent 并行（Swarm of Agents）。

1. 因果机器学习

不同于 Datadog 或 Splunk 等传统工具主要依赖统计学上的相关性，Traversal 构建了基于因果图的底层架构。

在架构上，Traversal 不仅摄取日志和指标，还通过与云基础设施（如 Kubernetes、Terraform、负载均衡器）的深度集成，实时绘制服务间的依赖关系图谱，这使自身能够通过逻辑链条精准追踪故障的传播路径，而非仅仅聚合同时发生的警报。

当异常发生时（例如服务延迟飙升），Traversal 利用因果图将症状回溯至确切的根因。例如，它能识别出是一次错误的功能发布导致了流量激增，而不是简单地报告 CPU 使用率过高。这种基于服务依赖图识别故障链的能力，是 Traversal 与仅做异常检测的竞品最大的区别。

Traversal 团队还利用了自身在 MIT 和 Berkeley 的研究成果，特别是基于合成控制（Synthetic Controls）和潜变量模型（Latent Variable Models）的算法，来计算和识别真正的因果关系。

2. 推理模型

Traversal 特别强调在推理阶段投入计算资源。它不仅仅依赖信息检索，而是通过多步推理（Chain-of-Thought）和反思机制（Reflection），不断校正判断，从而提高结论的准确性和可信度。由于企业级系统中总会存在不可预见的缺失环节，监控数据也不可能做到完全完备，因此引入推理模型是必需的。Traversal 能成功的原因之一就源于公司之前对推理模型的前瞻性押注，在模型的推理能力广泛应用之前，就构建了能够充分利用这些能力的系统架构。

Traversal 认为，目前企业往往已经和 OpenAI 或者 Anthropic 等大模型厂商已有合作关系，因此不应该要求企业使用 Traversal 的模型，而是 Traversal 需要设计出可以“即插即用”的架构，使用企业提供的模型，并在企业环境中对模型进行微调。

3. Agent 并行

在真实生产环境中，追踪数据规模巨大，无法一次性放入模型的 context。Traversal 通过逐步、智能构建 context 来解决：LLM 负责语义理解，统计方法处理时间序列，二者协同逐步逼近根因，这正是 agentic 架构的核心价值，也就是只保留关键信息，更快定位问题。

在事故发生时，客户通常希望两分钟内得到结果。团队将 PB 级数据分析视为一个有序的动态搜索问题，通过并行 agent 架构跨 Elastic、Grafana、Datadog、ServiceNow 等系统查询和整合 PB 级数据，结合自研统计检验逐步缩小搜索范围，最终锁定关键信号。这种“agent 版 MapReduce”让 agent 能在庞大异构数据上高效分析，同时遵守安全规范。

数字孪生与仿真模拟

Traversal 引入数字孪生（Digital Twin）技术，与云基础设施、CI/CD 流水线及可观测性工具深度集成，实时构建并维护一个与生产环境同步的虚拟副本。该数字孪生不仅包含服务拓扑，还涵盖实时流量、依赖关系和故障传播路径，为 AI 提供安全的仿真环境。

利用这一数字孪生环境，Traversal 能够在采取任何实际行动之前，进行多路径的仿真模拟，这被称为“主动试错”机制。当系统检测到异常（例如数据库延迟飙升）时，Traversal 不会盲目执行某一个预设脚本，而是会在数字孪生中并行模拟多种潜在的修复策略。

•以数据库性能问题为例，Traversal 会同时模拟“增加只读副本”、“优化查询语句”以及“调整连接池限制”这三种不同的解决方案。在模拟运行的过程中，系统利用强化学习模型对每一种方案的执行结果进行实时评分，评估其对性能的具体影响以及是否解决了核心问题。只有在虚拟环境中被验证为得分最高、置信度最优的方案，才会被选中准备应用到生产环境。

•这一机制也在 Wayfair 的实践中得到验证：在黑色星期五期间，Traversal 通过仿真确认 Redis 扩容才是应对缓存过载的有效方案，成功避免了无效修复带来的风险。

此外，为了解决企业对 AI 自动执行高风险操作的信任顾虑，Traversal 构建了严格的安全执行机制，使 AI 能够从“建议者”真正进化为敢于操作的“执行者”。对于被判定为高风险的修复操作，Traversal 绝不会直接全量推送到生产环境，而是采用影子测试（Shadow Testing）或金丝雀发布（Canary Execution）。

•在影子测试模式下，Traversal 会在后台运行新的修复配置，使其与现有的生产配置并行工作但不处理实际流量，以此来对比验证新方案的稳定性和效果。

•在金丝雀发布模式下，系统仅将修复方案应用于极小比例（例如 1%）的真实用户流量。系统会实时监控这 1%流量的性能指标，只有确认修复有效且无负面副作用后，才会逐步扩大应用范围直至全量推广。

05.

商业模式

根据我们研究，Traversal 采用的是混合式、以结果为核心的定价模式，核心思路是先覆盖系统规模成本，再根据实际创造的运维价值收费，而不是简单按使用量计费。这种模式有效地解决了 Datadog 或 Splunk 等传统工具“数据量越大，成本越高，但价值未必线性增长”的痛点，同时也区别于 Resolve 等竞品主要基于节点或许可证的传统模式。

首先是固定基础费用。这部分是固定成本，主要与系统规模相关，包括被监控的服务或集成数量、接入的遥测数据量，以及并行运行的模拟数量等，用于覆盖平台的持续监控、分析和运行能力。

第二部分是按结果计费的可变费用，也是 Traversal 最具差异化的地方。该费用只在产生明确、可验证成果时才计入，例如成功自动修复的事故数量；通过提前预测并触发回滚或扩容而避免的事故；每次事故分诊和排障中节省的工程师时间。

举例来说，如果系统在部署后 4 分钟内预测到一次服务回归，并自动回滚，从而避免了一次 L1 级事故和 3 小时以上的人工排查，这次事件就会被计为一次“高价值规避事件”，并纳入结果计费。

在此基础上，Traversal 还使用 ROI 分档机制来控制费用。客户会与 Traversal 事先约定基线指标，如单次事故的平均成本和平均 MTTR。系统基于这些数据持续计算 ROI，并将客户划分到不同区间，比如 2–5 倍、5–10 倍、10 倍以上，只有当实际 ROI 跨过对应阈值时，才会触发更高档位的可变费用，而且这部分费用始终低于系统所释放的价值，确保整体投入产出比为正。

此外，Traversal 还提供可选增值模块，例如事故复盘自动生成、业务影响可视化，以及针对边缘场景的定制化模拟。这些模块可按需单独购买，也可打包进企业级套餐。

客户案例

Traversal 客户包括 Digital Ocean、Eventbrite、Cloudways、American Express 以及财富 100 强中的一些大型金融机构，Traversal 在数百起高影响力的事故中实现了 90% 以上的准确率。

有客户特别强调了选择 Traversal 的关键驱动力在于团队“极度渴望实验”的文化以及快速响应能力：其他厂商只发反馈表（Feedback form），而 Traversal 团队会到现场开 1.5 天的 workshop，而且客户提出的反馈，Traversal 能在下一个 Sprint（两周内） 就修改上线。

尽管 Traversal 在处理已知故障模式上表现卓越，但在面对“未知”（如第三方 API 突发的新型错误）时，系统仍面临学习周期较长的挑战。Traversal 目前正在希望通过摄取更底层的原始遥测数据来优化模型，来加速对新故障模式的自适应能力。

•客户反馈

•合同规模

•客户落地进度：值得注意的是，Nike 曾评估过 Traversal，但由于数据隐私和合规性要求（需要访问 Wiki、Jira 等敏感内部文档），最终拒绝了试点，转而选择了可以在气隙（Air-gapped）环境中运行的 Resolve。

06.

团队

创始团队由高校教授和证券交易员组成，AI 与工程能力强，专注因果机器学习、强化学习和 agentic 能力，但在 observability 经验上相对不足。团队 90% 为工程师，多数有博士背景。CEO Anish 表示，团队几乎对 SRE 一无所知，却从“第一性原理”出发进入赛道。团队认为 SRE 的核心不是 observability：观测只能让人看到系统发生了什么，真正难且有价值的是搞清问题根因并指导下一步行动，这正是 AI 擅长的。

创始人

•Anish Agarwal - CEO & Cofounder

Anish 博士毕业于 MIT 计算机科学，是哥伦比亚大学运筹学与计算机科学教授。他曾做过 BCG 咨询顾问、微软研究院 Machine Learning Researcher、亚马逊核心 AI 团队 Research Scientist。Anish 专注于因果机器学习和合成数据生成。在实现了成为教授的目标后，他希望能将科研与技术商业化结合起来，因此在 2023 年创办 Traversal 并担任 CEO。

•Raj Agrawal - Cofounder

Raj 博士毕业于 MIT 计算机科学，曾就职于 Arbilex（一家 AI 法律初创公司，用 AI 等技术预测案件胜诉概率）、 Basis（一家 AI 研究机构）、Broad Institute（一家生物医学研究机构）。

Raj 过去的研究专注于将图模型应用于大规模机器学习系统。在研究“基因调控网络如何导致疾病”时，他发现其中的一些原理同样适用于理解“微服务架构中问题如何引发生产事故”。在 Broad Institute 工作期间，Raj 做 CRISPR 干预实验来研究药物处理或基因敲除对基因表达的影响，他开发了用于学习基因因果关系的技术。而这一技术也能迁移到工程系统中：只需将“基因”节点替换为“微服务”，就可以研究当某个服务被更改或破坏时，这种变动是如何在整个系统中传播的。

•Raaz Dwivedi - Cofounder

Raaz 曾获得印度理工高考（IIT-JEE）全国第十名，博士毕业于 UCB 计算机科学，是哈佛与 MIT 的博士后，也是康奈尔的运筹学与计算机科学教授，曾获得印度理工学院的总统金奖。在工作经历上，Raaz 曾就职于微软研究院和 WorldQuant。Raaz 的研究经历集中在因果机器学习和强化学习领域。他创办 Traversal 也是为了将自己的研究成果能够应用到业界的故障排查中，希望能够实现真正意义上的“自愈软件”。

•Ahmed Lone - Cofounder

Ahmed 是宾夕法尼亚大学计算机科学与金融双学士，硕士毕业于哥伦比亚大学应用数学，Ahmed 过去的工作经历涉及工程、产品、量化交易等不同的领域，曾在 Citadel Securities 担任量化研究员。之前他在做高频量化交易员的时候，曾多次在凌晨三点因生产事故被叫醒，对代码系统运维的痛点有着深刻的亲身体会。

07.

AI SRE 市场竞争

客户在考虑 AI SRE 的时候，最关心的就是准确性，这个因素可以从两个维度来衡量：1）事故复杂程度；2）可检索的数据范围。Treversal 正是利用自身的技术优势和架在各个可观测平台之上的“中立”地位，抓住了准确性，从而能最大程度地抓住客户。

目前 Treversal 的竞争对手可以大致分成以下几类。

传统可观测性巨头

以 Datadog （Bits AI）、Splunk、Dynatrace 为代表的传统巨头的 AI SRE 本质是利用 AI 提高用户对自己平台内数据的依赖度，从而服务于核心的数据存储业务。而 Traversal 则不寻求替换现有工具，而是构建一个跨平台的“大脑层”，利用推理能力连接数据孤岛。

以 Datadog 的 Bits AI 为例，可观测平台的优势在于：

•Datadog 的 Bits AI 直接运行在原生数据之上，无需 API 采样即可获得最完整的上下文。

•对于已经全量使用 Datadog 的企业，它能像高级 SRE 一样自动查阅内部日志、面板和 Runbook，极大缩短报警到响应的时间。

•有专家访谈称 Datadog 的成本约为 Traversal 的一半。

但这种“全家桶”模式在面对大型企业的真实复杂环境时，面临两个无法解决的结构性挑战。

1. 可检索的数据上下文有限

虽然 Datadog 和 Grafana 确实具备接入 Splunk、Dynatrace 和 AWS 等数据源的技术能力，但在企业平均同时使用 5 种监控工具的现实环境下，这种接入受到商业模式与成本的巨大制约。

Grafana 主要采用联合模式（Federation），通过插件直接查询源头数据而不进行移动，扮演的是连接器角色。相比之下，Datadog 采用摄取模式（Ingestion），核心商业逻辑是要求用户将数据复制并存储到自己的平台中。但出于商业利益，Datadog 缺乏动力去深度分析存储在竞争对手（如 Splunk）平台上的数据，除非用户将这些数据全量迁移过来。有专家访谈称，如果要使用 DataDog 的 AI SRE，就需要将所有数据都导入 DataDog，这会让 DataDog 的费用增加 10 倍，Datadog 因此只能看到企业数据的一部分。

Traversal 解决这一困境的方式并非替代现有的存储层，而是作为一个智能覆盖层（Intelligence Layer），通过只读 API 权限（Read-Only Access）直接架在现有的 Datadog、Splunk 和 AWS CloudWatch 等工具之上。它不需要用户进行昂贵的数据迁移，就能跨越这些平台获取信息。

除了连接现有工具，Traversal 的核心差异点在于它会直接摄取原始的 OpenTelemetry （OTel） 数据。它不依赖经过预处理或聚合的指标，而是分析最底层的原始链路数据（Raw Spans），利用这些数据构建基础设施的“数字孪生”和因果关系图，从而在虚拟模型中进行故障模拟和预测。

在全面性方面，Datadog 在历史数据存储和合规归档上更为全面，但在跨孤岛的上下文关联和数据精度上，Traversal 被认为更具优势。

•Datadog 的 AI 能力局限于内部存储的数据，如果用户为了节省成本将非关键日志留在 Splunk 或 AWS S3 中，Datadog 对这部分数据不仅无法感知，也无法进行有效的关联分析。而 Traversal 能够跨越工具边界，将 Datadog 的指标报警、Splunk 的日志错误以及 AWS 的配置变更自动关联起来，提供真正的全局视角。

•Datadog 为了处理海量数据通常会对指标进行采样或聚合，可能会丢弃极端的异常点；而 Traversal 倾向于处理原始数据，在分析长尾延迟等复杂故障时，能捕捉到 Datadog 可能已经过滤掉的微观细节。

2. 复杂事故的处理能力有限

有专家评价 Datadog 的 AI 主要是判断“系统状态”（Up/Down），缺乏 Traversal 那种跨越大量事件日志进行深度聚合和根因定位的能力。

因为传统厂商的 AI 多数停留在统计学层面的相关性排序，本质上是在海量噪声中做概率匹配。这只能处理有固定流程、高频发生的简单事故。在面对复杂严重故障（往往没有 Runbook、跨多个不兼容系统）时，传统 LLM 方案受限于 Context 长度无法吞吐 PB 级数据，且容易产生幻觉。

AI SRE 工具

这一类玩家是 Traversal 的直接竞争对手。根据客户访谈，Traversal 的优势在于自动化修复和深度根因分析，尤其是在复杂的物理/IoT 网络环境中，主要短板在于面对大型企业时的“数据安全合规”问题，以及在辅助人类决策（Copilot 对话体验）和专项日志挖掘上的不足。

Traversal vs Resolve

Resolve 是 Traversal 最直接的竞争对手，两者的核心差异体现在“执行能力”与“安全合规”的权衡上。

根据专家访谈，Traversal 具备显著的“行动者”（Doer）属性，能够实现 40% 的全自动问题解决率，例如通过 IoT 物理重启设备而无需人工干预。此外，Traversal 的“数字孪生仿真”技术允许在实际修复前在虚拟环境中模拟测试，有效降低了误报风险，而 Resolve 目前仅能推荐历史方案，缺乏对当前方案有效性的实时验证。

尽管 Traversal 在深度根因分析和团队响应速度上占优，但安全合规壁垒是主要痛点。由于 Traversal 要求访问 Wikis、Notion 和 Confluence 等包含敏感知识产权的非结构化数据，导致 Traversal 未能通过 Nike 的安全审查。相反，Resolve 凭借“混合/卫星”架构，在数据处理上更符合大型企业的合规标准，从而成功进入了 Nike 的供应商名单。

同时，业界对 Traversal 的“因果机器学习”的技术路线仍存在争议，有技术专家认为“因果机器学习”在业内尚未被充分证实，甚至有营销噱头的嫌疑，而 Resolve 基于指标的关联分析被认为相对更务实。

Traversal vs Flip

针对 Flip，两者的竞争焦点集中在技术底层的护城河与用户交互体验上。

Traversal 拥有由实时依赖图谱和因果推断技术构建的技术栈，具有极强的技术壁垒。有专家普遍认为，Traversal 向下兼容做辅助工具（Copilot）相对容易，而 Flip 想要向上突破做深度的根因分析则难度极大。而且 Traversal 的定位更加精准，基于实时状态分析，并具备独特的“爆炸半径”分析功能和简洁的 UI 设计。

但 Flip 在人机交互方面表现更为强劲，拥有出色的自然语言问答和上下文总结能力，这使得 Flip 在一线工程师的分诊工作中更具优势。此外，在处理非结构化数据和作为“智能助手”提取历史文档知识方面，Traversal 目前略逊于 Flip。

Traversal vs Deductive

在同 Deductive 的对比中，Traversal 强调的是因果性与平台完整性。

Traversal 的优势在于能够明确指出“因为 A 导致 B”的因果逻辑，而非仅仅发现两者同时发生的信号聚合。作为一个统一整合了日志、追踪和指标的独立平台，Traversal 的完整性远高于常作为 PagerDuty 插件存在的 Deductive。

不过，在海量日志挖掘方面，Deductive 表现出了更高的专业性。Traversal 在海量数据中“大海捞针”发现微小模式偏差的能力（即日志异常检测）尚不及 Deductive 专精。

文章来自于“海外独角兽”，作者 “Haozhen”。