中文精炼导读

核心观点

  • 客户体验（CX）正成为 agent 增长最快的应用类别，因为 ROI 相对容易衡量：更快响应提升转化、更少转人工降低单次接触成本、更高解决率留住客户；进入生产后挑战从"构建"转向"改进运营"。
  • 最领先的团队把 agent 当作需要持续测试、部署、监控和迭代的生产系统，并涌现出几类模式：面向消费者的自助服务 agent、一线人员副驾驶（copilot）、非工程师可配置的自助平台、语义路由与分诊、以及把评估（evals）变成跨团队共同语言。
  • 三家标杆企业的硬数据：Lyft 的 AI Assist 每月处理约 27 万次互动、实现 65% 拦截率与 35% AI 解决率，新 agent 开发从约 6 个月缩短到约 2 周；Vodafone 的 Super TOBi 服务近 950 万客户、正确率 90%、解决率 82%；LATAM 的 Concierge 通过加一个客户关怀专家把"超出范围"消息从 13% 降到 1%。
  • 评估是生产化的核心基建：Lyft 构建了"评估飞轮"——离线模拟多轮对话、行为特定规则（rubric）、LLM 评估器与人工校准、上线后用 LangSmith 追踪每次调用，并把失败生产轨迹送进标注队列形成反馈。
  • 最大价值的转变是"对话成为商业智能的来源"：LATAM 的 Compass 管道把 agent 对话、联络中心录音、UX 访谈、法律文档等非结构化来源转化为本体驱动的知识图谱，让每个 agent 都能从其他 agent 学到的东西中受益。
CX Agent 生产化全景
CX Agent 生产化全景

内容精讲

文章先梳理 CX agent 的五个新兴模式。面向消费者的自助服务 agent 最直观：直接与客户对话（文本或语音），处理账单、账户访问、索赔、预约等，价值易于度量。Podium 的 AI Employee 为汽车经销商、暖通承包商等本地企业响应入站线索，数据显示 5 分钟内响应比 1 小时内响应转化率高 46%。一线人员副驾驶是杠杆更高的用例：不直接面对客户，而是与人工代表协作给出"下一步最佳行动"——Cisco 的 CX 组织为网络工程师构建的系统能把数千个潜在发现缩到最关键几个，连模糊的"help"请求都能路由到正确问题。自助服务平台在"工程团队无法再为每个 agent 单独开发"时出现：Lyft 允许运营团队和产品经理用 prompt + 配置文件启动新 agent，无需 ML 工程师参与；Podium 也围绕相同原语构建了类似系统。语义路由与分诊在客户请求不完整或含糊时至关重要——LATAM 的 Concierge 最初 13% 消息被归为"超出范围"，审查后发现其中 95% 是 agent 尚未设计处理的合法乘客需求（值机、行李），加一个客户关怀专家后该比例从 13% 降到 1%。评估成为技术与领域团队的共同语言：更多人参与构建 agent 后，需要一致的方式定义"什么是好行为"并判定能否上线，evals 把领域专长转化为可测试的标准。

Lyft 的案例展示了一个"把支持工程变成自助平台"的系统。Lyft 每月促成 7,900 万次出行，AI Assist 每月处理约 27 万次互动、横跨 7 个以上生产 agent，实现 65% 拦截率与 35% AI 解决率。Lyft 对"解决"设了很高的标准：必须端到端解决问题而非只防止客户转人工——复杂的司机损坏索赔流程包括收集信息和照片、通过工具取数、应用欺诈信号、做决策并向司机解释结果，全程在 15 分钟内。架构是基于 LangGraph 的路由器式多 agent 系统：元 agent（meta-agent）分类每个请求并路由到专门子 agent（骑手/司机分路径）；每个子 agent 本身是一个注册为子图节点的完整 LangGraph 状态图；当意图 agent 中途发现需要更专门的处理（如从通用司机意图转向损坏索赔），就交回控制权给元 agent 重新路由。agent 分两类：专业 agent 由 ML 工程师构建（处理图像、欺诈检测这类高风险流程），可配置 agent 是自助层——运行时用 JSON 配置 + LangSmith Prompt Hub 的 prompt 初始化，可由领域专家而非工程师编写。结果是新 agent 开发时间从首个司机 agent 的约 6 个月缩到约 2 周。

Lyft 的评估飞轮是全文最值得学习的部分。上线前：跑模拟的多轮对话（LLM 扮演客户），用基于代码的断言和 LLM 评估器组合评估轨迹，把"通过评估"作为上线门槛。团队从通用指标转向行为特定的规则（rubric）：早期"响应有用性、对话自然度"这类通用指标无法指导改进，于是和运营、质量专家一起构建了窄而行为特定的通过/失败规则——教育规则检查"能解决时是否给出有用教育内容、明确无法解决时是否升级"，若重复相同教育、未做合理尝试就升级或含事实错误则失败；升级规则定义用户要求人工时的预期行为（应拒绝一次、重复请求后升级），立即升级、第二次请求后拒绝升级、提供必要信息前升级等都判失败。LLM 评估器要与人工审查者校准到足够高的一致性，确保自动化分数反映运营与质量团队的标准。模拟用户也要校准：最初的 LLM 客户"太有教养、耐心、配合"，导致离线通过率超 90% 却反映不了生产行为——Lyft 按真实客户原话微调模拟用户，引入"退款寻求者""AI 怀疑论者""坚决要找到人工的客户"等角色。上线后：用 LangSmith 追踪每次调用（推理、检索内容、调用的工具），判断失败源自路由、上下文、工具还是最终响应；并配置自动化把失败生产轨迹送进标注队列，产品经理和质量审查员用自由文本标记失败模式，把个别糟糕互动转化为结构化产品洞察，再反馈到 prompt、工作流、数据集和未来的离线测试。下一步是更标准化的评估框架（版本化的任务/数据集/角色/评分器原语）、回归测试，以及长期把成功轨迹用作监督微调（SFT）示例。

