挑战 ServiceNow：让更多人都能用上的代码代理——与 Serval 联合创始人兼 CEO Jake Stauch 对谈

这就是企业软件领域终极的登月式挑战：让这些代理自行行动、替你工作，神奇地发现所有问题并把它们解决掉。我觉得还没有人真正弄清楚如何把这件事做好。这有点像 OpenAI、Hugging Face 等公司遇到的事件：给代理一个任务，它却做出了意料之外的事。代理能力变强后，理论上可能开始编写能在你的系统上采取行动的代码，这会带来没有边界的安全风险。我不认为近期有人能解决它。一方面，你希望代理足够自主，不需要人一直盯着；另一方面，在企业里，自主性又非常可怕。Serval 就是那道边界，是护栏。我们让有大量规则、审批、流程和内部政治的大型企业能够安全、放心地大规模采用这些工具。

很高兴来到这里。

简单介绍一下，Serval 做的是企业自动化和企业服务管理。我们的设想是，人们可以在工作中提问、获得帮助，并把工作中许多自己不喜欢的部分自动化，我们用代码生成代理来实现。公司主要做的就是这个。我们和 ServiceNow 这样的公司竞争，它是这个领域历史悠久的大型传统供应商。我是在上一家公司 Verkada 工作时发现这个品类的。当时我们向 IT 团队销售企业级实体安全产品。我花了很多年和 IT 团队交流，弄清楚该为他们做什么。我很喜欢问他们：“你们在哪方面花钱最多？最讨厌什么？”ServiceNow 常常排在那些清单的前列。我一直觉得这个领域或许有更好的解决方案，但在我任职的大部分时间里，还看不出怎么才能打败 ServiceNow。他们是一家很出色的公司，做成了很多事，为什么我们能和他们竞争呢？

我想，问题是很难在这个平台上构建东西。它是一个非常稳健、可定制、功能强大的平台，能够映射各种企业工作流。归根结底，它是工作流自动化平台，所以能做很多事；但你每有一个不错的想法，都得自己去实现，很多时候还得找顾问来做。因此它总是比你期望的进度慢 6 到 12 个月。如果要做的是一个能用 5 年、10 年的大型入职流程，而且业务不会变，投入前期成本，部署后运行一段时间也没问题。但如果你想跟上所有希望构建的自动化，ServiceNow 就跟不上。它还很贵，而且会越来越贵。用户的许多不满，正是因为它跟不上业务想前进的步伐，成本又不断增加。

……这就是许多用户不满的原因：它跟不上业务想前进的步伐，价格还越来越高。

是的，所有内部事务。

我们很喜欢“为其他所有人打造的代码代理”这个想法。企业早期采用 AI 的大部分工作都发生在工程团队里。原因有很多，当然，工程师通常是各种新技术的早期采用者；但他们也能够构建并试用这些工具，因为有代码审查流程。即使是 19 岁的实习生，也可以做出非常强大的东西，再经过审查流程才进入生产环境，这很安全。我们希望把同样的能力带给企业里的其他人。我们打造了一个平台，把代码代理带进 IT 部门，再由 IT 推广给人力资源、财务、人事和法务团队。

我觉得它们对消费者、小型企业，甚至许多中型企业都很有用。但在大型企业里，审批流程和行为规范非常多。我一开始也没充分意识到这一点：每个人能做什么、不能做什么，都有很多流程；个人权限集又非常有限。即便公司允许你把自己的代理带到工作中（很多情况下并不允许），它能做的也极为有限，几乎连你的邮件都读不了。

是的，完全如此。这里的差距显然在于技术普及。技术能做很多事，而企业对可能性的探索才刚刚开始。很多工作在于理解人员、流程、现有工作流，以及未来希望它们变成什么样；我们认为这仍然需要人来做。所以我们会派部署策略师（这是我们的称呼）和一位现场部署软件工程师到客户那里，弄清楚如何实施、如何解决企业遇到的各种问题，然后带着客户走完整个实施过程。

两年半。

我常开玩笑说，一切都完全按我们那套非常不切实际的计划进行。我们从一开始就想成为史上最大的企业软件公司。我们列出所有公司，圈出 ServiceNow，说我们要打败他们，做出规模大得多的东西。第一天，在我联合创始人 Alex 的客厅里，当时只有两个人，我们就这么说了。这个目标听起来疯狂，但从来就是我们的初衷；我们不是后来才逐渐有了这个野心，而是从一开始就奔着它去的。

对。企业初创公司通常有两种做法：做一层软件，或转向更低端市场。第一种是做一个小层，和大公司和平共处，比如在它们现有工作之上加一个 AI 代理。这样很容易限制发展；我能想到的成功案例可能只有 Vevo 之类，它最初基于 Salesforce，后来迁移成自己的平台。要反向整合非常难，除非你找到一个细分市场之后再扩展。

没错。

对。我们看了这些路径后就想，为什么不直接挑战最大的那家？这当然更难，但如果赢了，回报也足够大。我认为这对我们非常重要，因为从第一天就面向大型企业，会让你做出许多不同的决定：产品怎么设计、团队怎么组建、如何看待增长，都和先服务一个市场、以后再扩张有根本区别。

