当 Agent 开始参与企业经营决策，它面对的就不只是"数据在哪张表"，还要弄清楚：这个客户是谁？当前状况如何？何时需要干预？可以采取哪些动作？判断依据又是什么？

数据资产擅长记录"发生了什么"，但仅凭数据，Agent 还无法可靠地理解业务、作出判断并执行操作。企业还需要一层 语义资产 ：让人和 Agent 使用同一套业务概念、判断规则和行动边界。 Ontology 的作用，正是把分散在各系统中的数据、规则与能力，组织成一套可理解、可计算、可执行的业务语义。

上一篇建立了 AI Native 架构的基本分层：记录系统负责交易事实，Ontology 负责统一业务语义，Agent 负责理解目标和执行任务。本文回答接下来的关键问题：

Ontology 究竟要沉淀什么，如何建设，又该怎样供 Agent 使用？

全文沿着一条主线展开：

业务场景 + 已有资产（DDD / 数仓 / 微服务）
        │
        ▼
分步构建（六步）
        │
        ▼
语义资产与 Semantic Service
（Fact · Logic · Action）
        │
        ▼
    Agent 消费

为了让讨论落到实处，本文用 客户健康度 作为贯穿案例。一家 toB 公司的客户信息散落在 CRM 、工单系统和财务系统，健康度由运营人员手工计算，流失预警主要依赖个人经验。公司希望让 Agent 识别高风险客户，并在满足条件时触发跟进。

 从 DDD 到 Ontology，缺的是什么 

DDD 领域模型服务于限界上下文内部的业务实现，已经很好地解决了业务实现问题，但它天然面向的是"软件开发"——消费方是程序员，产物是可运行的代码模块 。

但 Agent 的需求跨出了单个限界上下文。以客户健康度为例，它不仅要认识 Customer，还必须知道：

• 跨系统身份 ：CRM、客服和财务系统中的三个 ID，是否指向同一家公司；
• 指标口径 ：Health Score 包含哪些维度，权重和时间窗口如何定义；
• 规则版本 ：什么条件会触发预警，规则由谁维护，当前生效的是哪个版本；
• 判断依据 ：结论引用了哪些数据和规则，可信程度如何；
• 行动边界 ：当前允许执行什么，谁有权限，是否需要审批。

DDD 并不排斥这些内容，问题在于在实际实现中往往把它们分散在不同位置：指标在数仓或文档中，权限在网关，血缘在数据平台，大部分规则在代码或运营文档中。开发者尚可通过系统知识把这些信息拼起来，但Agent 需要一份明确、稳定且可查询的上下文。

可以把 DDD 理解为各部门的内部词典：CRM、财务、客服都能清楚定义自己的"客户"。Ontology 要做的是建立企业级词典，保留各上下文的差异，同时说明概念之间如何对应、各自适用于什么范围，以及发生冲突时以谁为准。

因此，从 DDD 走向 Ontology，并不仅是重建领域模型，而是完成三项扩展：

1. 复用已有领域资产 ：提取实体、值对象、领域规则和应用服务；
2. 桥接不同上下文 ：补充身份映射、属性来源和状态语义的对应关系；
3. 补齐运行时语义 ：统一指标口径、规则版本、动作权限与证据链。

经过这三步，原本局部、隐含的领域知识，才能成为跨系统共享并由 Agent 直接消费的 语义资产 。

Ontology 的核心模型：Fact · Logic · Action

这里把企业语义划分为三类可运行资产：Fact、Logic 和 Action。这一划分参考了"事实—事理—行动"模型与 Palantir Foundry 的 Semantic、Dynamic、Kinetic 要素，并针对 Agent 的运行时需求作了调整。

在客户健康度场景中，三层各有明确分工。

Fact 层 先解决"客户是谁"。CRM 中的"星辰科技"、工单系统中的"星辰科技有限公司"和财务平台里的企业编号，需要映射为同一个 Customer。商机阶段、合同到期日、近 30 天工单量和最近登录时间仍由各自的权威系统提供，但通过统一对象对外呈现。

Logic 层 负责计算和判断。例如，Health Score 由活跃度、续费意向和工单满意度加权得出；当分数低于 60，且合同将在 90 天内到期时，触发流失预警。指标定义、阈值和适用条件都要结构化并纳入版本管理。Policy 则描述可复用的约束，例如哪些角色可查看敏感属性、哪类动作必须经过审批。

Action 层 把底层 API 包装成受约束的业务动作。"创建 CSM 跟进任务"可以由 Agent 自动执行；"升级服务等级"需要主管批准并附合同依据；"发放续费优惠券"还要通过预算校验。动作契约引用 Logic 层的 Policy，并记录调用身份、校验结果和执行证据。这样既避免了权限定义在两层重复维护，也保留了动作执行时的完整上下文。

