如果让 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 一上来就告诉我们「这个企业的本体是什么」，而是让它首先去观察：
· 系统里有什么？页面是什么？
· 页面之间怎么跳转？
· 有哪些表格？有哪些字段？
· 用户会进行什么操作？操作之后发生了什么？
· 调用了哪些 API？API 返回了什么？
· 数据发生了什么变化？有哪些错误？有哪些状态变化？
· 文档怎么描述？历史行为是什么？
这些东西本身并不是业务世界。但它们是业务世界留下来的痕迹。
于是，一个完全不同的思路出现了：
真实业务系统
↓
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 Graph：
API 变化
↓
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 —
