从 DevOps 的"心脏病发作"到 AI 驱动的诊断：Traversal 的 AI 代理

coverSequoia Capital · 2025-06-24🎬 在 YouTube 观看原视频 →>

摘要

Traversal 的联合创始人 Anish 和 Raj 正在用 AI 代理（AI Agent）重塑 DevOps 和站点可靠性工程（SRE）领域。他们以一个生动的医疗类比开篇：今天的 DevOps 工程师如同"每周发作两次心脏病，同时忍受每日不断的慢性病痛"——即同时应对高严重性事故（High Severity Incidents）和无尽的警报流（Alert Streams）。

Traversal 的愿景是将 DevOps 工程师从"重症监护室的外科医生"转变为"基础设施的生命规划师"。他们构建的 AI 代理通过 LLM 编排工具（工具调用），在只读访问数据的前提下执行根因分析（Root Cause Analysis, RCA）。面对碎片化的可观测性（Observability）市场——企业通常同时使用 Datadog、Splunk、Datadog、Elastic、Grafana、ServiceNow 等五六种工具——Traversal 提供了一个数据源无关的诊断层。

实践结果令人振奋：当根因存在于数据中时，Traversal 能达到 L4 自主级别（精准定位到有问题的 PR 或日志），准确率超过 90%，并且在 2 到 4 分钟内完成分析。他们发现产品在大型企业中价值最高——因为大企业的可观测性数据成熟但团队高度碎片化，无人拥有完整的调试上下文。最具反直觉的发现是：向大企业推广 AI 方案反而比初创公司更快，因为大企业"对用 AI 解决真实问题的渴望异常强烈"。对于 AI 生成代码和"氛围编程（Vibe Coding）"的兴起，他们警告：当 AI 编写的代码在生产环境中以意想不到的方式交互时，需要新的 AI 维护工具来解困。

正文

医疗类比：DevOps 工程师的三重痛苦

Anish 一针见血地描述了当前 DevOps 和 SRE 从业者的处境。他将运维工作分为三个层次，恰好对应马斯洛需求层次：

第一层——心脏病发作：高严重性事故（P0/P1 Incident）。"你必须在那一瞬间解决它，其他一切都不重要。五分钟之内唯一重要的事情就是解决你正在经历的心脏病发作。"这就是传统意义上的战情室（War Room）场景，30 到 50 人涌入 Slack 频道，相互暗中指责，上演"谁是凶手"的剧本。

第二层——慢性疾病：持续的警报流和部署安全检查。"就像你每天都要应对的脚踝扭伤，你很难提前规划三个月，因为有些东西每天都在困扰你。"这正是 DevOps 工程师每天处理数千条告警、逐一判断部署是否安全的日常。

第三层——生命黑客：规划基础设施的未来。"如何优化睡眠和营养以提高生活质量？"——这是运维工作最有创造力的部分：未来五年基础设施的演进方向在哪里，应该在哪些领域投资。

"不幸的是，今天的 DevOps 和 SRE 工程师的生活是：每周发作两次心脏病，同时忍受每天不断的慢性病痛。"Anish 总结道。如果 Traversal 完成使命，AI 代理将接管第一和第二层需求，让 DevOps 工程师专注于最令人满足的创造性工作。

根因分析的荒诞现实

Raj 描述了企业事故的典型生命周期：某个客户发现问题→客服确认不是用户错误→升级给工程团队→经过五六层工程组织的"电话游戏"→最终到达 DevOps/SRE 团队→判定是否值得启动事故流程→创建 Slack 事故频道→30 到 50 人涌入→"某个 10x 工程师像福尔摩斯一样突然喊了一声 Aha，找到根因"→回滚或热修复→然后所有人慢慢寻找长期修复方案。

"不可思议的是，可观测性工具已经是企业仅次于云支出的第二大软件开支，但我们仍然停留在这种根因分析的水平上。"根源在于，可观测性行业本质上是"遥测数据（Metrics, Events, Logs, Traces，简称 MELT）的创建、存储和可视化层"——这已经是技术所能做到的全部。而故障排除这整个复杂工作流仍然高度依赖人工。

从 React 到推理时计算：技术架构的进化

Traversal 早期采用业内流行的 React 框架为小型公司构建了有效的系统。但当他们开始服务拥有数千微服务的大型企业时，遭遇了"觉醒时刻"："无论我们怎么改提示词，准确率顽固地停留在 0%。"

这个低谷迫使团队做出关键决策：不做面向特定公司的硬编码、不将人类的调试工作流硬编码进代理的行为。相反，他们将复杂性转移到了推理时计算（Inference Time Compute）上——"用 Token 来解决这个问题"。一旦找到利用推理时计算的架构，准确率开始飙升。

现在 Traversal 的架构分为两个阶段：离线阶段利用 LLM 和统计方法构建系统间的丰富依赖关系图（Dependency Map），同时使用自博弈（Self-play）优先处理最有希望的根因分析路径；在线事故发生时，代理利用实时信息和依赖关系图来决策每一步要追溯哪些线索。

