> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI代理正在吞噬SaaS
- URL: https://www.hubwiz.com/blog/ai-agents-are-eating-sass/
- Published: 2026-02-05T18:27:26.000Z
- Updated: 2026-02-05T18:27:26.000Z
- Description: 自建与购买的计算方式开始改变。软件吞噬了世界。代理将吞噬SaaS。
- Author: admin
- Tags: INDUSTRY, #Import 2026-10-14 14:41

我们花了十五年时间见证"软件吞噬世界"。整个行业都被软件吞没了——零售、媒体、金融——不胜枚举。过去几十年，随着SaaS工具的激增，各行各业都经历了令人难以置信的颠覆。这导致了大批SaaS公司的涌现——总估值达数万亿美元。

在我上一篇关于AI编程助手是否使软件成本下降了90%的文章中，我主要探讨了市场的*供给*端。如果这个假设成立，那么对SaaS工具的*需求*端会发生什么？我一直在思考软件工程变革带来的二阶和三阶效应。

自建与购买的计算方式开始改变。软件吞噬了世界。代理将吞噬SaaS。

## 1、我看到的信号

最明显的起点是需求开始蒸发——尤其是对于"较简单"的SaaS工具。我相信许多软件工程师已经开始意识到这一点——很多我原本会寻找免费增值版或付费服务的东西，我现在可以在几分钟内让代理解决，完全按照我想要的方式。有趣的是，我甚至没有注意到这种转变。它就这样发生了。

如果我想要一个内部仪表板，我甚至不觉得Retool或类似工具会让它变得更容易。我直接构建仪表板。如果我需要在媒体摄入过程中重新编码视频，我直接让Claude Code围绕ffmpeg编写一个健壮的包装器——而不是产生将原始文件发送到单独服务、触及层级限制或试图在脑海中适应另一个API心智模型的所有成本（和速度）。

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

另一个可能更有影响力的转变是，人们开始真正质疑大型"企业"SaaS公司的续约报价。虽然这还处于非常早期的阶段，但我认为这是一种非常重要的新兴行为。我已经看到几个例子：SaaS供应商X像往常一样发送年度两位数百分比的涨价通知，而现在团队开始问"我们真的需要付这笔钱吗，还是可以自己构建我们需要的？"一年前，这最多是一个假设性问题，会很快得到"不"的结论。现在，这是一个人们正在认真思考的真正选项。

最后，大多数SaaS产品包含许多客户不需要或不使用的大量功能。SaaS产品工程中的许多复杂性就在于管理这些功能——当只有一个客户（你自己的组织）时，这些复杂性会一夜之间消失。同样，当同一个人时，客户可以完全控制路线图。不再希望SaaS供应商优先处理你的请求而不是其他客户的。

## 2、维护的反对意见

对此的主要反对意见是"谁维护这些应用程序？"这是一个真正正确的反对意见。软件有bug要修复、规模问题要解决、安全漏洞要打补丁——这些都不会改变。

我认为首先需要指出的是，很多SaaS的维护状况很差（根据我的经验，往往是越贵的东西质量越差）。通常，安全风险来自于需要连接和接口内部数据的外部第三方。如果你能把这一切都移到你现有的VPN或访问解决方案后面，你突然就能显著减少组织的攻击面。

除此之外，代理本身也能大幅降低维护成本。我经历过的最痛苦的维护任务之一——从弃用的库更新到另一个有更多支持的库——使用代理变得显著更容易，尤其是在静态类型的编程生态系统中。此外，公司构建内部工具最大的犹豫是有一个人了解一切——如果他们离开，所有内部知识就会消失。代理不会离开。通过一个深思熟虑的AGENTS.md文件，他们可以向未来的任何人解释代码库。

最后，SaaS也带来维护问题。我最近从朋友那里看到这个月的一个焦点事件：一家SaaS公司决定弃用他们现有的API端点，迁移到另一套API，而这些API并没有相同的方法可用。由于这是一个必不可少的系统，这是一个巨大的问题，需要大量资源来更新、测试和推出受影响的集成。

