大模型应用：Drools+混元大模型：企业级智能决策的“规则+底线”双引擎.88

一、前言

现在企业数字化转型越走越深，智能决策系统说白了，就是要既守住合规风控的底线，又能做好用户体验，这两者平衡好了，业务才能稳。很多传统企业早就用Drools规则引擎，搭起了一套成熟的刚性决策逻辑，靠着明确的IF-THEN规则，把业务底线守得牢牢的，不管是合同审核、合规检查，还是客服流程，只要触碰到规则红线，就能精准拦截风险，这也是企业合规治理的核心底气。但说实话，纯靠规则引擎也有短板，而且越到实际应用中越明显：非结构化的文本它读不懂，那些没明确规则的长尾模糊场景它处理不了，输出的结果也冷冰冰的，一点不人性化，跟不上现在复杂多变的业务节奏，也满足不了用户对体验的要求。

而大模型技术的普及，刚好给这个难题提供了实实在在的破局办法。它最厉害的就是能读懂自然语言、能结合上下文推理，还能柔性生成内容，正好补上了规则引擎的短板，不用再死卡规则，能对业务内容做智能解读、优化表述，还能给出合理化建议，把原来冷冰冰的判定，变成了有温度的柔性服务。

现在我们把Drools规则引擎和大模型深度结合，搭一套"硬规则兜底、大模型做柔性处理"的双引擎决策架构：规则引擎管死合规底线，坚决不碰风险；大模型专注优化业务体验，搞定那些柔性场景。今天我们就从Drools的核心组件讲起，结合大模型协同落地，把"规则管底线，大模型管体验"这个实用的企业智能决策方式弄个清楚明白。

二、核心基础

1. 基础概念

1.1 Drools 规则引擎

• **定位：**执行确定性、刚性、可编码的业务规则；好比企业的"合规门卫"。
• **本质：**规则即代码，执行即合规。
• 特点：
  • 明确触发条件：如"合同金额 > 100万"、"文本包含'退款不处理'"。
  • 强制执行动作：如"拒绝提交""打回修改""记录违规日志"。
  • 无模糊空间：规则是布尔逻辑（是/否），不依赖上下文理解或概率判断。
  • 高可靠可审计：每条规则可追溯、可测试、可监管，符合合规要求。
• 核心原理： Rete算法是 Drools 高效匹配规则的核心，通俗理解：
  • 将所有规则拆解为"条件节点"，如"金额 > 100 万"、"无法人签字"，构建成"规则匹配网络"；
  • 新数据进入时，仅遍历网络匹配符合的节点，无需逐条检查所有规则，大幅提升匹配效率，适合企业级海量规则场景。
• **核心价值：**守住企业运营的法律、风控、流程底线，防止"低级错误"或"红线行为"。

1.2 大模型（LLM）

• **定位：**处理非结构化、模糊、需语义理解与生成的任务；好比企业的"智能管家"。
• **本质：**理解即服务，生成即优化。
• 特点：
  • 理解意图与语境：能识别"语气生硬"、"条款歧义"、"用户焦虑"等软性信号。
  • 生成柔性建议：如"建议将'概不负责'改为'在合理范围内承担相应责任'"。
  • 具备泛化能力：面对未见过的表述，也能基于常识和训练数据推理。
  • 不可完全确定：输出具有概率性，需配合约束或后处理。
• 核心原理：
  • Prompt 工程：通过精准提示词引导大模型生成符合需求的内容，如"优化合同条款，保持核心权责不变，表述更专业"；
  • 上下文理解：基于海量语料训练的语义能力，识别文本中的模糊表述、用户情绪等柔性信息；
  • 结果可控性：规则兜底保证大模型输出不触碰底线，即使生成内容有小问题，也不违反合规规则。
• **核心价值：**提升用户体验、沟通效率、内容质量，实现"有温度的智能"。

1.3 融合的核心思想

• **分层决策，刚柔并济：**先让"门卫"（Drools）检查是否触碰底线，底线没问题再让"管家"（大模型）做柔性优化；若触碰底线，规则引擎直接拦截，大模型仅辅助解释原因。
• **本质：**先保安全，再求卓越。
• 融合架构原理：
  • 数据分离：结构化数据（金额、签约方）给 Drools 做规则匹配，非结构化文本（合同原文）给大模型做柔性处理；
  • 决策触发：Drools 的输出作为大模型的执行条件，仅规则通过时，大模型才做优化；
  • 结果融合：结构化规则结论 + 非结构化大模型建议 = 完整决策。
