第 19 章：Ontology 与 AI Agent

AI Agent 要真正进入企业，必须站在 ontology 上。

原因很简单：Agent 不是聊天机器人。聊天机器人只需要回答问题，Agent 要感知状态、调用工具、执行动作、改变对象、承担结果。只要涉及行动，就必须知道自己在操作什么对象，遵守什么规则，影响哪些关系。

如果没有 ontology，企业 Agent 很容易变成“会说话但不能真正干活”的系统。

比如一个销售 Agent，如果只接入文档和 CRM 字段，它可以回答客户信息、总结会议、写邮件。但如果它要真正推进销售流程，就必须理解客户对象、联系人对象、合同状态、报价规则、折扣权限、审批流程、风险标记、下一步任务。否则它不知道什么能做，什么不能做。

一个供应链 Agent 也一样。它不能只说“库存有风险”。它要知道哪个库存对象、关联哪些订单、影响哪些客户、有哪些替代供应商、谁能批准调整、调整会影响什么成本和交期。

企业 Agent 的关键能力不是语言，而是对象操作。

这就是 ontology 的意义。它为 Agent 提供一个结构化世界：

没有这套对象世界，Agent 只能猜。

大模型本身擅长语言和模式识别，但企业行动需要确定性、可审计、可追责。一个 Agent 不能因为“觉得可以”就修改合同，不能因为“推测风险低”就放行交易，不能因为“看起来合理”就改供应链计划。

它必须在规则内行动。

所以，未来企业 AI 的核心问题可能不是“哪个模型最聪明”，而是：哪个系统能让模型安全进入企业对象世界。

Palantir AIP 的意义就在这里。它不是简单给企业接入大模型，而是试图把 LLM 放在 ontology、权限、工具和工作流之上，让模型能理解企业对象，并在可控范围内采取行动。

这和普通 AI 应用有很大不同。

普通 AI 应用可能是：用户提问，模型回答。

企业 Agent 应该是：用户提出目标，Agent 识别相关对象，读取状态，理解规则，调用工具，生成方案，必要时请求审批，执行动作，更新对象状态，记录审计，继续反馈。

这就是从问答到操作的变化。

例如：

用户说：“帮我处理这个订单延误。”

没有 ontology 的 AI 可能会写一封道歉邮件。

有 ontology 的 Agent 应该能识别：这是哪个订单对象，延误原因是什么，涉及哪个供应商、哪个客户、哪个合同承诺、哪个库存对象，有哪些替代路线，哪些动作需要谁批准，预计成本如何，客户影响如何，执行后更新哪些状态。

这就是企业 Agent 和聊天机器人的差距。

Ontology 还解决 Agent 的边界问题。Agent 最危险的地方，是能行动但边界不清。它可能访问不该访问的数据，执行不该执行的动作，跳过审批，错误理解状态，造成真实损失。

企业本体论必须和权限、审计、责任绑定。Agent 每一次行动，都应该能回答：

这就是企业 AI 的安全底座。

从公司研究角度看，这会改变我们判断 AI 软件公司的方法。以后不能只看它有没有 Agent 概念，而要看它有没有对象层、权限层、工作流层和行动闭环。

很多所谓 Agent 公司，可能只是“模型 + 工具调用 + UI”。这类产品能做演示，但很难进入复杂企业核心系统。

真正强的企业 Agent 公司，需要理解客户对象世界，能接入业务系统，能处理规则和权限，能被审计，能长期嵌入工作流。

这也是 Palantir 的潜在优势。如果它已经在客户那里建立 ontology，那么接入 AI Agent 时，它比普通模型公司更接近行动层。模型公司有智能，但未必有企业对象世界；Palantir 有对象世界，再把智能接进去，就可能形成企业 AI 操作层。

当然，风险也在这里。Palantir 的 ontology 如果太重、太定制、太依赖交付团队，就可能限制扩张。模型公司和云平台也可能从另一侧切入，建立自己的语义层和工作流层。

所以判断不能停在口号，要看落地证据：Agent 是否真的操作对象？是否进入生产工作流？是否有权限控制？是否带来可衡量结果？客户是否扩大使用？

最后压缩：

AI Agent 要从“会回答”变成“会行动”，必须站在 ontology 上。

模型提供智能，ontology 提供对象世界，权限和规则提供安全边界，工作流提供行动路径。四者合起来，企业 AI 才能真正落地。