一、项目背景

我们运维的 AI 网关统一接住了公司内部十几条业务线对大模型能力的调用。早期网关对请求体几乎是"来者不拒"，只做了最基础的鉴权。结果没少踩坑：有调用方把字段名拼错、类型传成字符串而不是数字，网关照单全收转给后端模型服务，模型服务解析失败直接抛 500，连带把正常请求也拖慢了；还有一次超大且结构畸形的请求体把后端内存打满，整组实例抖动。我们当时定下一条原则：网关是第一道门，坏请求不能进后端，能填的缺省值填上，填不了的快速拒，后端异常要有兜底。

二、落地场景

我们在网关接入层加了"请求体 JSON Schema 校验"：每个模型接口声明自己的入参 schema（必填字段、类型、取值范围、枚举）。请求进来先过校验，缺字段且可给缺省值的自动补（比如没传 temperature 就填默认 0.7），类型错的尝试安全转换，转换不了或命中非法值的直接返回 400 并附明确错误原因。后端模型服务若超时或异常，网关按策略降级：先切到同能力的备用实例，再不行降级到兜底的小模型给"尽力而为"的回答，而不是把错误甩给调用方。所有拦截和降级都记到可观测看板，方便反查是哪个调用方在乱来。

三、关键技术挑战与解决思路

第一个挑战是 schema 的维护成本。十几个接口各自一套 schema，改起来容易漏。我们把 schema 和后端模型服务的接口定义同源管理，后端改了参数，网关 schema 自动同步，避免两边漂移。第二个挑战是"过度拒绝"——校验太严会把本来能用的请求挡掉。我们的策略是"可修复的先修复、不可修复的才拒"，并对缺省值填充做白名单，只允许安全、无副作用的默认值。第三个挑战是降级的选择，不能盲目兜底导致回答质量崩盘。我们给降级分了层级：实例级故障切同模型备用实例（质量不变），模型级故障才切兜底模型，并给响应打"降级"标记让调用方知情，由调用方决定是否接受。

案例片段（已脱敏）： 一次非法请求拦截——某调用方传入 {"model":"xx","messages":[{"role":"user","content":123}]}，content 应为字符串却传了整数。Schema 校验命中 type 错误，网关返回 400 INVALID_PARAM: messages[0].content expected string, got integer，并在看板标记该 app_id 当日第 3 次类型错误。调用方当日修复后此类 400 归零，后端模型服务异常率由约 1.8% 降到约 0.3%。 降级配置片段：on backend_timeout: step1=retry_other_replica(same_model); step2=fallback_to(model="lite", tag="degraded"); max_total_latency=1500ms。一次主模型实例故障中，降级命中率约 97%，未命中部分由调用方重试，无请求直接失败给用户。

四、效果数据

上线一个季度，网关拦截的非法请求占总量约 3.4%，这些请求此前会穿透到后端造成异常。后端模型服务的异常率因此从约 1.8% 降到约 0.4%。降级机制在后端实例故障期间兜底命中率约 97%，用户侧基本无感。网关 P99 延迟在接入校验后不升反降约 8%，因为坏请求被挡在更前面、不再占用后端排队资源。数字为脱敏示意值。

五、可复用经验总结

第一，网关必须对请求体"先验身"，坏流量挡在门外比后端容错便宜得多。第二，容错要分"可修复"和"不可修复"，能填缺省值就填，别一刀切拒绝。第三，降级要分层、要打标，调用方有知情权。第四，schema 要和后端同源维护，否则早晚漂移出事故。这套"Schema 校验 + 安全缺省 + 分层降级"的接入层设计，成了我们 AI 网关的标配第一道防线。

附：工程落地细节

Schema 的维护我们做了同源管理：网关的入参 schema 和后端模型服务的接口定义来自同一份契约文件，后端改了参数，网关 schema 自动同步生成，避免两边漂移导致校验形同虚设。缺省值填充我们用了白名单机制，只允许安全、无副作用的默认值（如 temperature 默认零点七、top_p 默认一），绝不自动补任何会改变业务语义的字段。降级分了清晰层级：实例级故障先切同模型备用副本（质量不变），模型级故障才切兜底小模型，并在响应头打 degraded 标记让调用方知情，由调用方决定是否接受这个"尽力而为"的回答。

附：给同行的一点提醒

网关必须对请求体先验身，坏流量挡在门外比后端容错便宜得多，我们之前不在意这层，坏请求穿透把后端内存打满的事故吃过不止一次。容错要分可修复和不可修复，能填缺省值就填，别一刀切拒绝，否则正常调用也会被误伤。降级要分层、要打标，调用方有知情权。schema 一定要和后端同源维护，否则早晚漂移出线上解析失败的事故。

附：一点落地后的量化补充

校验拦截的看板我们按调用方维度开放，哪家 app_id 的非法请求多一目了然，我们据此推动调用方整改，两周内头部三家调用方的类型错误归零。降级命中时的响应我们统一打了 degraded 标记，调用方可以据此决定是否走自己的补偿逻辑，实际观察约九成七的降级用户侧无感，只有约三成的调用方会真的去读这个标记做二次处理。网关整体的稳定性因此上了一个台阶，后端模型服务不再被坏请求偷袭。

附：小结

把校验和降级放在网关接入层，本质上是用"前置防御"换"后端稳定"。我们算过一笔账：每拦掉一个坏请求，后端就少一次异常处理的开销，长期来看后端实例可以配得更紧凑，省下的算力成本比网关多做的那点校验工作高出一个数量级。所以这道门不是成本，是投资。