• 执行流程：
  • 1. 输入（如合同草稿、客服回复）首先进入 Drools 规则引擎；
  • 2. 若触发任一禁止性规则 → 立即拒绝，并可调用 LLM 生成人性化解释，如："因合同金额超100万，缺少法人签字，暂无法通过"；
  • 3. 若未触碰底线 → 交由 大模型进行润色、建议、情绪适配等柔性处理；
  • 4. 最终输出 = 合规 + 体验优化 的结果。

2. Drools规则引擎基础

• **本质：**开源Java规则引擎，遵循 Rete 算法，将业务规则从代码中抽离为"IF-THEN"形式，如IF 合同金额>100万 AND 无法人签字 THEN 驳回，无需改代码即可调整规则。
• 核心组件：
  • 规则库（Rule Base）：存放所有硬规则的"手册"，如合规条款、业务底线；
  • 工作内存（Working Memory）：存放待检查的业务数据，如合同金额、客服对话；
  • 推理引擎（Inference Engine）：用Rete算法匹配"手册"和"数据"，是规则引擎的大脑。
• **核心优势：**规则可配置、执行高效、结果可解释，适合做底线管控。

3. 大模型的柔性处理能力

• **核心特点：**理解自然语言、上下文推理、生成人性化内容，覆盖"无明确规则但需主观判断"的长尾场景。
• 体现的价值：
  • 提升体验：规则引擎仅输出"是/否"，大模型可输出"为什么 + 怎么做"，如合同审核后不仅说"合规"，还告诉"哪条条款可优化"；
  • 降低规则维护成本：无需为所有长尾场景编写规则，如客服的每一种情绪都写规则不现实，大模型可覆盖；
  • 增强解释性：将冰冷的规则条款转化为通俗易懂的语言，如"违规原因：金额超 100 万无法人签字 → 整改建议：补充法人签字页"；
  • 拓展业务边界：规则引擎只能处理可量化规则，大模型可处理主观判断场景，如合同条款是否公平。
• 企业场景适配：
  • 合同审核：规则通过后优化条款表述、提示潜在风险；
  • 客服流程：规则校验无敏感词后，根据用户情绪调整回复语气；
  • 合规检查：规则未违规时，生成通俗易懂的合规说明。

4. 核心对比总结

维度	Drools 规则引擎（硬规则）	大模型（柔性处理）
核心目标	合规管控、风险拦截、守住底线	体验提升、内容优化、建议生成
规则形式	明确 IF-THEN 规则，可量化	无固定规则，依赖上下文推理
结果特性	确定性、可解释、零容错	灵活性、人性化、可容错
典型输出	"违规，驳回""合规，通过"	"条款建议优化为 XXX""回复语气可更温和"

三、Drools核心组件

Drools 规则引擎的核心组件围绕"规则怎么存、数据怎么放、怎么匹配执行"三大核心问题设计，我们可以把 Drools 比作一位企业合规审核员，每个组件对应审核员的工具和工作区域，先通过表格快速建立认知：

核心组件	通俗比喻	核心职责
Rule Base（规则库）	审核员的 "规则手册"	存储所有已编译的刚性业务规则
Fact（事实）	待审核的 "原始材料"	待匹配的结构化业务数据（如合同金额、签字状态）
Working Memory（工作内存）	审核员的 "工作台"	临时存放 Fact，供推理引擎匹配规则
Inference Engine（推理引擎）	审核员的 "大脑"	匹配 Fact 与规则，决定执行哪些规则
Agenda（议程）	审核员的 "待办清单"	存放匹配成功的规则，按优先级排序等待执行
KieSession（KIE 会话）	审核员的 "一次完整审核流程"	所有组件协作的入口，封装完整执行生命周期

1. Rule Base（规则库）

• **通俗定义：**就像审核员手里的《企业合规规则手册》，里面写满了所有不能突破的刚性规则，比如"合同金额超 100 万必须有法人签字"，手册内容可随时更新，不用重新培训审核员，不用改代码。
• 技术细节：
  • 存储的是已编译的DRL规则，DRL是 Drools 专属的规则语言，格式为rule "规则名" when 条件 then 动作 end；
  • 支持规则分组管理，如按业务域分"合同合规组"、"财务审批组"，版本管理如 V1.0 规则适配旧合同，V2.0 适配新合同；
  • Drools 6 + 后整合到 KieBase 中，KieBase 是 Rule Base 的升级版，包含规则库 + 知识库元数据。

2. Fact（事实）

