一、前言

       现在企业数字化转型越走越深，智能决策系统说白了，就是要既守住合规风控的底线，又能做好用户体验，这两者平衡好了，业务才能稳。很多传统企业早就用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核心组件

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

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
import dashscope
from dotenv import load_dotenv

# 加载环境变量
load_dotenv()

# --------------------------
# 1. 配置项
# --------------------------
# 模拟Drools REST API地址（实际替换为真实Drools服务地址）
DROOLS_API_URL = "http://localhost:8000/drools/contract/check"
# 通义千问大模型配置
DASHSCOPE_API_KEY = os.getenv("DASHSCOPE_API_KEY", "")
dashscope.api_key = DASHSCOPE_API_KEY

# --------------------------
# 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:
        response = dashscope.Generation.call(
            model='qwen-turbo',
            messages=[
                {"role": "system", "content": "你是专业的合同审核顾问，擅长合规解释和文本优化。"},
                {"role": "user", "content": prompt}
            ],
            result_format='message',
            temperature=0.3  # 降低随机性，保证结果稳定
        )
        return response.output.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 的核心组件，理解规则匹配的逻辑；再结合大模型的柔性处理能力，重点琢磨两者协同的落地细节。不用追求复杂，先把“规则兜底、大模型补位”的核心逻辑搞懂，再结合实际业务优化，这样下来，会有个递进熟悉的过程，了解的也会比较透彻。