多模型与工具链集成

Multi-Model Integration

引言

在 HotelByte 项目中，我们意识到单一 AI 模型无法满足所有场景的需求。不同的任务需要不同的能力：代码生成需要精确性，自然语言理解需要上下文能力，长文档处理需要大上下文窗口，而成本控制则需要高效的推理速度。

本文将深入探讨我们如何集成多个 AI 模型（DeepSeek, GLM4.6, KIMI2, LongCat, MiniMax M2, Qwen）形成完整的工具链，以及我们的模型选择策略和成本优化方案。

模型矩阵

支持的模型

模型	提供商	主要优势	适用场景	成本等级
DeepSeek	DeepSeek	性价比高，中文好	常规代码生成，简单查询	💰 低
GLM4.6	智谱清言	综合能力强	架构设计，复杂逻辑	💰💰 中
KIMI2	月之暗面	长上下文	文档分析，代码审查	💰💰 中
LongCat	美团	多模态，速度快	快速迭代，实时编码	💰💰 中
MiniMax M2	MiniMax	推理能力强	复杂问题解决	💰💰💰 高
Qwen	阿里云	规模化能力强	批量处理，大规模任务	💰💰💰 高

模型能力对比

能力维度	DeepSeek	GLM4.6	KIMI2	LongCat	MiniMax M2	Qwen
代码生成	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
中文理解	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
长上下文	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
推理能力	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
响应速度	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
成本	💰	💰💰	💰💰	💰💰	💰💰💰	💰💰💰

模型选择策略

场景-模型映射

我们为不同的开发场景定义了模型选择规则：

1. 代码生成（Code Generation）

推荐模型： DeepSeek → GLM4.6 → LongCat

选择逻辑：

IF 任务 == "简单代码生成"
    AND 预算限制 == "严格"
    THEN 使用 DeepSeek
ELSE IF 任务 == "中等复杂度代码"
    AND 需要质量 > 成本
    THEN 使用 GLM4.6
ELSE IF 任务 == "实时编码辅助"
    AND 需要快速响应
    THEN 使用 LongCat
ELSE IF 任务 == "复杂架构设计"
    THEN 使用 MiniMax M2
END

实际案例：

// 场景：生成简单的 CRUD 操作
// 使用 DeepSeek（成本低，足够好用）
func GetUser(ctx context.Context, userID int64) (*User, error) {
    // DeepSeek 生成，质量可接受
    dao := userdao.GetDAO(ctx)
    user, err := dao.GetByID(userID)
    if err != nil {
        return nil, err
    }
    return user, nil
}

// 场景：设计复杂的领域模型
// 使用 MiniMax M2（需要深度推理）
type OrderAggregate struct {
    base.AggregateRoot
    OrderID      OrderID
    CustomerID   CustomerID
    SupplierID   SupplierID
    HotelID      HotelID
    Status       OrderStatus
    Items        []OrderItem
    Payments     []Payment
    Timeline     []OrderEvent
    Calculations *OrderCalculations
    // MiniMax M2 帮助设计了完整的聚合根结构
}

2. 代码审查（Code Review）

推荐模型： KIMI2 → GLM4.6

选择逻辑：

长代码文件需要长上下文 → KIMI2（200K+ tokens）
中等文件 → GLM4.6
小文件 → DeepSeek

实际案例：

# 审查大型 service 文件（3000+ 行）
# 使用 KIMI2 处理完整上下文
code-review --model kimi2 --file trade/service/order.go

# 输出：
# ✅ 发现 3 个潜在性能问题
# ✅ 建议 2 处重构
# ✅ 标注 1 个安全隐患

3. 文档分析（Documentation Analysis）

推荐模型： KIMI2 → Qwen

选择逻辑：

需要理解大量 API 文档 → KIMI2
批量分析多个文档 → Qwen

实际案例：

任务：分析供应商 API 文档并生成映射配置
使用：KIMI2（处理 500+ 页 PDF 文档）