• **通俗定义：**就是交给审核员的"待审核材料"，比如合同的结构化数据（金额、签约方、是否有法人签字）、客服对话的敏感词检测数据等，是规则匹配的原材料。
• 技术细节：
  • 本质是普通的Java对象（POJO）或 JSON/Map 等结构化数据，比如Contract类，包含 amount、hasLegalSign等属性；
  • Fact 默认只读，若需修改需通过update($fact)通知工作内存，否则推理引擎无法感知变化；
  • 支持动态插入（insert）、删除（retract）、更新（update），是规则匹配的唯一数据源。

3. Working Memory（工作内存）

• **通俗定义：**审核员的"工作台"，所有待审核的Fact都放在这里，方便审核员（推理引擎）随时拿取和规则手册比对，审核完成后工作台会清空。
• 技术细节：
  • 内存级临时存储区域，会话结束后数据自动清空；
  • 核心功能是Fact 管理：接收业务系统插入的 Fact，向推理引擎提供匹配数据源；
  • 当Fact被更新（update）时，会触发"规则重新匹配"，比如修改合同金额后，重新检查是否命中金额相关规则。

4. Inference Engine（推理引擎）

• **通俗定义：**审核员的"大脑"，核心能力是把工作台上的Fact（合同数据）和规则手册（Rule Base）里的规则逐条比对，找出符合条件的规则，同时决定先执行哪条。
• 技术细节：
  • 核心算法：Drools 6 + 默认使用Phreak 算法（Rete 算法的优化版），通过"规则条件网络"大幅提升海量规则下的匹配效率，比如1000条规则时，无需逐条比对，仅匹配符合条件的节点；
• 核心流程：
  • 1. 模式匹配（Pattern Matching）：比对 Fact 和规则的条件（LHS），找出匹配的规则；
  • 2. 冲突解决（Conflict Resolution）：当多个规则匹配成功时，按"优先级（salience）、规则插入顺序、事实更新时间" 等策略排序；
  • 3. 规则执行（Rule Firing）：按排序结果触发规则的动作（RHS）。
• 企业场景示例：
  • 推理引擎匹配到"金额 150 万 + 无法人签字"的 Fact，命中 CONTRACT_001 规则，判定该合同需驳回。

5. Agenda（议程）

• **通俗定义：**审核员的"待办清单"，所有匹配成功的规则都会被放进这个清单，清单会按优先级排序，比如"金额违规"比"条款不规范"优先级高，审核员按清单顺序执行。
• 技术细节：
  • 存储的是 "规则激活实例（Activation）"，即"匹配成功的规则 + 对应的 Fact"；
  • 支持议程组（Agenda Group） ：可将规则分组，比如"紧急规则组"、"普通规则组"，通过kieSession.getAgenda().getAgendaGroup("urgent").setFocus()指定只执行某组规则；
  • 可手动控制规则执行：比如kieSession.fireUntilHalt()（持续执行直到暂停）、kieSession.fireAllRules()（执行所有匹配规则）。
• 企业场景示例：
  • 合同审核中，CONTRACT_001 规则（salience=10）和 CONTRACT_002 规则（salience=5）都匹配成功，Agenda 会先把 CONTRACT_001 排在前面，优先执行驳回操作。

6. KieSession（KIE 会话）

• **通俗定义：**审核员的"一次完整审核流程"，是业务系统和 Drools 交互的唯一入口，所有组件（Rule Base、Working Memory、Agenda、推理引擎）都通过会话协作完成一次规则执行。
• 技术细节： 分为两种类型：
  • StatefulKieSession（有状态会话）：支持多次插入 Fact、多次触发规则，比如先插入合同基本信息，再插入补充条款，分次匹配规则，适合长流程业务；
  • StatelessKieSession（无状态会话）：一次插入 Fact + 一次触发规则 + 结束，适合短流程，如单次客服敏感词检测；
• **生命周期：**创建→插入 Fact→触发规则→执行规则→关闭会话，必须关闭，释放内存。

7. 组件协作流程

以合同审核为例，组件间的完整协作流程如下：

流程总结：

• **Drools 核心组件的核心分工：**Rule Base 存规则、Working Memory 存数据、推理引擎做匹配、Agenda 排顺序、KieSession 做入口，Fact 是贯穿全程的匹配对象。
• **组件协作的核心逻辑：**业务系统通过 KieSession 插入 Fact→推理引擎匹配 Fact 与 Rule Base 的规则→匹配成功的规则进入 Agenda 排序→按顺序执行规则动作→返回结果。
• **执行落地关键：**优先使用 StatefulKieSession 处理长流程业务，通过"规则分组 + 优先级"控制执行顺序，Fact更新后需调用update()通知工作内存，确保规则重新匹配。

四、执行流程

以合同审核为例，完整执行流程如下

主要步骤说明：

