【本体论】企业 Agent 缺的是可控业务世界

在 BI 时代，“销售额”口径理解错了，结果通常是一张错误报表。

在 Agent 时代，同样的错误可能触发一次错误行动：追加预算、降低库存、暂停计划，或者向错误的人群发送营销信息。

AI 从回答问题走向操作业务后，风险结构发生了变化。模型是否聪明仍然重要，但企业还需要回答：

• Agent 理解的是哪个客户、订单或计划？
• 它使用的指标和规则是否权威？
• 哪些计算必须由确定性函数完成？
• 它可以调用哪些动作？
• 谁来审批，失败后怎样回滚？
• 决策和结果是否可追溯？

本体论在 AI 时代重新受到重视，不是因为它能替代大模型，而是因为它为大模型提供了一个有对象、有规则、有权限、可以安全行动的业务世界。

语义错误正在变成行动风险

大模型擅长理解语言，却不天然理解企业内部语境。

它不知道“客户”指 CRM 里的合同主体、订单中的购买人，还是物流系统里的收货人；不知道“计划”是广告计划、采购计划还是生产计划；也不知道“收入”采用支付、开票还是回款口径。

只做问答时，系统还能要求用户复核。Agent 获得工具调用能力后，模糊语义会沿着执行链被放大：

Palantir 在解释为什么建设 Ontology 时，把企业决策拆成 Data、Logic、Action 和 Security。

这个拆分提供了一个实用判断：企业 AI 的瓶颈不只是模型能力，还包括数据是否有业务意义、逻辑是否可靠、动作是否被治理、安全边界是否明确。

如果这四部分仍分散在数仓、文档、代码、接口和人员经验中，Agent 只能临时拼接上下文。它可能答对，也可能在缺少关键条件时给出看似合理的方案。

RAG、ChatBI、工作流和 API 工具分别少了什么

当前企业 AI 常见方案已经解决了很多局部问题。

RAG 可以从文档中检索相关内容，为模型补充知识。它适合回答政策、产品手册和历史方案，但找到“良品率”“合格率”和 FTQ 三份材料，并不等于系统知道三者在当前企业是否等价。

ChatBI 或 NL2SQL 可以把自然语言转换为查询。它降低了数据使用门槛，但主要链路仍是“问题—SQL—结果—解释”。当对象跨越多个系统、指标存在多个版本时，模型还需要额外的语义约束。

工作流和 RPA 可以执行固定流程。它们擅长“满足条件 A 就执行动作 B”，但面对需要综合多个对象关系、预测结果和模糊信息的场景，通常需要额外的判断层。

API 工具让 Agent 能够调用业务系统，却把另一类问题暴露出来：接口名称、参数、权限和副作用是按技术系统组织的，不一定等于业务人员理解的动作。

方案	已解决的问题	仍然缺少的部分
RAG	找到相关知识	对象身份、权威口径、动作边界
ChatBI / NL2SQL	用自然语言查数	跨系统对象上下文和执行闭环
工作流 / RPA	自动执行固定步骤	复杂语义和动态判断
API 工具调用	连接外部系统	业务意图、统一权限、审批和审计
指标语义层	统一指标计算	对象关系、业务动作和状态反馈

这些方案都可以成为企业 Agent 的组成部分。问题不在于谁替代谁，而在于是否有一层结构把它们绑定到同一套业务对象上。

这里需要强调：本体论提供的是组合协议，不是又一个孤立工具。

本体论给 Agent 的四项基础设施

对 Agent 来说，企业 Ontology 同时承担四个角色。

上下文

Ontology 告诉 Agent 当前处理的对象是谁，处于什么状态，与哪些对象相关。

用户问“这个计划为什么转化下降”，Agent 可以沿计划找到创意版本、曝光频次、目标人群、商品库存、落地页和历史转化，而不是在所有表和文档里重新猜测查询路径。

业务词典

对象、属性和指标拥有明确定义、权威来源与适用条件。

“ROI”究竟使用支付金额还是归因收入，“库存”是可售库存还是账面库存，不应该由模型根据自然语言临时推断。

工具箱

