你知道的，我认为理想化的工作愿景与实际工作之间总是存在差距。是的。我认为每个职业都是如此。你会理想化，孩子们做得最极致，对吧，当他们说想成为消防员和宇航员时，想象那份工作是什么样子。然后然后你进入那份工作，你意识到，哦，这份工作中实际上有很多我不喜欢的东西。演讲者1 | 00:19 - 00:26 我们想做那个真正弥合你想象的工作与你实际工作之间差距的工具。演讲者2 | 00:43 - 00:47 好的。我和杰克在一起，Serval的创始人兼CEO。杰克，欢迎来到节目。演讲者1 | 00:47 - 00:48 非常感谢。很高兴来到这里。演讲者2 | 00:48 - 01:00 好的。我们从一个高层次的问题开始。你们正在构建新一代的ServiceNow，可以说是AI原生的ServiceNow。没错。为什么世界需要一个AI原生的ServiceNow？演讲者1 | 01:01 - 01:20 是的，员工在工作场所需要帮助。这就是我们的核心理念——我们是一个员工支持平台。技术术语是企业服务管理，但真正含义是在工作中获得帮助。获得帮助的理想方式是，你提出请求，立即自动获得帮助。你不需要等待某人追踪工单并将其分配给某人。演讲者1 | 01:20 - 01:33 你立即获得帮助。这需要某种自动化支持，而这种自动化最好用AI构建。所以我们从第一性原理思考。我们如何支持员工？你自动化所有请求。演讲者1 | 01:33 - 01:38 你如何自动化所有这些请求？AI确实是将这些自动化带给员工的好工具。演讲者2 | 01:38 - 02:06 太棒了。让我们详细谈谈。我记得很久以前，当我们第一次见到ServiceNow创始人弗雷德·卢迪时，大约在2007、2008年左右。那时候，人们认为ServiceNow很棒，因为它相较于Peregrine和Remedy有了一个大的阶跃变化。他们做对的关键是把企业软件看作一个抽象——就是工作流在数据库之上，对吧？演讲者2 | 02:06 - 02:32 所以他们在数据库之上构建了这个灵活的工作流配置引擎。那时候这很棒，IT人员喜欢它，他们开始飞速发展。我听你说的意思是这还不够。有了AI，有一种新一代的自动化可以做。能否详细谈谈ServiceNow构建的东西和你们构建的东西，以及并排比较，这次真正不同的东西是什么？演讲者1 | 02:32 - 02:58 他们做对了。我们也构建了工作流在数据库之上，这是正确的抽象。那些是正确的原语。他们工作流和数据库的问题是需要大量的手动工作来构建和维护，所以构建那些工作流通常需要专门的开发资源来完成。虽然这听起来不错，你投入那些资源，最终得到一个漂亮的自动化，但这可能需要数周甚至数月。演讲者1 | 02:59 - 03:26 在业务流程快速变化的时代，当你得到那个工作流实现时，你的业务流程可能已经改变并转移了，你需要不同的工作流。所以你的自动化有点落后于你想要的位置。现在这比以往任何时候都更真实。数据库也是如此。如果你需要手动更新那些条目，查看你的IT资产，确保它们在这些系统中是最新的，那将非常痛苦，你需要引入顾问或内部开发人员来更新。演讲者1 | 03:26 - 03:57 我们采取了独特的方法，让我们保留那些原语——工作流在数据库之上——但允许你使用AI来构建工作流，使用AI来更新数据库。我们这样做的方式是这个代码生成引擎，你描述你想要的工作流，所有不同的步骤、权限、审批和逻辑。我们把你的自然语言描述转换成代码。所以你的工作流立即出现。开发这些工作流的时间几乎为零。同样的事情也适用于我们的数据库。演讲者1 | 03:57 - 04:08 你可以准确地描述你想从哪些源获取哪些数据，我们的系统将实际生成代码来获取那些数据并保持其更新，而不需要你做任何手动干预。演讲者2 | 04:08 - 04:27 我记得你说过，几个月前，当我们第一次认识时，你说的一件事真的引起了我的兴趣，大概意思是，如果你真的想推动企业自动化，你必须使构建自动化的过程与被自动化的工作流一样简单，如果不能更简单的话。演讲者1 | 04:27 - 04:28 完全正确。演讲者2 | 04:28 - 04:30 你还相信这个吗？这仍然正确吗？演讲者1 | 04:30 - 05:00 我仍然相信这个，这个洞察来自设身处地为IT或其他部门的人着想，他们面临一个任务，某人要求他们重置密码，你有两个选择。你可以去Google Workspace，找到用户，点击重置密码按钮。或者你可以打开工作流构建器，拖动触发器、响应，然后构建这个自定义工作流。当你面临那个选择时，你只会重置密码。你会做那个手动的事情。演讲者1 | 05:00 - 05:13 但是如果实际上构建自动化更容易，你会构建自动化，因为为什么不呢？我认为这归结为这一点。人们在那一刻必须做出决定，你希望那个决定非常非常容易选择自动化，而不是选择手动步骤。演讲者2 | 05:13 - 05:24 现在，有没有太简单以至于不适合自动化的事情？比如，人们谈论氛围编码和所有的糟粕，是否存在糟粕自动化？演讲者1 | 05:25 - 05:42 是的。它是真实存在的，我们必须围绕那个构建一些非常有趣的东西，因为，是的，当你让自动化变得如此容易时，某人可能本周构建了第二十个密码重置工作流。是的。它基本上和之前19个一样，现在你有了所有这些重复的工作流，AI会混淆应该运行哪一个。演讲者2 | 05:42 - 05:43 是的，你们如何处理那个？演讲者1 | 05:43 - 06:17 我们基本上在Serval之上构建了一个新的智能体，我们对此非常兴奋，它具有你曾经构建的所有工作流的完整上下文感知，它们如何工作，它们将要做什么。所以当你说，嘿，我想要这个做X、Y和Z的工作流，它说，嘿，实际上，你已经有19个做那个的了。我可以修改其中一个，但这是我认为你应该做的。我认为你应该删除其中10个，把剩下的9个分成这些不同的类别，添加这些审批步骤，所以它实际上引导你完成系统，是你在我们产品方面的专家助手，帮助你将业务需求转化为实际的产品实现。演讲者2 | 06:17 - 06:43 说到产品，你是一个产品人，我们从每个可能的来源一致听说你非常以客户为中心，真的善于倾听客户并弄清楚他们需要什么。你有一个指导性指标可以告诉你产品正在变得更好更有用，还是更多你收集所有轶事，综合它们，你有一个直觉？有没有一个数字你可以看？演讲者1 | 06:43 - 06:53 我认为后者。像，我尝试与客户紧密嵌入。完全沉浸，我在每个客户Slack频道里。是的。我想我们大多数客户每天都会在该频道收到我的Slack。演讲者1 | 06:53 - 06:56 哇。这是一个巨大的，也许——演讲者2 | 06:56 - 07:01 只是设置一下背景，听众可能会认为，你大概有四个客户吧。你有多少客户？演讲者1 | 07:01 - 07:13 不，超过100个客户。好的。还有很多大企业。在所有这些对话中一直保持那种状态有时是势不可挡的。有时我觉得，哦，伙计，我是不是在浪费时间？演讲者1 | 07:13 - 07:42 但我觉得我真的理解什么进展顺利，什么不顺利。我只是触及了脉搏。特别是当很多实施工作已经变得非常快速。任何初创公司更多的护城河是客户洞察，实际理解他们想要什么的同理心。如果我们在客户洞察方面有差异化优势，那将比为产品优势更有价值，因为产品优势可以在一夜之间被复制。演讲者2 | 07:42 - 08:13 让我们多谈谈那个，因为这已经是几年的热门话题。你知道，ChatGPT在2022年11月推出，人们立即开始贬低应用层公司为底层模型的包装器。对吧？你刚才说的有点像这个主题——总有一派观点说，底层模型将做所有事情。然后有一派观点说，当然，但你可以在上面构建一个公司来弥合原始能力与实际客户问题之间的差距。你如何看待你作为应用层公司运行者的角色与底层模型的角色的关系？你认为你的业务护城河随着时间如何形成？基本上，对于有兴趣的人来说，你如何在这个时代构建一个应用层公司？你的想法是什么？演讲者1 | 08:33 - 08:48 我认为当新模型推出时你必须感到高兴，这是我们的指导原则，即我们如何确保我们正在构建的东西实际上不会因为实验室和超大规模厂商推出的东西而过时，而是实际上变得更好？演讲者2 | 08:48 - 08:50 有什么好的例子？演讲者1 | 08:50 - 09:10 对我们来说，我们认为产品就是边界。产品就是控制。产品实际上限制了模型的能力。因为现在的问题不是Opus、GPT 5.5能否做这些惊人的事情，它们能否在我企业环境中做我想做的事情？能力实际上是无穷无尽的。演讲者1 | 09:10 - 09:57 现在的限制是我如何作为一个关心安全并在公司范围内部署的大型企业感到舒适，而不增加我的安全风险？所以我们从边界角度思考，这意味着非常无聊、老派的企业软件的东西——权限和审批、限制API集成的范围、对此的可视性、审计和报告、日志和警报，以及所有让你在让模型在你的环境中疯狂运行时感到舒适的东西。是的。从架构角度来看，我们做的一个根本性的事情是把智能体分成两部分。所以我们的客户，当他们体验Serval时，实际上与他们合作的有两个智能体。演讲者1 | 09:57 - 10:33 一个是管理员智能体，帮助构建所有这些工具和技能，配置服务台、哪些事情服务台智能体可以做以及它知道什么。所以是管理员构建那个。然后有服务台智能体，最终用户与之交谈来解决他们的问题。服务台智能体只能使用由管理员明确构建、发布并经过审批和权限的工具。是的。这和那些可能附带的审批一样，权限限制某些用户不能做某些事情。所有这些都在管理员端完成，但然后你得到服务台智能体使用那些工具的完全能力和智能。演讲者2 | 10:58 - 11:04 引擎盖下是什么？有没有什么可以说的关于你们使用哪些模型以及这可能如何随时间演变？演讲者1 | 11:05 - 11:54 是的，我们今天使用OpenAI、Anthropic模型，总是在试验来自所有提供商的最新模型以确保我们处于前沿，在我们做的一切上运行评估套件。今天，主要是OpenAI、Anthropic模型。我们发现不同模型在不同应用中更好。所以在最终用户交互方面，我们看到OpenAI模型最成功，这已经保持一致了相当长的时间，调用正确工具并以适当方式响应用户，这仍然是我们使用各种GPT模型取得很多成功的地方，并总是根据最新发布保持这些更新。但在自动化方面，主要是代码生成自动化，我们与Anthropic模型最成功。演讲者1 | 11:54 - 12:14 所以继续使用那些，Sonnet、Opus。在不同模型之间有很多权衡，最近有趣的是新发布通常不仅仅是即插即用的。有时候你得到一些优势，一些以前工作得很好的东西不再那么好了，所以随着事情的发展，这成了一个有趣的挑战。演讲者2 | 12:14 - 12:26 实际上，是的，你们如何处理那个？比如，将新模型纳入产品生产版本需要多长时间？那个过程有多少是某种方式自动化的？有多少只是某人必须坐下来弄清楚？比如，你如何处理那个？演讲者1 | 12:27 - 12:56 它没有我想要的那么自动化。我们有评估是自动化的，但在每种情况下，当我们有一个新模型要测试时，一些事情变得更好，一些事情变得更差。很多变得更差的事情，不一定是模型变差了，而是我们为该模型的已知怪癖或行为构建了很多提示调整和很多基础设施。当新模型出来时或你交换模型时，那些变得不那么有意义了。所以这是很多调整必须做的地方。演讲者1 | 12:56 - 13:31 然后你通过评估，你做一个跨客户的较慢发布。所以我们在这方面越来越好，但我认为在某些情况下权衡不值得，我们实际上升级了模型然后降级了模型并说，你知道吗？旧模型可能稍微快一点。或者它们在某种程度上可靠，而新模型可能不是，所以也许新模型稍微更智能，但它们的行为不太可预测，我们有不太可预测的防护栏来防止那种情况。所以我们说，嘿，这个模型可能不那么智能，但我们知道它会……