• **1. 数据预处理：**将非结构化合同文本转为规则引擎可识别的结构化数据（如提取金额、签约方），同时保留原文供大模型处理；
• **2. Drools 硬规则校验：**加载合规规则库，匹配结构化数据，判断是否触碰底线（结果唯一、可解释）；
• **3. 大模型柔性处理：**规则通过则优化文本、提建议；规则驳回则仅解释原因（不改变规则结论）；
• **4. 结果整合：**返回 "规则结论 + 大模型建议" 的完整审核结果。

五、案例详细分析

1. 定义Drools规则引擎的API接口

1.1 核心思路

Drools 的核心是"IF-THEN"规则匹配 + 执行，我们用 Python 实现一个轻量化模拟版本：

• 规则定义：用 JSON/字典格式模拟DRL规则，保留 Drools 的核心要素：规则 ID、优先级、条件、动作；
• 接口服务：用 FastAPI 搭建 REST API，模拟 Drools 的规则校验接口；
• 规则引擎核心逻辑：实现 "事实插入→规则匹配→冲突解决（优先级）→规则执行" 的完整流程。

1.2 规则引擎 + FastAPI 接口

提供一个 Drools 规则引擎的 REST API 接口，包含可直接运行的服务端代码、详细的规则定义样例（覆盖不同业务场景），主要目的是提供后续的合同审核中实际调用执行；

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List, Dict, Any, Optional
import uvicorn

# --------------------------
# 1. 数据模型定义（模拟Drools的Fact和Rule）
# --------------------------
# 规则条件模型（模拟DRL的LHS：Left Hand Side 条件部分）
class RuleCondition(BaseModel):
    field: str          # 匹配的字段名（如amount、has_legal_sign）
    operator: str       # 运算符（>、<、==、!=、>=、<=）
    value: Any          # 匹配值

# 规则动作模型（模拟DRL的RHS：Right Hand Side 动作部分）
class RuleAction(BaseModel):
    action_type: str    # 动作类型（set_field：设置字段，log：日志输出）
    field: Optional[str] = None  # 要设置的字段名
    value: Any          # 要设置的值/日志内容

# 规则模型（模拟Drools的Rule定义）
class Rule(BaseModel):
    rule_id: str        # 规则唯一ID（如CONTRACT_001）
    salience: int = 0   # 优先级（数值越高越先执行，模拟Drools的salience）
    conditions: List[RuleCondition]  # 规则条件（多个条件为AND关系）
    actions: List[RuleAction]        # 规则动作（按顺序执行）

# 事实模型（模拟Drools的Fact，以合同审核为例）
class ContractFact(BaseModel):
    contract_id: str
    amount: float               # 合同金额
    has_legal_sign: bool        # 是否有法人签字
    has_stamp: bool             # 是否盖公章
    audit_result: str = ""      # 审核结果（初始为空）
    violation_reason: str = ""  # 违规原因（初始为空）

# --------------------------
# 2. 规则引擎核心类（模拟Drools的推理引擎+Agenda+Working Memory）
# --------------------------
class DroolsSimulator:
    def __init__(self):
        # 规则库（模拟Rule Base）：存储所有规则
        self.rule_base: List[Rule] = []
        # 工作内存（模拟Working Memory）：存储待匹配的Fact
        self.working_memory: List[Any] = []

    def add_rule(self, rule: Rule):
        """添加规则到规则库"""
        self.rule_base.append(rule)
        # 按优先级排序（模拟Agenda的冲突解决策略）
        self.rule_base.sort(key=lambda x: x.salience, reverse=True)

    def insert_fact(self, fact: Any):
        """插入Fact到工作内存"""
        self.working_memory.append(fact)

    def _match_condition(self, fact: Any, condition: RuleCondition) -> bool:
        """匹配单个规则条件（核心：实现运算符逻辑）"""
        # 获取Fact的字段值
        fact_value = getattr(fact, condition.field, None)
        if fact_value is None:
            return False
        
        # 执行运算符匹配
        if condition.operator == ">":
            return fact_value > condition.value
        elif condition.operator == "<":
            return fact_value < condition.value
        elif condition.operator == "==":
            return fact_value == condition.value
        elif condition.operator == "!=":
            return fact_value != condition.value
        elif condition.operator == ">=":
            return fact_value >= condition.value
        elif condition.operator == "<=":
            return fact_value <= condition.value
        else:
            raise ValueError(f"不支持的运算符：{condition.operator}")

    def _match_rule(self, fact: Any, rule: Rule) -> bool:
        """匹配单个规则的所有条件（AND关系）"""
        for condition in rule.conditions:
            if not self._match_condition(fact, condition):
                return False
        return True

    def _execute_action(self, fact: Any, action: RuleAction):
        """执行规则动作"""
        if action.action_type == "set_field":
            # 设置Fact字段值（模拟Drools的修改Fact）
            setattr(fact, action.field, action.value)
        elif action.action_type == "log":
            # 日志输出（模拟Drools的控制台输出）
            print(f"[规则执行日志] {action.value}")
        else:
            raise ValueError(f"不支持的动作类型：{action.action_type}")

    def fire_all_rules(self) -> List[Any]:
        """触发所有匹配的规则（模拟Drools的fireAllRules）"""
        results = []
        for fact in self.working_memory:
            # 遍历规则库（已按优先级排序）
            for rule in self.rule_base:
                # 匹配规则
                if self._match_rule(fact, rule):
                    # 执行规则动作
                    for action in rule.actions:
                        self._execute_action(fact, action)
            results.append(fact)
        # 清空工作内存（模拟会话结束）
        self.working_memory.clear()
        return results

