Yuxu Ge
文章 · 2024-03-11

打造具备行动力的智能客服：用 Agent 让大模型接入真实系统

RAG 解决"知识获取"，微调/数据增强提升"语言与领域适应"，而 Agent 赋予"操作执行"能力。这几种技术往往可以组合使用：在实际应用中，一个智能客服系统可能同时用到 RAG 获取最新产品信息，微调提升对客户问题的理解，而 Agent 处理复杂的售后操作。但在需要模型与数据库或业务系统集成、完成事务型任务时，Agent 是最合适的扩展方式。

智能客服平台的 Agent 操作示例

为更直观地了解 Agent 如何工作，我们以智能客服平台的常见需求为例，展示每种需求下 Agent 如何对接系统接口，实现从用户提问到后台操作再到回复结果的流程：

场景1：查询订单状态

用户可能会询问："我上周下的订单现在到哪儿了？" 传统 FAQ 式机器人只能给出预设回答或让用户自行查询。引入 Agent 后流程如下：

  1. 意图理解：模型识别出用户的意图是"查询订单状态"，并提取关键信息（如订单号或下单时间段）。如果用户未提供订单号，Agent 可以追问获取。
  2. 函数调用：Agent 决定调用后端提供的订单查询接口，例如 getOrderStatus(order_id) 函数。它会生成对应的函数调用请求，将订单号作为参数传递。OpenAI 的函数调用机制允许模型自动生成 JSON 格式的参数来调用预定义函数。
  3. 系统查询：后台接收到 getOrderStatus 调用后，查询数据库或调用内部服务获取该订单的当前状态（如"已发货，在途"），然后将结果返回给 Agent。
  4. 结果生成：Agent 将订单状态信息融入自然语言回复给用户。例如："您的订单目前状态是已发货，预计两天内送达。" 用户得到的是直接的答案，但这背后是模型通过 Agent 调用了实时的数据。

实现提示：在系统消息中明确指导模型遇到订单查询类请求时使用 getOrderStatus 函数，有助于提高调用准确性。例如提示："如果用户问订单状态（如'我的订单到哪了'），请调用订单状态检查接口查询。"

场景2：修改个人信息

假设用户说："我要把账号绑定的手机号码改成新的号码，可以帮我修改吗？"

  1. 意图解析：Agent 明确用户希望更改账户手机号。这属于需要鉴权的敏感操作。
  2. 身份验证：在调用真正的修改接口前，系统应验证用户身份（例如确保用户已登录会话，并有权限修改该账户信息）。Agent 可以提示用户通过验证码确认，或者系统直接利用会话中的认证信息。
  3. 函数调用：Agent 调用诸如 updateUserPhone(user_id, new_phone) 的函数，并传入用户 ID（或会话上下文中的身份标识）和新手机号。由于涉及安全，Agent 不会直接持有用户密码，而是利用后台安全模块执行此操作——遵循"最小权限"原则，只授予 Agent 所需的操作权限。
  4. 执行更新：后台接口验证权限后，修改数据库中用户的手机号，返回操作是否成功的结果（或新的联系方式记录）。
  5. 反馈用户：Agent 根据接口返回，生成回答："好的，您的手机号已更新为 XXX。如非本人操作请及时联系客服。" 若接口返回错误（比如格式不符或权限不足），Agent 则礼貌地告知用户失败原因，并提供进一步帮助建议。

场景3：提交退款申请

用户提出："我想退掉昨天买的商品，订单号12345，怎么申请退款？" 退款流程往往涉及多步操作：

  1. 意图识别：Agent 判断用户要对指定订单发起退款。它可能需要先确认订单状态（是否已发货或完成交付）以决定下一步。
  2. 检查订单：Agent 可能首先调用 getOrderStatus(order_id) 获取订单状态。如果结果显示订单已完成或已发货，则按照业务规则继续退款流程。
  3. 调用退款接口：Agent 使用退款相关的函数，如 requestRefund(order_id, reason)。参数包括订单号和退款原因（从用户描述中提取，若未提供可追问）。这个调用会在后台创建退款工单或触发退款流程。
  4. 结果处理：退款接口返回受理结果，例如退款申请单号或处理状态。Agent 将此信息转述给用户："您的订单退款申请已提交，单号为 XXXX，我们将在3个工作日内处理，退款将原路返回至您的支付账户。"
  5. 异常情况：如果退款接口返回错误（如订单不支持退款、超过退款期限等），Agent 应该识别这些信息，并向用户解释原因（避免直接暴露错误代码）以及提供替代方案（如联系人工客服）。

