单模型客服撞上了工具过载
Lyft 的客服系统起点并不复杂：一个接大语言模型的聊天机器人，负责回答乘客与司机的问题。但当工程团队把它接到二三十个内部接口时，麻烦来了——工具一多，模型常常选错工具，时延也跟着往上走，体验并不稳定。这种「工具过载」在很多企业的客服智能体项目里都出现过，是单智能体架构走到中后期的典型症状，靠加提示词往往压不住。
Lyft 的体量放大了这个问题：它服务的是跨市场的出行网络，客服诉求同时跨乘客与司机两端，内部接口天然就多。把一个万能客服机器人直接怼上全部系统，等于让模型在每次对话里都做一次大型路由决策，既慢又容易选错工具。这条路很多团队都试过，最后大多回到同一句结论——先把职责切小，再谈智能。
Lyft 没有继续在单模型里堆能力，而是把系统重做成多智能体结构：用一个路由智能体判断诉求属于哪一类，再把任务交给对应的专业子智能体。乘客改派、司机收入核算、安全与信任处理，各自有专门的智能体负责，彼此通过图流程做状态管理与交接。把职责切开之后，每一段都变简单、也变得可观测。
路由式架构：把专家拆开，把状态打通
关键不在于「用了几个模型」，而在于切完职责之后，每一步都显式、可追踪。路由智能体只做分诊与编排，专业子智能体只管自己那一类问题，安全校验、上下文传递、智能体之间的交接都写进图里，而不是靠一句含糊的提示去碰运气。某个子智能体出错，不会拖垮整体；新增一类诉求，就加一个专家，不必重写整条链路。
他们用 LangGraph 承载这套路由与状态，用 LangSmith 追踪每一步，再用大语言模型当裁判去评价回答质量。对客服这种「高频、多类、必须兜底」的场景，图的显式状态比黑盒编排更让人放心，也更容易在出问题时定位是哪一段跑了偏。
真正的杠杆在「谁能造智能体」
更值得记一笔的是组织层面的变化。Lyft 公开复盘里提到，智能体开发周期从大约六个月压缩到数周，并且非技术的业务专家也能直接搭建和打磨智能体。这在过去几乎不可想象——造智能体是工程团队的专属任务，业务方只能提需求、等排期。当搭建权下放到懂业务的人手里，智能体才能真正贴合一线流程，而不是停留在演示。
他们服务的是每月数十万量级的通话与交互，规模本身就在逼着架构走向可组合、可复用。把专家拆开之后，业务专家改的是自己那段逻辑，而不是去求工程团队改全局。这种「流程里的民主化」，比模型本身更强一点，更经得起扩张。
这套打法对外包的启示也实在：当企业想把客服智能体从试点推到全量，瓶颈通常不在模型供应商，而在内部流程有没有被拆清楚、有没有让一线人员参与。Lyft 把搭建权下沉，本质上是在补这块组织能力，比单纯换更贵的模型更治本，也更能扛住后续扩张带来的复杂度。
可复用的经验与边界
这类改造有几个可迁移的要点：其一，先解决工具过载，再谈智能，路由分诊是性价比很高的一步；其二，把状态与交接显式化，可观测性不是锦上添花，而是多智能体能否上生产的硬门槛；其三，让业务方参与造智能体，才能把领域知识沉淀进流程，而不是锁在工程师脑子里。
同时也要清醒：公开复盘展示的是架构切换后的效率增益，不是单点模型分数，也不代表所有场景都该拆成多智能体。紧耦合、强顺序的任务，单智能体配合结构化工具反而更干净。Lyft 的价值在于示范了一种可落地的切法——先按职责分专家，再用图把专家缝起来，而不是一上来就追求一个万能大模型。