# --------------------------
# 3. FastAPI接口搭建（模拟Drools的REST API）
# --------------------------
app = FastAPI(title="Drools规则引擎模拟器", version="1.0")
# 初始化规则引擎实例
drools_engine = DroolsSimulator()

# --------------------------
# 接口1：添加规则到规则库
# --------------------------
@app.post("/drools/rules/add", summary="添加规则到规则库")
def add_rule(rule: Rule):
    try:
        drools_engine.add_rule(rule)
        return {"code": 200, "msg": f"规则{rule.rule_id}添加成功", "data": rule}
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"添加规则失败：{str(e)}")

# --------------------------
# 接口2：合同审核规则校验（核心接口）
# --------------------------
@app.post("/drools/contract/check", summary="合同审核规则校验")
def contract_check(fact: ContractFact):
    try:
        # 插入Fact到工作内存
        drools_engine.insert_fact(fact)
        # 触发规则执行
        result = drools_engine.fire_all_rules()[0]
        return {
            "code": 200,
            "msg": "规则校验完成",
            "data": {
                "contract_id": result.contract_id,
                "audit_result": result.audit_result,
                "violation_reason": result.violation_reason,
                "original_data": {
                    "amount": result.amount,
                    "has_legal_sign": result.has_legal_sign,
                    "has_stamp": result.has_stamp
                }
            }
        }
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"规则校验失败：{str(e)}")

# --------------------------
# 接口3：获取规则库所有规则
# --------------------------
@app.get("/drools/rules/list", summary="获取规则库所有规则")
def list_rules():
    return {
        "code": 200,
        "msg": "获取规则列表成功",
        "data": [rule.dict() for rule in drools_engine.rule_base]
    }

# --------------------------
# 启动服务
# --------------------------
if __name__ == "__main__":
    # 启动UVicorn服务，访问地址：http://127.0.0.1:8000/docs 可查看接口文档
    uvicorn.run(app, host="0.0.0.0", port=8000)

1.3 详细规则样例解析

1.3.1 规则样例 1（核心违规规则：CONTRACT_001）

{
    "rule_id": "CONTRACT_001",
    "salience": 10,
    "conditions": [
        {"field": "amount", "operator": ">", "value": 1000000},
        {"field": "has_legal_sign", "operator": "==", "value": False}
    ],
    "actions": [
        {"action_type": "set_field", "field": "audit_result", "value": "驳回"},
        {"action_type": "set_field", "field": "violation_reason", "value": "合同金额超100万但无法人签字，违反CONTRACT_001规则"},
        {"action_type": "log", "value": "触发规则CONTRACT_001：合同驳回"}
    ]
}

核心要素解析：

• rule_id：规则唯一标识，对应 Drools 的rule "CONTRACT_001"；
• salience：优先级 10（最高），模拟 Drools 的salience 10，确保高风险规则先执行；
• conditions：规则条件（AND 关系），对应 Drools 的when部分，只有两个条件都满足才触发规则；
• actions：规则动作，对应 Drools 的then部分，按顺序执行"设置审核结果→设置违规原因→输出日志"。

1.3.2 规则样例 2（警告类规则：CONTRACT_002）

{
    "rule_id": "CONTRACT_002",
    "salience": 5,
    "conditions": [
        {"field": "has_legal_sign", "operator": "==", "value": True},
        {"field": "has_stamp", "operator": "==", "value": False}
    ],
    "actions": [
        {"action_type": "set_field", "field": "audit_result", "value": "通过（需补章）"},
        {"action_type": "set_field", "field": "violation_reason", "value": "合同有法人签字但无公章，需补充公章"},
        {"action_type": "log", "value": "触发规则CONTRACT_002：合同需补章"}
    ]
}

