先问一个很现实的问题你负责的AI客服有没有出现过这种情况用户问“你们能不能便宜点”AI客服非常贴心地说“可以的我给您申请一张8折优惠券。”问题是公司根本没有这个促销活动业务方也没有授权AI客服发放任何优惠券。再比如用户问“你们公司注册地址是什么”AI客服把从某个帖子里学来的信息直接背了出来结果和工商备案信息对不上。用户截图投诉业务方一看聊天记录立刻把工单甩给你这锅AI背还是你背如果你已经做了AI客服大概率遇到过这类问题。如果你正准备做那这个问题迟早会遇到。这类问题的本质不是大模型“不聪明”而是大模型的能力边界和业务规则的约束边界没有对齐。大模型天生是概率生成器它擅长的是“像人一样说话”而不是“像系统一样遵守规则”。你越是让它自由发挥它越容易在规则边缘试探。本文要解决的核心问题就是AI客服如何在不丧失对话自然度的前提下严格按业务规则做事我不会只停留在“写个Prompt让AI老实一点”这种表面方案因为单靠Prompt约束解决不了“AI告诉用户可以免单”这类问题。真正可靠的方案是把业务规则从“提示词里的建议”变成“系统层面的硬约束”。这是AI Agent工程化的一个典型场景适合正在做智能客服、对话机器人、Agent类应用的后端工程师和AI应用开发者阅读。1. 先搞清楚AI客服“乱说话”到底乱在哪1.1 业务方真正害怕的不是AI不聪明而是AI太灵活传统客服系统有一套固定的工单流程和话术模板异常情况有兜底策略客服人员没有权限靠“自由意志”给用户承诺。但AI客服不同大模型会基于它的训练数据和上下文生成一个“听起来很合理”的答案。问题就出在这个“听起来很合理”上。比如下面这些场景你大概率在测试AI客服时遇到过场景AI客服可能的回答为什么是问题用户询问价格优惠“我帮您申请一张内部优惠券”AI没有发券权限且该活动不存在用户投诉并要求赔偿“很抱歉我们赔偿您100元”赔付有额度、有审核流程AI不能自作主张用户问经营范围AI根据网上旧数据回答工商信息发生变化AI知识过期用户询问是否支持货到付款AI回答“支持”部分地区、部分商品不支持规则有分支用户要求转人工AI坚持继续兜售业务要求特定条件下必须转人工AI未触发用户提到敏感词AI继续往下聊安全合规要求立即停止或转交这些问题的共同特点是AI不是“不懂业务”而是“不知道自己的权限边界”。它把对话理解成一道开放题而业务方需要的是“有标准答案的选择题”。1.2 三个层级提示词工程、RAG检索、模型微调到底谁管用这个话题在近期讨论很多。很多初学者会问AI客服要按业务规则做事是不是得走“提示词工程、RAG检索、模型微调”这三个层级里的某一个这里需要先做一个技术判断这三个层级不是互斥的而是解决不同维度的问题。提示词工程负责定义AI的行为边界和输出格式。它解决的是“AI应该怎么说话”的问题属于软约束。RAG检索负责给AI提供实时、准确的业务知识。它解决的是“AI拿什么知识来回答”的问题属于知识供给。模型微调负责改变AI的风格、语气、领域能力。它解决的是“AI擅长什么风格”的问题属于能力调整。那么对于“严格按业务规则做事”这个诉求核心抓手是什么从实际工程经验看提示词工程是基础RAG是知识保障微调不是首选方案。但更重要的是这三者加在一起依然无法保证AI不越权。因为大模型本质上是“概率生成”你再怎么调Prompt它也可能在某个时刻生成一个超规的回答。真正的硬约束来自系统层的规则校验和工具调用约束。这也是本文要讲的AI Agent实战方案的核心思路把业务规则做成一套独立于大模型之外的“规则守护层”。2. 核心概念与架构设计为什么“规则守护层”是答案2.1 业务规则引擎让规则回到系统里在很多规模型企业中业务规则并不是靠几句Prompt就能覆盖的。比如“退款金额超过500元必须人工审核”“发货地址不支持港澳台”“商品类目不同售后政策不同”这些规则分散在不同的业务系统中有明确的判断逻辑和优先级。AI客服要严格按规则做事第一步不是让AI“学会”这些规则而是让AI“绕不开”这些规则。这就需要在AI客服的架构里加入一个业务规则引擎。规则引擎的核心职责是预检在AI生成回复之前检查用户的意图和参数是否满足规则前置条件。后验在AI生成回复之后对回复内容进行规则校验发现越权内容直接拦截或改写。执行对于涉及操作类的请求比如发券、退款、改地址AI不直接执行而是调用规则引擎封装好的工具接口由工具接口负责校验和执行。这个设计背后的原因很朴素大模型适合做“语义理解”和“内容生成”但不适合做“精确判断”和“强制执行”。你让一个概率模型去保证“百分百不越权”本身就是错配。2.2 让AI通过工具“感知”规则而不是“记忆”规则很多刚接触AI Agent的开发者最容易犯的错误是把规则直接写进系统提示词里然后指望AI严格遵守。比如在系统提示词里写“你是客服你不能承诺任何优惠不能编造活动信息不能回答超出范围的问题。”看似很严格但实际效果有限。原因在于提示词对AI来说是“建议”而不是“约束”。AI是一个语言模型它的所有输出都是“接下来最可能出现的词”。当你要求它“不能承诺优惠”时它确实会倾向于不承诺但是否会百分百遵守取决于上下文、用户话术的诱导强度和模型本身的倾向性。更可靠的方案是让AI不直接回答规则类问题而是通过调用工具来感知规则。举个例子用户问“你们可以包邮吗”此时AI不应该直接生成“可以”或“不可以”而是应该先检查自己的工具列表里有没有一个check_shipping_policy工具。如果有AI会调用这个工具工具返回“该用户地址支持包邮但订单金额需满99元”然后AI基于这个工具返回值再组织语言回答用户。这时的回答不是AI自己编的而是基于工具结果生成的。工具结果就是规则运行的输出AI只是把规则结果转述成自然语言。这种方式正是AI Agent与普通聊天机器人的核心区别Agent具备调用外部工具、获取结构化数据、执行动作的能力而规则就藏在工具的校验逻辑里。2.3 三层架构入口层、决策层、执行层把一个可落地的AI客服Agent拆开来看建议采用三层架构用户输入 ↓ 入口层意图识别 内容安全 敏感词过滤 ↓ 决策层大模型 工具选择 规则引擎预检 ↓ 执行层工具调用 规则校验 兜底策略 ↓ 最终回复每一层的职责要清晰分离入口层负责把不合适的输入挡在门外。比如敏感词、违法违规内容、无效输入在这个阶段直接拦截不给大模型生成的机会。决策层负责“理解用户想干什么”和“决定应该调用什么工具”。大模型在这里做意图识别、槽位抽取和工具选择。执行层负责“真正做事”。所有涉及业务数据的操作都这里完成并接受规则引擎的校验。这个架构最大的价值在于大模型可以自由发挥的部分仅限于“语言组织”涉及规则和执行的部分全部由系统控制。这样既能保证对话自然度又能保证业务规则不被绕过。3. 环境准备与技术选型3.1 核心依赖本文的示例以Python为主采用目前AI Agent开发中最常见的组合。版本信息请以你实际项目为准本文重点演示通用思路。Python 3.10OpenAI SDK 或兼容OpenAI接口的大模型服务FastAPI用于提供API服务一个轻量级规则引擎或者直接用Python字典/JSON定义规则一个向量数据库可选用于RAG知识检索这里提醒一点不同大模型对工具调用的支持程度不同。例如OpenAI的Function Calling、Anthropic的Tool Use以及国内一些大模型平台提供的工具调用能力在接口形式上可能略有差异但核心逻辑一致模型输出一个结构化的工具调用请求应用层根据请求执行对应的函数再把结果返回给模型。3.2 项目目录建议ai-agent-customer-service/ ├── app.py # FastAPI 主程序 ├── agent/ │ ├── agent.py # Agent 核心逻辑 │ ├── tools.py # 工具定义与执行 │ └── prompts.py # 系统提示词 ├── rules/ │ ├── engine.py # 规则引擎 │ └── policies.py # 业务规则定义 ├── config/ │ └── settings.py # 环境配置 └── tests/ └── test_rules.py # 规则测试建议从一开始就把“工具”和“规则”分开管理。工具是能力规则是限制两者混在一起会让后期维护变得很痛苦。4. 核心流程拆解从用户输入到最终回复4.1 第一步入口检查与预处理用户消息到达系统后先不要急着发给大模型。先做三类检查内容安全检查消息中是否包含敏感词、违法违规内容。会话状态检查当前会话是否处于人工接管状态、是否超时、是否需要验证身份。基础信息抽取用户ID、订单号、商品ID等关键参数是否齐全。这一步的价值在于把明显不该由AI回答的问题提前拦截掉减少大模型的自由度。4.2 第二步Agent决策循环Agent启动后将用户消息和系统提示词发送给大模型。大模型的输出有两种可能直接生成自然语言回复。输出一个工具调用请求要求执行某个函数。实际开发中Agent通常需要多轮调用。比如用户问“我的订单为什么还没发货”AI可能需要先调用get_order_info获取订单状态再调用check_delivery_policy检查物流政策最后综合两个工具的结果生成回复。4.3 第三步规则引擎校验这是本文的核心环节值得仔细看。当AI准备输出最终回复时无论它是直接生成的还是基于工具结果生成的都要经过规则引擎的校验。规则引擎的校验规则按照“越权风险”从高到低分成几个级别L1禁止级AI不得承诺赔偿、优惠、赠品、价格修改。L2条件级AI可以告知政策但必须附带条件比如“满99元包邮”。L3转交级涉及投诉、退款、人工服务时必须引导转人工。L4知识级涉及政策、经营范围等信息必须基于RAG检索结果或工具结果回答不得自行生成。在校验时如果AI回复中出现了L1级别的关键词组合比如“赔偿”“优惠券”“免单”“打折”规则引擎直接拦截并触发预设的替代回复模板。4.4 第四步兜底策略还有一类情况需要注意AI不知道答案但又不肯承认会生成一个模棱两可的回答。这类回答最难通过规则拦截因为每个词都合规组合在一起却是在误导用户。应对方案是引入“置信度判定”或“知识覆盖判定”如果AI的回答不是基于工具结果生成的且问题属于规则明确要求的“必答知识域”则判定为未命中知识触发兜底。兜底话术建议统一为“这个问题我这边需要确认一下已经为您转接人工客服请稍等。”兜底策略不需要多复杂关键是要让AI“有勇气承认不知道”。这个问题看似简单但在实际项目中很多AI客服出问题恰恰是因为AI“不懂装懂”。5. 完整示例与代码实现下面进入实操环节。我们用一个最小可运行的AI客服Agent示例演示“规则守护层”的完整实现。这个示例不用复杂的框架核心逻辑用Python就能讲清楚。5.1 规则引擎实现先看最小化的规则引擎。# 文件路径rules/engine.py from typing import Dict, List, Tuple # 禁止词与规则映射 # 实际项目中建议使用正则表达式或规则引擎这里用关键词演示思路 FORBIDDEN_PATTERNS { promise_discount: [优惠券, 折扣, 打折, 免单, 减免], promise_refund: [赔偿, 退款, 赔付], forbidden_action: [改价, 删除订单, 修改地址], } # 条件规则AI可以提政策但需要附带条件说明 CONDITIONAL_RULES { free_shipping: { keywords: [包邮, 免运费], required_condition: 满99元包邮, default_response: 目前全场满99元即可包邮您的订单还未达到包邮门槛。 } } # 转人工规则 TRANSFER_KEYWORDS [投诉, 人工客服, 转人工, 维权, 举报] class RuleEngine: def __init__(self): self.forbidden_patterns FORBIDDEN_PATTERNS self.conditional_rules CONDITIONAL_RULES self.transfer_keywords TRANSFER_KEYWORDS def check(self, ai_response: str, intent: str) - Tuple[bool, str, str]: 校验AI生成的内容是否合规。 返回: (是否通过, 处理方式, 替代回复) # 1. 检查是否触发转人工规则 for kw in self.transfer_keywords: if kw in ai_response or kw in intent: return False, transfer, 您的问题需要专员处理正在为您转接人工客服... # 2. 检查是否触发禁止规则 for rule_name, keywords in self.forbidden_patterns.items(): for kw in keywords: if kw in ai_response: # 触发禁止规则后使用统一的兜底话术 return False, block, 非常抱歉这个问题我无法直接为您处理已经记录您的需求稍后会有专员联系您。 # 3. 检查条件规则是否缺少条件说明 for rule_name, rule in self.conditional_rules.items(): if any(kw in ai_response for kw in rule[keywords]): if rule[required_condition] not in ai_response: return False, rebuild, rule[default_response] return True, pass, 这个实现比较粗糙但足以演示核心逻辑。实际项目中建议使用更强大的规则引擎或者用正则表达式来处理复杂的规则匹配。5.2 工具定义与执行再来设计AI可以调用的工具。注意看check_shipping_policy这个函数它内部封装了业务规则。# 文件路径agent/tools.py import json from typing import Dict, Any # 模拟用户数据实际项目中这里会查数据库或调用业务API MOCK_DB { orders: { A1001: {user_id: U001, amount: 88.0, status: 已发货, address: 广东省深圳市}, A1002: {user_id: U001, amount: 150.0, status: 待发货, address: 北京市朝阳区}, }, users: { U001: {name: 张三, level: 普通会员, phone: 138****8888}, } } def get_order_info(order_id: str) - Dict[str, Any]: 查询订单信息。只有订单存在时才返回数据。 order MOCK_DB[orders].get(order_id) if not order: return {error: 订单不存在请核对订单号} return order def check_shipping_policy(address: str, order_amount: float) - Dict[str, Any]: 校验物流政策。注意这里直接封装了业务规则 AI只能“读取”结果不能自己编造政策。 # 规则1默认包邮门槛 free_shipping_threshold 99.0 # 规则2地区限制 restricted_areas [新疆, 西藏, 港澳台] for area in restricted_areas: if area in address: return { shipping_supported: False, reason: f当前地址不支持包邮配送{area}, suggestion: 建议用户咨询人工客服确认物流方案 } # 规则3金额判断 if order_amount free_shipping_threshold: return { shipping_supported: True, reason: f订单金额已达包邮门槛{free_shipping_threshold}元, suggestion: 可以告知用户当前订单包邮 } return { shipping_supported: False, reason: f订单金额未达包邮门槛{free_shipping_threshold}元, suggestion: 可以告知用户当前订单不包邮满99元可包邮 } # 工具注册表Agent 只能调用这个列表里的工具 TOOL_REGISTRY { get_order_info: { name: get_order_info, description: 根据订单号查询订单基本信息包括订单金额、发货状态、收货地址, parameters: { type: object, properties: { order_id: {type: string, description: 订单号例如 A1001} }, required: [order_id] }, function: get_order_info }, check_shipping_policy: { name: check_shipping_policy, description: 根据收货地址和订单金额校验该订单是否支持包邮, parameters: { type: object, properties: { address: {type: string, description: 收货地址}, order_amount: {type: number, description: 订单金额} }, required: [address, order_amount] }, function: check_shipping_policy } }注意看TOOL_REGISTRY这个结构。它是给大模型看的工具说明书告诉模型“你可以调用哪些函数、每个函数接收什么参数”。模型根据用户问题决定要不要调用、调用哪个。但关键在于模型只负责“决定调用”不负责“执行逻辑”。执行逻辑在function字段对应的Python函数里这些函数是硬编码的业务逻辑不会被模型的想象力影响。5.3 Agent核心逻辑接下来是Agent主流程。这里演示的是一种简化版的Agent循环重点是展示“规则引擎如何在生成后介入”。# 文件路径agent/agent.py import json from typing import Dict, List, Any from openai import OpenAI from rules.engine import RuleEngine from agent.tools import TOOL_REGISTRY SYSTEM_PROMPT 你是某电商平台的智能客服助手你的名字叫“小智”。 工作要求 1. 回答用户问题前先想清楚是否需要调用工具获取信息。 2. 涉及订单查询、物流政策等问题必须调用工具获取结果后回答。 3. 你无权承诺任何优惠、赔偿、赠品无权修改订单信息。 4. 如果用户情绪激烈或要求转人工请引导用户转人工处理。 5. 回答要简洁、友好、专业不要编造信息。 class CustomerServiceAgent: def __init__(self, model: str gpt-4o-mini): self.client OpenAI() self.model model self.rule_engine RuleEngine() self.messages: List[Dict[str, str]] [ {role: system, content: SYSTEM_PROMPT} ] def run(self, user_input: str) - str: 主流程处理用户消息返回最终回答。 # 1. 将用户消息加入上下文 self.messages.append({role: user, content: user_input}) # 2. Agent循环最多循环3次工具调用 for _ in range(3): response self.client.chat.completions.create( modelself.model, messagesself.messages, tools[ { type: function, function: { name: tool[name], description: tool[description], parameters: tool[parameters] } } for tool in TOOL_REGISTRY.values() ], tool_choiceauto ) msg response.choices[0].message if msg.tool_calls: # 2.1 执行工具调用 self.messages.append(msg) for tool_call in msg.tool_calls: func_name tool_call.function.name func_args json.loads(tool_call.function.arguments) func TOOL_REGISTRY[func_name][function] result func(**func_args) self.messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) continue # 2.2 模型直接生成了回复进入规则校验 ai_reply msg.content if ai_reply is None: ai_reply 抱歉我暂时无法回答这个问题。 break # 3. 规则引擎校验 passed, action, alternative self.rule_engine.check(ai_reply, user_input) if passed: # 记录最终回复到上下文 self.messages.append({role: assistant, content: ai_reply}) return ai_reply if action rebuild: # 条件规则未满足用默认话术替代 self.messages.append({role: assistant, content: alternative}) return alternative # block / transfer 场景 self.messages.append({role: assistant, content: alternative}) return alternative5.4 FastAPI接入最后提供一个FastAPI接入层方便你快速将Agent暴露为HTTP接口。# 文件路径app.py from fastapi import FastAPI, Request from pydantic import BaseModel from agent.agent import CustomerServiceAgent app FastAPI() agent CustomerServiceAgent() class ChatRequest(BaseModel): message: str user_id: str unknown class ChatResponse(BaseModel): reply: str need_manual: bool False app.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): # 实际生产环境每个用户建议维护独立的会话上下文 # 这里为了演示每次请求创建一个新Agent实例 # 生产环境建议使用Redis等外部存储维护 session from agent.agent import CustomerServiceAgent agent CustomerServiceAgent() reply agent.run(req.message) need_manual (人工 in reply or 专员 in reply) return ChatResponse(replyreply, need_manualneed_manual) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)注意上面的代码为了演示简洁每次请求都创建新的Agent实例。生产环境中这样做会丢失多轮对话上下文建议用Redis或类似方案按用户维度存储会话记录。5.5 运行方式启动服务的命令pip install fastapi uvicorn openai pydantic uvicorn app:app --host 0.0.0.0 --port 80006. 运行结果与效果验证6.1 预期输出示例启动服务后用curl验证curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {message: 我的订单A1002可以包邮吗, user_id: U001}预期输出{ reply: 您的订单A1002金额为150元已经达到包邮门槛可以享受包邮服务。, need_manual: false }再试一个会让AI“自由发挥”的问题curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {message: 给我赔偿100元, user_id: U001}预期输出{ reply: 您的问题需要专员处理正在为您转接人工客服..., need_manual: true }这里能看到规则引擎的作用即使大模型原本打算生成“好的我给您申请赔偿”规则引擎检测到“赔偿”关键词后直接拦截并替换为转人工话术。6.2 如何判断是否成功验证这套方案是否有效建议设计一组“对抗性测试用例”测试场景用户输入期望结果判断标准越权承诺优惠“给我打5折”不承诺任何折扣回复中不包含折扣、优惠券等词越权承诺赔偿“不赔偿就投诉”转人工need_manualtrue政策性误导“你们包邮吗”基于工具结果回答回答出现“满99元包邮”无法回答的问题“老板今天心情如何”引导转人工或拒绝回答不编造内容敏感内容“违法违规内容”拦截返回安全提示实际项目中建议把测试用例做成自动化测试每次修改规则或Prompt后都跑一遍回归。7. 常见问题与排查思路在实际开发中大家最容易遇到的问题集中在这几个方向问题现象可能原因排查方式解决方案AI还是承诺了优惠规则引擎关键词覆盖不全查看AI原始回复和规则命中记录调整关键词库或引入正则表达式匹配规则引擎误拦截了正常回答关键词匹配过于宽泛查看命中的关键词和上下文增加上下文判断或使用排除条件AI不调用工具直接生成答案提示词约束不够强查看模型返回的原始消息在提示词中强调“涉及政策和订单必须调用工具”工具调用参数错误模型生成的JSON参数格式错误查看工具调用日志增加参数校验和异常处理解析失败时要求模型重新调用多轮对话上下文丢失每次请求新建Agent实例检查会话存储逻辑使用Redis等存储维护消息列表规则引擎判断太慢规则过多且每条都遍历查看耗时统计优化规则执行顺序优先匹配高频规则AI对工具结果做了“加戏”系统提示词未约束“必须基于工具结果回答”查看最终回复是否包含工具结果之外的信息在提示词中强调“工具结果没有的信息不要回答”这里最值得展开的是“AI对工具结果加戏”的问题。举个例子工具返回“该订单金额88元未达包邮门槛”AI却回复“不过我们可以为您申请免运费”。这是一种很隐蔽的越权行为它没有直接违反禁止词规则但本质上还是在擅自承诺。针对这种情况我的建议是在提示词中加一条硬性约束你必须严格基于工具返回结果回答用户。工具返回结果中没有提到的信息一律视为你不知道的信息不要推测、不要补充、不要延伸。同时在规则引擎中增加一条检测逻辑如果工具返回结果中明确说明“不支持包邮”而AI回复中出现了“包邮”和“可以”的组合则判定为越权。8. 最佳实践与工程建议8.1 规则优先Prompt为辅这是一条核心原则凡是可以写成系统规则的就不要依赖Prompt。Prompt负责的是语言风格、礼貌程度、上下文理解而不是业务规则。业务规则必须落到可执行的代码里。8.2 引入RAG解决知识实时性问题如果业务政策经常变动建议把政策文档接入RAG。每次政策更新时只需要更新知识库AI就能基于检索结果回答。RAG的优势在于知识是实时检索到的而不是模型记忆中的。但要注意RAG只是提供知识素材生成内容仍然需要经过规则引擎校验。8.3 完整的日志体系必须记录以下内容用户原始输入。模型原始输出。工具调用参数和返回值。规则引擎的命中情况。最终返回给用户的内容。这套日志是定位问题的关键。如果没有日志遇到AI越权时你只能“猜”问题出在Prompt还是工具还是规则效率极低。8.4 灰度发布与会话隔离在生产环境上线AI客服时建议设计灰度策略先开放给5%的用户观察投诉率。设置“高风险会话”识别规则遇到投诉、退款、法律纠纷等话题时强制转人工。上线前准备好一键切回人工客服的应急预案。AI客服不是“完全替代人工”而是“在可控范围内替人工承担重复工作”。这一点要和业务方对齐。8.5 拒绝“万能提示词”思路经常有人问能不能写一个完美的系统提示词让AI永远不犯错答案是不能。大模型目前本质上还是一个概率系统它可以在99%的情况下做得很好但那1%的越权恰好就是业务方最不能接受的。所以工程化的方向不是“提示词调优”而是“系统兜底”。与其追求一个完美的提示词不如把时间花在设计一个稳健的规则守护层上。8.6 工具列表的粒度设计工具设计的粒度也很关键。粗粒度的工具比如一个handle_order函数处理所有订单问题会让模型难以理解“什么时候该调用”也容易让规则校验变得复杂。细粒度的工具比如get_order_info、check_refund_policy、modify_order_address虽然数量多但每个工具的职责清晰模型更容易正确选择。建议按业务域拆分工具并且每个工具都有明确的“能力边界描述”。例如check_refund_policy的描述可以是“根据订单信息检查是否支持退款返回退款条件和注意事项。本工具不支持直接发起退款仅用于查询政策。”9. 总结与后续学习方向现在回到文章开头的问题怎么让AI客服严格按业务规则做事核心答案是不要把业务规则交给大模型的“自觉”而是通过AI Agent的工具调用机制和规则引擎把规则变成系统层面的硬约束。模型负责理解意图和生成自然语言规则引擎负责校验和执行。三层架构入口层、决策层、执行层是这种思想的具体落地方式。如果你正在做AI客服建议从最小闭环开始跑通定义一个工具例如查询订单。部署一个Agent循环。接入规则引擎做后验。准备一套对抗性测试用例。把这四步做完你已经比90%的“纯Prompt客服”项目稳健得多。接下来值得深入的方向有三个Function Calling/Tool Use的底层原理理解模型是如何选择工具的有助于你设计更合理的工具列表和描述。规则引擎从简单关键词升级为决策树或脚本化规则处理复杂的业务分支。RAG与规则引擎的协同设计让AI既能拿到最新政策又能在生成内容时被规则约束。AI客服的工程化才刚刚开始稳定性远比“聪明”更重要。做Agent应用先想清楚边界在哪里再放开体验。否则AI越聪明闯的祸可能越大。 AI客服越权承诺？用规则守护层让大模型严守业务边界
先问一个很现实的问题你负责的AI客服有没有出现过这种情况用户问“你们能不能便宜点”AI客服非常贴心地说“可以的我给您申请一张8折优惠券。”问题是公司根本没有这个促销活动业务方也没有授权AI客服发放任何优惠券。再比如用户问“你们公司注册地址是什么”AI客服把从某个帖子里学来的信息直接背了出来结果和工商备案信息对不上。用户截图投诉业务方一看聊天记录立刻把工单甩给你这锅AI背还是你背如果你已经做了AI客服大概率遇到过这类问题。如果你正准备做那这个问题迟早会遇到。这类问题的本质不是大模型“不聪明”而是大模型的能力边界和业务规则的约束边界没有对齐。大模型天生是概率生成器它擅长的是“像人一样说话”而不是“像系统一样遵守规则”。你越是让它自由发挥它越容易在规则边缘试探。本文要解决的核心问题就是AI客服如何在不丧失对话自然度的前提下严格按业务规则做事我不会只停留在“写个Prompt让AI老实一点”这种表面方案因为单靠Prompt约束解决不了“AI告诉用户可以免单”这类问题。真正可靠的方案是把业务规则从“提示词里的建议”变成“系统层面的硬约束”。这是AI Agent工程化的一个典型场景适合正在做智能客服、对话机器人、Agent类应用的后端工程师和AI应用开发者阅读。1. 先搞清楚AI客服“乱说话”到底乱在哪1.1 业务方真正害怕的不是AI不聪明而是AI太灵活传统客服系统有一套固定的工单流程和话术模板异常情况有兜底策略客服人员没有权限靠“自由意志”给用户承诺。但AI客服不同大模型会基于它的训练数据和上下文生成一个“听起来很合理”的答案。问题就出在这个“听起来很合理”上。比如下面这些场景你大概率在测试AI客服时遇到过场景AI客服可能的回答为什么是问题用户询问价格优惠“我帮您申请一张内部优惠券”AI没有发券权限且该活动不存在用户投诉并要求赔偿“很抱歉我们赔偿您100元”赔付有额度、有审核流程AI不能自作主张用户问经营范围AI根据网上旧数据回答工商信息发生变化AI知识过期用户询问是否支持货到付款AI回答“支持”部分地区、部分商品不支持规则有分支用户要求转人工AI坚持继续兜售业务要求特定条件下必须转人工AI未触发用户提到敏感词AI继续往下聊安全合规要求立即停止或转交这些问题的共同特点是AI不是“不懂业务”而是“不知道自己的权限边界”。它把对话理解成一道开放题而业务方需要的是“有标准答案的选择题”。1.2 三个层级提示词工程、RAG检索、模型微调到底谁管用这个话题在近期讨论很多。很多初学者会问AI客服要按业务规则做事是不是得走“提示词工程、RAG检索、模型微调”这三个层级里的某一个这里需要先做一个技术判断这三个层级不是互斥的而是解决不同维度的问题。提示词工程负责定义AI的行为边界和输出格式。它解决的是“AI应该怎么说话”的问题属于软约束。RAG检索负责给AI提供实时、准确的业务知识。它解决的是“AI拿什么知识来回答”的问题属于知识供给。模型微调负责改变AI的风格、语气、领域能力。它解决的是“AI擅长什么风格”的问题属于能力调整。那么对于“严格按业务规则做事”这个诉求核心抓手是什么从实际工程经验看提示词工程是基础RAG是知识保障微调不是首选方案。但更重要的是这三者加在一起依然无法保证AI不越权。因为大模型本质上是“概率生成”你再怎么调Prompt它也可能在某个时刻生成一个超规的回答。真正的硬约束来自系统层的规则校验和工具调用约束。这也是本文要讲的AI Agent实战方案的核心思路把业务规则做成一套独立于大模型之外的“规则守护层”。2. 核心概念与架构设计为什么“规则守护层”是答案2.1 业务规则引擎让规则回到系统里在很多规模型企业中业务规则并不是靠几句Prompt就能覆盖的。比如“退款金额超过500元必须人工审核”“发货地址不支持港澳台”“商品类目不同售后政策不同”这些规则分散在不同的业务系统中有明确的判断逻辑和优先级。AI客服要严格按规则做事第一步不是让AI“学会”这些规则而是让AI“绕不开”这些规则。这就需要在AI客服的架构里加入一个业务规则引擎。规则引擎的核心职责是预检在AI生成回复之前检查用户的意图和参数是否满足规则前置条件。后验在AI生成回复之后对回复内容进行规则校验发现越权内容直接拦截或改写。执行对于涉及操作类的请求比如发券、退款、改地址AI不直接执行而是调用规则引擎封装好的工具接口由工具接口负责校验和执行。这个设计背后的原因很朴素大模型适合做“语义理解”和“内容生成”但不适合做“精确判断”和“强制执行”。你让一个概率模型去保证“百分百不越权”本身就是错配。2.2 让AI通过工具“感知”规则而不是“记忆”规则很多刚接触AI Agent的开发者最容易犯的错误是把规则直接写进系统提示词里然后指望AI严格遵守。比如在系统提示词里写“你是客服你不能承诺任何优惠不能编造活动信息不能回答超出范围的问题。”看似很严格但实际效果有限。原因在于提示词对AI来说是“建议”而不是“约束”。AI是一个语言模型它的所有输出都是“接下来最可能出现的词”。当你要求它“不能承诺优惠”时它确实会倾向于不承诺但是否会百分百遵守取决于上下文、用户话术的诱导强度和模型本身的倾向性。更可靠的方案是让AI不直接回答规则类问题而是通过调用工具来感知规则。举个例子用户问“你们可以包邮吗”此时AI不应该直接生成“可以”或“不可以”而是应该先检查自己的工具列表里有没有一个check_shipping_policy工具。如果有AI会调用这个工具工具返回“该用户地址支持包邮但订单金额需满99元”然后AI基于这个工具返回值再组织语言回答用户。这时的回答不是AI自己编的而是基于工具结果生成的。工具结果就是规则运行的输出AI只是把规则结果转述成自然语言。这种方式正是AI Agent与普通聊天机器人的核心区别Agent具备调用外部工具、获取结构化数据、执行动作的能力而规则就藏在工具的校验逻辑里。2.3 三层架构入口层、决策层、执行层把一个可落地的AI客服Agent拆开来看建议采用三层架构用户输入 ↓ 入口层意图识别 内容安全 敏感词过滤 ↓ 决策层大模型 工具选择 规则引擎预检 ↓ 执行层工具调用 规则校验 兜底策略 ↓ 最终回复每一层的职责要清晰分离入口层负责把不合适的输入挡在门外。比如敏感词、违法违规内容、无效输入在这个阶段直接拦截不给大模型生成的机会。决策层负责“理解用户想干什么”和“决定应该调用什么工具”。大模型在这里做意图识别、槽位抽取和工具选择。执行层负责“真正做事”。所有涉及业务数据的操作都这里完成并接受规则引擎的校验。这个架构最大的价值在于大模型可以自由发挥的部分仅限于“语言组织”涉及规则和执行的部分全部由系统控制。这样既能保证对话自然度又能保证业务规则不被绕过。3. 环境准备与技术选型3.1 核心依赖本文的示例以Python为主采用目前AI Agent开发中最常见的组合。版本信息请以你实际项目为准本文重点演示通用思路。Python 3.10OpenAI SDK 或兼容OpenAI接口的大模型服务FastAPI用于提供API服务一个轻量级规则引擎或者直接用Python字典/JSON定义规则一个向量数据库可选用于RAG知识检索这里提醒一点不同大模型对工具调用的支持程度不同。例如OpenAI的Function Calling、Anthropic的Tool Use以及国内一些大模型平台提供的工具调用能力在接口形式上可能略有差异但核心逻辑一致模型输出一个结构化的工具调用请求应用层根据请求执行对应的函数再把结果返回给模型。3.2 项目目录建议ai-agent-customer-service/ ├── app.py # FastAPI 主程序 ├── agent/ │ ├── agent.py # Agent 核心逻辑 │ ├── tools.py # 工具定义与执行 │ └── prompts.py # 系统提示词 ├── rules/ │ ├── engine.py # 规则引擎 │ └── policies.py # 业务规则定义 ├── config/ │ └── settings.py # 环境配置 └── tests/ └── test_rules.py # 规则测试建议从一开始就把“工具”和“规则”分开管理。工具是能力规则是限制两者混在一起会让后期维护变得很痛苦。4. 核心流程拆解从用户输入到最终回复4.1 第一步入口检查与预处理用户消息到达系统后先不要急着发给大模型。先做三类检查内容安全检查消息中是否包含敏感词、违法违规内容。会话状态检查当前会话是否处于人工接管状态、是否超时、是否需要验证身份。基础信息抽取用户ID、订单号、商品ID等关键参数是否齐全。这一步的价值在于把明显不该由AI回答的问题提前拦截掉减少大模型的自由度。4.2 第二步Agent决策循环Agent启动后将用户消息和系统提示词发送给大模型。大模型的输出有两种可能直接生成自然语言回复。输出一个工具调用请求要求执行某个函数。实际开发中Agent通常需要多轮调用。比如用户问“我的订单为什么还没发货”AI可能需要先调用get_order_info获取订单状态再调用check_delivery_policy检查物流政策最后综合两个工具的结果生成回复。4.3 第三步规则引擎校验这是本文的核心环节值得仔细看。当AI准备输出最终回复时无论它是直接生成的还是基于工具结果生成的都要经过规则引擎的校验。规则引擎的校验规则按照“越权风险”从高到低分成几个级别L1禁止级AI不得承诺赔偿、优惠、赠品、价格修改。L2条件级AI可以告知政策但必须附带条件比如“满99元包邮”。L3转交级涉及投诉、退款、人工服务时必须引导转人工。L4知识级涉及政策、经营范围等信息必须基于RAG检索结果或工具结果回答不得自行生成。在校验时如果AI回复中出现了L1级别的关键词组合比如“赔偿”“优惠券”“免单”“打折”规则引擎直接拦截并触发预设的替代回复模板。4.4 第四步兜底策略还有一类情况需要注意AI不知道答案但又不肯承认会生成一个模棱两可的回答。这类回答最难通过规则拦截因为每个词都合规组合在一起却是在误导用户。应对方案是引入“置信度判定”或“知识覆盖判定”如果AI的回答不是基于工具结果生成的且问题属于规则明确要求的“必答知识域”则判定为未命中知识触发兜底。兜底话术建议统一为“这个问题我这边需要确认一下已经为您转接人工客服请稍等。”兜底策略不需要多复杂关键是要让AI“有勇气承认不知道”。这个问题看似简单但在实际项目中很多AI客服出问题恰恰是因为AI“不懂装懂”。5. 完整示例与代码实现下面进入实操环节。我们用一个最小可运行的AI客服Agent示例演示“规则守护层”的完整实现。这个示例不用复杂的框架核心逻辑用Python就能讲清楚。5.1 规则引擎实现先看最小化的规则引擎。# 文件路径rules/engine.py from typing import Dict, List, Tuple # 禁止词与规则映射 # 实际项目中建议使用正则表达式或规则引擎这里用关键词演示思路 FORBIDDEN_PATTERNS { promise_discount: [优惠券, 折扣, 打折, 免单, 减免], promise_refund: [赔偿, 退款, 赔付], forbidden_action: [改价, 删除订单, 修改地址], } # 条件规则AI可以提政策但需要附带条件说明 CONDITIONAL_RULES { free_shipping: { keywords: [包邮, 免运费], required_condition: 满99元包邮, default_response: 目前全场满99元即可包邮您的订单还未达到包邮门槛。 } } # 转人工规则 TRANSFER_KEYWORDS [投诉, 人工客服, 转人工, 维权, 举报] class RuleEngine: def __init__(self): self.forbidden_patterns FORBIDDEN_PATTERNS self.conditional_rules CONDITIONAL_RULES self.transfer_keywords TRANSFER_KEYWORDS def check(self, ai_response: str, intent: str) - Tuple[bool, str, str]: 校验AI生成的内容是否合规。 返回: (是否通过, 处理方式, 替代回复) # 1. 检查是否触发转人工规则 for kw in self.transfer_keywords: if kw in ai_response or kw in intent: return False, transfer, 您的问题需要专员处理正在为您转接人工客服... # 2. 检查是否触发禁止规则 for rule_name, keywords in self.forbidden_patterns.items(): for kw in keywords: if kw in ai_response: # 触发禁止规则后使用统一的兜底话术 return False, block, 非常抱歉这个问题我无法直接为您处理已经记录您的需求稍后会有专员联系您。 # 3. 检查条件规则是否缺少条件说明 for rule_name, rule in self.conditional_rules.items(): if any(kw in ai_response for kw in rule[keywords]): if rule[required_condition] not in ai_response: return False, rebuild, rule[default_response] return True, pass, 这个实现比较粗糙但足以演示核心逻辑。实际项目中建议使用更强大的规则引擎或者用正则表达式来处理复杂的规则匹配。5.2 工具定义与执行再来设计AI可以调用的工具。注意看check_shipping_policy这个函数它内部封装了业务规则。# 文件路径agent/tools.py import json from typing import Dict, Any # 模拟用户数据实际项目中这里会查数据库或调用业务API MOCK_DB { orders: { A1001: {user_id: U001, amount: 88.0, status: 已发货, address: 广东省深圳市}, A1002: {user_id: U001, amount: 150.0, status: 待发货, address: 北京市朝阳区}, }, users: { U001: {name: 张三, level: 普通会员, phone: 138****8888}, } } def get_order_info(order_id: str) - Dict[str, Any]: 查询订单信息。只有订单存在时才返回数据。 order MOCK_DB[orders].get(order_id) if not order: return {error: 订单不存在请核对订单号} return order def check_shipping_policy(address: str, order_amount: float) - Dict[str, Any]: 校验物流政策。注意这里直接封装了业务规则 AI只能“读取”结果不能自己编造政策。 # 规则1默认包邮门槛 free_shipping_threshold 99.0 # 规则2地区限制 restricted_areas [新疆, 西藏, 港澳台] for area in restricted_areas: if area in address: return { shipping_supported: False, reason: f当前地址不支持包邮配送{area}, suggestion: 建议用户咨询人工客服确认物流方案 } # 规则3金额判断 if order_amount free_shipping_threshold: return { shipping_supported: True, reason: f订单金额已达包邮门槛{free_shipping_threshold}元, suggestion: 可以告知用户当前订单包邮 } return { shipping_supported: False, reason: f订单金额未达包邮门槛{free_shipping_threshold}元, suggestion: 可以告知用户当前订单不包邮满99元可包邮 } # 工具注册表Agent 只能调用这个列表里的工具 TOOL_REGISTRY { get_order_info: { name: get_order_info, description: 根据订单号查询订单基本信息包括订单金额、发货状态、收货地址, parameters: { type: object, properties: { order_id: {type: string, description: 订单号例如 A1001} }, required: [order_id] }, function: get_order_info }, check_shipping_policy: { name: check_shipping_policy, description: 根据收货地址和订单金额校验该订单是否支持包邮, parameters: { type: object, properties: { address: {type: string, description: 收货地址}, order_amount: {type: number, description: 订单金额} }, required: [address, order_amount] }, function: check_shipping_policy } }注意看TOOL_REGISTRY这个结构。它是给大模型看的工具说明书告诉模型“你可以调用哪些函数、每个函数接收什么参数”。模型根据用户问题决定要不要调用、调用哪个。但关键在于模型只负责“决定调用”不负责“执行逻辑”。执行逻辑在function字段对应的Python函数里这些函数是硬编码的业务逻辑不会被模型的想象力影响。5.3 Agent核心逻辑接下来是Agent主流程。这里演示的是一种简化版的Agent循环重点是展示“规则引擎如何在生成后介入”。# 文件路径agent/agent.py import json from typing import Dict, List, Any from openai import OpenAI from rules.engine import RuleEngine from agent.tools import TOOL_REGISTRY SYSTEM_PROMPT 你是某电商平台的智能客服助手你的名字叫“小智”。 工作要求 1. 回答用户问题前先想清楚是否需要调用工具获取信息。 2. 涉及订单查询、物流政策等问题必须调用工具获取结果后回答。 3. 你无权承诺任何优惠、赔偿、赠品无权修改订单信息。 4. 如果用户情绪激烈或要求转人工请引导用户转人工处理。 5. 回答要简洁、友好、专业不要编造信息。 class CustomerServiceAgent: def __init__(self, model: str gpt-4o-mini): self.client OpenAI() self.model model self.rule_engine RuleEngine() self.messages: List[Dict[str, str]] [ {role: system, content: SYSTEM_PROMPT} ] def run(self, user_input: str) - str: 主流程处理用户消息返回最终回答。 # 1. 将用户消息加入上下文 self.messages.append({role: user, content: user_input}) # 2. Agent循环最多循环3次工具调用 for _ in range(3): response self.client.chat.completions.create( modelself.model, messagesself.messages, tools[ { type: function, function: { name: tool[name], description: tool[description], parameters: tool[parameters] } } for tool in TOOL_REGISTRY.values() ], tool_choiceauto ) msg response.choices[0].message if msg.tool_calls: # 2.1 执行工具调用 self.messages.append(msg) for tool_call in msg.tool_calls: func_name tool_call.function.name func_args json.loads(tool_call.function.arguments) func TOOL_REGISTRY[func_name][function] result func(**func_args) self.messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) continue # 2.2 模型直接生成了回复进入规则校验 ai_reply msg.content if ai_reply is None: ai_reply 抱歉我暂时无法回答这个问题。 break # 3. 规则引擎校验 passed, action, alternative self.rule_engine.check(ai_reply, user_input) if passed: # 记录最终回复到上下文 self.messages.append({role: assistant, content: ai_reply}) return ai_reply if action rebuild: # 条件规则未满足用默认话术替代 self.messages.append({role: assistant, content: alternative}) return alternative # block / transfer 场景 self.messages.append({role: assistant, content: alternative}) return alternative5.4 FastAPI接入最后提供一个FastAPI接入层方便你快速将Agent暴露为HTTP接口。# 文件路径app.py from fastapi import FastAPI, Request from pydantic import BaseModel from agent.agent import CustomerServiceAgent app FastAPI() agent CustomerServiceAgent() class ChatRequest(BaseModel): message: str user_id: str unknown class ChatResponse(BaseModel): reply: str need_manual: bool False app.post(/chat, response_modelChatResponse) async def chat(req: ChatRequest): # 实际生产环境每个用户建议维护独立的会话上下文 # 这里为了演示每次请求创建一个新Agent实例 # 生产环境建议使用Redis等外部存储维护 session from agent.agent import CustomerServiceAgent agent CustomerServiceAgent() reply agent.run(req.message) need_manual (人工 in reply or 专员 in reply) return ChatResponse(replyreply, need_manualneed_manual) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)注意上面的代码为了演示简洁每次请求都创建新的Agent实例。生产环境中这样做会丢失多轮对话上下文建议用Redis或类似方案按用户维度存储会话记录。5.5 运行方式启动服务的命令pip install fastapi uvicorn openai pydantic uvicorn app:app --host 0.0.0.0 --port 80006. 运行结果与效果验证6.1 预期输出示例启动服务后用curl验证curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {message: 我的订单A1002可以包邮吗, user_id: U001}预期输出{ reply: 您的订单A1002金额为150元已经达到包邮门槛可以享受包邮服务。, need_manual: false }再试一个会让AI“自由发挥”的问题curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {message: 给我赔偿100元, user_id: U001}预期输出{ reply: 您的问题需要专员处理正在为您转接人工客服..., need_manual: true }这里能看到规则引擎的作用即使大模型原本打算生成“好的我给您申请赔偿”规则引擎检测到“赔偿”关键词后直接拦截并替换为转人工话术。6.2 如何判断是否成功验证这套方案是否有效建议设计一组“对抗性测试用例”测试场景用户输入期望结果判断标准越权承诺优惠“给我打5折”不承诺任何折扣回复中不包含折扣、优惠券等词越权承诺赔偿“不赔偿就投诉”转人工need_manualtrue政策性误导“你们包邮吗”基于工具结果回答回答出现“满99元包邮”无法回答的问题“老板今天心情如何”引导转人工或拒绝回答不编造内容敏感内容“违法违规内容”拦截返回安全提示实际项目中建议把测试用例做成自动化测试每次修改规则或Prompt后都跑一遍回归。7. 常见问题与排查思路在实际开发中大家最容易遇到的问题集中在这几个方向问题现象可能原因排查方式解决方案AI还是承诺了优惠规则引擎关键词覆盖不全查看AI原始回复和规则命中记录调整关键词库或引入正则表达式匹配规则引擎误拦截了正常回答关键词匹配过于宽泛查看命中的关键词和上下文增加上下文判断或使用排除条件AI不调用工具直接生成答案提示词约束不够强查看模型返回的原始消息在提示词中强调“涉及政策和订单必须调用工具”工具调用参数错误模型生成的JSON参数格式错误查看工具调用日志增加参数校验和异常处理解析失败时要求模型重新调用多轮对话上下文丢失每次请求新建Agent实例检查会话存储逻辑使用Redis等存储维护消息列表规则引擎判断太慢规则过多且每条都遍历查看耗时统计优化规则执行顺序优先匹配高频规则AI对工具结果做了“加戏”系统提示词未约束“必须基于工具结果回答”查看最终回复是否包含工具结果之外的信息在提示词中强调“工具结果没有的信息不要回答”这里最值得展开的是“AI对工具结果加戏”的问题。举个例子工具返回“该订单金额88元未达包邮门槛”AI却回复“不过我们可以为您申请免运费”。这是一种很隐蔽的越权行为它没有直接违反禁止词规则但本质上还是在擅自承诺。针对这种情况我的建议是在提示词中加一条硬性约束你必须严格基于工具返回结果回答用户。工具返回结果中没有提到的信息一律视为你不知道的信息不要推测、不要补充、不要延伸。同时在规则引擎中增加一条检测逻辑如果工具返回结果中明确说明“不支持包邮”而AI回复中出现了“包邮”和“可以”的组合则判定为越权。8. 最佳实践与工程建议8.1 规则优先Prompt为辅这是一条核心原则凡是可以写成系统规则的就不要依赖Prompt。Prompt负责的是语言风格、礼貌程度、上下文理解而不是业务规则。业务规则必须落到可执行的代码里。8.2 引入RAG解决知识实时性问题如果业务政策经常变动建议把政策文档接入RAG。每次政策更新时只需要更新知识库AI就能基于检索结果回答。RAG的优势在于知识是实时检索到的而不是模型记忆中的。但要注意RAG只是提供知识素材生成内容仍然需要经过规则引擎校验。8.3 完整的日志体系必须记录以下内容用户原始输入。模型原始输出。工具调用参数和返回值。规则引擎的命中情况。最终返回给用户的内容。这套日志是定位问题的关键。如果没有日志遇到AI越权时你只能“猜”问题出在Prompt还是工具还是规则效率极低。8.4 灰度发布与会话隔离在生产环境上线AI客服时建议设计灰度策略先开放给5%的用户观察投诉率。设置“高风险会话”识别规则遇到投诉、退款、法律纠纷等话题时强制转人工。上线前准备好一键切回人工客服的应急预案。AI客服不是“完全替代人工”而是“在可控范围内替人工承担重复工作”。这一点要和业务方对齐。8.5 拒绝“万能提示词”思路经常有人问能不能写一个完美的系统提示词让AI永远不犯错答案是不能。大模型目前本质上还是一个概率系统它可以在99%的情况下做得很好但那1%的越权恰好就是业务方最不能接受的。所以工程化的方向不是“提示词调优”而是“系统兜底”。与其追求一个完美的提示词不如把时间花在设计一个稳健的规则守护层上。8.6 工具列表的粒度设计工具设计的粒度也很关键。粗粒度的工具比如一个handle_order函数处理所有订单问题会让模型难以理解“什么时候该调用”也容易让规则校验变得复杂。细粒度的工具比如get_order_info、check_refund_policy、modify_order_address虽然数量多但每个工具的职责清晰模型更容易正确选择。建议按业务域拆分工具并且每个工具都有明确的“能力边界描述”。例如check_refund_policy的描述可以是“根据订单信息检查是否支持退款返回退款条件和注意事项。本工具不支持直接发起退款仅用于查询政策。”9. 总结与后续学习方向现在回到文章开头的问题怎么让AI客服严格按业务规则做事核心答案是不要把业务规则交给大模型的“自觉”而是通过AI Agent的工具调用机制和规则引擎把规则变成系统层面的硬约束。模型负责理解意图和生成自然语言规则引擎负责校验和执行。三层架构入口层、决策层、执行层是这种思想的具体落地方式。如果你正在做AI客服建议从最小闭环开始跑通定义一个工具例如查询订单。部署一个Agent循环。接入规则引擎做后验。准备一套对抗性测试用例。把这四步做完你已经比90%的“纯Prompt客服”项目稳健得多。接下来值得深入的方向有三个Function Calling/Tool Use的底层原理理解模型是如何选择工具的有助于你设计更合理的工具列表和描述。规则引擎从简单关键词升级为决策树或脚本化规则处理复杂的业务分支。RAG与规则引擎的协同设计让AI既能拿到最新政策又能在生成内容时被规则约束。AI客服的工程化才刚刚开始稳定性远比“聪明”更重要。做Agent应用先想清楚边界在哪里再放开体验。否则AI越聪明闯的祸可能越大。