我们并不真正清楚怎样打败其他公司，也不知道自己的优势是什么，更不知道 AI 带来了什么样的突破、让它们无法追上。凭着我们对 IT 的了解，我们明白 ServiceNow 本质上是一个工作流自动化平台。

是的，所以……实际上我们开始构建这个东西时——

我们押注代码代理会变得非常好用。背后的理论是，编程是一个可验证的领域，模型应该能通过持续迭代不断提升。因此我们从根本上相信代码代理至少能做好某些任务。我没料到它们在通用软件开发方面也能变得这么强，但像重置密码、获取审批这样的确定性流程脚本，定义非常清楚、结果也能验证，我们觉得模型会擅长这些任务。

我们非常期待它们进步，因为这能解锁许多我们希望实现的功能，比如更好的浏览器和电脑操作，以及更多后台代理、个人代理，让它们在企业里真正有用。我们一直相信，我们不自己构建大语言模型；我们构建的是护栏和边界。对我们来说，边界就是产品，因为有了我们，大型企业才能在繁杂规则、审批、流程和内部政治之下，安全、放心地大规模采用这些工具。Serval 就是边界，就是护栏。模型智能提升只会让我们的产品更强大，也会让客户希望进一步收紧边界和护栏。

因为想想看：我也许可以放心地给你一些超出你实际需要的权限，因为我觉得你不会造成太大破坏。但如果你还能使用各种代理，那么哪怕权限只比普通水平高一点，可能造成的破坏也会扩大。我们现在已经能在网络安全风险上看到这一点。

所以，作为大型企业，我实际上会想把每个人的权限缩减到真正的最小权限：除非工作绝对需要，否则不能访问任何文档，也不能采取任何行动。但例外总会不断出现。我们就是负责授予这些例外的那一层，让你能为它们设置审批流程，关联审计轨迹和工单。我们掌控企业里的权限提升方式，因此企业越收紧终端用户权限，我们就越重要、越有力量。

我们必须让自己和客户相信，Serval 是让你在工作中获得晋升的途径。客户采用 Serval 不能只是冒个险，希望之后得到回报；我们得让他们相信，做了这件事不仅不会惹上麻烦，还会成就你的职业生涯，甚至让你获得晋升。

是自上而下的。我们向高管团队销售，很多时候是向 IT 领导层销售，再推广到其他部门。我们的信息是：人们过去靠 ServiceNow 建立职业生涯，而你会靠这一代产品建立自己的职业生涯。我们正看到这种情况发生。最大的客户之一是 Fox。Fox Corporation 在全公司采用 Serval，负责在一线推动迁移的人，后来被提名为全公司的 MVP。

他还因为这项工作获了奖。这正是我们要做的：告诉客户，这不只是证明你对组织有用，而是证明你可能是公司里最不可或缺的人，因为你在引领这场变革。我们在 AI 转型中极为关键，我认为这也是一种很好的销售方式。

消费领域常常是企业接下来会发生什么的一个窗口，虽然两者并不总是一样。我非常看好个人代理在企业里的形态。电子邮件、Slack 等工具改变了我们的工作沟通方式，我认为个人代理也会成为其中的重要部分。每个人都会有自己的个人代理，替自己执行任务、再把任务委托给其他个人代理。你的代理会和同事的代理交流。我很期待这一点。

我觉得会。我想，就像我有 Gmail，也有公司邮箱一样。

我认为最重要的一点是软件开发生命周期。工程领域里我们习以为常：有开发环境、暂存环境、生产环境，它们之间有各种关卡；还可以用分支开发，不会破坏其他系统。

有些情况是这样，但我认为大多数新的 AI 产品没有采用这种做法。它们基本上是在说：“来构建这些很酷的代理，然后直接发布到生产环境。”但大型企业、尤其大型金融机构，需要遵循软件开发生命周期；不能在没有审查、用户验收测试和其他检查的情况下，就发布新的代理能力。

没错。所以我们一直在思考，怎样才能让世界上最大的公司采用这项技术，而不只是做出强大、很酷、我们很想交到客户手中的东西。

我觉得有些公司最终也做不到。它们看到企业软件需要付出的代价，就决定自己不想构建这些东西。回头看前面提到的许多转向低端市场的公司，有时它们确实看到了进入企业市场的机会，但这要求完全不同的一套构建原则，也要构建不同的产品，有些公司就是不愿意这么做，于是把这块市场让给了别人。我们选择说：“把最棘手的问题交给我，我们会解决，让你在这个充满风险和治理顾虑的世界里实现 AI 转型。”

部署软件时很重要的一点是，我们从不构建定制功能，也不开发客户专属的产品能力。幸运的是，在我们的领域里没人要求我们这么做。客户提出的需求，最终其他客户也都会需要。它们可能会影响优先级，但本来就是我们希望加入平台的东西。

……这让我们可以试探哪些应该成为真正的一等功能，哪些应该继续以 Serval 自动化的形式存在。

我们还在观察。我确实看到 CIO 客户试图从最初那种不计 token 用量的阶段退回来，但我也觉得我们还处在采用曲线的非常早期，所以整体上不会收缩，支出反而会继续大幅增长，因为大多数公司才刚开始摸索这件事。