设计思路：

• 优先级 5（中），低于核心违规规则，确保先检查高风险问题；
• 条件为 "有签字但无公章"，属于非致命问题，因此审核结果为 "通过（需补章）"，兼顾合规性和灵活性；
• 动作部分明确提示整改方向，符合企业 "底线不突破，细节可优化" 的需求。

1.3.3 规则样例 3（合规规则：CONTRACT_003）

{
    "rule_id": "CONTRACT_003",
    "salience": 1,
    "conditions": [
        {"field": "amount", "operator": "<=", "value": 1000000},
        {"field": "has_legal_sign", "operator": "==", "value": True},
        {"field": "has_stamp", "operator": "==", "value": True}
    ],
    "actions": [
        {"action_type": "set_field", "field": "audit_result", "value": "通过"},
        {"action_type": "set_field", "field": "violation_reason", ""},
        {"action_type": "log", "value": "触发规则CONTRACT_003：合同审核通过"}
    ]
}

设计思路：

• 优先级 1（最低），确保先匹配高优先级的违规\警告规则，只有所有高优先级规则不匹配时才触发此规则；
• 条件为"金额≤100 万 + 有签字 + 有公章"，完全符合合规要求，因此违规原因为空，审核结果为"通过"。

1.4 运行启动

启动完成后，通过http://localhost:8000/drools/contract/check接口进行调用；

2. 基于规则引擎+大模型的合同审核

我们采用的是混元大模型，首先要配置好刚才启动的Drools调用地址DROOLS_API_URL，同时要申请混元大模型的api_key；

import os
import json
import requests
from openai import OpenAI
from dotenv import load_dotenv

# 加载环境变量
load_dotenv()

# --------------------------
# 1. 配置项
# --------------------------
# 模拟Drools REST API地址（实际替换为真实Drools服务地址）
DROOLS_API_URL = "http://localhost:8000/drools/contract/check"
# 腾讯混元大模型配置
HUNYUAN_API_KEY = os.getenv("HUNYUAN_API_KEY", "sk-WlJPK********************vZ5NP8Ze")
client = OpenAI(
    api_key=HUNYUAN_API_KEY,
    base_url="https://api.hunyuan.cloud.tencent.com/v1"
)

# --------------------------
# 2. Drools规则校验函数（模拟+真实接口兼容）
# --------------------------
def drools_contract_check(contract_data):
    """
    调用Drools做硬规则校验（兜底）
    :param contract_data: 合同结构化数据
    :return: 规则校验结果
    """
    try:
        # 调用真实Drools REST API
        response = requests.post(
            DROOLS_API_URL,
            json=contract_data,
            headers={"Content-Type": "application/json"}
        )
        response.raise_for_status()
        return response.json()
    except Exception as e:
        # 本地模拟规则校验（方便测试）
        print(f"Drools接口未部署，使用本地模拟：{e}")
        # 核心规则：金额>100万且无法人签字 → 违规
        if contract_data["amount"] > 1000000 and not contract_data["has_legal_sign"]:
            return {
                "pass": False,
                "violation_reason": "合同金额超100万但无法人签字，违反合规规则CONTRACT_001",
                "rule_id": "CONTRACT_001"
            }
        else:
            return {"pass": True, "violation_reason": "", "rule_id": ""}

# --------------------------
# 3. 大模型柔性处理函数
# --------------------------
def llm_contract_optimize(contract_text, rule_result):
    """
    调用大模型做柔性处理（体验优化）
    :param contract_text: 合同原始文本
    :param rule_result: 规则校验结果
    :return: 大模型生成的建议
    """
    # 规则违规：仅生成解释+整改建议
    if not rule_result["pass"]:
        prompt = f"""
        请以通俗易懂的语言解释以下合同违规原因，并给出具体整改建议：
        违规原因：{rule_result["violation_reason"]}
        要求：整改建议可落地，语言简洁。
        """
    # 规则合规：优化文本+提示潜在风险
    else:
        prompt = f"""
        请优化以下合同文本，要求：
        1. 表述更专业、无歧义，不改变核心权责；
        2. 提示潜在的非合规风险（非违规，但需注意）；
        3. 建议简洁明了，分点列出。
        合同文本：{contract_text}
        """

    # 调用腾讯混元大模型
    try:
        completion = client.chat.completions.create(
            model="hunyuan-lite",
            messages=[
                {"role": "system", "content": "你是专业的合同审核顾问，擅长合规解释和文本优化。"},
                {"role": "user", "content": prompt}
            ],
            temperature=0.3  # 降低随机性，保证结果稳定
        )
        return completion.choices[0].message.content
    except Exception as e:
        return f"大模型处理失败：{str(e)}"

