前言：多平台 AI 接入的痛苦，当事人现身说法

做独立开发这两年，我同时接了 GPT、Claude、Gemini 三个平台。每个平台的 SDK 不同、认证方式不同、响应格式不同——代码越接越多，到最后维护成了一场噩梦。

去年我同时维护三个项目：
- 🗞 资讯聚合机器人 — 接了 GPT-4o 写摘要
- 🎨 设计素材生成工具 — 接了 DALL·E 3 出图
- 📊 内部知识库问答 — 接了 Claude 3.5 做 RAG

每个平台独立接入听起来合理，但真正跑起来问题就来了：

Key 管理混乱
- 三个平台三套 Key，本地测试来回切换，生产环境配错一位是常事

SDK 风格迥异
- OpenAI 用 chat.completions.create，Anthropic 用自己的消息格式，Google Gemini 又是另一套

升级维护成本高
- SDK 每次大版本升级，改一堆业务代码，全靠人工盯着 changelog

计费分散
- 充值要在三四个平台间来回跑，账单也是分开的

这些问题积累起来，每加一个新模型就要多花大半天，纯粹是体力活。

---

思路一：自己封装一层抽象

最直觉的做法，是写一个统一的 Wrapper，把三个平台的差异封装掉：
 

class AIAggregator:
    def __init__(self):
        self.openai = OpenAI(api_key=os.getenv('OPENAI_KEY'))
        self.anthropic = Anthropic(api_key=os.getenv('ANTHROPIC_KEY'))
        self.gemini = GoogleGenerativeAI(api_key=os.getenv('GEMINI_KEY'))
    
    def chat(self, model: str, messages: list):
        if model.startswith('gpt'):
            return self.openai.chat.completions.create(model=model, messages=messages)
        elif model.startswith('claude'):
            return self.anthropic.messages.create(model=model, messages=messages)
        elif model.startswith('gemini'):
            return self.gemini.generate_content(messages)

优点： 完全自控，没有第三方依赖

缺点： 每加一个新平台要改这个类，模型多了分支越来越长，平台版本升级时要手动适配。封装层本身也成了一个维护负担。

---

思路二：借助 API 路由层

后来我开始尝试把 AI 模型调用统一到一个端点，把差异化的事情交给中间层来处理。

核心思路：客户端只对接中间层的接口规范，切换模型时只需改参数，不需要动代码。

实操：以 OpenAI SDK 为例

主流 SDK 支持 base_url 自定义，只需要把端点指向路由层地址：
 

from openai import OpenAI

client = OpenAI(
    base_url='https://<router-host>/v1',  # 统一入口
    api_key='your-router-key'              # 一把 Key
)

# 调 GPT
gpt_response = client.chat.completions.create(
    model='gpt-4o',
    messages=[{'role': 'user', 'content': '写一段产品推广语'}]
)

# 无缝切 Claude —— 改 model 参数就行，其他不变
claude_response = client.chat.completions.create(
    model='claude-opus-4-6',
    messages=[{'role': 'user', 'content': '写一段产品推广语'}]
)

关键点： 业务代码只依赖 client 实例，切换模型时改 model 参数即可，调用方式完全一致。

---

选型时我关注的核心指标

接入路由层之后，我比较在意这几个实际指标：

1. 模型覆盖 — 至少要有需要的几个主流模型，且能保持和官方同步更新
2. 接口兼容性 — 能否直接用 OpenAI SDK 或 Anthropic SDK 访问，还是必须用 Restful API
3. 响应透明度 — 延迟、Token 消耗、模型状态是否可见
4. 计费方式 — 统一充值还是按平台分开结

目前我自己在用的是 AIYUN ROUTER，主要因为它模型池相对齐全（18+ 主流模型），接口格式兼容几家主流厂商的规范，调试和切换确实省心不少。不强制推荐，大家可以根据自己需求比较。

---

踩坑总结：几条实操建议

1. 先想清楚真的需要多模型吗

如果项目只需要一个模型，直连官方 SDK 是最简单可靠的。多模型接入适合确实有对比需求、或不同业务用不同模型的场景。

2. 封装层尽量做薄

抽象层一旦变厚，维护成本会抵消它带来的好处。核心只做路由分发，不要在中间层堆业务逻辑。

3. 计费一定要盯紧

多模型统一计费虽然方便，但也容易忽略单个模型的实际消耗。建议在路由层开启用量告警，防止某个模型悄悄吃光预算。

4. 关注模型版本更新节奏

官方模型更新很快，路由层如果跟进不及时，可能会遇到 "model not found" 的问题。选型时看看维护活跃度。

---

最后

多 AI 模型接入没有银弹，关键是明确自己的需求边界。如果只是懒得管理多套 Key，一个简单的 Wrapper 或者现成的路由层都可以解决问题。如果是需要对模型做精细化管理（比如成本优化、延迟对比），一层统一的抽象会更值得投入。

---

本文思路供参考，具体工具选型请根据项目实际需求评估。