我接触过的公司里，尝试在内部编写代码、构建这些工具的，特别是系统记录的核心工具，而不是一些单点解决方案，都发现企业软件的构建和维护成本相当高。即使能做，在许多情况下也不符合经济效益，除非你的需求非常特别、独一无二。对于不是核心能力的东西，购买现成产品一直都是“自建还是购买”的问题；现在仍然和过去一样。企业软件依然难以构建。很多公司正在发现，或者重新认识到，企业软件很复杂，而且需要人来维护。

边缘情况就是系统会出问题，需要人更新。于是你得配备团队、支付人力成本，而且很多时候没人愿意去内部工具团队工作。所以自建会遇到这一大堆问题。

没错，我认为确实会出现整合。因此会有一场“SaaS 末日”，但主要影响的是那些单点解决方案、规模较小的公司。我不认为核心系统记录会真正消失，比如 ERP、HRIS、ITSM、CRM。它们会继续存在，只是可能转型。我们用 Serval 正在替代这些工具。所以我认为会出现新一代的在位厂商，但这些品类不会就这样消失。

IT 很有意思，因为他们其实比很多人想象的更接近软件工程师。特别是在大型企业，很多情况下 IT 部门就是工程团队。他们没有软件工程团队，所以 IT 负责运行所有这些系统，也经常编写代码并管理系统。

我认为每家公司在构建第一代 AI 工具时都发现了一件事：你可以打造非常强大、复杂的系统，但之后还得培训用户，让他们理解产品的各种基本构件，以及这些系统如何组合。因此第一代做法是派许多全职员工去给客户讲解：“平台该怎么用？要不我直接替你搭好吧。”后来我们发现，如果客户能直接和一个理解他们需求、并能把需求转化为产品构件的代理对话，那就太好了。

完全正确。旧一代自动化产品面临一个“白纸”问题：我知道想把工作中的很多事情自动化，但到底从哪里开始？像我们这样的产品会先问你想从哪里开始，然后提出建议。你可以和代理反复讨论，说：“我其实不明白这是什么意思，你想表达什么？能解释一下吗？我想做这件事，该怎么做？”它们可以提供和检索信息，向你解释概念。

我总是这样向企业描述后台代理：它们是企业软件领域终极的登月式挑战。让代理自行行动、替你工作，神奇地发现所有问题并把它们解决掉。如果能部署并且让它按权限运行，那就太棒了。我觉得还没人真正弄清楚怎么把它做好，因为一方面，你希望代理足够自主，能自己调查并解决问题，不用人一直盯着；另一方面，在企业里，自主性非常可怕。你需要确切知道它们能读什么。这有点像……

正是如此。对于我最优秀的员工，我会怎么做？给他们一个高层次的任务，让他们自己去做，别来找我，然后他们回来时已经做成了很棒的事。我也希望能够信任代理这么做：给它一个高层次任务，让它解决问题后回来。但我认为我们还没找到一种让企业觉得安全的方式。

我们认为，对大型企业来说，办法是让能力逐步升级，虽然并不完美。代理可以先去做事，然后回来提出：“这些能力能帮我完成工作，我希望能做这些事。”你再批准。它提出的都是确定性工作流，比如“我想调用这个工具”“我想运行这个脚本来完成 X、Y、Z，可以吗？”你在权限和护栏限制下逐项批准：“好，这可以；这个也行。”随着时间推移，代理会变得相当能干，因为它有足够大的工具箱来解决大多数问题。

老实说，两方面都是。记忆显然得越来越好，因为代理要理解人的偏好。上下文也要大得惊人，因为我不想和你开一堆不同的聊天；我希望有一个对话能一直追溯到我们最初的交流，而你还记得其中相关的关键点。

是啊。

现在有 200 人。

一月份还是 200 人，所以今年扩张得非常快。

我认为招聘速度还会在现在的基础上继续加快。我们相信，工作需求是无限的，竞争是无限的，雄心也是无限的。虽然每位员工现在都比一年前能多做很多事，但我们对他们能做到什么的目标更大了。正因为每位员工的效率都高得多，我们才想要更多员工，而不是更少。

Verkada、我们所处的品类以及我们所处的时代，都有一个特别之处：总潜在市场没有边界。可服务市场的大小，似乎更多取决于我们的雄心有多大，而不是这门生意本身有多大的根本限制。我们本质上要为世界上每一位员工自动化各种工作，所以总潜在市场有多大，取决于我们想把它做多大。

我们深入客户现场。即使没有被派驻的工程师，也都加入客户的 Slack 频道，不停地讨论客户，每天都能听到客户的声音。大多数工程师每周至少参加一次客户会议；我认为大多数人实际上每天至少参加一次。

没错，这是个很大的挑战。我们的产品经常发布变化得太快，快到没人跟得上，包括我自己。我们努力确保招聘的工程师真正以产品为导向。我们作出的一项改变是，要求他们深入理解客户，并让他们直接面对客户，因为他们必须在一线做很多决定，不可能每一项产品决定都逐级交给领导层。

谢谢邀请我们。