AI客服不自由发挥：硬规则引擎+LLM结构化约束实战方案

这次我们来看一个实战问题：AI 客服上线后“自由发挥”怎么办？业务部门要求所有话术必须按规章来，但大模型一开口就经常跑偏，甚至承诺“可以无理由退款 100%”。问题不在模型本身，而在你把客服的“规则”全部塞进了提示词，让它自己判断。AI Agent 实战里最核心的一条原则是：能确定的东西不要让模型做决定，先把规则抽出来。

这篇文章会围绕“让 AI 严格按业务规则做事”这个场景，拆解一套可落地的技术方案。重点聊三件事：为什么提示词工程压不住客服幻觉；RAG、微调、规则引擎分别解决什么问题；以及怎么用“硬规则优先 + LLM 理解 + 结构化输出 + 人工兜底”的模式，把 AI 客服的行为锁死。最后附上完整的 Python 代码示例、接口调用方法和排查清单。

1. 核心能力速览

先给一张速览表，方便判断这套方案适不适合你的场景。

2. 适用场景与使用边界

2.1 这个方案解决什么问题

AI 客服最常见的失败案例是“一本正经地胡说八道”。客服话术一旦涉及价格、时效、赔偿、售后政策，就不允许出现概率性回答。业务方的要求通常非常明确：

• 未发货订单申请退款，必须全额原路退回。
• 已发货订单要申请退货，需在签收后 7 天内提出。
• 生鲜、定制类商品不支持 7 天无理由退货。
• 超过 30 天未申请售后的订单，客服只能引导用户走人工审核。

这些规则是确定性的，理论上不需要 LLM 来判断。如果你把规则文字写进 system prompt 里，让模型自己“理解后执行”，遇到复杂上下文就很容易出错。模型对规则的理解是概率性的，它不会去查“这个订单什么时候签收的”“这件商品属不属于生鲜”，它只会根据文字的相似度去生成回答。

所以这套方案的第一个目标，是把确定性规则从模型手里剥离出来，交给代码去执行。

2.2 不适合什么场景

这套“强规则约束”方案并不适合所有客服场景。

如果业务本身就是开放式的，例如售前产品咨询、闲聊陪伴、创意建议，强行套规则引擎反而会让对话显得死板。规则引擎擅长的是“判断题”和“计算题”，不擅长“开放题”。另一个极端是：如果业务方希望完全由大模型自由发挥，那这篇文章的思路完全不适用。

另外，如果业务规则本身还在频繁变动，例如运营每周调整优惠策略，这需要把规则配置化，否则每次都要改代码。

2.3 合规与安全边界

这里必须强调合规问题。AI 客服涉及用户订单、手机号、地址、聊天记录等敏感数据，在生产环境部署时要确保：

• 优先使用私有化部署或企业级 API，避免敏感数据外泄。
• 对话日志脱敏后再入库。
• 涉及退款、赔偿等操作，AI 客服只能给出答复，不能直接执行资金操作，除非有完整的审批链路。
• 话术必须经过业务方审核，AI 不能生成“额外承诺”或“合同变更”类表述。
• 人工客服兜底是必须的，AI 没有权限处理的东西要明确转接。

3. 三层技术路线对比：提示词、RAG 与模型微调

热搜词里有个很典型的问题：“AI 人工智能客服是属于提示词工程、RAG 检索、模型微调这三个层级里的哪一个？”严格来说，一个成熟可用的 AI 客服往往是三层同时存在的，只看你解决什么问题。

3.1 提示词工程层

提示词工程管的是“模型以什么身份、按什么逻辑说话”。它能约束语气、角色、回答格式，但对硬性业务规则的约束力很弱。

原因是：提示词只是文字，模型对文字的理解存在偏差。同一个规则“7 天无理由退货”在不同上下文里，模型可能执行成 7 天、8 天、或者“具体以签收时间为准”。另外，模型输入长度有限，你不可能把几千条业务规则全部塞进提示词。

提示词工程适合做的是：定义客服人格、规定回答风格、要求输出 JSON 结构化结果、设定拒绝回答的兜底话术。

