不用coze/dify，自己编程做一个可控的能够完成工作的客服：
coze/dify这类平台的缺点是适合非程序员，很难可控，同时复杂度也不低。那么适合程序员的智能客服，可以编程来实现，只需要2个简单文件，稍微配置一下就实现，也许值得试试，以下我介绍我的方案。
一般的客服是什么功能：
这是一般的客服，能够回答问题。但是缺点就是无法类似人类客服那样，能够办理业务，真正工作。
例如客服遇到的麻烦：
因为输入输出和交互过程都是模糊的，一般客服的那种（查询知识库-》回答），这模式很难解决客户问题，客户不想和AI说话。
解决方法：
客服需要意图识别和收集用户数据，进行api调用和回答正常，对用户有帮助，办理好业务。例如以下就是一个办理业务的对话：
假设用户提问：“Hi, can you tell me the delivery date for my order?”助手应执行以下步骤： 1. 识别意图：用户明确要求“delivery date”，符合工具调用条件。 2. 参数提取：需引导用户提供 order_id（因消息中未直接包含该信息）：*“Sure! Please provide your order ID so I can check the delivery schedule.”* 3. 工具调用：获得 order_id 后，后台执行 get_delivery_date(order_id="XXX")。 4. 返回结果：向用户展示函数返回的配送日期（如 *“您的订单预计在2025年6月25日18:00前送达”* ）。coze / dify 怎样解决：
首先，我还是介绍一下coze,dify 它们的客服方案是怎样的，对比起来理解我新的方案有什么好处：
coze的解决方法：
意图识别：
多分支意图识别：
复杂的提示语指引用户，指引AI, 能够按流程 输入输出和走好流程：
麻烦就是： 很简单的业务都会很难搭建流程，因为输入输出和过程都很多模糊和条件分支：
售后：# 你的工作任务如下：## 第一步：判断关键信息- 查询用户问题和诉求 - 结合历史会话，根据用户本轮问题，了解用户当前遇到了什么问题、有什么诉求 ## 第二步：判断所属场景根据判断出的用户问题和诉求，判断用户所处的场景，场景定义如下：{#InputSlot placeholder="请输入编辑块内容为空时的提示文案" mode="input"#}- 物流场景： - 用户表达商家发货慢/长时间不发货、或因商家发货慢进线催促商家发货。 - 用户进线查询物流进度、催促物流进度、咨询快递拒收问题，或反馈快递不派送的问题。 - 用户咨询反馈在物流快递运输途中产生催促等诉求或遇到物流快递异常等问题- 支付场景： - 用户表达支付成功后未及时显示订单信息，进线询问订单状态及处理办法。 - 用户反馈支付失败，但账户已扣款，进线要求退款或解决支付失败问题。 - 用户咨询支付过程中遇到的支付方式限制、支付密码无法输入等技术问题。 - 用户对支付金额有异议，如实际支付金额与商品标价不符，进线要求核实和处理。 - 用户在支付时遭遇网络卡顿等情况，不确定支付是否成功，进线确认支付结果。- 售后场景： - 用户发现商品存在质量问题，如损坏、功能缺失等，进线申请退换货或维修服务。 - 用户对商家或平台的售后服务政策有疑问，如退换货期限、运费承担等，进线咨询。 - 用户在申请售后服务后，进线查询售后进度，如审核是否通过、商品何时寄出等。 - 用户反馈在维修过程中遇到的问题，如维修时间过长、未修好等，要求进一步处理。 - 用户对退换货后的退款方式和时间有疑问，进线询问具体情况。-无明确场景： -用户的描述无法找到对应的场景{#/InputSlot#} ## 第三步：输出判断结果输出格式示例：售后场景 ## 限制- 只能输出物流场景、支付场景、售后场景、无明确场景中的一个场景，不要输出其他无关内容！！！！需要搭建复杂coze:
自适应智能体方案：
自适应智能体方案，是不需要搭建流程，让AI自己解决所有问题：
"Agentic agent" 可以翻译为 “能动性智能体” 或 “自主行为体”。
具体解释：
- Agentic 强调自主性、能动性和主动行为的能力。Agent 在人工智能和认知科学中通常译为“智能体”或“行为体”。
生成式 AI 客服的核心其实是通过大语言模型，构建智能体。
智能体 = 大模型 + 工具 + 记忆 + 对话策略。
· 大模型作为“智能体”大脑，用于理解问题和生成回答；
· 工具包括知识库、数据库、API 接口，用于提供结构化答案；
· 记忆还可以保持上下文、多轮对话状态；
· 对话策略促使智能体主动引导、符合品牌风格。
这种架构让 AI 客服能够感知用户意图、决策流程、调用相关数据或动作（如查库存、发票、物流）并生成自然语言回复。
并且，当智能体识别到自己无法准确解决用户问题时，也可以将智能地切换至人工客服。
智能体一般系统提示语：
# 角色 **客服小川** — 良品川子饮品店 AI 客服助手，服务于“良品川子”饮品店铺，擅长商品查询、下单、发票、配送与售后等服务。 ## 性格特质 - **亲切热情**：语气自然，像朋友般交流，用“您好”“没问题”“我来帮您”等表达。 - **专业靠谱**：熟知商品/政策/流程，回答精准稳重却不生硬。 - **反应迅速**：及时响应，并主动提示下一步操作选项。 - **品牌一致性**：语言、风格与“良品川子”调性保持统一。 ## 技能 - **知识检索**：能调用商品表、FAQ、支付与发票表、物流配送表等知识库内容。 - **意图识别 & 上下文维护**：识别用户意图（价格、库存、退换、发票等），维持多轮对话上下文。 - **主动引导**：在合适时机建议“是否需要我帮您下单或预约送货”。 - **问题处理**：遇不到的内容，礼貌回应并引导用户补充或转人工。 ## 具体互动流程 1. **欢迎** - 用户接入时发送： “您好，欢迎来到良品川子，我是客服小川，请问有什么可以帮您的？” 2. **意图识别 & 检索** - 判断用户意图，并调用相应知识库模块（如“保质期”、“发票说明”等）。 3. **信息提供 + 政策补充** - 直接回答问题，并补充相关政策细节，如“未开封7天退货”或“电子发票24小时内发送邮箱”等。 4. **主动引导** - 若用户未明确下一步，提示：“需要我帮您下单、预约配送或开票吗？” 5. **结束** - 结束时发送：“感谢您的惠顾，祝您生活愉快～有问题随时联系小川哦！” ## 交互示例 **示例 - 查询价格** 用户：这瓶蜂蜜柠檬茶多少钱？ 小川：蜂蜜柠檬茶500ml售价¥14，未开封保质期180天。需要我帮您查看库存或下单吗？ **示例 - 需要发票** 用户：可以开票吗？ 小川：支持电子发票，下单时备注邮箱，24小时内发送；如需纸质发票请提供抬头、税号和邮寄地址。 **示例 - 退货申请** 用户：我想退一箱苏打水。 小川：苏打气泡水保质期365天，未开封支持7天无理由退货。请提供订单号，我帮您安排。 **示例 - 转人工** 用户：我要投诉配送问题… 小川：非常抱歉给您带来不便，请提供订单号或快递单号，我这边将为您转人工客服处理。 ## 限制 - 回应采用极简风格，精炼核心信息，严格控制回复长度，避免冗余。 - 回复为纯文本格式，不使用 Markdown 标记。 - 不私自编造数据；若信息不明确，提示用户补充；如涉及政治、宗教或成本等无关内容，拒绝回复。 - 遇复杂或纠纷问题，需引导转人工客服，确保处理无缝。阿里百炼平台
这种是能够智能的调用知识库，识别意图和运行对应流程，自动调用api，自动填充参数，自动按反馈情况回答问题。我推荐阿里百炼平台，是很好的完成Agentic agent自适应智能体的工作。如下是我的一个客服例子：
我的新方案：
介绍完目前行业的主流方案，其实大部分情况用这些方案也是简单有效的。但是程序员往往需要可控的，真实工业级的客服，能够很好的回答问题，能够很好的完成业务，可以调试，简单高效。那么，我研究出以下简单的方案（只需要2个python文件），也是可以达到：下面是展示一些例子：用户查询订单：
用户留言：
用户咨询知识库：
用户问FAQ：
用户查看商品：
客服前端UI:
项目底层是基于 openai的agent ：
代码简单介绍：
1 建立各种tool工具：
2 建立对应的多个agent智能体：
3 就这么简单，简单配置（或者让AI写代码），一下子就搞出一个更好的客服。
开源地址：
代码模块包括： 客服agent， agent前端调试， 客服前端UI 。而功能调用，目前主要是利用了wordpress+woocommerce作为例子，换成其他都可以。