通过以上示例可以看到，每当用户提出操作型请求时，Agent 都充当了"大脑"和"桥梁"的角色：由模型决策选择调用哪个后端接口，再由系统执行实际操作，将结果交给模型组织语言回复用户。整个过程对用户是透明的，他们体验到的只是一个更智能、更有用的客服助手。

Agent 的实现方法：LangChain 与 OpenAI Function Calling

要让模型具备上述 Agent 能力，开发者可以利用现有框架和 API 来实现"模型调用函数"的机制。当前比较流行的两种途径是使用 LangChain 框架的 Agent 或 OpenAI 的函数调用(Function Calling)接口。下面介绍这两种方法如何实现让模型对接本地函数或外部 API：

基于 LangChain 的 Agent 实现

LangChain 提供了丰富的 Agent 模板，用于让 LLM 调用开发者提供的工具。典型实现步骤：

  1. 定义工具：将可用的函数或接口封装为 LangChain 的 Tool 对象，包括名称、功能描述和实际执行函数。例如，我们定义一个查询订单状态的工具：
from langchain.agents import Tool

def get_order_status(order_id: str) -> str:
    # 查询数据库或调用API获取订单状态
    status = ...  
    return status

order_tool = Tool(
    name="get_order_status",
    func=get_order_status,
    description="根据订单ID查询订单当前状态（如待发货、运输中、已送达）"
)

类似地，可以定义修改手机号、提交退款的工具，并适当在描述中注明何时使用该工具。

  1. 初始化 Agent：选择一个 LLM（如 GPT-4）作为决策大脑，指定 Agent 类型（ZeroShotReactDescription 等）和工具列表。LangChain 会在幕后构造提示，让模型按需调用工具。例如：
from langchain.agents import initialize_agent, AgentType
from langchain.chat_models import ChatOpenAI

llm = ChatOpenAI(model_name="gpt-4")
agent = initialize_agent([order_tool, update_phone_tool, refund_tool], llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)

AgentType.ZERO_SHOT_REACT_DESCRIPTION 指一种经典的 ReAct Agent 方法，即模型通过思考（Thought）→ 行动（Action）→ 观察结果（Observation）→ 思考… 迭代，直到得出最后答案。LangChain 会将工具的描述提供给模型，模型以格式化输出决定调用哪个工具和传入何种参数。

  1. 运行对话：将用户问题传给 Agent，例如 agent.run("查询订单12345的配送状态")。模型收到带有工具说明的上下文，会产生类似："Thought: 我需要查询订单状态\nAction: get_order_status\nAction Input: 12345"的决策。LangChain 捕获到模型意图，调用对应函数 get_order_status("12345")，获取结果如"已发货，快递在途中"。然后将结果再反馈给模型作为 Observation，模型据此生成最终答案："您的订单12345已发货，目前快递在途中"。这一切对开发者是透明的，LangChain Agent 帮我们完成了决策流程的管理。

LangChain 的优势是封装了 Agent 决策逻辑，开发者只需提供工具集合和基础 Prompt。它还支持记忆机制，方便多轮对话中保留上下文。不过需要注意为每个工具撰写清晰的描述，避免模型误用工具或调用失败。同时 LangChain 的 Agent 属于第三方库实现，其提示工程和决策流程可调整的空间较大，需根据模型表现反复调优。

基于 OpenAI 函数调用的实现

OpenAI 提供了内置的函数调用机制，使得模型能够按规范返回一个函数调用请求，开发者再执行该函数并将结果反馈给模型。实现步骤如下：

  1. 定义函数及描述：在后端实现所需的实际函数，例如查询订单的 get_order_status(order_id)，退款申请的 request_refund(order_id, reason) 等。然后按照 OpenAI API 要求，用 JSON Schema 描述每个函数的参数和用途。例如，定义查询订单函数的描述：
{
  "name": "get_order_status",
  "description": "根据订单ID获取订单状态。如用户问“我的订单到哪了”时调用此函数查询。",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单号"
      }
    },
    "required": ["order_id"]
  }
}

上述描述包含函数名、用途说明，以及参数的 JSON 模式（模型会依据这里的约束来填充参数）。

  1. 调用 ChatCompletion API：在与 OpenAI 的对话请求中，传入上述函数定义列表以及用户消息。以 Python 库为例：
