# FDE进化36记-第22记-规则、本体和业务语义层到底怎么分工？

> 退款链路一塞进 Prompt，语义、决策、流程就全糊了。

```text
[读者] 正在做客服 Agent 的 FDE 与架构师
[痛点] 本体、规则、流程和 Prompt 混成一团
[现在读] 多企业退款要审计、要高金额审批
[读完] 能把退款拆成三层可验证能力
```

```text
[旧方案] Prompt 里写满退款条件与步骤
    |
    v
[新需求] 多企业差异、高金额审批、全链路审计
    |
    v
[冲突] 业务语义、决策真值和执行时序耦合
    |
    v
[后果] 误退款、难追责、改一处崩三处
```

我是老李，在做全球智能客服平台的 FDE。这个平台同时服务多企业、多项目、多语言、多渠道，后面连着 CRM、订单、支付、物流、工单和知识库。客服 Agent 不只是聊天，它要真能推进业务。

最近一个高频任务是退款。用户说“订单没收到，我要退款”，Agent 要判断订单状态、支付渠道、金额、时效、客户等级，再决定是直接退款、转人工、补资料还是拒绝。

变化来自企业 B：它要求退款条件走本企业规则，高金额必须人工审批，每次决策要留下可追溯证据。原来那套 Prompt 很快就顶不住了。问题是，本体、规则、流程到底谁管什么？退款链怎么拆，才不让 Prompt 变成业务数据库？如果拆错，后面会付出什么代价？

# 01、故事

现场是一个跨境客服项目。企业 A 的退款政策宽松，企业 B 更严；同一句“我要退款”，在英语、西语和中文里还会带出不同语境。系统当前方案叫 V1：把所有退款条件、审批阈值、执行步骤都写进系统 Prompt。任务是让 Agent 根据对话生成退款建议，并在低金额时直接调用退款 Tool。

V1 上线后，低金额简单单能跑，但一到多企业就乱。企业 B 的高金额订单被直接建议退款；客服用不同语言追问时，Agent 对“已发货未签收”的解释不一致；工单里只留下一段模型回答，审计问“为什么退”时，没人能拿出结构化证据。

更麻烦的是，运营只想改企业 B 的审批阈值，却要动整段 Prompt。改完后，企业 A 的时效规则又被影响。现场开始出现一句很典型的话：模型好像什么都懂，但没人能证明它按哪条规则做了决定。

> 语义混一处
> 决策失证据
> 流程难追责
> 改动牵全身

# 02、问题

旧方案失效，不是模型突然变笨，而是 Prompt 同时承担了三种职责：描述业务世界、做条件判断、安排执行顺序。业务影响很直接：退款建议不可审计，高金额审批可能被绕过，多企业规则无法复用。技术表现则是，规则散落在文本里，流程状态藏在对话历史里，本体关系根本没有显式建模。

可验证的完成标准必须具体：同一退款请求，能输出结构化退款建议；能指出命中了哪条企业规则；高金额必须进入人工审批节点；审批通过后才能调用退款 Tool；每一步都有状态和审计记录。

这里的关键不再是“让模型回答得更像人”，而是让系统能回答：业务世界里有什么，满足什么条件得出什么结果，什么时候由谁执行。

> 旧法非不灵
> 职责混成团
> 标准先立住
> 再谈智能化

# 03、原理

先把三句话钉死。本体回答“业务世界有什么以及如何关联”，比如客户、订单、支付、退款案件、商品、物流单之间的关系。规则回答“满足什么条件得出什么结果”，比如订单已支付、未发货、金额低于阈值，则建议自动退款。流程回答“什么时候由谁执行”，比如高金额先生成审批任务，人工通过后再调用退款 Tool。

反直觉判断：把业务拆成本体、规则和流程，不是为了让 LLM 少干活，而是为了让 LLM 的输出可以被验证。Prompt 适合理解意图、组织语言和调用受控工具，但它不是规则数据库，也不是状态机。OMG DMN 适合表达决策需求图、决策表和 FEEL 表达式；Drools 可作为规则与 DMN 执行引擎；OMG BPMN 适合表达流程、网关、事件和任务边界。具体版本与实现能力需按当前官方文档核验。

这意味着，退款链路不该问“Prompt 怎么写得更全”，而该问“这条知识属于哪一层”。一旦分层，模型输出就能变成结构化输入，交给确定性组件决策和执行。

> 本体管名词
> 规则管判断
> 流程管时序
> 模型管交互

# 04、架构

