[开场音乐]

Ryan Donovan：大家好，欢迎来到Stack Overflow播客，这里是探讨软件与技术一切话题的平台。我是主持人Ryan Donovan，今天我们将讨论AI可能无法完全替代我们完成软件开发生命周期的领域。我的嘉宾是再次做客的Spiros Xanthos。上次他作为Splunk的代表参与对话，而今天他以Resolve AI首席执行官兼创始人的身份来到节目。欢迎来到节目，Spiros。

Spiros Xanthos：你好Ryan，很高兴再次回来。感谢你的邀请。

Ryan Donovan：请和我们分享一下自从我们上次对话（大约三四年前）以来你一直在做什么。

Spiros Xanthos：是的，上次我们交谈时，我是Splunk可观测性部门的总经理。那时我们刚刚推出了完整的可观测性套件，这是一个集成了指标、追踪、日志、真实用户监控的单一产品，背后由OpenTelemetry支持。当时我们的理念是，如果你能将所有数据集中在一个地方，人类就能更好地管理生产系统——这确实没错，但现实是即使有最好的数据，大部分复杂性仍然落在人类身上。在实践中，我在管理大型工程团队的最后一份工作中看到，我们绝大部分时间——通常超过70%——都花在维护、故障排除和保持系统运行上，而不是构建新系统。这是因为软件系统的复杂性呈超线性增长，结果就是没有人能完全理解整个系统；我们拥有的工具虽然有数据，但通常任何类型的智能都需要由人类提供。这变得繁琐、有压力，需要大量艰苦工作且耗时很长。所以当我的联合创始人Mayank和我离开Splunk时，我们有一个想法：也许我们可以使用AI，构建能够完成人类工作的智能体。我们不想专注于那30%的构建工作，而是想专注于70%的运行、维护和生产软件系统故障排除工作。这就是Resolve AI的核心理念。

Ryan Donovan：那30%——我知道这是"概率"他解决了编码问题。这是你可以轻松获得统计上准确的代码生成的部分。每个人都喜欢绿地项目，但做那70%——它的范围是什么？是编码、基础设施，还是事件管理？那"不好玩"的70%的完整范围是什么？

Spiros Xanthos：它并不总是70%，对吧？有时可能是50/50，有时可能更糟。比如，我有时与拥有遗留代码库的非常大的企业交谈，他们可能从运行在云和Kubernetes上的新应用程序一直到大型机。你知道，在维护和发展这些系统所需的时间方面，这些情况往往更糟。但我想说的是，有构建时间——编码是你在那里做的主要事情——模型在能够生成越来越大的代码块方面做得非常好。我认为这会继续下去，在某种意义上，它会让其余部分变得更糟，对吧？那么其余部分是什么？其余部分是许多许多活动。比如待命和故障排除事件，本质上是管理基础设施以进行扩展和成本控制，管理你在生产中拥有的所有工具，比如可观测性工具——例如设置警报、管理它们的成本、创建仪表板。还有安全性和合规性，比如推出更改并确保它们以正确的方式落地。所以是这些事情的组合。Resolve选择专注于的，我认为可能是最困难、对人类来说也最痛苦的部分，那就是待命事件故障排除。所以我们构建了可以待命、响应警报和事件、自主进行故障排除、为你提供答案、找到根本原因的智能体，这样你基本上可以避免创建涉及多人的升级，避免影响客户导致停机，并且通常使其变得容易得多，或者让你更有信心，当出现问题时，你能够同时得到答案。我们构建系统的方式是理解生产软件的一般情况，并且能够使用所有工具，对吧？所以它适用于我描述的所有其他问题。

Ryan Donovan：事件响应压力非常大——需要低延迟。所以当你有这些AI智能体时，我会过度简化并故意说错：它有点像自动化的运维手册，对吧？故意说错的是我敢打赌还有更多内容。

