架构

团队里用的 AI 服务越来越多——OpenAI、Deepseek、通义、豆包、Claude……每个平台一套 API、一套 Key、一套计费口径。配置越来越乱，调用越来越散，于是总有人会提出： 要不我们自己搭一个 AI Gateway 吧？自建，或者买个现成的。 这个想法非常自然。我也有过。 搭建一个 AI Gateway 一次解决所有的问题，多好的 KPI 叙事。 但是，仔细一想，把账一算，我决定放弃在公司里自建 AI Gateway。 先给结论 对绝大多数公司来说，自建或购买 AI Gateway 的 ROI 都很低。 注意，决定性的因素不是你用了多少种 AI 服务。哪怕你接了十几个平台，只要项目规模没到、团队能力没到，这笔投入依然不划算。 真正划算的前提只有一个组合：项目数足够多，且你本来就有一支扛得住 7×24 的运维/平台团队。 否则，你大概率是在用一个永久性的负债，去换一两天就能消化掉的麻烦。 下面展开说为什么。 一、AI Gateway 到底解决了什么 先得承认，AI Gateway 的确能解决公司的一些问题： 多平台 fallback：同一个模型要在多个供应商之间兜底。比如 Deepseek，要做 Deepseek 官方 → 火山引擎 → 阿里云百炼 的 fallback 路径，每个业务都得自己写一遍。 API Key 轮换要重启服务：换一次 Key 就得重启应用。三个服务用到了就至少轮换三次，再乘上多环境（dev / staging / prod），数字很快就上去了。 请求监控各自为政：对 AI 调用的监控，每个业务都得自己实现一套。 接口不统一：想换模型，就得重新对接一个平台的 SDK，而不是一套接口打天下。 申请 Key 流程慢：业务向运维申请 Key，走流程要时间。 成本统计粒度粗：很多 AI 平台的成本统计很弱，做不到按 Key 或按 Project 维度归集，只能在业务代码里自己埋点。 这听起来非常的美好，也很能打动老板们。 ...

All problems in computer science can be solved by another level of indirection – David Wheeler 计算机科学中的任何问题，都可以通过加上一层逻辑层来解决。– David Wheeler 总之，分层就是有好处 在计算机领域，“分层” 概念无处不在。比如 web 开发时的 MVC ，网络编程时的 OSI 参考模型和 TCP/IP 协议族。 但是为什么要进行分层呢？不同的书有不同的说法。 在《图解TCP/IP》这本书这样说： 在这一模型中，每个分层都接收它下一层所提供的特定服务，并且负责为自己的上一层提供特定的服务。上下层之间进行交互时所遵循的约定叫做“接口”。 在我看来，说了等于白说。:-P 而《企业应用架构模式》开篇第 1 章是这样说的： 在分解复杂的软件系统时，软件设计者用得最多的技术之一就是分层。 当用分层的观点来考虑系统时，可以将各个子系统想像成按照“多层蛋糕”的形式来组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。 Marting Fowler在第 1 章后面，又举了一个表现层，领域层，数据源层的例子。但是个人认为依然没有把为什么要分层说透。 对于为什么要分层，我见过的大多数文章说的只是它带来的好处。比如下层修改实现，不影响上层使用；分离关注点等。但是为什么会带来这些好处？看似很傻的一个问题，其实很难回答。 两个例子帮助你认识“分层” 我们先通过两个例子给大家一些感性的认识。 自动驾驶 用分层的思维来看开车这件事情是这样的： 分层 具体内容 人的意图 前行，不上坡，右转弯 人的操作 踩着油门，瞥一眼后视镜，方向盘打右 汽车运行 根据踩下油门的程度，发动机输出动力，而方向盘打右转动转向拉杆 发动机 进气，压缩，点燃，排气 更底层省略…. 更底层省略 ….. 因为有了分层，当我们要实现自动驾驶汽车时，要解决的就只是“人的操作”这一层的问题，而不需要实现“人的操作”以下所有的层，也就是不需要自己从头造汽车（不是绝对，但是绝对不需要从头造所有的部分）。 IoT 云云对接 总要举一个软件开发领域的例子吧。我们举一个 IoT 云云对接的例子。 当第三方云想控制 M云的空调时，系统的外观是这样的： ...