很多团队会用 LiteLLM 类代理或统一 AI Proxy 来连接多家模型供应商。它们的优点很明显：统一 OpenAI 兼容接口、支持多模型路由、能做虚拟 Key、预算、限流和成本统计。
但代理层一旦进入生产，也会变成关键基础设施。它管着上游 key、模型权限、账单和日志，所以测评时不能只看“能不能转发”。
1. 虚拟Key是不是按团队和用途拆分
生产环境不应该让所有应用共用一把 key。更合理的做法是按团队、项目、环境和用途创建虚拟 Key。
检查项包括：
- 是否能限制 key 可访问的模型
- 是否能设置单 key 预算
- 是否能设置 RPM / TPM
- 是否能快速停用或轮换
- 是否能追踪 key 的调用历史
如果虚拟 Key 只是一个转发凭证，没有预算和模型权限，那治理价值会大打折扣。
2. 模型白名单是否默认收紧
多模型代理最常见的问题，是模型列表越来越多，最后谁都能调贵模型。安全的默认策略应该是：新 key 默认不能访问高价或高风险模型，需要显式授权。
尤其要检查：测试环境是否能调生产模型，普通脚本是否能调高价推理模型，外包或临时项目是否有过宽权限。
3. 管理密钥是否被隔离
代理层通常有 master key 或管理员凭证。它不应该出现在业务代码、前端、普通 CI 日志或共享文档里。
管理密钥只应该用于创建和管理虚拟 Key，而业务调用应该使用受限 key。这个边界如果没守住，后面的权限设计都会失效。
4. 预算是否真的能阻断请求
预算功能不能只停留在看板上。测评时应该实际验证：超过预算后，请求是否会被阻断，错误信息是否清晰，是否会出现并发下预算绕过的问题。
同时，要区分硬限制和软提醒。软提醒适合人工跟进，硬限制适合测试环境、临时项目和高风险 Agent。
5. 日志是否默认脱敏
AI 代理会看到 prompt、response、headers、错误信息和上游返回。日志里最容易泄露的是：Authorization、用户隐私、内部系统提示、数据库字段和业务文档片段。
上线前要确认：敏感字段是否 masking，谁能看原文日志，日志保留多久，导出时是否仍然脱敏。
6. 为什么可以用中转站先收口
如果团队暂时不想自己维护完整代理系统，可以先用 https://top-api.cc 这样的统一入口承接多模型调用，把 key、模型路由和成本观测集中起来。后续再根据业务成熟度决定是否自建更复杂的网关。
结语
LiteLLM 类代理的价值不只是“一个接口调多家模型”，更重要的是治理能力。虚拟 Key、预算、模型白名单、管理密钥隔离和日志脱敏，才是生产测评里真正该逐项打勾的内容。
Leave a Reply