Vodafone 的 LLM Compiler 工作流时间线
Vodafone 的 LLM Compiler 工作流时间线

Fastweb + Vodafone 为意大利数百万电信客户服务，选了 LangGraph + LangChain 作为基础（客户服务流程天然映射为基于图的决策流），构建了两个旗舰 agent。面向客户的 Super TOBi 服务近 950 万客户（客户伴侣应用 + 语音渠道），正确率 90%、解决率 82%、客户努力度 5.2/7，帮助减少响应时间和转人工。架构是两类 LangGraph agent：监督员作为每个请求的入口，应用护栏、校验、塑造输入，处理问候、结束对话、转人工等常见场景后路由到合适的用例 agent；专业用例 agent 负责特定类别需求、可访问一组 API，遵循 LLM Compiler 模式——决定调用哪些 API、协调多步骤计划、生成针对客户上下文的响应，部分用例 agent 还能返回结构化动作标签，让聊天机器人直接在对话里完成交易（激活优惠、禁用服务、更新支付方式）。面向内部的 Super Agent 帮助把一次性解决率提到 86% 以上：把运营知识存在 Neo4j 活图里，业务专家写结构化模板，LangGraph 构建的自动化管道解析文档、识别每步需要的 API、检查流程一致性，CI/CD 管道让更新流程数小时上线无需停机；运行时监督员决定匹配结构化流程还是开放式回答，结构化路径逐步调用 API 测试条件直到找到问题，开放路径走"向量库 + 知识图谱"混合检索，让答案锚定在正确业务上下文并附来源引用。他们还从第一天就上 LangSmith："没有深度可观测性，你无法在生产中运行 agent 系统。"每日评估流程是：收集 LangSmith 数据集轨迹 → 夜间用 Evaluators SDK 自动评估 → 输出分数（1-5）、解释和违反的指南。

LATAM Airlines（拉美最大航司，年运 8,700 万乘客，利润率仅 3%-5%，燃料占每 1 美元运营成本约 31 美分）构建在内部 Cosmos AI 平台上，该平台用 LangSmith 提供基础设施、CI/CD、模型访问、可复用模板与可观测性，支撑超过 120 个生成式 AI 产品、20 个业务领域。面向客户的 Concierge 是旅行规划 agent：beta 首月 52,000 用户，生产一年多后约 4,000 日活。架构最初是分诊 agent 模式，但生产追踪显示约 15% 的延迟和 token 开销来自重复的结构化输出——团队重构为监督员保持控制、只在返回最终响应前结构化一次输出，在保持输出质量的同时降本约 15%。它从生产对话中发现的问题正是前文说的"13% 超出范围消息"案例：加客户关怀专家后该比例降到 1%，回访率还提高了 6%，现在约 12% 的每日消息由该 agent 处理。内部知识提取系统 Compass 是一个本体驱动的管道，把非结构化来源（agent 对话、UX 研究访谈、联络中心通话、法律文档）转化为存进 BigQuery Graph 的结构化知识：解析器为模型准备多模态输入，映射器用 Gemini 识别领域本体定义的实体与关系，建模器写入知识图谱；本体注册表定义每个领域提取什么，评估层衡量语义提取质量。同一管道通过换本体支持截然不同的用例（UX 痛点 vs 法律合同条款），模型可替换而本体是公司专有资产。成效：一个 UX 研究工作流把处理时间从数周缩到数天，活跃用例本体覆盖率约 85%-98%、处理约 8,000 份文档、成本降到每份约 1 美分。选型上他们评估过 Spanner Graph 但最终选 BigQuery Graph——数据都在 BigQuery，避免联合查询和额外延迟，"生态系统现实比技术纯粹性更重要"。

文章最后总结了 CX 构建者关注的五个主题：随着 agent 开发扩展到工程之外，prompt 质量成为瓶颈（需要结构化框架与自动化检查）；可观测性必须在反馈到来之前就位（Cisco 甚至建了分诊 agent 从 LangSmith 的 MCP 服务器拉失败 trace、自动开 Jira 工单）；架构往往是通过生产使用"发现"出来的（LATAM 的 15% 开销、Lyft 的路由器架构都是响应约束演化而来）；最大的价值在 agent 成为工作流一部分时出现（从聊天机器人变成有委派任务与工作流责任的"队友"）；对话正成为商业智能的来源。结论是：CX 最重要的转变是交互现在可以被持续观察、评估和改进——agent 的价值不仅来自它今天能处理的对话，还来自系统如何从这些互动中学习并随时间改进。

阅读价值

适合 CX 平台团队、负责客户支持 AI 化的产品与工程负责人，以及所有在把 agent 推向生产的人：文章用 Lyft、Vodafone、LATAM 三家的真实架构与硬数据，覆盖了评估飞轮、可观测性驱动改进、知识图谱、架构演进（triage → supervisor）等生产化必需的全部环节；其中 Lyft 的 evals 方法论和 LATAM 的"从生产追踪发现架构问题"尤其值得直接借鉴。

阅读英文原文 → 返回 AI 技术文档

本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.langchain.com/blog/customer-experience-cx-agents-in-production-lessons-from-lyft-vodafone-and-latam-airlines