--- id: "EZcWEsMuLb4" title: "挑战 ServiceNow：让更多人都能用上的代码代理——与 Serval 联合创始人兼 CEO Jake Stauch 对谈" channel: "No Priors: AI, Machine Learning, Tech, & Startups" host: ["Sarah Guo","Elad Gil"] guests: ["Jake Stauch"] date: "2026-10-29" updated: "2026-10-30" duration: "38:06" duration_seconds: 2286 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=EZcWEsMuLb4" canonical: "https://pod-exp.pages.dev/EZcWEsMuLb4/" transcript_jsonl: "https://pod-exp.pages.dev/EZcWEsMuLb4/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["企业软件","AI 智能体","AI 编程","AI 安全"] series: ["AI 与软件","AI 软件工程师"] --- # 挑战 ServiceNow：让更多人都能用上的代码代理——与 Serval 联合创始人兼 CEO Jake Stauch 对谈 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Serval 联合创始人兼 CEO Jake Stauch 介绍了公司如何以代码生成代理挑战 ServiceNow，把企业自动化交给 IT 团队，并通过确定性审批、权限控制和审计轨迹满足大型组织的治理要求。他回顾了从创立之初就瞄准大型企业系统的选择，解释为何代码比拖放式工作流更适合表达自动化，以及模型进步如何让更多员工成为构建者。对话还讨论了企业代理的自主性与安全边界、前线部署和自动化工程服务、AI 支出的投资回报、SaaS 工具整合、Catalyst 管理代理、招聘和产品决策方式，以及客户需求快速变化时工程团队如何持续调整。 ## [0:01] 未知自主代理的企业风险 · YouTube **Jake Stauch：** 这就是企业软件领域终极的登月式挑战：让这些代理自行行动、替你工作，神奇地发现所有问题并把它们解决掉。我觉得还没有人真正弄清楚如何把这件事做好。这有点像 OpenAI、Hugging Face 等公司遇到的事件：给代理一个任务，它却做出了意料之外的事。代理能力变强后，理论上可能开始编写能在你的系统上采取行动的代码，这会带来没有边界的安全风险。我不认为近期有人能解决它。一方面，你希望代理足够自主，不需要人一直盯着；另一方面，在企业里，自主性又非常可怕。Serval 就是那道边界，是护栏。我们让有大量规则、审批、流程和内部政治的大型企业能够安全、放心地大规模采用这些工具。 ## [0:50] Jake Stauch 与 Serval 的背景 · YouTube **Sarah Guo：** 听众朋友们好，欢迎回到《No Priors》。今天我和 Elad 请到了 Serval 联合创始人兼 CEO Jake Stauch。Serval 像非洲野猫一样迅捷，正试图挑战 ServiceNow；更广泛地说，它把代码生成的力量带给 IT 和整个企业团队。欢迎你，Jake。 **Elad Gil：** Jake，谢谢你今天来《No Priors》，很高兴你能来。 **Jake Stauch：** 很高兴来到这里。 **Sarah Guo：** 你能多讲讲自己的经历、Serval 是怎么创立的，以及最初想解决什么问题、为什么开始做这件事吗？ **Jake Stauch：** 简单介绍一下，Serval 做的是企业自动化和企业服务管理。我们的设想是，人们可以在工作中提问、获得帮助，并把工作中许多自己不喜欢的部分自动化，我们用代码生成代理来实现。公司主要做的就是这个。我们和 ServiceNow 这样的公司竞争，它是这个领域历史悠久的大型传统供应商。我是在上一家公司 Verkada 工作时发现这个品类的。当时我们向 IT 团队销售企业级实体安全产品。我花了很多年和 IT 团队交流，弄清楚该为他们做什么。我很喜欢问他们：“你们在哪方面花钱最多？最讨厌什么？”ServiceNow 常常排在那些清单的前列。我一直觉得这个领域或许有更好的解决方案，但在我任职的大部分时间里，还看不出怎么才能打败 ServiceNow。他们是一家很出色的公司，做成了很多事，为什么我们能和他们竞争呢？ **Elad Gil：** 用户觉得它哪里让人恼火？ **Jake Stauch：** 我想，问题是很难在这个平台上构建东西。它是一个非常稳健、可定制、功能强大的平台，能够映射各种企业工作流。归根结底，它是工作流自动化平台，所以能做很多事；但你每有一个不错的想法，都得自己去实现，很多时候还得找顾问来做。因此它总是比你期望的进度慢 6 到 12 个月。如果要做的是一个能用 5 年、10 年的大型入职流程，而且业务不会变，投入前期成本，部署后运行一段时间也没问题。但如果你想跟上所有希望构建的自动化，ServiceNow 就跟不上。它还很贵，而且会越来越贵。用户的许多不满，正是因为它跟不上业务想前进的步伐，成本又不断增加。 ## [3:00] 将代码代理带给工程师以外的人 · YouTube **Jake Stauch：** ……这就是许多用户不满的原因：它跟不上业务想前进的步伐，价格还越来越高。 **Elad Gil：** 你刚才提到的一点很有意思。看 AI 的应用情况，早期大量落地都集中在代码代理上，也就是工程师用它来开发业务应用、产品和其他东西。而你们正在开拓这个品类，让公司里的任何人，比如 IT 人员，都能构建供整个企业广泛使用的内部产品或工具。你们基本上是在为……提供代码代理。 **Jake Stauch：** 是的，所有内部事务。 **Elad Gil：** 对那些往往不太会编程的人来说。能多讲讲吗？我觉得这特别有意思。 **Jake Stauch：** 我们很喜欢“为其他所有人打造的代码代理”这个想法。企业早期采用 AI 的大部分工作都发生在工程团队里。原因有很多，当然，工程师通常是各种新技术的早期采用者；但他们也能够构建并试用这些工具，因为有代码审查流程。即使是 19 岁的实习生，也可以做出非常强大的东西，再经过审查流程才进入生产环境，这很安全。我们希望把同样的能力带给企业里的其他人。我们打造了一个平台，把代码代理带进 IT 部门，再由 IT 推广给人力资源、财务、人事和法务团队。 底层是代码代理，但我们在上面提供了各种抽象层、护栏和控制，让所有操作经过审批、暂存和审批流程，并留下审计轨迹。核心问题是：怎样构建一个系统，让每个人都能轻松成为构建者？ 我们的核心洞见是，IT 人员其实想要构建东西。对世界上大多数公司来说，他们没有工程部门，只有 IT 部门。大多数公司有 IT 部门，却没有一支软件工程师团队。为公司构建和配置技术的是 IT 部门，而我们本质上是在为他们打造 AI 平台。 ## [4:40] 个人代理在企业里的局限 · YouTube **Sarah Guo：** 这和正在开发的各种职场代理有什么关系？比如 OpenAI 的 Dot，或类似的虚拟助手，可以替你去做事情。 **Jake Stauch：** 我觉得它们对消费者、小型企业，甚至许多中型企业都很有用。但在大型企业里，审批流程和行为规范非常多。我一开始也没充分意识到这一点：每个人能做什么、不能做什么，都有很多流程；个人权限集又非常有限。即便公司允许你把自己的代理带到工作中（很多情况下并不允许），它能做的也极为有限，几乎连你的邮件都读不了。 想想你在工作中需要处理的所有事情、想接触的系统，以及可以构建的各种自动化，个人权限实在太有限，所以个人代理往往没什么用。我们和 IT 团队合作，他们可以接入服务账号凭证和管理员级权限，因此能建立一种机制，让员工可以使用更高权限，在工作中完成各种复杂操作，同时仍然经过非常严格、确定性的审批周期和工作流，并留下审计轨迹，因为 Serval 底层也是一个工单系统。 你可以说：“我想让代理去做 X、Y、Z。”但大多数大型企业对此会很不放心。通过 Serval，这会生成访问申请，走审批流程，所有操作都会记录在案。随后你可以获得即时授权，只运行这一次确定性工作流，整个过程都会被追踪。是的，这比我们喜欢的 Instinct、Muse 等工具那种神奇的个人代理体验麻烦一些，但大型企业，尤其是受监管的企业，要采用这类技术，就必须做到这些。 ## [6:29] 如何在大型组织中有效部署 Serval · YouTube **Elad Gil：** 这也关系到技术传统上的普及方式：由 Accenture、Deloitte 这样的咨询公司负责一部分工作，替客户实施。你们是在把这部分能力直接交给 IT 部门。你们是否也在探索更深入的前线部署模式？你们实际上怎样才能在企业里把它搭建起来、有效使用？ **Jake Stauch：** 是的，完全如此。这里的差距显然在于技术普及。技术能做很多事，而企业对可能性的探索才刚刚开始。很多工作在于理解人员、流程、现有工作流，以及未来希望它们变成什么样；我们认为这仍然需要人来做。所以我们会派部署策略师（这是我们的称呼）和一位现场部署软件工程师到客户那里，弄清楚如何实施、如何解决企业遇到的各种问题，然后带着客户走完整个实施过程。 不过我们发现，产品实施和部署后，客户往往还有一长串想做的事。正如软件工程领域的情况一样，对工作的需求其实是无穷的。我们开始组建一支叫作 Pro Serval 的团队；这个领域叫自动化工程。我们会安排自动化工程师持续提供支持和服务，因为客户想自动化的事情太多了，需要有人帮他们判断哪些流程可以自动化、流程是什么样的、如何打通所有系统，以及怎样用 Serval 这样的产品把它投入生产。 ## [7:55] 从第一天起就瞄准企业系统记录 · YouTube **Sarah Guo：** 公司成立多久了？ **Jake Stauch：** 两年半。 **Sarah Guo：** 看 ServiceNow 这门生意，我觉得 Serval 是少数直接挑战、并试图替换大型企业系统记录的公司之一。你们一开始就想做到这一步吗？这么庞大的产品套件，你们打算怎么一步步攻下来？ **Jake Stauch：** 我常开玩笑说，一切都完全按我们那套非常不切实际的计划进行。我们从一开始就想成为史上最大的企业软件公司。我们列出所有公司，圈出 ServiceNow，说我们要打败他们，做出规模大得多的东西。第一天，在我联合创始人 Alex 的客厅里，当时只有两个人，我们就这么说了。这个目标听起来疯狂，但从来就是我们的初衷；我们不是后来才逐渐有了这个野心，而是从一开始就奔着它去的。 **Elad Gil：** 很多人可能会从票务系统上面加一层自动化开始。 **Jake Stauch：** 对。企业初创公司通常有两种做法：做一层软件，或转向更低端市场。第一种是做一个小层，和大公司和平共处，比如在它们现有工作之上加一个 AI 代理。这样很容易限制发展；我能想到的成功案例可能只有 Vevo 之类，它最初基于 Salesforce，后来迁移成自己的平台。要反向整合非常难，除非你找到一个细分市场之后再扩展。 另一种做法是下沉市场，服务中小企业和中型企业。许多 Workday、Salesforce 的竞争者都说，自己要做同类产品的低端版本。 **Sarah Guo：** 就像 Rippling 或 HubSpot？ **Jake Stauch：** 没错。 **Elad Gil：** 花十年时间？ **Jake Stauch：** 对。我们看了这些路径后就想，为什么不直接挑战最大的那家？这当然更难，但如果赢了，回报也足够大。我认为这对我们非常重要，因为从第一天就面向大型企业，会让你做出许多不同的决定：产品怎么设计、团队怎么组建、如何看待增长，都和先服务一个市场、以后再扩张有根本区别。 ## [9:51] 用工作流自动化平台挑战 ServiceNow · YouTube **Sarah Guo：** 你们为什么选择这个领域，而不是 Salesforce 服务器等其他几个各自领域的巨头？ **Jake Stauch：** 我们并不真正清楚怎样打败其他公司，也不知道自己的优势是什么，更不知道 AI 带来了什么样的突破、让它们无法追上。凭着我们对 IT 的了解，我们明白 ServiceNow 本质上是一个工作流自动化平台。 我和联合创始人很早就有一个想法：在企业里，代码才是表达自动化的正确方式。所有自动化都应该用代码构建。拖放式工作流构建器这种抽象层很痛苦：对非技术用户来说太复杂，对技术用户来说又是烦人的抽象。代码是构建自动化的更好方式。问题显然是，会写代码的人不多，也不可能足够快地写出来，让这种方式适用于自动化。 AI 让这成为可能时，我们俩都一下子想通了：如果代码是构建自动化的正确方式，而现在人人都能写代码，我们就能打造更好的自动化平台。而自动化平台最适合进入什么市场？就是挑战 ServiceNow 这样的庞大传统软件公司。 ## [11:01] 看好代码代理演进，并在企业构建护栏 · YouTube **Elad Gil：** 不过，两年半前你们刚起步时，大多数代码工具还只是 Tab 补全，根本不好用。 **Jake Stauch：** 是的，所以……实际上我们开始构建这个东西时—— **Elad Gil：** 当时的假设是什么？是认为代码能力会大幅进步，还是你们觉得要自己构建工具、后来发现不需要，因为模型变得太好了？我很好奇这段转变。 **Jake Stauch：** 我们押注代码代理会变得非常好用。背后的理论是，编程是一个可验证的领域，模型应该能通过持续迭代不断提升。因此我们从根本上相信代码代理至少能做好某些任务。我没料到它们在通用软件开发方面也能变得这么强，但像重置密码、获取审批这样的确定性流程脚本，定义非常清楚、结果也能验证，我们觉得模型会擅长这些任务。 从工作流自动化的角度看，我们认为它最终能做到。早期它还做不到，所以在最初的演示中，我们会提示大语言模型：“嘿，这里有一个你可以用来构建密码重置工作流的建议方法。”我们给它提供许多示例，逐渐扩大示例库。后来模型越来越强，最终变得很难把它难住：只要 API 存在，你几乎很难给它一个无法自动化的工作流。 **Elad Gil：** 是的。看看现在的代码代理，以及客户的需求，你和 Alex 是期待它们继续进步，还是会担心？它们对你们自己的产品会有什么影响？ **Jake Stauch：** 我们非常期待它们进步，因为这能解锁许多我们希望实现的功能，比如更好的浏览器和电脑操作，以及更多后台代理、个人代理，让它们在企业里真正有用。我们一直相信，我们不自己构建大语言模型；我们构建的是护栏和边界。对我们来说，边界就是产品，因为有了我们，大型企业才能在繁杂规则、审批、流程和内部政治之下，安全、放心地大规模采用这些工具。Serval 就是边界，就是护栏。模型智能提升只会让我们的产品更强大，也会让客户希望进一步收紧边界和护栏。 我认为企业会越来越严格地控制个人访问权限。随着权限变窄、个人能够做的事越来越少，这种趋势会发生。 **Sarah Guo：** 为什么会这样？ **Jake Stauch：** 因为想想看：我也许可以放心地给你一些超出你实际需要的权限，因为我觉得你不会造成太大破坏。但如果你还能使用各种代理，那么哪怕权限只比普通水平高一点，可能造成的破坏也会扩大。我们现在已经能在网络安全风险上看到这一点。 **Elad Gil：** 完全如此。 **Jake Stauch：** 所以，作为大型企业，我实际上会想把每个人的权限缩减到真正的最小权限：除非工作绝对需要，否则不能访问任何文档，也不能采取任何行动。但例外总会不断出现。我们就是负责授予这些例外的那一层，让你能为它们设置审批流程，关联审计轨迹和工单。我们掌控企业里的权限提升方式，因此企业越收紧终端用户权限，我们就越重要、越有力量。 ## [14:31] Serval 的高风险高回报与代理趋势 · YouTube **Elad Gil：** 有没有什么故事或成功案例可以分享？客户要替换一个根深蒂固的现任系统，承担的风险很大，也要投入自己的时间。为什么要冒这个险？有没有客户已经走过这段路、看到了结果？ **Jake Stauch：** 我们必须让自己和客户相信，Serval 是让你在工作中获得晋升的途径。客户采用 Serval 不能只是冒个险，希望之后得到回报；我们得让他们相信，做了这件事不仅不会惹上麻烦，还会成就你的职业生涯，甚至让你获得晋升。 **Sarah Guo：** 这是自上而下推动的，对吧？ **Jake Stauch：** 是自上而下的。我们向高管团队销售，很多时候是向 IT 领导层销售，再推广到其他部门。我们的信息是：人们过去靠 ServiceNow 建立职业生涯，而你会靠这一代产品建立自己的职业生涯。我们正看到这种情况发生。最大的客户之一是 Fox。Fox Corporation 在全公司采用 Serval，负责在一线推动迁移的人，后来被提名为全公司的 MVP。 **Elad Gil：** 哇。 **Jake Stauch：** 他还因为这项工作获了奖。这正是我们要做的：告诉客户，这不只是证明你对组织有用，而是证明你可能是公司里最不可或缺的人，因为你在引领这场变革。我们在 AI 转型中极为关键，我认为这也是一种很好的销售方式。 **Sarah Guo：** 你创办 Serval 时，很擅长提前判断趋势：知道代码代理会变好，也知道这是转型的方式，还识别出了合适的市场。你预测未来两三年会发生什么？不只是对你们公司，也包括更广泛的 AI。你看到什么即将发生的大变化，特别让你兴奋？ **Jake Stauch：** 消费领域常常是企业接下来会发生什么的一个窗口，虽然两者并不总是一样。我非常看好个人代理在企业里的形态。电子邮件、Slack 等工具改变了我们的工作沟通方式，我认为个人代理也会成为其中的重要部分。每个人都会有自己的个人代理，替自己执行任务、再把任务委托给其他个人代理。你的代理会和同事的代理交流。我很期待这一点。 但在网络安全风险不断上升的情况下，我们要怎样保障安全？大型企业会越来越担心每个人的代理在电脑上采取什么行动、使用什么浏览器。员工和消费者希望个人代理在工作中能做什么，与企业治理层面的要求之间存在张力；我觉得这很有意思，也会在这种张力中产生许多机会。 **Elad Gil：** 你觉得个人代理和工作代理会分开吗？ **Jake Stauch：** 我觉得会。我想，就像我有 Gmail，也有公司邮箱一样。 **Sarah Guo：** 是啊。 ## [17:25] 企业需要不同的产品构建原则 · YouTube **Elad Gil：** 如果把几个前提放在一起：权限例外和访问控制会变得复杂，也需要更大规模的管理；另外，由于自动化变得容易，人们会在各处构建更多自动化。除了“代码生成应该是产品里真正的自动化形式”之外，你们还采用了哪些体现这些判断的核心设计原则？ **Jake Stauch：** 我认为最重要的一点是软件开发生命周期。工程领域里我们习以为常：有开发环境、暂存环境、生产环境，它们之间有各种关卡；还可以用分支开发，不会破坏其他系统。 **Elad Gil：** 抱歉确认一下，IT 自动化现在还不是这么运作的，对吧？ **Jake Stauch：** 有些情况是这样，但我认为大多数新的 AI 产品没有采用这种做法。它们基本上是在说：“来构建这些很酷的代理，然后直接发布到生产环境。”但大型企业、尤其大型金融机构，需要遵循软件开发生命周期；不能在没有审查、用户验收测试和其他检查的情况下，就发布新的代理能力。 **Elad Gil：** 合规检查。 **Jake Stauch：** 没错。所以我们一直在思考，怎样才能让世界上最大的公司采用这项技术，而不只是做出强大、很酷、我们很想交到客户手中的东西。 **Elad Gil：** 很多 AI 公司，特别是垂直领域的公司，得花一两年，有时甚至更久，才能理解这些要求。现在很有意思，整个行业都开始采用前线部署模式，也开始考虑软件开发生命周期、合规，以及企业里的其他方面，而这些过去几乎都被忽视了。 **Jake Stauch：** 我觉得有些公司最终也做不到。它们看到企业软件需要付出的代价，就决定自己不想构建这些东西。回头看前面提到的许多转向低端市场的公司，有时它们确实看到了进入企业市场的机会，但这要求完全不同的一套构建原则，也要构建不同的产品，有些公司就是不愿意这么做，于是把这块市场让给了别人。我们选择说：“把最棘手的问题交给我，我们会解决，让你在这个充满风险和治理顾虑的世界里实现 AI 转型。” **Sarah Guo：** 你们部署产品时，会有客户环境工程师、持续自动化专家和核心平台。你们如何决定什么功能进入核心平台，什么留在每个客户自己的环境里？ **Jake Stauch：** 部署软件时很重要的一点是，我们从不构建定制功能，也不开发客户专属的产品能力。幸运的是，在我们的领域里没人要求我们这么做。客户提出的需求，最终其他客户也都会需要。它们可能会影响优先级，但本来就是我们希望加入平台的东西。 另一方面，因为底层是代码生成平台，客户在 Serval 里构建的东西又非常独特。一家公司的密码重置工作流，和另一家的会非常不同，令人惊讶；入职、离职以及各种内部自动化也是如此。但这些差异本身由平台的核心原语支持。Serval 几乎就像 IT 部门和其他部门用来构建自动化、规模化管理自动化的 IDE。 如果我们看到同一个客户一遍又一遍地构建相同的自动化，每次都以相同方式定制和实现，就会考虑：“这是否应该成为产品的一等功能？”例如，我们看到很多客户在构建工作流，用来发现知识库文章之间有冲突或已经过时，于是决定直接自动处理。还有客户设置自动化，回收长期无人使用、却仍在付费的软件许可证，自动取消这些订阅。于是我们把这种能力直接构建进平台。这让我们可以试探哪些应该成为真正的一等功能，哪些应该继续以 Serval 自动化的形式存在。 ## [21:25] 企业核心功能与自动化的界线 · YouTube **Jake Stauch：** ……这让我们可以试探哪些应该成为真正的一等功能，哪些应该继续以 Serval 自动化的形式存在。 ## [21:31] Token 使用上限、长期预算与投资回报 · YouTube **Elad Gil：** 今年，我们的企业客户在软件团队代码生成的整体支出上走过一段历程：先让大家试用，接着把 token 用量拉到极限，然后限制用量、弄清楚谁在真正有效地使用。你怎么看这对你们业务的影响？又如何看待实际的智能成本？ **Jake Stauch：** 我们还在观察。我确实看到 CIO 客户试图从最初那种不计 token 用量的阶段退回来，但我也觉得我们还处在采用曲线的非常早期，所以整体上不会收缩，支出反而会继续大幅增长，因为大多数公司才刚开始摸索这件事。 它们都会经历一轮快速早期采用，然后稍微收紧支出，尝试衡量和计算投资回报。但我经常从客户那里听到，他们并不太担心长期预算影响。他们知道短期会收缩，却仍计划增加支出。他们需要的是更多投资回报的证据。 我认为行业的转变就在这里：大家会寻找办法证明这些支出带来了什么。这很难，我不认为有人真正弄清楚了，如何衡量买来的 token 产生了什么价值。但这会给我们带来很大的机会：展示完成了哪些工作，并把它与其他平台、成本模式或人力完成的工作进行比较。客户要我们帮他们证明这笔钱花得值，这就是我们要完成的任务。 我们尝试按运行的工作流定价，因为我认为这比只按 token 计费更能反映实际完成的工作；token 数量更像是冗长和低效程度的指标。不过我想，我们最终都会找到不同的方式来证明所做的事确实合理。 ## [23:22] SaaS 末日与软件公司的 AI 转型 · YouTube **Elad Gil：** 人们一直在谈所谓“SaaS 末日”：公司会自己构建内部 SaaS 软件，各个品类都会消失。就像你刚才说的，很多人正在用 token 成本来判断，重建这些系统是否划算、是否做得到。你怎么看 SaaS 末日，或者 SaaS 与 AI 之间的这种转变？ **Jake Stauch：** 我接触过的公司里，尝试在内部编写代码、构建这些工具的，特别是系统记录的核心工具，而不是一些单点解决方案，都发现企业软件的构建和维护成本相当高。即使能做，在许多情况下也不符合经济效益，除非你的需求非常特别、独一无二。对于不是核心能力的东西，购买现成产品一直都是“自建还是购买”的问题；现在仍然和过去一样。企业软件依然难以构建。很多公司正在发现，或者重新认识到，企业软件很复杂，而且需要人来维护。 **Elad Gil：** 具体会遇到哪些使用场景和边缘情况？ **Jake Stauch：** 边缘情况就是系统会出问题，需要人更新。于是你得配备团队、支付人力成本，而且很多时候没人愿意去内部工具团队工作。所以自建会遇到这一大堆问题。 我确实看到了变化，主要发生在单点解决方案上：很多公司有几百个 SaaS 应用，但实际只需要几十个工具。因此，我认为各种单点解决方案的泛滥会收缩，它们会被核心系统记录和核心平台吸收。 **Sarah Guo：** 我觉得中间件也会消失。 **Jake Stauch：** 没错，我认为确实会出现整合。因此会有一场“SaaS 末日”，但主要影响的是那些单点解决方案、规模较小的公司。我不认为核心系统记录会真正消失，比如 ERP、HRIS、ITSM、CRM。它们会继续存在，只是可能转型。我们用 Serval 正在替代这些工具。所以我认为会出现新一代的在位厂商，但这些品类不会就这样消失。 ## [25:21] 如何把平台级能力交给企业 IT 用户 · YouTube **Sarah Guo：** 我很好奇，你们如何理解 IT 用户？他们不是软件工程师，但了解自己的业务，也知道想自动化什么。谈到“氛围编程”时，我会想：他们懂安全架构吗？懂如何与治理体系集成吗？你们怎么协调代码生成、“氛围编程”的做法和挑战，以及构建稳健 IT 系统的要求？ **Jake Stauch：** IT 很有意思，因为他们其实比很多人想象的更接近软件工程师。特别是在大型企业，很多情况下 IT 部门就是工程团队。他们没有软件工程团队，所以 IT 负责运行所有这些系统，也经常编写代码并管理系统。 因此我们把他们当作成年人，给他们软件工程师会用的工具。我们会抽象掉一部分复杂性，让某些事情更易用；但不会只把一堆云端代码丢给他们，然后祝他们好运。我们会针对他们的用例打造平台。我们也不要求他们一定会写代码，或理解生成的每一行代码，但仍让他们看到底层代码。你始终可以查看代码，也可以让整套系统走完整的软件开发生命周期；不过不一定非得这样。 我们的许多产品原则，都来自同时考虑不同类型的用户：一类是能够并且确实会一路写代码的 IT 工程师；另一类可能是市场部门或人事团队的人，他们不想看到代码，但又希望底层代码生成带来灵活性，因为他们有复杂工作流想要构建，不想靠拖放操作拼出来。因此，关键是脑中要有多个用户画像，同时也要把 IT 当作成熟的专业人员。过去很多产品对 IT 有些居高临下，仿佛他们不懂这些东西，所以只需要非常精简、意见明确、简单易用的版本。实际上，IT 很欣赏复杂性，也欣赏这些平台的能力。我们想把这种能力交到他们手上。 ## [27:26] 用 Catalyst 构建自动化并提升技术能力 · YouTube **Elad Gil：** 你们构建了一个帮助用户创建自动化的代理，能解释一下它怎么工作吗？ **Jake Stauch：** 我认为每家公司在构建第一代 AI 工具时都发现了一件事：你可以打造非常强大、复杂的系统，但之后还得培训用户，让他们理解产品的各种基本构件，以及这些系统如何组合。因此第一代做法是派许多全职员工去给客户讲解：“平台该怎么用？要不我直接替你搭好吧。”后来我们发现，如果客户能直接和一个理解他们需求、并能把需求转化为产品构件的代理对话，那就太好了。 所以我们打造了 Catalyst。它是管理平台的代理，管理员可以用它构建底层自动化、配置审批规则、权限检查和各种策略、更新不同系统，并了解整个部署情况。既然 Serval 底层都是代码生成，在上面放一个代理帮助管理整个系统，就非常合理，也极其强大。这样客户不必先培训自己如何使用 Serval，只要和一个真正理解 Serval、知道怎么在上面构建东西的代理对话就行。它就成为进入产品的主要界面。 **Sarah Guo：** 我觉得有一点被低估了，也很有意思：在不同产品里的代理体验，包括代码生成代理，能够在用户构建产品或实施方案时一路陪伴他们，实际上是在提高大量用户的技术能力，把更多人变得更像工程师。 **Jake Stauch：** 完全正确。旧一代自动化产品面临一个“白纸”问题：我知道想把工作中的很多事情自动化，但到底从哪里开始？像我们这样的产品会先问你想从哪里开始，然后提出建议。你可以和代理反复讨论，说：“我其实不明白这是什么意思，你想表达什么？能解释一下吗？我想做这件事，该怎么做？”它们可以提供和检索信息，向你解释概念。 这样一来，它就成了构建伙伴。你能做到的远远多于只提示代理去构建某个东西；它还能带你走完整个过程，帮你探索之前根本没想到的新机会。 ## [29:38] 下一波浪潮：企业后台代理与自主性 · YouTube **Sarah Guo：** 现在有个话题似乎讨论得不够多：后台代理。你怎么看？下一波浪潮会是什么样？ **Jake Stauch：** 我总是这样向企业描述后台代理：它们是企业软件领域终极的登月式挑战。让代理自行行动、替你工作，神奇地发现所有问题并把它们解决掉。如果能部署并且让它按权限运行，那就太棒了。我觉得还没人真正弄清楚怎么把它做好，因为一方面，你希望代理足够自主，能自己调查并解决问题，不用人一直盯着；另一方面，在企业里，自主性非常可怕。你需要确切知道它们能读什么。这有点像…… **Elad Gil：** OpenAI、Hugging Face 遇到的那些事件：代理接到任务后，为了完成任务却做了意料之外的事。那你能设置哪些护栏？ **Jake Stauch：** 正是如此。对于我最优秀的员工，我会怎么做？给他们一个高层次的任务，让他们自己去做，别来找我，然后他们回来时已经做成了很棒的事。我也希望能够信任代理这么做：给它一个高层次任务，让它解决问题后回来。但我认为我们还没找到一种让企业觉得安全的方式。 **Elad Gil：** 嗯。 **Sarah Guo：** 怎样才能让它安全？人们尝试过各种办法，从宪法式 AI 到某些强化学习方法。我很好奇你们有没有想到解决方案？ **Jake Stauch：** 我们认为，对大型企业来说，办法是让能力逐步升级，虽然并不完美。代理可以先去做事，然后回来提出：“这些能力能帮我完成工作，我希望能做这些事。”你再批准。它提出的都是确定性工作流，比如“我想调用这个工具”“我想运行这个脚本来完成 X、Y、Z，可以吗？”你在权限和护栏限制下逐项批准：“好，这可以；这个也行。”随着时间推移，代理会变得相当能干，因为它有足够大的工具箱来解决大多数问题。 这种做法并不完美，因为你得一直盯着审批流程。但我认为这是必要的；否则代理理论上可以开始写代码，直接在你的系统里采取行动，带来没有边界的安全风险。我不觉得近期有人能承担这种风险。 **Elad Gil：** 回到你刚才说的期待未来能力：你觉得现在还缺少一些模型能力吗？我这么问是因为，代理主动预测一个人的需求并且预测正确，仍然很难；这需要大量偏好数据。比如一个员工要弄清楚 Jake 作为 CEO 的真实优先级是什么，你给他一个高层次任务时到底是什么意思。你认为这是模型问题，还是当下完全属于护栏和执行框架的问题？ **Jake Stauch：** 老实说，两方面都是。记忆显然得越来越好，因为代理要理解人的偏好。上下文也要大得惊人，因为我不想和你开一堆不同的聊天；我希望有一个对话能一直追溯到我们最初的交流，而你还记得其中相关的关键点。 但权限问题始终会是最大的难题。即便我觉得代理非常有价值、很聪明，可以替我做这些事，我又能信任它放手去做、而不必看管它的行动到什么程度？ **Sarah Guo：** 对人也是这样吧？任何为你工作的人都得回来确认：这是不是你要的，并给你几个选项。所以我觉得这只是很正常的工作流程，对吧？ **Jake Stauch：** 是啊。 ## [33:07] Serval 的招聘速度与无限雄心 · YouTube **Sarah Guo：** 是啊。公司大约成立两年半了，你们很快就做出了成熟的企业级产品。现在团队有多大？ **Jake Stauch：** 现在有 200 人。 **Elad Gil：** 200 人？ **Jake Stauch：** 一月份还是 200 人，所以今年扩张得非常快。 **Sarah Guo：** 这确实是很不寻常的一年。你们预计还会这么快地招聘吗？你显然相信 AI，为什么还要招这么多人？还有，你和团队之前也在初创公司待过，过去两年和之前十年的做法有什么不同？ **Jake Stauch：** 我认为招聘速度还会在现在的基础上继续加快。我们相信，工作需求是无限的，竞争是无限的，雄心也是无限的。虽然每位员工现在都比一年前能多做很多事，但我们对他们能做到什么的目标更大了。正因为每位员工的效率都高得多，我们才想要更多员工，而不是更少。 **Elad Gil：** 想到你之前在 Verkada 的经历，过去两年你们的运作方式和之前十年相比有什么不同？ **Jake Stauch：** Verkada、我们所处的品类以及我们所处的时代，都有一个特别之处：总潜在市场没有边界。可服务市场的大小，似乎更多取决于我们的雄心有多大，而不是这门生意本身有多大的根本限制。我们本质上要为世界上每一位员工自动化各种工作，所以总潜在市场有多大，取决于我们想把它做多大。 因此关键在于我们能多快增长、有多大雄心，并据此做决策，而不是只看“市场现状如何、我们实际能做到什么”。这带来另一套挑战，并不是绝对更好，因为开放空间太多，我们必须做更多决定，确定真正要专注的方向。不过，不被市场规模限制、也不受市场框框约束，确实很有意思。 ## [34:59] 跟上客户节奏与产品职能的根本变化 · YouTube **Sarah Guo：** 既然范围这么广，你们如何安排产品、工程和设计团队的工作节奏？ **Jake Stauch：** 我们深入客户现场。即使没有被派驻的工程师，也都加入客户的 Slack 频道，不停地讨论客户，每天都能听到客户的声音。大多数工程师每周至少参加一次客户会议；我认为大多数人实际上每天至少参加一次。 这就像住在一个国家里学习外语：你完全沉浸在买家和客户的思维方式中，理解他们想要什么、如何看待问题，并实时适应他们偏好的变化。客户随着市场变化，开始谈论试用的不同产品和感兴趣的事情，我们的工程师始终了解这些情况，能够快速调整。 因此我们把产品开发真正下放给工程团队。我们没有单独的产品职能，因为每天和客户交流的就是工程师，他们能快速适应客户今天、本周提出的需求，而不是一个月前的需求。 **Sarah Guo：** 听起来这是一种很自然的方式，可以跟上快速变化的市场和客户优先级。那你和 Alex 及管理团队如何把这些信息梳理清楚？传统企业软件公司会做架构评审—— **Elad Gil：** 是的，会有季度路线图，排定优先级，再培训客户了解新产品。 **Sarah Guo：** 而且会告诉客户，变化不能太快，因为他们吸收变化也需要时间。 **Jake Stauch：** 没错，这是个很大的挑战。我们的产品经常发布变化得太快，快到没人跟得上，包括我自己。我们努力确保招聘的工程师真正以产品为导向。我们作出的一项改变是，要求他们深入理解客户，并让他们直接面对客户，因为他们必须在一线做很多决定，不可能每一项产品决定都逐级交给领导层。 根本性的变化是，你必须愿意把很多产品决策权下放，快速行动；如果方向错了，也要愿意撤销、回滚，放弃自己珍爱的方案。你得愿意改变那些曾认为是产品根基的东西；当工程师告诉你“客户现在是这么看问题的，我们应该换种做法”时，你要能转向。 我在 Serval 最自豪的一点，是我们多次决定抹掉过去投入很深的成果，然后说：“市场变了，客户变了，我们要彻底换一种做法。”我认为，正是这种反复重塑自己的能力和意愿，让我们跟上了变化。 **Elad Gil：** 在这个时代，最持久的一些东西就是这样。谢谢你，Jake。 **Jake Stauch：** 谢谢邀请我们。 ## [37:49] 结尾 · YouTube **Sarah Guo：** 欢迎在 Twitter 上关注 @NoPriorsPod。想看我们的脸，就订阅 YouTube 频道。也可以在 Apple Podcasts、Spotify 或你收听节目的任何平台关注我们。这样每周都会收到新节目。订阅邮件，或在 no-priors.com 查看每期节目的文字稿。