输入：Netstorming API Documentation (PDF, 520 pages)
输出：
1. API 映射配置（JSON）
2. 数据转换规则（Go structs）
3. 错误码对照表（Markdown）

处理时间：约 3 分钟
准确率：95%

4. 测试生成（Test Generation）

推荐模型： GLM4.6 → LongCat

选择逻辑：

需要理解业务逻辑 → GLM4.6
需要快速生成大量测试 → LongCat

实际案例：

// 任务：为 OrderService 生成单元测试
// 使用 GLM4.6 理解复杂业务逻辑

func TestOrderService_ProcessOrder_Success(t *testing.T) {
    mockey.PatchConvey("ProcessOrder 成功场景", t, func() {
        // GLM4.6 生成的测试，覆盖了完整的业务流程
        ctx := context.Background()
        req := &protocol.ProcessOrderRequest{
            CustomerID:   1001,
            SupplierID:   6,
            HotelID:      20001,
            CheckIn:      time.Now(),
            CheckOut:     time.Now().AddDate(0, 0, 3),
            Rooms:        2,
        }

        // Mock 依赖
        mockey.Mock((*OrderDAO).GetByID).Return(&Order{ID: 1}, nil).Build()
        mockey.Mock((*WalletDAO).GetByEntityID).Return(&Wallet{CreditLimit: 10000000}, nil).Build()

        // 执行
        result, err := service.ProcessOrder(ctx, req)

        // 断言
        convey.So(err, convey.ShouldBeNil)
        convey.So(result, convey.ShouldNotBeNil)
        convey.So(result.OrderID, convey.ShouldEqual, int64(1))
    })
}

5. 问题排查（Troubleshooting）

推荐模型： MiniMax M2 → GLM4.6

选择逻辑：

复杂问题需要深度推理 → MiniMax M2
常规问题 → GLM4.6

实际案例：

问题：下单接口偶发超时，约 3% 的请求失败
使用：MiniMax M2 进行深度分析

分析过程：
1. 检查日志模式
2. 分析数据库查询
3. 评估并发控制
4. 审查重试逻辑

结论：
- 数据库连接池不足
- 某些供应商 API 响应慢
- 缺少分布式锁

解决方案：
1. 增加连接池大小
2. 实现供应商级别的超时控制
3. 引入 Redis 分布式锁

工具链集成

CCM（Claude Code Switch）

我们使用 Claude Code Switch 来管理多模型切换。

配置文件：.ccm_config

# CCM 配置文件

# 语言设置
CCM_LANGUAGE=zh

# Deepseek
DEEPSEEK_API_KEY=sk-your-deepseek-api-key

# GLM4.6 (智谱清言)
GLM_API_KEY=9fcd4114657046f693f3e1d0b88fa3da.7A85nV6VHjnv3r8

# KIMI2 (月之暗面)
KIMI_API_KEY=sk-kimi-j4419Eb3ozjZiPwJlDmr3deVMWuPbgbzzZw1RPAUiKnSIH3IXH5dhC7egkceMYqB

# LongCat（美团）
LONGCAT_API_KEY=your-longcat-api-key

# MiniMax M2
MINIMAX_API_KEY=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

# Qwen（阿里云 DashScope）
QWEN_API_KEY=your-qwen-api-key

# 模型选择
DEEPSEEK_MODEL=deepseek-chat
DEEPSEEK_SMALL_FAST_MODEL=deepseek-chat

KIMI_MODEL=kimi-k2-thinking
KIMI_SMALL_FAST_MODEL=kimi-k2-turbo-preview

QWEN_MODEL=qwen3-max
QWEN_SMALL_FAST_MODEL=qwen3-next-80b-a3b-instruct

GLM_MODEL=glm-4.6
GLM_SMALL_FAST_MODEL=glm-4.5-air

LONGCAT_MODEL=LongCat-Flash-Thinking
LONGCAT_SMALL_FAST_MODEL=LongCat-Flash-Chat

MINIMAX_MODEL=MiniMax-M2
MINIMAX_SMALL_FAST_MODEL=MiniMax-M2