```text
[输入] 客服对话、订单事件、退款请求
    |
    v
[模块] 本体语义层 + DMN 决策 + Workflow 编排 + Tool 网关
    |
    v
[数据/状态] 客户、订单、支付、退款案件、审批任务、审计事件
    |
    v
[处理] 本体解析 -> 规则评估 -> 流程路由 -> Tool 执行
    |
    v
[输出] 退款建议、审批任务、退款结果、证据链
```

边界要清楚：本体不写 if-else，只定义概念、属性、关系和约束；DMN 不保存订单状态，只接收事实并输出决策；Workflow 不判断“是否满足退款条件”，只根据决策结果决定走自动退款、人工审批还是补资料。Prompt 负责把多语言对话归一成意图和槽位，不负责最终业务真值。

收益是可验证、可审计、可复用；代价是多了一层模型和版本治理。适用条件是业务规则频繁变化、需要审计、多企业差异明显的客服场景。若只是一次性演示，全塞 Prompt 也许更快，但它无法承担生产责任。

> 输入先归一
> 规则定真假
> 流程管人机
> 输出留证据

# 05、实战一次

环境与依赖：Python 3.11，标准库即可跑最小分层；生产可将决策表替换为 Drools/KIE 的 DMN 执行。这里未在当前环境实测，以下为预期结果。V1 目标：跑通“本体事实 -> 决策表 -> 工作流状态 -> 退款建议”。

配置用 YAML 表示本体和规则版本：

```yaml
tenant: enterprise_b
ontology_version: refund-onto-v1
rule_version: refund-dmn-v1
workflow_version: refund-flow-v1
thresholds:
  auto_refund_amount: 100
  currency: CNY
```

本体事实用 Python 字典表示：

```python
order = {
    'order_id': 'O-1001',
    'paid': True,
    'shipped': False,
    'amount': 80,
    'currency': 'CNY',
    'customer_level': 'normal',
    'payment_channel': 'card'
}
```

核心实现：决策表先判断是否满足退款条件，工作流再决定自动或人工：

```python
def decide_refund(order, thresholds):
    if not order['paid']:
        return {'decision': 'reject', 'reason': 'order_not_paid'}
    if order['shipped']:
        return {'decision': 'manual_review', 'reason': 'already_shipped'}
    if order['amount'] <= thresholds['auto_refund_amount']:
        return {'decision': 'auto_refund', 'reason': 'low_amount_paid_unshipped'}
    return {'decision': 'manual_review', 'reason': 'high_amount'}

def run_workflow(order, decision):
    state = {'order_id': order['order_id'], 'status': 'new'}
    if decision['decision'] == 'reject':
        state['status'] = 'rejected'
    elif decision['decision'] == 'auto_refund':
        state['status'] = 'refund_tool_called'
    else:
        state['status'] = 'pending_approval'
    state['evidence'] = decision
    return state

thresholds = {'auto_refund_amount': 100}
decision = decide_refund(order, thresholds)
result = run_workflow(order, decision)
print(result)
```

启动与请求：把上述代码保存为 `refund_v1.py` 后执行：

```bash
python refund_v1.py
```

示例输出：

```console
{'order_id': 'O-1001', 'status': 'refund_tool_called', 'evidence': {'decision': 'auto_refund', 'reason': 'low_amount_paid_unshipped'}}
```

验证点：退款建议有 decision 和 reason；工作流状态明确；证据与订单绑定。留下的问题也很明显：金额币种未统一、企业规则版本未绑定、人工审批没有超时和幂等。

> 先跑通一条链
> 再暴露新缺口
> 不把 Prompt 当库
> 证据先落地

# 06、排查

第一条诊断链。现象：企业 B 一笔 300 CNY 退款被建议自动退款，没有进人工审批。怀疑：模型忽略了高金额条件。检查：读取决策日志、规则版本、租户配置。证据：日志显示加载的是 enterprise_a 的 `refund-dmn-v1`，企业 B 规则没有生效。根因：规则执行器只按全局版本加载，租户与规则版本没有绑定。修复：决策请求必须携带 tenant 和 rule_version，加载失败时拒绝自动退款。

**错误尝试：** 有人建议把阈值再写回 Prompt，并在提示词里加一句“高金额必须审批”。这个尝试错在把确定性规则降级为概率约束，模型可能这次遵守，但无法保证每次遵守，也无法审计命中哪条规则。

第二条诊断链。现象：同一订单在中英文对话里得到不同退款金额。怀疑：LLM 换算币种出错。检查：本体实例、支付记录、订单金额字段。证据：订单金额是 USD，支付记录是 CNY，本体只有 `amount`，没有 `currency` 和 `exchange_rate` 关系。根因：本体缺语义，字段名相同不代表含义相同。修复：本体增加 Money 值对象、Currency、PaymentMethod 和订单-支付关系，决策前先归一金额。

