图片来源：Sequoia Capital
Z Highlights
-
在我看来，排查问题、做RCA，是任何一组软件工程师中最复杂的工作流之一。而现在我们有机会在复杂性层级上更进一步，使用AI系统来自动化整个工作流，而不再止步于存储和可视化。
-
我们真正想要实现的是：你必须定义一组足够丰富的工具，使得一个RCA可以被表达成某种工具调用的组合或序列。这其实就是多Agent和系统复杂性所在的核心问题：你如何把这些工具组合起来解决一个复杂任务。
-
所有最有趣的创新，都是在像我们这样的、专注于研究的小型初创公司中发生的。能够看到在一些顶尖大学里最好的研究成果，而现在又看到它们在公司中的实际应用，感觉这里才是所有魔法和特别工作的发生地。
-
能够快速迭代AI和数据的心态，才是使某人成为优秀AI研究员或AI工程师的关键。所以这更多的是一种思维方式，而不是证书。
Anish Agarwal，Traversal 联合创始人兼 CEO，MIT计算机科学博士。Raj Agrawal，Traversal 联合创始人，MIT 计算机科学博士，曾在基因调控网络研究中提出关键因果建模方法，推动 AI 在企业系统根因分析中的落地应用。本次访谈由Sequoia Capital在2025年6月发起，与Traversal联合创始人Anish Agarwal和Raj Agrawal探讨AI如何重塑企业关键系统的RCA流程与软件可靠性维护的未来。
AI在DevOps与SRE中的革命性应用
Sonya Huang：今天我们很高兴欢迎Anish和Raj，Traversal的联合创始人。Traversal正在构建AI Agent，以改变DevOps和站点可靠性工程的世界。现在公司拥有战情室和大量的DevOps和SRRE团队，负责排查生产故障并修复代码库中的问题。每一分钟的生产停机都非常昂贵，有时甚至是生死攸关。保持公司的应用程序正常运行是一项非常困难且宝贵的工作，而随着AI生成代码和vibe coding的到来，这个问题只会变得更加严重。Traversal认为，Agent是解决这个问题的可扩展方案，并且已经从他们部署到生产中的故障排查Agent中看到了令人兴奋的成果。我们很高兴能让他们分享更多关于这个愿景以及迄今为止的成果。
Bogomil Balkansky：Anish和Raj，欢迎来到《Training Data》，很高兴今天能有你们的到来。我们已经合作了一年，迫不及待想要与我们的观众分享AI和AI Agent如何改变站点可靠性工程和DevOps的世界。当然，我们也需要在后面的对话中插入一些鸡尾酒，但我们稍后会再提到这一点。首先，我们从一些快速的观点开始，五年后，DevOps或SR会像今天这样存在吗？
Anish：这是个很棒的问题。它会存在，但它将与现在的方式有根本性的不同。在DevOps和SR的世界里，医疗保健的类比通常是非常自然的。
在这个世界里，如果你考虑到医疗保健和马斯洛的需求层次，就可以想象，第一阶段是你心脏病正发作，你必须立即解决这个问题，除此之外没有其他任何事情重要，五分钟后没有任何事情比解决你现在的心脏病发作更重要，对我来说，这就像是处理一个高严重性的事故。
第二阶段是，你在处理一些慢性问题，比如你扭伤了脚踝，或者任何其他影响到你的疾病，很难提前三个月规划，因为这是每天都在影响你的事情。这与DevOps中的工作类似，处理一系列的警报，检查部署是否安全等等。
第三阶段，我把它看作是“生活黑客”，你在思考如何优化我的睡眠和营养，以便拥有一个高质量且充实的生活，这就相当于规划你接下来五年的基础设施，以及如何现在就开始在正确的地方进行投资。如果我想象一下，目前DevOps和SRE工程师的生活状况，那就像是每周心脏病发作两次，并且每天都在应对一种让人虚弱的慢性病。
Bogomil Balkansky：当我听你说这些时，我试着想象我认识的那些DevOps和SRE人员，他们穿着医护服，或者戴着CGI监控设备来进行“生活黑客”，像是优化他们的基础设施。
Anish：人们没有意识到，但当你把它与医疗保健联系起来时，你就会意识到我们已经习惯了什么样的生活，和实际上生活应该是什么样子的。我们思考大规模软件系统的健康状况时，也是如此。如果Traversal能做好它的工作，那么在第一阶段和第二阶段的需求——即处理高严重事故以及每天面对的无休止的痛苦——应该由AI和AI Agent来解决，而DevOps和SR可以去处理更具创意的、有趣的部分，比如“我的基础设施在未来一年或五年应该是什么样子？”这样，这将变成一份更有意义的工作。
Bogomil Balkansky：现在，许多工程团队都在采用自主编码的技术，比如Cursor和Windsurf。你认为这会对人们如何维持基础设施的可靠性产生深远影响吗？还是说，AI将在实现这一愿景中发挥重要作用，把人们从像重症监护室外科医生那样的角色中解放出来，转而成为更具思考性的规划者？
Anish：这会有一个短期的答案，也会有一个长期的答案。
至少在短期内，它是一个两极分化的世界。第一个世界是，在Cursor和Windsurf等技术的推动下，vibe coding的概念变得非常流行。我们可以写一个提示或者几个提示，然后让一些东西起来，大家可以使用和玩耍。但这里的类比就像快时尚，你试穿一件衣服，喜欢就穿，不喜欢就丢掉，接着开始穿下一件。在这种世界里，可靠性其实并不重要，因为你不需要照顾你创造的东西，没有工艺可言。
但在另一个世界，你开始将这些AI驱动的软件工程技术应用到关键任务系统中，比如支付、金融机构、身份验证、安全基础设施、流媒体等，就会导致一个重大问题，而这个问题可能已经存在，并且看起来只会变得更糟。我们和我们合作的企业看到的情况是，每个人都在使用AI驱动的软件工程工具来指导他们写代码。实际上，些代码甚至可以通过本地单元测试，看起来一切都很完美。然而问题在于大规模企业中，当你系统的不同部分以你没有预料到的方式交互时，事情就会出错，或者你无法预见到这个问题。当这种情况发生时，由于所有的代码都是由AI系统编写的，很难调试，因为你已经失去了上下文，你不再是写这段代码的人。除非我们找到使用AI系统来进行软件维护的方法，否则我们将受到限制，要么人们会禁止使用AI软件工程工具，因为它带来了太多的停机时间，要么就会出现其他类似的情况。在这个世界里，我们将需要新的工具和新的软件来帮助维护这些系统，Traversal可以在这方面发挥作用。
AI驱动的故障排查与RCA：从手动到自动化
Bogomil Balkansky：你真的很擅长用词和类比，我很喜欢你提到的“两个世界”的说法，要么是Louis Vuitton的高端时尚，要么就是像Shein那样的快时尚，或者类似的东西。但我们可能一下子就跳得有点太快了。我们不如回到之前的几个步骤，或许可以为我们的观众解释一下，RCA到底是什么？它是做什么的？跟我们分享一下这个精彩的故障排查和RCA的世界吧。
Anish：所以如果我单纯考虑一个事件的生命周期，事件的故事在不同公司之间总是出奇地相似。
一个客户登录平台，发现事情没有按预期工作，要么问题已经被记录下来，要么他们向客户支持提出投诉。客户支持查看问题后说：“好的，这不是用户错误，确实是一个问题。”然后它在不同复杂度的工程组织之间通过一种电话游戏的方式逐级上报。最终，它会到达DevOps和SR团队，他们查看问题，基于它的影响、严重性和紧急性，决定这是否值得作为一个事件处理。如果他们认为它值得作为一个事件处理，突然之间混乱就爆发了。你会创建一个Slack事件频道，30到50人会在频道里，每个人都在暗地里互相指责发生了什么，类似一个“谁做的？”的情形。几乎毫无例外，都会发生同样的事情：会有一个10倍工程师，他已经在公司工作了一段时间，像福尔摩斯一样解决了这个情况，“啊哈”——他们会准确找出发生了什么，虽然不清楚他们是怎么得出结论的，但他们找到了答案。然后，找出某种热修复方案，接着大家开始寻求一个长期的解决方案，随着时间推移不断改进。这通常就是事件处理的全过程，这个过程我们称之为事件生命周期，尤其是RCA。
令人惊讶的是，所有的Observability工具，像这些不可思议的公司，通常是公司在技术开支中第二大项，仅次于云开支，然而我们仍然停留在RCA的状态上。这就是我对如今RCA的看法。
Bogomil Balkansky：那么，能不能给我们更多的背景？RCA在今天公司使用的各种Observability工具中处于什么位置？如果这是技术开支中的第二大项，为什么你仍然会看到有50个人在Slack频道里，像在侦破“谁做的？”的剧情一样？
Anish：这恰好说明了这个问题的重要性。Observability所做的一切，已经是他们在六个月前那个技术水平下所能做到的最好了。如果我去定义Observability，它本质上是关于遥测数据的生成，也就是所谓的MELT数据：指标、事件、日志和追踪，简称MELT。它的核心在于生成这些数据、将其存储下来，并在此之上提供一个良好的可视化层，让人们能够从系统的不同部分提取出合适的视角，创建出“观察窗口”。
Observability的尽头正是存储和可视化层——因为过去也只能做到这一步。而故障排查的复杂工作流仍然是高度依赖人工的，这只是因为在那时我们也只能手动完成这些流程。而现在，这些AI Agent公司所承诺的，是能够自动化我们在软件之上执行的这些复杂工作流。在我看来，排查问题、做RCA，是任何一组软件工程师中最复杂的工作流之一。而现在我们有机会在复杂性层级上更进一步，使用AI系统来自动化整个工作流，而不再止步于存储和可视化。
Traversal的解决方案与行业影响
Sonya Huang：你可以讲讲你们的产品吗？你们正在构建的Agent或多个Agent是怎样来解决这个问题的？它是如何工作的？
Raj：也许我可以先退一步说说，Agent到底是什么。其实它是LLM对工具的一种编排。在我们的体系中，这些工具可能包括数据获取工具，比如如何拿到日志、获取指标、返回数据处理结果，或是将数据格式化成Agent能够理解的方式，或者是一些统计工具，比如运行异常检测。我们真正想要实现的是：你必须定义一组足够丰富的工具，使得一个RCA可以被表达成某种工具调用的组合或序列。这其实就是多Agent和系统复杂性所在的核心问题：你如何把这些工具组合起来解决一个复杂任务。至少在我们的应用场景里，数据体量太大，必须是顺序处理的，因为一个跟踪记录甚至可能无法装入LLM的上下文里，所以你得知道怎么一点一点构建这个LLM的上下文，最终追溯到根本原因。这正是这个问题如此具有挑战性的原因。
Sonya Huang：你们是否是在模拟一个人类故障排查员的认知架构？就是说，操作流程图是不是和一个人类会做的事情非常相似，还是说Agent采取的是完全不同的路径？
Raj：我们在最初考虑这个问题的时候，确实试图去模仿一个SRE在调试时的思路，那是非常手动、非常顺序的。一个SRE通常会看一条证据，然后思考下一步要看哪条证据。但很多时候，他们是基于系统知识跳跃推理的，而这些是Agent可能不具备的。我们在这里其实借助了更大的规模来绕过这种“系统知识”的缺失问题。这个Agent基本上会以一种更系统化的方式去查找，比如它会参考Google SRE handbook里提到的那些关键指标，比如延迟、错误率等，它会采用一种健康监测的方式去拼接整个问题空间的搜索路径。这个过程不是像人那样靠“跳跃式”的推理，而是Agent以一种顺序的流程方式去一步步达到答案。
Bogomil Balkansky：是否有特定的条件或环境，使得这种Agent驱动的方法效果更好或更差？
Anish：是的，从根本上来说，这是关于数据访问的问题。我们发现——令人惊讶的是——有时我们在像A轮初创公司中能提供的价值较少，而在大型企业中能够提供更多价值。因为当你变成一个大型企业时，你的Observability是相当成熟的，所有的系统都被以一种方式进行监控，确保了基础数据到位。但是，你的团队通常是高度分散的，因此没有一个团队或一个人能够有足够的上下文来拼凑出调试的全部信息。正因如此，你会看到在Slack事件室里有30或50个人。我们从根本上发现，当数据能为Agent提供从高层触发到根本原因的推理步骤时，我们能发挥最大的作用。数据太多，一个人无法在脑海中保持所有信息。如果这些数据本身没有，那么Agent就会受限，这通常在企业环境中不会发生——这是我们发现的情况。
Bogomil Balkansky：非常有趣，实际上有些反直觉，因为在初创公司中，通常情况下，选择设计合作伙伴或客户的方式是从小公司或中型企业开始，然后逐步过渡到大型企业。如果我们用L1到L5的类比来描述自动驾驶汽车的技术进展，那么你们离让Agent正确找到事故的根本原因还有多远？或者更广泛地说，什么才算成功？我们是否在努力实现100%的正确解决？在这个上下文中，什么才算是正确的解决方案？
Raj：这是一个很好的问题。这里有两个案例。第一个案例是根本原因在数据中，因此它可能在某些日志或某个PR中。在这种情况下，我会说通过Traversal我们达到了L4，但我不会说L5，因为对我们来说，可能我们能够标记出那个有问题的PR或是那条触发的日志，但仍然有最后一步的修复和补救。如果修复并不是局限于某个特定文件或代码更改，而是需要进行一个更大范围的系统级变更，那么我们还没有做到这一点。不过，这也是看代码Agent发展的一个激动人心的地方，因为在这个层面我们能够达到L5。对于那些根本原因不在数据中的情况，我们更多的是处于L2的水平。Traversal可以发现很多重要的症状，帮助人们调试，但有时数据中并没有包含根本原因，这时需要人类做更多的推理跳跃，才能找到真正的根本原因。不过，症状确实能帮助我们确定如何进行这些跳跃。而对于我们来说，当我们注意到这种情况时，我们可以告诉客户，或许你应该以这种方式进行监控，使系统更加可观察。
Sonya Huang：目前AI领域涌现出许多有趣的原生AI公司，比如你们这样的公司，同时也有一些传统的企业，在很多情况下他们并不是“掌舵人睡觉”那种状态。你是怎么看待传统企业的风险的？为什么你的客户会选择与你合作？
Anish：是的，这是一个很好的问题，其中的核心是Observability的成本非常高。它是一个昂贵的产品，人们为之付费，因此它变得极度碎片化。你去任何一家大企业，他们都在使用DataDog、Splunk、Datadog、Elastic、Grafana、ServiceNow等，几乎什么都有。它们都在进行这种“消耗战”，问题是，如果你仅仅从定价模型上来看，这些公司都基于它们存储的数据量来收费。因此，公司A没有动力去提供更好的洞察力来分析公司B存储的数据。如果你看一下任何一个SRE或在岗的工程师，他们在调试时会调用他们可以访问的所有五六个工具，这种历史行业的碎片化，最终会导致像我们这样的公司出现。至少目前，我们不依赖于数据存储的位置，这给了我们机会。
Sonya Huang：你们现在有没有客户已经在部署Traversal了？你从中发现，基于你们的学术背景，你们原本的预期和实际在现实环境中遇到的差异有哪些？
Anish：这是一次相当有趣的旅程。像大多数公司一样，我们从非常小的公司开始，然后构建了一些对他们有效的东西。通常，这个过程是这样的：我们会查看他们过去的100个事件，通常是在Slack频道中，然后试着用我们的思维去理解，他们在那个特定公司中通常是如何调试一个事件的。在这种情况下，Agent的一个非常流行的框架是React框架，作为一个通用的概念，这个框架是可行的，我们可以将这种元工作流嵌入到一个React Agent系统中，它能够做得非常好。然后，到了一定时候，我们开始面向更大的公司，这些公司有着实际的大规模Observability系统，成千上万个微服务，类似这样的情况。
我记得很清楚有一周，是我们第一次面对这种规模，当我们尝试将我们的系统应用于历史上发生的某个事件时，我们的准确率是0%，无论我们怎么调整提示语、做任何改动，它都顽固地停留在0%上。这是一次彻底的“当头棒喝”，我记得我和Raj当时做了个深刻的反思，接着我们就开始考虑解决方案，我们做了一些有趣的决定，最终对我们有利：我们决定，系统中不会有任何特定公司硬编码的内容，工作流中人类操作的内容也不会硬编码到Agent的工作流中，这样复杂性必须去某个地方，最终它进入了计算，在我们这个领域里，表现为在问题中使用Token，即在推理时消耗Token。
一旦我们找到了一种能够利用推理时计算的架构，现在每个人都认为这很重要，准确性就开始大幅提高。我们发现，当根本答案就在数据中时，我们能在90%以上的时间内找到答案，而且通常能在2到4分钟内找到，这非常令人惊讶。现在你只需要看看这些Slack频道，人们大部分时间都在验证我们找到的答案，而不是实际去追溯根本原因。仅仅是时间上，月度解决时间已经大幅缩短，平均在Slack频道中的人数也减少了，这两个方面是任何企业都非常关心的。
Bogomil Balkansky：在这种情况下，你是如何衡量准确性的呢？例如，很多公司都专注于LLM的性能评估，在SRE和根本原因分析的领域里是否也有类似的概念？你们是如何知道自己正确地识别出根本原因的呢？
Anish：对我们来说，最重要的标准就是在真实事件中进行测试。老实说，当你为客户提供服务时，事件通常每周会发生两到三次，在这种情况下，你可以获得最直接的反馈。通常，一个事件的解决过程可能需要几个小时，你可以查看事后总结，从中进行评估。所以真实事件是最有价值的评估来源。除此之外，我们还会评估一些其他的小任务，比如当用户尝试从Observability系统中获取特定信息时，或者进行RCA时需要处理的较小任务，这些任务量相对较大。但归根结底，真实的现场事件是我们最好的评估方式，效果非常好。
Bogomil Balkansky：听起来你们在某个时刻经历了一个“当头棒喝”的情况，部署产品后准确率停留在0%，直到你们回到起点，重新审视并重构整个架构。那么，能否给我们简单介绍一下现在产品是如何工作的？是什么使得它能够精准地进行RCA？
Raj：我们做出的一个重要决策是，我们只需要对数据具有只读访问权限。这是一个基于企业不希望再增加更多工具生成数据的考虑。那么我们是如何做到的呢？
有两个阶段，一个是离线阶段，另一个是在线阶段。在离线阶段，我们主要是在学习这个丰富的依赖关系图，探索不同功能和日志之间如何相互关联，一种方法是通过LLM，LLM会进行遍历，真正理解这些日志及其不同标签在语义上的关联关系。
然后，我们还使用了统计学，当时间序列中存在自然波动时，统计学就会发挥作用，这些波动会留下因果关系的痕迹，这正是Anish和我在研究生时期一起研究的内容——如何从数据中提取因果关系。这对于构建这个丰富的依赖图非常关键。
我们还使用了自我训练，基本上是为了优先选择那些对RCA非常有前景的路径。现在，一旦我们构建了这个丰富的依赖关系图，在在线阶段，当一个真实事件发生时，Agent会利用实时信息和这个依赖图来判断该进行哪些操作，进而完成RCA。
Bogomil Balkansky：离线部分需要多长时间才能发挥效果？换句话说，从部署解决方案到第一次能够真正排查的事件，这段孕育期需要多久？
Raj：这取决于他们是想排查一个实时事件还是历史事件。一般来说，我会说我们大约需要5到10小时，去浏览他们的整个代码库，查看他们的Observability系统，真正了解这个系统。对于大型客户来说，可能需要一天的时间，但一般是5到10小时。
Sonya Huang：你提到过推理和推理时间计算几次，想问一下，你们是使用现有的基础模型，并对它们进行微调以适应你们的需求吗？还是说你们自己构建了大量这种架构？能不能稍微谈谈你们做出的一些架构决策？
Anish：我们学到的一个非常有趣的事情是，如果你和企业合作，他们通常已经与某个LLM提供商有了现有的合作关系。所以他们可能与OpenAI或Anthropic有企业合同。如果你试图向他们提供你自己的模型或者微调过的模型，你就会陷入一年的“安全地狱”。所以你必须约束自己，不能要求使用你自己模型，而是得能够使用他们提供的模型。通常，OpenAI是一个相对安全的选择，Anthropic也是。大部分的复杂性其实在于如何获取LLM能够使用的正确工具集，以便协调RCA步骤。另一件事是，你可以在公司的环境中进行微调。例如，如果他们指向他们的Azure OpenAI实例，你可以通过每次发生事件后，看看最终的根本原因是什么，看看你离目标有多远，系统就可以微调以确保这个差距随着时间的推移越来越小。这大概是我们看到的实践过程。
Bogomil Balkansky：你们还提到你们的部分架构基于你们多年的学术研究，能否分享一下你们的博士论文和现在将这些内容转化为公司业务之间的关系？
Raj：是的，实际上有一件事挺有意思的，至少在研究生期间，我和Broad Institute紧密合作，主要是理解在这些CRISPR干预中，基因调控网络是如何工作的。你做CRISPR干预时，试图理解这种药物或这个基因敲除实验对这些基因表达的影响。我们在那里开发的用于学习基因间因果结构的技术，结果发现它与我们在生产系统中面临的问题非常相关。如果你把基因节点替换成微服务，然后你学习当我做了PR更改或破坏了系统的某个部分时，这种变化是如何传播的，几乎就成了一个完全相同的问题。这完全是运气，我们当时并不知道会发生这种情况，直到深入了解问题后，我们才意识到：哇，真幸运，我们的研究生研究在这里发挥了作用。
Bogomil Balkansky：在过去一年到一年半的旅程中，还有哪些其他的惊喜？
Anish：对我来说，其中之一，也是我们如此开心的一部分，就是人工智能进入了工业时代。所有最有趣的创新，都是在像我们这样的、专注于研究的小型初创公司中发生的。能够看到在一些顶尖大学里最好的研究成果，而现在又看到它们在公司中的实际应用，感觉这里才是所有魔法和特别工作的发生地。对我来说，这真的很惊讶，因为我来自学术界，曾经想成为教授，创新应该在那里发生。所以这个转变真的是让我很惊讶。另一个让我惊讶的事情是，企业对使用AI解决实际问题的渴望非常强烈。你可以看到与他们合作的速度，通常需要一两年才能完成的事情，现在几个月就能迅速做完。所以市场的渴望和行业创新的速度都让我感到非常惊讶。
Bogomil Balkansky：说到创新的速度，事情发展得非常迅速，你们已经做这个产品稍微超过一年了。有没有遇到过这种情况，需要回去重新做一些工作，因为市场上现在出现了MCP或者其他什么新东西，而之前你们必须自己去开发，但现在这些东西几乎是现成的，或者说，如何让你的架构和工作内容具备未来适应性呢？
Anish：说实话，对于这一代公司来说，这将是一个持续的挑战。如果你从事产品、设计或核心工程工作，你就必须不断做出预测，判断AI在六个月后会发展成什么样，并且愿意在六个月后重新评估所有事情。好消息是，这一切只会变得更好，所以你并不需要担心六个月后产品会变得更差。例如，一个非常有趣的预测已经兑现了，那就是Raj和Raj非常有远见地预见到推理模型将会变得更强大，他们在9月就做出了这个预测，基于他们对世界发展趋势的判断，并且我们设计了我们的系统，让推理模型能够在架构中发挥出色作用，现在来看，这个预测的结果确实让我们的架构受益匪浅。所以，你必须不断地做出这种六个月的预测，去判断AI的未来走向，并恰当地乘势而上。能够正确做出几次这样的预测的公司将会赢得未来。如果你问我，你更愿意成为一个AI团队来解决这个问题，还是成为一个Observability团队，虽然我有偏好，但我还是更倾向于选择AI团队。因为作为AI团队，你只需要更善于做出这些未来走向的预测，并在这过程中变得更加成熟。
Sonya Huang：你们团队的构成是怎样的？有多少是研究人员，有多少是来自领域的？我很好奇AI原生Agent公司将来会是什么样的。
Raj：目前来说，我们大概90%是工程师。很多人有博士学位，专攻机器学习，此外，大部分人都有传统的软件工程背景，他们对生成式AI非常感兴趣，并且在自己生活中使用过。对于这些问题，至少现在的门槛比较低，大家都在尝试学习如何创建一个Agent。我不认为现在像以前那样，需要博士学位来编写这些复杂的LLM的梯度更新，现在已经更加民主化了，这一点从我们的团队组成就能看出来。
我们也有一些专门从事基础设施工作的团队成员，负责如何扩展这些Agent。对于Anish提到的推理时间计算问题，如何让AI Agent完成远超人类能力的工作，这是一个非常有趣的挑战。对我们而言，每次调查都需要发起成千上万的网络请求，因此这也促使我们招募最优秀的基础设施工程师。此外，我们还有产品经理，接下来一个月会有一些新成员加入，所以我们非常兴奋，期待将来自不同背景的人们聚集在一起，共同解决这个艰难的问题。
Anish：公司内部每个人的共同点是对生成式AI的兴奋感。正是因为这个原因，大家愿意去学习、适应，并且丢掉那些不奏效的东西，而不是固守己见。因为正是那些固守传统的人，才是这种文化下无法生存的人，因为这个世界变化太快了。如果我考虑一下，什么是有趣的，我就会想到AI研究员、AI工程师和普通工程师之间的差异，应该怎么组织这些人呢？这跟你是否有博士学位或任何形式的证书没有关系，关键在于你在思考时有多么具有实验性，有多么愿意去做一些小的预测和假设，然后迅速地验证它们。能够快速迭代AI和数据的心态，才是使某人成为优秀AI研究员或AI工程师的关键。所以这更多的是一种思维方式，而不是证书。
Bogomil Balkansky：说到你们团队的组成，我发现很有趣的是，你们俩以及你们的另外两位联合创始人并不是Observability领域的业内人士，整个公司在AI和工程能力上非常强大，但在Observability领域的专业知识相对较弱。然而，你们却在这个领域掀起了波澜，成功解决了那些通常需要一大群人四处奔波、垃圾捡捡找出问题日志的复杂问题。这几乎引出了一个问题：你们认为未来在你们客户的观察团队中，情况会是怎样的？你提到过，很多人掌握了所有的内部知识和直觉，能够在没有数据的情况下进行推理。这些技能在5到10年后是否仍然有价值，还是说Observability团队将会发生根本变化？
Anish：我有几个方面的看法。首先，未来会有大量工作需要围绕AI系统本身的可靠性展开。而如何评估AI系统的可靠性，不仅需要遵循一些基本的SRE原则，同时还需要具备一定的AI素养。因为这些系统出故障的方式往往非常独特，是我们过去未曾习惯的。因此，现代SRE团队在某种程度上需要同时精通这两个领域——既要了解LLM和AI系统是如何失效的，也要理解传统系统的故障模式。将这两方面结合起来，才能真正成为一名优秀的DevOps或SRE工程师。
另外还有一个相对简单但同样重要的点是：Observability的数据层本身也将发生根本性的变化。比如，一条日志的结构和内容将会变得完全不同。要成为一名合格的SRE或DevOps工程师，其中一个关键能力就是知道如何写好日志。这样在系统发生故障时，才能保证你有合适的可观测手段。日志的设计也是一门艺术，要在不过度生成的前提下记录恰到好处的信息。未来日志的写法也将发生根本变化——因为它们不再是写给人看的，而是写给AI系统来读取和理解的。
Bogomil Balkansky：这点非常有意思——你觉得Cursor目前在编写高质量日志这方面的能力如何？
Raj：它写日志的表现挺靠谱的。它比人类做得更好。它在格式化方面做得很好——人类总是会拼写错误，我自己拼写就特别差。Cursor在这方面表现得很出色。但它仍然在模仿传统日志的格式。就像Anish提到的，你其实并不需要那么多传统格式。比如，你实际上希望尽可能多的信息都写进消息字段里，因为那才是真正表达出了发生了什么。而这样一来，当LLM读取时，它就更容易理解如何“跳转”到相关线索。但很多时候人们不愿意在日志里加太多内容，因为人类没法阅读那么长的错误堆栈追踪。
Sonya Huang：我们的上下文窗口比这些LLM还要短。
Raj：是的。
Anish：还有一点是如何跟业务逻辑建立联系。很多时候，系统工程上可能一切看起来都正常，但“正常”其实是取决于具体业务逻辑的。一个系统是否健康，往往要和业务目标相挂钩。所以，能把这两者以合适的方式通过日志连接起来，这本身就是一种艺术。而要做到这一点，对Cursor或任何其他AI系统来说都很难，除非它们对你的业务逻辑有充分理解——也许未来会实现。
Sonya Huang：当你设想未来软件工程的发展，Observability和Traversal会扮演什么样的角色？你在这期播客一开始就提到，现在没人会“vibe coding”去写一个支付系统或银行系统。那么如果Traversal构建的一切都成功了，Observability也如你预期那样发生了变革——未来那些在大型银行、支付公司、医疗机构里的工程师，真的会“vibe coding”地写程序吗？
Anish：在某种程度上是的。我们会对“这个系统是否真正完成了某种功能”有更清晰的判断方式——而这通常会以某种形式的单元测试来体现。我们在测试方面也会更强大。所以只要代码通过了某些测试，那它就是合格的，至于这段代码到底是怎么写的，其实谁也不会在意。未来软件工程的发展方向就是：更关注“是否实现了预期功能”，而不是“这段代码是怎么写的”。这当然有好的一面，但也有不好的一面。正如我们之前提到的，当系统出现故障时，往往是因为多个部分以你意想不到的方式发生了交互。很多时候系统出错，是因为你依赖的第三方服务没能满足SLA，而这类问题未来会更常见，调试起来也会更困难——因为你可能根本不知道某段代码文件里到底写了什么。这正是我们要面对的挑战，也是为什么我相信像Traversal这样的产品将发挥重要作用——因为它处理的是这些更加微妙复杂的问题。
Raj：人类的优势就在这里——目前人类大多编写自己的代码，因此他们拥有丰富的系统知识。当他们遇到故障时，可以通过已有的经验迅速排除许多路径，因为他们可能已经遇到过类似的情况，或者理解自己写的错误信息。但如果是AI生成的代码，他们就没有这种结构性的优势，那时你真的需要一个AI故障排除工具。
Sonya Huang：好的，我们接下来进入快速问答环节，大家准备好了吗？我们来一问一答的方式。Anish先来，未来12个月内，您认为哪个AI应用领域会迎来突破？
Anish：我尽量用两句话回答吧——任何能更好地利用推理模型的应用都将会脱颖而出，诊断类应用就是其中之一，尤其是医疗领域，这是一个典型的例子。
Bogomil Balkansky：有其他你敬佩的初创公司或者创始人吗？
Raj：我会说是Deis Hosabus，希望我没有把名字念错，他真是个了不起的研究员，做了很多基础性工作，并且总是致力于解决最难的问题。
Bogomil Balkansky：如果有人想了解AI，推荐哪些内容？
Anish：我最喜欢的一篇文章，你可以在五分钟内读完，是Rich Sutton的《Better Lesson》，他去年因为强化学习的工作获得了诺贝尔奖。
Bogomil Balkansky：还有其他你敬佩的AI Agent公司吗？你们是第一批真正的Agent原生公司，是否有其他类似公司？
Anish：除了像Glean这样的公司，Perplexity是其中之一，他们做得非常出色。
Bogomil Balkansky：在个人生活中你使用的最喜欢的AI应用有哪些？
Anish：说实话，我除了ChatGPT之外没怎么使用过其他的。
Raj：不幸的是，我也是一样，它现在已经成了我最好的朋友。
Sonya Huang：哇，我喜欢这个。那么最后一个问题，五年后我们还会像现在一样“vibe coding”编写银行应用、支付系统和医疗系统吗？
Anish：在某种程度上会的。
Sonya Huang：太好了，感谢今天的分享，真的很喜欢这次对话，祝贺你们在Traversal取得的成就。
Raj：谢谢。
Anish：非常感谢。
原视频：From DevOps ‘Heart Attacks’ to AI-Powered Diagnostics With Traversal’s AI Agents
https://www.youtube.com/watch?v=7hBG5ShQ2BA
编译：Li Jiahui
请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。
Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。
（文：Z Potentials）