三层对应三类常见缺口：客户 ID 无法跨系统对齐，是 Fact 问题；公式和规则藏在脚本或文档中，是 Logic 问题；API 缺少统一的前置条件、授权和证据要求，是 Action 问题。Ontology 的建设目标可以概括为： 统一事实，显式表达规则，把能力封装为受约束的动作 。

这项工作同时需要领域建模和数据治理。前者定义客户、合同、工单等对象及其关系，后者保证定义长期可信，例如明确健康度公式的维护者和变更审批流程。只有建模，口径会逐渐分裂；只有治理，又缺少承载规则的统一业务结构。

三层模型说明了要沉淀什么，下面进入具体的建设路径。

下图是从业务场景到语义服务落地的完整架构视图：

如下图，六个步骤从业务场景出发，逐步沉淀 Fact、Logic 和 Action，最后封装为可运行的 Ontology Service。每一步都要同步落实 Owner、Version、Lifecycle、Permission、Audit 和 Metric；治理不是上线后打补丁，而是建设过程的一部分。

Step 1：识别场景

先选一个价值明确、使用频繁且效果可验证的场景，不必一开始就建立覆盖全公司的模型。范围过大不仅拉长交付周期，也很难检验语义资产是否真正有用。

案例 ：假设这家公司年流失率约 15%，每流失一个中型客户就会损失数十万元 ARR。客户成功团队只有 8 个人，却要管理 4000 多个活跃客户。依靠人工排查，团队往往要等到客户明确表示不续费时才发现风险，留给挽留的时间已经不多。

公司把第一个场景定为： Agent 自动识别高流失风险客户并触发跟进 。随后梳理这个场景涉及的对象、指标、规则和动作：

产出： 本体缺口清单 ，用于界定建设范围和信息来源。

Step 2：盘点资产

建设前先盘点现有资产，再决定从哪里切入：

• 已有 DDD 领域模型：从领域实体和规则演进，复用现有定义；
• 已有数仓和指标平台：从 Metrics Layer 切入，先统一指标口径；
• 两者都不完整：从业务文档和访谈记录中提取候选定义，必要时用 AI 辅助整理，再交由领域专家确认。

案例 ：这家公司的 CRM 有完整的领域模型（Customer、Contract、Opportunity），数仓中有基础的客户行为数据（登录日志、功能使用量），但客服系统的数据从未被整合过，健康度计算完全在运营团队的 Excel 中完成。盘点后确定策略：以 CRM 领域模型为起点，补接客服和产品行为数据，将 Excel 中的计算逻辑结构化。

产出： 资产盘点表 。

Step 3：沉淀 Fact

这一步从各系统的局部模型中提取核心业务对象，建立身份映射和关系定义。目标是让 Agent 在提到"星辰科技"时，能够定位它在各系统中的记录，并知道匹配结果是否可靠。

案例 ：

CRM 客户 ─┐
运营主体 ──┼── Customer Object（统一客户身份）
客服账号 ──┘
  ├── 身份规则：统一社会信用代码 > 企业名称+地址 > 人工确认
  ├── 属性来源：
  │     商机阶段 ← CRM（权威源）
  │     信用额度 ← 财务系统（权威源）
  │     服务等级 ← 客服系统（权威源）
  │     最近登录 ← 产品日志（T+1 更新）
  │     工单满意度 ← 客服系统（实时）
  ├── 关系图：Customer → Contract（1:N）→ Subscription（1:N）
  │           Customer → Case（1:N）
  │           Customer → CSM（N:1，指定客户成功经理）
  └── 置信度：高/中/低 → 低置信度进入待确认队列

身份映射并非简单的主键关联。同一家公司可能被不同销售重复录入，改名后可能留下新旧两条记录，母子公司之间则应建立关系而不是直接合并。因此，匹配规则需要分级：优先使用统一社会信用代码，再尝试企业名称与地址的组合；仍不能确认时，进入人工审核队列。

同步治理 ：每个 Object 必须指定 Owner（如 Customer 由客户成功团队负责），身份映射规则有版本号，冲突率纳入日常监控指标。

产出： Fact Asset 统一对象模型（Object + Link + ID 映射） 。

Step 4：沉淀 Logic

将散落在数仓脚本、代码分支、运营文档和个人经验中的业务逻辑，转成结构化、可测试、可版本管理的语义资产。

案例 ：

健康度评分的公式经过客户成功团队和数据团队共同校准，确定为三个维度：

