生产环境对话揭示了原始代理未曾设想到的客户需求。

LATAM航空发现，13%发送给其礼宾代理的消息被归类为超出范围。在审查生产追踪记录后，团队发现其中95%实际上是乘客的合理需求。

增加一位客服专家后，超出范围率从13%降至1%，回复率提高了6%。

了解LATAM航空和其他客户体验团队如何利用生产反馈来改进代理表现：

生产环境中的客户体验代理

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

随着客户体验代理投入生产，挑战从构建转向了如何改进其运作方式。团队从真实交互中学习，完善代理行为，并决定何时将对话转化为结构化工作流。他们越来越多地利用这些交互来改善更广泛的客户体验。

进展最快的团队将代理视为需要持续测试、部署、监控和迭代的生产系统。本文探讨这种方法在三家公司中的实践：

• Lyft构建了一个自助平台，允许非技术运营团队和产品经理配置和启动支持代理
• Fastweb + Vodafone构建了Super TOBi和Super Agent，以支持面向客户的对话和内部呼叫中心团队
• LATAM航空构建了旅行辅助代理Concierge，以及一个将非结构化对话转化为结构化信号的系统Compass

结合来自Cisco和Podium的额外示例，我们将探讨客户体验领域出现的用例、团队在生产中遇到的技术和运营挑战，以及LangSmith、Deep Agents和LangGraph如何支持代理开发生命周期(https://www.langchain.com/blog/the-agent-development-lifecycle)中的持续改进。

客户体验代理的新兴模式

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

一线人员和代表副驾驶可能是更高杠杆的用例。这些代理不是直接与客户交谈，而是与人工代表一起工作，并提示最佳下一步行动。Cisco的客户体验组织为网络工程师使用这种方法。其系统将数千个潜在发现缩小到少数几个最重要的发现，因此即使是“帮助”这样模糊的请求也能被引导到正确的问题。

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

语义路由和分诊在客户请求不完整或模糊时变得至关重要。LATAM航空在礼宾代理上遇到了这种情况。最初，13%的消息被归类为超出范围。审查对话后，团队发现95%是代理尚未设计来处理的合理乘客需求，包括值机和行李问题。增加一位客服专家后，超出范围率从13%降至1%。

**评估成为技术团队和领域团队的共同语言。**随着越来越多的人参与构建代理，团队需要一种一致的方法来定义良好行为是什么样子，并确定代理是否准备好发布。评估将领域专业知识转化为具体的、可测试的标准，工程师、产品经理和运营团队可以使用这些标准来审查性能并指导改进。

Lyft在向非工程师开放代理开发后遇到了这个问题。平台不再是主要限制；提示和评估质量成了瓶颈。团队引入了结构化的提示编写框架和自动化检查，以便在生产环境之前捕获矛盾的指令和不完整的对话路径。

这些模式共同展示了当客户体验代理投入生产后工作如何变化。以下三个团队说明了组织如何大规模设计、评估和改进这些系统。

三个拥有生产环境客户体验代理的团队

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

Lyft的AI助手支持乘客和司机处理账户访问、损坏索赔、费用审核和收入纠纷等问题。Lyft每月促成7900万次行程，因此需要代理系统进行支持。AI助手在七个或更多生产代理中每月处理约27万次交互。该系统实现了65%的偏转率和35%的AI解决率。

Lyft对解决率设定了有意的高标准，要求代理端到端解决问题，而不仅仅是阻止客户联系人工。对于司机损坏索赔等复杂工作流程，这可能包括收集信息和照片、通过工具检索数据、应用欺诈信号、做出决定并向司机解释结果（全部在15分钟内完成）。

代理架构

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

当意图代理在对话中途确定请求需要更专业的处理程序（例如，从通用司机意图代理转向损坏索赔代理）时，它会将控制权返回给元代理以进行重新路由。这可以防止对话被强制引导到错误路径。

Lyft将其代理分为两类：

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

这种方法将代理开发时间从Lyft第一个司机代理的大约六个月减少到新可配置代理的大约两周。

Lyft如何构建评估

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

Lyft构建了一个连接开发和生产的评估飞轮。在发布之前，团队运行模拟的多轮对话，其中LLM扮演客户角色与代理对峙。每个模拟都围绕任务、用户角色和环境定义，反映代理在生产中可能遇到的情况。生成的轨迹可以使用基于代码的断言和LLM评判器的组合进行评估，包括代理是否授予了正确的让步、适当地升级，或在预期的回合数内解决问题。

这些离线场景的多样性很重要。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中断谈话（YouTube (https://www.youtube.com/watch?v=UVeeNW_z068)）

Fastweb + Vodafone：两个代理驱动客户体验

Fastweb + Vodafone是瑞士电信集团的一部分，为意大利数百万电信客户提供服务。如此规模的客户服务涉及广泛的需求，从计费和漫游到服务激活和技术支持，通常客户期望在单次交互中解决问题。

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

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

代理架构

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

Super TOBi

Super TOBi是Fastweb + Vodafone现有聊天机器人的代理演进。它现在在客户伴侣应用和语音渠道中服务于近950万客户，处理成本控制、活跃优惠、漫游、销售和计费等用例。

该系统实现了90%的正确率、82%的解决率和5.2/7的客户努力得分，有助于减少响应时间和转接人工操作员。

其架构围绕两种类型的LangGraph代理组织：一个主管和一组专门的用例代理。

主管是每个请求的入口点。它应用防护措施，验证和塑造输入，并处理常见场景，如问候、对话结束和转接人工操作员。然后它将请求路由到适当的用例代理，或者在意图不清晰时提出澄清问题。

每个用例代理负责特定类别的客户需求，并有权访问一组定义的API。遵循LLM编译器模式，它可以确定哪些