Anish 指出，他们的一项重要决策是只要求只读数据访问——因为企业不希望又增加一个产生数据的工具。

大企业比初创公司更适合 AI 诊断

一个反直觉的发现是，Traversal 在大型企业中创造的价值远高于初创公司。Raj 解释："当你成为一个大企业，可观测性已经非常成熟——一切都被以正确的方式记录下来，基础数据就位。但团队高度碎片化，没有人或团队拥有完整的调试上下文。这就是为什么 30 到 50 个人出现在 Slack 事故频道中。"

Traversal 的核心价值主张是：当推理步骤能从数据中找到时，代理能做得比任何人都好——"只是数据量太大，任何一个人都无法全部记在脑中"。这与传统 SaaS 企业"先攻小公司再攻大公司"的路径截然相反。

在新客户部署上，Traversal 系统通常需要 5 到 10 小时来遍历客户的整个代码库和可观测性系统并建立起系统理解。大型客户可能需要一天。

在碎片化的可观测性市场中竞争

Raj 指出，可观测性市场之所以昂贵且碎片化，根因在于传统的定价模型：所有工具都基于存储的数据量收费。"因此，Datadog 没有动力告诉你 Splunk 里存储了什么。但要调试一个问题，SRE 需要同时调用五六种工具。"

这种历史性的碎片化为 Traversal 创造了一个机会窗口：作为数据源无关的诊断层，代理可以跨越不同的存储系统进行推理。"理想情况下，像我们这样至少在现阶段对数据存储位置保持中立的公司，会获得机会。"

然而，Traversal 面临的一个现实约束是企业通常已有 LLM 供应商的合同（OpenAI 或 Anthropic），如果试图引入自己的模型或微调版本，"你将在安全审批的地狱中困上一年"。因此，Traversal 的设计是模型无关（Model-Agnostic）的——复杂性的重心在于"让 LLM 访问正确的工具组合来编排根因分析流程"。同时，他们可以在客户的 Azure OpenAI 实例上进行微调，使其在每次事故后自动缩小差距。

从学术研究到工业落地：意外的幸运

Anish 透露了一个出人意料的学术渊源：他在 MIT 博士期间与 Broad Institute 合作，研究 CRISPR 基因干预——通过基因调控网络理解药物或基因敲除实验对基因表达的影响。事实证明，他们为学习基因间因果结构而开发的技术，与应用到微服务（Microservices）之间因果关系的发现惊人地一致。

"如果你把基因节点换成微服务节点，然后研究当我在做一个 PR 变更或破坏系统某部分时，影响如何蔓延——这几乎变成了同一个问题。"Raj 坦承这是"纯粹的运气"——"直到我们深入问题之后才意识到，天啊，我们的研究生研究竟然在这里发挥了作用，我们太幸运了。"

AI 时代的日志文化变革

一个令人深思的观点：可观测性的数据层本身将发生根本性改变。"当 AI 系统自己读取日志时，日志的格式应该与供人类滚动浏览的日志完全不同。"Raj 指出，AI 时代的日志应该在消息字段中嵌入尽可能多的信息——因为 LLM 可以处理长错误堆栈，而人类不行。"人类的上下文窗口比这些 LLM 短多了。"

Anish 补充了一个细微差别：让日志连接业务逻辑。"工程系统本身可能没问题，但什么才算'正常'取决于业务逻辑。在正确的方向上连接这两者仍然是一门艺术，除非 AI 拥有对业务逻辑的完整理解——这可能会发生，我不确定。"

AI 生成代码的维护危机

对于"氛围编程"和 AI 辅助编码工具（Cursor、Windsurf 等），Traversal 的两位创始人提出了警醒。Raj 区分了两种不同的世界：

快时尚（Fast Fashion）的世界：你写一段 prompt，得到一些代码，部署后让人们试用。"在这个世界里，可靠性根本不重要——因为你根本不需要维护你创建的东西，没有工艺可言。你创建它，然后抛弃它。"

关键任务系统（Mission-Critical Systems）的世界：支付、金融、安全基础设施。当 AI 编写的代码在这些系统中以你从未意识到或无法预见的方式交互时，当代码出错时，"你根本无法调试它——因为代码不是你写的，你不再拥有上下文。"

Raj 警告："除非我们找到使用 AI 系统进行软件维护的方法，否则我们会被扼住喉咙——要么人们禁止使用 AI 软件工程工具，因为停机时间太多；要么我们需要新的工具和软件来维护这类系统。这就是 Traversal 可以发挥作用的地方。"

他被问到"五年后支付系统或银行系统会不会被'氛围编程'"时，回答是："在某种程度上，是的。"因为只要代码通过了测试，谁在乎代码是怎么写的——但关键是要有"更好的测试感"。

问答精选