下一段路：建立跨模型家族的 AI 实践

前面五章把道理讲透了。这一章聊点实在的：到底怎么落地。

阻力是真实存在的

Gartner 2025 年的评估显示，只有 15% 的 IT 应用负责人在考虑、试点或部署完全自主的 AI agent。注意，这里说的是 fully autonomous agent，不是广义上的 AI 应用（大多数公司多少都在用 AI 了），但这个数字足以说明 multi-agent 的采用还处在非常早期的阶段。Tray.ai 的企业调研也印证了这一点：安全顾虑依然是头号拦路虎，53% 的管理层和 62% 的一线开发者都提到了它。

集成复杂度、人才短缺、组织惯性——这些让多 AI 落地比单供应商方案难得多。连接多个 provider 意味着要维护多套 API 契约、认证体系、rate limit 策略和错误处理逻辑。能搞定 multi-agent 架构的工程师不好招。要让组织在"现在跑得挺好"的单供应商系统上增加复杂度，你得拿出过硬的商业论据。

但这些问题，当年 multi-cloud 运动全遇到过。供应商锁定担忧、集成复杂度、安全顾虑、组织阻力——一个不少。Multi-cloud 花了 5 到 7 年，从边缘理念走到大约 86% 的采用率。Multi-AI 走在同一条曲线上，只是还更靠前。

好在，让多模型工作流更易用的工具正在降低集成门槛——OpenRouter、LiteLLM、各类 model gateway。它们还年轻，但已经能让你把一个任务交给一个模型生成、另一个 model family 来审查，而不需要重构整个技术栈。

选对组合

第 5 章从成本优化的角度聊了模型选择：选够用且便宜的，别浪费钱。这一节换个角度——从战略层面看：哪些 model family 组合能为你的具体领域提供最好的覆盖。

正确的方向不是"加更多模型"，而是选互补的 model family。不同 AI 家族各有特点：

视觉和多模态：Gemini 和 GPT-4o 在图像理解与语言处理结合的任务上领先。如果你的工作流涉及视觉输入——文档扫描、图表解读、UI 分析——你需要能原生处理 vision 的 model family。

代码生成和推理：Claude 和 Codex 擅长结构化代码输出、复杂 reasoning chain、以及遵循细致的指令。在软件工程任务中，这些家族往往能产出更高质量的初始结果。

低成本审查：Qwen、MiniMax 以及其他开源或高性价比模型，能以较低成本提供独立视角。即使它们在单模型 benchmark 上分数没那么高，训练数据的差异仍然让它们在跨家族审查中很有价值。

垂直领域：针对特定领域 fine-tune 的模型，在医学术语、法律判例、金融建模这类窄场景中，往往能超过通用模型。

最好的多 AI 架构不是 10 个模型各干各的同一件事，而是 2 到 3 个模型互相补位。Claude + GPT 的组合能用两种不同的训练视角覆盖代码和通用推理。再加一个 Qwen 或 MiniMax 做第三方审查员，花很少的钱就多一个视角。互补性比单个模型的能力更重要——这就是第 2 章集成研究的实战应用。

成熟度模型

根据我在不同组织观察到的模式以及自己的实践经验，多 AI 的采用通常会沿着这条路径演进：

Level 0，单模型。一个 provider，手写 prompt。大多数个人和小团队从这里起步。低风险任务它能搞定，但模型的盲区就是输出的天花板。

Level 1，随意多模型。多个模型在手，根据任务类型手动切换。"我写代码用 Claude，写文案用 GPT。"没有结构化流程，也没有跨家族审查。比 Level 0 强，因为至少不同任务拿到了不同视角，但还没有用多样性来校验正确性。

Level 2，结构化 pipeline。把跨家族审查内建到工作流中。pipeline 的不同阶段用不同 provider，任务之间的依赖关系强制你走完流程——审查步骤跳不掉。我自己做的 Claude Code 插件 Dev Buddy 就在这个级别。每个阶段可以走不同 provider，pipeline 的结构让审查步骤不可能被悄悄砍掉。

