真实面经题目 · 原创解析
这题考察的是多大模型供应商接入时的工程抽象能力，不是简单写几个 if else 适配接口。好的统一调用网关要把业务层看到的协议收敛成稳定的内部模型契约，同时把供应商差异隔离在 adapter 层：消息格式、模型名、参数范围、流式协议、错误码、限流、鉴权、计费、上下文长度、工具调用、JSON 输出能力都不能泄漏给上层。架构上通常分为统一 API、路由与策略、provider adapter、可靠性治理、观测与审计、配置和灰度几个部分。回答要强调边界：网关不是只做转发，而是承担能力抽象、故障隔离、降级切换、成本治理和可观测性；但也不能把所有模型能力抹平成最低公约数，否则会损失模型特性。因此设计上要有基础统一契约和可扩展 capability 描述，既屏蔽常见差异，又允许业务显式选择高级能力。
我会把统一大模型调用网关设计成“稳定内部契约 + 多 provider adapter + 策略治理”的结构。业务侧只调用一套 `/chat/completions` 或内部 SDK，传入统一的 `messages`、`model_alias`、`temperature`、`max_tokens`、`stream`、`tools`、`response_format`、`trace_id` 等字段；网关先做鉴权、参数校验、预算和 prompt 安全检查，再根据模型别名、场景、成本、延迟、可用性和灰度规则路由到具体供应商。每个供应商有独立 adapter，负责把内部请求转换成官方 API 的字段、模型名、签名方式、超时设置和流式协议，并把响应、错误码、usage、finish_reason、SSE chunk 统一归一化。可靠性上要做超时、重试、限流、熔断、降级、fallback 和幂等控制，不能对所有错误盲目重试；观测上记录 trace、provider、model、延迟、首 token 时间、输入输出 token、错误类型、命中缓存、降级路径和成本。能力差异不能粗暴抹平，可以维护 `capability matrix`，标记每个模型是否支持工具调用、JSON schema、视觉输入、长上下文、流式 usage 等，高级能力由业务显式声明并由网关做兼容性校验。
网关最先要解决的是业务代码不直接依赖各家官方 API。内部协议可以参考通用 chat/message 抽象，但要按自己的业务需求定义清楚：`system/user/assistant/tool` 消息、文本和多模态 content、采样参数、停止词、最大输出、流式开关、工具定义、结构化输出、业务场景、租户、trace_id、幂等键和预算标签。业务侧使用 `model_alias` 而不是厂商真实模型名，例如 `fast-chat`、`deep-reasoning`、`cheap-summary`，这样模型替换、灰度和降级可以在配置层完成。统一契约的价值是稳定上层调用和治理口径，而不是强行让所有供应商能力完全一样。
每个 provider adapter 负责处理官方 API 的所有细节，包括鉴权签名、endpoint、模型 ID、字段名映射、参数范围转换、消息格式转换、流式 chunk 解析、错误码映射、usage 解析和响应归一化。比如有的供应商把最大输出叫 `max_tokens`，有的叫 `max_completion_tokens`；有的流式返回 OpenAI 风格 SSE，有的返回自定义事件；有的支持 tool call，有的只支持纯文本。adapter 输出必须归一成内部 `LLMResponse` 或 `LLMStreamEvent`，包含 `delta`、`finish_reason`、`usage`、`provider_request_id`、`raw_error_code` 等字段。这样新增供应商时只增加 adapter 和配置，不改业务流程。
多模型网关不能只做最低公约数，否则工具调用、JSON schema、多模态、长上下文、reasoning、缓存、logprobs 等能力都会被浪费。更合理的是维护 `capability matrix`：每个 provider/model 声明上下文长度、最大输出、是否支持 stream、是否支持 function calling、是否支持强 schema、是否返回 usage、是否支持图像输入、限流额度、价格和 SLA。请求进入网关后，如果业务声明 `requires: ['json_schema', 'stream']`，路由器只能选择满足能力的模型；如果不满足，要在请求前失败或走明确的降级策略，而不是把工具调用 silently 丢掉。这样既屏蔽差异，又保留模型特性。
路由层不应写死 provider，而应使用规则或策略引擎。输入包括业务场景、租户等级、模型别名、请求 token 估算、实时健康状态、限流余量、成本预算、延迟目标和灰度比例。常见策略是主备路由、按权重灰度、低价值请求走低成本模型、高价值请求走高质量模型、长上下文请求走支持长窗口的模型、某供应商错误率升高时自动熔断。路由决策要记录到 trace 中，包含候选模型、选择原因和降级原因，否则线上问题很难解释。
官方大模型 API 的不稳定通常表现为超时、429 限流、5xx、连接中断、流式中途断开、内容安全拦截或 usage 缺失。网关需要分层超时：连接超时、首 token 超时、整体生成超时；重试要按错误类型决定，网络抖动和部分 5xx 可以有限重试，非幂等工具调用、内容安全拒绝、参数错误不应重试。限流既要按 provider 配额，也要按租户、场景和用户做配额；熔断基于错误率、p95 延迟、429 比例等指标；降级可以切换备选模型、关闭非必要高级能力、缩短上下文、返回排队/稍后重试，具体要由业务可接受性决定。
流式调用是差异最容易泄漏的地方。网关应把不同供应商的 SSE、分块 JSON 或自定义事件转换成内部事件，例如 `message_start`、`content_delta`、`tool_call_delta`、`usage_delta`、`message_end`、`error`、`heartbeat`。同时要处理心跳保活、客户端取消、上游取消、半包解析、流式错误归因和最终 usage 补齐。业务侧只消费统一事件，不关心上游 chunk 格式。对于不支持流式 usage 的供应商，可以由网关在结束后估算或异步补记，但要标明 usage 来源，避免成本报表失真。
统一网关的最大价值之一是所有调用有统一观测口径。每次请求至少记录 trace_id、tenant、scene、model_alias、provider、real_model、prompt token、completion token、首 token 时间、总耗时、错误分类、重试次数、fallback 链路、命中缓存、费用估算和 provider request id。日志要注意脱敏，原始 prompt/response 可按业务合规策略采样或加密存储。指标层要能按供应商、模型、场景、租户维度查看 p50/p95/p99、成功率、429、超时、单 token 成本和质量反馈。没有这些，网关只是一层代理，无法承担生产治理。
模型名、provider endpoint、路由权重、超时、重试次数、限流配额、fallback 链、能力矩阵和价格都应配置化，并支持灰度发布和回滚。新增供应商时走 adapter 接口测试、contract test、流式解析测试、错误码映射测试和小流量灰度。内部 SDK 和网关协议要版本化，避免一次能力升级破坏所有调用方。对于业务强依赖的高级能力，要建立兼容性测试集，例如 JSON schema 遵循率、工具调用参数正确率、多轮上下文一致性，而不是只测 HTTP 200。
可以让外部形态接近 OpenAI API，降低接入成本，但内部不要被某一家协议锁死。更稳的做法是定义内部 canonical request/response，再提供 OpenAI-compatible adapter 给业务使用。这样当国内供应商有特殊能力、特殊错误语义或不同流式事件时，网关内部仍能表达，不会被外部兼容层限制。
fallback 不是简单失败后换模型。要按场景配置可替代模型，并用离线评测确认 prompt 兼容性、JSON 输出兼容性和质量底线。线上 fallback 要记录原因，并尽量保留相同系统提示、工具定义和输出 schema。如果主模型是强推理模型，备选模型能力明显更弱，就应返回降级提示或只用于低风险场景，而不是无条件替换。
网关应保存 provider 返回的原始 usage，同时维护内部估算口径。计费和预算可以优先使用 provider usage；如果流式无 usage 或返回延迟，则用 tokenizer 估算并标记为 estimated。报表中要区分官方值和估算值，价格表也要按 provider/model 版本配置化，否则成本核算会出现系统性偏差。
可以做，但要控制边界。网关适合承载公共治理能力，例如安全前置检查、上下文截断、模板版本号、trace 和缓存 key；业务语义 prompt 最好由业务服务或专门 prompt 管理层维护。否则网关会变成业务逻辑大杂烩，新增场景都要改网关，反而降低可维护性。
至少要有 contract tests：普通非流式、流式、错误码、超时、限流、取消、usage、工具调用、JSON 输出、多轮消息和最大上下文边界。还要做 shadow traffic 或灰度，把同一批请求跑主 provider 和新 provider，对比成功率、延迟、格式稳定性和质量抽样。只有 HTTP 调通不代表 adapter 可上线。