Spiros Xanthos：是的。我认为如果运维手册是一种解决方案，那在10年前可能已经解决了问题，因为每个达到一定规模的公司都开始维护运维手册标准操作程序。但问题是，现代软件系统非常动态，变化非常非常频繁，有时一天10-100次。所以运维手册变得非常非常快就过时了。而且与代码不同，代码可以说是自文档化的，如果代码发生变化，它就在那里，对吧？当生产系统发生变化时，运维手册不会自动更新。所以你面临的问题是运维手册很快过时，而且问题也不会以完全相同的方式重复出现，对吧？总有一些细微的变化。这就是过去尝试的任何产品——我过去也研究过这些东西——我们之前称之为AIOps的——很难扩展的原因，因为你显然无法描述每个问题。然后如果你描述了一个问题的子集，那么我们可用的工具就无法很好地泛化，对吧？所以它们要么能捕捉到那个问题，要么不能，然后又回到人类提供直觉。所以这与那非常非常不同。

Ryan Donovan：当你和Splunk一起在这里时，我们谈到了追踪神秘的500服务器错误。根据我有限的了解，这些错误似乎相当棘手。你追踪到一个根服务，然后你会想，“好吧，这里可能失败的事情有多少？“AI如何简化或更好地追踪这些错误？

Spiros Xanthos：所以，想想Resolve AI本质上做什么，以及现代AI与智能体可能做什么，或多或少是完成人类的工作。人类如何故障排除你描述的问题，本质上是使用多种工具的组合，就像你给的例子。也许有人从日志查询开始，发现系统某部分出现一堆500错误，然后我们会深入系统的那部分。他们可能会检查仪表板，检查代码，进行更改，检查功能标志，尝试理解是否有模式变化，尝试理解是否有依赖的云服务失败。做所有这些通常需要使用许多许多工具，并在头脑中有效地组合数据——实际上就是陈述假设，尝试验证或推翻假设，随着找到更多数据，也许你会提出新的假设，对吧？越来越精确。这样做的问题是人类只能串行工作，需要很长时间，而且在实践中更糟，因为作为开发人员，我的知识可能仅限于我的服务，对吧？一旦我需要跳转到其他依赖项，我可能没有内部知识，不理解那个系统，可能不理解遥测数据……所以我需要呼叫其他人，对吧？另一个团队。这有时可能持续三四个环节，直到我们找到答案。AI能做得更好更快的是，它可以更快地并行检查所有这些事情。它可以更快地完成所有这些有压力的工作。然后，当存在一些不确定性时，它可以让人参与进来。你知道，人类必须决定采取哪条路径，或者当需要采取有风险或可逆的行动时。在这种情况下，最好的方式可能是人类提供判断并决定做什么。但实际的证据收集、假设检验、跨多个工具连接点，这些都可以通过智能体更快地完成。

Ryan Donovan：这本质上是一个数据收集和处理的工作，对吧？

Spiros Xanthos：但是，你知道，非常复杂的数据收集，对吧？智能体必须能够进行推理，基本上，对吧？给定一个症状或症状选项，它必须做出决定，对吧？这就是为什么它不是运维手册。有很多推理，对吧？就像人类查看数据时的推理方式。

Ryan Donovan：当然。所以这些显然是智能体的。它们有工具使用能力。你必须告诉它如何使用每个工具吗？你必须为每个工具进行配置吗？或者AI智能体是否能够获取新工具并弄清楚如何使用它？

Spiros Xanthos：我们处理问题的方式，以及我们发现最有效的方式是，如果智能体在一组数据上进行了预训练，或者智能体必须在一组数据上进行预训练，这么说吧，对吧？智能体必须理解代码，必须理解日志，必须理解指标，必须理解基础设施和变更。现在，有多种实现或多个工具可以给你这些数据，对吧？通常在一个客户内部就有三四个日志工具。每个都有变化，但它们都包含相同的数据，所以开箱即用，Resolve AI带有与环境中所有常见工具的第三方集成。从GitHub到可观测性工具再到云服务。你不需要做任何事，只需连接它们，智能体就知道如何使用它们。不过，我们经常遇到自定义工具——也许客户构建了自己的日志工具，或者构建了自己的变更追踪系统——在这些情况下，最简单的是：如果有MCP服务器，智能体开箱即用就知道如何使用它，对吧？因为有描述，它理解它的功能，理解参数，所有这一切。如果没有，我们有一种通过API访问的方式，但那时用户必须提供一些文档。这不难；只是需要更多工作来描述智能体应该如何访问该工具。但老实说，我在实践中发现，20%的工具通常提供80%的覆盖范围，而且你知道，对于长尾，许多更"定制"的工具已经有MCP服务器了。