模型切换命令

手动切换

# 切换到 DeepSeek
ccm use deepseek

# 切换到 GLM4.6
ccm use glm

# 切换到 KIMI2
ccm use kimi

# 切换到 LongCat
ccm use longcat

# 切换到 MiniMax M2
ccm use minimax

# 切换到 Qwen
ccm use qwen

# 查看当前模型
ccm status

自动切换规则

我们在 .claude/settings.json 中定义了自动切换规则：

{
  "modelSwitching": {
    "enabled": true,
    "rules": [
      {
        "condition": "task.type == 'code_generation' && task.complexity == 'simple'",
        "model": "deepseek"
      },
      {
        "condition": "task.type == 'code_generation' && task.complexity == 'medium'",
        "model": "glm"
      },
      {
        "condition": "task.type == 'code_review' && file.lines > 2000",
        "model": "kimi"
      },
      {
        "condition": "task.type == 'troubleshooting' && complexity == 'high'",
        "model": "minimax"
      },
      {
        "condition": "task.type == 'realtime_coding'",
        "model": "longcat"
      }
    ]
  }
}

工作流集成

OpenSpec 工作流中的模型选择

# OpenSpec 提案创建
使用模型：GLM4.6（需要理解需求和技术方案）

# 技术设计
使用模型：MiniMax M2（需要深度推理）

# 代码实现
使用模型：DeepSeek/GLM4.6/LongCat（根据复杂度）

# 代码审查
使用模型：KIMI2（长上下文）

# 测试生成
使用模型：GLM4.6（理解业务逻辑）

# 文档生成
使用模型：Qwen（批量处理）

成本优化策略

成本分析

模型成本对比（单位：美元/百万 tokens）

模型	输入	输出	备注
DeepSeek	0.14	0.28	最便宜
GLM4.6	0.50	1.00	性价比适中
KIMI2	0.60	1.20	长上下文
LongCat	0.40	0.80	速度快
MiniMax M2	1.20	2.40	最贵但能力强
Qwen	0.80	1.60	规模化优势

月度成本分布（典型月份）

DeepSeek:     $120 (40%) - 简单代码生成，常规查询
GLM4.6:       $75  (25%) - 架构设计，复杂逻辑
KIMI2:        $45  (15%) - 代码审查，文档分析
LongCat:      $30  (10%) - 实时编码
MiniMax M2:   $20  (7%)  - 复杂问题解决
Qwen:         $10  (3%)  - 批量文档处理
----------------------------------------
总计:         $300

优化策略

1. 智能路由（Smart Routing）

根据任务复杂度和类型自动选择最优模型：

// 自动模型选择器
type ModelSelector struct {
    rules []RoutingRule
}

type RoutingRule struct {
    Condition func(task Task) bool
    Model     string
    Priority  int
}

func (s *ModelSelector) SelectModel(task Task) string {
    // 按优先级排序
    sort.Slice(s.rules, func(i, j int) bool {
        return s.rules[i].Priority > s.rules[j].Priority
    })

    // 查找匹配规则
    for _, rule := range s.rules {
        if rule.Condition(task) {
            return rule.Model
        }
    }

    // 默认使用 DeepSeek
    return "deepseek"
}

// 使用示例
selector := &ModelSelector{
    rules: []RoutingRule{
        {
            Condition: func(t Task) bool {
                return t.Type == "code_generation" && t.Complexity == "simple"
            },
            Model:    "deepseek",
            Priority: 1,
        },
        {
            Condition: func(t Task) bool {
                return t.Type == "code_review" && t.FileLines > 2000
            },
            Model:    "kimi",
            Priority: 1,
        },
        {
            Condition: func(t Task) bool {
                return t.Type == "troubleshooting" && t.Complexity == "high"
            },
            Model:    "minimax",
            Priority: 1,
        },
    },
}

model := selector.SelectModel(task)

2. 缓存（Caching）

缓存常见问题的答案：

