多语言客户支持代理:使用 Dify Agent 进行工具协作、回退和内存管理的实用设计
简介
对于全球运营的公司来说,多语言客户支持是一个不可避免的问题。传统上,支持是通过为每种语言组织支持团队或使用翻译工具来处理的,但随着LLM增强的多语言处理能力,现在用单个AI代理支持多种语言是一种现实的方法。
然而,设计多语言客户支持代理时最重要的不是它是否可以支持多种语言。 GPT-4o和Claude等模型可以在没有提示的情况下处理多语言输入和输出。真正的设计挑战在于工具调用链的稳定性、回退策略的清晰性以及会话内存的正确管理。
在本文中,我们将解释构建企业级多语言客户支持代理的设计模式,重点关注 Dify 的 Agent 节点。
背景和问题
多语言客户支持的现状
| 问题 | 常规回应 | AI 代理解决方案 |
|---|---|---|
| 确保每种语言的人员安全 | 雇用每种语言的母语人士 | 单代理自动检测和切换语言 |
| 24小时支持 | 轮班制度/与海外基地的协调 | 代理提供 24/365 的主要支持 |
| 响应质量的变化 | 通过手册和培训实现标准化 | 通过知识库 + 提示实现响应质量标准化 |
| 与业务系统协作 | 操作人员手动参考和输入 | 通过代理调用工具实现自动协作 |
| 升级判断 | 取决于操作者个人判断 | 使用基于规则+情绪检测的自动升级 |
Dify Agent 节点的主要功能
Dify 的 Agent 节点原生支持以下配置项。
| 设置项目 | 描述 |
|---|---|
| 代理策略 | 从函数调用/ReAct |
| 工具清单 | 代理可用的工具列表 |
| 说明 | 对Agent的指示(相当于系统提示) |
| 查询 | 用户输入 |
| 最大迭代次数 | 工具调用的最大迭代次数 |
| 内存 | 对话历史记录保留开/关 |
| 窗口尺寸 | 保留的通话轮数 |
整体架构
flowchart TD
A[ユーザー入力<br>任意の言語] --> B[Dify Agent ノード]
B --> C{意図判定}
C -->|FAQ| D[Knowledge Base 検索]
C -->|注文照会| E[Tool: 注文検索API]
C -->|配送状況| F[Tool: 物流追跡API]
C -->|工単作成| G[Tool: チケット作成API]
C -->|クレーム/感情的| H[Tool: 人間エスカレーション]
C -->|不明| I[フォールバック: 確認質問]
D --> J[回答生成<br>入力と同じ言語で]
E --> J
F --> J
G --> J
H --> K[人間オペレーターに転送]
I --> J
J --> L[ユーザーへ返答]
工具设计细节
工具列表和定义
Agent 的准确性很大程度上取决于工具描述的质量。抽象的解释不允许LLM选择合适的工具。
工具1:订单搜索
name: search_order
description: |
顧客の注文情報を検索します。
以下の場合に使用してください:
- 顧客が注文番号を提示して状況を確認したい場合
- 顧客が「注文」「購入」「買った」等のキーワードを含む質問をした場合
以下の場合は使用しないでください:
- 注文番号が不明で、顧客が一般的な質問をしている場合
- 返品・返金に関する質問の場合(create_ticket を使用)
parameters:
order_id:
type: string
required: true
description: 注文番号(例: ORD-20260412-001)
工具2:物流追踪
name: track_shipment
description: |
配送状況を追跡します。
以下の場合に使用してください:
- 顧客が「届かない」「配送」「いつ届く」等の配送関連の質問をした場合
- 注文検索の結果、ステータスが「発送済み」の場合
parameters:
tracking_number:
type: string
required: true
description: 追跡番号
工具 3:创建工单
name: create_ticket
description: |
カスタマーサポートチケットを作成します。
以下の場合に使用してください:
- 顧客が返品・返金を希望する場合
- 商品の不具合を報告する場合
- Agent では解決できない問題の場合
parameters:
customer_id:
type: string
required: true
issue_type:
type: string
enum: [return, refund, defect, complaint, other]
required: true
description:
type: string
required: true
description: 問題の概要(日本語で記載)
工具 4:常见问题解答搜索(知识库)
name: search_faq
description: |
FAQ ナレッジベースを検索します。
以下の場合に使用してください:
- 顧客が製品の使い方、仕様、ポリシーに関する一般的な質問をした場合
- 注文や配送に直接関係しない質問の場合
工具 5:人为升级
name: escalate_to_human
description: |
人間のオペレーターにエスカレーションします。
以下の場合に必ず使用してください:
- 顧客が明らかに怒っている、または強い不満を表明している場合
- 法的な言及(訴訟、消費者庁等)がある場合
- 3回以上ツール呼び出しを試みても解決できない場合
- 返金額が50,000円を超える場合
parameters:
reason:
type: string
required: true
priority:
type: string
enum: [normal, high, urgent]
required: true
conversation_summary:
type: string
required: true
description: これまでの会話の要約
设计Agent指令(系统提示)
あなたは多言語カスタマーサポートの AI アシスタントです。
【言語ルール】
- ユーザーが使用した言語と同じ言語で回答してください
- 言語の切替が検出された場合は、新しい言語に合わせてください
- 製品名・ブランド名は原語のまま使用してください
【回答構造】
1. まず結論を述べる
2. 次に根拠や状況を説明する
3. 最後に次のアクションを提示する
【ツール呼び出しルール】
- ツールを呼び出す前に、必要なパラメータが揃っているか確認すること
- パラメータが不足している場合は、推測せずユーザーに確認すること
- 1つの質問に対してツール呼び出しは最大3回までとする
- ツール呼び出しが失敗した場合は、エラー内容をユーザーに伝え、
代替手段を提示すること
【禁止事項】
- 注文のキャンセル・返金の自動実行(チケット作成まで)
- 個人情報(クレジットカード番号等)の取得要求
- 他社製品との比較における他社の誹謗
- 未確認の情報に基づく断定的な回答
【エスカレーション条件】
以下の場合は必ず escalate_to_human を呼び出すこと:
- 顧客の感情が強くネガティブ(怒り、失望、脅し等)
- 法的措置への言及
- 3回のツール呼び出しで解決できない場合
- 自分の回答に自信がない場合
设计后备策略
3 层后备模型
Fallback 是 Agent 无法返回最佳答案时的一种疏散策略。在客户支持中,后备设计是最重要的问题之一,因为“给出错误的响应”比“无法回答”要严重得多。
flowchart TD
A[ユーザーの質問] --> B{ツール呼び出し<br>条件を満たす?}
B -->|Yes| C[ツール呼び出し実行]
B -->|No| D[第1層: Knowledge Base 検索]
C --> E{成功?}
E -->|Yes| F[回答生成]
E -->|No| G[第2層: 確認質問]
D --> H{該当情報あり?}
H -->|Yes| F
H -->|No| G
G --> I{情報取得成功?}
I -->|Yes| C
I -->|No| J[第3層: 人間エスカレーション]
第 1 层:知识库后备
如果不满足调用该工具的条件(无订单号、无发货信息等),请先搜索知识库。如果您可以用常见问题解答、产品规格、政策文档等静态信息来回答,请到此为止。
第 2 层:确认问题回退
如果知识库未提供答案,请向用户询问缺少的信息。
確認質問の例:
- 「注文番号をお教えいただけますか?注文確認メールに記載されています。」
- 「お問い合わせの製品名をお聞かせください。」
- 「いつ頃ご注文されましたか?おおよその日付で構いません。」
重要的是不要调用工具来猜测缺失的信息。如果您使用错误的订单号进行搜索,您将面临返回他人信息的风险。
第 3 层:人为升级
如果出现以下任何情况,请立即上报给人工操作员:
| 条件 | 检测方法 |
|---|---|
| 顾客负面情绪强烈 | LLM 的情感分析 |
| 提及法律诉讼 | 关键词检测+LLM判断 |
| 三个或更多失败的工具调用 | 计算迭代次数 |
| 退款金额超过阈值 | 检查工具返回值 |
| 无法验证身份 | 工具调用结果的差异 |
会话内存管理
内存窗口设计
Dify Agent 节点的 内存 设置允许您控制保留的对话轮数(窗口大小)。设置适当的窗口大小与答案质量和成本/延迟之间的平衡直接相关。
| 场景 | 推荐的窗口尺寸 | 原因 |
|---|---|---|
| 单身常见问题 | 2-3 圈 | 较少依赖于上下文 |
| 订单查询 | 4-6 圈 | 需要提供订单号和产品名称参考 |
| 处理退货和投诉 | 6-8 圈 | 了解流程很重要 |
| 复杂的技术支持 | 8-10 圈 | 步骤的上下文很重要 |
窗口大小权衡
- 如果太大:由于不相关的过去信息,导致令牌成本增加、延迟增加、答案准确性降低
- 如果太小:无法解决您之前提到的问题,再次请求相同的信息。
对于长对话会话,使用“摘要机制”是有效的,该机制将超出窗口大小的对话转换为摘要文本并将其包含在上下文中。
多语言支持的实现点
语言检测和切换
LLM具有自动检测输入语言并以相同语言做出响应的能力。但需要注意以下几点。
| 积分 | 对策 |
|---|---|
| 混合输入(日语/英语等) | 在说明中指定以主要语言回答 |
| 语言切换检测 | 如果使用的语言与上一回合不同,请调整为新语言 |
| 工具输出语言 | 如果 API 响应是英语,请将响应翻译成用户的语言 |
| 专有名词的处理 | 产品和公司名称应以其原始语言使用 |
多语言知识库
| 方法 | 优势 | 缺点 |
|---|---|---|
| 按语言分类的知识库 | 针对每种语言优化的答案 | 维护成本高 |
| 单个 KB(主要语言) | 维护方便 | 小语种搜索准确率下降 |
| 单个 KB + 嵌入的多语言支持 | 良好的平衡性 | 取决于嵌入模型的多语言性能 |
推荐的方法是使用多语言嵌入模型搜索单个知识库(日语+英语)。 multilingual-e5-large和bge-m3等模型支持跨语言的语义搜索。
选择代理策略
函数调用与 ReAct
| 项目 | 函数调用 | 反应 |
|---|---|---|
| 工作原理 | LLM 结构和输出工具调用 | 思考→行动→观察循环 |
| 准确度 | 高(适用于兼容型号) | 取决于型号 |
| 兼容型号 | GPT-4o、Claude、Gemini等 | 大多数LLM |
| 调试 | 可通过工具调用日志进行追踪 | 可视化思维过程 |
| 推荐用途 | 生产经营 | 原型/调试 |
建议在实际客户支持操作中使用函数调用。可以预期工具调用的高精度和可预测的行为。
设置最大迭代次数
限制代理重复工具调用的最大次数。客户支持建议 3-5 次。
- 少于3次:无法回应复杂询问
- 超过5次:无限循环风险、延迟增加、客户等待时间增加
运行监控
要监控的指标
| 指标 | 目标值 | 警报条件 |
|---|---|---|
| 自动解析率 | 60-70% | 一星期低于50% |
| 平均响应时间 | 3秒内 | 超过 5 秒 |
| 升级率 | 20-30% | 超过 40% |
| 工具调用成功率 | 超过95% | 低于 90% |
| 客户满意度 (CSAT) | 4.0/5.0或以上 | 小于 3.5 |
实施步骤
| 相 | 期间 | 内容 |
|---|---|---|
| 第一阶段 | 2 周 | 常见问题解答仅限自动应答。知识库+简单的聊天机器人。 |
| 第二阶段 | 1 个月 | 切换到代理节点。添加了订单搜索和交付跟踪工具。 |
| 第三阶段 | 1-2个月 | 添加了升级票证创建。实施后备策略。 |
| 第四阶段 | 继续 | 扩展多语言知识库。通过分析对话日志改进提示工具。 |
总结
在设计多语言客户支持代理时,语言支持并不是一个差异化因素,因为它可以通过LLM的基本功能来实现。以下三点才是真正考验设计质量的。
- 工具调用链的稳定性:具体描述工具,明确调用条件。
- 清晰的后备策略:三层设计:知识库→审查问题→人员升级
- 正确管理会话内存:根据场景设置Window Size并使用汇总机制
Dify 的代理节点允许您通过 GUI 来配置函数调用/ReAct 选择、工具定义、内存设置和最大迭代次数,为构建企业级客户支持代理提供充分的基础。