Ryan Donovan：是的。我想在最初的联系邮件中，我们谈到了使用AI作为生产系统的控制平面。你能详细说明这个想法吗？

Spiros Xanthos：我们在实践中发现的是，虽然我们的目标是"构建能够使用与人类相同工具来运行生产和故障排除事件的AI智能体”，但我们发现要做好这一点，你必须既能够使用所有这些工具，又能够进行推理，并且能够学习。学习的意思是，提取存在并分散在这些工具和人类头脑中的内部知识，基本上。当你开始获取所有内部知识，并且控制所有这些人类使用的工具时，你实际上在这些低级工具之上有了这层抽象——这层智能抽象层。这允许你本质上执行大多数人类在生产中必须执行的任务，而且快得多。例如，经常有跨越多个工具的问题，可能不是故障排除；我给你一个我们工程师昨天做的例子：我们意识到我们的日志量在最近几周显著增长。所以我们的一位工程师去找Resolve，说：“你能按量给我前五个长日志行，并告诉我如何优化吗？“于是Resolve去我们的日志工具中运行查询，找出哪些"日志行"量最高，然后回去查看代码，看这些日志是从哪里产生的，然后建议如何更改代码以减少日志量。本质上，一个可能花费某人一小时或几小时的练习，在两分钟内完成，并且还给出了我们必须应用的特定代码更改来优化日志。所以，任何这种性质的任务——可能严格来说不是故障排除——都可以更快地执行，因为作为人类，你可以在比底层工具更高的抽象层次上操作。你不需要理解日志工具的查询语言。你得到需要更改代码的确切位置，或者理解代码的特定行为。

Ryan Donovan：听起来你必须做的就是能够识别问题，然后去找AI说，“嘿，这是什么？”

Spiros Xanthos：正确。我认为这就是我们今天的位置，对吧？今天，大部分情况下，我会说我们和我们的客户使用Resolve AI来识别问题，找到问题、警报或事件的根本原因，或者回答涉及所有这些工具的任何其他问题。我认为我们也在非常快地进入下一个阶段，即"好吧，既然你识别了问题，你能为我修复它吗？“所以这可以采取事件修复的形式，也可以只是"为我刚刚描述的日志量问题创建一个PR，并为我完成它。“我认为我们将很快看到这个循环闭合……“好吧，这是问题。这是修复。请处理它。“你知道，我们信任AI采取的行动集合——随着答案质量的提高，它将非常非常快地扩展。

Ryan Donovan：所以这一切都引出了人类将能够采取的行动的问题。当我第一次在一家大型科技公司工作时，我对那里的工程师数量感到惊讶——数百名工程师——听起来很多这类工作现在将由AI完成。你认为我们是在用编码让自己失业吗？

Spiros Xanthos：我认为软件工程师或站点可靠性工程师的工作已经改变了。如果你要在当今环境中成功，你实际上必须能够有效使用AI工具，因为它们创造了很多生产力增益，有效性——你可以更好地完成工作。现在，我认为同样的方式，比如我们从汇编语言转向高级语言，转向拥有为我们完成大部分工作的操作系统——我认为这没有什么不同。我不认为我们会有更少的软件工程师。只是工作会不同。在所有这些中，我认为我们将拥有更高的生产力，更高的技术产出。我们将能够用技术解决更多问题。我认为许多依赖技术的问题将变得更便宜解决。所以总的来说，我相信我们正在创造一个新的抽象层次。人类必须学会在这个高抽象层次上操作，但我不认为所有这些的最终结果会是技术领域的人更少。如果有的话，可能会更多。

Ryan Donovan：对。嗯，我的意思是，许多这些更高的抽象层次也使得软件复杂性更高。你认为AI会启用一个新的复杂性层次吗？

