我们最新的指南《生产环境中的客户体验智能体》探讨了@Lyft、@fastwebvodafone和@LATAMAirlines如何构建能够解决客户请求、辅助一线团队并通过生产反馈不断改进的智能体。

阅读指南：https://t.co/WUeBmN8Q9v

生产环境中的客户体验（CX）智能体

来源：https://www.langchain.com/resources/customer-experience-cx-agents-in-production 客户体验已成为智能体发展最快的类别之一，部分原因在于其投资回报率相对容易衡量。更快的响应可以提升转化率，更少的升级可降低单次联系成本，而更高的解决率有助于留住客户。

随着CX智能体进入生产环境，挑战从构建它们转向改进它们的运作方式。团队正在从真实交互中学习，优化智能体行为，并判断对话何时应转变为结构化工作流。他们也越来越倾向于利用这些交互来改善更广泛的客户体验。

走在前列的团队将智能体视为生产系统，需要持续测试、部署、监控和迭代。本文探讨了这一方法在三家公司中的具体实践：

• Lyft，构建了一个自助服务平台，使非技术运营团队和产品经理能够配置和部署支持智能体
• Fastweb + Vodafone，构建了Super TOBi和Super Agent，以同时支持面向客户的对话和内部呼叫中心团队
• LATAM Airlines，构建了旅行协助智能体Concierge，以及将非结构化对话转化为结构化信号的Compass系统

结合Cisco和Podium的其他案例，我们将探讨客户体验领域涌现的用例、团队在生产中遇到的技术与运营挑战，以及LangSmith、Deep Agents和LangGraph如何在智能体开发生命周期（https://www.langchain.com/blog/the-agent-development-lifecycle）中支持持续改进。

客户体验智能体中的新兴模式

面向消费者的自助服务智能体通常是最显眼的起点。它们通过聊天或语音直接与客户交互，帮助处理账单、账户访问、理赔和预约安排等任务。其价值相对容易衡量：更快的响应可提升转化率，而更高的解决率可减少升级并降低支持成本。例如，Podium的AI Employee会响应汽车经销商、暖通空调承包商和其他本地企业的入站线索。对这些企业而言，五分钟内响应相比一小时内响应能带来高出46%的线索转化率。

**一线人员和客服坐席副驾（copilot）**可能是杠杆效应更高的用例。这些智能体不直接与客户对话，而是与人工坐席协同工作，呈现下一个最佳行动。Cisco的CX组织将这种方法用于网络工程师。其系统将数千个潜在发现缩小到少数几个最关键的项，因此即使是“帮助”这样模糊的请求也能被路由到正确的问题。

自助服务平台在工程团队无法再为每个智能体单独构建时出现。Lyft的平台允许运营团队和产品经理创建提示词和配置文件，无需机器学习工程师参与即可启动新的支持智能体。Podium围绕其内部使用的相同原语构建了类似的系统。这使得一个底层架构能够支持从汽车销售到暖通空调保修支持的各种用例。

语义路由与分诊在客户请求不完整或含糊时变得至关重要。LATAM航空在Concierge中体会到了这一点。最初，13%的消息被归类为超出范围。在审查对话后，团队发现其中95%是智能体尚未被设计处理但确实存在的乘客需求，包括值机和行李问题。增加一位客户关怀专员后，超出范围率从13%降至1%。

**评估（Evals）成为技术和领域团队之间的共同语言。**随着越来越多人参与构建智能体，团队需要一种一致的方式来定义良好行为的标准，并判断智能体是否准备好上线。评估将领域专业知识转化为具体的、可测试的标准，工程师、产品经理和运营团队可以用它们来审查性能并指导改进。

Lyft在向非工程师开放智能体开发后遇到了这一点。平台不再是主要约束；提示词和评估质量才是。团队引入了结构化的提示词编写框架和自动化检查，以在矛盾指令和不完整对话路径进入生产环境之前将其拦截。

这些模式共同表明，一旦CX智能体进入生产环境，工作性质就会发生变化。以下三个团队展示了组织如何设计、评估和规模化改进这些系统。

三个拥有生产环境CX智能体的团队

Lyft：将支持工程转变为自助服务平台