# --------------------------
# 4. 主流程：Drools+大模型融合
# --------------------------
def contract_review_main(contract_data, contract_text):
    """合同审核主流程：先规则，后大模型"""
    # 第一步：Drools硬规则校验
    print("===== 1. Drools规则引擎校验 =====")
    rule_result = drools_contract_check(contract_data)
    print(f"规则结果：{rule_result}\n")

    # 第二步：大模型柔性处理
    print("===== 2. 大模型柔性处理 =====")
    llm_result = llm_contract_optimize(contract_text, rule_result)
    print(f"大模型建议：{llm_result}\n")

    # 第三步：整合最终结果
    final_result = {
        "rule_check": rule_result,
        "llm_suggestion": llm_result,
        "final_conclusion": "审核不通过" if not rule_result["pass"] else "审核通过，建议参考优化意见"
    }

    print("===== 3. 最终审核结果 =====")
    print(final_result)
    return final_result

# --------------------------
# 5. 测试用例
# --------------------------
if __name__ == "__main__":
    # 测试用例1：违规合同（金额150万，无法人签字）
    test_contract_data_1 = {
        "contract_id": "CON20260213001",
        "amount": 1500000,
        "has_legal_sign": False,
        "parties": ["甲方A", "乙方B"]
    }
    test_contract_text_1 = """
    甲方A与乙方B签订购销合同，合同金额150万元，甲方应在2026年3月1日前支付全款，乙方应在付款后7日内交货。
    本合同一式两份，双方各执一份，签字后生效。
    """
    contract_review_main(test_contract_data_1, test_contract_text_1)

    # 测试用例2：合规合同（金额50万，有法人签字）
    print("\n" + "-"*60 + "\n")
    test_contract_data_2 = {
        "contract_id": "CON20260213002",
        "amount": 500000,
        "has_legal_sign": True,
        "parties": ["甲方C", "乙方D"]
    }
    test_contract_text_2 = """
    甲方C与乙方D签订服务合同，合同金额50万元，甲方应在服务完成后10日内支付费用，乙方应提供6个月的售后保障。
    本合同无明确的违约责任条款，双方口头约定如有争议协商解决。
    """
    contract_review_main(test_contract_data_2, test_contract_text_2)

输出结果：

===== 1. Drools规则引擎校验 =====

Drools接口未部署，使用本地模拟：422 Client Error: Unprocessable Entity for url: http://localhost:8000/drools/contract/check
规则结果：{'pass': False, 'violation_reason': '合同金额超100万但无法人签字，违反合规规则CONTRACT_001', 'rule_id': 'CONTRACT_001'}

===== 2. 大模型柔性处理 =====
**大模型建议：**合同违规原因：此合同金额为100万以上，但缺少法定代表人或授权代理人的签字，这违反了公司内部的合规规 定。

**整改建议：**尽快安排法定代表人或有权机构进行签字确认，确保合同的有效性和合规性。

===== 3. 最终审核结果 =====

{'rule_check': {'pass': False, 'violation_reason': '合同金额超100万但无法人签字，违反合规规则CONTRACT_001', 'rule_id': 'CONTRACT_001'}, 'llm_suggestion': '合同违规原因：此合同金额为100万以上，但缺少法定代表人或授权代理人的签字，这违反了公司内部的合规规定。\n\n整改建议：尽快安排法定代表人或有权机构进行签字确认，确保合同的有效性和合规性。', 'final_conclusion': '审核不通过'}

---

===== 1. Drools规则引擎校验 =====

Drools接口未部署，使用本地模拟：422 Client Error: Unprocessable Entity for url: http://localhost:8000/drools/contract/check
规则结果：{'pass': True, 'violation_reason': '', 'rule_id': ''}

===== 2. 大模型柔性处理 =====
**大模型建议：**以下是优化后的合同文本：

**合同文本优化版**：

甲方C与乙方D签订了一份服务合同，合同总金额为人民币伍拾万元整（¥500,000）。根据合同约定，甲方应在服务完成后的十（10）个工作日内向乙方支付相应的服务费用。同时，乙方承诺提供六（6）个月的售后服务保障。

值得注意的是，本合同中并未明确列出违约责任的条款。为了应对可能出现的争议，双方同意通过友好协商的方式予以解决。尽管此点已在原文中提及，但在此重申以确保双方对此有充分的理解。

此外，建议在合同中增加一条关于违约责任的具体条款，以进一步明确双方在违反合同时应承担的法律责任，从而降低潜在的合规风险。

