0:00 / --:--
No Priors · 10 月 29 日
Jake Stauch 认为编程智能体降低了构建门槛，但企业采用的真正瓶颈是审批、权限、测试和审计等治理机制，Serval 把这些护栏做成产品核心。
Serval 想用代码生成重做企业工作流平台：让 IT 团队和业务部门都能构建自动化，同时以审批、最小权限和审计机制，解决 AI 智能体（Agent）进入大型企业后最难跨越的治理问题。
这集还没有学习卡。生成后会保存在这一集，下次直接打开。
Latent Space· 2026-10-28为什么 AI 智能体喜欢 SupabaseWhy Agents Love Supabase同主题：AI 编程Latent Space· 2026-10-21面向《财富》2000 强的 AI：Tenex 如何构建 AI 原生 SDLC——Alex Lieberman 与 CJ HessAI for the Fortune 2000: How Tenex Builds an AI-Native SDLC — Alex Lieberman & CJ Hess同主题：AI 编程
a16z Show· 2026-10-16AI 能写代码。它能运行系统吗？｜Grepr CEO Jad NaousNo Priors
Taking on ServiceNow: Coding Agents the Rest of Us with Serval Co-Founder and CEO Jake Stauch
YouTube
音频
Jake 在 Verkada 与企业 IT 团队长期接触时，反复听到他们对 ServiceNow 的矛盾评价：平台功能强、可定制，却也昂贵、实施慢，常需顾问参与。Serval 因而选择直接进入企业服务管理与工作流自动化市场，而不是只在现有工单系统上叠加一个聊天入口。
本集的关键背景是编程智能体能力的进步。代码可以精确表达复杂工作流，但过去编写和维护代码的门槛太高；生成代码降低了构建门槛，却没有自动消除生产环境中的权限、审批与安全责任。Serval 的产品设想，正是把这两面放在同一个平台内处理。
这场对话的主线不是“让 AI 替员工多做几个任务”，而是企业能否把生成代码的能力，变成可部署、可管理的基础设施。Jake 认为，ServiceNow 的痛点并非缺少功能，而是每增加一种自动化都要付出较高的实施成本，导致系统长期落后于业务变化。Serval 的切入点，是让 IT 团队借助编程智能体快速构建工作流，再把能力提供给 HR、财务等部门；但真正决定它能否取代现有平台的，是测试环境、审批、临时提权与审计等企业级机制。
节目也揭示了这一叙事中的张力。Serval 主张把构建能力交还给客户，却仍派驻实施人员，并提供持续的自动化工程服务，说明模型降低了写代码的成本，并未消除梳理组织流程的工作。Jake 看好更主动的个人智能体和后台智能体，却承认企业不可能放心让它们自行编写代码、取得系统权限并执行动作。他因此把产品价值放在“边界”上：智能体可以提出需求和方案，真正触及系统的动作则逐步获得授权。与“SaaS 全部会被内部自建软件替代”的说法不同，他预计核心记录系统仍会存在，变化更多发生在谁提供这些系统、以及零散工具如何被整合。这个判断有吸引力，但替换成本、安全效果和投入产出比，仍需要客户层面的长期证据。
💬 他们说了什么：Jake 将 Serval 定位为企业自动化与企业服务管理平台。在 Verkada 工作时，他发现 IT 团队经常既在 ServiceNow 上花很多钱，又对它感到不满。按他的描述，新工作流往往需要自行实施或请顾问完成，使平台相对于业务需求滞后约 6—12 个月；成本还会继续上升。
💡 为什么重要：竞争切口不是证明旧平台“做不到”，而是改变从产生想法到投入使用的速度。如果自动化需求持续变化，实施周期本身就成为产品体验的一部分。
⚡ 争议点：这是 Jake 根据客户交流作出的归纳，不代表所有 ServiceNow 部署。成熟平台已有的集成、稳定性和治理能力，也不能只用实施速度衡量。
💬 早期采用编程智能体的主要是工程团队。Jake 指出，工程师之所以敢试验，还因为代码审查为上线前的错误提供了关口。Serval 希望把类似能力交给 IT，再扩展到 HR、财务和法务：底层生成代码，外层提供预发布、审批和审计。
💡 它把“谁能构建内部工具”从软件工程团队扩展到熟悉业务流程的人员，同时试图保留工程组织已有的上线纪律。
⚡ 能发起构建不等于能判断代码质量、安全架构或异常处理。抽象层能降低使用门槛，却不能替代明确的审查责任。
💬 Jake 认为，个人智能体在消费者和较小组织中可能很好用，但大型企业的员工权限有限，甚至未必允许把个人智能体接入工作系统。Serval 的设想是由 IT 管理服务账户与较高权限；员工提出请求后，经确定性的审批流程取得一次性的即时访问权限，执行过程留在工单与审计记录中。
💡 企业需要的不是一个永远拥有管理员权限的“万能助手”，而是在特定任务、特定时间内受控调用能力的机制。
⚡ 集中管理高权限也会集中风险。实际安全性取决于凭据保管、审批人判断、执行范围，以及撤销权限是否可靠。
💬 Serval 会安排部署策略人员和部署工程师进入客户现场，先弄清现有流程与目标流程，再协助上线。初次部署之后，客户还有大量长尾需求，因此公司又建立名为 Pro Serval 的持续自动化工程服务。
💡 生成代码解决不了“企业实际上如何运作”这一发现问题。人员、制度、系统之间的差异，仍需要访谈、设计与实施。
⚡ 持续服务有助于客户落地，也可能增加交付成本。若每增加一个客户都要投入大量人员，平台业务能否保持理想的软件经济性，就值得观察。
💬 Jake 说，创办 Serval 时，他与联合创始人 Alex 就决定正面挑战 ServiceNow，而非仅为旧系统增加一层 AI 功能，或先服务较小企业。他们判断：企业自动化适合用代码表达；传统拖拽式构建器对非技术用户仍复杂，对技术用户又过于受限。编程智能体使更多人能够使用代码这种表达方式。
💡 目标市场会反过来决定产品设计。若从第一天服务大型企业，权限、审计、迁移和复杂组织流程就不是以后补做的功能。
⚡ “代码比可视化工作流更好”不能脱离维护者能力和具体任务判断。生成更快，不保证后续修改、排错和交接更容易。
💬 Jake 回忆，创业初期的代码生成能力不足，团队曾给模型提供密码重置等流程范例。他们押注这类程序化脚本定义清晰、容易验证，模型会逐步改进。如今他欢迎模型更强，因为 Serval 不自建大模型，而把权限边界、审批与审计视为产品核心。他还预测，智能体越有能力，企业越可能收紧个人的常驻权限，再通过受控例外临时放行。
💡 这提出一种与“模型能力即全部价值”不同的分工：模型扩大可完成的任务范围，治理层决定任务能否安全进入生产系统。
⚡ 能力进步也可能推动现有平台或云厂商建设类似护栏。Serval 能否长期凭治理层建立优势，不能仅由模型发展趋势推导出来。
💬 谈到替换根深蒂固的系统，Jake 强调必须让客户看到职业收益，而非只承担迁移风险；他举例称，Fox Corporation 全公司采用 Serval，牵头迁移的员工获得公司层面的表彰。产品设计上，他要求自动化遵循开发、预发布、生产之间的关口，以及评审、用户验收和合规检查。客户各自的密码重置或入职流程可以不同，但共同能力应沉淀在平台中；反复出现的知识库过期检测和闲置软件许可证回收，则被考虑做成内置功能。
💡 采购决定同时是组织决定和技术决定。可重复的平台能力、客户特有的流程配置，以及上线责任，必须分清。
⚡ Fox 案例说明存在成功采用的客户，却不足以证明普遍迁移效果；节目没有给出迁移前后的成本、故障或效率对照。
💬 Jake 观察到，CIO 在早期积极使用模型后，开始控制支出并追问投资回报，但总体采用仍可能继续增长。Serval 尝试按工作流运行次数定价，而非按 Token 定价：前者更接近完成的工作，后者也可能反映模型冗长或效率低下。
💡 预算讨论正在从“用了多少 AI”转向“完成了什么、替代了什么成本”。这会影响产品计价、日志设计和采购评估。
⚡ 一次工作流运行也不等于一次成功交付。简单与复杂流程价值悬殊，运行次数仍需结合完成率、人工返工和业务结果解读。
💬 Jake 不认为企业会因为能生成代码，就普遍自建并维护核心记录系统。边缘情况、系统故障和长期维护仍需人员投入。他预计数量众多的单点 SaaS 工具会收缩、并入核心平台；ERP、HRIS、ITSM、CRM 等类别则会保留，只是提供者可能换代。
💡 这区分了“构建成本下降”和“软件全生命周期成本消失”。AI 可能改变买什么，却未必推翻购买非核心软件的经济逻辑。
⚡ Serval 自身也在挑战核心 ITSM 提供者。“核心类别持续存在”与“现任厂商不会被替换”是两回事；整合趋势的速度和范围仍属预测。
💬 面对“IT 用户是否理解生成代码及安全架构”的疑问，Jake 认为大型企业的 IT 团队常常已在编写代码、运营系统，应获得接近软件工程师的平台能力。Serval 同时面向会看代码的 IT 工程师，以及只想描述复杂流程、不想看到代码的业务用户；代码可查看，使用界面则不必强迫每个人直接编程。
💡 设计重点不是把平台一律简化，而是在统一治理下提供不同深度的操作方式，让业务知识和技术能力各得其所。
⚡ 用户画像跨度越大，默认设置越关键。业务用户即使看不到代码，也必须理解其请求会触及哪些数据和系统。
💬 Serval 建立了名为 Catalyst 的智能体，让管理员用对话描述需求，再由它转化为平台中的自动化、审批规则、权限检查和策略配置。Jake 认为，这能缓解用户面对复杂平台时“不知从何开始”的问题；智能体还可解释概念、提出建议，并陪同用户迭代方案。
💡 AI 不只是代写工作流，也可以成为使用复杂企业软件的入口，并在构建过程中提高用户对系统的理解。
⚡ 自然语言降低了学习界面的成本，也可能模糊配置细节。管理员仍需能检查生成的规则，确认它们与原始意图一致。
💬 Jake 称后台智能体是企业软件的“登月目标”：它们主动发现并解决问题，却也可能为完成任务采取意外行动。他主张逐步扩展能力——智能体提出想调用的工具或脚本，由人批准确定性的动作，而非允许其无限制编写并执行代码。他承认，更好的记忆与上下文能力也不可少。谈到公司运营，他称 Serval 当时成立约 两年半、团队有 200 人，仍计划加快招聘；工程师深入客户沟通，产品决策更多下放给团队，并在方向不合适时撤销既有设计。
💡 自主性不是单纯调高模型权限的开关，而是一套逐级授权、复核和纠错的组织过程。Serval 自身快速扩张，也使其产品迭代方式必须跟上客户需求。
⚡ 逐项审批能约束高风险动作，却可能削弱后台智能体的效率；高速招聘与去中心化决策，则需要相应的架构一致性和质量控制。节目未提供这些机制的量化效果。
“Serval is the boundary. Serval is the guardrails.” “Serval 是边界，也是护栏。”——Jake Stauch
“On the other hand, autonomy is very scary in the enterprise.” “但另一方面，自主性在企业里非常令人担忧。”——Jake Stauch
“We try to price on workflows run because I think it's a better reflection of actual work being done versus just tokens.” “我们尝试按工作流运行次数定价，因为它比 Token 更能反映实际完成的工作。”——Jake Stauch
企业智能体的关键对象可能是“权限例外”，而不只是“任务”。 员工提出跨系统请求时，真正稀缺的往往不是生成操作步骤，而是取得合法、适时、范围受限的执行资格。由此看，工单、身份权限管理与自动化执行之间的连接，可能比聊天界面本身更重要。
代码生成改变的是定制的边际成本，不是维护责任的归属。 每家公司都能生成不同的入职流程，并不意味着这些流程可以无人负责地长期运行。版本、测试、异常处理与审计仍要有明确所有者。
“智能体会教用户构建”需要可验证的学习结果。 Catalyst 可能帮助管理员理解平台，也可能让人过度依赖对话而忽略配置。值得观察的不只是首次构建速度，还包括用户能否独立解释、检查和修正其自动化。