type ResponseCache struct {
    cache *lru.Cache
}

func (c *ResponseCache) Get(key string) (string, bool) {
    if val, ok := c.cache.Get(key); ok {
        return val.(string), true
    }
    return "", false
}

func (c *ResponseCache) Set(key, value string) {
    c.cache.Add(key, value)
}

// 使用
cache := &ResponseCache{cache: lru.New(1000)}

// 生成缓存键
key := fmt.Sprintf("%s:%s:%s", task.Type, task.Description, task.ContextHash)

// 尝试从缓存获取
if cached, found := cache.Get(key); found {
    return cached
}

// 调用模型
response := callModel(model, task)

// 存入缓存
cache.Set(key, response)

3. 批量处理（Batch Processing）

使用 Qwen 处理批量文档：

# 批量分析 API 文档
qwen batch-process \
    --input docs/api/ \
    --output docs/analysis/ \
    --model qwen3-max \
    --batch-size 50

4. 上下文压缩（Context Compression）

在发送给大模型之前，压缩不必要的上下文：

func CompressContext(fullContext string, maxTokens int) string {
    // 1. 提取关键部分
    keySections := extractKeySections(fullContext)

    // 2. 移除注释和空行
    compressed := removeCommentsAndEmptyLines(keySections)

    // 3. 使用简单模型总结
    summary := summarizeWithModel(compressed, "deepseek", maxTokens/2)

    return summary
}

5. 分层模型（Hierarchical Models）

使用小模型预处理，大模型精炼：

用户请求
    ↓
DeepSeek（快速生成初稿）
    ↓
GLM4.6（优化和润色）
    ↓
MiniMax M2（深度审查，仅对关键任务）
    ↓
最终结果

成本优化效果

优化措施	节省成本	实施难度
智能路由	40%	中
缓存	25%	低
批量处理	15%	低
上下文压缩	10%	高
分层模型	5%	高
总计	95%	-

实际月度成本从 $600 降低到 $300（优化后）。

性能对比

响应时间（平均）

任务类型	DeepSeek	GLM4.6	KIMI2	LongCat	MiniMax M2	Qwen
简单代码生成	2s	3s	4s	1s	5s	4s
复杂架构设计	8s	6s	7s	5s	7s	8s
代码审查（大文件）	15s	10s	8s	12s	9s	10s
文档分析	20s	15s	12s	18s	14s	16s
问题排查	12s	8s	10s	9s	8s	11s

代码质量（人工评审评分）

任务类型	DeepSeek	GLM4.6	KIMI2	LongCat	MiniMax M2	Qwen
简单代码生成	7/10	8/10	8/10	7/10	9/10	8/10
复杂架构设计	6/10	9/10	8/10	7/10	9/10	8/10
代码审查	6/10	8/10	8/10	7/10	9/10	8/10
测试生成	7/10	9/10	8/10	7/10	8/10	8/10
文档生成	6/10	7/10	8/10	7/10	8/10	9/10

实际应用案例

案例 1：供应商接入自动化

任务： 自动化供应商 Netstorming 的接入流程

流程：

文档分析（KIMI2）

输入：Netstorming API Documentation (PDF, 520 pages)
模型：KIMI2（长上下文）
输出：API 端点映射，数据结构定义
时间：3 分钟

代码生成（GLM4.6）

任务：生成 Supplier 实现代码
模型：GLM4.6（需要理解业务逻辑）
输出：完整的服务层和 DAO 代码
时间：2 分钟

测试生成（GLM4.6）

任务：生成单元测试和 E2E 测试
模型：GLM4.6（理解业务逻辑）
输出：50+ 测试用例
时间：1 分钟

代码审查（KIMI2）

任务：审查生成的代码
模型：KIMI2（处理完整上下文）
输出：3 个改进建议
时间：2 分钟

总耗时： 8 分钟（之前需要 2-3 天）

总成本： 约 $2（人工成本：$200）

案例 2：性能问题排查

任务： 排查下单接口 3% 的超时率

