[开场音乐]

Ryan Donovan: 大家好，欢迎来到Stack Overflow播客，这是一个讨论所有软件和技术话题的地方。我是主持人Ryan Donovan，今天我们要讨论的是AI可能无法完全替代我们完成软件开发生命周期的领域。我的嘉宾是一位返场嘉宾，Spiros Xanthos。之前他作为Splunk的代表参与过我们的对话，而今天他则是以Resolve AI的CEO和创始人身份来到节目。欢迎来到节目，Spiros。

Spiros Xanthos: 嗨，Ryan。很高兴再次回来。谢谢邀请我。

Ryan Donovan: 那么，跟我们聊聊自从我们上次对话以来这三四年你都在忙些什么吧。

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

Ryan Donovan: 那30%的部分，我知道是AI已经解决的编码问题。这部分你可以通过统计上准确的代码生成轻松实现。每个人都喜欢新项目，但处理那70%——它的范围是什么？是编码、基础设施，还是事件管理？那70%不有趣的工作具体包括哪些？

Spiros Xanthos: 并不总是70%，对吧？有时可能是50/50，有时甚至更糟。比如，我有时会和拥有遗留代码库的大型企业交流，他们的系统可能从运行在云和Kubernetes上的新应用一直到大型机。这些系统在维护和演进上花费的时间往往更糟。但我的观点是，构建时间中编码是主要活动，模型在生成越来越大的代码块方面做得非常好。我认为这会继续发展，从某种意义上说，这会让剩下的部分变得更糟。剩下的部分包括许多活动：比如值班和故障排除事件、管理基础设施以进行扩展和成本控制、管理生产环境中的所有工具（例如可观测性工具）——设置警报、管理成本、创建仪表板。还有安全与合规、推出变更并确保它们正确落地。所以，这是这些活动的组合。Resolve选择专注于可能最困难、对人类也最痛苦的部分：值班事件故障排除。我们构建的代理可以值班、响应警报和事件、自主进行故障排除、找到答案和根本原因，从而避免多人升级、避免影响客户和中断，总体上让事情变得更简单，或者让你更有信心在出现问题时能迅速得到答案。我们构建系统的方式是理解生产软件的整体情况，能够使用所有工具，因此它适用于我描述的所有其他问题。

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

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

Ryan Donovan: 当你和Splunk一起来这里时，我们谈到了追踪神秘的500服务器错误。据我观察，这些问题似乎很棘手。你追踪到根服务，然后想“这里可能出问题的地方有多少？”AI如何简化或更好地追踪这些问题？

Spiros Xanthos: 可以这样想，Resolve AI和现代AI代理所能做的，基本上就是替代人类的工作。人类如何故障排除你描述的问题？他们基本上结合使用多种工具，比如你给的例子。可能有人从日志查询开始，发现系统某部分出现一堆500错误，然后深入查看该部分。他们可能检查仪表板、代码、进行更改、检查功能标志、尝试理解是否有模式变化、或者是否有依赖的云服务失败。所有这些通常需要使用许多工具，并在脑海中有效结合数据——实际上就是提出假设，尝试验证或推翻假设，随着找到更多数据，可能提出新的、更精细的假设。问题在于人类只能串行工作，花费很长时间，而且实践中更糟，因为作为开发者的知识可能仅限于自己的服务；一旦需要跳转到其他依赖，我可能没有内部知识，不理解系统，不理解遥测数据……所以我需要呼叫其他人，另一个团队。有时这可能持续三四个回合才能找到答案。AI能做得更好、更快的是，它可以更快速、并行地检查所有这些事情，并能更快地完成这些压力大的工作。然后，在存在不确定性时，它可以引入人类，比如当需要决定采取哪条路径，或者当需要采取有风险或不可逆的行动时，最好由人类提供判断并决定做什么。但实际的证据收集、假设测试、跨多个工具连接点的工作，代理可以更快完成。

Ryan Donovan: 这本质上是一个数据收集和处理的过程，对吧？

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

Ryan Donovan: 当然。所以这些显然是代理式的。它们有工具使用能力。你需要告诉它如何使用每个工具吗？你需要为每个工具进行 onboarding吗？还是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频道或线程中有两个代理，一个可以拿另一个的输出执行操作。所以，我相信不仅仅是人类管理代理，代理之间也会协作。显然，它们之间需要某种编排，无论是来自另一个代理还是人类。

Ryan Donovan: 我的意思是，最近有A2A协议捐赠给Linux基金会，但我没怎么听说它作为协议有多好。

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

Ryan Donovan: 我不确定我们已经到了人们大量使用代理与代理对话的阶段。我们还在摸索代理。

Spiros Xanthos: 是的。如果发生，也是以非常人类化的方式发生。我举个例子。我们已经能做并且在使用的是，在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、给出精彩答案、分享知识或好奇心的人致敬，今天我们向 stellar answer badge 的获奖者致敬。恭喜“larsks”回答了：“如何进入Docker容器的shell？”如果你好奇，我们会在节目笔记中提供。我是Ryan Donovan，Stack Overflow的博客编辑和播客主持人。如果你有评论、关切或想讨论的话题，请发邮件到podcast@stackoverflow.com。如果你想直接联系我，可以在LinkedIn上找到我。

Spiros Xanthos: 我是Spiros Xanthos，Resolve AI的创始人和CEO。Resolve AI如我们所述，正在构建AI代理来帮助故障排除警报和事件，并运行生产系统。你可以在resolve.ai找到我们，也可以直接联系我。我的邮箱是我的名字@resolve.ai。

Ryan Donovan: 邮箱开放。谢谢大家收听，我们下次再聊。

订阅播客 在您喜欢的收听服务上获取The Stack Overflow Podcast。

• Apple Podcasts
• Overcast
• Pocket Casts
• Spotify
• RSS feed