从 DevOps "心脏病发作"到 AI 驱动诊断——Traversal 的 AI 智能体
摘要
Anish 和 Raj，Traversal 的联合创始人，正在用 AI 智能体重塑 DevOps 和站点可靠性工程（Site Reliability Engineering, SRE）的世界。他们提出了一个令人共鸣的类比：如今的 DevOps/SRE 工程师就像每周经历两次"心脏病发作"、同时还患有一种慢性病的患者——既要处理高严重级别的生产事故，又要被无穷无尽的告警和部署安全检查所折磨。
Traversal 的愿景是让 AI 接管低层次的故障排查和日常运维工作，将人类工程师解放出来去关注更有创造性的部分：基础设施的未来规划。他们的智能体系统目前能够在两到四分钟内定位到根因（当根因存在于数据中时），准确率超过 90%，大幅缩短了解故障的平均解决时间（MTTR），并减少了 Slack 事故频道中的参与人数。
更富洞见的是，Traversal 发现其产品在大型企业中反而比在 A 轮创业公司中更有价值——因为大企业的可观测性基础设施成熟、数据完善，但团队高度碎片化，没人能独自掌握所有上下文，这正是 AI 智能体发挥优势的最佳场景。
正文
医疗保健类比：三阶段需求层次
Raj 用一个精彩的医疗类比来解释 DevOps 和 SRE 的工作状态：
- 第一阶段：心脏病发作——正在发生的高严重级别生产事故。必须立即解决，其他一切都不重要。这是 P0 级别的故障应急响应。
- 第二阶段：慢性疾病——日常不断的告警流、部署安全检查、监控信息过载。它不像心脏病发作那样致命，但每天都在消耗精力。
- 第三阶段：生活优化——规划未来五年的基础设施、在正确的地方投入资源。这类似于优化睡眠和营养以追求更高的生活质量。
"但不幸的是，如今 DevOps / SRE 工程师的生活状态是：每周两次心脏病发作 + 每天需要应对的慢性疾病。"
Traversal 的目标是让 AI 智能体接管第一阶段和第二阶段，让人类工程师专注于第三阶段——这才是真正有意义和有创造力的工作。
AI 生成代码的"双面刃"
Anish 指出，Cursor、Windsurf 等 AI 编码工具的兴起正在制造一个新的危机。他用快时尚（Fast Fashion）的类比："你可以写几个提示就搭出一个可用的东西——试试看，不喜欢就扔掉。在这个世界里，可靠性其实不重要。"
但另一面是关键任务系统——支付、金融、安全基础设施、流媒体——这些领域同样在引入 AI 生成的代码。"当我们与企业客户合作时发现，每个人都在用 AI 辅助编码。问题在于：AI 生成的代码在本地测试中一切完美，但在大型系统中，不同模块之间的意外交互会导致故障。而因为你没有自己写这些代码，你根本没有上下文去调试它。"
"除非我们找到用 AI 系统来维护软件的方法，否则要么人们会禁用 AI 编码工具，要么宕机时间会飙升到无法接受的程度。"这正是 Traversal 所处的位置——用 AI 来维护 AI 生成的代码。
传统可观测性的尽头
Raj 对可观测性（Observability）行业的评价一针见血：它本质上只是数据的创建、存储和可视化——所谓 MELT 数据（Metrics、Events、Logs、Traces）。可观测性公司做到了他们能做的最好：用一个好看的仪表盘让你看到系统的各个切面。
但从定位到根因的复杂工作流仍然是纯手工的。当你看到 30-50 人挤在 Slack 频道里相互隐晦地指责、寻找"凶手"时——这就是可观测性工具在故障排查中能发挥的极限。AI 智能体公司的承诺，就是自动化这些在软件之上运行的复杂工作流。
Traversal 的架构：离线学习 + 在线推理
Traversal 的核心架构分为两个阶段：
1. 离线阶段：系统构建一个丰富的依赖关系图（Dependency Map）——理解不同功能、不同日志如何相互关联。这通过两种方式实现：
- LLM 语义理解：遍历代码和日志，理解标签之间的语义关系。
- 统计因果推断：利用时间序列中的自然变化来提取因果关系——这是 Anish 和 Raj 在研究生阶段研究的核心方法（最初用于 Broad Institute 的 CRISPR 基因调控网络研究，意外地与微服务故障传播问题高度同构）。
- 自博弈（Self-Play）：优先探索对根因分析最有希望的路径。
2. 在线阶段：当真实事故发生时，智能体使用实时信息和已经构建好的依赖关系图，判断应该做哪些"跳跃"来逐步逼近根因。
系统只需要只读访问数据，不需要生成新数据——这对企业客户来说是一个关键的安全卖点。
从 0% 到 90% 准确率的觉醒
Raj 分享了一个关键转折点：当团队第一次将系统部署到真正的大规模企业环境（数千个微服务）时，准确率顽固地停留在 0%。"无论我们怎么调整提示词、怎么改，它就是不动。我和 Raj 喝了一杯 Negroni......"
突破来自于两个关键架构决策：
1. 不做任何硬编码——不将特定公司的工作流写入提示词，不将人类调试的 meta 工作流硬编码到智能体系统中。
2. 将复杂性转移到计算上——在推理时投入更多 token 进行搜索和推理，利用推理时间计算（Inference Time Compute）。
一旦找到了能利用推理时间计算的架构，准确率开始飙升。现在，当根因确实存在于数据中时（日志、PR、指标等），Traversal 能在 2-4 分钟内定位到答案，准确率超过 90%。
企业比初创公司更需要 Traversal
一个反直觉的发现：Traversal 在大型企业中产生的价值远高于早期创业公司。原因有二：
1. 数据基础成熟——大企业的可观测性基础设施完善，所有东西都被充分埋点。
2. 团队碎片化——没有任何一个人或团队有足够的上下文来拼凑全局。这就是为什么 Slack 频道里会有 30-50 人。
"当推理所需的所有步骤都在数据中、但数据量太大导致任何一个人都装不下时——这就是我们创造最大价值的地方。"
竞争格局与未来
面对 Datadog、Splunk、Grafana 等传统巨头，Raj 认为机会在于这个行业的碎片化本质。"你去任何一家大企业，他们同时用 DataDog、Splunk、Datadrace、Elastic、Grafana、ServiceNow——什么都用。"每家可观测性公司都基于自己存储的数据定价，因此没有动力去分析存储在别人那里的数据。而 Traversal 作为一个数据源无关的层，恰好能跨越这道壁垒。
关于模型选择，Traversal 的策略非常务实：企业通常已有 OpenAI 或 Anthropic 的企业合同。如果自带模型会陷入一年的安全审批地狱。所以他们设计系统能够使用客户指定的任何模型，并可以在客户环境内进行微调（Fine-tuning），让系统随着每次事故的反馈不断缩小差距。
Anish 总结道："在产品和设计、核心工程领域——你必须不断对未来六个月的 AI 发展方向下注，并且愿意在六个月后重新评估一切。好消息是：它只会变得更好。"