Metric: customer_health_score
├── 公式：100 × (login_recency × 0.3 + renewal_intent × 0.4 + ticket_satisfaction × 0.3)
├── 取值：0–100 分；三个分量先归一化到 0–1
├── 分量：
│   ├── login_recency：最近 30 天登录天数 / 30
│   ├── renewal_intent：
│   │     续费沟通评分 × 0.5 + 功能使用趋势 × 0.3 + 商务响应评分 × 0.2
│   └── ticket_satisfaction：近 90 天工单 CSAT 平均分 / 5
├── 维度：按客户、按时间（滚动计算，每日更新）
├── 数据源：Login Service + CRM + Ticket System
├── Owner：客户成功团队
├── 审核人：数据团队（负责口径一致性）
└── 版本：v1.2（2026-06-15 生效）


Rule: churn_risk_alert
├── 条件：health_score < 60 且 0 ≤ 合同剩余天数 ≤ 90
├── 排除条件：已有进行中的跟进任务 或 客户已确认续费
├── 输出：高风险标记 + create_followup_task 候选动作
├── 测试集：12 条边界用例（包括刚好 60 分、刚好 90 天等边界场景）
└── 版本：v2.0（相较 v1.0，增加合同到期条件以减少误报）

Logic 层主要包含三类内容：

• Metric ：完整描述公式、维度、数据源和更新频率，供 Agent 与 BI 共同引用；
• Rule ：按照"定义—测试—发布—监控—退役"管理生命周期，保留测试用例和版本记录；
• Policy ：描述角色、数据范围、风险等级和审批要求，供对象查询和动作执行共同引用。

同步治理 ：指标 Owner 负责口径确认和维护，规则变更必须经过审批并保留历史版本，关键指标定期与业务团队对账。

产出： Logic Asset 指标定义库 + 规则库 + Policy 库 。

Step 5：沉淀 Action

将现有 API 和应用服务封装为带约束的动作契约。契约需要说明：动作何时可用、由谁执行、会产生什么副作用，以及执行后如何追溯。

案例 ：

Action: create_followup_task
├── 前置条件：churn_risk_alert 规则命中
├── 授权策略：客户成功经理或受托 Agent；中风险，无需逐次审批
├── 副作用：在 CRM 创建 Task，发送通知给指定 CSM
├── 幂等性：同一客户 7 天内不重复创建
└── 证据要求：绑定 health_score 快照 + 规则版本 + 触发时间
Action: upgrade_service_level
├── 前置条件：客户 ARR > 50 万 且 合同剩余 > 180 天
├── 授权策略：高风险，需要主管审批
├── 审批超时：48 小时未审批自动提醒，7 天未审批自动关闭
└── 证据要求：绑定审批记录 + 合同快照 + health_score 历史趋势
Action: issue_renewal_coupon
├── 前置条件：churn_risk_alert 命中 且 客户无历史欠款
├── 授权策略：额度不超过合同金额 5% 且预算充足时，Agent 可执行
├── 预算校验：调用财务系统确认当月优惠预算余额
└── 证据要求：绑定预算校验结果 + 规则版本

每次判断和执行都要保留三类证据：

• 数据证据 记录数据源与快照时间，
  
• 规则证据 记录规则版本和命中条件，
  
• 执行证据 记录触发者、策略校验结果与审批过程。发生异常时，团队才能判断问题来自数据、规则还是授权配置。

同步治理 ：动作契约变更走发布流程，证据链路完整性定期抽检。

产出： Action Asset 动作契约库 + 证据链路规范 。

Step 6：封装为 Semantic Service

最后，把前五步形成的资产装入运行时，而不是停留在文档或 ER 图中。这个运行时对 Agent、Workflow、业务应用和 BI 提供统一接口。

工程形态不必一步到位。初期可以采用模块化单体验证价值，边界稳定后再按负载和团队职责拆分；如果早期场景只有分析需求，Metrics Layer 可能已经足够。

语义服务也不只是另一层 CRUD API。当 Agent 查询"星辰科技的状况"时，响应除了对象数据，还应包含计算结果、规则命中、当前可用动作及证据引用：

{
  "customer_id": "C-10042",
  "snapshot_time": "2026-07-03T10:00:00+08:00",
  "fact": {
    "name": "星辰科技有限公司",
    "contract_remaining_days": 75,
    "last_login": "2026-06-20",
    "open_cases": 3,
    "csm": "小明（客户成功经理）"
  },
  "logic": {
    "health_score": 48,
    "score_breakdown": {
      "login_recency": 0.23,
      "renewal_intent": 0.50,
      "ticket_satisfaction": 0.70
    },
    "metric_version": "health-score-v1.2",
    "rule_hit": "churn_risk_alert-v2.0",
    "risk_factors": ["30天仅登录7天", "合同75天后到期", "近60天无续费沟通记录"]
  },
  "permitted_actions": ["create_followup_task", "issue_renewal_coupon"],
  "restricted_actions": [
    {
      "action": "upgrade_service_level",
      "reason": "合同剩余不足 180 天，且该动作需要主管审批"
    }
  ],
  "evidence_ref": "evidence-C10042-20260703"
}

