夜雨聆风 | 侯君璠，AI架构陪跑师，清华大学工程管理硕士（MEM），企业架构研究会发起人，国内大型央企单位技术总监、解决方案专家。20余年工作经验，曾任美国某大型科技公司-M中国区首席架构师，国内某大型险资技术总监、某大型科技咨询公司副总裁。深耕于企业架构、人工智能研究与落地方案，以及先进工程项目管理和企业数字化转型等领域。 |
一、AI 融合暴露问题一般不是模型问题，而是语义问题
在当下不少企业在建设AI系统能力融合的时候，比如对于数据中台，知识图谱与AI模型和工具融合时都会遇到一个比较尴尬的问题，部署的模型很强，手中的工具也很多，希望通过这些工具和模型构建出来的子系统也很多，但是真正进入到真正义务执行的时候，发现AI融合进去后只能停留在了问答和业务总结层面
融合的AI只能做一些问答功能，“订单为什么异常”它可以回答，但“这个订单现在是否可以继续履约”却很难可靠判断；“客户风险画像”AI可以总结并进行构建，却很难安全得触发“冻结额度、发起复核、推送工单”这些动作；它可以阅读制度文档，却无法真正理解企业系统中对象、状态、动作、权限、证据之间的关系。
问题在模型本身？并不是，真正的问题在于在企业系统没有给 AI 提供一个可执行的业务世界。传统系统和AI融合时，能提供给AI的资料是一堆表、一堆 API、一堆流程节点、一堆规则引擎和一堆历史数据。这些资料，从局部看它们是正确的，但整体上看好像理解上就不全了，因为这些资料缺乏统一的业务语义。
这也是我们为什么反复去研究Palantir 的 Ontology 。因为它并不是把本体简单理解成了一个静态知识图谱，而是把现实世界的业务对象、关系、状态、逻辑和动作，组织成一个可计算、可治理、可执行的运行时，并且不断的迭代优化。
【企业架构研究会在每个月都会发布相关最新技术研究的研究报告，并且构建不同的社群，如有希望获取的，希望进群一起研讨的，请留言：“进群并获取资料”，我们恭候各位到来，希望与各位有识之士一同研讨中国的企业IT产业和技术发展的方向】
二、传统 App-Centric 架构的三种断裂
让我们来举一个传统的简单例子。一个典型企业订单链路会同时经过 CRM、OMS、Risk、Payment、WMS、Finance、BPM 和 BI 等系统。单独看，每个系统边界清楚、职责明确，也符合传统企业架构的分工逻辑。但一旦从业务对象角度观察，问题就出现了：
比如同一个客户，在 CRM 里叫 Customer，在订单系统里叫 Buyer，在支付系统里叫 Payer，在风控系统里叫 Risk Subject。同一个订单，在 OMS 里是交易记录，在支付系统里是支付载体，在风控系统里是风险事件，在仓储系统里是履约任务，在财务系统里是收入依据。
图1：传统架构的三种断裂。问题不在系统数量，而在语义没有被统一接管。
传统系统的集成一般都是靠 API 编排或工作流拼接完成的，但这些动作没有被表达为统一的业务动作，而是散落在多个系统调用中。因此这就造成了系统和架构的断裂，主要包括：
l对象断裂：同一个现实世界对象，被不同系统建成不同数据模型。它们可能指向同一实体，但在系统中却被建成多个孤立概念。
l状态断裂：一个订单可能同时拥有 order_status、payment_status、risk_status、delivery_status、invoice_status。它们分别正确，但企业缺少一个统一状态机来回答“订单当前真实业务状态是什么”。
l动作断裂：一次“确认履约”可能涉及支付确认、风控校验、库存锁定、发货指令、财务确认、客户通知。
在人工时代，这些断裂是可以靠操作人员经验、制度文档和系统切换来勉强维持的。但在 AI Agent 时代就不行了。AI 不会可不会天然知道 Buyer 和 Payer 是否同一人，也不会天然理解payment_status=SUCCESS这个的意义，这是否意味着订单可以进入 Fulfilled，更不会天然知道某个 API 调用是只读查询，还是会产生生产副作用。
因此，AI 落地企业系统的关键，不是多接几个 API，也不是把更多文档塞进向量库，而是先建立一个可执行的业务语义空间。
三、Gotham、Foundry、AIP 不是产品升级，而是运行时Runtime升级
我们在理解 Palantir的系统和产品时不能只看产品名，也不能只看单个产品的功能。
Gotham、Foundry、AIP 表面上看是不同阶段的产品，但实际上通过对这些系统的组合，它们对应着同一条能力演进链：现实碎片对象化、企业机制运行化、AI 编排语义化。
图2：Palantir 推导链。从现实碎片对象化，到企业机制运行化，再到 AI 编排语义化。
1. Gotham：把非结构化世界变成对象网络
Palantir 的早期业务场景主要来自情报和国防领域。这里的原始材料一般不会是干净的数据库，而是大量非结构化信息：报告、PDF、图像、记录、通信文本、线索材料。
Gotham 的关键价值，不是简单做数据搜索，而是帮助分析人员把现实世界中的碎片信息对象化和关系化。因此这些材料本身无法直接支撑系统准确的分析，并采取成功的行动。它们必须先被转化为可计算对象：人、地点、组织、事件、关系、时间和行动轨迹。。
这对一般的企业系统同样适用。对企业来说，企业里的订单、客户、合同、设备、供应商、工单，本质上是现实世界中的业务对象也不是表。因此也只有当这些对象被语义化建模之后，系统才有可能对它们进行统一理解。
2. Foundry：从数据平台到企业运行机制
如果 Gotham 解决的是“如何从现实碎片中识别对象”，Foundry 解决的是第二个问题：企业不是只有数据，企业还有运行机制。
Palantir 官方文档将 Ontology 定位为组织的 operational layer，位于数字资产之上，并连接这些数字资产与现实世界对象。更关键的是，它不仅包含 objects、properties、links 这类 semantic elements，也包含 actions、functions、dynamic security 这类 kinetic elements。
这句话背后其实是有一个重要判断的，那就是Data其实并不是的企业系统的核心， Data + Logic + Action才是。因为Data 负责表达当前事实，Logic 负责表达企业如何判断，Action 负责表达企业如何改变现实世界，只有这三者结合起来才能完整抽象出一个现实世界。这才是Foundry 相比传统数据平台的关键差异。
传统的数据平台主要是停留在“把数据汇集起来、算出来、展示出来”的功能上。而 Foundry 的 Ontology 在这些基础上进一步把数据接入业务流程和操作动作，让企业不只是看见业务，而是运行业务。
3. AIP：AI 是运行在本体之上不是替代本体
到了 AIP 阶段，很多人会以为重点是对大模型的使用和结合上。但从架构上看，“把 LLM 接进来”不是AIP 的关键，把 AI 放到一个已经被本体约束过的业务运行空间里是AIP的重点。
大模型具备更多的能力，包括生成计划，解释状态，也包括通过AGENT来调用工具，协助操作人员决策。但它不应该直接来不应该直接面对零散的 API,面对数据库,它真正需要的是面对事本体中的对象、关系、函数、动作和权限边界。
因此 AIP 对智能化企业架构的启发是在AI能力构建时应该在本体运行时中理解对象、调用方法、生成动作计划，并接受权限、策略和审计约束不应该绕开本体直接操作系统。
四、Ontology是企业运行时Runtime
很多企业一提到Ontology构建时往往会理解成知识图谱的构建，大家的第一反应是对象、关系、属性、可视化图谱。这种理解并不算错。可是从架构边界来说，知识图谱更多解决“对象之间有什么关系”；企业级 Ontology 的构建还必须解决“对象如何被使用、如何被计算、如何被扩展、如何被治理、如何被执行”，因此它是企业的Runtime。
lObject 让企业拥有统一的业务对象；
lLink 让对象关系具备业务语义；
lState 让对象拥有可解释生命周期；
lMethod 让业务判断变成确定性计算；
lAction 让业务动作具备权限、幂等、副作用声明和审计证据；
lPolicy 与 Audit 则让执行过程可治理、可追踪、可复盘；
Ontology的 Runtime能力不是一个新名字包装，而是 Palantir 三阶段能力演进后的工程收敛结果：Gotham 证明现实世界必须对象化，Foundry 证明企业机制必须运行化，AIP 证明 AI 执行必须语义约束化。
Ontology Runtime= Object + Link + State + Method + Action + Policy + Audit
五、结论：本体即软件
通过以上的研究，我们发现Palantir 产品架构对架构升级的最大启发是一种底层的实现判断：当业务对象、关系、状态、逻辑和动作都被本体接管之后，那么本体就不再是数据模型，而变成了组织运行的软件内核。
因此企业软件的下一阶段，不是继续堆更多应用，也不是继续把更多 API 暴露给 AI。真正思考的方向是把如何把企业核心业务对象建成可计算、可执行、可治理的运行时。
声明：本文核心文字内容由本人亲自撰写，图片由模型生成
【持续未完，敬请关注】
