如果让 AI 真正理解一家企业到底需要什么一开始很容易想到的是数据治理、本体、知识图谱、RAG、MCP……但继续往下推会发现一个更基础的问题我们甚至还没有真正把「这个企业的业务世界是什么」说清楚。ERP 里有订单CRM 里也有订单。一个叫order的表是不是销售订单页面上的「提交」究竟意味着业务流程进入了什么状态「已审核」是谁审核的什么情况下可以审核为什么某些订单不能修改「销售额」到底怎么算这些问题往往并不存在于某一个数据库表、某一份接口文档或者某一张本体设计图里。它们散落在企业多年运行形成的各种系统痕迹中。于是我开始重新理解企业业务建模也许首先不是建模而是理解。· · ·一、过去可能把问题想反了谈企业 AI 时经常会出现这样的路径数据↓数据治理↓本体↓知识库↓Agent这条路径当然没有错。但它隐含了一个前提我们已经知道数据代表什么业务。现实中的企业并不是这样。一家运行了十几年甚至几十年的企业可能同时存在ERP CRM MES WMSOA 财务系统 采购系统人力系统 自研系统 第三方 SaaSExcel 各种接口 历史系统而且这些系统往往不是按照今天我们理解的「业务世界」设计出来的。同一个业务对象在不同系统里可能拥有完全不同的名字同一个名字在不同部门又可能代表不同的东西甚至很多真正重要的业务规则从来没有被正式建模过。它们可能只存在于「老员工都知道。」这才是企业 AI 最麻烦的地方。二、本体真正难的地方不是「怎么建」「企业里有哪些对象」「对象之间有什么关系」「订单有哪些状态」「客户和订单是什么关系」这些问题看起来非常简单甚至任何一个懂业务的人都可以回答一部分。真正困难的是你凭什么认为这个答案是真的比如系统里出现/order/list /api/order order_info customer_id order_status我们很容易推断这里应该存在一个「销售订单」。但这只是一个合理猜测。真正的业务事实可能更加复杂·/order可能是采购订单·order_status可能只是系统内部状态· 页面上的「订单」可能包含多个业务概念· 一个订单可能跨越销售、发货、结算三个系统· 数据库里的订单状态和业务人员理解的订单状态可能并不一致。所以我越来越觉得本体不是企业业务理解的起点而更像是理解结果的一种表达形式。真正的问题应该变成我们如何从真实企业系统中逐渐获得对业务世界的可信理解三、也许第一步应该是「观察企业」这让我想到一个很朴素的东西考古。不是让 AI 一上来就告诉我们「这个企业的本体是什么」而是让它首先去观察· 系统里有什么页面是什么· 页面之间怎么跳转· 有哪些表格有哪些字段· 用户会进行什么操作操作之后发生了什么· 调用了哪些 APIAPI 返回了什么· 数据发生了什么变化有哪些错误有哪些状态变化· 文档怎么描述历史行为是什么这些东西本身并不是业务世界。但它们是业务世界留下来的痕迹。于是一个完全不同的思路出现了真实业务系统↓Observation观察↓Evidence证据↓Hypothesis假设↓人的确认与修正↓Business World Model这里最重要的变化是AI 不再直接「猜本体」它先观察再寻找证据然后提出假设最后让业务人员确认。四、Observation 不等于业务知识这是我觉得特别重要的一层。例如系统中存在一个页面/order/list页面里面有客户名称、订单金额、订单状态、创建时间。我们可以记录「/order/list 页面存在一个表格包含四个字段。」—— 这属于 Observation。但不能直接写「这是销售订单。」—— 因为后者已经是业务解释。再比如发现GET /api/order返回{ customer_id: ..., amount: 10000, status: approved }这仍然只是事实。真正的业务语义应该来自后续推理这些页面、接口、字段和行为很可能共同指向某一个业务对象。于是Observation 是事实业务模型是解释。这两个东西必须分开。五、Evidence 可能比「知识库」更加重要如果 AI 说「这是销售订单」我们真正应该问的不是「AI 的置信度是多少」而是你为什么这么认为于是就需要 Evidence。例如SalesOrder │ ├── 页面证据 │ /order/list │ ├── API 证据 │ GET /api/order │ ├── 数据证据 │ order.customer_id │ ├── 行为证据 │ 创建 → 提交 → 审核 │ └── 文档证据 《销售订单管理说明》这样一个业务对象不再只是一个 JSON。它背后有一张Evidence Graph。这件事情的重要性在于企业 AI 的可信度也许不应该来自「模型有多聪明」而应该来自「结论背后有多少可以追溯、可以验证的证据」。甚至还要考虑一个问题证据之间是不是独立的页面、API、数据库字段看起来是三个证据但它们可能实际上都来自同一个后端模型。如果把它们简单相加就会产生虚假的高置信度。所以证据数量不等于证据强度。六、AI 应该先提出 Hypothesis而不是直接下结论这又让我重新理解了 AI 在企业业务建模中的位置。它其实非常适合做一件事情提出假设。例如/order/list、GET /api/order和order_info可能对应同一个业务对象。这不是结论而是 Hypothesis。然后 AI 可以继续寻找证据页面名称一致↓字段结构相似↓API 调用关系一致↓数据库字段可以对应↓用户操作导致相同状态变化↓历史数据行为是否一致如果证据越来越充分这个假设越来越可信如果出现冲突假设进入 Conflict如果证据不足Unknown。这比让 AI 强行回答一个答案要健康得多。七、Unknown 其实比「猜一个答案」更重要这是最近越来越看重的一点。企业 AI 最危险的并不是「不知道」而是不知道却表现得像知道。例如「销售订单超过 100 万必须总经理审批。」如果系统没有足够证据就不应该因为 AI 觉得「企业一般都是这么做的」于是把它写进业务模型。规则大额订单审批规则UNKNOWN· 已有证据页面存在审批按钮、部分历史订单经过审批· 缺失证据无法确定金额阈值、无法确定审批角色、无法确定例外情况这时候 Agent 才能真正说「目前证据不足无法确认企业的大额订单审批阈值。」我觉得这反而是一种更高级的企业 AI。八、于是「本体」开始变成一个结果当我们把这些东西串起来真实系统↓Observation↓Evidence↓Hypothesis↓Human Confirmation↓Business World Model这时候再来看 Ontology就完全不一样了。它不再是「我们坐下来设计一套企业本体」而变成「我们把已经逐渐理解的业务世界结构化表达出来。」Business World Model 里面可能包含Business Object Business RelationBusiness State Business ProcessBusiness Rule Business Metric但每一个元素背后都应该能够追溯· 这个东西是什么为什么这么定义· 来自哪里谁确认的· 有哪些证据哪些地方还不知道· 最近有没有发生变化这时候模型才真正具有企业属性。九、而这又会产生一个非常重要的能力影响分析假设某个 ERP 的接口发生变化。以前API 改了某个报表突然坏了我们往往只能等问题出现。但如果业务世界模型背后存在 Evidence GraphAPI 变化↓Observation 变化↓Evidence 失效↓SalesOrder.customerId 映射受影响↓Customer → SalesOrder 关系受影响↓销售额指标受影响↓相关 Capability 受影响↓Agent 查询能力受影响系统就可以提前告诉我们「这个系统发生了变化它可能影响业务世界模型中的 7 个元素以及 3 个 Agent 能力。」这时候业务建模就不再是一份静态文档而变成了一套持续感知企业变化的系统。十、这也改变了我们对「自动化」的理解最开始很容易产生一个非常诱人的想法能不能让 AI 自己进入 ERP把所有页面都爬一遍然后自动把整个企业本体构建出来技术上当然可以做很多事情。但问题不在于「能不能爬」问题在于业务语义不能简单从页面上被确定。所以更合理的方向可能不是前者而是后者✗ 看似省事AI 自动考古↓自动生成完整本体✓ 更合理AI 自动观察↓AI 自动整理证据↓AI 自动提出假设↓AI 找出不确定区域↓人只处理真正需要判断的问题↓业务世界逐渐形成这时候人的工作就不再是「把整个 ERP 一张表一张表梳理一遍」而更像是「AI 已经替我完成了大量观察和归纳我只需要确认真正具有业务判断价值的地方。」这两种工作量是完全不同的。十一、最终的目标也许不是「建一个本体库」如果 Business World Model 建好了下一步自然会出现一个问题那 Agent 怎么使用答案其实并不复杂。业务世界模型提供对象、关系、状态、规则、指标、证据。然后再把这些模型映射到真实系统中的API、数据库、查询能力、系统操作。于是 Agent 才真正知道我要回答这个问题应该理解哪个业务对象通过什么关系找到数据最后应该调用哪个系统能力。例如用户问「今年华东地区销售额最高的五个客户是谁」Agent 不应该从几十个 API 里盲猜而是用户问题↓Business World Model↓Customer↓SalesOrder↓SalesAmount↓Region↓Query Plan↓对应系统能力这时候 MCP 更像是业务世界与 Agent 之间的执行接口而不是业务知识本身。十二、所以我现在反而不认为 Capability Compiler 越聪明越好这是这套思路里一个很容易走偏的地方。如果 Business World Model 还在持续变化我们没有必要一开始就做一个非常复杂、非常「聪明」的 Capability Compiler。第一阶段真正需要解决的是让已经确认的业务能力稳定地落到真实系统上。也就是说Business World Model↓明确的 Capability↓明确的 Execution Plan↓真实 API / 数据查询↓稳定执行先把这条链跑通而不是一开始就让 Compiler 自己进行大量复杂推理。因为业务世界的理解应该复杂能力执行反而应该尽可能简单、确定。这可能也是企业 AI 系统和普通 Agent 系统非常不同的一点。十三、最后重新理解「企业 AI」如果把这些东西放在一起我现在越来越觉得企业 AI 的核心问题也许并不是「怎样让 AI 更聪明」而是「怎样让 AI 真正理解一个企业」而理解企业并不是把更多文档塞进上下文也不是单纯建设一个更大的知识库更不是先设计一套漂亮的本体。它可能是一个持续的过程观察企业↓积累证据↓形成假设↓寻找反证↓人确认↓形成 Business World Model↓连接真实系统能力↓被 Agent 使用↓系统发生变化↓重新观察↓模型继续演化↻ 持续循环于是一个企业的业务世界不再是一张静态的「知识图谱」它更像是一个活的模型。· · ·结语也许我们真正需要的是「企业世界的感知层」过去我们习惯于数据 → 治理 → 建模 → 应用。但对于一个已经运行多年的复杂企业这条链条可能缺少了一个非常重要的环节理解数据和系统到底意味着什么。而这件事不能完全靠数据库结构解决也不能完全靠 LLM 猜测解决。它需要System Observation Evidence AI Hypothesis Human Judgment Business World Model。最终形成的也许不是传统意义上的「本体」而是一张持续生长的Enterprise Business World Model。它知道企业有哪些业务对象知道它们之间有什么关系知道哪些规则已经被确认知道哪些地方还不知道知道每一个结论为什么成立也知道当真实系统发生变化时哪些业务认知可能已经失效。如果未来 Agent 真正要进入企业或许它首先需要的不是更多工具而是一双能够「看见企业」的眼睛。而这可能才是企业 AI 基础设施下一阶段值得讨论的问题。— END — 企业 AI 真正缺的，可能不是本体，而是理解业务世界的方法
如果让 AI 真正理解一家企业到底需要什么一开始很容易想到的是数据治理、本体、知识图谱、RAG、MCP……但继续往下推会发现一个更基础的问题我们甚至还没有真正把「这个企业的业务世界是什么」说清楚。ERP 里有订单CRM 里也有订单。一个叫order的表是不是销售订单页面上的「提交」究竟意味着业务流程进入了什么状态「已审核」是谁审核的什么情况下可以审核为什么某些订单不能修改「销售额」到底怎么算这些问题往往并不存在于某一个数据库表、某一份接口文档或者某一张本体设计图里。它们散落在企业多年运行形成的各种系统痕迹中。于是我开始重新理解企业业务建模也许首先不是建模而是理解。· · ·一、过去可能把问题想反了谈企业 AI 时经常会出现这样的路径数据↓数据治理↓本体↓知识库↓Agent这条路径当然没有错。但它隐含了一个前提我们已经知道数据代表什么业务。现实中的企业并不是这样。一家运行了十几年甚至几十年的企业可能同时存在ERP CRM MES WMSOA 财务系统 采购系统人力系统 自研系统 第三方 SaaSExcel 各种接口 历史系统而且这些系统往往不是按照今天我们理解的「业务世界」设计出来的。同一个业务对象在不同系统里可能拥有完全不同的名字同一个名字在不同部门又可能代表不同的东西甚至很多真正重要的业务规则从来没有被正式建模过。它们可能只存在于「老员工都知道。」这才是企业 AI 最麻烦的地方。二、本体真正难的地方不是「怎么建」「企业里有哪些对象」「对象之间有什么关系」「订单有哪些状态」「客户和订单是什么关系」这些问题看起来非常简单甚至任何一个懂业务的人都可以回答一部分。真正困难的是你凭什么认为这个答案是真的比如系统里出现/order/list /api/order order_info customer_id order_status我们很容易推断这里应该存在一个「销售订单」。但这只是一个合理猜测。真正的业务事实可能更加复杂·/order可能是采购订单·order_status可能只是系统内部状态· 页面上的「订单」可能包含多个业务概念· 一个订单可能跨越销售、发货、结算三个系统· 数据库里的订单状态和业务人员理解的订单状态可能并不一致。所以我越来越觉得本体不是企业业务理解的起点而更像是理解结果的一种表达形式。真正的问题应该变成我们如何从真实企业系统中逐渐获得对业务世界的可信理解三、也许第一步应该是「观察企业」这让我想到一个很朴素的东西考古。不是让 AI 一上来就告诉我们「这个企业的本体是什么」而是让它首先去观察· 系统里有什么页面是什么· 页面之间怎么跳转· 有哪些表格有哪些字段· 用户会进行什么操作操作之后发生了什么· 调用了哪些 APIAPI 返回了什么· 数据发生了什么变化有哪些错误有哪些状态变化· 文档怎么描述历史行为是什么这些东西本身并不是业务世界。但它们是业务世界留下来的痕迹。于是一个完全不同的思路出现了真实业务系统↓Observation观察↓Evidence证据↓Hypothesis假设↓人的确认与修正↓Business World Model这里最重要的变化是AI 不再直接「猜本体」它先观察再寻找证据然后提出假设最后让业务人员确认。四、Observation 不等于业务知识这是我觉得特别重要的一层。例如系统中存在一个页面/order/list页面里面有客户名称、订单金额、订单状态、创建时间。我们可以记录「/order/list 页面存在一个表格包含四个字段。」—— 这属于 Observation。但不能直接写「这是销售订单。」—— 因为后者已经是业务解释。再比如发现GET /api/order返回{ customer_id: ..., amount: 10000, status: approved }这仍然只是事实。真正的业务语义应该来自后续推理这些页面、接口、字段和行为很可能共同指向某一个业务对象。于是Observation 是事实业务模型是解释。这两个东西必须分开。五、Evidence 可能比「知识库」更加重要如果 AI 说「这是销售订单」我们真正应该问的不是「AI 的置信度是多少」而是你为什么这么认为于是就需要 Evidence。例如SalesOrder │ ├── 页面证据 │ /order/list │ ├── API 证据 │ GET /api/order │ ├── 数据证据 │ order.customer_id │ ├── 行为证据 │ 创建 → 提交 → 审核 │ └── 文档证据 《销售订单管理说明》这样一个业务对象不再只是一个 JSON。它背后有一张Evidence Graph。这件事情的重要性在于企业 AI 的可信度也许不应该来自「模型有多聪明」而应该来自「结论背后有多少可以追溯、可以验证的证据」。甚至还要考虑一个问题证据之间是不是独立的页面、API、数据库字段看起来是三个证据但它们可能实际上都来自同一个后端模型。如果把它们简单相加就会产生虚假的高置信度。所以证据数量不等于证据强度。六、AI 应该先提出 Hypothesis而不是直接下结论这又让我重新理解了 AI 在企业业务建模中的位置。它其实非常适合做一件事情提出假设。例如/order/list、GET /api/order和order_info可能对应同一个业务对象。这不是结论而是 Hypothesis。然后 AI 可以继续寻找证据页面名称一致↓字段结构相似↓API 调用关系一致↓数据库字段可以对应↓用户操作导致相同状态变化↓历史数据行为是否一致如果证据越来越充分这个假设越来越可信如果出现冲突假设进入 Conflict如果证据不足Unknown。这比让 AI 强行回答一个答案要健康得多。七、Unknown 其实比「猜一个答案」更重要这是最近越来越看重的一点。企业 AI 最危险的并不是「不知道」而是不知道却表现得像知道。例如「销售订单超过 100 万必须总经理审批。」如果系统没有足够证据就不应该因为 AI 觉得「企业一般都是这么做的」于是把它写进业务模型。规则大额订单审批规则UNKNOWN· 已有证据页面存在审批按钮、部分历史订单经过审批· 缺失证据无法确定金额阈值、无法确定审批角色、无法确定例外情况这时候 Agent 才能真正说「目前证据不足无法确认企业的大额订单审批阈值。」我觉得这反而是一种更高级的企业 AI。八、于是「本体」开始变成一个结果当我们把这些东西串起来真实系统↓Observation↓Evidence↓Hypothesis↓Human Confirmation↓Business World Model这时候再来看 Ontology就完全不一样了。它不再是「我们坐下来设计一套企业本体」而变成「我们把已经逐渐理解的业务世界结构化表达出来。」Business World Model 里面可能包含Business Object Business RelationBusiness State Business ProcessBusiness Rule Business Metric但每一个元素背后都应该能够追溯· 这个东西是什么为什么这么定义· 来自哪里谁确认的· 有哪些证据哪些地方还不知道· 最近有没有发生变化这时候模型才真正具有企业属性。九、而这又会产生一个非常重要的能力影响分析假设某个 ERP 的接口发生变化。以前API 改了某个报表突然坏了我们往往只能等问题出现。但如果业务世界模型背后存在 Evidence GraphAPI 变化↓Observation 变化↓Evidence 失效↓SalesOrder.customerId 映射受影响↓Customer → SalesOrder 关系受影响↓销售额指标受影响↓相关 Capability 受影响↓Agent 查询能力受影响系统就可以提前告诉我们「这个系统发生了变化它可能影响业务世界模型中的 7 个元素以及 3 个 Agent 能力。」这时候业务建模就不再是一份静态文档而变成了一套持续感知企业变化的系统。十、这也改变了我们对「自动化」的理解最开始很容易产生一个非常诱人的想法能不能让 AI 自己进入 ERP把所有页面都爬一遍然后自动把整个企业本体构建出来技术上当然可以做很多事情。但问题不在于「能不能爬」问题在于业务语义不能简单从页面上被确定。所以更合理的方向可能不是前者而是后者✗ 看似省事AI 自动考古↓自动生成完整本体✓ 更合理AI 自动观察↓AI 自动整理证据↓AI 自动提出假设↓AI 找出不确定区域↓人只处理真正需要判断的问题↓业务世界逐渐形成这时候人的工作就不再是「把整个 ERP 一张表一张表梳理一遍」而更像是「AI 已经替我完成了大量观察和归纳我只需要确认真正具有业务判断价值的地方。」这两种工作量是完全不同的。十一、最终的目标也许不是「建一个本体库」如果 Business World Model 建好了下一步自然会出现一个问题那 Agent 怎么使用答案其实并不复杂。业务世界模型提供对象、关系、状态、规则、指标、证据。然后再把这些模型映射到真实系统中的API、数据库、查询能力、系统操作。于是 Agent 才真正知道我要回答这个问题应该理解哪个业务对象通过什么关系找到数据最后应该调用哪个系统能力。例如用户问「今年华东地区销售额最高的五个客户是谁」Agent 不应该从几十个 API 里盲猜而是用户问题↓Business World Model↓Customer↓SalesOrder↓SalesAmount↓Region↓Query Plan↓对应系统能力这时候 MCP 更像是业务世界与 Agent 之间的执行接口而不是业务知识本身。十二、所以我现在反而不认为 Capability Compiler 越聪明越好这是这套思路里一个很容易走偏的地方。如果 Business World Model 还在持续变化我们没有必要一开始就做一个非常复杂、非常「聪明」的 Capability Compiler。第一阶段真正需要解决的是让已经确认的业务能力稳定地落到真实系统上。也就是说Business World Model↓明确的 Capability↓明确的 Execution Plan↓真实 API / 数据查询↓稳定执行先把这条链跑通而不是一开始就让 Compiler 自己进行大量复杂推理。因为业务世界的理解应该复杂能力执行反而应该尽可能简单、确定。这可能也是企业 AI 系统和普通 Agent 系统非常不同的一点。十三、最后重新理解「企业 AI」如果把这些东西放在一起我现在越来越觉得企业 AI 的核心问题也许并不是「怎样让 AI 更聪明」而是「怎样让 AI 真正理解一个企业」而理解企业并不是把更多文档塞进上下文也不是单纯建设一个更大的知识库更不是先设计一套漂亮的本体。它可能是一个持续的过程观察企业↓积累证据↓形成假设↓寻找反证↓人确认↓形成 Business World Model↓连接真实系统能力↓被 Agent 使用↓系统发生变化↓重新观察↓模型继续演化↻ 持续循环于是一个企业的业务世界不再是一张静态的「知识图谱」它更像是一个活的模型。· · ·结语也许我们真正需要的是「企业世界的感知层」过去我们习惯于数据 → 治理 → 建模 → 应用。但对于一个已经运行多年的复杂企业这条链条可能缺少了一个非常重要的环节理解数据和系统到底意味着什么。而这件事不能完全靠数据库结构解决也不能完全靠 LLM 猜测解决。它需要System Observation Evidence AI Hypothesis Human Judgment Business World Model。最终形成的也许不是传统意义上的「本体」而是一张持续生长的Enterprise Business World Model。它知道企业有哪些业务对象知道它们之间有什么关系知道哪些规则已经被确认知道哪些地方还不知道知道每一个结论为什么成立也知道当真实系统发生变化时哪些业务认知可能已经失效。如果未来 Agent 真正要进入企业或许它首先需要的不是更多工具而是一双能够「看见企业」的眼睛。而这可能才是企业 AI 基础设施下一阶段值得讨论的问题。— END —