[开场音乐]

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%。我知道那是"概率"他解决了编码问题。这是你可以轻松获得统计上准确的代码生成的部分。每个人都喜欢绿地项目，但做那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: 当然。所以，这些显然是代理式的。它们有工具使用能力。你必须告诉它如何使用每个工具吗？你必须为每个工具进行引导吗？或者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。我编辑博客，在这里主持播客。如果你有评论、担忧、要涵盖的主题，请发邮件到podcast@stackoverflow.com。如果你想直接联系我，你可以在LinkedIn上找到我。

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

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