一句"上季度净收入是多少"，财务和销售可以给出两个都说得通、却对不上的数字。前者说的是已确认收入扣除退款和折扣，后者说的是签约金额扣除签约折扣——两个数字都可能算对，只是回答的不是同一个问题。

一批货原定周三送到，眼看要拖到周五。供应链看板把相关订单全部标红，客服工作台筛出一份需要提前联系的客户名单，自动化系统却没有发出任何提醒。三个系统看的是同一批货，得出的结论却不一样：有些订单周六才需要送齐，周五到货并不算违约；另一些承诺周四交齐，若等到真正逾期才提醒，客户早已错过交付时间。

这两件事看起来无关，其实是同一个问题的两面：不是数据不够，也不是模型不够聪明，而是"业务判断"没有一个唯一的、可复用的出处。

MIT Technology Review Insights 在 2026 年 7–8 月对 400 位年营收 5 亿美元以上企业高管的调研给出了一个直白的答案：55% 的高管把"缺乏业务上下文"列为 AI Agent 洞察质量低下的首要原因，排在第二位的才是数据碎片化或不可访问（45%）。Snowflake 有个更形象的比喻：Agent 每次都像第一天入职的新员工——它能看到仓库里的数据，也会写 SQL，却不知道企业内部该向谁确认，更不知道哪一个定义才是正式版本。

过去比谁答得快，现在比谁答得有依据。一句"上季度净收入是多少"，财务和销售可以给出两个都说得通、却对不上的数字。前者说的是已确认收入扣除退款和折扣，后者说的是签约金额扣除签约折扣——两个数字都可能算对，只是回答的不是同一个问题。

一批货原定周三送到，眼看要拖到周五。供应链看板把相关订单全部标红，客服工作台筛出一份需要提前联系的客户名单，自动化系统却没有发出任何提醒。三个系统看的是同一批货，得出的结论却不一样：有些订单周六才需要送齐，周五到货并不算违约；另一些承诺周四交齐，若等到真正逾期才提醒，客户早已错过交付时间。

这两件事看起来无关，其实是同一个问题的两面：不是数据不够，也不是模型不够聪明，而是"业务判断"没有一个唯一的、可复用的出处。

MIT Technology Review Insights 在 2026 年 7–8 月对 400 位年营收 5 亿美元以上企业高管的调研给出了一个直白的答案：55% 的高管把"缺乏业务上下文"列为 AI Agent 洞察质量低下的首要原因，排在第二位的才是数据碎片化或不可访问（45%）。Snowflake 有个更形象的比喻：Agent 每次都像第一天入职的新员工——它能看到仓库里的数据，也会写 SQL，却不知道企业内部该向谁确认，更不知道哪一个定义才是正式版本。
过去比谁答得快，现在比谁答得有依据。

一、十天之内，Ontology 从概念变成了基础设施

2026 年 11 月的头两周，这个领域接连发生了三件事：

11 月 3 日，Snowflake 在 Expedition 2026 发布 Business Ontology，把"定义、拥有并审批共享业务术语"做成 Horizon Context 中的受治理层，同时发布 Cortex AI Gateway 统一治理 Agent 的行为与开销。其工程博客的标题几乎就是结论——Meaning Before Metrics，先有含义，后有指标。

11 月 12 日，Palantir 宣布 Ontology SQL 与 Ontology SQL Functions 在 Foundry 正式可用：开发者可以直接查询本体中的对象、接口与多对多链接，并把查询发布成带参数的函数，交给不同应用与流程重复调用。

同期，国内标准组织披露《本体建模技术要求》《本体智能平台技术要求》已完成研制并开展首批评测，《本体智能研究报告（2.0）》拟于 2026 年 12 月发布。

把镜头再拉远一点，同一时间窗口里还有几条并行的路线：Microsoft 把 Ontology 放进 Fabric IQ，作为 OneLake 之上的企业语义基础；Databricks 让 Genie 从查询、看板、文档与工单中持续整理组织知识；国内也有厂商从业务场景侧切入，把本体、知识中台与多智能体放在同一套体系里。

换句话说，这不是两三家厂商各自的产品发布，而是数据仓库、办公生态、Lakehouse、运营系统与应用厂商，几乎同时认定了同一件事：企业 AI 的竞争焦点，正在从"谁的模型更强"转向"谁的语义地基更扎实"。 当模型能力逐渐成为可采购的标准件，真正决定 Agent 能否进入生产系统的，是企业有没有把散落在 BI 模型、dbt 项目、流程文档和资深员工经验里的业务知识，变成一层可治理、可复用、可审计的上下文。

