SaaS 已死？Palantir 这篇文章真正值得看的不是口号，而是企业软件范式的变化

> 基于 Forbes 文章 *Palantir Says SaaS Is Dead* 的中文提炼。 > 原文链接：https://www.forbes.com/sites/stevebanker/2026/05/16/palantir-says-saas-is-dead/ > 原摘要路径：/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260517-151951-Palantir-Says-SaaS-Is-Dead-232947-038935960-summary.md

一句话

Palantir 说“SaaS 已死”，不是说所有云软件都会消失，而是在说：标准化、模板化、要求企业迁就软件流程的 SaaS，正在被“企业本体 + AI 代码生成 + 业务代理”这种更贴近真实业务的定制化模式挑战。

这篇文章在讲什么

文章围绕 Palantir 部署策略师 Danny Lukus 的观点展开：传统企业软件，尤其是供应链和 ERP/SCM 系统，通常提供一套标准流程，让不同客户套用同一模板。

Palantir 认为，这种方式有两个问题：

1. 太僵硬：真实企业流程往往比标准软件复杂，员工最终还是要用 Excel、手工表格、线下流程补洞。 2. 削弱差异化：如果大家都用同一套标准模板，企业的运营能力就越来越像；即便某家公司提出了改进需求，软件商也可能把类似能力卖给其他客户。

Palantir 的方案是：不要求企业替换 SAP、Oracle 等既有系统，而是在这些系统上方搭一层抽象能力，用自己的平台和 Ontology（本体层）把数据、对象、权限、流程和动作统一起来，再由工程师和 AI 工具快速构建企业专属流程。

Palantir 的核心主张

1. 标准 SaaS 解决不了企业最复杂的业务差异

供应链管理不是简单的软件功能清单，而是由工厂、库存、订单、客户、供应商、运输、财务等大量对象和规则交织而成。

标准 SaaS 能覆盖通用流程，但经常覆盖不了企业真正差异化的部分。于是企业会出现典型现象：系统在用，但关键决策仍然靠 Excel、人工判断和临时脚本完成。

这恰恰是 Palantir 看到的机会。

2. AI 代码生成改变了“定制开发”的成本结构

过去企业自研软件风险高、周期长、成本高，所以购买标准软件是更现实的选择。

但 Palantir 认为，Claude、Codex 等 AI 编码工具让定制化软件开发变得更快、更便宜。forward-deployed engineers 可以直接进入客户现场，快速搭建模型和工作流，根据反馈迭代，而不是先做数月需求调研再启动漫长开发。

这就是文章中“SaaS 已死”的主要逻辑：当定制开发不再那么昂贵，标准 SaaS 的经济优势会被削弱。

3. Ontology 是让 AI Agent 真正可用的底座

文章里最关键的概念不是 Agent，而是 Ontology。

Palantir 所说的 Ontology，可以理解为企业的业务操作层或数字孪生：它定义企业里有哪些对象，比如工厂、设备、产品、订单、库存、客户；这些对象之间有什么关系；谁能看什么数据；哪些动作可以被触发；动作结果如何写回底层系统。

如果没有这一层，AI Agent 很容易变成孤立脚本；有了这一层，Agent 才能在一个可理解、可约束、可追踪的业务环境中协作。

文中的具体例子

文章提到几个细节：

一个典型 Agent 流程可能是：

1. 一个 Agent 判断新采购订单是否出现； 2. 解析订单并匹配主数据； 3. 另一个 Agent 判断库存是否足够； 4. 如果需要生产，再调用调度 Agent 计算生产周期； 5. 调度 Agent 可能使用线性规划等方法给出答案。

作者的怀疑很重要

这篇文章不是单纯替 Palantir 站台。作者明确表达了两个怀疑：

1. 生成式 AI 是否真的能写出可支撑复杂仓库海量交易的代码？ 2. AI 代码生成是否能快速做出真正可扩展的大规模优化算法？

这些怀疑很现实。传统供应链计划软件公司花了几十年优化算法和求解引擎，不是简单几句 prompt 就能完全替代。

所以，更稳妥的判断是：

> AI 会显著降低企业定制流程和自动化原型的成本，但在大规模优化、复杂约束求解、高并发交易处理等场景，还不能轻率认为它已经替代成熟专业软件。

对企业的启发

不要先问“要不要替换 SaaS”

更好的问题是：

> 我们有哪些关键业务流程，名义上在系统里，实际上还靠 Excel、人工判断、邮件、微信群、临时脚本维持？

这些地方往往就是标准软件没有覆盖好的业务缝隙。

先做小型业务本体，而不是直接做大平台

企业可以从一个具体流程开始，例如：

先定义这个流程里有哪些对象、字段、规则、权限和动作，再看 AI 能否帮助生成自动化逻辑。

AI Agent 的价值不在“像人”，而在“嵌入流程”

一个 Agent 不需要拥有通用智能才有价值。只要它能稳定完成一个明确任务，并能与其他 Agent 或系统动作衔接，就可能减少大量人工协调。

可以转发给团队的三个问题

1. 我们现在有哪些流程表面上在系统里，实际上靠 Excel 或人工补洞？ 2. 这些流程里，哪些属于我们真正的运营差异化，而不是通用功能？ 3. 如果只选一个低风险场景，能否用“本体定义 + AI 代码生成 + 小型 Agent”做一个两周原型？

我的判断

“SaaS 已死”是一个过度营销的说法。

但它背后的趋势值得重视：企业软件正在从“购买标准功能”转向“围绕企业自己的业务语义快速生成能力”。

标准 SaaS 不会消失，但它会越来越像基础设施；真正形成差异化的部分，可能会更多发生在标准系统之上的本体层、自动化层和 Agent 协作层。

适合落地的最小动作

如果要把这篇文章转成内部行动，可以从一件事开始：

> 找一个最依赖 Excel 的供应链或运营流程，画出它的对象、规则、异常和人工动作，然后尝试用 AI 生成一个只处理单一异常的小型自动化原型。

不要一开始就做“大模型平台”。先验证一个真实流程中的小闭环。

---

来源限制：本文基于 Forbes 原文摘要和可提取正文整理。文章核心观点大量来自 Palantir 员工表述，缺少第三方深度技术验证；涉及 AI 生成优化模型和大规模可扩展代码的部分，应视为供应商主张，而非已充分证明的事实。