Lyft 如何用 LangGraph 和 LangSmith 构建自助式 AI 智能体客服平台

这是一篇来自我们朋友 Lyft 的客座文章，Lyft 的 SCX 数据科学与 MLE 团队构建了一个多智能体客户支持系统，使非技术领域的专家也能交付 AI 智能体。由机器学习工程师 Akshay Sharma 领导。感谢你们的贡献。

TL;DR

通过利用 LangGraph 编排一个精密的多智能体系统，Lyft 已经转型了其客户支持运营，为乘客和司机管理着数百万次交互。我们的“自助式”平台将 LangGraph 的子图架构与 LangSmith 强大的追踪和监控工具集成在一起，赋能非技术领域的专家独立开发和优化 AI 智能体。这一转变将智能体开发从大约六个月加速到仅需几周，同时通过自动化的 LLM-as-a-judge 评估系统维持着高标准。

Lyft 的目标：安全地加速智能体迭代

在包括账户访问、损坏索赔、费用审核和收入纠纷在内的众多类别中，Lyft 的 AI Assist 为乘客和司机管理客户支持。我们的旅程始于 2023 年，但流程是劳动密集型的；开发每个 AI 智能体都需要机器学习工程师（MLE）和工程团队数月的专注工作。尽管我们成功地为乘客和司机推出了效率越来越高的智能体，但整体速度仍然是一个显著的瓶颈。

到 2026 年，我们现有的运营模式面临着由新用户群体、更多问题类型、自动驾驶汽车支持等驱动的不可持续的需求激增。开发周期依赖于一个缓慢的迭代循环：领域专家定义工作流行为，然后 MLE 将其转化为工具配置和提示词。这种来回审查追踪、标记问题和调整代码的过程，对于每一个智能体都需要数周的协作。因此，那些对客户问题理解最深刻的人，在没有技术中间人的情况下无法实施解决方案。

这引出了我们的一个关键问题：我们能否赋能运营团队、VoC 负责人和产品经理，让他们直接使用自然语言构建和优化智能体？我们的目标是消除日常迭代过程中的技术中介，以加速学习和部署。至关重要的是，这种向自助服务的转变不能损害我们对体验、准确性和安全性的严格标准；每个智能体仍然必须达到我们手动工程系统的质量水平。

架构：基于 LangGraph 构建的多智能体系统

路由器多智能体模式

我们的系统遵循 LangGraph 的路由器多智能体架构。一个元智能体充当有状态的路由器：它对传入的请求进行分类，并使用 Command(goto=...) 将其分派给合适的专用子智能体。每个子智能体都是一个完整的 LangGraph StateGraph，作为子图节点注册在元智能体中。

我们为乘客和司机运行独立的路由器实例。当乘客联系客服时，元代理会路由到 rider_intent 子代理，该子代理会对乘客特定的意图进行分类（例如遗失物品、费用争议、行程问题）。对于司机，它会路由到 driver_intent 子代理，该子代理处理司机特定的意图（例如收入、账户访问、损坏索赔）。如果意图代理在对话过程中判断用户需要更专业的代理，它会使用 Command(goto=..., graph=Command.PARENT) 将控制权交还给元代理，元代理再重新路由到合适的专家代理，例如在对话中途从司机意图代理跳转到损坏索赔代理。

每个子代理，无论其专业方向如何，都遵循一致的节点模式：

这为我们带来了两个重要特性。第一，安全机制在每一轮都并行运行， 恶意意图检测和安全问题检测在任何 LLM 推理发生之前，通过 LangGraph 的 Command(goto=[...]) 扇出并发执行。第二，子代理是模块化的，可独立部署，添加新代理意味着定义一个新的子图并将其注册到元代理中。

专用代理与可配置代理

我们有两类代理：

专用代理由 MLE 为复杂、高风险的工作流手工构建。例如，我们的损坏索赔代理协助进行图像处理、欺诈检测、多步分类，以及对于低代码方法来说过于复杂的自动化调用。

可配置代理是自助服务层。它们在运行时从存储在我们内部配置服务中的 JSON 配置初始化，提示词则从 LangSmith 的 Prompt Hub 拉取。领域专家按照我们的结构化模板（角色、范围、工作流阶段、内容指南）编写提示词，ConfigurableAgent 类负责其余工作：图构建、工具绑定、安全门控和状态管理。