Lyft的AI Assist为乘客和司机处理账户访问、损坏索赔、费用复核和收入争议等问题。Lyft所承载的行程量决定了其需要智能体系统来提供支持。Lyft每月促成7900万次行程，而AI Assist每月处理约27万次交互，涉及七个或更多生产智能体。该系统实现了65%的拦截率（deflection rate）和35%的AI解决率。

Lyft有意设置了很高的解决标准，要求智能体端到端地解决问题，而不仅仅是阻止客户转接人工。对于司机损坏索赔等复杂工作流，这可能包括收集信息和照片、通过工具检索数据、应用欺诈信号、做出决策，并向司机解释结果（所有这些都需在15分钟内完成）。

智能体架构

Lyft当前系统采用基于路由器的多智能体架构，构建于LangGraph之上。一个元智能体对每个传入请求进行分类，并将其路由到专门的子智能体，乘客和司机各有独立的路径。每个子智能体本身都是一个完整的LangGraph状态图，作为子图节点注册。

当意图智能体在对话中途发现请求需要更专业的处理器时（例如从通用司机意图智能体切换到损坏索赔智能体），它会将控制权交还给元智能体进行重新路由。这避免了对话被强行导入错误路径。

Lyft将其智能体分为两类：

• 专业智能体由机器学习工程师构建，用于复杂、高风险的流程，例如涉及图像处理和欺诈检测的损坏索赔
• 可配置智能体是自助服务层。它们在运行时使用JSON配置和来自LangSmith Prompt Hub的提示词进行初始化，提示词可以由领域专家而非工程师编写

这种方法将智能体开发所需时间从Lyft首个司机智能体的大约六个月缩短到新可配置智能体的大约两周。

Lyft如何构建评估

随着平台变得易于使用，提示词和评估质量开始成为瓶颈。

Lyft构建了一个将开发与生产连接起来的评估飞轮。上线前，团队会运行模拟的多轮对话，其中LLM扮演客户与智能体交互。每个模拟都围绕一个任务、用户角色和环境来定义，以反映智能体在生产中可能遇到的情况。由此产生的轨迹可以使用基于代码的断言和LLM评判器（judge）相结合的方式进行评估，包括智能体是否给予了正确的让步、是否适当升级、是否在预期的轮数内解决了问题。

离线场景的多样性很重要。Lyft将离线评估作为上线门槛，使团队能够快速行动，而不必将真实客户当作测试用例。智能体只有达到所需的质量阈值，才能进入生产环境。

团队很早就认识到，通用的评估指标是不够的。诸如响应有用性、对话自然度、工具使用适当性和对话完整性等初始指标虽然能产生分数，但无法告诉团队应该改变什么。

Lyft转而与运营和质量专家合作，基于支持交互实际应如何展开，构建了细粒度、针对特定行为的评分标准。团队还从宽泛的标量分数转向更简单的通过/失败结果。

例如，一个“教育”评分标准会检查智能体在能够解决问题时是否提供有用的教育内容，但在明确无法解决时是否升级。如果智能体重复相同教育内容太多次、在做出合理尝试帮助之前就升级，或包含事实错误，则判定失败。

另一个“升级”评分标准定义了当用户要求转接人工时的预期行为。智能体应首先拒绝一次，然后在用户再次请求后升级。如果它立即升级、在第二次请求后拒绝升级、在提供必要信息之前就升级，或在明确无法帮助后仍继续多轮，则判定失败。

这些评分标准比通用质量分数更有用，因为每个失败都指向特定的产品、提示词或工作流更改。

Lyft还将其LLM评判器与人工审核者进行校准。团队收集人工标签，并反复迭代每个评判器，直到达到足够高的一致率。这让团队相信自动化分数能够反映其运营和质量团队本会应用的标准。

模拟用户也需要同样程度的校准。Lyft最初由LLM生成的客户过于清晰、耐心且配合，导致离线通过率超过90%，但这并不能反映生产环境中的行为。真实用户往往写得支离破碎、省略上下文、重复自己，或带着特定目标而来，例如拿到退款或绕过智能体。

为了使离线评估更贴近现实，Lyft基于真实客户原话对模拟用户进行了微调，并引入了诸如“退款追寻者”“AI怀疑论者”以及“一心想转人工的用户”等角色。让模拟客户不那么“完美”使评估变得更难，但也让离线结果对生产性能更具预测性。