第三条诊断链。现象：人工审批通过后，退款 Tool 被调用两次。怀疑：Workflow 重试没有幂等。检查：审批任务状态、Tool 调用日志、审计事件。证据：审批节点超时重试后再次发布 `approved` 事件。根因：流程状态机缺少幂等键和去重窗口。修复：用 refund_case_id 作为幂等键，Tool 网关检查执行记录。

> 现象先分开
> 证据再说话
> 根因落层级
> 修复不拍脑袋

# 07、优化

基于第 06 章证据，V2 做四个修改。第一，规则版本按 tenant 绑定，决策请求显式携带 `tenant`、`rule_version`、`ontology_version`。原因是多企业差异不能靠 Prompt 兜底。新行为是加载失败时拒绝自动退款，转入人工。验证方案：对企业 A、B 分别回放同一订单，检查命中的规则版本和决策原因。

第二，本体扩展 Money、Currency、PaymentMethod 和订单-支付-退款案件关系。原因是金额与币种不能只靠字段名。新行为是决策前把金额归一成企业结算币种。验证方案：构造 USD/CNY 混合订单，检查归一结果和证据字段。

第三，Workflow 增加 `pending_approval`、`approved`、`refund_called`、`refund_failed` 状态，并用 `refund_case_id` 做幂等键。原因是流程重试必须可恢复。新行为是重复审批事件不会重复调用 Tool。验证方案：重复发送 approved 事件，检查 Tool 调用记录只有一条。

第四，输出结构化契约：decision、reason、rule_version、evidence、next_action。原因是下游系统和审计不能解析自然语言。验证方案：用 Schema 校验每次输出，不合规直接进入人工队列。

> 规则绑租户
> 本体补语义
> 流程加幂等
> 输出成契约

# 08、演进

```text
[同一输入] 订单 O-1001，企业 B，300 CNY
    |
    +--[V1] Prompt 混合规则 / 无租户版本 / 可能误自动退款
    |
    +--[V2] 本体归一变币种 + DMN 决策 + Workflow 审批 / 可审计
    |
[Trade-off]
得到可验证与可审计，失去一次性 Prompt 的短期灵活；适用于多企业生产，不适用于纯演示。
```

正确性上，V1 依赖模型遵循文本，V2 把条件交给规则和流程；稳定性上，V2 对多企业、多语言更稳，但组件更多；复杂度上，V2 增加本体、规则版本、状态机；成本上，需要治理模型和版本，但减少误退款与返工；适用范围上，V2 适合生产客服，V1 适合原型；遗留问题包括审批超时策略、跨渠道状态同步、规则灰度发布。

> 旧版求快
> 新版求稳
> 取舍看场景
> 边界要写清

# 09、洞见

## 9.1 本体是业务世界的名词和关系，不是条件分支

反直觉判断：本体越像“数据字典”，越容易失败；它必须表达关系、约束和值对象。退款场景里，订单、支付、退款案件、审批任务不是孤立表，它们之间的关系决定证据链能否成立。

## 9.2 规则必须可版本化、可测试、可追溯

反直觉判断：把规则写进 Prompt 看似灵活，实际把可测试性交给了概率。DMN 或 Drools 式规则的价值不在引擎本身，而在于条件、输入、输出和版本可以单独回归。企业 B 改阈值，不应该影响企业 A。

## 9.3 流程回答时序、责任和恢复，不回答业务真值

BPMN 式流程关心的是何时创建审批任务、谁处理、失败后怎么重试。它不判断订单是否已支付，只消费决策结果。把流程和规则混在一起，会造成“审批通过但条件不满足”或“条件满足但状态丢失”。

## 9.4 Prompt 是交互层和编排入口，不是业务语义层

Prompt 可以理解多语言意图、抽取槽位、生成解释，但最终决策必须落到结构化事实和规则。反直觉判断：让 Prompt 少承担业务真值，反而能让 Agent 在更复杂场景里更可靠。

> 本体立世界
> 规则定真假
> 流程管时序
> 模型管对话

# 10、系统落地

原来有什么：全球智能客服平台已有对话入口、工单、CRM、订单和支付连接，以及基础的退款 Tool。原来缺的是把业务语义、决策和流程显式分开，导致多企业场景靠 Prompt 硬撑。