functions = [ ... 上面定义的各函数schema ... ]
messages = [
  {"role": "system", "content": "你是一个智能客服助手，请帮助用户解决问题。"},
  {"role": "user", "content": "请问我的订单12345现在什么状态？"}
]
response = openai.ChatCompletion.create(
    model="gpt-4-0613",
    messages=messages,
    functions=functions,
    function_call="auto"    # 模型可以自主决定是否调用函数
)

OpenAI 模型收到函数列表和对话内容后，如果判断需要查询订单，就会在回答中返回一个特殊的函数调用响应，例如：

{
  "role": "assistant",
  "content": null,
  "function_call": {
    "name": "get_order_status",
    "arguments": "{ \"order_id\": \"12345\" }"
  }
}

这表示模型选择调用 get_order_status，并填充了参数。

  1. 执行函数并反馈结果：我们的应用收到上述响应后，解析出需要调用的函数名称和参数，然后实际调用 get_order_status("12345")。假设获得结果 {"status": "已送达"}。接下来，我们将这个结果作为一个新的消息传回模型：
follow_up_message = {
  "role": "function",
  "name": "get_order_status",
  "content": "{\"status\": \"已送达\"}"
}
follow_response = openai.ChatCompletion.create(
    model="gpt-4-0613",
    messages=messages + [response.choices[0].message, follow_up_message]
)

模型会将函数返回值纳入考虑，生成最后给用户的回答，例如："您的订单12345已经送达。如有其他问题，请随时联系。"

在这个过程中，模型从未直接执行任何后台代码，而只是提出调用意图和参数，由外部应用完成实际操作，因此应用始终保持对关键事务的掌控权。OpenAI 函数调用的优点是接口规范统一、模型行为可预测，尤其在 functions 中提供严格的参数模式（OpenAI 还支持严格模式 strict 验证参数结构），可以减少模型生成无效参数的情况。开发者也可以通过检查 function_call 的内容，在执行前做最后的验证和安全检查。

对比：LangChain Agent 更偏向高层封装和跨工具的灵活决策，适合快速集成各种类型的工具（包括搜索、计算等）；OpenAI 函数调用则提供了一种更底层和精细控制的方法，将函数调度纳入模型推理流程的一部分，易于调试和与现有后端集成。两种方式都可以达到让模型调用 API 的目的，可根据项目偏好选择。事实上，LangChain 也可以结合 OpenAI 函数调用，使两者优势相得益彰。

安全控制与权限机制

让模型具备"行动力"的同时，必须重视安全边界和权限控制，确保系统可靠不滥用。以下是几项关键的安全机制与策略：

通过以上多层防护，我们既赋予了智能客服 Agent 行动能力，又将误用风险降到最低。例如，OpenAI 函数调用模式下应用程序始终有机会拦截并审核模型请求，再决定是否执行。安全机制确保 Agent"有所为有所不为"，只能在授权范围内代替用户行动，一旦越界就会被拒绝或交由人工处理。

部署中的挑战与优化策略

在将 Agent 集成方案付诸实际部署时，还会遇到一些实战挑战。下面列举几个常见问题及相应的优化策略：

通过针对上述挑战采取相应的优化策略，我们可以大幅提高智能客服 Agent 的可靠性和用户体验。例如，精心设计的工具描述和提示可以让模型正确率显著提高；完善的记忆和错误处理让对话更加流畅连贯。最终，部署成功的 Agent 将如同一名高效的数字客服专员，既能对答如流，又能即时办理业务，真正实现让大模型为业务赋能。

结语

在这篇文章中，我们探讨了如何通过 Agent 技术，让大语言模型接入真实系统，从而打造一个具备行动力的智能客服。我们分析了 Agent 相对于 RAG、微调、数据增强等方案的独特价值，演示了在客服场景下 Agent 处理查询订单、修改信息、退款等操作的过程，并介绍了基于 LangChain 和 OpenAI 函数调用两种实现方式。同时，我们重点讨论了安全权限控制措施，确保 Agent 在赋能的同时不失控，并分享了实际部署中遇到的挑战和优化经验。

借助 Agent，一个原本只能"回答问题"的客服 AI 升级为可以"解决问题"的强大助手：它连接了用户与后端系统，让对话不再停留于表面回答，而是能够直接执行操作达成用户目标。这种范式正是下一代智能客服系统的方向。当然，部署 Agent 也需要我们在系统架构和安全方面投入更多思考和努力。但可以预见，随着 OpenAI 等生态的完善，以及业界最佳实践的丰富，Agent 将在各行业客服平台中扮演越来越关键的角色，推动人机交互从单纯问答迈向对话即服务的新阶段。

© 2026 Yuxu Ge ·