AI辅助编程多模型分工：规划、调度与执行如何配置

在AI辅助编程中，开发者通常同时面对多个能力与价格层级不同的模型。一个常见做法是：让推理深度较高的模型负责规划，让成本低、速度快的模型循环执行，再由人工或另一个模型做检查。这套做法在任务简单时效率很高，但任务变长、上下文变厚时，问题会集中暴露。本文从角色分工的角度梳理这类问题，并给出可落地的配置思路。

一、多模型协作的真正难点

多模型协作的效果取决于三件事：规划是否正确、执行是否稳定、验收是否可靠。任何一环失效，整体结果都会下滑。

最常见的失效方式是“上游正确、下游失真”。规划文档逻辑清楚，执行模型却漏改调用方、忽略边界条件，或者在测试未覆盖的路径上引入回归。执行结果一旦需要人工或更强的模型反复审查，审查成本可能抵消前面省下的费用。

第二个难点是上下文膨胀。每轮调用都携带完整对话历史和整个代码仓库时，输入token随轮次持续增长。对于输入计费较高的模型，这部分开销往往比输出更大。把长历史反复交给执行模型，既费钱，也会稀释模型对当前步骤的注意力。

二、三种常见分工方式

1. 强规划加轻执行

规划由推理深的模型完成，执行交给成本低、吞吐高的模型。单次调用便宜，适合重复性高的小修改。缺点是执行质量波动大，错误会沿步骤传递，验收环节需要额外投入。

2. 强模型全程执行

同一个强模型负责规划、编码和验收。一致性好，错误较少。缺点是每轮都要重读长历史，单次成本高，而且简单编辑所需的推理量远低于它的推理能力，相当于能力被浪费。

3. 分层协作

把流程拆成三层：

• 规划层：拆解目标，定义范围与验收标准。
• 调度验收层：维护任务状态，切分步骤，检查每步结果。
• 执行层：只接收结构化任务包，不携带历史运行。

这种方式借鉴了管理分层的思路，让每一层只承担与其职责相匹配的上下文和推理量。

三种方式的对比如下：

维度	强规划加轻执行	强模型全程执行	分层协作
单次调用成本	低	高	中
执行质量稳定性	波动较大	较稳定	依赖任务包质量
上下文负担	中，取决于历史管理	高，历史持续增长	低，执行层无历史
错误拦截能力	依赖额外验收	依赖模型自检	调度层逐步验收
实施复杂度	低	低	较高

三、按角色匹配推理强度

推理强度应与任务的不确定性成正比。

规划阶段要权衡方案、识别风险、判断哪些模块会受影响，不确定性最高，适合开足推理深度。

执行阶段在明确的任务包内按规格修改代码，推理需求较低，但对代码能力和工具使用要求高。如果任务涉及界面截图理解或图像识别，执行层应选择具备相应多模态能力的模型。

调度验收层要记住进度、比对结果、判断是否需要重试，适合中等推理强度，并且需要长程一致性。

还有一点值得注意：执行质量不完全取决于推理量，更取决于输入是否清晰。任务包写得具体，执行层即使推理强度较低，也能稳定完成工作。

四、用任务包让执行层无历史运行

执行层无历史运行的前提是，调度层为每一步生成一份自包含的任务包。任务包至少包含以下字段：

task:
  id: "auth-rate-limit-03"
  goal: "为登录接口增加按用户名的失败次数限制"
  scope:
    files: ["src/auth/login.py", "tests/test_login.py"]
    out_of_scope: ["数据库结构变更", "前端代码"]
  constraints:
    - "不修改现有响应结构"
    - "失败计数复用已有缓存模块"
  context:
    - "login() 当前签名与调用方列表"
    - "现有缓存接口的读写方法说明"
  acceptance:
    - "新增单元测试覆盖锁定与解锁"
    - "全部现有测试通过"
    - "改动文件不超出 scope"

该结构为示意，字段可按团队的流程调整。关键在于三点：目标要可判断是否完成；范围要写明不做什么；验收条件要尽量机器可检查。

五、调度循环的实现思路

下面的伪代码展示调度层如何驱动执行层，并在失败时升级处理：

MAX_RETRY = 3
def run_task(task, planner, scheduler, executor):
    plan = planner.plan(task.goal, task.summary)
    for step in scheduler.split(plan):
        package = step.to_package()
        for attempt in range(MAX_RETRY):
            result = executor.run(package)      # 执行层只接收任务包，不附带历史
            verdict = scheduler.review(step, result)
            if verdict.passed:
                break
            package = scheduler.revise(package, verdict.issues)
        else:
            escalate(step, result)              # 超过重试上限，交给规划层或人工
            return
    scheduler.finalize(task)

调度层与执行层之间的契约是“任务包进、结构化结果出”。结构化结果应包括改动文件列表、测试输出、静态检查结果等可机器判断的内容。重试次数控制在两到三次较为合适。次数过多通常说明任务包本身有缺陷，继续重试只会增加成本。

六、验收与升级规则

验收应优先依赖可自动化验证的项目：

• 单元测试与集成测试是否通过；
• 类型检查、静态分析和格式检查是否报错；
• 改动文件是否超出任务包中定义的范围。

审查模型或审查人员应使用独立上下文，只接收需求描述、代码差异和测试结果，不接收执行层的推理过程。这样可以减少审查者被执行过程说服的风险。

以下情况应直接升级，不交给自动重试：

• 连续多次验收失败；
• 修改涉及权限、加密、支付等敏感模块；
• 需要改动跨模块的公共接口；
• 任务包中的假设与代码库实际情况明显不符。

七、成本应按“被接受的变更”计算

只看单次调用的单价容易得出误导性的结论。更合理的指标是每个被接受的变更所消耗的总成本，可以拆解为：

总成本 = 规划 + 调度 + 执行（含重试）+ 验收 + 人工返工

同一项任务，如果执行层便宜却需要三轮返工，总成本未必低于一次完成的强模型方案。具体单价和计费规则以服务方公布的为准，选型前应根据自己的任务样本实际测算。

八、选择建议

• 单文件、小改动：一个模型直接完成即可。分层的管理开销往往超过收益。
• 多文件、多步骤、需要持续推进：分层协作更稳定，错误也更容易被拦截。
• 涉及截图理解或界面操作：执行层选择具备相应多模态能力的模型。
• 历史很长、仓库很大：执行层必须无历史运行，所需上下文通过任务包显式传递。
• 团队流程尚不成熟：可先用强模型全程执行，积累任务模板后再拆分角色。

多模型协作的收益来自边界清晰的分工。模型数量本身不产生收益。