二、同一个词，五条路：谁在给 Agent 造"企业词典"

有意思的是，这几家都在用 Ontology 这个词，划定的产品边界却并不重合。把各自的官方定位摆在一起看，会看到五条不同的切入路线：

这不是选型排行榜。五条路线对应的是五类不同的既有系统基础，也对应五种不同的"业务知识从哪来"的答案。

Microsoft 的思路是"把数据提升为业务语言"。 在 Fabric IQ 中，企业定义实体类型、属性、关系、规则与指标，并绑定到 OneLake 数据源；Agent 可以用业务术语提问，而不必理解 SQL/KQL 或底层表名。它天然适合已经把数据、办公与业务系统放在同一生态里的企业——本体的价值，一半来自它连着什么。

Databricks 的思路更偏"让本体自己长出来"。 Genie Ontology 从表、查询、看板、管道、文档、工单、聊天和会议中抽取组织知识，再结合人工标注持续更新，为 Genie One、Genie Code 等 Agent 提供同一份整理后的上下文。它降低的是"从零建模"的成本：对数据资产丰富、分析使用频繁的企业，先让系统把散落的知识整理出来，再谈治理。

这两条恰好补上了另外两条的中间地带：一端是"先有人工批准的正式定义"（Snowflake），一端是"先有可执行的业务对象"（Palantir）。自动整理让冷启动变轻，生态绑定让落地路径变短。

迈富时则是从业务场景侧往回建。 与四家从数据或平台侧切入不同，它先把营销、销售、服务里高频发生的对象、关系和动作固定下来，再让知识中台、多智能体协同与模型调度接在同一套语义上。这决定了它关心的问题不太一样：不是"这张表怎么映射"，而是"一次客户风险处置，Agent 依据什么判断、被允许做哪一步、结果如何回到业务系统"。

两条需要提前说清的边界，会贯穿全文：自动抽取出来的知识，不等于"企业正式认可的定义"；能回答业务问题，也不等于具备安全写回的闭环。另外，这几家产品的可用状态并不一致——有的仍处预览，有的平台已可用但部分子功能仍在预览。平台整体可用不等于每一项能力都可用，选型时应逐项核验，而不是按"是否已正式发布"一刀切。

三、Agent 不缺算力，缺一部"企业词典"

一个 Agent 要正确回答收入问题，需要知道财务部门如何定义"收入"、它与订单和客户是什么关系。这些知识通常不在任何一张表里。团队往往为每个新 Agent 重新构建一遍，构建错了，人们就会基于错误的数字做决策，并从此不再信任 AI。

Snowflake 的解法不是再造一个更大的模型，而是把业务知识从"隐性经验"变成"显性资产"。一条业务定义要真正进入 Agent 的工作范围，至少要回答四个问题：

这里有一条值得所有企业抄下来的治理规则：AI 可以发现线索、整理证据、提出候选；但企业正式认可什么，仍然由人决定。 已审批定义与 AI 推断冲突时，Agent 必须使用已审批定义。新概念先是草稿，已批准定义的修改不会立即覆盖当前版本，审批人和变更记录都会被保留。

Snowflake 还建议把结果分成三档——Governed（直接来自正式指标）、Derived（由正式指标推导并展示公式）、Exploratory（临时 SQL，同时展示查询与风险）。它不会让 Agent 变得无所不知，但做到了另一件更重要的事：当系统无法确定含义时，不再让它静默选择。

有一点在中国企业的语境里尤其容易被跳过：同一个东西，各部门叫法往往不止两种。客户、买家、甲方；订单、单据、工单；还有只在老系统里存在的历史旧称。把标准词、同义词、别名连同所属业务域一起登记，听起来是最朴素的一步，却直接决定了 Agent 能不能听懂业务人员随口说出的那句话。我们在服务企业客户时，往往会把这一步放在建模之前——不是因为它技术含量高，而是因为跳过它，后面所有口径治理都会反复返工。

四、两条最容易被混为一谈的边界：定义治理不等于运营执行

上一章的五条路线里，最常被放在一起比较、也最容易被混淆的，是 Snowflake 和 Palantir 这两条。

