原文：Ontology-Oriented Software Development，作者 Peter Wilczynski，Palantir Ontology System Product Lead，2024 年 1 月
软件行业的结构性失败
文章开篇引用 Charlie Munger 的话：“Show me the incentive and I’ll show you the outcome”——这句话直接指向了软件行业的根本问题。
行业产出软件的速度越来越快，但对经济生产力的影响却微乎其微。原因不在技术不够好，而在于整个行业的组织方式出了问题：绝大多数人才在开发模块化组件，而不是将这些组件整合成能真正产生业务成果的企业系统。更讽刺的是，当前的软件架构是为风险投资的回报结构优化的——鼓励零部件供应商之间的零和竞争，而非围绕系统整体性能的正和协作。
结果是一个悖论：过去二十年，零部件层面的改进巨大，但系统层面的改进停滞甚至退化。因为孤立优化的组件越来越难协同变更，零部件变好了，系统反而变僵了。客户购买了”模块化”的承诺，实际得到的是碎片化和僵硬的企业架构。这种技术僵硬甚至渗透进组织文化，造成全面的停滞。
Palantir 的判断是：不存在一个 shrink-wrapped 的产品能解决所有企业的问题。定制化的软件工程必须在客户现场完成（in situ）。要让这条路经济可行，需要一种技术把定制化企业软件开发的边际成本压到零。
这种技术就是 Ontology。
Ontology 到底解决什么问题
文章用一个航空公司的场景来说明。当一架飞机在例行检查中触发了警告灯，组织需要在几分钟内回答三个问题：怎样换机才能最小化旅客影响？哪个机场有对应零件和合格技师？飞机是否需要停飞？
找到最优解需要协调多个系统的数据（机场运营数据库、航班乘客名单、资源管理系统）、逻辑（预测影响、评估风险的模型）和行动（写回决策到运营系统、向相关人员发送通知）。
在传统碎片化架构下，工程师需要学习每个系统的 API、与各自的 IT 团队对接、手动协调不同数据模型。最关键的问题是：这些整合知识被锁在一个又一个孤立的应用里，其他团队无法复用。
Ontology 把这些知识集中到一个共享系统中。它不是另一个数据库，而是将碎片化的 data、logic、action 整合成一个更高层级的抽象。翻译工作只做一次（从各组件的数据模型映射到共享的概念模型），而不是每建一个新应用就重新来一遍。
更重要的是，这种知识会快速复利（compound）：新应用可以直接利用已有的系统整合工作，新组件也能通过与已有概念对齐而快速接入。
代码层面的差距
文章给出了一个直接的代码对比。
传统方式：工程师要写大量与底层系统直接交互的胶水代码——MySQL 连接配置、邮件服务配置、REST API 调用、认证处理。真正的业务调度逻辑只占总代码量的一小部分，大部分代码都花在”连接管道”上。
Ontology-Oriented 方式：使用 Ontology SDK（OSDK），工程师用业务语言编程——不是 rows and columns，而是 Aircraft、FlightSchedule、Airport。碎片化整合的复杂性被封装在 Ontology 内部，客户端代码在更高的抽象层级上运行。
这个对比的关键启示不在于”代码更短”，而在于抽象层级的跃升。就像高级编程语言让程序员不再需要理解硬件组件的实现细节，Ontology-Oriented 的方式让程序员不再需要理解企业架构中各个软件组件的实现细节。OSDK 不是在为 Palantir 的产品提供通用 API，而是在为你的业务提供一套用你自己业务语言编写的 API 工具包。
从应用到 AI：Ontology 为什么能让 AIP 快速落地
软件行业中，更高层级的抽象总是颠覆性的——从最简单的程序开始，但由于结构性优势，最终超越在位者。
Ontology 首先改变了应用开发。它让 low-code 应用更强大（可以调用 code-based 的 data/logic/action 元素），让 low-code 和 pro-code 之间的迁移不需要从头重写，让两种开发方式通过 Ontology 互操作。
但更大的杠杆出现在 AI。文章指出一个关键观察：从一个核心视角看，AI 系统更像应用而非用户——它们直接与 API 交互。因此，构建完整的企业 AI 系统需要一种架构，在其中所有系统都被整合到一个共享的 API 表面上。而 Ontology 恰恰提供了这个表面。
这就是为什么 Palantir 能如此快速地发布 AIP——底层基础设施已经就绪。Ontology 把企业的 data、logic、action 解构并暴露为一个统一的、以决策为中心的模型。这个模型通过三种接口分别服务于不同消费者：
- Natural Language Interfaces（NLI）：让人类和语言 AI 用自然语言与 Ontology 交互
- API：让程序员和 AI 系统直接访问 Ontology
- GUI：为用户提供 Ontology 的可视化表达
文章最后给出了全篇最有力的一句总结：
Realizing the potential of operational AI in an enterprise context is not an AI problem — it’s an ontology problem.
在企业场景中释放 AI 的运营潜力，瓶颈不在 AI 本身，在 ontology。