1. 从一次架构评审的翻车现场说起去年年底我参加了一个内部架构评审团队花了三个月搭了一套智能工单系统底层是微服务加规则引擎上层套了个大模型做意图识别。演示当天一切正常直到有人问了一句如果客户上周改过合同条款这周又提了个新需求系统怎么判断该走哪条流程现场沉默了整整十秒。规则引擎里没有这条路径大模型也不知道合同改过——因为合同数据躺在另一个系统的数据库里两边从来没对齐过。这不是个例。我后来陆续接触了七八个号称AI 原生的项目发现一个共性大部分团队把 AI 当成一个外挂的接口而不是系统的组织原则。他们做的事情是传统架构 LLM 调用而不是真正的 AI Native。这两者的差距不是加个模型就能补上的它涉及到对象怎么建模、状态怎么流转、Agent 怎么协作这一整套底层范式。这篇内容我想把这件事讲透。核心围绕两个东西AI Native 方案和类 Ontology 对象建模。前者是一种架构取向后者是一种建模方法。它们之间的关系不是替代而是互补——但很多人把它们搞混了结果做出来的系统既不像传统架构那样可控也不像 AI 原生那样灵活。如果你正在做 AI Agent、企业级智能应用、或者任何需要让系统自己理解业务的项目这篇应该能帮你少走几个月的弯路。2. 传统对象建模在智能场景下到底卡在哪2.1 关系型建模的隐含假设世界是静态的传统系统架构的根基是关系型建模。一张订单表、一张用户表、一张合同表用外键连起来查询的时候 JOIN 一下。这套东西统治了企业软件三十年它的隐含假设是实体是稳定的关系是预先定义好的状态变化是离散的事件。这个假设在传统业务里没问题。订单就是订单用户就是用户字段定好了就不太会变。但一旦引入 AI情况就变了。AI 要处理的是意图上下文语义相似度这类模糊的东西它们没法用外键表达。你没法在数据库里建一个字段叫客户这句话的真实意图因为意图是动态推断出来的不是存储的。我见过最典型的翻车是团队为了支持 AI 查询在订单表旁边加了一堆扩展字段什么intent_hint、context_json、ai_score。半年后这张表有四十多个字段一半没人知道是干嘛的。这就是用关系型思维硬扛 AI 需求的后果。2.2 规则引擎的困境分支爆炸第二个卡点是规则引擎。传统做法是把业务逻辑写成 if-else 或者决策树AI 来了之后团队想的是让模型输出一个分类然后走对应的规则分支。听起来合理实际做起来分支会爆炸。举个例子一个报销审批系统原本规则是金额小于 5000 直属领导批大于 5000 部门总监批。加了 AI 之后你想让它理解这笔报销是否合理于是规则变成金额小于 5000 且 AI 判定合理走 A金额小于 5000 但 AI 判定可疑走 B金额大于 5000 且 AI 判定合理走 C……每加一个 AI 维度分支数翻倍。三个维度就是八条路径五个维度就是三十二条。维护成本指数级上升。这里的关键问题是规则引擎假设条件是可枚举的而 AI 的输出是连续的、概率性的。用离散的框架去接连续的输出必然产生裂缝。2.3 数据孤岛让 AI 变成瞎子第三个卡点最隐蔽也最致命。传统架构里数据按系统划分CRM 管客户ERP 管订单OA 管流程。每个系统有自己的数据库、自己的模型、自己的语义。AI 要做跨系统的推理时它面对的是几套互不兼容的方言。回到开头那个工单系统的例子。合同系统里合同变更是一个事件记录工单系统里需求是一个工单类型两个系统对变更这个词的理解完全不同。AI 拿到的是一堆碎片它没法知道上周改的合同条款和这周提的需求之间有关系因为关系从来没有被显式建模过。这就是为什么很多 AI 项目在 Demo 阶段惊艳一上生产就拉胯。Demo 用的是干净的单源数据生产面对的是割裂的多源数据。3. 类 Ontology 对象建模把关系变成一等公民3.1 Ontology 的核心思想不是分类是关系网络很多人第一次听到 Ontology本体这个词会以为它是更复杂的分类体系。这是个误解。Ontology 的核心不是把东西分门别类而是把实体之间的关系显式建模出来让关系成为可以被推理的一等公民。用生活化的类比传统数据库像一本电话簿你按名字查号码查完就完了。Ontology 像一张社交网络图你不仅知道谁是谁还知道谁认识谁、谁和谁有业务往来、谁最近和谁发生过冲突。当你要判断这个客户该不该给折扣时电话簿只能告诉你他的等级社交网络图能告诉你他和哪些高价值客户有关联、他最近有没有投诉记录、他的合同还有多久到期。Palantir 的 Foundry Ontology 是这套思路最成熟的工业实现。它的做法是把企业里所有的实体客户、订单、设备、事件、文档都抽象成 Object把实体之间的关联抽象成 Link把实体的属性变化抽象成 Action。这三样东西构成了一个可推理、可追溯、可演化的语义网络。3.2 Object、Link、Action 三件套怎么落地具体到实操层面类 Ontology 建模通常包含三个层次Object对象不是数据库表而是业务概念的语义封装。一个客户Object 不只是 id name phone它包含了这个客户的所有相关属性、关联的其他对象、以及可以对这个对象执行的操作。关键是Object 的定义是面向业务语义的不是面向存储的。Link关联显式定义对象之间的关系。比如客户-签订-合同合同-包含-条款条款-触发-工单。这些关系不是查询时临时 JOIN 出来的而是建模时就声明好的。好处是 AI 在做推理时可以沿着 Link 遍历而不是盲目地扫描全表。Action动作定义可以对对象执行的操作以及操作的前置条件和后置效果。比如修改合同条款这个 Action前置条件是合同处于生效状态后置效果是生成一条变更记录并触发关联工单的重新评估。Action 把业务规则从散落的 if-else 里抽出来变成可组合、可追溯的单元。维度传统关系型建模类 Ontology 建模核心单元表、行、列Object、Link、Action关系处理外键 JOIN显式 Link可遍历语义表达字段名 注释对象类型 属性语义变更追踪审计日志Action 链天然可追溯AI 友好度低需大量适配高语义直接可用3.3 为什么这套东西天然适合 AI类 Ontology 建模之所以和 AI 天然契合是因为大模型的推理方式和图遍历的方式高度相似。LLM 处理问题时本质上是在语义空间里找关联、做推断。如果底层数据本身就是一张语义图LLM 的推理路径就能直接映射到图的遍历路径上中间不需要反复做数据翻译。我实测过一个对比同样一个判断客户是否有流失风险的任务用传统宽表喂给 LLM需要先把二十几个字段拼成一段自然语言描述模型经常抓错重点用 Ontology 图喂给 LLM直接把客户节点和它关联的最近事件、投诉记录、合同状态作为上下文传进去模型的判断准确率明显更高而且能给出推理链路——因为该客户近 30 天有 2 次投诉且合同即将到期所以风险高。这个推理链路是可以被验证的不是黑盒。4. AI Native 架构不是加个模型是换套组织原则4.1 AI Native 和AI 赋能的本质区别市面上大量项目自称 AI Native实际上做的是AI 赋能——在原有架构上加一个 AI 模块。这两者的区别用一句话概括AI 赋能是把 AI 当工具AI Native 是把 AI 当组织原则。AI 赋能的典型形态是传统后端 一个/ai/chat接口。用户提问后端调模型模型返回结果后端再处理。AI 是一个被调用的服务系统的骨架没变。AI Native 的形态是Agent 是系统的基本执行单元模型是 Agent 的大脑工具和数据是 Agent 的手脚Agent 之间的协作构成了系统的业务流程。这里没有主流程调用 AI的说法因为流程本身就是 Agent 协作涌现出来的。这个区别听起来抽象落到代码上很具体。AI 赋能的项目里你会看到大量的if (needAI) { callModel() }AI Native 的项目里你会看到 Agent 注册表、工具描述、任务分解器、结果聚合器——整个系统的拓扑结构是围绕 Agent 组织的。4.2 Agent 作为一等公民的架构含义把 Agent 当一等公民意味着几件事第一Agent 有明确的能力边界。每个 Agent 声明自己能做什么、需要什么输入、产出什么输出。这跟微服务的接口定义类似但更强调能力而非接口——因为 Agent 的能力是语义级的不是 API 级的。第二Agent 之间通过语义协作不是通过硬编码调用。传统微服务里A 调 B 是写死的。AI Native 里A 需要完成一个任务它会根据任务描述去寻找能帮忙的 Agent可能是 B也可能是 C取决于当前上下文。这需要一套 Agent 发现和协商机制。第三Agent 的状态是显式的。传统服务是无状态的状态存在数据库里。Agent 需要维护自己的上下文、记忆、当前任务栈。这些状态怎么存、怎么恢复、怎么在 Agent 之间传递是 AI Native 架构必须解决的问题。4.3 分布式 Agent 协作的真实难点我在实际项目里踩过的最大的坑是 Agent 之间的责任边界模糊。举个例子一个订单处理流程拆成了意图识别 Agent库存检查 Agent价格计算 Agent审批 Agent。看起来清晰实际跑起来经常出现意图识别 Agent 觉得这是修改订单库存 Agent 觉得这是新订单两边对同一个请求的理解不一致导致库存被重复扣减。根因是Agent 之间共享的语义没有统一。每个 Agent 用自己的 prompt 理解世界但 prompt 之间没有对齐。解决办法是引入一个共享的 Ontology 层——所有 Agent 都基于同一套 Object 定义和 Link 关系来理解业务这样即使各自的推理路径不同对这是什么对象它和什么有关联的认知是一致的。这就是为什么我说 AI Native 和类 Ontology 建模是互补的AI Native 提供了执行框架Ontology 提供了语义底座。没有 Ontology 的 AI Native 是一盘散沙没有 AI Native 的 Ontology 是一张死图。5. 两套范式在同一个业务场景下的正面对比5.1 场景设定一个跨系统的合同变更处理为了把差异讲清楚我设计一个具体场景某企业有一个合同管理系统和一个工单系统。客户提出合同变更请求系统需要判断这个变更是否影响正在执行的工单如果影响要重新评估工单的优先级和资源分配。这个场景涉及三个核心实体合同、条款、工单。涉及两个关键关系合同包含条款、条款影响工单。涉及一个动作变更合同条款。5.2 传统方案的做法与瓶颈传统方案的做法通常是合同系统收到变更请求更新合同表。触发一个消息通知工单系统。工单系统收到消息根据合同 ID 查询关联工单。对每个工单跑一遍规则引擎判断是否需要调整。瓶颈在哪第一合同和工单的关联关系是查询时推断的不是建模时声明的。如果关联逻辑复杂比如一个条款可能影响多个工单且影响方式不同查询逻辑会变得极其臃肿。第二规则引擎判断是否影响时只能基于结构化字段没法理解条款的自然语言内容。第三整个链路是单向的工单系统的反馈没法回流到合同系统导致合同系统不知道自己的变更造成了什么后果。5.3 AI Native Ontology 方案的做法同样的场景用 AI Native Ontology 的做法建模阶段定义 Contract、Clause、Ticket 三个 Object定义 Contract-contains-Clause、Clause-affects-Ticket 两个 Link定义 ModifyClause 这个 Action声明它的后置效果是触发所有关联 Ticket 的重新评估。执行阶段一个合同变更 Agent接收请求它调用 ModifyClause ActionAction 自动沿着 Link 找到所有受影响的 Ticket把它们的上下文当前状态、资源占用、优先级打包交给工单评估 Agent。工单评估 Agent 结合条款的自然语言内容和工单的当前状态判断影响程度输出调整建议。建议回流到合同系统形成闭环。关键差异关联关系是显式的不需要查询时推断条款内容被 Agent 理解不是被规则匹配反馈是双向的合同系统能看到变更的后果。对比维度传统方案AI Native Ontology关联关系查询时推断逻辑臃肿建模时声明直接遍历内容理解规则匹配无法处理自然语言Agent 理解支持语义判断反馈闭环单向通知无回流双向协作可追溯扩展成本加一个实体要改多处加一个 Object 即可可解释性规则日志碎片化Action 链完整可追溯5.4 成本与收益的冷静评估必须说清楚AI Native Ontology 不是银弹它的前期成本明显更高。建模阶段需要业务专家和技术专家一起梳理实体和关系这个工作量在传统方案里是不需要的。而且 Ontology 的维护需要持续投入业务变了模型要跟着变。收益体现在哪里在需求变化的响应速度上。传统方案里加一个新实体或新关系往往要改数据库、改接口、改规则、改前端牵一发动全身。Ontology 方案里加一个 Object 或 Link其他部分基本不用动因为系统是围绕语义组织的不是围绕流程硬编码的。我的经验是如果业务相对稳定、变化少传统方案更划算如果业务频繁变化、需要跨系统推理、需要 AI 深度参与Ontology 方案的长期收益会覆盖前期成本。别为了追概念硬上先评估自己的业务变化频率。6. 落地路径从现有系统迁移到 AI Native 的实操步骤6.1 第一步识别核心 Object别贪多迁移最容易犯的错是想一次建完整个企业的 Ontology。这是不可能完成的任务。正确做法是从最痛的那个业务场景切入只建这个场景需要的 Object。具体怎么选找那些跨系统查询频繁规则经常改AI 判断准确率上不去的场景。比如客户流失预警、供应链异常处理、合规审查。这些场景的共同点是需要跨多个数据源、需要语义理解、需要动态推理。选好场景后列出这个场景涉及的所有实体。注意是业务实体不是数据库表。一个客户可能对应三张表但在 Ontology 里就是一个 Object。这个抽象过程需要业务人员参与技术人员单独做容易做偏。6.2 第二步用 Link 把孤岛连起来Object 建好后关键是定义 Link。这一步的价值最高也最容易被跳过。很多团队建了一堆 Object但 Link 定义得很随意结果 AI 推理时还是找不到路径。定义 Link 的原则是只定义业务上有意义的关系不定义技术上能连的关系。客户和订单有关系是业务关系客户表和订单表有相同字段是技术关系后者不该进 Ontology。实操建议拿一张白纸把核心 Object 画成圈然后问业务人员这两个东西之间有什么关系。他们说的每一句话都可能是一条 Link。比如客户投诉会影响他的信用评级这就是一条 Complaint-affects-CreditRating 的 Link。6.3 第三步把规则改写成 Action传统系统里的业务规则散落在代码、配置、存储过程里。迁移到 AI Native 时需要把它们抽出来改写成 Action。改写的方法对每条规则问三个问题——它作用于哪个 Object它的前置条件是什么它执行后改变了什么把答案填进 Action 的定义里。举个例子规则金额大于 10000 的报销需要总监审批改写成 Action 就是作用于 Expense Object前置条件是 amount 10000后置效果是创建一个 ApprovalTask 并指派给 Director 角色。这样规则就从代码里的 if变成了可被 Agent 调用的动作。6.4 第四步让 Agent 接管但保留人工兜底Agent 接管不是一蹴而就的。我的建议是分三阶段第一阶段Agent 只做建议不做决策。它输出判断和理由人工确认后执行。这个阶段用来积累信任和收集反馈。第二阶段Agent 做低风险决策高风险决策仍走人工。比如金额小于 1000 的自动处理大于的转人工。第三阶段Agent 做大部分决策人工只处理异常。这时候需要建立完善的监控和回滚机制确保 Agent 出错时能快速止损。关键提醒无论哪个阶段都要保留完整的 Action 日志。Agent 的每一步推理、每一次 Action 调用都要可追溯。这不仅是合规要求也是排查问题的唯一依据。6.5 第五步建立 Ontology 的演化机制Ontology 不是建完就完了。业务在变模型必须跟着变。但变化不能随意否则会破坏已有 Agent 的推理逻辑。我的做法是建立一套版本化的 Ontology 管理机制每次修改 Object 或 Link都要记录版本、影响范围、迁移方案。新增字段是安全的删除字段要评估影响修改 Link 语义要格外谨慎因为它可能改变多个 Agent 的推理路径。这套机制听起来重但比改完发现线上 Agent 全乱套要轻得多。我见过一个团队因为改了一个 Link 的方向导致三个 Agent 的判断逻辑全部反转排查了两天才找到原因。7. 几个容易踩的坑和我的应对经验7.1 坑一把 Ontology 做成超级数据库最常见的误解是把 Ontology 当成一个集中式的大数据库把所有数据都往里塞。结果建出来的东西又大又慢Agent 查一次要等好几秒。正确的做法是Ontology 存的是语义和关系不是原始数据。原始数据还在各自的系统里Ontology 只存 Object 的标识、关键属性、以及 Link。Agent 需要详细数据时通过 Object 的标识去源系统取。这样 Ontology 保持轻量查询快也避免了数据同步的一致性问题。7.2 坑二Agent 的 prompt 和 Ontology 脱节第二个坑是 Agent 的 prompt 里硬编码了业务概念和 Ontology 的定义不一致。比如 Ontology 里客户包含潜在客户和活跃客户两个子类型但 Agent 的 prompt 里只写了客户导致它把潜在客户也当成活跃客户处理。解决办法是Agent 的 prompt 应该从 Ontology 动态生成而不是手写。至少Object 和 Link 的定义要作为 prompt 的一部分注入。这样 Ontology 变了Agent 的理解自动跟着变。7.3 坑三忽视 Action 的幂等性Agent 调用 Action 时可能因为重试、并发等原因重复调用。如果 Action 不是幂等的就会产生重复数据或重复副作用。比如创建工单这个 Action 被调了两次就产生了两张工单。我的做法是所有 Action 都要声明幂等键。比如 ModifyClause 的幂等键是合同 ID 条款 ID 变更内容哈希同样的变更请求重复到达时直接返回上次的结果不重复执行。7.4 坑四没有为 Agent 的幻觉设计兜底Agent 会犯错这是事实。它会调用错误的 Action会误解 Object 的关系会给出不合理的判断。如果系统没有兜底机制一次错误可能导致严重后果。兜底机制包括Action 的前置条件校验不满足就拒绝执行、关键操作的二次确认高风险 Action 需要人工或另一个 Agent 确认、结果的可逆性设计能回滚的操作优先。我在项目里强制要求任何修改核心数据的 Action都必须有对应的回滚 Action。8. 关于这套架构未来走向的个人判断做了几个项目之后我越来越觉得 AI Native 和 Ontology 的结合不是可选项而是必然项。原因很简单AI 的能力越强对语义底座的要求越高。模型再聪明如果它面对的数据是一盘散沙它也做不出靠谱的判断。反过来一个清晰的 Ontology 能让中等能力的模型发挥出超预期的效果。我观察到的一个趋势是越来越多的团队开始把 Ontology 当作AI 的基础设施来建设而不是某个项目的附属品。这个转变很重要因为基础设施需要长期投入、需要标准、需要治理而项目附属品往往是临时凑合的。另一个趋势是 Agent 之间的协作协议正在标准化。早期每个团队自己定义 Agent 怎么通信现在开始出现一些通用的模式比如基于能力描述的 Agent 发现、基于任务契约的协作。这些模式成熟后跨团队的 Agent 协作会变得像今天的微服务调用一样普遍。如果你现在正在做 AI 相关的架构设计我的建议是别急着堆模型先把业务的 Object 和 Link 理清楚。这一步做扎实了后面无论换什么模型、加什么 Agent系统都能稳。这一步偷懒了后面每加一个功能都是在还债。最后分享一个我自己的小习惯每次设计一个新的 Agent我都会先问自己这个 Agent 需要理解哪些 Object需要沿哪些 Link 推理需要调用哪些 Action。如果这三个问题答不上来说明我对业务的理解还不够这时候写 prompt 就是瞎写。先把这三个问题答清楚Agent 的设计自然就出来了。
1. 从一次架构评审的翻车现场说起去年年底我参加了一个内部架构评审团队花了三个月搭了一套智能工单系统底层是微服务加规则引擎上层套了个大模型做意图识别。演示当天一切正常直到有人问了一句如果客户上周改过合同条款这周又提了个新需求系统怎么判断该走哪条流程现场沉默了整整十秒。规则引擎里没有这条路径大模型也不知道合同改过——因为合同数据躺在另一个系统的数据库里两边从来没对齐过。这不是个例。我后来陆续接触了七八个号称AI 原生的项目发现一个共性大部分团队把 AI 当成一个外挂的接口而不是系统的组织原则。他们做的事情是传统架构 LLM 调用而不是真正的 AI Native。这两者的差距不是加个模型就能补上的它涉及到对象怎么建模、状态怎么流转、Agent 怎么协作这一整套底层范式。这篇内容我想把这件事讲透。核心围绕两个东西AI Native 方案和类 Ontology 对象建模。前者是一种架构取向后者是一种建模方法。它们之间的关系不是替代而是互补——但很多人把它们搞混了结果做出来的系统既不像传统架构那样可控也不像 AI 原生那样灵活。如果你正在做 AI Agent、企业级智能应用、或者任何需要让系统自己理解业务的项目这篇应该能帮你少走几个月的弯路。2. 传统对象建模在智能场景下到底卡在哪2.1 关系型建模的隐含假设世界是静态的传统系统架构的根基是关系型建模。一张订单表、一张用户表、一张合同表用外键连起来查询的时候 JOIN 一下。这套东西统治了企业软件三十年它的隐含假设是实体是稳定的关系是预先定义好的状态变化是离散的事件。这个假设在传统业务里没问题。订单就是订单用户就是用户字段定好了就不太会变。但一旦引入 AI情况就变了。AI 要处理的是意图上下文语义相似度这类模糊的东西它们没法用外键表达。你没法在数据库里建一个字段叫客户这句话的真实意图因为意图是动态推断出来的不是存储的。我见过最典型的翻车是团队为了支持 AI 查询在订单表旁边加了一堆扩展字段什么intent_hint、context_json、ai_score。半年后这张表有四十多个字段一半没人知道是干嘛的。这就是用关系型思维硬扛 AI 需求的后果。2.2 规则引擎的困境分支爆炸第二个卡点是规则引擎。传统做法是把业务逻辑写成 if-else 或者决策树AI 来了之后团队想的是让模型输出一个分类然后走对应的规则分支。听起来合理实际做起来分支会爆炸。举个例子一个报销审批系统原本规则是金额小于 5000 直属领导批大于 5000 部门总监批。加了 AI 之后你想让它理解这笔报销是否合理于是规则变成金额小于 5000 且 AI 判定合理走 A金额小于 5000 但 AI 判定可疑走 B金额大于 5000 且 AI 判定合理走 C……每加一个 AI 维度分支数翻倍。三个维度就是八条路径五个维度就是三十二条。维护成本指数级上升。这里的关键问题是规则引擎假设条件是可枚举的而 AI 的输出是连续的、概率性的。用离散的框架去接连续的输出必然产生裂缝。2.3 数据孤岛让 AI 变成瞎子第三个卡点最隐蔽也最致命。传统架构里数据按系统划分CRM 管客户ERP 管订单OA 管流程。每个系统有自己的数据库、自己的模型、自己的语义。AI 要做跨系统的推理时它面对的是几套互不兼容的方言。回到开头那个工单系统的例子。合同系统里合同变更是一个事件记录工单系统里需求是一个工单类型两个系统对变更这个词的理解完全不同。AI 拿到的是一堆碎片它没法知道上周改的合同条款和这周提的需求之间有关系因为关系从来没有被显式建模过。这就是为什么很多 AI 项目在 Demo 阶段惊艳一上生产就拉胯。Demo 用的是干净的单源数据生产面对的是割裂的多源数据。3. 类 Ontology 对象建模把关系变成一等公民3.1 Ontology 的核心思想不是分类是关系网络很多人第一次听到 Ontology本体这个词会以为它是更复杂的分类体系。这是个误解。Ontology 的核心不是把东西分门别类而是把实体之间的关系显式建模出来让关系成为可以被推理的一等公民。用生活化的类比传统数据库像一本电话簿你按名字查号码查完就完了。Ontology 像一张社交网络图你不仅知道谁是谁还知道谁认识谁、谁和谁有业务往来、谁最近和谁发生过冲突。当你要判断这个客户该不该给折扣时电话簿只能告诉你他的等级社交网络图能告诉你他和哪些高价值客户有关联、他最近有没有投诉记录、他的合同还有多久到期。Palantir 的 Foundry Ontology 是这套思路最成熟的工业实现。它的做法是把企业里所有的实体客户、订单、设备、事件、文档都抽象成 Object把实体之间的关联抽象成 Link把实体的属性变化抽象成 Action。这三样东西构成了一个可推理、可追溯、可演化的语义网络。3.2 Object、Link、Action 三件套怎么落地具体到实操层面类 Ontology 建模通常包含三个层次Object对象不是数据库表而是业务概念的语义封装。一个客户Object 不只是 id name phone它包含了这个客户的所有相关属性、关联的其他对象、以及可以对这个对象执行的操作。关键是Object 的定义是面向业务语义的不是面向存储的。Link关联显式定义对象之间的关系。比如客户-签订-合同合同-包含-条款条款-触发-工单。这些关系不是查询时临时 JOIN 出来的而是建模时就声明好的。好处是 AI 在做推理时可以沿着 Link 遍历而不是盲目地扫描全表。Action动作定义可以对对象执行的操作以及操作的前置条件和后置效果。比如修改合同条款这个 Action前置条件是合同处于生效状态后置效果是生成一条变更记录并触发关联工单的重新评估。Action 把业务规则从散落的 if-else 里抽出来变成可组合、可追溯的单元。维度传统关系型建模类 Ontology 建模核心单元表、行、列Object、Link、Action关系处理外键 JOIN显式 Link可遍历语义表达字段名 注释对象类型 属性语义变更追踪审计日志Action 链天然可追溯AI 友好度低需大量适配高语义直接可用3.3 为什么这套东西天然适合 AI类 Ontology 建模之所以和 AI 天然契合是因为大模型的推理方式和图遍历的方式高度相似。LLM 处理问题时本质上是在语义空间里找关联、做推断。如果底层数据本身就是一张语义图LLM 的推理路径就能直接映射到图的遍历路径上中间不需要反复做数据翻译。我实测过一个对比同样一个判断客户是否有流失风险的任务用传统宽表喂给 LLM需要先把二十几个字段拼成一段自然语言描述模型经常抓错重点用 Ontology 图喂给 LLM直接把客户节点和它关联的最近事件、投诉记录、合同状态作为上下文传进去模型的判断准确率明显更高而且能给出推理链路——因为该客户近 30 天有 2 次投诉且合同即将到期所以风险高。这个推理链路是可以被验证的不是黑盒。4. AI Native 架构不是加个模型是换套组织原则4.1 AI Native 和AI 赋能的本质区别市面上大量项目自称 AI Native实际上做的是AI 赋能——在原有架构上加一个 AI 模块。这两者的区别用一句话概括AI 赋能是把 AI 当工具AI Native 是把 AI 当组织原则。AI 赋能的典型形态是传统后端 一个/ai/chat接口。用户提问后端调模型模型返回结果后端再处理。AI 是一个被调用的服务系统的骨架没变。AI Native 的形态是Agent 是系统的基本执行单元模型是 Agent 的大脑工具和数据是 Agent 的手脚Agent 之间的协作构成了系统的业务流程。这里没有主流程调用 AI的说法因为流程本身就是 Agent 协作涌现出来的。这个区别听起来抽象落到代码上很具体。AI 赋能的项目里你会看到大量的if (needAI) { callModel() }AI Native 的项目里你会看到 Agent 注册表、工具描述、任务分解器、结果聚合器——整个系统的拓扑结构是围绕 Agent 组织的。4.2 Agent 作为一等公民的架构含义把 Agent 当一等公民意味着几件事第一Agent 有明确的能力边界。每个 Agent 声明自己能做什么、需要什么输入、产出什么输出。这跟微服务的接口定义类似但更强调能力而非接口——因为 Agent 的能力是语义级的不是 API 级的。第二Agent 之间通过语义协作不是通过硬编码调用。传统微服务里A 调 B 是写死的。AI Native 里A 需要完成一个任务它会根据任务描述去寻找能帮忙的 Agent可能是 B也可能是 C取决于当前上下文。这需要一套 Agent 发现和协商机制。第三Agent 的状态是显式的。传统服务是无状态的状态存在数据库里。Agent 需要维护自己的上下文、记忆、当前任务栈。这些状态怎么存、怎么恢复、怎么在 Agent 之间传递是 AI Native 架构必须解决的问题。4.3 分布式 Agent 协作的真实难点我在实际项目里踩过的最大的坑是 Agent 之间的责任边界模糊。举个例子一个订单处理流程拆成了意图识别 Agent库存检查 Agent价格计算 Agent审批 Agent。看起来清晰实际跑起来经常出现意图识别 Agent 觉得这是修改订单库存 Agent 觉得这是新订单两边对同一个请求的理解不一致导致库存被重复扣减。根因是Agent 之间共享的语义没有统一。每个 Agent 用自己的 prompt 理解世界但 prompt 之间没有对齐。解决办法是引入一个共享的 Ontology 层——所有 Agent 都基于同一套 Object 定义和 Link 关系来理解业务这样即使各自的推理路径不同对这是什么对象它和什么有关联的认知是一致的。这就是为什么我说 AI Native 和类 Ontology 建模是互补的AI Native 提供了执行框架Ontology 提供了语义底座。没有 Ontology 的 AI Native 是一盘散沙没有 AI Native 的 Ontology 是一张死图。5. 两套范式在同一个业务场景下的正面对比5.1 场景设定一个跨系统的合同变更处理为了把差异讲清楚我设计一个具体场景某企业有一个合同管理系统和一个工单系统。客户提出合同变更请求系统需要判断这个变更是否影响正在执行的工单如果影响要重新评估工单的优先级和资源分配。这个场景涉及三个核心实体合同、条款、工单。涉及两个关键关系合同包含条款、条款影响工单。涉及一个动作变更合同条款。5.2 传统方案的做法与瓶颈传统方案的做法通常是合同系统收到变更请求更新合同表。触发一个消息通知工单系统。工单系统收到消息根据合同 ID 查询关联工单。对每个工单跑一遍规则引擎判断是否需要调整。瓶颈在哪第一合同和工单的关联关系是查询时推断的不是建模时声明的。如果关联逻辑复杂比如一个条款可能影响多个工单且影响方式不同查询逻辑会变得极其臃肿。第二规则引擎判断是否影响时只能基于结构化字段没法理解条款的自然语言内容。第三整个链路是单向的工单系统的反馈没法回流到合同系统导致合同系统不知道自己的变更造成了什么后果。5.3 AI Native Ontology 方案的做法同样的场景用 AI Native Ontology 的做法建模阶段定义 Contract、Clause、Ticket 三个 Object定义 Contract-contains-Clause、Clause-affects-Ticket 两个 Link定义 ModifyClause 这个 Action声明它的后置效果是触发所有关联 Ticket 的重新评估。执行阶段一个合同变更 Agent接收请求它调用 ModifyClause ActionAction 自动沿着 Link 找到所有受影响的 Ticket把它们的上下文当前状态、资源占用、优先级打包交给工单评估 Agent。工单评估 Agent 结合条款的自然语言内容和工单的当前状态判断影响程度输出调整建议。建议回流到合同系统形成闭环。关键差异关联关系是显式的不需要查询时推断条款内容被 Agent 理解不是被规则匹配反馈是双向的合同系统能看到变更的后果。对比维度传统方案AI Native Ontology关联关系查询时推断逻辑臃肿建模时声明直接遍历内容理解规则匹配无法处理自然语言Agent 理解支持语义判断反馈闭环单向通知无回流双向协作可追溯扩展成本加一个实体要改多处加一个 Object 即可可解释性规则日志碎片化Action 链完整可追溯5.4 成本与收益的冷静评估必须说清楚AI Native Ontology 不是银弹它的前期成本明显更高。建模阶段需要业务专家和技术专家一起梳理实体和关系这个工作量在传统方案里是不需要的。而且 Ontology 的维护需要持续投入业务变了模型要跟着变。收益体现在哪里在需求变化的响应速度上。传统方案里加一个新实体或新关系往往要改数据库、改接口、改规则、改前端牵一发动全身。Ontology 方案里加一个 Object 或 Link其他部分基本不用动因为系统是围绕语义组织的不是围绕流程硬编码的。我的经验是如果业务相对稳定、变化少传统方案更划算如果业务频繁变化、需要跨系统推理、需要 AI 深度参与Ontology 方案的长期收益会覆盖前期成本。别为了追概念硬上先评估自己的业务变化频率。6. 落地路径从现有系统迁移到 AI Native 的实操步骤6.1 第一步识别核心 Object别贪多迁移最容易犯的错是想一次建完整个企业的 Ontology。这是不可能完成的任务。正确做法是从最痛的那个业务场景切入只建这个场景需要的 Object。具体怎么选找那些跨系统查询频繁规则经常改AI 判断准确率上不去的场景。比如客户流失预警、供应链异常处理、合规审查。这些场景的共同点是需要跨多个数据源、需要语义理解、需要动态推理。选好场景后列出这个场景涉及的所有实体。注意是业务实体不是数据库表。一个客户可能对应三张表但在 Ontology 里就是一个 Object。这个抽象过程需要业务人员参与技术人员单独做容易做偏。6.2 第二步用 Link 把孤岛连起来Object 建好后关键是定义 Link。这一步的价值最高也最容易被跳过。很多团队建了一堆 Object但 Link 定义得很随意结果 AI 推理时还是找不到路径。定义 Link 的原则是只定义业务上有意义的关系不定义技术上能连的关系。客户和订单有关系是业务关系客户表和订单表有相同字段是技术关系后者不该进 Ontology。实操建议拿一张白纸把核心 Object 画成圈然后问业务人员这两个东西之间有什么关系。他们说的每一句话都可能是一条 Link。比如客户投诉会影响他的信用评级这就是一条 Complaint-affects-CreditRating 的 Link。6.3 第三步把规则改写成 Action传统系统里的业务规则散落在代码、配置、存储过程里。迁移到 AI Native 时需要把它们抽出来改写成 Action。改写的方法对每条规则问三个问题——它作用于哪个 Object它的前置条件是什么它执行后改变了什么把答案填进 Action 的定义里。举个例子规则金额大于 10000 的报销需要总监审批改写成 Action 就是作用于 Expense Object前置条件是 amount 10000后置效果是创建一个 ApprovalTask 并指派给 Director 角色。这样规则就从代码里的 if变成了可被 Agent 调用的动作。6.4 第四步让 Agent 接管但保留人工兜底Agent 接管不是一蹴而就的。我的建议是分三阶段第一阶段Agent 只做建议不做决策。它输出判断和理由人工确认后执行。这个阶段用来积累信任和收集反馈。第二阶段Agent 做低风险决策高风险决策仍走人工。比如金额小于 1000 的自动处理大于的转人工。第三阶段Agent 做大部分决策人工只处理异常。这时候需要建立完善的监控和回滚机制确保 Agent 出错时能快速止损。关键提醒无论哪个阶段都要保留完整的 Action 日志。Agent 的每一步推理、每一次 Action 调用都要可追溯。这不仅是合规要求也是排查问题的唯一依据。6.5 第五步建立 Ontology 的演化机制Ontology 不是建完就完了。业务在变模型必须跟着变。但变化不能随意否则会破坏已有 Agent 的推理逻辑。我的做法是建立一套版本化的 Ontology 管理机制每次修改 Object 或 Link都要记录版本、影响范围、迁移方案。新增字段是安全的删除字段要评估影响修改 Link 语义要格外谨慎因为它可能改变多个 Agent 的推理路径。这套机制听起来重但比改完发现线上 Agent 全乱套要轻得多。我见过一个团队因为改了一个 Link 的方向导致三个 Agent 的判断逻辑全部反转排查了两天才找到原因。7. 几个容易踩的坑和我的应对经验7.1 坑一把 Ontology 做成超级数据库最常见的误解是把 Ontology 当成一个集中式的大数据库把所有数据都往里塞。结果建出来的东西又大又慢Agent 查一次要等好几秒。正确的做法是Ontology 存的是语义和关系不是原始数据。原始数据还在各自的系统里Ontology 只存 Object 的标识、关键属性、以及 Link。Agent 需要详细数据时通过 Object 的标识去源系统取。这样 Ontology 保持轻量查询快也避免了数据同步的一致性问题。7.2 坑二Agent 的 prompt 和 Ontology 脱节第二个坑是 Agent 的 prompt 里硬编码了业务概念和 Ontology 的定义不一致。比如 Ontology 里客户包含潜在客户和活跃客户两个子类型但 Agent 的 prompt 里只写了客户导致它把潜在客户也当成活跃客户处理。解决办法是Agent 的 prompt 应该从 Ontology 动态生成而不是手写。至少Object 和 Link 的定义要作为 prompt 的一部分注入。这样 Ontology 变了Agent 的理解自动跟着变。7.3 坑三忽视 Action 的幂等性Agent 调用 Action 时可能因为重试、并发等原因重复调用。如果 Action 不是幂等的就会产生重复数据或重复副作用。比如创建工单这个 Action 被调了两次就产生了两张工单。我的做法是所有 Action 都要声明幂等键。比如 ModifyClause 的幂等键是合同 ID 条款 ID 变更内容哈希同样的变更请求重复到达时直接返回上次的结果不重复执行。7.4 坑四没有为 Agent 的幻觉设计兜底Agent 会犯错这是事实。它会调用错误的 Action会误解 Object 的关系会给出不合理的判断。如果系统没有兜底机制一次错误可能导致严重后果。兜底机制包括Action 的前置条件校验不满足就拒绝执行、关键操作的二次确认高风险 Action 需要人工或另一个 Agent 确认、结果的可逆性设计能回滚的操作优先。我在项目里强制要求任何修改核心数据的 Action都必须有对应的回滚 Action。8. 关于这套架构未来走向的个人判断做了几个项目之后我越来越觉得 AI Native 和 Ontology 的结合不是可选项而是必然项。原因很简单AI 的能力越强对语义底座的要求越高。模型再聪明如果它面对的数据是一盘散沙它也做不出靠谱的判断。反过来一个清晰的 Ontology 能让中等能力的模型发挥出超预期的效果。我观察到的一个趋势是越来越多的团队开始把 Ontology 当作AI 的基础设施来建设而不是某个项目的附属品。这个转变很重要因为基础设施需要长期投入、需要标准、需要治理而项目附属品往往是临时凑合的。另一个趋势是 Agent 之间的协作协议正在标准化。早期每个团队自己定义 Agent 怎么通信现在开始出现一些通用的模式比如基于能力描述的 Agent 发现、基于任务契约的协作。这些模式成熟后跨团队的 Agent 协作会变得像今天的微服务调用一样普遍。如果你现在正在做 AI 相关的架构设计我的建议是别急着堆模型先把业务的 Object 和 Link 理清楚。这一步做扎实了后面无论换什么模型、加什么 Agent系统都能稳。这一步偷懒了后面每加一个功能都是在还债。最后分享一个我自己的小习惯每次设计一个新的 Agent我都会先问自己这个 Agent 需要理解哪些 Object需要沿哪些 Link 推理需要调用哪些 Action。如果这三个问题答不上来说明我对业务的理解还不够这时候写 prompt 就是瞎写。先把这三个问题答清楚Agent 的设计自然就出来了。
