生产级大模型平台工程实战手册

在我们将基于 LLM 的库存推荐系统投入生产运行的第一个月末，约 15% 的智能体返回结果是幻觉——听起来言之凿凿，但内容毫无事实依据。 六个月后，幻觉率降到了 1.5%。推动这一数字下降的关键，并非换用更强大的基础模型，而是我们做出的一个决定：不再将大模型相关能力视作应用层的业务问题，而是把它当作平台基础设施来对待。 本文所描述的项目，是一家大型零售企业的库存准确性平台。系统库存记录会因错放、损坏、盗窃和计数错误而与货架实际商品产生偏差，这种偏差会影响下单、补货以及商品供给。 我们的多智能体大模型系统对数百万 SKU、数十亿条历史库存记录中的异常信号进行分析，为业务方生成库存修正建议，助力业务始终保持库存数据准确。 本文描述的平台层，由业务、产品、软件工程师、数据科学家、数据工程专家共同构建，目前服务于数十个应用团队，覆盖库存审计、补货审查、差异分诊等场景。 本文记录了这次架构转型——面向企业级流量，对 Gemini、GPT 等基础模型进行统一路由与治理。下文中的这些工程范式正是我当初希望项目上线第一天就能拥有的。 文中提到的所有基础组件，都在配套的 GitHub代码库 "中提供了实现，代码刻意设计为无隐藏抽象层。很多框架会用装饰器或内置智能体封装底层逻辑，而这个代码库把内部运作逻辑全部暴露，保证这些工程范式清晰易懂。 本文中的代码片段均直接取自该代码库。代码库和生产环境有一处刻意设计的差异：代码库通过 Ollama " 运行本地模型 llama3.1 "，使用 LiteLLM " 对接，而非调用云端托管基础模型。整个方案可以端到端本地运行，无需任何 API 费用。 为什么独立的 LLM 应用在规模化后会失效 几乎所有团队都会遇到高度相似的故障模式，甚至可以预判：原型能跑，首次生产环境部署，在一周内看起来一切正常。随后，那些评估阶段不会暴露的问题开始出现在监控面板上。 在我们的案例中，测试阶段暴露出了三类问题，每一类都是原型阶段没有覆盖到的场景。第一个是 LLM API 限流。在真实请求量下，我们开始被模型厂商限流。第二个是上下文问题。当系统推荐了不合适的商品时，根因几乎都是输入模型的数据，而非模型本身——这说明健壮的数据工程管线是解决问题的核心。第三个是大问题：幻觉。单次看很罕见，但在生产流量持续请求下，幻觉会稳定出现。我们在平台中设计了监控能力来追踪这些故障，正是这种可见性把每一个问题从谜团变成了可修复的对象。 追踪这些问题后，我们也清楚地明白：这些问题应当放在平台层统一处理，而不是交给单个应用。有三点特性尤为突出： 幻觉是输出问题，而非程序 Bug幻觉返回的内容不会抛出调用栈异常，所有传统健康检查都能通过。下游服务接收结果并据此执行操作，很久之后才有人发现这个推荐结果对应的事实根本不存在。Token 消耗不可控如果没有按请求归属统计用量，每月收到的账单就只有服务商给出的一行总金额。无法区分是哪个应用、哪个团队、哪个场景产生的开销，成本优化只能靠猜测。行为不可观测延迟监控面板显示 P99 延迟正常，错误率接近 0。但模型输出质量在悄无声息地变差，但输出内容在语法上依然合法。 这些都不是应用程序的 Bug。几乎所有做大模型功能的团队都会碰到同类问题，大家第一反应都是在应用内部进行修复，于是 N 个团队写出 N 份重复的脚手架代码。这部分通用能力本应该下沉到平台层统一实现。 搭建共享大模型平台的理由 集中管理大模型能力并不是纸上谈兵。这和大型系统中集中管理 身份认证 "、 日志 "、 服务网格 "的逻辑几乎完全一致：当多个应用存在同样的跨模块通用需求时，重复开发的成本会超过搭建共享基础设施的成本。 对 LLM 而言，共享的关注点是： 重试逻辑与故障分类提示词注册表与版本管理Schema 强制约束按请求统计 Token 成本行为可观测性工具调用与上下文路由跨工具服务的身份认证与授权 还有一个比重复更重要的二阶效应。共享平台强制形成契约，应用声明它们需要什么（即模型、提示词版本、Schema、工具集、评估引擎），平台负责交付。正是这种契约让新应用几天内就能上线，因为最难的部分已由平台解决。 搭建这个平台的决策点不是第一个 LLM 应用上线，而是第二个。等到十个团队都各自上线大模型功能后再在底层改造搭建平台将会是漫长艰难的迁移工作。 平台架构 图 1 展示了各个基础组件之间的组合关系。代码库实现了完整请求路径，与生产环境架构保持一致。 唯一入口是网关。网关负责调用方身份认证、签发携带角色信息的 JWT、暴露智能体执行接口、提供用户/团队维度指标、提供仅管理员可用的提示词回滚接口。网关后方，一个基于谷歌智能体开发套件 ADK "构建的根协调智能体在每一轮请求中识别意图，并将任务分发给一个或多个专家智能体；每个专家智能体绑定注册表中指定的提示词与结构化输出 Schema。专家智能体负责工具连接，对应多个独立的 MCP 服务，按团队或场景隔离；每个服务器在工具运行前自行验证调用方令牌并执行授权策略。 编排能力通过 ADK " 实现：它提供智能体与子智能体拓扑结构、协调器分发给专家智能体的委托调用，同时提供回调钩子，平台在此记录调用成本与延迟。 所有智能体通过 LiteLLM " 调用模型，这样可以随意切换模型厂商。本地调试时智能体可以调用本地模型，在生产环境中可以切换为 Gemini " 或 GPT " 等云端基础模型，仅修改模型标识即可。 配套代码库中的本地模型由 Ollama " 提供，因此网关、智能体、工具服务都可以在笔记本上端到端运行，无 API 调用费用。 工具服务基于 模型上下文协议 "部署。ADK 的 MCP 客户端连接智能体与团队侧服务，团队侧服务使用 FastMCP " 构建。 这种分层解耦的价值在于：没有哪个单独的框架会垄断整个系统。模型层、工具层、编排层各自基于稳定接口，任意一层都可以替换，比如更换更强的模型、不同的工具服务、甚至是编排引擎，都无需重写平台基础组件。这就是依赖层面贯彻“无隐藏抽象”原则：每个工具只负责一件事，组件间调用路径清晰可见。 结构化输出：在平台层强制校验 Schema，并在失败时重试 我们所做的性价比最高的改变是在平台边界而非应用边界强制结构化输出。 这个模式的逻辑并不稀奇。每次调用大模型时声明目标 Schema（我们使用 Pydantic " 模型），平台在校验通过后才将结果返回调用方。如果校验失败，平台会把校验错误作为提示词附加上下文重新发给模型，重试次数上限可配置。 把这个模式放在平台层而非各个应用中所带来的变化： 一个实现统一处理所有 Schema 不匹配问题，优化一次，所有应用受益。下游调用方可以依赖这个契约：只要调用成功返回，输出结构一定符合规范。Schema 违规会成为平台监控指标，而不是深埋在应用日志里的运行时异常。 我们的输出 Schema 不只是格式化数据，它也是给模型的显式指令，包含专门为隔离和度量幻觉而设计的追踪字段。图 2 展示了文档专家智能体的输出 Schema 示例。 from pydantic import BaseModel, Field class DocsOutput(BaseModel): """Result o