Spiros Xanthos：我相信会的。我认为这已经在编码中发生了，并且很快也会在生产系统中发生，这带来了更多复杂性。现在，想象一下如果你80%、90%的代码是生成的。这可能意味着你对代码的熟悉程度不如以前，因此人类故障排除AI生成的代码的事件可能会变得更难。我们可能也需要AI的协助来做这件事。这与我们从在服务器上运行应用程序到运行容器再到运行微服务的概念相同。复杂性大大增加；有更好的工具能够处理这些。我只是认为这次的跳跃更高，但概念上可能是一样的。我们谈到了这个70-30，或者无论比例是多少。我认为它正在变得更糟，因为我们已经从一个运行大型生产系统很困难的情况开始。现在很多代码也是生成的，并且以更快的速度生成，我们绝对需要AI工具来管理它们。

Ryan Donovan：我的意思是，似乎它创造了这项新技术，然后在它之上有一个容器编排层。我认为你在智能体方面也看到了这一点，但我可以看到一个世界，在智能体之上有一个编排层，试图理解现在正在生成的大量代码。

Spiros Xanthos：我同意。我们已经看到了。我们还没有合适的协议让智能体相互通信，但一个非常简单的例子是：经常——我们自己也在这样做——你可以在同一个Slack频道或Slack线程中有两个智能体，一个可以接受另一个的输出并执行一个动作。所以，我确实相信不仅仅是人类管理智能体。我认为将是智能体相互协作。显然，你知道，它们之间的一些协调，无论是来自另一个智能体还是人类。

Ryan Donovan：我的意思是，最近有A2A协议捐赠给了Linux基金会，但我没有听到太多关于它作为协议有多好的消息。

Spiros Xanthos：我认为它还没有得到我希望的采用。但我们也还在早期阶段。

Ryan Donovan：我不确定我们是否已经到了人们大量使用智能体与智能体对话的地步。我们还在摸索智能体。

Spiros Xanthos：是的。如果发生，也是以非常类似人类的方式发生的。我给你一个例子。我们已经可以做的，并且我们在Resolve使用的是，在Slack内部，智能体可能在待命，接收警报，运行所有工具，找到根本原因。所以这只是一个更改或修复。假设修复可能是一个代码更改。很容易将其作为提示，即使在线程内，说"好吧，现在调用一个编码智能体去创建一个PR来修复这个问题，基于Resolve AI提供的非常详细的、有效的提示。“所以，我们看到像这样的用例，但它不是完全自动化的。更多是一个智能体的输出成为另一个智能体的输入。

Ryan Donovan：运行一个智能体SRE的计算要求是什么？

Spiros Xanthos：你需要对智能体、公司及其背后的人拥有的信心水平，可能比处理编码智能体时更高，因为对于一个有效的智能体SRE，它需要连接到人类可以访问的大多数工具。通常是代码；是遥测基础设施。所以在这个意义上，安全要求、信任和合规性更高，但一旦连接到所有这些工具，它也非常强大，因为它不仅可以在一种数据类型上采取行动，而且可以结合来自多个这些工具的知识、信息、可能还有洞察力，并将它们链接成一个答案。

Ryan Donovan：SRE角色在计算领域相当新，大约15年或更短。你认为有了AI，它还会必要吗？因为即使在AI之前，我也听过一些人说，比如，开发人员应该管理代码到生产，甚至不应该有SRE或DevOps。

Spiros Xanthos：首先，如果你看我们的行业，不同公司实现这一点的方式有很多很多变化。有些情况下你没有多个角色——你可能有软件工程师，他们既待命，又管理平台基础设施，管理云上的服务，他们也是软件工程师。话虽如此，实际上他们做的是身兼多职，对吧？当你试图管理一些基础设施服务、平台、容器或进行故障排除与编写代码时，工作略有不同。需要完成的任务或工作就在那里，无论你是否将它们分成多个人，可能是另一个问题。还有，你也有变化，比如你可能嵌入SRE作为事件发生时的第一道防线，或者他们可能管理基础设施。也许你还有专门的平台和SRE团队负责基础设施，而开发人员通常负责应用程序。所以无论如何，我不认为需要完成的工作正在改变。只是你可能让专门的人员担任SRE或基础设施工程师的角色，或者你可能没有，但工作仍然必须完成。比如，在AI SRE中，实际上你能做的，以及我们看到许多用户能够更有效做的——或者许多软件工程师——是更好地自助服务，对吧？当出现问题时，他们不一定需要呼叫理解基础设施的人。他们可以自己理解这是应用程序问题还是基础设施问题，如果问题进入他们不是专家的系统部分，智能体可以帮助他们找到答案。

