用中转或网关调大模型，安全边界在哪？六个必须问清的问题
中转和网关解决的是「一个 key 调多家」的便利问题，代价是你的请求要经过第三方。方便和风险是同一件事的两面，判断能不能用，取决于你的数据是什么性质。
这篇给六个必须问清的问题。聚合与中转的形态对比见 API 聚合与中转对比。
问题一：数据流向哪里
你的完整请求（system prompt、用户输入、检索到的文档、代码）都会经过中转层。这意味着：
- 中转方能看到你的全部输入和输出
- 中转方可能存储这些内容（用于计费、调试、或其他用途）
- 数据可能跨越你不知道的网络边界
对公开信息、玩具项目、个人学习，这通常无所谓。对企业代码、客户数据、未发布产品信息，这是需要正式评估的事，不是技术选择。
问题二：日志留存多久、给谁看
问清楚三件事：请求内容是否落盘、留存多久、内部谁能访问。
正规服务会在文档或协议里写明。写得含糊或者干脆没写的，就按「可能全存」来评估风险。
顺带一提，自己的日志也要注意。很多团队在自己的调用层里把完整 prompt 打进日志，然后日志进了一个所有人都能看的平台——这个泄漏路径和中转方无关，但同样真实。
问题三：密钥归谁
两种模式，风险不同：
模式 A：你把原厂密钥交给中转方。 中转方用你的密钥调用。风险最高——密钥泄漏等于你的账户被别人用，而且用量和账单都算你的。
模式 B：中转方发给你一把它自己的密钥。 你的原厂密钥不出手。风险低一些，但你和原厂之间隔了一层，出问题时排查链路更长。
如果一定要用模式 A，至少给中转方发一把权限最小、额度受限、可随时吊销的独立密钥，绝不用生产主密钥。密钥管理规范见 API Key 安全管理。
问题四：可用性责任在谁
多一层就多一个故障点。中转挂了，你的服务就挂了，而你对它的运维一无所知。
评估时问：有没有状态页、有没有可用性承诺、故障时怎么通知、有没有备用节点。
工程上的对策是保留直连能力：代码里能一键切回原厂直连。这个开关平时不用，但值得留着，做法见 Agent 的多模型路由策略里的故障切换部分。
问题五：计费是否透明
中转方通常在原厂价上加价，或者用自己的计价体系。要问清楚：
- 加价比例是多少，还是另一套定价
- token 计数以谁的为准（中转方的统计和原厂可能不一致）
- 有没有最低消费、有效期、退款规则
- 能不能看到明细账单
计数口径不透明是最容易吃亏的地方。做法是自己也记一份用量（从响应的 usage 字段取），定期和账单对一遍。对不上就该问了。价格核对的通用方法见大模型 API 的最新价格去哪查。
问题六：合规资质是否匹配你的场景
企业场景下，这一条往往是决定性的，而且不是技术团队能单独拍板的：
- 服务方的主体是谁、在哪注册
- 有没有相关的资质和安全认证
- 数据处理协议能不能签
- 出了事故责任怎么划分
个人项目可以跳过这一节；企业项目请把这一节交给法务和安全同事，别自己判断。
自建网关：另一种选择
如果你的诉求主要是「统一管理多家密钥、统一记账、统一限流」，而不是「省事地拿到某家的额度」，那自建网关是更干净的方案：
优点：数据不出你的边界、密钥你自己管、计费你自己算、可以按需定制路由和限流策略。
代价：一个需要运维的服务。要考虑高可用、监控、升级。
折中做法：自建一层很薄的转发（只做密钥管理、用量记录和路由），不做复杂功能。这一层代码量不大，但把上面六个问题里的前五个都消解了。
自建薄网关该做哪几件事
如果决定自建，一层很薄的转发就能解决大部分问题，不需要做成完整的 API 网关产品。建议只做这五件事：
一、密钥托管。 原厂密钥只存在网关这一层，业务侧拿网关发的内部凭证。这样密钥不散落在各个服务和开发者机器上，轮换也只需改一处。
二、用量记录。 每次调用记下调用方、模型、输入输出 token、耗时、是否命中缓存。这是成本归因和优化的基础，见 API 成本监控。
三、限速与配额。 按调用方设速率上限和额度上限，防止某个业务把额度吃光。原理见 RPM 和 TPM 是什么。
四、路由与降级。 按模型别名路由到具体厂商，某家故障时自动切换。策略见 Agent 的多模型路由策略。
五、错误归一。 把各家的错误结构映射成统一类型，上层只认几种标准错误。
不建议在这一层做的：内容审核、复杂的提示改写、结果缓存。这些和业务耦合太深，放在网关里会让它变成一个谁都不敢改的东西。
上线前的安全自查
无论用第三方还是自建，上线前过一遍这几条：
- 密钥有没有进代码仓库、有没有进前端产物
- 日志里有没有完整 prompt 和密钥明文
- 网关本身的访问控制做了吗（内网限制、鉴权）
- 出站流量走的是哪条链路，有没有经过意料之外的第三方
- 出问题时能不能快速吊销单个调用方的凭证
最后一条特别容易被忽略：如果所有服务共用一把内部凭证，那么某个服务出问题时你只能全部吊销，等于全线停摆。按调用方发凭证，成本很低但关键时刻能救命。
一条实用的判断线
数据敏感度决定方案：
- 公开信息、学习实验 → 中转随便用，图方便
- 内部数据、客户信息 → 自建网关或直连原厂
- 受监管的数据（个人信息、金融、医疗等） → 直连原厂，且走合规评估流程
判断依据是数据性质，不是项目大小。一个小项目处理客户身份信息，也该按高标准来。
三个高频问题
问：中转比直连便宜，是不是就该用？ 便宜的前提是你能接受数据经过第三方。数据敏感度决定方案，价格只是次要因素。
问：怎么判断一家中转靠不靠谱？ 看它敢不敢把数据处理条款写清楚、有没有状态页和故障公告、能不能开正规发票。三项都含糊的建议避开。
问：自建网关要投入多少？ 只做密钥托管、用量记录、限速、路由、错误归一这五件事的话，代码量不大，但要按内部服务的标准做监控和高可用。