智能体上线后，同样的评估循环会在在线环境中继续。每次调用都会在LangSmith中跨开发、预发布和生产环境进行追踪，包括智能体的推理、它检索到的教育内容以及它调用的工具。这使得团队能够判断故障来自路由、上下文、工具执行还是最终响应。

LangSmith还使评估过程对机器学习团队之外的人变得可访问。产品经理和运营专家可以直接定义通过/失败标准、编写评分标准并配置LLM评判器。这让最了解支持体验的人进入评估过程，而不是要求工程师为他们翻译每一条需求。

Lyft配置了自动化机制，将失败的生产轨迹发送到标注队列（https://docs.langchain.com/langsmith/annotation-queues）。产品经理和质量审核员随后用自由文本标记失败模式，将一个个糟糕的交互转化为结构化的产品洞察。这些发现会反馈到提示词、工作流、数据集和未来的离线测试中。

下一步

团队现在正在努力构建更标准化的评估工具集。目前，许多离线测试仍然是以一次性脚本或笔记本的形式开始。Lyft希望用带版本管理的原语（例如任务、数据集、角色和评分器）替换它们，以便团队可以共享并自动运行。

这将使得每次提示词更改都能进行回归测试、在相同场景下比较模型，并维护一个易于增长的评估集。

随着时间的推移，Lyft还认为这些轨迹将不仅仅是评估数据。成功的轨迹可以成为监督微调的示例。长期目标是让生产反馈不仅改进模型周围的提示词和工作流，还能改进模型本身。

%402x%201.png)

Lyft带来的更广泛启示是：向更多人开放智能体开发并不会消除对严谨性的需求，而是将这种严谨性转移到提示词创建、评估和生产反馈的周边系统中。自助服务平台使智能体构建更快，而评估飞轮使它们能够安全上线，并随着时间推移稳步改进。

了解更多：Lyft用户案例（博客（https://www.langchain.com/blog/lyft-built-a-self-serve-ai-agent-platform-for-customer-support-with-langgraph-and-langsmith）），Lyft Interrupt演讲（YouTube（https://www.youtube.com/watch?v=UVeeNW_z068））

Fastweb + Vodafone：两个智能体驱动客户体验

Fastweb + Vodafone隶属于Swisscom集团，为意大利数百万电信客户提供服务。这种规模下的客户服务涉及广泛的需求，从账单、漫游到服务激活和技术支持，而且客户往往期望一次性解决。

其现有聊天机器人TOBi能够处理简单的请求，但更复杂的案例需要更深入的上下文、访问多个系统，并协调多个步骤。呼叫中心顾问在内部也面临类似挑战：他们需要快速了解客户历史、识别问题，并在多个系统和知识源中确定正确的下一步行动。

Fastweb + Vodafone着手支持体验的两端：一个能够端到端解决更复杂请求的面向客户智能体，以及一个能够帮助顾问更快、更一致工作的内部智能体。

智能体架构

Fastweb + Vodafone选择LangGraph和LangChain作为其AI转型的基础，因为其客户服务流程自然映射为基于图的决策流程。其实现围绕两个旗舰项目展开：Super TOBi和Super Agent。

Super TOBi

Super TOBi是Fastweb + Vodafone现有聊天机器人的智能体进化版。它现在为Customer Companion App和语音渠道的近950万客户提供服务，处理成本控制、活跃优惠、漫游、销售和账单等用例。

该系统实现了90%的正确率、82%的解决率，以及5.2分（满分7分）的客户努力度评分，帮助缩短了响应时间和转接人工的次数。

其架构围绕两类LangGraph智能体组织：一个Supervisor和一组专门的Use Case智能体。

Supervisor是每个请求的入口。它应用防护措施，验证并格式化输入，并处理常见场景，如问候、对话结束和转接人工操作。然后它会将请求路由到适当的Use Case智能体，或在意图不明确时提出澄清问题。

每个Use Case智能体负责特定类别的客户需求，并可访问一组已定义的API。遵循LLM Compiler模式，它可以决定调用哪些API、协调多步骤计划，并根据客户上下文生成响应。

某些Use Case智能体还可以返回结构化动作标签，而不仅仅是自然语言响应。这些标签使聊天机器人能够在对话循环中执行特定操作，例如读取OTP、管理计费流程，或与后端系统交互以完成请求。