3.2 RAG 检索增强层

RAG 解决的是“模型不知道你的业务知识”的问题。你可以把完整的售后规则文档、商品说明、常见问题导入向量数据库，用户提问时先检索相关内容，再把检索结果拼进 prompt 让模型回答。

RAG 比单纯提示词强的地方在于：它能覆盖大规模知识库，且更新知识只需要换文档，不需要重新部署模型。

但 RAG 也有两个明显限制：

• 检索质量不稳定，召回不到正确文档时，模型还是会答错。
• 对“条件判断”类规则支持不好。例如“用户申请退款，订单是否发货？是否超过退款时限？商品是否在退货范围内？”RAG 可以搜到规则文本，但它不负责执行逻辑判断，模型可能只看到第一条相关规则就生成答案。

3.3 模型微调层

用户问 AI 客服是不是需要做模型微调，这要分场景看：

• 如果目标是让模型学会“模仿你的回答风格”，微调有作用。
• 如果目标是让模型学会“严格遵守业务规则”，微调的作用很有限。

原因是微调改变的是模型权重和输出风格，它并不能真正“记住”几百条具体规则。模型在微调后依然可能有幻觉和遗忘问题，而且微调成本高、迭代周期长，业务规则一变就得重新训练，不适合高频变动的场景。

真正需要微调的场景是：模型对某一类任务的基础能力不够。例如你希望客服模型在识别用户情绪时更准确，或者希望它始终用简称称呼你的产品，这些适合微调。硬规则约束，请交给代码。

3.4 我的结论

AI 客服要让业务规则“不可违背”，正确路线是：

硬规则引擎 -------> 前置判断和拦截 RAG/知识检索 -----> 给模型提供业务知识依据 提示词工程 -------> 管模型的语言风格和输出格式 模型微调 ---------> 可选，用于提升特定任务的能力

这四层不是替代关系，是配合关系。下面我们来写代码。

4. 环境准备与前置条件

本项目用的技术栈比较简单，属于“轻量可直接跑”的模板。建议在 Linux 或 macOS 下开发，Windows 的 WSL 也可以。

4.1 环境清单

4.2 安装命令

# 创建虚拟环境 python3 -m venv venv source venv/bin/activate # 安装依赖 pip install fastapi uvicorn openai pydantic pytest

如果使用本地模型，例如通过 Ollama 或 vLLM 提供的 OpenAI 兼容接口，只需要把代码中的base_url改成本地地址即可。

4.3 目录结构规划

ai_agent_customer_service/ ├── main.py # FastAPI 入口 ├── config.py # 全局配置 ├── rules/ │ ├── __init__.py │ ├── policy.py # 硬规则引擎 │ └── policy_data.py # 规则数据 ├── llm/ │ ├── __init__.py │ ├── client.py # LLM 调用封装 │ └── prompts.py # 提示词模板 ├── agent/ │ ├── __init__.py │ └── pipeline.py # 智能体编排主流程 ├── tests/ │ └── test_policy.py # 规则引擎测试 └── requirements.txt

5. 硬规则引擎：把确定性判断从模型剥离

这是整个方案的核心。我们要把“客服不能自由发挥”的诉求，从一句口号变成代码逻辑。

5.1 规则数据结构

用一个电商售后客服来做例子。定义业务规则如下：

# rules/policy_data.py from dataclasses import dataclass, field @dataclass class ReturnPolicy: refund_days: int = 7 no_return_categories: list = field(default_factory=lambda: ["生鲜", "虚拟商品", "定制商品"]) max_refund_days: int = 30 quality_issue_support: bool = True

规则不要写死在提示词里，建议放在独立的 Python 模块或 JSON 配置中，运营可以直接改。

5.2 规则判断引擎

