最近在重构一个 AI Agent 项目时,我意识到一个问题:

现在 AI 应用最大的成本,已经不是 Prompt 了。

而是:

模型接入与切换成本

尤其项目从 Demo 进入正式工程阶段后,这个问题会迅速放大。


一、最开始,我也只接 OpenAI

一开始的架构其实很简单:

client = OpenAI(api_key=xxx)

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages
)

那时候大家默认:

  • GPT 最强
  • OpenAI 就是标准答案
  • 能跑起来最重要

但后面随着业务复杂度增加,问题越来越明显。


二、AI 工程开始出现“模型分工”

后来我们发现:

不同模型其实适合不同任务。

比如:

场景 更适合的模型
代码生成 Claude
中文问答 Qwen
推理任务 DeepSeek
长上下文 Gemini
低成本批量生成 开源模型

于是项目逐渐变成:

一个业务
调用多个模型

问题也随之而来。


三、最麻烦的不是 Prompt,而是接口兼容

真正让人头疼的是:

不同模型之间并没有真正统一。

虽然很多都“兼容 OpenAI API”,但实际细节差异非常多。

比如:

1. Tool Calling 不兼容

有些支持:

  • function calling

有些支持:

  • tool use

还有些:

  • JSON schema 行为不同

Agent 一复杂,问题马上出现。


2. 上下文限制不同

有些模型:

  • 128K

有些:

  • 32K

有些:

  • 长文本稳定性很差

结果:

  • chunk 策略不同
  • memory 策略不同
  • RAG 参数不同

整个系统会越来越碎。


3. 返回格式不稳定

尤其做 Workflow 时最明显。

同样 Prompt:

某些模型:

  • JSON 非常稳定

某些模型:

  • 经常夹带解释文本

最后不得不写大量:

try:
    json.loads(content)
except:
    repair_json(content)

这些其实都不是业务逻辑。

但会消耗大量工程时间。


四、后来我开始把“模型层”单独抽象出来

后面重构时,我开始把 AI 调用独立成:

AI Gateway Layer

架构变成:

业务层
  ↓
AI Gateway
  ↓
不同模型提供方

这样做以后,最大的变化是:

1. 业务不再感知模型差异

业务代码只关心:

generate_text()
call_tools()
embedding()
rerank()

至于底层:

  • OpenAI
  • Claude
  • DeepSeek
  • Gemini

全部隐藏。


2. 模型切换成本极低

以前切模型:

改 SDK
改参数
改 Prompt
改解析逻辑

现在:

改配置

这个差距非常大。


3. 更适合 Agent 系统

Agent 最大的问题其实是:

稳定性

因为:

  • 多轮调用
  • 工具调用
  • 长上下文
  • 状态管理

都会放大模型差异。

如果底层接口不统一,
整个 Agent Workflow 会非常脆弱。

所以后来我越来越倾向于:

模型可替换
接口标准化

而不是:

  • 深度绑定某一家模型

五、为什么现在越来越多人在做“AI 中间层”?

因为 AI 工程已经开始 Infra 化。

现在很多系统其实都在做:

  • AI Router
  • AI Gateway
  • Model Proxy
  • Multi-LLM Dispatch
  • Prompt Middleware

本质上和以前:

  • 数据库中间件
  • API Gateway
  • Service Mesh

是同一种思路。


六、最近测试了一个比较顺手的方案

最近在调试多模型 Workflow 时,我试了下:

AIKOpen

一开始只是因为:

支持 OpenAI 兼容接口

所以迁移成本比较低。

后面发现这种统一接口方案,在下面这些场景确实挺方便:

  • AI Agent
  • Workflow 编排
  • 多模型切换
  • Prompt AB Test
  • 成本控制
  • 模型 fallback

尤其是做:

模型路由

的时候,会明显轻松很多。


七、现在 AI 开发最重要的,其实是“解耦”

这半年最大的感受就是:

AI 模型变化速度太快了。

今天最强的模型,
可能几个月后就被替代。

所以工程上更合理的做法其实是:

业务逻辑
不要绑定具体模型

而是:

绑定能力接口

比如:

  • 推理能力
  • Embedding 能力
  • Tool Calling 能力
  • Rerank 能力

至于底层是谁提供,
其实应该可替换。


八、总结

现在 AI 开发已经开始从:

“调用模型”

进入:

“管理模型”

阶段。

后面真正复杂的,
可能已经不是 Prompt Engineering。

而是:

  • 模型调度
  • 成本控制
  • 稳定性
  • 兼容层
  • 工作流编排

这些工程问题。

所以我现在越来越觉得:

AI 系统最终比拼的,可能不是谁接了最新模型。

而是谁把:

模型抽象层

做得更稳定。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