传统 API 监控里，一条 HTTP 请求通常对应一个服务操作。LLM 应用不一样：用户问一句话，内部可能先检索两次、调用主模型、执行工具、再调用模型总结；上游断流后还可能换模型重试。只记录入口 latency 和 status=200，看不出回答为何错，也算不清真实成本。

我把 run 定义成一次用户意图的完整处理，下面挂 retrieval、model attempt、tool call、policy decision 和 finalization。HTTP request 是承载方式之一，不是业务身份。所有事件通过 run_id 串起来，最终状态由证据归并得出。

多接几家模型后，网关很容易加一条“失败就切下一个”的逻辑。它能缓解单供应商不可用，却不是完整路由：备用模型可能不支持 function calling、上下文不够、数据地域不合规，或者虽然 HTTP 成功，业务输出已经无法使用。

我把路由分成两步。先用硬约束过滤出“有资格执行”的模型，再在候选中按具体任务的成功率、延迟和成本选择。fallback 也必须重新通过硬约束，不能为了可用性把安全与能力要求降掉。

模型开启 stream=true 后，客户端能更早看到文字，接口看起来只是从一次 JSON 响应变成多次回调。实现里最常见的 bug，是每收到一个网络 chunk 就 JSON.parse，或者把每个 data: 行当成完整业务消息。

TCP/HTTP 传输分片、SSE 事件和模型增量是三层边界。它们恰好可能对齐，但协议从未保证对齐。我会先把字节流解析成完整 SSE event，再把供应商 event 归一化，最后由状态归并器构造答案。

模型网关第一版通常很像反向代理：统一鉴权，替换 endpoint，把 messages 转给不同供应商。真正接入多个模型后，会发现最难的不是请求字段，而是每家对流式增量、结束原因、工具调用、错误和用量的表达都不同。

如果网关只输出一套“看起来统一”的 JSON，却不保存转换前证据，线上出现空回答、工具参数残缺或 HTTP 200 后中途断流时，无法判断问题来自供应商、适配器还是客户端。我会同时保留原生协议轨和统一语义轨，两者用同一个 request ID 关联。