AI 代理正在蚕食 SaaS 市场

我们看到的信号

显而易见的地方就是需求开始消失——尤其是对那些"更简单的" SaaS 工具的需求。我相信很多软件工程师已经意识到了这一点——许多我过去会考虑寻找的免费或付费服务，现在我可以让一个 agent 在几分钟内解决，完全按照我的需求。有趣的是，我甚至没有注意到这种转变。它就这样发生了。

如果我想要一个内部仪表板，我甚至都不会想到 Retool 或类似工具会让事情更简单。我就自己构建仪表板。如果我需要重新编码视频作为媒体摄入过程的一部分，我只需让 Claude Code 围绕 ffmpeg 编写一个健壮的包装器——这样就不用承担向单独服务发送原始文件的所有成本（和速度问题），不用处理分级限制，也不用费力理解另一个 API 的设计思路。

对于那些不是纯软件开发的任务来说，这种现象更加明显。例如，我让 Gemini 3 在几分钟内生成了非常高质量的 UI/UX 模型和线框图——不需要使用单独的服务或找模板来开始。同样，当我想做演示时，我不需要使用平台来美化我的幻灯片——我只需让 Claude Code 将我的 markdown 导出为设计精良的 PDF。

我开始看到的另一个、可能影响更大的转变，是人们真正开始质疑大型"企业级" SaaS 公司的续约报价。虽然这还处于早期阶段，但我相信这是一个非常重要的新兴行为。我已经看到了几个例子，其中 SaaS 厂商 X 发送了他们通常的年度两位数百分比价格涨幅，现在团队开始问："我们真的需要支付这笔钱，还是可以自己构建我们需要的东西？"一年前这充其量是一个假设问题，答案很快就是"不"。现在这是一个真实的选项，人们正在花真实的精力思考这个问题。

最后，大多数 SaaS 产品包含许多客户不需要或不使用的功能。SaaS 产品工程中的很多复杂性就来自于管理这些——当你只有一个客户（你的组织）时，这种复杂性一夜之间就消失了。而且，当是同一个人时，这个客户对路线图有完全的控制。不再需要希望 SaaS 厂商优先考虑你的需求而不是其他客户的需求。

维护的反对意见

这种想法的关键反对意见是"谁来维护这些应用？"这是一个真实、正确的反对意见。软件有需要修复的错误、需要解决的扩展问题、需要修补的安全问题，这些都不会改变。

我认为首先重要的是指出，许多 SaaS 维护不周——在我的经验中，往往越贵质量越差。通常，安全风险来自于有外部第三方需要连接和接口访问内部数据。如果你可以将这一切都放在你现有的 VPN 或访问解决方案后面，你突然就能显著减少你的组织的攻击面。

除此之外，agents 本身大幅降低了维护成本。我经历过的一些最痛苦的维护任务——从已弃用的库迁移到另一个有更多支持的库——用 agents 可以显著简化，特别是在静态类型的编程生态中。此外，公司在构建内部工具时最大的犹豫是只有一个人了解一切——如果他们离职，所有内部知识就会消失。Agents 不会离职。而且有一份精心设计的 AGENTS.md 文件，它们可以向将来的任何人解释代码库。

最后，SaaS 也带来维护问题。最近我的一个朋友经历的一个闪光点是，一家 SaaS 公司决定弃用其现有的 API 端点并转向另一组 API，这些新 API 没有所有相同的方法。因为这是一个关键系统，这是一个巨大的问题，需要大量的资源来更新、测试和推出受影响的集成。

我不是在暗示没有真正软件知识的 SME 会突然替换他们整个 SaaS 套件。我确实认为开始发生的是，具有某种程度的技术能力和理解的组织会对他们的 SaaS 采购和供应商生命周期进行更加批判的思考。

SaaS 的经济学问题

SaaS 估值建立在两个关键假设上：快速的客户增长和高 NRR（通常超过 100%）。

我认为我们已经可以看到一个世界，其中某些工具和应用细分市场对新客户的需求开始下降。这是一个问题，会导致这些公司的销售和营销支出增加。