Ontology 暴露经过治理的 Functions 和 Actions。

Agent 可以调用 ROI、风险评分、预测和优化函数，也可以在授权范围内发起调预算、创建工单、暂停计划等动作。

护栏

权限、参数校验、审批条件和不可执行边界进入对象与动作层。

Agent 只能访问当前用户有权查看的对象，只能调用被授权的动作。高风险动作可以强制人工审批。

这四项基础设施解决的是同一个问题：让 AI 的语言推理落到稳定业务结构上。

确定性逻辑与非确定性推理必须分工

LLM 的优势是理解模糊表达、归纳材料、提出解释和组织方案。企业决策同时包含大量必须可复现的逻辑：

• 指标公式。
• 预算上限。
• 库存约束。
• 审批规则。
• 风控阈值。
• 预测与优化模型。

这些逻辑不适合让 LLM 每次重新生成。

更稳妥的结构是：

假设广告投放 Agent 收到任务：“这个计划消耗太快，帮我处理。”

合理的分工是：

1. LLM 理解“消耗太快”指向预算进度异常。
2. Ontology 定位具体计划及其账户、商品、创意和转化。
3. Function 计算消耗率、ROI、库存风险和预测值。
4. LLM 结合函数结果解释原因并提出调整方案。
5. Action 校验预算范围、权限和审批条件。
6. 审批后写回媒体平台。
7. Action Log 记录过程，后续数据验证效果。

让模型负责理解和编排，让函数负责稳定计算，让 Action 负责受控执行。这比把全部公式、规则和 API 说明写进 Prompt 更容易测试和维护。

从 Copilot 到 Automation 的五级阶梯

企业 Agent 不需要一开始就获得自动执行权。

更合理的路径，是按风险逐级开放能力。

阶段	Agent 能力	产品重点
1. Copilot	查询对象、解释状态	对象准确、语义一致、来源可追溯
2. Decision Support	调用函数、分析原因、生成方案	计算可靠、依据透明
3. Governed Agent	在人工审批下发起有限 Action	权限、校验、审批、回滚
4. Automation	在明确条件内自动执行	阈值、异常处理、人工接管
5. Learning Loop	根据动作结果优化规则和策略	日志质量、效果评估、版本治理

每次升级都应该满足新的门槛。

从 Copilot 到 Decision Support，需要权威指标和可复用函数。进入 Governed Agent，需要 Action、权限、审批和审计。进入 Automation，还需要明确的错误成本、回滚方式和人工接管条件。

这条阶梯也避免了一个常见误区：把“能够调用 API”直接当成“已经是 Agent”。

工具可调用只说明通路已经打通，不代表业务语义正确，也不代表系统被允许安全执行。

产品经理如何构建最小本体闭环

借鉴本体论方法，不需要先购买特定平台，也不需要先设计整个企业的对象宇宙。

从一个结果可验证的业务闭环开始。

1. 选择高价值场景

适合的场景通常具备四个条件：

• 决策频率足够高。
• 当前需要跨多个系统获取信息。
• 结果可以被观察和评价。
• 动作风险可以逐步控制。

广告预算异常处置、库存补货、供应商风险预警和复杂指标问数，都比“建立企业统一知识大脑”更适合作为起点。

2. 识别 5—10 个核心对象

以广告预算异常为例，可以先定义：

• 客户。
• 广告账户。
• 投放计划。
• 创意。
• 商品。
• 预算。
• 消耗。
• 转化。
• 审批单。

每个对象要明确唯一 ID、权威来源、关键属性和状态。

3. 定义关键关系

只保留会影响判断和动作的关系：

• 客户拥有账户。
• 账户包含计划。
• 计划使用创意。
• 计划推广商品。
• 消耗与转化归因到计划。
• 预算调整生成审批单。

关系不是为了把图画得更复杂，而是为了让 Agent 获得必要上下文。

4. 沉淀 3—5 个函数

先选决策中真正会使用的稳定计算：

• 预算消耗率。
• ROI。
• 转化成本。
• 素材疲劳度。
• 库存风险。

每个函数都要说明输入、公式、来源、版本和异常处理。

