一支团队关停 LLM 客服生产服务的踩坑总结

背景

一位开发者 8 个月前曾在 r/LocalLLaMA 发布过帖子，介绍团队正在开发一款基于 LLM 的医疗预约客服机器人——通过即时通讯渠道，帮助私立诊所的患者与诊所沟通、安排就诊。如今，团队决定正式关停该项目，原因是「在生产环境中遭遇的挫折远超预期」。本文整理其在实践中遇到的关键问题。

框架选型：PydanticAI 的同步陷阱

团队最初直接通过 OpenRouter 调用各家模型 API，社区建议改用 PydanticAI 来抽象模型调用与工具调用逻辑。开发阶段表现良好，但上线后暴露出工程层面的问题：

PydanticAI 核心设计围绕异步（async）展开，即便使用 sync 封装，内部仍是异步逻辑；
若整体架构为同步，要么重写为异步（成本高），要么在同步环境中嵌套异步循环，容易导致进程卡死、必须系统级 kill；
这些问题在测试阶段难以复现，真正流量进来后才显现。

模型与供应商可靠性

团队在 OpenRouter 上切换过多个模型供应商，包括：

GLM 4.5 / 5.0 / 5.2
DeepSeek
Mimo
Qwen
ChatGPT
Claude
Minimax

实际运行中发现：

各供应商并不保证可用性，即便是官方模型方也可能返回空响应而非正常错误；
即便配置 fallback，多家供应商可能在同一时刻同时异常，导致整条流程中断；
用户简单的提问也可能让模型返回非法的结构化数据，Pydantic 校验大多时候无济于事。

结构化输出与角色漂移

LLM 在结构化输出上存在不确定性。PydanticAI 允许让 agent 返回原始字符串或 Pydantic 模型，但前者会丢失字段描述的约束，后者又依赖模型自身能否稳定输出指定 JSON。反复校验、重试、提高 temperature 都不能根治问题，开发者感叹：「如果 LLM 决定要出错，它就会一直出错下去。」

此外，emoji 也可能让角色设定崩塌。用户消息中的「🤩🎉」曾让机器人自发编造「为你儿子高兴」之类的内容，违反系统提示。开发者推测，模型读到 emoji 后自行决定要「变得热情、友好、让用户开心」，从而越过了角色边界。

Agent 过度主动带来的风险

Agent 在生产中表现出过度积极的倾向——即便用户没有明确请求，也会主动推进任务。开发者举例称，机器人在某次预约场景中出现了「令人害怕」的自主行动，提示其行为边界需要更严格的工具调用与流程约束，而不仅仅依赖系统提示词。

结语

该团队的经历再次印证了一件事：当前 LLM 在「个人一对一使用」场景下体验优秀，但作为面向终端用户的商业服务时，可靠性、结构化输出稳定性、角色一致性都仍是显著短板。开源模型的总体质量在过去 8 个月确实有明显提升，但要达到生产级 SLA，仍需大量工程化兜底——而这部分成本，往往远超小团队的承受范围。