Level 3，自动路由。系统知道什么类型的任务该交给哪个 model family，自动分发。路由依据包括任务特征、历史分歧模式、以及跨家族审查在哪些地方抓到过最多错误。路由服务的目标是知识层面的——为任务匹配到正确的多样性视角，而不仅仅是做 load balancing。

Level 4，自我优化。系统能学习哪些模型组合对哪些任务类型产生最有效的挑战模式。它追踪跨家族分歧中哪些最终变成了真正的修正、哪些只是噪音，然后据此调整 ensemble。今天这基本还停留在理论阶段。

大多数组织还在 Level 0 或 1。Level 2 和 3 的工具已经存在。Level 4 是前沿。

实操建议

个人：从"第二意见"开始。任何重要输出都用两个不同 AI provider。Claude 写，GPT 审，或者反过来。订阅用户加一个订阅的边际成本其实不高。API 用户要算额外调用费用，但别忘了审查比生成便宜——input 更短，output 是判断而不是完整创作。记下跨家族审查抓到了哪些原本会漏掉的错误，这些数据就是你扩大实践的最好论据。

团队：把跨家族审查变成流程硬要求，不是可选项。用 Dev Buddy 这类工具从结构上强制执行，避免 deadline 一紧就被跳过。跟踪采用前后的错误率——before/after 数据是在组织内部推广多 AI 实践最有力的武器。从风险最高的工作流开始，再往外扩展。

企业：审计一下你们的 AI 模型集中度。有多少关键工作流只经过单一 AI family，没有任何反对视角？找出相关错误会造成最大损失的地方。用第 5 章的 ROI 数据和第 4 章的风险数据来构建商业论据。先做一个 pilot：选最高风险的工作流，加上跨家族审查，看它能抓到什么。

我们还缺哪些证据

这个系列提出了一个有力的论证，但诚实地说，必须承认其中的缺口。研究社区还没有提供：

在相同任务、受控成本和延迟约束下，直接对比同家族 vs 跨家族 multi-agent 系统的 benchmark。这是最关键的一块缺失证据。

最优组合研究：哪些具体的 model family 配对，在什么任务类型上互补性最好。目前的实践大多还是经验性的，靠轶事而非数据。

执行顺序实验：用同一套任务和完整的成本核算，比较路径 A（贵模型生成、便宜模型审查）vs 路径 B（便宜模型生成、贵模型审查）。

跨家族相关性分析：测量不同 model family 的盲区在实践中到底有多独立。对闭源模型来说，这可能需要 black-box testing。

长期成本收益数据：用数月甚至数年的时间跨度来衡量多 AI 的 ROI，而不是从单个任务对比中推断。

这些缺口不会推翻整个论点。逻辑论证和类比证据已经足够强。但最强的那些主张在直接证据到来之前，仍然属于推断。我宁愿把这一点说清楚，也不愿假装证据比实际更完整。

一种思维方式

我做的两个工具——Dev Buddy 做结构化 pipeline，OpenHive 做层级式 multi-agent 团队——都是跨家族理念的具体实现。但这个理念不依赖任何特定工具，也不依赖任何特定 provider。严格来说，它甚至不依赖 AI。

来自多元来源的独立视角，比未经质疑的单一来源分析更能产出好结果。医学早就想通了这一点，法律想通了，科学也想通了。AI 正在追上来。

59% 的开发者已经在并行使用三个或更多 AI 工具。Gartner 报告，从 2024 Q1 到 2025 Q2，multi-agent 系统的咨询量暴涨了 1,445%。不管我们有没有一套完整的理论，行业都在朝着多 AI 的方向走。

你可以有意识地走过去——有一套框架决定哪些模型组合，有一套策略让它们协同工作。也可以稀里糊涂地凑合着用，走一步看一步。

我知道我会押哪边。