Jake Stauch¶
Serval 联合创始人兼 CEO（企业自动化 / 企业服务管理，正面对标 ServiceNow；⚠️ 联创名为 Alex，转录稿只有名）。此前在 Verkada 卖企业物理安防给 IT 团队，由此发现这个类目。⚠️ 自述公司两年半、今天 200 人。
定位：本库第一份来自"把护栏本身当作产品"的企业侧材料——⚠️⚠️ 他的核心判断是 agent 变强会让企业把权限收得更紧，而拥有"权限怎么被提升"那一层的人反而更不可或缺。
⚠️ 立场：他在卖 Serval，全部产品、增长与客户陈述为自述；节目由投资方主持。✅ 但本库判定厂商色彩比同类材料轻，依据是三处主动让步：承认自家路线"挺烦人、得盯着"、对能力边界明确划线（"没人真的搞清楚该怎么做好"）、以及对"怎么证明 ROI"这个对自己有利的题目给了否定答案。
核心观点¶
来源：No Priors × Serval（2026-10-29）
- ⚠️⚠️ "工程团队先用上 AI"有一个流程解释，而不只是"他们是早期采用者"："他们能拿这些工具做实验，是因为他们有 code review 这个流程。哪怕一个 19 岁的实习生去建一个很强的东西，再走这个流程然后进生产，都是很安全的。" → 处方是把同一套安全发布流程带给 IT / HR / 财务 / 法务（[00:03:01]）。✅ 而配套洞察改变了买家是谁："大多数公司有 IT 部门，而不是一支软件工程师团队……是 IT 在为公司建和配置技术。"
- ⚠️⚠️ "边界就是产品"："我们不是在造 LLM，我们在造护栏、造边界。而边界就是我们的产品。" ✅ 推论反直觉："智能变得更好只会让我们的产品更强，同时也让客户更想把那些护栏收得更紧。"（[00:12:09]）
- ⚠️⚠️ 企业里的个人权限会越收越紧，而不是越放越宽："我可能会安全地给你比你需要的更多权限，因为我不觉得你能造成多大破坏。但如果你能用上这些 agent，那你用任何稍微超出常规的权限能造成的破坏就放大了。" → 收到真正最小权限 → 例外会一直出现 → ⚠️⚠️ "通过拥有企业里权限是怎么被提升的这件事，我们反而越不可或缺——你把终端用户权限收得越紧越是这样。"（[00:13:09]）
- ⚠️⚠️ "把个人 agent 带进大企业"不成立，而理由不是安全政策："任何一个人的权限集合都太有限了……它连你的邮件都几乎读不了。" 解法是换权限来源（IT 的服务账号 + 管理员权限）→ just-in-time 提权 + 确定性审批 + 审计轨迹（底下是工单系统）；✅ 他承认代价："比我们在 Instinct、Muse 这些工具里喜欢的那种魔法般的个人 agent 体验要烦人一点。"（[00:04:02]–[00:06:05]）
- ⚠️⚠️ 代码取代拖拽式编排的抽象层论证："拖拉拽的 workflow builder 是一个让人痛苦的抽象层级，因为它对非技术用户来说太复杂，而对技术用户来说又被抽象得很烦人。" 原阻碍是"没多少人会写代码且快不到划得来"，而 AI 解掉了它（[00:10:09]）。
- ⚠️ 两年半前的赌注与它的校准："赌的是 coding agent 会变得非常好，理由是这是一个可验证的领域，应该能相当好地爬坡"；⚠️⚠️ "我没预期它们会在通用软件开发上好到今天这个程度，但对重置密码、取得审批这种确定性程序性脚本，定义得太清楚、太可验证了。" ✅ 而早期的示例库脚手架被模型吃掉了："后来模型就是变得太好了，很难给它一个它自动化不了的工作流——只要那些 API 存在。"（⚠️⚠️ 瓶颈从"模型会不会写"转移到"目标系统有没有接口"）
- ⚠️⚠️ SDLC 是采用的解锁条件："大多数新的 AI 产品没有接受这一套，它们基本上在说：我们来建这些酷 agent，然后直接发到生产"；而大金融机构"不会在没有评审、没有用户验收测试和合规检查的情况下就上线新的 agent 能力"。⚠️ 而对"要花一两年想明白"他的回答更强："有些情况下他们永远到不了那儿。有些公司就是看了一眼做企业软件要什么，然后决定：我们并不真想建那个东西。"（[00:17:10]–[00:19:10]）
- ⚠️⚠️ background agent 是"企业软件里的终极登月"，而阻塞条件是自主性："一方面你希望它们非常自主……另一方面，自主性在企业里非常可怕"；方案是能力的渐进升级（agent 申请、人逐项批准确定性工作流），⚠️ 代价是"得盯着那个流程，挺烦人的"，⚠️⚠️ 边界是"否则它理论上就能开始写能在你系统上采取动作的代码，而那是一个无界的安全风险"。被问模型还是 harness："两者都是"——记忆要更好、上下文要大到"一个一直回溯到第一次谈话的单一对话"，⚠️⚠️ "但权限问题会一直是最大的那件事。"（[00:29:17]–[00:32:18]）
- ⚠️⚠️ 按跑过的 workflow 计费而不是按 token："token 更像是啰嗦和低效"；✅ 而他对自己有利的题目给了否定答案："我不知道有谁真的搞清楚了怎么衡量你从买来的那些 token 里得到了什么。" ⚠️ 他的观察是 CIO 在从 token maxing 往回收，但总量仍会上升（"大多数公司还是第一次在搞清楚这件事"），而客户要的是 ROI 证明、不是省钱。（[00:21:11]–[00:23:14]）
- ⚠️⚠️ SaaS 末日的可检验拆分："确实会有一场 SaaS 末日，但发生在 point solution 那类小市值公司身上。我不认为你真能摆脱核心的记录系统——ERP、HRIS、ITSM、CRM……会出现新一代在位者。" ⚠️ 自建派的阻碍是经济学与维护，含一条很具体的组织事实："很多情况下没人真的想在内部工具团队工作。"（[00:23:14]–[00:25:15]）
- ⚠️ "Serval 是你在公司里升职的方式"："它不能是'Serval 是你冒的一个风险'。我们必须让客户相信：你做这件事，你会成就你的职业生涯。" ⚠️ 自述证据是单个客户（Fox 全公司采用，一线主导者被提名全公司 MVP）。
- ⚠️ 从不建定制功能（"而且幸运的是在我们这个类目里，没人要求过"）；定制落在用户自建的自动化里（"Serval 几乎变成了 IT 部门的那个 IDE"）；✅ 而"客户一遍遍建同样的东西"是升级成一等功能的信号（例：检测冲突/过期的知识库文章、回收闲置软件许可）。
- ⚠️⚠️ Catalyst：一个给管理员用来操作平台的 agent——第一代问题是"你得训练人去理解你全部的产品原语"，✅ 现在"你不需要把自己训练成会用 Serval 的人，agent 就是你进入产品的主界面"。🔗 本库记为"文档/培训 → agent"这条位移在五天内的第三个独立样本（另两个是 Anthropic 的"cookbook 在变没用"、Supabase 的"把 Claude 指向一个参考架构"）。
- ⚠️⚠️ 组织：没有产品职能。"我们把产品开发真正下放给了工程团队"；工程师泡在客户 Slack、"大多数每天至少一次客户电话"，比喻是"像沉浸在一个国家里学外语"。✅ 而他承认的代价："我们的产品发得、变得比任何人能跟上的都快，包括我自己"、必须把决策下放、⚠️⚠️ 以及"我最自豪的事情之一，是我们有多少次决定擦掉我们过去做过、而且曾经非常投入的东西"。
- ⚠️⚠️ "因为每个员工的生产力都高这么多，我们其实想要更多的人，不是更少"（理由是"工作的需求是无限的，竞争是无限的，野心是无限的"）。🔗 本库记为"生产力提升 → 更多人"这一结构在本周的第三个样本（另两个是 DoorDash 的需求侧理由、Supabase 的运维不可自动化）。
- ⚠️ 把 IT 当成年人对待："IT 其实比很多人愿意承认的更接近软件工程师。尤其在大企业里，IT 部门在很多情况下就是那支工程团队"；✅ 但"我们不只是把 Claude Code 丢给他们然后说祝你好运"；⚠️⚠️ 而他对既有产品的批评最锋利："外面很多产品其实对 IT 有点居高临下……实际上 IT 欣赏这种复杂度。"
- ⚠️ FDE 是解法（🔗 本库里一处三方分歧的一方）："扩散显然是这里的缺口……而那里面很多就是理解人、流程、到底存在哪些工作流——我们认为这些仍然需要人"；形态是 deployment strategist + deployed software engineer + 持续服务部门（automation engineering）。⚠️⚠️ 与 Decagon 的"FDE 是陷阱"、Cuban 的"如果你需要 FDE，那就把 AI 的水平说完了" 构成三方分歧（✅ 本库判为三方在回答不同问题，真正的分歧只在前两者之间）。