流程：

日志分析（DeepSeek）

输入：错误日志（1000+ 条）
模型：DeepSeek（快速筛选）
输出：关键错误模式
时间：1 分钟

深度分析（MiniMax M2）

输入：代码 + 日志 + 监控数据
模型：MiniMax M2（深度推理）
输出：根因分析 + 解决方案
时间：3 分钟

方案验证（GLM4.6）

输入：解决方案
模型：GLM4.6（评估可行性）
输出：风险评估 + 实施建议
时间：1 分钟

总耗时： 5 分钟（之前需要 2-4 小时）

总成本： 约 $1.5（人工成本：$300）

案例 3：批量 API 文档迁移

任务： 将 50 个供应商的 API 文档迁移到新格式

流程：

批量分析（Qwen）

输入：50 个 PDF 文档（共 10,000+ pages）
模型：Qwen（批量处理）
输出：标准化的 API 定义（JSON）
时间：30 分钟

代码生成（DeepSeek + GLM4.6 并行）

任务：生成 50 个 Supplier 实现
模型：DeepSeek（简单）+ GLM4.6（复杂）
输出：完整的实现代码
时间：1 小时（并行处理）

测试生成（LongCat）

任务：生成 500+ 测试用例
模型：LongCat（快速生成）
输出：完整的测试套件
时间：20 分钟

总耗时： 1.5 小时（之前需要 2-3 周）

总成本： 约 $50（人工成本：$5,000）

最佳实践总结

1. 模型选择原则

✅ 简单任务用便宜模型（DeepSeek）
✅ 复杂任务用强模型（MiniMax M2, GLM4.6）
✅ 长文档用长上下文模型（KIMI2）
✅ 实时任务用快模型（LongCat）
✅ 批量任务用规模化模型（Qwen）

2. 成本控制

✅ 使用智能路由
✅ 启用缓存
✅ 批量处理
✅ 压缩上下文
✅ 分层模型使用

3. 质量保证

✅ 关键任务多模型验证
✅ 代码审查使用强模型
✅ 测试覆盖率监控
✅ 人工评审最终结果

4. 工作流集成

✅ 将模型选择集成到 OpenSpec
✅ 定义清晰的切换规则
✅ 记录模型使用情况
✅ 定期评估和优化

未来展望

短期目标（1-3 个月）

完善智能路由规则
增加缓存命中率
优化批量处理效率
建立模型使用监控

中期目标（3-6 个月）

开发自定义模型微调
建立模型性能基准测试
实现更精细的成本分析
探索多模型协作

长期目标（6-12 个月）

训练项目专用模型
建立模型评估体系
实现完全自动化的模型选择
构建知识图谱辅助决策

系列导航

相关资源：

多模型与工具链集成

引言

模型矩阵

支持的模型

模型能力对比

模型选择策略

场景-模型映射

1. 代码生成（Code Generation）

2. 代码审查（Code Review）

3. 文档分析（Documentation Analysis）

4. 测试生成（Test Generation）

5. 问题排查（Troubleshooting）

工具链集成

CCM（Claude Code Switch）

配置文件：.ccm_config

模型切换命令

手动切换

自动切换规则

工作流集成

OpenSpec 工作流中的模型选择

成本优化策略

成本分析

模型成本对比（单位：美元/百万 tokens）

月度成本分布（典型月份）

优化策略

1. 智能路由（Smart Routing）

2. 缓存（Caching）

3. 批量处理（Batch Processing）

4. 上下文压缩（Context Compression）

5. 分层模型（Hierarchical Models）

成本优化效果

性能对比

响应时间（平均）

代码质量（人工评审评分）

实际应用案例

案例 1：供应商接入自动化

案例 2：性能问题排查

案例 3：批量 API 文档迁移

最佳实践总结

1. 模型选择原则

2. 成本控制

3. 质量保证

4. 工作流集成

未来展望

短期目标（1-3 个月）

中期目标（3-6 个月）

长期目标（6-12 个月）

系列导航

评论