# rules/policy.py from datetime import datetime, timedelta class PolicyEngine: def __init__(self, policy): self.policy = policy def check_refund_eligibility(self, category: str, order_status: str, signed_at: str | None) -> dict: """检查退货退款资格。""" # 先判断类目是否支持退货 if category in self.policy.no_return_categories: return { "eligible": False, "reason": f"该商品属于{category}类目，不支持无理由退货。", "next_action": "human" } # 未发货订单，直接全额退款 if order_status == "pending": return { "eligible": True, "reason": "订单未发货，可以全额退款。", "refund_type": "full", "next_action": "fulfill" } # 已签收订单，判断是否在退货时限内 if order_status == "signed": if signed_at is None: return { "eligible": None, "reason": "缺少签收时间信息，无法自动判断，转人工处理。", "next_action": "human" } signed_dt = datetime.fromisoformat(signed_at) now = datetime.now() days_since_signed = (now - signed_dt).days if days_since_signed > self.policy.max_refund_days: return { "eligible": False, "reason": f"订单签收已超过 {self.policy.max_refund_days} 天，无法在线申请售后。", "next_action": "human" } if days_since_signed <= self.policy.refund_days: return { "eligible": True, "reason": "在无理由退货时限内，可以申请退货退款。", "refund_type": "refund", "next_action": "guide_return" } return { "eligible": False, "reason": "已超过7天无理由退货时限，请走人工审核流程。", "next_action": "human" } # 其他状态：未知 return { "eligible": None, "reason": "无法判断订单状态，转人工处理。", "next_action": "human" }

这段代码的价值在于：它把“能不能退款”“该怎么答复”变成了确定性逻辑，模型没有机会乱猜。所有可能让模型自由发挥的关键判断点，都优先走这里。

5.3 单元测试：先锁规则再写业务

规则引擎必须用测试用例锁住，否则后续改代码容易改出 bug：

# tests/test_policy.py from datetime import datetime, timedelta from rules.policy import PolicyEngine from rules.policy_data import ReturnPolicy def test_pending_order_full_refund(): engine = PolicyEngine(ReturnPolicy()) result = engine.check_refund_eligibility("数码", "pending", None) assert result["eligible"] is True assert result["refund_type"] == "full" def test_no_return_category(): engine = PolicyEngine(ReturnPolicy()) result = engine.check_refund_eligibility("生鲜", "pending", None) assert result["eligible"] is False def test_expired_return_window(): engine = PolicyEngine(ReturnPolicy()) signed_at = (datetime.now() - timedelta(days=45)).isoformat() result = engine.check_refund_eligibility("数码", "signed", signed_at) assert result["eligible"] is False assert result["next_action"] == "human"

写测试的必要性这里不展开，但请记住：AI 客服上线前如果规则测试不过，等于是在给用户送钱。

6. LLM 模块：只负责理解和表达，不负责决策

规则引擎处理完确定性判断后，我们把“用户说的话”转成结构化信息，再喂给 LLM 生成最终话术。

6.1 信息抽取：让 LLM 从对话里提取结构化字段

用户说一句“我要退货，我买的麦克风前天签收了”，我们需要提取：

• 用户意图：退货
• 商品类目：数码（或具体商品名）
• 订单状态：signed
• 签收时间：前天

这种信息抽取可以用 prompt 让 LLM 完成，输出 JSON：

# llm/prompts.py SYSTEM_PROMPT = """你是电商客服的信息抽取助手。 请从用户消息中提取以下字段，并输出JSON： { "intent": "退货|退款|查询物流|人工客服|闲聊", "category": "商品类目，如数码、生鲜、服饰、未知", "order_status": "pending|signed|unknown", "signed_at": "用户提到的签收时间，格式ISO8601，如果没提到则为null" } 如果没有足够信息，字段值用"unknown"或null表示。只输出JSON，不要输出其他文字。"""

LLM 抽取字段即使偶尔抽错，规则引擎也能兜底。例如抽取结果为order_status=unknown，规则引擎会返回“无法判断，转人工”。这就形成了第一层保护。

6.2 话术生成：规则引擎给定“边界”，LLM 只说边界内的话

拿到规则引擎的判断结果后，我们要求 LLM 在这个边界内生成回复：

# llm/prompts.py GENERATE_REPLY_PROMPT = """你是电商售后客服。 系统已经判断出本次售后结果，请你用礼貌、简洁的口吻，基于结果生成回复。 禁止添加任何系统没有给出的承诺、金额、时限。 判断结果： {policy_result} 用户原话： {user_message} 请生成不超过100字的客服回复。"""

