Java架构师的AI转型之路（下）：模型层与平台化架构
系列文章：总篇 · 上篇 · 中篇 · 下篇
接中篇
在中篇中，我详细拆解了 Phase 2 的实战过程——从Agent基础（ReAct/Tool Use）到多Agent协作（LangGraph状态机），从人工审核节点到Java侧的服务治理集成。
如果你跟着做到了这一步，那么现在你已经能让AI自主完成复杂任务了。
但作为一个消费者，很快会和我一样意识到一个问题：
我们不可能让所有请求都走 GPT，太贵了，而且很多时候根本不需要那么强的模型！
于是进入 Phase 3——模型层与平台化。这也是整个转型的"分水岭"：从"用AI做项目"升级到"为整个组织设计AI基础设施"。
本文是系列文章的下篇，也是终章。
一、模型选型：为什么"一个模型打天下"是错的
很多团队刚开始用AI时，所有人的默认选择都是 GPT 或 Claude。这是最贵的"懒政"。
不同任务对模型能力的需求差异巨大：
| 任务类型 | 所需能力 | 推荐模型 | 单次成本（估算） |
|---|---|---|---|
| 简单问答/分类 | 基础理解 | Qwen / GLM | ¥0.001-0.01 |
| 代码生成/补全 | 代码能力 | DeepSeek / CodeLlama | ¥0.01-0.05 |
| 复杂推理/分析 | 深度思考 | GPT / Claude | ¥0.1-0.5 |
| 多模态/视觉 | 图文理解 | GPT / Qwen | ¥0.2-1.0 |
| 长文档摘要 | 长上下文 | Claude（200K窗口） | ¥0.1-0.3 |
| 金融专业问答 | 领域知识 | 微调后的领域模型 | 取决于部署方式 |
差距是 100 倍。如果你让所有请求都走最贵的模型，一年下来成本可能是百万级别的。
1.1 智能路由：用"小模型做初筛，大模型做终审"
这里的设计思路借鉴了负载均衡算法：
用户请求 ↓ ┌─────────────────────────────┐ │ 模型路由网关 │ │ │ │ ① 意图分类（小模型/Qwen） │ ← 判断这是什么类型的任务 │ ② 复杂度评估 │ ← 简单/中等/复杂 │ ③ 路由决策 │ │ ├─ 简单 → Qwen │ ←（便宜，延迟低） │ ├─ 中等 → DeepSeek │ ←（性价比高） │ └─ 复杂 → GPT │ ←（强，但贵） │ │ │ ④ 降级策略 │ ← 主模型挂了自动切备用 └─────────────────────────────┘ ↓ 返回结果1.2 路由网关代码实现
# model_router.pyimportopenaifromenumimportEnumclassTaskComplexity(Enum):SIMPLE="simple"# 分类、短问答、关键词提取MEDIUM="medium"# 代码生成、摘要、翻译COMPLEX="complex"# 多步推理、分析报告、创意写作# 模型配置MODEL_CONFIG={TaskComplexity.SIMPLE:{"model":"qwen","max_tokens":512,"temperature":0.3,"cost_per_1k":0.001,# 元},TaskComplexity.MEDIUM:{"model":"deepseek","max_tokens":2048,"temperature":0.5,"cost_per_1k":0.014,},TaskComplexity.COMPLEX:{"model":"gpt","max_tokens":4096,"temperature":0.7,"cost_per_1k":0.3,},}classModelRouter:def__init__(self):self.client=openai.OpenAI()self.classifier=self._init_classifier()def_init_classifier(self):"""用小模型做意图分类，极快极便宜"""returnopenai.OpenAI()# 实际可用本地部署的Qwendefclassify_task(self,user_message:</
