多模型协同为何失效？三层分工架构落地指南

多模型研发流水线越来越常见。高阶模型负责设计，轻量模型负责写代码，这种分工看上去合理。但实际落地时，角色错位、成本失控和代码质量下滑常常同时出现。本文先拆解常见的失败模式，再给出三层分工方案，并附上任务下发格式、成本估算方法和试点步骤，方便团队直接参考。

一、多模型协同下“无限子弹”模式的三大常见缺陷

“无限子弹”模式指高阶模型负责规划，轻量模型用尽可能大的上下文、尽可能高的调用频率持续编码。这种思路把编码工作交给成本较低的模型，运行中却常暴露以下问题。

1. 执行质量下降

轻量模型接到清晰的规划后，遇到复杂业务逻辑时，推理深度可能不够，容易生成质量低或偏离预期的代码。规划再好，执行层走偏，前期设计也无法落地。更麻烦的是，代码中可能留下不易察觉的逻辑缺陷，要到上线后才会暴露。

2. 返工成本转嫁到高阶模型

执行出错后，系统通常要再次调用高阶模型做代码审查和纠错。高阶模型为了定位问题，需要读入整个代码仓库和较长的对话历史。前期省下的Token预算会被返工消耗掉，总成本可能超过直接使用高阶模型。

3. 能力分配颠倒

这种模式让推理能力强、单价高的模型负责思考，让推理能力弱的模型负责动手。思考环节的用量小，执行环节的用量大，最终产出质量却由执行环节决定。这与“设计与实现能力相匹配”的软件工程原则相悖。

二、三层分工架构

三层架构把决策、管理和执行拆开，每层只承担与其能力匹配的工作。

层级	主要职责	模型类型	选型示例
顶层规划	架构设计、技术选型、任务拆解，输出验收标准	高阶推理模型	DeepSeek-R1、OpenAI o 系列等推理模型
中层调度与验收	拆分任务、下发指令、维护项目状态、初步验收	通用大模型	同级通用模型，需兼顾指令遵循与代码阅读能力
基层执行	按单条指令生成代码，不保存历史	代码能力较强的轻量模型	Qwen-Coder、DeepSeek-Coder 等代码专用模型

以上为选型思路示例。模型版本更新快，具体选择应以团队自己的实测结果为准。

顶层规划层不直接写代码，它的输出是结构化计划，包括目标、模块边界、接口约定和验收标准。中层把计划拆成任务，逐条发给执行层。中层也不只是传话，它要检查输出是否符合接口定义，是否通过测试。中层的深度推演能力弱于顶层，所以它不负责方案取舍，只判断代码是否符合既定规范。

任务下发格式

中层向基层下发的任务建议使用固定结构，便于校验和日志追踪。示例如下：

{
  "task_id": "T-0113",
  "parent_plan": "PLAN-2026-017",
  "goal": "为订单模块新增按状态筛选的查询接口",
  "context": {
    "files": ["src/order/query.ts", "src/order/types.ts"],
    "interfaces": ["GET /api/orders?status=..."]
  },
  "constraints": ["不修改已有字段的含义", "复用 OrderStatus 枚举"],
  "acceptance": ["单元测试覆盖空值、非法状态和分页", "返回结构符合 OrderPage 类型"],
  "output_format": "unified_diff",
  "max_retry": 2,
  "timeout_seconds": 300,
  "sandbox_permissions": {
    "read_paths": ["src/order/"],
    "write_paths": ["src/order/query.ts", "src/order/types.ts"],
    "network": false,
    "exec": ["npm test -- order"]
  }
}

中层在下发前要校验路径。路径必须落在代码仓库根目录之内，包含“..”或绝对路径的请求直接拒绝。执行层只能运行白名单中的命令，且默认不开放网络访问。这些限制能防止执行层读写仓库以外的文件，也能避免模型生成的代码引入意外的外部调用。

执行层返回的结果也应结构化，至少包含任务编号、状态、代码差异和自检结果。中层收到结果后，有三种处理方式：

• 通过：合并到代码库，记录任务完成状态。
• 未通过且未超过重试上限：把失败用例和差异说明附在原任务中，重新下发。
• 连续失败或涉及方案问题：升级给顶层规划层，由其修改计划。

重试上限和升级条件要事先写明。否则流水线可能在同一个任务上无限循环，持续消耗Token。

三、架构优势与成本估算

1. 成本与返工

中层验收能在代码进入主干前拦截一部分错误，从而减少返工。这种做法能否省钱，取决于具体数字，不能凭直觉判断。单个任务的期望成本可以用下面的公式估算：

单任务期望成本 = 执行成本 ×（1 + 平均重试次数）+ 中层验收成本 + 升级概率 × 顶层单次成本

下面用假设数字演示计算。设执行成本为1个单位，中层验收成本为0.3个单位，平均重试次数为0.5次，升级概率为10%，顶层单次成本为10个单位。则：

1 ×（1 + 0.5）+ 0.3 + 0.1 × 10 = 1.5 + 0.3 + 1 = 2.8个单位

作为对照，如果所有任务都直接交给顶层模型，每个任务按一次调用计算，成本为10个单位。三层架构的期望成本是2.8个单位，约为对照组的28%。

这个结论有前提。对照组假设顶层模型一次就能完成任务，没有额外的审查成本。另外，比较只在质量达标时才成立，因此试点阶段必须同时监控通过率。

敏感性也要看清楚。若升级概率提高到30%，成本变为1.5 + 0.3 + 3 = 4.8个单位，仍低于对照组。若升级概率保持10%，平均重试次数要达到约7.7次，三层架构的成本才会与对照组持平。重试这么多次，说明任务拆分或执行模型存在明显问题，应先修正流程。

上述数字只用于演示。团队应替换成自己的计费数据和实际重试记录，再做判断。

2. 方案的边界

三层架构并非在所有场景都更省钱。任务边界模糊、需求频繁变动的项目，中层拆分任务的成本会明显上升。此时可以减少自动化层级，让高阶模型直接处理关键模块。

四、试点验证步骤

1. 选择低风险模块做试点。 挑选边界清楚、依赖较少、已有完整测试的模块，例如内部报表查询或工具类接口。支付、权限等高风险代码暂不纳入试点。
2. 先写好中层的校验脚本。 校验内容包括接口签名是否与计划一致、单元测试是否通过、代码差异是否只落在任务允许的路径内。脚本要能在人工介入前自动拦截明显错误。
3. 小比例灰度上线。 先让流水线处理约10%的任务，人工复核全部合并结果。连续两周记录四项指标：首次通过率、平均重试次数、升级比例、每个合并任务的总Token成本。
4. 根据数据决定是否扩大范围。 若首次通过率和成本都达到事先设定的阈值，再逐步扩大到更多模块。若重试次数或升级比例持续偏高，应先调整任务拆分粒度或更换执行模型，不急于扩大规模。