# Configurable agents are loaded dynamically at startup
for configurable_agent in load_configurable_agents():
    self.configurable_subagents[configurable_agent.config.intent] = configurable_agent

# Each one registers as a subgraph in the meta agent
for configurable_subagent in self.configurable_subagents.values():
    graph_builder.add_node(
        configurable_subagent.config.intent,
        configurable_subagent.get_state_graph()
    )
    graph_builder.add_edge(configurable_subagent.config.intent, "finalize")

这意味着产品经理可以通过编写提示词和 JSON 配置来定义一个新代理，例如用于司机税务问题。无需更改 MLE 代码。平台负责图构建、工具执行、检查点、追踪和安全。

使用 DynamoDB 实现状态持久化

多轮对话需要持久状态。我们构建了一个自定义的 DynamoDBSaver，它实现了 LangGraph 的 BaseCheckpointSaver 接口，让我们能够在各轮对话之间持久保存对话状态，而无需任何内存假设。每个检查点存储完整的图状态、执行元数据和父检查点引用，从而支持生产环境中的对话重放、调试和状态检查。

LangSmith：从追踪到生产监控

追踪每一次代理调用

所有环境（开发、预发布、生产）中的每一次代理调用都会通过 LANGSMITH_TRACING=true 追踪到 LangSmith。每个追踪都捕获完整的图执行过程：运行了哪些节点、LLM 看到了什么、调用了哪些工具、token 使用量，以及每一步的延迟。

我们使用一个构建运行时元数据以便过滤的工具，用自定义元数据（用户类型、代理名称、意图、对话 ID）来丰富追踪：

# Metadata flows through to LangSmith for filtering and debugging
tags = build_langsmith_metadata(
    agent_name=self.name,
    user_type=context.user_type,
    interaction_id=context.interaction_id
)

这非常宝贵。当司机报告一个令人困惑的回复时，我们可以调出确切的追踪，查看每个节点的输入/输出，确定问题出在意图分类、工具执行还是最终的 LLM 回复中，并在数小时内修复。

LLM 作为评判者的评估流水线

在任何 agent 全量上线（100% 流量）之前，它必须通过我们的评估流水线。流程如下：

小规模生产发布（5–10%） —— agent 以低流量处理真实流量。
采样生产轨迹 —— 我们捕获真实对话作为评估数据集。
运行 LLM-as-a-Judge 评估器 —— 使用来自 LangSmith Prompt Hub 的共享 judge 提示词模板，并扩展 agent 专属指标。

我们的基线评估指标（适用于每个 agent）：

然后我们为每个专用 agent 添加一些领域特定指标。例如，核心收入 agent 会检查该 agent 是否遵循或偏离了相关政策，或是否使用了任何不合逻辑或不一致的推理。

评估器使用 LangSmith 的多轮评估器自动在生产轨迹上运行，并配置了线程过滤器（例如 run name is ride_earnings）和采样率，采样率在初始发布期间较高，随着信心增长而逐渐降低。

生产监控仪表盘

生产环境中的每个 agent 都有一个克隆的 LangSmith 监控仪表盘，用于跟踪：

运行量 和 错误率 —— 我们是否看到意外的峰值或故障？
p50/p95 延迟 —— agent 的响应速度是否足够快，能满足实时支持？
Token 使用量 —— 成本是否在预算之内？
工具调用成功率 —— 外部 API 集成是否健康？
LLM-as-a-Judge 分数随时间的变化 —— 质量是在上升还是下降？

我们还设置了由 LangSmith 指标触发的 PagerDuty 告警。如果错误率超过 5%，或 p95 延迟在 15 分钟窗口内超过 10 秒，值班工程师会自动收到寻呼。

按工具划分的错误率示例图表（生产监控仪表盘的一部分）

在生产环境中运行带有自定义（agent 专属）指标的 LLM Judge 评估。提示：使用二元输出（True/False 或 Pass/Fail），而不是不准确且无法采取行动的分数。

惨痛教训：提示词质量才是瓶颈，而非基础设施

