1. 从“单模型调用”到“多态平台”我为什么会做这件事去年年初我们团队接到一个挺头疼的需求要在同一个产品里同时支撑智能客服、代码审查助手、文档摘要、数据分析对话好几个场景每个场景对模型的侧重点还不一样。刚开始我图省事直接在所有接口里写死某家大模型厂商的API结果上线不到两个月就出问题了。首先是成本失控。所有请求一股脑往最贵的那个旗舰模型上打月初预算几天就烧掉一大截月初还好到月底就紧巴巴运营同学天天来找我调配额。其次是效果不均。代码审查这个场景某个开源模型的表现其实已经够用了但我这边没做过适配只能硬着头皮用统一的接口而数据分析对话那类复杂任务同一家模型又经常在长上下文里丢信息逻辑一绕就乱。最难受的是被单一供应商卡脖子人家一调价、一限流我的业务就得跟着抖连个紧急备份通道都没有。所以后来我们咬着牙做了现在这个“多态大模型平台”。这个“多态”我拆分成了三层理解第一层是能力形态要能同时处理文本生成、代码补全、结构化抽取、图像理解这些不同模态的请求第二层是部署形态云上的商用API能用私有化部署的开源模型也能接某些对时延极敏感的模块甚至要能落到内网边缘节点第三层是协作形态既能单模型独立完成任务也能让多个模型按角色分工协同。如果你现在正要搭自己的模型接入中台或者想把自己零散的模型调用整理成一套可复用的平台能力这篇文章应该能帮你少走不少弯路。我不会只讲概念后面会把我拆架构、写适配器、做路由、调性能的具体做法和踩坑记录全部摊开。2. 平台架构的整体设计五个核心模块怎么分工先说结论我们没有做成一个“大而全”的一体化平台而是拆成了五个相对独立的模块彼此通过内部API通信。这样做的原因很简单——多态意味着模型来源、任务类型、部署位置都在变如果所有逻辑堆在一个服务里任何一个维度变化都会牵动全局改一次要回归测试半天。2.1 接入网关层所有请求的统一入口业务方不直接感知底层模型他们只向网关提交一个标准化的请求对象里面带上任务类型、输入数据、期望的输出格式等元信息。网关负责协议统一、API密钥校验、基础限流。为什么这一层必须独立因为后期我们接入了新的模型厂商、切换私有化模型业务方一点都感知不到。接口形态从第一天就冻结后续所有演进都在平台内部完成这个前置决策省了后面无数口舌。2.2 模型适配层把不同厂商的“方言”翻译成普通话每个模型厂商的API格式都不一样有的用Messages结构有的用Completion风格有的返回纯文本有的返回JSON。适配层的职责就是做“翻译”对内是统一的中间协议对外是针对每个模型的适配器插件。每接入一个新模型只需要写一个适配器并存档到模型注册表不需要动业务代码。2.3 路由决策层决定这个请求应该交给谁路由层是整个平台的大脑。它会根据请求的任务类型、上下文长度、成本上限、延迟要求甚至当前各模型服务的健康状态计算出一个最优模型集合。这里不只是选一个模型还可以决定是否需要多模型并行投票、是否需要走“大模型规划小模型执行”的组合链路。路由策略我放在第4章细讲它是整个平台价值兑现的关键。2.4 工作流编排层把单次调用串成完整任务很多任务的形态不是“一次问答”就能完成的而是需要多个步骤先做意图识别再调用工具API获取数据再生成结果最后做格式校验。编排层把这些步骤定义成可复用的工作流每个节点指定模型、工具或固定逻辑。它还负责状态保存和失败重试。这层也是我们后来接入Agent能力的基础。2.5 运营治理层配额、计量、审计、成本分摊模型花钱谁用了多少、花在哪个业务线、效果如何这些如果没有数据支撑完全没法向管理层交代。所以平台从第一天就强制记录每个请求的模型名、输入输出token数、时延、成本估算按业务线分摊。这个数据不止用于账单还用于后面做路由策略的优化迭代。下面这张表可以概括各模块的职责和关键产物模块核心职责关键产物接入网关层统一入口、鉴权、限流统一API规范、API Key账户体系模型适配层厂商协议转换模型注册表、适配器插件仓库路由决策层请求级模型选择与组合路由策略引擎、健康检查模块工作流编排层多步骤任务编排与状态管理工作流定义DSL、执行引擎运营治理层计量、审计、成本分析请求日志、成本报表、告警规则这五个模块合起来对外提供的是一个“模型无关”的能力平台。业务侧只需关心“我要什么样的结果”而不必关心“这个结果到底由哪家模型产出”。3. 模型接入层统一协议与动态路由的实现细节3.1 统一协议的设计我给模型调用定义了中间格式第一步是定义一套“既足够抽象、又足够实用”的中间请求协议。早期版本我设计得很啰嗦把温度、top_p、惩罚系数全塞进协议结果差不多每接入一个新模型就要改字段。后来我把参数分成了“基础参数”和“扩展参数”两部分。基础参数只有五个model_group模型分组别名、task_type任务类型、messages对话/输入内容、response_format输出结构、max_tokens输出长度上限。其他所有采样参数统一放进extras字典由适配器自行映射。这五项的确定是经过长期观察的——无论哪个厂商最终跑业务时都绕不开这五个能力而其他参数更多是锦上添花。response_format是重中之重的字段。我们内部约定了几种枚举值TEXT、JSON、JSON_SCHEMA、CODE。对应到各家厂商的API就是不同的参数配置。比如OpenAI风格的接口实现JSON_SCHEMA要用json_schema类型的response_format而某些国内厂商是返回参数里带一个hint字符串。这些差异全部收敛在适配器里业务层完全不感知。3.2 适配器模式每个模型一个翻译官实现上我用了比较朴素的适配器模式。每个适配器实现统一的接口方法class ModelAdapter(ABC): abstractmethod async def chat(self, request: UnifiedRequest) - UnifiedResponse: ... abstractmethod def parse_response(self, raw) - UnifiedResponse: ...有的厂商还会给出流式输出streaming所以适配器还得实现stream_chat。这里有两个容易踩的坑第一个坑是超时设置。不同模型的速度差别非常大我们用统一超时策略导致大量误判快模型10秒就能回慢模型可能要90秒。后来改成超时时间由模型注册表的meta信息路由每个模型配自己的建议超时和服务降级策略。第二个坑是错误码语义差异。有的厂商限流返回429有的返回500有的返回一个业务错误码字符串。适配器内部必须把这些统一映射成平台内部的四类错误RATE_LIMITED、CONTEXT_LENGTH_EXCEEDED、BAD_REQUEST、SERVICE_UNAVAILABLE。不统一的话路由层做故障转移时根本没有依据。3.3 动态路由策略不是所有请求都配得上旗舰模型路由决策我用了一个比较务实的方法先把每个任务打上标签再根据标签做规则匹配和打分排序。第一步是整理模型注册表。每个模型除了API地址外还维护一组能力标签例如{ model_name: deepseek-chat, group: general_chat, tags: [中文, 代码, 低时延, 低成本], context_window: 64000, max_output_tokens: 8192, rough_cost_per_1k_tokens: 0.001, p99_latency: 8.5, health_score: 100, status: active }第二步是定义任务标签。每个接入平台的任务都必须声明它对哪些能力敏感。比如客服会话标签是“中文、低时延、成本敏感”代码审查标签是“代码、高准确”长文档摘要标签是“长上下文、逻辑强”。第三步是打分。我用一个简单但有效的公式score 0.4 * capability_match 0.3 * latency_score 0.2 * cost_score 0.1 * health_scorecapability_match是能力标签的覆盖率latency_score和cost_score是把延迟、成本归一化到0-100分之后的值。打分高的模型优先被选中。如果最高分低于60或者模型健康检查失败就触发降级规则比如SUMMARIZE类的任务会从大模型降级到稍小的模型。这个策略的线上效果说实话超预期。当时一个月下来总成本降了大概40%P95延迟也小了一些因为模型被更精准地分配了。当然打分权重不是一成不变的每隔一两个版本就要结合运营治理层的数据调整一次。如果你们业务的默认场景特别单一公式可以直接固定成“指定模型名故障降级”前期会省事很多。4. Agent与工具编排让大模型从“会聊天”到“能干活”4.1 为什么要把单次调用升级成工作流模型本身再强不接工具、不落地执行流程它始终只是个“聊天机器”。我们会话系统里有一类高频需求用户问“帮我查一下昨天华东区的销售额波动原因”。如果只是把问题直接扔给模型它大概率会说一堆正确的废话因为它没有数据访问能力。所以平台第二期开始引入工具调用和Agent编排。思路是让模型决定“需要调用哪个工具、传什么参数”然后平台负责实际执行再把工具返回结果喂回模型继续推理。这样一个基础的能力闭环就出来了。4.2 抽象工具注册表不绑定具体的执行实现工具定义我使用了开放API风格的结构每个工具包括名称、描述、输入JSON Schema、实际执行端点{ tool_name: query_sales_data, description: 查询指定区域的销售额数据参数需要包含date和region, input_schema: { type: object, properties: { date: {type: string}, region: {type: string} }, required: [date, region] }, endpoint: internal://data-query-service/sales }这里要特别提醒工具描述文本的质量直接决定了模型选工具的正确率。我一开始写得很随便比如“获取数据”模型经常选错工具。后来把描述重写成“当用户提到按地区、按日期的销售额查看请求时优先调用此工具如果用户询问的是库存或退款不要调用此工具”这种带边界说明的句式选对率提高了不少。不要小看这一步写工具描述和写few-shot示例一样本质是在给模型做条件化引导。4.3 多模型分工大小模型协作的任务分配机制在我们的Agent链路里很少让同一个模型把所有事情做完。比较典型的链路是意图识别节点用便宜的小模型快速判断用户意图类型计划生成节点复杂任务交给能力更强的模型让它输出但步骤计划同时通过工具调用拿数据执行校验节点用小模型做输出格式校验、敏感词过滤。这套大小模型协同设计成本上比“全程用大模型”省而且速度更快。但代价是链路变复杂、调试变难。为了能观察每一步在干什么工作流引擎里必须记录每个节点的输入输出摘要、token消耗、耗时并提供一个链路追踪的调试页面。这个页面后来成了我们日常排障的标配强烈建议你们做Agent平台时第一个就要做可观测性不要等到出问题再去补。4.4 结构化输出的保障让模型的回复“长成规定样子”多态平台最需要的其实是可控性尤其在Agent场景里模型输出如果不是严格的结构化数据后面的程序根本没法处理。我推荐三管齐下第一在prompt里明确定义输出格式给出示例并要求“只输出JSON不要解释”第二在response_format参数里强制指定JSON_SCHEMA让模型从机制上受限第三在结果侧加一道校验器用JSON Schema校验不合格就自动重试一次。第三道防线特别重要。模型不是每次都会遵守格式约束加了校验重试之后下游解析报错率基本降到了可忽略的水平。这里还涉及一个踩坑点重试时要考虑幂等。比如“查询库存”这类只读操作可以放心重试但“创建订单”“发送消息”这类写操作一旦模型已经调用了工具成功重试可能产生重复副作用。我们的做法是给工作流里的工具调用按节点做去重同一个工作流实例里相同工具相同参数默认只执行一次。除非显式标记了allow_retry否则不会重复执行写类操作。5. 成本与延迟的平衡改造前后的实测数据与调参思路5.1 成本模型我计算请求成本的三个口径算钱这事如果没有一个统一口径很容易被各厂商五花八门的计费方式绕晕。我在模型注册表里统一维护了三个数字input_1k_cost每千输入token的价格output_1k_cost每千输出token的价格fixed_cost单次请求固定费用有些厂商没有。单次请求成本就按input_tokens / 1000 * input_1k_cost output_tokens / 1000 * output_1k_cost fixed_cost计算。适配器返回时顺手把token数带上运营层直接落库报表就能按业务线、按模型组做多维下钻。有了这个基础路由层的成本分才算得准。5.2 混布改造后的实测数据改造前我们所有请求打到一个旗舰大模型上月成本高且时延不稳定。改造后我按任务类型重新做了分布任务类型改造前使用模型改造后常用模型成本变化耗时变化智能客服对话旗舰大模型中端通用模型 拒答兜底下降约60%相近代码审查旗舰大模型开源代码模型私有化部署接近零边际成本略升长文档摘要旗舰大模型长上下文模型按需路由下降约30%相近数据分析Agent旗舰大模型大小模型协作链路下降约40%P95略升但可控这里面的关键不是“无脑用小模型”而是“小模型解决不了的时候要能准确识别并升级到大模型”。比如智能客服我们用了一个意图分类哨兵高置信度的简单问题直接走小模型低置信度或有投诉倾向的会话才升级到大模型。这个升级决策本身也是一个模型调用但它是处理成本里的一个点总体仍省得多。5.3 三层缓存不只是KV缓存我把缓存拆成了三层第一层是完全相同的请求短时缓存。同一用户、同一问题在5分钟内重复提交直接返回上一次结果。这个命中率不高但实现极简单。第二层是语义缓存。把用户输入做embedding算余弦相似度跟缓存池里的历史问题比对相似度超过0.92就直接复用答案。这样可以应对用户用不同句子问同一个问题的情况。注意要设置缓存时效还得做敏感上下文的隔离避免不同用户之间的数据串味。第三层是步骤级缓存只针对Agent链路里的中间结果。比如长文档摘要里第一步“抽取关键段落”如果输入文档的哈希值没变这个中间结果可以直接复用省掉重复读入长上下文的费用。三层缓存叠加之后成本又降了一大截。不过缓存也会带来新鲜度问题尤其是客服场景资料库更新之后不能还让用户拿到旧答案。我的做法是在缓存键里带上业务资料版本号资料一更新旧缓存自动失效。5.4 延迟调优流式输出与首token时间的取舍当时实测发现很多模型调用之所以感觉慢瓶颈往往不在总时长而在首token时间TTFT。如果业务流程要求必须等完整结果才能渲染那体验就是“等半天没反应”。为此我把大部分交互场景改成了SSE流式输出客户端先收到首批token用户先看到内容在“打字”感知等待时间大幅下降。但流式输出和结构化校验之间有点矛盾JSON输出如果边生成边往客户端推中间可能推出去一段不完整的JSON。我的处理思路是对要求严格JSON_SCHEMA的节点走非流式让模型一次性输出完整JSON再解析对纯文本对话场景走流式。然后经过一层网关缓冲确保到达客户端的内容要么是完整JSON、要么是统一格式的文本片段。6. 这半年踩过的坑与应对方案6.1 模型返回格式不兼容多模态“翻译”翻车我们早期接图像理解模型时以为图像理解任务的输出一定也是文本。后来发现某开源模型的输出里混着特殊标记符还有把它本地输出结构包装成Markdown图片链接的。这个坑导致后链路的解析直接把标记符当成正文渲染。后来我在适配器里加了一个输出sanitize步骤对已有的特殊标记和包装文本做剥离并把统一协议里的image理解结果单独拆成content片段。所有多模态输出都遵守一条规则——“返回的content是不带平台强相关的纯内容渲染层的格式由前端自己决定”。6.2 私有化开源模型的量化损失便宜是要付出代价的为了降本我把一个模型量化成INT8部署当时跑基准测试觉得效果还行结果一上真实业务就发现某些类别的意图识别准确率明显下降。回查之后发现是量化过程中激活值分布没有处理好尤其对长尾中文表达特别敏感。修复方案是改用混合量化关键层保留FP16低风险层才压缩。这也说明“私有化部署不要盲目追求最小的显存占用”部署前至少要拿自己的业务语料跑一遍对比测试不要只信几个通用公开基准。6.3 限流与配额一个用户把整个平台的额度打爆有一次某个用户开启了一个大数据量的批处理任务一瞬间就把某家厂商的每分钟配额全部耗尽导致其他业务的实时请求全部受影响。因为只做了应用级总量限制没做业务线级别的分级配额。后来我在网关层实现了“业务线-应用-用户”三级配额桶每个桶有独立的速率限制和最大并发数。批处理任务被单独分到低优先级的配额实时交互请求永远有独立配额。上线后再没出现一家业务拖垮全平台的事故。6.4 上下文管理长会话的成本黑洞长对话场景下如果把整段历史每次原封不动传进模型token量会随轮次线性上涨。平均一轮对话几百轮下来上下文费用高得吓人。我们引入了摘要压缩对话超过一定轮数后把更早的历史让一个低成本模型压缩成结构化摘要只保留最近几轮原始对话。效果不错但要注意压缩有损对需要长期记忆的业务要同时考虑外部记忆存储比如向量库而不是单纯依赖模型上下文。7. 后续思考从“多态模型平台”到“智能体平台”的延展做到现在这个阶段我个人最大的体会是平台的价值不在于把多少个模型接入进来而在于“接进来之后能跑出多少种可靠的应用形态”。多态大模型平台发展到后面其实就是智能体平台的地基——模型、工具、工作流、状态管理、可观测性这五件套齐全了Agent应用的构建就变得非常顺滑。目前我们正在尝试把整个配置文件模型注册、路由规则、工具定义、工作流描述全部沉淀为代码仓库里的版本化资产用Git来管理变更。一个新的Agent上线不再是改代码而是提交一个YAML描述文件走评审合并后自动生效。这个方向虽然实施起来有不少细节要处理但我判断是值得投入的。最近还计划在路由层引入基于线上效果反馈的自动调优让模型选择不再依赖我拍脑袋定权重。最后再分享一个经验如果你们团队也想做类似的平台千万不要一上来就追求大而全。先咬住一个真实业务场景跑通闭环把统一协议、路由、成本计量这三个最小模块立起来再去想Agent编排、自动调优这些进阶能力。平台的搭建始终是服务于应用研发目标的工具自身再优雅最终还是要回到“业务问题有没有被更快更便宜地解决”这个最朴素的判断标准上。