5. 封装 2—3 个动作

动作要少，并且可以回滚或人工接管：

• 生成调整建议。
• 发起预算调整审批。
• 审批后修改预算。

“直接自动调整所有计划”不适合作为第一阶段。

6. 同时设计权限和审计

明确谁能看成本、谁能修改预算、什么幅度需要审批、谁处理失败，以及动作日志保存什么信息。

权限和 Action 是一组设计，不应该分成两个后续需求。

7. 用真实结果迭代

记录 Agent 使用了哪些对象和函数、给出什么方案、谁做了调整、结果是否改善。

用户经常问不出来的问题、Agent 容易理解错的对象、需要人工反复补充的条件，都是下一轮本体要修正的地方。

如何识别“概念包装”

本体论和 Agent 都容易出现演示效果很好、生产能力很弱的项目。

评审时可以检查八项：

1. 对象是否来自真实业务，而不是给数据表改名。
2. 对象身份和指标口径是否有权威来源。
3. 关系是否能支持真实的上下游影响分析。
4. 函数是否可测试、可复现、可追溯。
5. Action 是否包含参数校验、权限和审批。
6. 执行失败是否可以回滚或人工接管。
7. 结果是否写回权威系统并更新对象。
8. 是否有人长期维护对象、规则和动作版本。

如果一个方案只有聊天窗口、知识库和几十个 API 工具，它可以是有价值的助手，但还不能据此证明企业已经建立可治理的 Agent 操作环境。

如果一个本体项目只有对象关系图和建模数量，也不能证明它进入了业务运行。

判断标准应该落在业务闭环是否真实发生：系统是否基于准确对象形成判断，是否在权限内执行动作，是否记录结果，并且能够用结果修正下一次决策。

本体论不会自动解决的问题

本体论不是可靠性的替代品。

底层数据错误，对象状态依然会错；没有明确业务负责人，指标口径仍然会争议；Action 设计不完整，Agent 仍然可能造成损失；对象和规则长期无人维护，本体也会逐渐脱离现实。

它也不会消除大模型幻觉。它能做的是缩小模型的解释空间，把关键计算交给确定性函数，把工具调用限制在受控动作中，并让决策过程可追溯。

建设成本同样真实存在。历史上的企业本体和语义网项目，多次因为范围过大、维护困难和价值验证周期过长而降温。LLM 降低了自然语言消费门槛，但没有消除对象治理、身份映射、规则维护和组织协同成本。

因此，AI 时代本体论最合理的落地方式不是“大一统”，而是：

从一个高价值业务闭环开始，用少量对象、函数和动作验证价值，再沿真实需求逐步扩展。

系列结论

四篇文章最终可以收束到一个定义：

四篇文章采用同一个定义：本体论是企业对现实业务世界的可执行定义系统。

它不是数据库、数仓、知识图谱、数字孪生或 UEI 的替代品，而是把这些能力组织到稳定业务对象之上。

Palantir 提供了一种工程化样本：用 Object、Property 和 Link 表达业务，用 Function 沉淀逻辑，用 Action 改变状态，用 Security 管理边界，用 Action Log 和 Write-back 完成反馈。

对企业 Agent 来说，这套结构同时是上下文、词典、工具箱和护栏。没有它，AI 更容易停留在问答、查数和裸工具调用；有了它，团队才具备从 Copilot 逐步走向 Governed Agent 和 Automation 的条件。

产品经理不需要先学会写 OWL，也不需要先建设整套平台。更现实的起点，是在需求评审中持续追问：

• 核心业务对象是什么？
• 对象状态如何变化？
• 变化由哪些规则决定？
• 谁可以发起和审批？
• AI 能看什么、算什么、做什么？
• 结果怎样回流和验证？

当这些问题有了稳定答案，企业 AI 才真正拥有一个可以工作的业务世界。

参考资料

• Palantir Why create an Ontology?
• Palantir Agents Overview
• Palantir Action Types Overview
• Palantir Functions on Objects
• Palantir Action Log
• Palantir AIP

---

系列导航

• 上一篇：【本体论 03】Palantir 把业务语义变成操作层