Ryan Donovan：关于填补那些仍然由人类完成的工作——我知道有很多关于找工作的焦虑。据传闻，我听说市场很艰难，但找到能够胜任人类工作的合适人选仍然很重要。我知道你有一些关于在这个时代如何找到好人才的技巧。

Spiros Xanthos：事实是，我确实相信市场现在有点艰难，你可能在经验不足或刚从大学毕业的人身上看到更多这种情况。我认为那里可能是最难找到工作的地方。我希望这能改变，但在我看来，这是更广泛的经济问题。更多是关于AI。只是当前的经济状况。话虽如此，优秀的工程师总是有很多选择，你越优秀，选择就越多。这就是现状。在我看来，除非你有优秀的人才，否则你无法建立一家伟大的公司，句号。所以，作为创始人，我花了绝大部分时间，或者说到目前为止花了绝大部分时间，试图说服聪明或比我更聪明的人加入我们，并拥有公司某个领域的所有权，并比我更好地解决它。初创公司必须提供，尤其是在竞争更激烈的AI领域，是大量的成长、大量的所有权、快速移动的能力、解决以前从未解决过的非常非常困难的问题的能力，这些可能是大公司甚至实验室无法提供给你的。所以，我不认为初创公司适合每个人，但对于那些能够承受风险、希望拥有大量所有权、能够快速移动的人来说，它是一个神奇的地方，尤其是一家有吸引力并解决他们问题的公司。当然，我试图在技术技能和文化契合度方面设定非常高的标准，但我也认为有独特的优势，如果某人有这种倾向或个性，初创公司对他们来说是更好的地方。

Ryan Donovan：我看到的很多焦虑来自初级开发人员。我知道你说现在对他们来说市场很艰难。你对初级开发人员如何向潜在雇主展示他们的才能有什么想法吗？

Spiros Xanthos：我认为这与以前没有太大不同，因为一个人拥有的经验例子越多，就越容易，无论是实习还是他们从事过开源工作，或者甚至在大学期间做了很多编程或技术工作，能够去面试并证明他们与那些没有真正在行业工作过的人一样跟上了进度。我看到的另一件事是，并不是没有很多招聘，只是比以前少了很多。所以，除了拥有所有正确的技术技能外，可能还需要更多的主动性。不仅仅是申请工作，而是尝试找到你认识的人工作的地方，对吧？或者尝试获得一个热情的介绍。与以往相比可能没有太大不同，只是你可能需要做更多这样的事。我这次整个讨论的总体信息是，我确实相信所有软件工程师和SRE的工作已经改变，尽管如此，我认为我们正处于正在发生的这场革命的开端。我自己过去两年与AI合作的经验是，模型在以稳定的速度进化，如果不是加速的话。智能体可能甚至落后于模型，但它们也在快速移动。我确实相信，随着推理和答案质量的提高，我们将看到智能体自动采取更多行动。所以，如果我对所有这些的结论是，现在更重要的是投身于此，无论你是一个关心自己职业生涯的个人，还是一个公司的CTO并考虑AI采用，我认为我们有更多的空间。它来了。它没有放缓。

Ryan Donovan：女士们先生们，现在是节目的时间，我们向那些来到Stack Overflow、给出精彩答案、分享一些知识或分享一些好奇心的人致敬，今天我们向一个杰出答案徽章的获得者致敬。祝贺’larsks’回答了：“如何进入Docker容器的shell？“如果你好奇，我们会在节目笔记中为你提供。我是Ryan Donovan。我编辑博客，在Stack Overflow主持这个播客。如果你有评论、关切或要讨论的话题，请发邮件到podcast@stackoverflow.com。如果你想直接联系我，你可以在LinkedIn上找到我。

Spiros Xanthos：我是Spiros Xanthos，Resolve AI的创始人兼首席执行官。Resolve AI如我们所述，正在构建AI智能体，以帮助故障排除警报和事件，并运行生产系统。你可以在resolve.ai找到我们，你可以直接联系我。我的邮箱是我的名字@resolve.ai。

Ryan Donovan：邮箱是开放的。感谢大家收听，我们下次再聊。