这里的关键是：模型的职责是“把结果说得好听”，不是“决定结果”。决策是规则引擎做的，模型只是翻译。这种设计对模型的服从性要求极低，甚至用一个小模型就能完成。

7. Agent 主流程编排

7.1 主流程实现

# agent/pipeline.py import json from rules.policy import PolicyEngine from llm.client import LLMClient from llm.prompts import SYSTEM_PROMPT, GENERATE_REPLY_PROMPT class CustomerServiceAgent: def __init__(self, policy_engine: PolicyEngine, llm_client: LLMClient): self.policy = policy_engine self.llm = llm_client def handle_message(self, user_message: str) -> dict: # 1. LLM 抽取结构化信息 extracted = self.llm.extract(user_message) # 2. 规则引擎判断 decision = self.policy.check_refund_eligibility( category=extracted.get("category"), order_status=extracted.get("order_status"), signed_at=extracted.get("signed_at") ) # 3. 转人工场景 if decision.get("next_action") == "human": return { "reply": "这个问题我需要为您转接人工客服，请稍等。", "decision": decision, "extracted": extracted } # 4. 生成最终话术 reply = self.llm.generate_reply(decision, user_message) return { "reply": reply, "decision": decision, "extracted": extracted }

这个编排方式叫“Rule-based routing”：规则引擎前置，LLM 后置。用户和 AI 客服的对话严格走这条链路，模型没有任何机会在规则之外发表意见。

7.2 为什么不用 LangGraph 也能做

很多 Agent 开发教程喜欢直接上 LangGraph 或 CrewAI，但在这个场景里，编排逻辑非常简单线性：

用户消息 -> 信息抽取 -> 规则判断 -> 转人工/生成回复

用 LangGraph 可以做，但没必要。真正的工程重点在规则设计和 prompt 边界控制，先把这个做好，再考虑框架。

如果你已经有 Agent 框架，完全可以把这个流程封装成框架里的一个 Worker 或 Tool，编排思路是一样的。

8. 接口 API 与批量任务

8.1 FastAPI 接入

实际生产中，客服系统需要一个 HTTP 接口：

# main.py from fastapi import FastAPI from pydantic import BaseModel from agent.pipeline import CustomerServiceAgent from rules.policy import PolicyEngine from rules.policy_data import ReturnPolicy from llm.client import LLMClient app = FastAPI() agent = CustomerServiceAgent( policy_engine=PolicyEngine(ReturnPolicy()), llm_client=LLMClient() ) class MessageRequest(BaseModel): user_message: str session_id: str = "default" class MessageResponse(BaseModel): reply: str decision: dict extracted: dict @app.post("/api/chat", response_model=MessageResponse) async def chat(req: MessageRequest): result = agent.handle_message(req.user_message) return MessageResponse( reply=result["reply"], decision=result["decision"], extracted=result["extracted"] ) if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

启动服务：

python main.py

验证接口：

curl -X POST http://127.0.0.1:8000/api/chat \ -H "Content-Type: application/json" \ -d '{"user_message": "我买的生鲜想要退货", "session_id": "001"}'

预期返回结果：decision.eligible == False，消息提醒“生鲜不支持无理由退货”。这样规则永远先于模型生效。

8.2 批量任务

有些客服场景不是实时对话，而是离线工单处理。例如客服每天要处理 5000 条留言，我们可以走批量脚本：

# batch_process.py import json import csv from pathlib import Path def batch_process(input_path: str, output_path: str): with open(input_path, "r", encoding="utf-8") as f: rows = list(csv.DictReader(f)) results = [] for row in rows: try: result = agent.handle_message(row["message"]) results.append({ "id": row["id"], "reply": result["reply"], "next_action": result["decision"].get("next_action"), "eligible": result["decision"].get("eligible") }) except Exception as e: results.append({ "id": row["id"], "reply": f"处理失败: {e}", "next_action": "error" }) with open(output_path, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) if __name__ == "__main__": batch_process("data/input.csv", "data/output.json")

批量处理要注意三点：

