本文整理自腾讯架构师同盟发起的谈话类播客「架构达尔文」第一期。主持人为安峰（霁川社内容博主、企业数字化转型顾问），嘉宾为萧然（英派科技 SVP、腾讯云架构师、《领域驱动设计》作者）与张毅（腾讯云架构师）。三位曾在同一家公司共事，这期更像一次老朋友围炉夜话。
当 AI 开始写代码、生成原型、甚至参与决策，架构师还剩下什么工作？这期对谈给出的一个答案是：架构师的工作，可能会从设计软件结构，延伸到设计 AI 能理解和行动的企业知识结构。
这正是腾讯架构师同盟新发起的谈话类播客「架构达尔文」想聊的事，第一期聊的就是最近被反复提起的词------本体论（Ontology）。
软件行业太善于造新名词，而 ontology 听起来又格外玄乎。但它其实并不是新词：本体论探讨的是关于世界存在本质的哲学命题，早在古希腊时期就有了，亚里士多德在前人基础上将其发扬光大，称之为"第一哲学"。不过我们今天用来命名这门哲学的 ontology 一词，直到 17 世纪才出现。
哲学史到此为止。真正值得讨论的是：都 AI 时代了，为什么要把这么一个老古董概念重新搬出来？它到底解决了什么问题？
一、本体论在 AI 时代到底解决什么问题
要回答这个问题，得先从知识管理说起。
知识管理是一个历久弥新的课题。只要你持续学习，大概每半年到一年都会换一种方式来存储知识------从 U 盘随身携带，到云端 Wiki，再到个人博客。对商业组织来说更是如此：每个组织都说自己是"学习型组织"，在知识管理上投了大量精力和金钱；但同样每隔半年，就会有人抱怨知识管理不到位、知识找不到。
嘉宾萧然在讨论中点出一个关键转向：过去知识管理主要是面向人 的，而今天，知识管理还要面向模型。
2023 年大语言模型出现，它具有很强的理解、生成甚至判别能力，而它判别和理解的基础，就是喂给它的知识------我们常说的"上下文"。于是知识管理进入了一个新领域：如何管理知识，才能让大模型更好地理解企业的业务上下文、团队上下文和个人上下文。
找来找去，大家发现知识管理又回到了一个本质问题。而 Palantir 这家公司恰好证明了：借用 ontology 这个概念并加以丰富，构建出一个动态本体，确实很利于 AI（至少是大模型）来消费知识。
所以，本体论在今天重新被重视，本质上是因为------大模型需要一种更高质量、更结构化、更可追溯的企业知识管理方式。
这里有一个容易被忽略的区分：
- RAG、向量数据库解决的是"找知识"------从海量内容里检索出相关片段。
- 本体关注的是"知识之间是什么关系，以及这些关系能支撑什么行动"------它不只是存储，而是把业务概念、规则、行为结构化地组织起来。
换句话说，本体是把知识以一种模型化的方式来构建和管理，专门用来喂给 AI。这是一种形式化的抽象过程，和建模思想一脉相承。
二、Palantir 为什么把本体论重新带火
谈 ontology，几乎绕不开 Palantir。这家公司把哲学意义上的本体做了三处关键改造，让它从"学术概念"变成了"可被 AI 消费的工程产物"。这也是整篇文章最值得拆解的工程锚点。
改造一：从"全行业本体"收缩到"企业上下文本体"
在 Palantir 之前，金融等行业也曾尝试构建覆盖整个产业的统一知识本体------一旦构建起来，产业各方都遵循它，互通互联的好处不言而喻。但这件事从来没有真正成功过。
原因不难理解：不管做多少抽象分层、流程标准化，都没办法规避某个产业在特定社会人文环境下的不确定性和变化参数。想要包罗万象、把所有细节都定义出来，几乎不可能。通讯行业算是相对成功的，但那更多是靠协议而非纯粹的本体。
Palantir 的第一处修改是缩小范围 ：不追求一个产业，不追求全人类，只追求这家企业。企业内部怎么干的，企业上下文是相对清晰的，确定性更大。这是从"产业级"到"企业级"的务实收缩。
改造二：把 Action 放进本体
这是最具颠覆性的一处修改。传统本体主要定义实体、属性、关系，而 Palantir 在模型里增加了 Action（行动） 这个基本单元。
为什么这对 Agent 如此关键？因为智能体不只回答问题，它还会执行动作。如果对象能发生什么行动没有被建模清楚，那 Agent 一旦采取行动，就没人能说清楚这个行动是怎么发生的、为什么发生、作用在了谁身上。
嘉宾指出，本体里的各个实体行为（action），恰恰是让"决策可追溯、过程可解释"成为可能的基础。
嘉宾将其类比为：在动态执行过程中允许模型结构（乃至元模型）持续演进------相当于允许在运行中修改表的 schema。这对传统数据库思维是很大的挑战，也带来了从存储、事务一致性到上层编排的巨大复杂度。
改造三：从知识图谱走向数字孪生
这是 Palantir 的"发明创造"。它把 ontology 从静态知识，升级成了数字孪生。
数字孪生和知识库最大的区别在于：知识库是静态的，而数字孪生可以做模拟。当本体建模到足够完整、与现实结合足够紧密时，企业就可以做沙盘推演，预知采取某个行动方案会带来什么后果。
对谈中引用了辛顿教授的一个观点来表达这种冲击：AI 世界最可怕的一点是，人类世界的 100 年，在 AI 世界里只需要一秒钟或一分钟。
这已经超越了"知识管理"的范畴，走向了真正意义上的数字孪生世界------在 AI 世界里做 simulation，模拟人类 10 年、100 年才会发生的事情。
需要强调的是：不要把 Palantir 当作唯一正确答案。 它是当前被验证有效的路径之一，但还不是终局。Anthropic 走的是另一条路------以 skill 为中心、分布式小颗粒、从任务分解视角延伸出的一整套架构体系，和 ontology 的方式并不相同。当模型能力越来越强、吃掉的东西越来越多时，ontology 是不是迎接 AI 应用的最好方式，现在断言还为时尚早。
三、AI 真的能"理解"本体知识吗
这是一个很本质的疑问。我们定义一个商品属于某个品牌，AI 真的能理解这层关系吗？毕竟我们常听到"今天的 AI 并不能真正理解世界，它只是在推测下一个词"。
李飞飞教授在做世界模型，正是因为她认为大模型需要理解物理原理------苹果一定会下落，不能往上飞。反对者会说这只是"文字接龙"游戏。但反过来，对谈中也提到，随着模型规模继续扩大（从万亿级参数向更大规模演进），"预测下一个 token"这件事是否已经涌现出某种对世界运作规律的理解，仍是一个值得讨论的问题。
但对本文的话题来说，"理解不理解"其实不是最关键的。关键是：能不能被约束。
本体把业务概念、关系和规则显式化后，成为模型推理时必须遵守的上下文约束。图谱关系告诉模型"实际的关联在这里"，reasoning 链路告诉模型"你该沿着什么路径思考"，action 告诉模型"你可以做什么、不能做什么"。某种意义上，这是在给模型加一道 harness（约束带）：只要是知识库里有的知识，就必须取信于它，不能自由接龙。
这确实对对抗幻觉有很大作用。企业级 Agent 的底线不是"看起来聪明"，而是：
- 决策可追溯------为什么这个产品定价是 15 元，得能说出推理过程；
- 过程透明------整个判断和行动经得起审计和检查。
正因如此，对谈中有一个略显尖锐但很有启发的判断：如果一家企业既没有做本体，也没有知识图谱或语义层建模，那么它所谓的"Agent / 智能体"很可能还停留在实验或演示阶段，根本上不了生产。
四、本体论和 DDD：像，但不是一回事
这是架构师读者最关心的部分。本体论火起来时，很多做过 DDD 的人第一反应是："这不就是 DDD 换了层皮吗？"
先承认相似性。二者确实相通：
- 都强调建模（DDD 甚至在书里通篇提的是"模型驱动设计"）；
- 都从业务语言出发；
- 都会讨论实体、属性、关系、行为（DDD 里可能叫 event / behavior，本体里叫 action）；
- 都反对纯技术视角的"数据表建模"，主张以业务视角建模。
这些相似性并非巧合------建模思想都可追溯到面向对象甚至更早，"实体"这个词亚里士多德也在用。
但战略层面，两者差异巨大，思路甚至完全相反。
| 维度 | DDD | 本体论（Palantir 式） |
|---|---|---|
| 核心问题 | 管理软件复杂度 | 管理企业知识并供 AI 消费 |
| 战略方法 | 限界上下文 + 关注点分离 | 追求企业级语义一致性和全局关联 |
| 主要消费者 | 人和确定性软件系统 | AI Agent、决策系统、数字孪生 |
| 建模结果 | 支撑系统设计和代码实现 | 支撑推理、行动、模拟和审计 |
| 典型方法 | 事件风暴、统一语言、聚合、上下文映射 | 实体、关系、Action、动态本体 |
简单说，DDD 是为了让人和系统更好地管理复杂度；本体论是为了让 AI 更好地消费、推理和行动。
DDD 的核心口号是"应对软件的复杂度"。它通过 domain / subdomain 分离、bounded context 来做关注点分离------一个时间点只关注一部分复杂度，把边界划清楚后就好做了。难点在于找到正确的分解视角，对人的抽象能力要求极高。
本体论则不同。它追求的是：能不能构建一个达成共识的、企业级的、包罗万象的模型，让终极的那个决策智能体来消费。 它并不强调一定要划上下文边界，甚至更强调语义的一致性------在全公司对同一业务概念建立统一术语是完全 OK 的。
这引出一个重要判断：DDD 的战术建模方法可以借鉴，但 DDD 的战略分解思想不能直接照搬到本体论里，甚至是有害的。
原因在于：本体论的一个核心 promise 是"可发现（discover）"------靠 AI 去发现之前没发现的关联。如果你已经人为做了 subdomain 和 bounded context 拆分，就等于提前给定了边界，AI 帮不了你发现跨领域的关联。
一个直观的例子：用 DDD 建好模型的分析系统，没法告诉你"一款新产品投放是否具有创新性"------因为你已经锁死了视角。而本体在建模到一定完整程度后，修改本体实例（投放一款新产品），大模型就能消费这个知识、在 AI 世界里做模拟，推演出可能的后果。
所以，如果你只是想做一个 Graph RAG（微软的 Graph RAG 成绩就非常好），在某个 bounded context 范围内做超级自动化，那用 DDD 的方式切上下文完全没问题。但如果你对标 Palantir 式的完整本体，就不要用 DDD 的战略建模思想，否则会害了自己。
还要补充一个关键的技术差异：存储。 DDD 落地时最常见的痛点是 O/R Mapping，配上中国大量使用的 MyBatis 和关系型数据库，常常做不好。而本体在 Palantir 平台里用的是对象存储------它本质上是以业务对象的形式建模，而不是以数据形式建模。很多国内厂商学 Palantir 学不会，根子就在没意识到建模方法已经被改变了。如果只是把本体压扁成关系表，很容易退回传统数据建模思路，而错过本体建模最关键的对象、关系、行动语义。
五、企业落地：难点不是工具，而是人和方法
那么在中国企业里，本体到底落地得怎么样？
金融行业跑得最快。 他们的 IT 化、数字化水平最高。比如做投资分析时要建产业图谱------把整个芯片产业的上下游关系建模进图谱，让大模型据此推理，效果不错。这其实就是一种本体应用。再往前走，账户体系、零售业务、对公业务，金融行业都在系统性推进。
制造业在起步。 一些大型制造企业的 IT 团队做了多年开发，技术人员本身也算是行业内的"业务专家"，他们缺的不是行业知识，而是本体论这套方法，以及从企业全局视角做战略建模的能力。对于 IT 能力较弱的中小企业，要么请专业咨询团队，要么找解决方案架构师来实施落地。
落地过程中，最大的难题不是工具，而是人和方法。
谁来负责本体建设？
Palantir 的经验是 FDE（Forward Deployed Engineer，前置部署工程师）角色。FDE 团队分两部分：
- Echo（回声）团队：懂业务的人，负责把业务语义和关系建模出来；
- Delta 团队：偏技术实现。
这给企业一个启示：本体建设需要既懂业务、又懂建模和技术落地的人。这个角色不是传统意义上的售前、咨询顾问或开发工程师，而是夹在业务现场、建模方法和工程实现之间的复合型角色。但这里有个现实矛盾------业务专家很难主导这件事。因为业务专家都很忙，忙的是自己的专业业务；而且建模要求的是抽象能力，这恰恰是很多业务专家欠缺的。
嘉宾萧然的经验是：与其硬拉业务专家来做建模，不如用 process mining（流程挖掘）收集流程数据，由 FDE 通过流程挖掘还原业务里的关系图谱，再拿这个图谱去跟业务确认。FDE 扮演类似 DDD 里架构师的角色，业务作为参与方参与进来。
缺一套"事件风暴"式的方法论
这也许是当前最大的痛点。DDD 之所以能普及，很大程度上是因为有了 Alberto Brandolini 提出的事件风暴（Event Storming）------它找到了一个切入点，用最简单的方式（从"发生了什么事件"出发）反向追溯聚合和领域模型，系统化地告诉团队如何协作、如何从微观到宏观再回到微观。
有意思的是，事件风暴恰恰选了 Eric Evans 当年最不重视的 event 作为突破口。它本质上是一种业务流程建模，通过流程反向追溯可能的聚合，再找核心实体，是"反向找"的。
本体论目前没有这样一套成熟、可复制的方法论。现在的做法，说白了还是"名词动词法"------找出实体、定义关系、挂上 action，靠经验。哪个环节靠经验，瓶颈就在那里。
嘉宾张毅提到一个很实际的判断：因为缺少方法论，企业招 FDE 时只能看行业经验------找懂这个行业、懂领域知识的人，比懂方法论更重要，因为方法论本身还不成熟。
方法论空白里，藏着机会
一个值得期待的判断：未来一定会出现一套类似事件风暴、但更适合本体构建的方法论。 而且有了 AI 之后，这套方法论可能会比事件风暴更简单高效------让智能体来识别实体、关系、行为，可能比人工快很多。AI 做建模时，本质上也是按"名词动词"的方式在提炼关键信息。
更重要的是，本体有一个 DDD 建模所不具备的优势：它可以被验证。 DDD 建模出来的是一张模型图，没法直接测试；而本体作为 Agent 的基础知识，它和 Agent 的推理过程结合后，质量高不高、对不对，是可以通过真实任务反向验证的------给 AI 跑实例，它就能告诉你答案对不对、本体有没有问题。这能比传统领域建模更快地修正本体质量。
六、从哪里开始做
如果你所在的企业想落地本体，给三步建议。
第一步：从一个业务理解深、痛点明确的领域开始。
不要一上来就做全企业本体。找一个你真正吃透的领域，先把它建模出来。萧然的建议很直接：找到一个企业业务理解比较深刻的领域，从那里开始着手建立本体。
第二步：先做语义层或知识图谱，再逐步走向 Action 建模。
对多数企业来说，第一步不是数字孪生，而是先把核心概念、关系、规则讲清楚。能做到"语义层（semantic）"已经很不容易；能做到把 action 建模清楚、让实体上的行动可追溯可解释（即 kinetic 层），就已经相当有价值；而能做动态数字孪生模拟（dynamic 层），那要求极高，多数企业暂时做不到。
第三步：用 Agent 的真实任务反向验证本体质量。
不要等本体建得"完美"了才用。让智能体去消费它，看它能否支撑可追溯的回答、可解释的行动、稳定的业务决策。验证不通过的地方，就是本体需要修正的地方。
对想学习和实践本体论的业务和技术人员，张毅的建议同样务实：
- 从痛点出发，先想清楚要解决什么问题。 AI 时代学东西很容易，难的是明确学习方向和目标。
- 结合自己的场景，提炼一套小范围、可重复的工作方法。 现在没有放之四海皆准的方法论，但你可以为自己的场景提炼一套方法，实践之后再去调整。
七、架构师的新工作
最后，把视角拉回到"架构师"这个群体。
过去，架构师主要设计系统边界、模块结构和技术方案------这是确定性的、面向人的工作。而在 AI 时代，架构师还需要设计一件事：企业的知识，如何被模型理解、被约束、被行动、被演进。
本体论不会去动你的存量系统------它服务的目的不是改造原有流程型系统，而是为将来的智能体提供底座。它和传统业务系统是并存关系，而非替代关系。
软件大概会长期并存三种形态：经典确定性流程型系统、数据驱动的机器学习系统、以大模型为底座的 Agent 智能体。本体论对第三种友好；放到前两种里，投入产出比就很低了。所以 DDD 并没有过时------它依然在第一种软件里非常有用。
而那个被忽视的"存量系统"问题同样值得关注：99% 的遗留流程型系统还在运行，还在加新功能。大模型其实提供了一个之前没有的手段------让智能体去观测代码改动是不是"散弹枪式修改"（shotgun surgery），判断模型是否需要重构、服务边界该怎么重新划分。可见的未来，这件事会变成"智能体做大部分工作，人做 human-in-the-loop 的判断"。遗憾的是，当前所有亮眼工程都聚焦在 Agent 本身，很少有人关注用 AI 来驱动遗留系统的架构演进。
不过这也许是阶段性的。等 Agent 的热潮稍微沉淀，注意力迟早会回到"怎么通过 AI 把原来的系统演进得更快、更高质量"。
结语
本体论不是一个新名词，也不是 DDD 的换皮。它更像是 AI 时代企业知识基础设施的一种候选答案------把企业的知识建模成 AI 能可靠消费、能推理、能行动、能审计的结构。
真正的问题不是"要不要追这个概念"，而是：
你的企业知识，是否已经到了可以被智能体可靠消费的程度？
如果还没有，也许，是时候重新认识一下这个两千多年前的老概念了。
本文基于「架构达尔文」第一期对谈整理，观点来自对谈现场嘉宾讨论，部分技术细节（如模型参数量、平台具体能力）为嘉宾讨论时的表述，未做独立核实，仅供参考。