本篇新增什么：退款本体片段、DMN 风格决策表、Workflow 状态与审批节点、结构化证据契约。现在能做什么：同一退款请求可完成意图识别、事实归一、规则评估、流程路由、人工审批和 Tool 调用，并留下可追溯证据。

还缺什么：规则版本灰度、审批超时、跨渠道案件同步、多语言本体标签、Tool 权限和审计。下一步演进是把本体扩展到商品、物流和工单，把 DMN 接入 Drools/KIE 或等价执行器，把 BPMN 流程服务化，并让评测覆盖误退款、漏审批和重复调用。

> 平台添一层
> 语义可复用
> 决策可验证
> 流程可恢复

# 11、小结

```text
Q1 → 本体管业务世界有什么及如何关联，规则管条件到结论，流程管何时由谁执行
Q2 → 把退款拆成本体事实、DMN 决策、Workflow 审批和 Tool 执行，Prompt 只做归一与解释
Q3 → 拆错会让误退款、漏审批、难审计、改一处崩三处
状态 → 退款链路已具备本体、规则、流程三层可验证骨架
```

这条骨架不依赖某一家模型，也不把企业规则锁在提示词里。它让客服 Agent 从“会回答”进入“能承担业务责任”的阶段。

> 三责先分开
> 链路才可测
> 证据落下来
> 智能才可用

# 12、作业

## 12.1 理解题：为什么本体不能直接写成 if-else 规则？

参考答案：本体描述概念、属性、关系和约束，解决“有什么以及如何关联”。if-else 是决策逻辑，属于规则层。把两者混在一起，会导致语义复用差、规则版本无法独立治理，也难以回答证据来自哪个业务事实。

## 12.2 实战题：为“退款条件满足→生成退款建议→高金额人工审批→调用退款 Tool”画出三层分工。

参考答案：本体层定义 Order、Payment、RefundCase、ApprovalTask、Customer 及关系；规则层用 DMN 决策表判断是否满足退款、是否高金额、是否需补资料；Workflow 层根据 decision 进入 auto_refund 或 pending_approval，人工通过后由 Tool 网关调用退款 Tool，并写入审计事件。

## 12.3 排障题：审批通过后退款 Tool 被调用两次，你先查什么？

参考答案：先查 Workflow 状态与幂等键，再查审批事件是否重复发布，最后查 Tool 网关执行记录。不要先改 Prompt 或提高模型温度。根因通常在状态机缺少幂等和去重，而不是模型不聪明。

## 12.4 架构判断题：多企业客服平台，应该让每个租户维护一套 Prompt，还是维护一套本体、规则和流程资产？

参考答案：优先维护可版本化的本体、规则和流程资产，Prompt 作为交互层按租户做轻量适配。每个租户一套 Prompt 短期快，长期会出现不可审计、不可测试、无法复用和升级困难。资产化分层更适合多企业生产。

> 题练分层眼
> 手拆退款链
> 证据成习惯
> 架构不靠猜

# 13、思考

回到核心冲突：Prompt 不是不能写业务，而是不能独自承担业务真值。本体、规则和流程分别解决“有什么”“满足什么条件得出什么结果”“什么时候由谁执行”。当这三层分开，LLM 才能被放在正确位置：理解意图、归一多语言输入、解释结果、调用受控工具。

可复用的工程判断是：只要一个客服场景需要多企业差异、审计、审批或恢复，就不要把条件、状态和执行顺序继续塞进 Prompt。先把本体立住，再把规则版本化，最后用 Workflow 管住人机边界。

> 一问分三层
> 一拆见边界
> 一证留证据
> 一链可生产

我是老李，在做全球智能客服平台的 FDE。这个平台同时服务多企业、多项目、多语言、多渠道，后面连着 CRM、订单、支付、物流、工单和知识库。客服 Agent 不只是聊天，它要真能推进业务。

FDE进化36记-第22记-规则、本体和业务语义层到底怎么分工？

用退款链路拆开本体、DMN 规则与 Workflow：本体管业务世界，规则管条件结论，流程管何时谁执行。

架构师

架构设计

后端

开发工具

将退款链路拆分为本体语义层、DMN规则层与BPMN流程层，Prompt仅负责意图归一与交互，确保决策可审计、规则可版本化、流程可恢复，解决多企业退款中误判、难追责与改动连锁问题。

代码解释

数据库

路由

Python

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

FDE进化36记-第22记-规则、本体和业务语义层到底怎么分工？-腾讯云开发者社区-腾讯云

FDE进化36记-第22记-规则、本体和业务语义层到底怎么分工？

FDE进化36记-第22记-规则、本体和业务语义层到底怎么分工？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