多模型协作开发（Multi-Model Collaboration）详解-三亩地-编程学习日记

单一模型存在三个无法同时满足的约束：

所以核心思路是：不要让一个模型干所有事，而是让不同模型/Agent 各司其职，像真实团队一样分工协作。

原理：一个路由器根据任务难度/类型，把请求分发给不同模型。

请求 → 路由器（判断任务难度） ├─ 简单任务（补注释、格式化、写测试用例） → 小模型（便宜快） ├─ 中等任务（实现功能模块） → 中档模型 └─ 复杂任务（架构设计、算法优化） → 最强模型（贵但值）

代表：OpenRouter、Martian、OpenAI 的自动路由、各大厂的 Model Gateway。

优点：成本可降低 70%~90%，延迟显著下降。缺点：路由判断本身会出错，可能把难任务发给弱模型。

原理：一个主 Agent（Orchestrator，编排者）负责拆解任务、调度执行、汇总结果，多个子 Agent 各管一段。

典型分工：

主 Agent（规划与调度） ├─ Planner Agent 拆解需求、制定开发计划 ├─ Coder Agent 编写代码 ├─ Reviewer Agent 审查代码、找 Bug ├─ Tester Agent 运行测试、反馈失败 └─ Docs Agent 写文档、更新 README

工作流示例（用 LangGraph 的状态机思想）：

Draft(起草) → Lint(静态检查) → Test(测试) → Fix(修复) → Review(评审) → Merge

代表：Claude Code 的 Sub-Agent 能力、AutoGen、LangGraph、CrewAI、MetaGPT（模拟软件公司组织架构）。

优点：能处理跨领域复杂任务，每个环节用最合适的模型，质量可交叉验证。缺点：系统复杂度指数上升，调试困难，Agent 之间错误会传播，延迟累加。

原理：让 3 个不同模型生成同一段代码，再用单元测试或投票机制选出最优解。

模型A 生成方案1 ─┐ 模型B 生成方案2 ─┼→ 全部跑单元测试 → 选通过率最高的方案 模型C 生成方案3 ─┘

优点：显著提升正确率（尤其数学、算法题），降低单一模型幻觉风险。缺点：成本是单模型的 3 倍以上，适合高价值、低频任务。

原理：先调用小模型，如果其置信度低或验证失败，再升级调用大模型。

小模型尝试 → 验证（测试/语法检查）→ 通过则结束 ↓ 失败 大模型重写 → 再验证

优点：兼顾成本与质量，适合自动化流水线。代表：各类自研 Model Gateway 的 fallback 策略、OpenAI 的 tiered models。

假设要构建"需求 → 自动生成 PR"的系统，合理的多模型协作设计：

环节	负责 Agent	推荐模型档位	理由
需求理解与拆解	Planner	强模型	理解歧义、拆任务需要强推理
代码生成	Coder	强模型	核心环节，质量优先
代码补全/样板代码	Coder	弱模型	重复性工作，用便宜模型
代码审查	Reviewer	强模型	找 Bug 需要全局理解
测试用例编写	Tester	弱模型	模板化程度高
文档生成	Docs	弱模型	基于已有代码，成本敏感

关键设计原则：只有 30% 的环节需要强模型，其余用弱模型即可，总成本可降至单一强模型的 40% 左右。

框架	特点	适合谁
Claude Code Sub-Agents	终端内多 Agent，主 Agent 可派发任务给子 Agent 并收回结果	个人开发者、CLI 工作流
LangGraph	图状态机，精确控制 Agent 流转，可编程性最强	需要复杂、确定性工作流的团队
AutoGen	微软出品，多 Agent 对话式协作，支持人机混合	研究、实验性项目
CrewAI	角色扮演式协作，API 简洁，上手快	快速搭建原型
MetaGPT	模拟软件公司（产品经理/架构师/工程师/QA 各司其职）	想体验"AI 软件公司"的团队
OpenRouter	模型路由服务，统一 API 访问多家模型	想动态切换模型的开发者

五大挑战：

最佳实践清单：

日记详情