很多 SaaS 产品已经不再与其他 SaaS 产品竞争了。它们正在与可组合的开源 AI 堆栈竞争。
开源 AI 已经达到了一个临界点，许多公司不再需要为每一个狭窄的工作流都单独订阅一个工具。相反，他们可以组装一个由开源模型、编排层、数据库、自动化工具和轻量级界面组成的灵活堆栈，来处理原本由 SaaS 工具负责的越来越多的工作。
这并不意味着 SaaS 已死。
这意味着默认的问题正在从：
“我们应该买哪个工具？”
转变为：
“我们是应该购买这个，还是应该用开源 AI 自己组合一个？”
这是一个重大的变化。
而这之所以发生，是因为开源生态系统不再仅仅为研究实验室、爱好者或基础设施密集型工程团队服务。它正在变得对初创公司、代理机构、运营者以及希望获得更多控制权、更低边际成本和更少供应商依赖的技术团队实用起来。
本文将探讨开源 AI 堆栈到底是什么，它为何开始取代部分 SaaS，哪些类别最易受影响，一个现代的堆栈是什么样的，它在哪些方面胜出，哪些方面仍有不足，以及如何在不让你的公司变成一个维护项目的前提下考虑采用它。
当人们说开源 AI 正在取代 SaaS 时，他们真正的意思是什么
这句话很容易被夸大。
开源 AI 并非在一瞬间取代所有 SaaS 公司。它正在取代的是一类日益增长的、工作流特定、中间件繁重、界面轻薄的产品，这些产品的核心价值越来越容易被复现。
具体来说，这包括围绕以下任务构建的软件：
- 回答内部文档中的问题
- 总结会议或转录文本
- 分类和路由工单
- 生成报告或提案
- 自动化重复的后台任务
- 丰富潜在客户和 CRM 数据
- 构建内部副驾驶 (copilot)
- 从混乱的文档中提取结构化数据
- 创建轻量级客户支持助手
- 通过规则和触发器连接工具
令人惊讶的是，这些类别中的大量 SaaS 产品并没有受到工作流设计上的深层护城河的保护。它们的优势通常来自打包、分发、用户体验和信任——而非来自不可替代的技术核心。
这很重要，因为技术核心正是开源 AI 正在使其变得更便宜、更容易复制的部分。
为什么这种转变现在正在发生
这不仅仅是模型变好了。
这是五个变化同时发生的结果。
- 开源模型现在对许多商业任务来说已经足够好了
最大的突破点不在于开源模型在每个基准测试中都击败了最好的前沿模型。
而在于它们不再需要这样做。
对于许多商业工作流来说，“世界最佳”是不必要的。团队真正需要的是：
- 一致的结构化输出
- 可接受的推理能力
- 强大的摘要能力
- 可靠的检索接地 (retrieval grounding)
- 可接受的延迟
- 隐私和部署控制
这个阈值比前沿模型炒作暗示的要低得多。
在许多用例中，开源模型已经超过了那个阈值。
- 模型周围的基础设施已经成熟
一个模型本身并不能取代一个 SaaS 工具。
一个模型加上：
- 推理层
- 界面
- 检索系统
- 自动化逻辑
- 日志记录
- 权限
- 存储
- 评估
才开始看起来像一个产品。
周边的生态系统才是使开源堆栈变得可行的关键。
- SaaS 的膨胀已经变得昂贵且运营混乱
团队对订阅层层叠加感到厌倦。
每一个新工具都引入：
- 另一张账单
- 另一个登录系统
- 另一次供应商评估
- 另一个数据孤岛
- 另一个集成面
- 另一次续订决策
当一个开源堆栈可以取代三到六个范围狭窄的工具时，其经济性很快就会引起注意。
- AI 原生工作流本质上是可组合的
传统的 SaaS 通常假设固定的工作流。
而开源 AI 堆栈奖励组合。
这意味着公司可以越来越多地构建针对其实际运营量身定制的系统，而不是强迫运营去适应预设的软件假设。
- 控制权正在变得具有战略意义
现在，更多的团队深切关心：
- 他们的数据存放在哪里
- 他们依赖哪个模型提供商
- 大规模使用时成本是多少
- 他们能否更换供应商
- 他们 AI 产品的行为是否可以检查
开源堆栈以许多 SaaS 产品无法提供的方式提供了控制权。
最易受开源 AI 影响的 SaaS 类别
并非所有 SaaS 都同样脆弱。
最容易受影响的类别通常具有四个共同特征：
- 工作流是重复性的
- 界面相对较薄
- “智能”主要是文本转换或路由
- 该产品可以通过组合模型、提示、检索和自动化来重现
最容易受影响的类别
- 内部知识助手 - 许多团队现在构建内部文档聊天系统的速度比他们评估企业 AI 知识工具的速度还要快。
- AI 写作和摘要工具 - 如果核心产品是“输入文本，生成更好的文本”，那么复制的门槛已经急剧下降。
- 基本支持副驾驶 (copilot) 和常见问题解答机器人 - 一旦检索、护栏和升级处理得当，许多支持用例在技术上就不再复杂到需要专门的供应商。
- 带有 AI 层的工作流自动化工具 - 相当一部分“AI 自动化”产品正受到开源编排、API 以及本地或托管模型组合的挑战。
- 潜在客户丰富和研究助手 - 这些工具仍然需要仔细的来源和合规性，但工作流的很大一部分现在可以通过开放数据、适当的数据抓取管道、丰富 API 和 AI 摘要来重现。
- 文档提取和分类软件 - 这是一个主要类别。对于许多结构化文档工作流，团队现在可以结合 OCR、提取管道、验证逻辑和 LLM 来取代昂贵的点解决方案。
较不易受影响的类别
一些 SaaS 仍然更具防御性，因为它依赖于：
- 专有分发
- 专门合规
- 网络效应
- 受监管的工作流
- 深度嵌入式集成
- 企业规模的信任和可审计性
- 独特的数据集或运营记录系统
换句话说，开源 AI 在问题属于工作流智能时最为强大，而不是在护城河是机构信任、分发或基础设施重地的地方。
现代开源 AI 堆栈的实际样子
当人们说“开源 AI 堆栈”时，他们通常描述得过于模糊。
实际上，它通常由几个层次组成。
- 模型层 这是语言或多模态智能所在的位置。典型的选择包括：用于推理和生成的开源权重 LLM、用于低成本分类和提取的较小本地模型、以及用于嵌入、转录、OCR 或重排序的专用模型。关键转变是模型不再是整个产品。它是更大系统中的一个层次。
- 推理层 这是实际服务于模型的运行时。常见模式包括：用于实验和私有工作流的本地运行时、供团队使用的自托管推理服务器、以及在管理 GPU 不必要时使用的托管开源模型提供商。这一层决定了成本、速度、运营复杂性和隐私姿态。
- 检索和数据层 这是将通用模型转变为业务工具的关键。典型组件：Postgres 或其他结构化存储、用于语义检索的向量搜索、文档存储和对象存储、元数据和过滤系统、数据连接器和摄取管道。AI 产品的很大一部分有用性来自这一层，而不是基础模型。
- 编排层 这一层控制系统如何运行。它决定：何时调用模型、使用哪个模型、如何检索上下文、何时调用工具、如何将步骤链接在一起、以及如何处理失败和重试。这就是自动化平台、工作流引擎和 Agent 框架变得有价值的地方。
- 界面层 这是用户实际接触的部分。它可能是：聊天 UI、仪表盘、浏览器扩展、内部管理工具、Slack 机器人、API 端点、或基于表单的工作流屏幕。开源堆栈现在能够竞争的一个关键原因是，许多业务工具并不需要极其复杂的 UI 来交付价值。
- 可观测性和评估层 这是玩具和可靠系统之间的区别。你需要知道：哪些提示运行了、检索到了什么上下文、请求花了多长时间、推理成本是多少、什么失败了、以及输出质量是提高了还是下降了。随着 AI 产品的成熟，这一层正在成为堆栈中战略上最重要的部分之一。
一个堆栈同时取代多个工具的实用示例
考虑一个小型销售或运营团队。
传统上，他们可能会为以下项目分别付费：
- 会议转录
- AI 摘要
- CRM 丰富
- 内部搜索
- 提案起草
- 工作流自动化
- 支持文档搜索
一个现代的开源堆栈可以将其中大部分功能合并到一个内部系统中。
例如：
- 用于通话的转录模型或 API
- 用于存储剧本、转录文本和提案的文档存储
- 用于知识搜索的向量检索
- 用于将摘要路由到 CRM 的工作流引擎
- 用于生成跟进草稿的提示模板
- 供团队访问的仪表盘或聊天 UI
- 用于衡量答案质量和工作流可靠性的评估层
这一个堆栈就可以取代几个狭窄的工具，同时让团队对输出格式、模型选择和成本行为拥有更多控制权。
这恰恰是许多 SaaS 类别容易受到攻击的原因。
不是因为开源 AI 在理论上很强大。
而是因为它越来越能够将多个软件购买行为合并到一个可组合的系统中。
目前最常见的开源 AI 堆栈模式
不同的团队根据其成熟度和目标采用不同版本的堆栈。
模式 1：个人构建者堆栈
这在独立开发者、技术创作者和顾问中很常见。
典型组件：
- 本地或低成本模型运行时
- 简单数据库
- 工作流自动化工具
- 轻量级前端
- 一个检索层
- 一个部署目标
这个堆栈针对速度和成本纪律进行了优化。
模式 2：初创公司内部工具堆栈
这对于正在构建内部副驾驶 (copilot) 或流程自动化的公司来说很常见。
典型组件：
- 托管或自托管模型层
- Postgres + 向量支持
- 文档摄取
- 认证和角色访问
- 工作流引擎
- 日志记录和跟踪
- 管理仪表盘
这个堆栈针对快速内部杠杆进行了优化。
模式 3：代理机构或运营者堆栈
这种模式通常被代理机构用于为自己或客户取代多个重复的 SaaS 工具。
典型用例：
- 潜在客户研究
- 提案生成
- 报告自动化
- 客户支持助手
- 内容工作流
- 接收和路由系统
这个堆栈针对跨项目复用进行了优化。
模式 4：产品化 AI SaaS 替代品堆栈
这是当一个团队停止仅仅在内部使用该堆栈，并将其转变为一个产品时。
在这一点上，堆栈通常会添加：
- 计费
- 多租户
- 细粒度权限
- 更强大的监控
- 反馈和 QA 工作流
- 更强的数据治理
这就是开源组合成为 AI 优先 SaaS 公司的直接威胁的地方。
在这些堆栈中反复出现的工具
具体的堆栈不断变化，但某些类别反复出现。
按层的常见构建模块
层 | 典型的开源选择 | 它们为何重要 |
|---|---|---|
模型 | 开源权重 LLM、嵌入模型、重排序器 | 核心推理和检索质量 |
推理 | Ollama、vLLM、自托管运行时、开源模型 API | 成本、隐私、服务灵活性 |
数据库 | Postgres、pgvector、文档/对象存储 | 结构化和语义记忆 |
自动化 | n8n 及类似的工作流工具 | 连接系统并减少手动操作 |
应用层 | Next.js、React、内部仪表盘、API | 轻量级产品表面 |
聊天/搜索 UI | Open WebUI、自定义界面 | 快速访问内部 AI 工作流 |
可观测性 | Langfuse、追踪工具、自定义日志 | 可靠性、质量和迭代速度 |
认证/后端 | Supabase、自定义认证、托管 DB 层 | 快速产品组装 |
评估 | 提示测试、回归套件、评分标准 | 防止无声的质量退化 |
重要的不是每个工具的确切品牌名称。
重要的是，每个主要层次现在都有可信的开源或开放标准选项。
正是这一点改变了“构建 vs 购买”的决策方程。
为什么团队会选择开源路线，即使 SaaS 更简单
乍一看，SaaS 看起来仍然更简单。
通常也确实如此。
那么，为什么更多的团队选择更艰难的道路呢？
因为在适当的情况下，更艰难的道路在战略上更好。
- 更低的长期成本 - 一个订阅看起来很便宜。七个重叠的订阅就不便宜了。开源堆栈通常具有更高的设置成本和更低的边际成本，尤其是对于内部已经拥有技术人才的团队。
- 更好的定制化 - 大多数 AI 工作流在不同团队之间并不相同。SaaS 工具通常迫使团队采用中等水平的工作流。组合系统让团队可以编码自己的逻辑、提示、审批和检索行为。
- 隐私和数据控制 - 许多企业越来越不愿意将敏感的内部数据通过一连串第三方工具发送，如果他们可以自己托管或管理堆栈的更多部分的话。
- 更少的供应商锁定 - 开源堆栈使切换组件更容易。你可以更改模型提供商、推理策略、UI 层、自动化引擎、评估流程，而无需从头重建整个系统。
- 更快的学习循环 - 当你拥有堆栈时，你会了解工作流实际在哪里中断。这通常比过早购买一个漂亮的黑盒更有价值。
SaaS 仍然明显胜出的地方
一个成熟的分析也必须明确说明这一点：
在许多情况下，SaaS 仍然是更明智的决定。
当你需要以下条件时，SaaS 仍然胜出：
- 立即部署，工程工作量最小
- 合规性、SLA 和采购准备就绪
- 企业支持和明确的责任制
- 为非技术团队提供高度打磨的用户体验
- 深度专有集成
- 不值得为定制所有权而投入战略资源的工作流
- 作为记录系统而非工作流层
这就是为什么最优秀的运营者并不教条。
他们不是因为开源时尚而替换 SaaS。
他们是在经济学、控制权和产品灵活性证明合理时才替换 SaaS。
团队在采用开源 AI 时犯的最大错误
他们试图过早地替换太多东西。
这通常会导致两个糟糕的结果之一。
结果 1：堆栈变成了一个内部科研项目
团队在交付业务价值之前花了数月时间组装基础设施。
结果 2：他们交付了一个脆弱的原型，却把它误认为是一个产品
工作流在演示中运行良好，但在实际使用中崩溃，因为可观测性、权限、评估和恢复逻辑被忽略了。
采用这个堆栈的正确方法不是从头重建你的整个软件堆栈。
而是从一个工作流开始，在这个工作流中：
- SaaS 成本是显而易见的
- 工作流是重复性的
- 逻辑是可解释的
- 控制权的投资回报率很高
这就是开源 AI 表现最佳的地方。
采用该堆栈的更明智的方法
最强大的团队通常遵循一个顺序。
第 1 步：确定一个高摩擦的工作流
好的例子：
- 跨文档和录音的内部搜索
- 重复的报告生成
- 潜在客户资格认定和丰富
- 支持草稿撰写
- 文档提取
第 2 步：首先只重建智能层
不要替换所有东西。
从替换成本最高或灵活性最低的部分开始。
第 3 步：比感觉需要的更早添加可观测性
记录：
- 输入
- 输出
- 检索上下文
- 故障
- 成本
- 延迟
没有这些，你将不知道系统是否在变好。
第 4 步：保持界面简单
一个能用的基本 UI 比一个延迟发布的复杂 UI 要好。
第 5 步：在扩展堆栈之前证明业务价值
一旦一个工作流运行良好，再谨慎扩展。
这就是开源 AI 堆栈如何成为运营杠杆而非技术表演。
对 SaaS 的真正竞争威胁不是模型本身
是组合。
这是许多人仍然忽略的战略思想。
SaaS 公司主要受到威胁的，并不是一个更好的模型。
它们受到威胁的，是一个公司可以越来越多地通过以下方式组合自己的系统的世界：
- 开源模型
- 开源基础设施
- 灵活的自动化
- 商品化数据库
- 轻量级界面
- 可重用的提示和评估层
一旦这成为常态，重心就会转移。
获胜的产品不再自动是拥有最漂亮仪表盘的那个。
它可能是最易于适应、运行成本最低、且最难集成到现有工作流中的那个。
这从根本上改变了竞争格局。
这对创始人和运营者意味着什么
如果你现在正在构建或购买软件，那么实际的教训很简单。
你应该停止把每一个 AI 工作流问题都当作一个软件采购问题。
有时它仍然是。
但越来越多的时候，它是一个堆栈设计问题。
这意味着值得问的问题是：
- 这个工作流在战略上值得拥有吗？
- 我们是否在为一个现在可以复现的东西支付 SaaS 价格？
- 一个可组合的内部堆栈能否取代几个点工具？
- 真正的护城河是在供应商那里，还是仅仅在执行速度和包装上？
- 我们需要一个打磨过的外部产品，还是一个可靠的内部系统？
能够很好地提出这些问题的团队，将在未来几年做出更好的技术决策。
最后的想法
开源 AI 堆栈并没有取代所有 SaaS。
但它正在取代足够多的部分，以至于软件市场被迫进入一个新的现实。
越来越多的工具不再仅仅因为方便就安全。
如果它们的核心价值可以从开源模型、检索、编排、存储和一个薄界面重建，那么它们的类别就面临压力——无论他们是否承认这一点。
这并不意味着每个公司都应该急于自托管所有东西。
它的确意味着旧的假设——先买，只有在绝对必要时才构建——正在变弱。
在 AI 密集型工作流中，一个新的假设正在出现：
当逻辑可复现时，先组合；当信任、规模或复杂性真正证明其合理性时，再购买。
这就是转变。
而对于现代软件的一大块来说，这仅仅是个开始。