• 必须加超时和重试，单条 LLM 调用异常不能拖垮整个批次。
• 每条记录要保存状态，处理完一批不要重复处理。
• 批量结果需要人工抽检，特别是next_action == human的条目。

8.3 失败重试建议

给一个通用重试模板：

import time from functools import wraps def retry(max_retries=3, delay=2.0): def decorator(func): @wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: if attempt == max_retries - 1: raise time.sleep(delay * (attempt + 1)) return None return wrapper return decorator

对超时、限流类异常使用指数退避重试；对参数错误类异常不要重试，直接记录日志并转人工。

9. 资源占用与性能观察

纯 API 方案下，本机资源占用非常低，主要消耗在 FastAPI 服务和规则引擎上，内存几百 MB 以内，显存占用为 0。

如果你把 LLM 换成本地模型，比如使用 Ollama 加载一个 7B 或 14B 的对话模型，显存占用会取决于模型量化版本和上下文长度。这时候需要重点观察：

• 模型加载后的基础显存占用。
• 并发请求到达后，显存是否会持续增长。
• 信息抽取任务的 prompt 长度对延迟的影响。
• 是否需要把信息抽取和话术生成分成两个独立模型实例。

我的建议是：信息抽取模型可以稍微弱一点，话术生成模型可以稍强一点。如果算力有限，两个任务共用一个模型也没问题，只要规则引擎的逻辑正确。

性能观察时，用 FastAPI 自带的日志或接入 Prometheus 都可以。关键指标是：

• P95 响应时间。
• 单请求 LLM 耗时占比。
• 规则引擎耗时（通常可忽略不计）。
• 转人工率。

如果 P95 响应时间过高，优先看是不是信息抽取 prompt 太长，或者模型并发度不够。

10. 常见问题与排查方法

11. 最佳实践与使用建议

这一节汇总工程落地时的关键实践。

11.1 先建规则清单再写代码

不要边写代码边定规则。上线前和业务方开一次会，把“能自动处理”和“必须转人工”的边界全部理清楚。至少覆盖：

• 可自动处理的条件。
• 必须转人工的条件。
• 无法判断时默认怎么处理。
• 客服话术的统一口径。

11.2 所有决策留痕

每次对话响应都记录：

• user_message脱敏文本。
• extracted抽取结果。
• decision规则判断结果。
• reply最终回复。
• model_name和prompt_version。

这样事后出现客诉时，可以快速定位是规则漏了还是模型输出有问题。

11.3 线上灰度

用分阶段上线策略：

• 第一阶段：AI 只做辅助回答，所有回复都有人工审核。
• 第二阶段：AI 可自动回复，但退款类操作必须人工确认。
• 第三阶段：规则覆盖率足够高后，再开放完全自动回复。

11.4 定期回去看转人工日志

转人工率是判断规则完备度的重要指标。每周看一次next_action=human的日志，把高频出现的 case 逐步补充进规则引擎，就能把 AI 客服的自主空间一点点压缩到合理范围。

11.5 涉及敏感操作必须加守护

如果客服系统要对接退款回调、工单创建等操作，AI 生成的指令必须经过第二层校验，不能直接执行。例如规则引擎判断“可以退款”，仍要调用独立的订单服务校验订单号、金额和用户权限，防止 prompt 注入或参数异常。

12. 总结与下一步

AI 客服之所以“自由发挥”，根源不是某个模型不行，而是你在让它做不擅长的事：用概率决策去执行确定性规则。解决思路是让规则引擎做决策，让 LLM 做表达。用硬规则引擎前置拦截所有确定性判断，再用 LLM 抽取信息和生成话术，把模型的发挥空间锁死在业务边界内。这个方案不依赖昂贵硬件，不需要微调大模型，改动现有客服系统的成本也低。

如果这篇文章对你有用，建议收藏备用。下一步你可以做的事情是：把手头的业务规则按“判断项”和“执行项”拆出来，先做一个最小规则引擎，再接入一个便宜的对话模型试试效果。等跑通之后，再考虑要不要引入 RAG 扩充知识库，或者在特定能力上做模型微调。