Snowflake 首先补的是"企业正式认可什么定义，以及这个定义由什么数据实现"：净收入 是一个业务概念，它属于哪个域、由谁审批、由哪个语义视图计算。Palantir 则把具体对象、当前状态和可执行动作也放进了同一层：Order 是对象类型，Order #1024 是一张具体订单，status = Delayed 是它当前的属性，"重新分配订单"是可以真正修改对象、检查权限并记录副作用的操作。

这不是高低关系，而是分工。行业里甚至出现了第三条路——把语义治理与受控执行分开：本体负责把业务世界说明白，执行系统负责证明任务确实做对了。收益是业务语义保持稳定、工具可以替换；代价是执行侧必须自己补齐权限校验、状态记录、结果验证与失败恢复。

11 月 12 日 Palantir 的那次更新，价值恰恰落在"关系"和"复用"上。Ontology SQL 可以查询对象类型、接口以及多对多链接——一张订单可以分批发运，一批货也可能包含多张订单，开发者不必为了一次查询另外维护一份脱离本体关系定义的关联表。更关键的是 SQL Functions：在 SQL Studio 里把发运批次编号定义为参数，将"预计延期订单"的判断发布成一个函数，Workshop、Actions、Automate 与 Ontology SDK 都可以调用。供应链看板拿结果评估调货方案，客服工作台按客户汇总需要联系的订单，自动化流程决定是否创建待办——三个系统可以呈现不同的内容，但"预计失约"的底层判断来自同一个可复用函数。

需要说清一个容易被混淆的边界：本体里有"动作"这个概念，不等于系统就能安全执行动作。 知道"高风险工单"的定义，不代表有权修改工单优先级；能查询"客户风险等级"，也不等于可以暂停客户账户。语义与权限，始终是两件事。

五、真正的分水岭：一条规则，能不能只写一次

回到那批晚到的货。

发运延迟不等于订单失约，订单失约也不等于客户已经收到预警。 这几种状态各有用途，问题出在不同系统没有明确区分它们：供应链关心发运异常，客服关心客户承诺，自动化系统关心何时触发动作。它们可以保留各自的视角，但凡是判断"哪些订单预计会失约"，就不该各算各的。

更难的是规则会随业务变化。第二位客户同意把承诺交付日从周四改到周五，预计送齐仍是周五，这张订单便可以退出预警名单；但月底复盘履约时，团队仍要追问：原先承诺的周四是否实现？因此，"最初承诺日期"和"客户最新确认日期"不能简单相互覆盖。预警采用哪个日期、什么状态才算客户确认，都必须成为明确的业务条件。否则，客户尚未同意改约，系统却可能因为内部调整了计划日期而提前撤销预警。

这正是"函数化"真正的价值：开发者在函数中更新判断逻辑，保持入参与返回字段不变，再用改约与未确认改约的订单分别验证结果；不同应用可以固定使用某个函数版本，也可以先让客服工作台验证新规则，再决定何时切换自动化流程。函数化的价值不在于消灭所有差异，而在于让每一种差异都能追溯到清楚的业务逻辑。看板显示五笔预计延期订单、客服只需联系三位客户，未必是数据不一致——一位客户可能对应多笔订单。

企业真正减少的，不只是重复 SQL，还有规则分叉之后一轮又一轮的对账、排查和修正。

把这套共识变成工程纪律，靠的是几个不起眼的设计：口径要写成可在线试算、发布前用真实数据验证的函数；模型要有草稿 / 已发布 / 已废弃的状态，改动可追溯、可回滚；客户改约这类变化，应当先在小范围验证新规则，再决定何时让自动化流程切换过去。这些都不是炫技，而是让"一条规则只写一次"在真实组织里能活下来的前提。

六、从"说得对"到"做得对"：本体层与控制面

Snowflake 这次发布里，还有一个容易被 Ontology 话题盖住的部分：Cortex AI Gateway。本体解决 Agent 说什么，网关治理 Agent 怎么干活——跨云、跨框架、跨供应商的连接统一施加策略，Agent 通过 MCP 在企业数据上执行操作时继承为人类用户建立的访问管控；成本可归属到用户、团队、Agent 与应用，并支持硬性限额；每一次模型调用、工具使用与决策都留在客户自己的账户里，可查询、可归因。

于是可以提炼出一个清晰的架构范式：

本体层解决"可信"——答案背后的口径经业务批准、有责任人、可追溯；

控制面解决"可控"——行为受策略约束、成本有上限、决策可审计。

两者缺一，Agent 都只能停在试点阶段。