这份响应把 Agent 决策所需的上下文放在一起：Fact 说明客户是谁，Logic 解释风险如何得出，Action 列出当前可执行与受限的动作，Evidence 提供追溯入口。底层数据仍由各业务系统负责，语义服务只统一其业务含义和调用契约。

产出： 可运行的 Semantic Service + Adapter 适配层 + 接口契约 。

Agent 如何消费 S emantic Service

语义服务上线后，一次典型调用如下：

用户："帮我看看星辰科技为什么风险高"
        │
        ▼
      Agent
        │
        ▼
  Query Semantic Service
        │
        ▼
  ┌─────────────────────────┐
  │ Fact:   Customer Object │
  │ Logic:  Health Score=48 │
  │         Rule: <60 触发   │
  │ Action: 创建跟进任务     │
  │ Evidence: 数据+规则快照  │
  └─────────────────────────┘
        │
        ▼
  Agent 生成结论：
  "星辰科技 Health Score 48（满分 100），低于预警阈值 60。
   主要风险因子：
   · 产品活跃度低——近 30 天仅登录 7 天
   · 续费信号弱——近 60 天无续费相关沟通记录
   · 合同即将到期——剩余 75 天
   建议：立即创建跟进任务，指派 CSM 张明跟进。"
        │
        ▼
  Agent 执行 Action（权限校验通过）
        │
        ▼
  CRM 中自动创建 Follow-up Task → 通知 CSM 小明

这次调用可以拆成四个环节：

1. 理解对象 ——通过 Fact 知道"星辰科技"是谁、关联了哪些合同和工单、谁是它的客户成功经理；
2. 理解逻辑 ——通过 Logic 知道 Health Score 怎么算的、各维度得分如何、为什么命中了流失预警规则；
3. 决定行动 ——通过 Action 知道当前能做什么（创建跟进任务）、哪些动作前置条件不满足或仍需审批，以及边界在哪里；
4. 留下证据 ——每一步都绑定了数据快照和规则版本，人类可以审计 Agent 做出的每个决定。

业务逻辑不再散落在 Agent 的提示词或工具代码中，底层系统的差异也由 Adapter 层处理。Agent 面向 Semantic Service 编排任务，调用时获得所需的事实、判断、动作与证据。

建设路径：组合而非二选一

（● 较好覆盖　◐ 部分覆盖　○ 通常不是重点；这里比较的是常见工程实践，而非理论能力上限）

不同路径之间并不互斥，组合使用才能完整覆盖 Fact、Logic 和 Action，比如用领域模型和知识图谱组织对象，用数据平台统一指标，用规则引擎承载判断，再从现有 API 和应用服务中提炼动作。LLM 适合辅助抽取候选定义，但不能代替领域专家确认。

能力边界：Ontology 与数据中台

在实践过程中也有同学会很有疑惑，这与数据中台有啥区别？实际Ontology 与数据中台确有重叠，但关注点不同。

数据中台可以提供可靠的数据和指标，是建设 Ontology 的重要基础。Ontology 在此之上继续回答三个问题：这些数据在业务上表示什么，当前应如何判断，以及在给定权限下可以采取什么动作。两者不是替代关系。

交付清单

这些定义当然需要文档，但不能只存在于文档中。生产环境还要以结构化形式存储，使其能够被版本管理、契约测试和 CI 校验，并由 Agent 在运行时读取。

 结语 

微服务把系统拆成可独立部署的能力单元，DDD 用限界上下文管理复杂业务。它们为应用开发奠定了良好基础，但当消费方增加了 Agent，还需要处理跨上下文的身份、口径、授权和证据问题。

从 DDD 到 Ontology，不是换一套名词，更不是推倒重来。DDD 中的实体和规则、数仓中的指标口径、微服务暴露的能力接口，都是可复用的原材料。新的工作，是把这些局部或隐含的资产连接起来，形成跨系统、可查询、可执行的语义契约。

整条路径可以归纳为三件事：

1. 分层沉淀 ：Fact 统一对象与关系，Logic 统一指标、规则与策略，Action 统一可执行能力和证据；
2. 场景驱动 ：从一个可验证的场景出发，完成识别、盘点、建模和服务化，再逐步扩展；
3. 服务化交付 ：把语义定义放进可查询、可执行、可审计的运行时，让 Agent、应用、工作流和 BI 共享同一套契约。

当更多 Agent 接入企业系统，稳定复用的核心不应只是数据库表和 API，还应包括它们背后的业务含义、判断规则与行动边界。 Ontology  正是这层共享能力的工程载体。