当我们首次向非技术团队成员开放 agent 构建时，我们以为最难的部分会是平台本身——正确绑定工具、处理图中的边缘情况以及管理状态。我们错了。

最难的部分是 提示词质量。领域专家深入了解他们的问题类型，但并不总是知道如何将这些知识转化为 LLM 能够可靠遵循的指令。我们看到一些 agent 能完美处理顺利路径，但在边缘情况上却崩溃了。提示词可能会定义当司机对车费提出异议时 agent 应该做什么，但对司机在对话中途改变话题时会发生什么却只字未提。或者语气部分会写着“要有同理心”，却没有具体说明这实际上意味着什么，因此 LLM 每次都会以不同的方式解读。

失败模式出奇地一致：缺少范围外定义（因此 agent 试图回答它没有工具回答的问题）、模糊的分支逻辑（阶段没有明确的进入或退出条件），以及听起来不错但给 LLM 留下太多即兴发挥空间的内容指南。

我们从两个方面着手解决这个问题。

第一，结构化的提示词编写框架。我们创建了一个包含五个必需组件的模板：身份（这个 agent 是谁、面向哪类用户、涉及哪个主题领域）、主要目标（使用具体动词，而不是含糊的“帮助”或“处理”）、范围（既包括范围内也包括范围外，并明确路由动作）、分阶段工作流（带编号的步骤，每个步骤都有进入条件，每个 if/else 都有分支，每个阶段都有终止动作），以及内容准则（具体的“该做/不该做”规则并附示例短语，而不是抽象原则）。我们为此配了一份审查清单，每个提示词在启用前都必须通过，比如“每个阶段都有出口吗？”以及“当某个工具不可用时，是否有相应的处理说明？”

第二，自动化提示词校验。我们正在构建一条由 Git 支持的提示词 lint 流水线，在任何提示词进入生产环境之前运行。当领域专家在我们的构建器 UI 中写完一个提示词后，它会针对我们的配置仓库发起一个 pull request。随后 CI 流水线会运行两层检查：先是快速的静态规则（捕获格式错误的模板变量、重复的意图 slug、拼写错误），接着是由 LLM 驱动的规则，用于检测提示词注入漏洞、相互矛盾的指令，以及对话流程无路可走的结构性死胡同。所有违规都会阻止合并。作者会在 UI 中收到行内反馈，并可自行修复问题，无需拉上 MLE。

这一切背后的关键洞察是：把提示词当作产品规格，而不是代码注释。提示词越明确，agent 就越一致。而越早发现质量问题——最好是在任何真实客户看到输出之前——整个系统的改进就越快。

成果

自自助式 agent 平台上线以来：

Agent 开发时间：从约 6 个月（第一个司机 agent）缩短到约 2 周即可完成新的可配置 agent。
Agent 覆盖范围：生产环境中可配置 agent 的数量不断增加，覆盖多种问题类型，此外还有若干专用 agent。
评估覆盖范围：100% 的生产 agent 都在实时 trace 上运行自动化的 LLM-as-a-Judge 流水线。
质量：基于 Langsmith 评估指标设置的幻觉防护栏，使幻觉和矛盾率下降了 20%。
运营效率：许多非工程团队成员现在可以独立构建和迭代 agent。‍
AI 解决率：自我们使用自助式平台上线几个 agent 以来，提升了 16%。

下一步

我们正在关注几个领域，以进一步推动该平台：

完成提示词 lint 流水线——上文所述的由 Git 支持的 CI 校验正在积极开发中。一旦全面推出，每个可配置 agent 的提示词在进入生产环境之前都将经过自动化的静态检查和 LLM 驱动的检查，常见错误无需任何人工 MLE 审查。
Mock 与仿真基础设施——构建一个仿真层，让 agent 构建者能够在部署到真实流量之前，针对合成对话和模拟工具响应进行测试，从而大幅缩短新 agent 的反馈循环。
成对评估——使用 LangSmith 的 Pairwise Annotation Queues，在上线前由人工评审者对提示词修订进行 A/B 测试。
扩展到更多地区和用户类型——将该平台带给欧洲的 Freenow 客户以及自动驾驶汽车支持场景。‍
更深入的评估自动化——从抽样评估转向对所有生产追踪进行持续评分，并带有自动提示退化警报。