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编排、自动调优这些进阶能力。平台的搭建始终是服务于应用研发目标的，工具自身再优雅，最终还是要回到“业务问题有没有被更快更便宜地解决”这个最朴素的判断标准上。