**潜在非合规风险提示**：

1. **违约责任不明确**：由于原合同中没有明确的违约责任条款，一旦发生争议，双方可能难以迅速定位责任方并采取相应 措施，这可能导致纠纷升级或影响合同的正常履行。

2. **售后服务期限的表述**：虽然合同中提到了乙方应提供六个月的售后保障，但未明确售后服务的内容、范围及具体质量 标准等关键信息。这可能导致在实际履行过程中出现误解或纠纷。

综上所述，建议在后续修改合同时，针对上述风险点进行补充和完善，以确保合同的合法性和有效性。

===== 3. 最终审核结果 =====

{'rule_check': {'pass': True, 'violation_reason': '', 'rule_id': ''}, 'llm_suggestion': '以下是优化后的合同文 本：\n\n**合同文本优化版**：\n\n甲方C与乙方D签订了一份服务合同，合同总金额为人民币伍拾万元整（¥500,000）。根据合同约定，甲方应在服务完成后的十（10）个工作日内向乙方支付相应的服务费用。同时，乙方承诺提供六（6）个月的售后 服务保障。\n\n值得注意的是，本合同中并未明确列出违约责任的条款。为了应对可能出现的争议，双方同意通过友好协商的方式予以解决。尽管此点已在原文中提及，但在此重申以确保双方对此有充分的理解。\n\n此外，建议在合同中增加一条关于违约责任的具体条款，以进一步明确双方在违反合同时应承担的法律责任，从而降低潜在的合规风险。\n\n**潜在非合规风险提示**：\n\n1. **违约责任不明确**：由于原合同中没有明确的违约责任条款，一旦发生争议，双方可能难以迅速定位责任 方并采取相应措施，这可能导致纠纷升级或影响合同的正常履行。\n\n2. **售后服务期限的表述**：虽然合同中提到了乙方 应提供六个月的售后保障，但未明确售后服务的内容、范围及具体质量标准等关键信息。这可能导致在实际履行过程中出现误解或纠纷。\n\n综上所述，建议在后续修改合同时，针对上述风险点进行补充和完善，以确保合同的合法性和有效性。', 'final_conclusion': '审核通过，建议参考优化意见'}

结果说明：

• 在第一组场景中：
  • 合同因金额超 100 万且无法人签字，被 Drools 规则引擎直接判定为不通过。这一步体现了规则引擎不可动摇的底线能力：
  • 只要触碰红线，立刻精准拦截、结果明确、可解释、无歧义，从根源上杜绝合规风险。
  • 而大模型则在规则结论基础上，把生硬的违规信息转化为通俗易懂的原因说明与整改建议，让业务人员一看就懂、知道怎么改，实现了 "刚性判定 + 柔性解释"。
• 在第二组场景中：
  • 规则引擎判定合同合规通过，证明业务底线没有问题。
  • 此时大模型开始发挥核心价值：自动优化合同措辞、补齐权责表述、指出违约责任不明确、售后条款模糊等潜在风险点，并给出可落地的优化建议。
  • 这些内容没有写在任何一条 IF-THEN 规则里，却是传统规则引擎完全做不到的。
• 这一正一反两个案例说明：
  • 规则引擎管底线，大模型管体验，不是一句口号，而是真正可落地、可复用的企业智能决策架构。
  • 规则引擎保证不出错、不违规；大模型提升效率、优化体验、补齐长尾能力。
  • 两者结合，既守住企业风控底线，又让业务处理更智能、更人性化，最务实、最具价值的应用方向。

六、总结

在大模型出现前，会觉得规则引擎够用就好，靠着明确的 IF-THEN 规则守住底线，就能满足企业合规需求。但接触大模型后，发现纯规则引擎的短板太明显，读不懂非结构化文本、处理不了模糊场景，输出的结果冷冰冰，根本跟不上现在的业务节奏。而大模型的出现，刚好补上了这个缺口，不用死卡规则，能读懂、能推理、能给出人性化建议，把生硬判定变成柔性服务，这才是现在企业真正需要的。规则引擎管死底线，杜绝合规风险，这是根基；大模型优化体验、补齐长尾场景，这是提升，两者结合的双引擎架构，才是企业数字化转型中最实用的方案。

我们了解过程中不要只单独学规则引擎或者大模型，要结合起来学，先吃透 Drools 的核心组件，理解规则匹配的逻辑；再结合大模型的柔性处理能力，重点琢磨两者协同的落地细节。不用追求复杂，先把"规则兜底、大模型补位"的核心逻辑搞懂，再结合实际业务优化，这样下来，会有个递进熟悉的过程，了解的也会比较透彻。