我并不是说没有真正软件知识的中小企业会突然取代他们整个SaaS套件。我确实认为开始发生的是，具有一定技术能力和理解力的组织将在他们的SaaS采购和供应商生命周期中更加批判性地思考。

## 3、SaaS的经济问题

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

我认为我们已经开始看到一个世界：某些工具和应用程序领域的新客户需求开始下降。这是一个问题，将导致这些公司的销售和营销支出增加。

然而，更隐蔽的是净收入保留率（NRR）下降。NRR是衡量现有客户持续在你身上花费多少的指标，经过客户流失调整。如果你的NRR是100%，你现有的客户群花费相同。如果低于这个数字，那么他们在你的花费就减少了*或者*总体上有客户流失。

许多优秀的SaaS公司的NRR显著高于100%。这就是许多SaaS商业模式的魅力所在——公司成长，需要更多用户加入他们的计划。或者他们需要从较低价位的层级升级到较高的层级以获得额外功能。这些增长通常是*非常* profitable的。你不需要在销售和营销上花费巨资来获得这种增长（你已经与他们建立了关系），为客户在SaaS产品中添加另外100个用户许可的利润率接近无穷大。

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

## 4、这不起作用的地方（以及仍然有护城河的地方）

显然，任何需要非常高正常运行时间和SLA的东西都很脆弱。达到四个或五个9是非常困难的，构建高可用性系统变得非常困难——而你在构建它们时很容易自找麻烦。因此，支付处理和其他核心基础设施在我眼中是相当安全的。你不会（还）容易地用代理取代Stripe及其在核心支付上的所有工程工作。

同样，非常高容量的系统和数据湖也很难取代。为巨大的数据集或交易量启动集群并不是小事。这再次需要专门的知识，这些知识在你的组织中可能很少见，如果存在的话。

另一个是具有显著网络效应的软件——尤其是与组织外部的人协作时。Slack就是一个很好的例子——你不会用内部工具取代它。同样，具有丰富集成生态系统和插件市场的产品在这里有真正的优势。

拥有专有数据集的公司仍然非常有价值。财务数据、销售情报等保持其价值。如果有什么不同的话，我认为这些公司有真正的优势，因为代理可以以新的方式利用这些数据——它们被更牢固地锁定。

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

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

## 5、谁最危险？

在我看来，真正面临严重风险的是那些后端工具——它们只是CRUD逻辑——或者在客户*自己的数据*之上的简单仪表板和分析。

这些工具通常会产生很多摩擦——因为它们不能按照客户*完全*想要的方式工作——而且它们是最容易被代理替换的工具。记录现有系统并告诉代理构建某些东西是非常容易的，但消除了痛点。

SaaS当然没有死亡。像任何重大技术变革一样，有赢家和输家。我确实认为，对于许多没有明确护城河或专有知识的SaaS产品，门槛会高得多。

难以预测的是代理能以多快的速度沿着价值链攀升。我假设代理无法管理复杂的数据库集群——但我不确定这种情况还会持续多久。

我没有看到每家公司突然取代所有SaaS支出的途径。如果有什么不同的话，我认为我们会看到市场的（又一次）分裂。拥有强大内部技术能力的公司与没有的公司。这成为有这些能力的人的另一个竞争优势——而没有的公司可能会看到显著增加的成本，因为SaaS供应商试图从第一组（更能转向的人）那里失去的一些销售补偿给第二组（不太能切换的人）。

但我的关键结论是，如果你的产品只是计费系统上的SQL包装器，你现在有了数千个竞争对手：客户公司的工程师，星期五下午有代理就能搞定。

---

原文链接: [AI agents are starting to eat SaaS](https://martinalderson.com/posts/ai-agents-are-starting-to-eat-saas/?ref=hubwiz.com)

汇智网翻译整理，发表于标明出处