搭建多 Agent 工作流时，一个很自然的想法是：简单任务给小模型，困难任务派最强模型做 subagent。
这套分法只看到了任务难度，没有看到决策责任。
困难任务真正稀缺的通常不是多写几百行代码，而是理解完整需求、识别约束、判断取舍，以及对最终结果负责。如果主脑把这部分也派出去，强模型虽然接到了“最难的活”，却只拿到一段压缩后的上下文。主脑随后还要重新理解它的判断，责任链反而被切成两段。
更稳的模型分级，不是让最强模型成为高级外包，而是让它成为决策者。
🧠 主脑负责不可委托的判断
主脑应保留这些工作：
- 理解用户真正要解决的问题；
- 把模糊目标拆成可执行计划；
- 处理存在多种合理答案的取舍；
- 排查跨系统、跨模块的复杂故障；
- 决定是否接受执行结果；
- 对最终交付负责。
这些工作高度依赖完整会话、历史决策和隐含约束。把它们交给临时启动的 subagent，等于先主动丢失上下文，再花算力让另一个模型重建。
即使 subagent 同样使用最强模型，也不能自动补回缺失的信息。模型能力更强，不等于它知道主脑没有传进去的事实。
🛠️ 执行方只接边界清晰的任务
执行模型最适合处理的是已经完成判断的工作，例如：
- 按明确方案实现代码；
- 根据指定结构写文档初稿；
- 批量读取文件并整理结果；
- 运行测试并修复局部小问题；
- 做格式调整、改名和机械迁移。
这类任务可以使用较便宜的模型，因为质量主要由计划清晰度、输入完整度和验收标准决定，而不是由执行方再次发明方案。
派工时至少应给出五样东西：目标、文件或系统边界、具体步骤、完成标准，以及需要返回的结果格式。遇到计划外判断，执行方应停下来回报，而不是自行扩大任务。
💸 节省额度只是副产品
让强模型留在主脑位置，确实能减少昂贵模型的重复调用，但成本不是唯一收益。
更重要的是，它让责任结构变得清楚：
- 主脑制定计划；
- 执行方完成有限任务；
- 主脑抽查、测试并作最终判断；
- 失败时由主脑接管，而不是继续向上换更强的 subagent。
如果执行失败就升级模型，系统很容易形成一条昂贵的重试链：小模型失败，换中模型；中模型失败，再换大模型。每一层都重新读取上下文，却没有人真正对方案负责。
失败回收到主脑，反而能暴露真实问题：是计划不完整、约束漏传，还是任务本身需要重新判断。
📏 不是所有小事都值得派出去
多 Agent 不等于每个任务都要并行。
subagent 有固定成本：启动、读取上下文、理解计划、返回结果，以及主脑重新验收。两三步能完成的小任务，派出去往往比主脑直接做更慢，也更容易产生信息损耗。
适合派工的场景通常只有两类：
- 工作量足够大，例如要批量读取很多文件；
- 任务彼此独立，可以真正并行。
否则，“使用了多个 Agent”只是流程变复杂，不是效率提升。
✅ 结论
模型分级不该只按任务难度排列，而应按责任划分：
- 最强模型做主脑，掌握上下文、制定计划、处理判断并完成验收；
- 中型模型做执行，完成边界清晰、需要一定能力的实现工作；
- 小型模型做体力活，负责搜索、批量读取和格式整理；
- 执行失败回到主脑，不靠不断升级 subagent 掩盖计划问题。
真正值得保留给强模型的，不是最费时间的动作，而是最不能切断的决策责任。
马启航Marvis