对企业的现实中，最有价值的差异也不是回答界面，而是能否在同一语义与权限框架下完成一条完整链路：查订单 → 判异常 → 拟方案 → 审批 → 写回 → 验证。这条链路上有三条应当被当作默认前提、而不是可选功能的工程常识：

重要处置保留人工确认。 高风险动作必须经过审批，失败时可接管、可回滚；Agent 可以给出建议，责任主体仍然是人。

上线前先试运行。 数据同步、触发器、规则变更都应在小范围数据上模拟验证，确认映射与条件符合预期后再启用。

模型可以提出定义，不能自动成为定义的批准人。 自动抽取降低了初始维护成本，但权威指标、约束规则和高风险动作仍需明确责任人。

迈富时把这一层做成 OntologyForce——一个以业务对象、关系、规则与动作为核心的企业级本体平台。它的定位不是"再做一个能聊天的 AI 应用"，而是让上述三条常识成为系统的默认配置：动作带前置条件与审批、口径以函数形式统一发布、模型可编译为标准格式交付给其他系统对接。换句话说，它不是替企业回答"AI 能做什么"，而是帮企业把"AI 依据什么做、被允许做什么"写进系统。这也解释了第二章里那条路线的选择：从业务场景侧切入，最终要补上的仍然是语义与执行之间的这一段。

七、别从"全公司大本体"开始

Ontology 最容易踩的坑，恰恰是把它做得太宏大。常见失败模式几乎都是组织问题而非技术问题：建模范围失控长期无法上线、口径未定各部门仍各说各话、上游表变更导致 Agent 错答、工具权限过宽、没有评测基线无法证明改善、Token 与查询成本失控、定义过期无人维护。

更稳妥的起点是一个高价值、边界清晰、可验证的业务域：多系统之间存在语义冲突、任务需要跨实体查询、错误答案代价高、定义有明确负责人、并且能拿到历史任务作为评测基线。先证明这一域的本体能否降低口径错误、人工复核、错误工具调用与每次有效任务成本，再谈扩展。

验证方式也必须克制。设计三组同条件实验：A 组用大模型加原始 schema / 工具描述作为基线，B 组加入文档 RAG，C 组在 B 的基础上加入本体定义、映射、约束和动作契约。模型、任务、权限、数据版本、超时与预算保持一致——不要把换一个更强模型带来的收益，算到 Ontology 头上。同时把业务定义、数据映射、约束规则、动作契约、评测资产分开维护，每类都有负责人、版本和变更流程，而不是全塞进一份越来越长、谁也不敢改的提示词。

中文业务语义还有一道额外的功课。企业术语存在简称、俗称、同名异义和部门差异，用"稳定概念 ID + 中文显示名 + 别名 + 所属领域 + 生效时间"来标识，比单靠中文名称做主键要可靠得多。同样重要的是开放性：业务定义与模型应能导出为 OWL2、SHACL 等标准格式，交付给其他系统按同一套模型对接。本体的价值在于共享，封闭的本体只是一张更大的电子表格——这句话对国内企业尤其适用，因为真正的壁垒从来不是画出一张关系图，而是能跨客户复用的领域实体、约束、动作与测试集。

结语：不赌模型，赌那张分工图

回看这几条路：有人把"先有含义，后有指标"写进产品，有人让业务判断可以被发布成一个函数、供多个系统复用，有人把本体接进已有生态，有人让知识从日常资产里自动长出来，也有人从一次客户风险处置往回建——切入点各不相同，落点却是同一处：给 Agent 一层可治理、可复用、可审计的业务上下文。 标准组织也开始为本体建模立规矩。

模型能力会持续加速，但企业价值不会随模型能力自动扩散。 个人提效较普遍，组织级收益仍稀少；Agent 越来越能干，但口径分歧、规则分叉与执行风险，恰恰会随自主度一起放大。真正稀缺的，从来不是某个最强模型，而是四项组织资产：一张任务级分工图、一套可治理的人机协作流程、一层可持续更新的企业上下文，以及以业务结果为核心的度量体系。

迈富时在服务企业客户时，把这个判断落得比较朴素：不去赌模型哪一代会补齐短板，而是帮客户把"任务分工图"和"企业记忆层"做扎实。前者决定 Agent 今天能接多少活，后者决定模型换了几代之后，这套系统还剩多少是自己的。

别把 AI 战略押在下一代模型上。押在那张会不断重绘、有人负责、能被复核、且始终属于你的分工图上。