然而，更隐险的是净收入留存率（NRR）的下降。NRR 是衡量现有客户继续与你相关支出的指标，经过客户流失调整。如果你的 NRR 是 100%，你现有的客户群在同一水平上支出。如果低于这个水平，那么他们和你的支出在减少，和/或客户总体在流失。

许多优秀的 SaaS 公司的 NRR 明显高于 100%。这是许多 SaaS 商业模式的美妙之处——公司增长需要向他们的计划添加更多用户。或者他们需要从较低定价层级升级到较高定价层级以获得额外功能。这些增加通常利润非常高。你不需要花一大笔销售和营销费用来获得这种增长（你已经和他们有关系），向 SaaS 产品的客户添加另外 100 个用户许可证的利润率大约是无穷大。

我认为这就是某些 SaaS 公司会被严重打击的地方。人们会开始将解决方案的部分内容迁移到自建/修改的内部平台，以避免为下一个定价层级支付明显更高的费用。或者他们会通过你的 API 从你的平台摄入数据，构建内部仪表板和报告，这意味着他们可以删除 80% 的用户许可证。

不适用的地方（以及仍然有护城河的地方）

显而易见的是任何需要非常高的正常运行时间和 SLA 的东西。达到四个或五个 9 真的很难，构建高可用性系统变得非常困难——而且很容易在构建它们时自己搬石头砸脚。因此，支付处理和其他核心基础设施在我看来非常安全。你（目前）不会用一个 agent 轻易替换 Stripe 及其在核心支付上的所有工程工作。

同样，非常高容量系统和数据湖也很难替换。为巨大的数据集或交易量启动集群并不是微不足道的。这再次需要专业知识，而这种知识在你的组织中可能很短缺，如果存在的话。

另一个是具有显著网络效应的软件——你与人协作，特别是与你的组织外部的人。Slack 是一个很好的例子——你不会用内部工具替换它。同样，具有丰富集成生态和插件市场的产品有真正的优势。

拥有专有数据集的公司仍然非常有价值。财务数据、销售智能等保持有价值。如果有什么的话，我认为这些公司有真正的优势，因为 agents 可以以新的方式利用这些数据——他们会被锁定得更深。

最后，监管和合规仍然非常重要。许多行业需要监管合规——这不会一夜之间改变。

这确实需要你的组织具有内部或外部的技能来管理这些新创建的应用。我认为涉及 SRE 和 DevOps 的产品和人员会看到真正的需求上升。我怀疑我们会看到完全新的职能和团队在公司内部专门用于管理这些新应用。这当然有成本，但这个成本通常可以由现有的 SRE 或 DevOps 职能来管理，或者如果需要新增的人头和基础设施，可以在更多应用上摊销。

对我而言，处于严重风险中的公司是后台工具，基本上只是 CRUD 逻辑——或基于他们客户自有数据的简单仪表板和分析。

这些工具通常产生很多摩擦——因为它们的运作方式与客户想要的方式不完全相同——它们是最容易被 agents 替换的工具。文档化现有系统并告诉 agent 构建某些东西非常容易，但消除了痛点。

SaaS 肯定没有死亡。像任何主要的技术转变一样，有赢家和输家。我确实认为对许多没有明确护城河或专有知识的 SaaS 产品来说，门槛会高得多。

很难预测的是 agents 能多快向价值链上升。我假设 agents 无法管理复杂的数据库集群——但我不确定这在不久的将来还会是这样。

而且我没有看到每家公司突然能够替换所有 SaaS 支出的途径。如果有什么的话，我认为我们会看到（另一次）市场分裂。具有强大内部技术能力的公司与那些没有的公司。这对那些有能力的公司来说是又一个竞争优势——那些没有能力的公司可能会看到成本大幅增加，因为 SaaS 提供商试图从第一组转向第二组（不太能够转换）来弥补一些失去的销售。

但我的关键要点是，如果你的产品只是一个 SQL 包装器在一个计费系统上，你现在有数千个竞争对手：你的客户中的工程师，手里拿着一个 agent，有个充裕的周五下午。