模型越来越擅长理解自然语言，却不一定真正理解企业的业务世界——这才是企业 Agent 落地真正的门槛：让它在允许的边界内可靠地行动。
这两年 AI Agent 技术发展迅速，工具调用、MCP、Skills、Multi-Agent 及 Workflow 等逐渐形成完整生态。AI 已从简单的代码生成、资料查询，进化到能操作浏览器、调用业务 API 甚至连续工作数小时。
然而，当这些能力进入大型企业复杂业务场景时，挑战随之而来。例如，“找出华东区逾期超过 30 天的客户，按风险等级排序并自动创建跟进任务”这一指令，涉及客户定义、逾期计算规则、权限管理及审批流程等多重业务逻辑。模型往往难以直接理解企业内部 CRM、ERP、财务系统间不一致的数据字段（如 customer_id 与 cust_no）及其背后的业务含义。
核心矛盾：模型擅长自然语言，却缺乏对企业业务世界的深层理解。
过去我们关注如何让 Agent 更“聪明”，现在需转向如何让 Agent 在企业边界内“可靠行动”。这就引出了 Ontology（本体）的概念。
01
企业 Agent 缺的是世界模型
02
五大 Ontology 技术路线
03
Ontology + Agent 实践
为什么说企业 Agent 缺的不是工具，而是一套业务世界模型？
回顾 AI 应用演进：
- Chatbot：解决自然语言交互；
- RAG：基于外部知识库回答问题；
- Tool Calling：调用 API、执行代码；
- Workflow：编排任务流程；
- AI Agent：具备自主规划与执行能力。
上述技术解决了交互、知识获取、能力调用和流程编排，但未解决企业业务语义统一的问题。若将复杂的业务规则全部写入 Prompt，会导致 Prompt 冗长、规则冲突及不同 Agent 间语义不一致，形成难以维护的架构。
解决方案是将业务概念、对象关系、规则和操作能力从 Prompt 中抽离，形成可被多个 Agent 共享的业务模型，即 Ontology。
Ontology 到底是什么？别把它理解成一张更高级的知识图谱
在企业 Agent 工程中，Ontology 是一套组织业务对象、关系、规则、可执行动作和权限约束的语义模型与运行机制。它不同于仅关注存储的数据库或仅关注实体关系的知识图谱，还包含业务逻辑与治理。
| 能力 | 含义 |
|---|---|
| Object | 业务对象 |
| Property | 对象属性 |
| Link | 业务关系 |
| Function | 计算与规则 |
| Action | 业务操作 |
| Security | 权限与治理 |
知识图谱侧重描述世界，操作型 Ontology 还需定义如何安全地改变这个世界。
五大 Ontology 技术路线，背后其实是五种不同的企业需求
1. 操作型 Ontology：Palantir —— 让 AI 能够执行业务
代表方向：Foundry / Ontology / AIP
Palantir 通过 Foundry 整合数据，Ontology 映射业务对象与逻辑，AIP 接入 AI 执行。其核心在于让 Agent 面向业务对象和受控 Action 工作，而非直接操作底层 SQL 或 API，确保身份校验、规则检查及审计闭环。
2. 工业型 Ontology：Siemens —— 理解工业对象与物理世界
代表方向：工业知识图谱、数字孪生、工业语义模型
针对工业场景复杂性，将设备、零部件、传感器、运行状态等对象及工程知识组织起来。需注意，此类技术虽能辅助分析，但执行生产操作仍需严格的安全联锁与授权机制。
3. 图数据库型 Ontology：Neo4j —— 复杂关系与 GraphRAG
代表方向：Neo4j、TigerGraph、GraphRAG
优势在于高效处理复杂关系和多跳查询，结合 GraphRAG 可为模型提供结构化上下文。但图数据库本身不包含完整的 Action、权限控制和事务执行机制，需与其他系统配合。
4. 语义网型 Ontology：Stardog —— 语义标准与知识推理
代表方向：RDF、OWL、SPARQL、语义推理
基于标准化本体语义进行逻辑推理，适用于跨系统集成和复杂领域建模。但语义推理不能替代数据库事务、审批流程和命令校验。
5. 企业生产力语义层：Microsoft —— 组织、协作和业务上下文
代表方向：Microsoft Graph、Microsoft 365 Copilot 生态
聚焦组织中的人、邮件、日历、文件等资源及其关系，支持办公场景下的协作与权限管理。与操作型 Ontology 不同，它更侧重生产力数据和协作上下文。
如果以 Ontology 为核心设计 Agent，架构应该怎么搭？
建议增加一层统一的业务语义与操作能力，包含以下七个方面：
- 业务概念层：统一定义客户、订单等核心概念，消除术语歧义。
- 实体与关系建模：明确对象间的关系、基数、约束及生命周期。
- 数据源映射：通过映射、适配或虚拟化将底层数据暴露为统一业务对象，兼顾数据新鲜度与一致性。
- 规则与约束：将信用额度、审批条件等业务逻辑固化，由可信服务执行，而非依赖模型自由推理。
- 工具与系统集成：将 API 封装为具有明确契约（输入、前置条件、权限、异常处理）的 Action。
- 权限与治理：在服务端链路落实用户身份、角色、数据权限及审计，而非仅写在 Prompt 中。
- 推理、执行与审计闭环：核验执行结果，支持重试、补偿及人工升级，确保业务状态可控。
用一个真实业务场景，看看 Ontology + Agent 到底怎么运行
需求：“找出华东区逾期超过 30 天的客户，按照风险等级排序，并为高风险客户创建跟进任务。”
STEP 01 定义业务对象
STEP 02 定义业务规则
STEP 03 定义 Action
Action 执行前需校验客户存在性、负责人有效性、重复任务及用户权限。
STEP 04 Agent 执行完整流程
关键点：
- Agent 负责理解目标，但不充当业务规则裁判；
- Ontology 提供语义，可信服务执行数据访问与授权；
- Action 执行后必须核验结果，利用幂等键避免重复操作。
Ontology First：企业 Agent 产品架构需要换一种设计顺序
传统开发模式先选模型再补业务规则，导致业务知识分散且难以维护。Ontology First 主张先定义核心业务对象、关系及 Action，构建最小可运行的业务语义层，再逐步扩展。
优势在于复用：同一对象定义和能力可服务于销售、客服、财务等多个 Agent，确保语义一致性与权限统一。
注意：并非所有场景都需要 Ontology。简单问答可用 RAG，固定流程可用 Workflow。Ontology 适用于业务对象多、系统关系复杂、语义不统一、规则频繁变化且对权限审计要求高的场景。
企业 Agent 的下一场竞争，可能是业务世界建模能力
企业 Agent 能力分为三个层次：
- 模型能力：理解问题、推理与计划；
- 工程执行能力：稳定调用工具、处理异常；
- 业务世界能力：理解对象、关系、规则与权限。
前两层决定能否“做完”任务，第三层决定能否“做对”事情。未来，多个 Agent 应共享经过治理的业务语义与能力体系。掌握业务世界建模与受控执行的方法，才是打开企业 Agent 落地大门的关键。
END