Code Agent 的编排模型需要与执行代码的模型同样强吗？

作者：袖梨 2026-09-19

不需要简单地让编排模型与代码执行模型使用同一个能力档位。真正决定模型强弱的，不是“编排器”这个名称，而是它被授权做多少判断。如果它只读取结构化状态、按照固定规则派发任务，较小模型甚至普通程序就能胜任；如果它要理解模糊目标、拆分跨模块工作、发现执行结果中的隐患、在假设变化后重写计划，并决定何时结束，那么它实际上承担了技术负责人和验收者的工作，能力通常不应明显弱于执行代码的模型。

因此，更准确的设计原则是按认知负载分配模型，而不是按代理角色分配模型。写代码需要局部实现能力，编排需要全局状态理解、风险判断和长程一致性。两者的能力维度不同，不能只拿参数规模、价格或通用榜单分数直接比较。工程上应先缩排器的自由度，再测试更便宜的模型能否稳定守住协议；如果无法缩小自由度，就应保留强规划和强验收能力。

先分清“调度”与“规划”

很多多代理系统把几种完全不同的职责都装进一个 orchestrator。第一种是调度：判断某个任务应交给哪个代理，记录运行中、成功或失败，控制并发，并在超时后重试。第二种是规划：把含糊需求变成有依赖关系的子任务，识别哪些文件和接口会互相影响。第三种是审查：判断实现是否真的满足目标，而不是仅仅看到测试命令退出为零。第四种是恢复：当代理报告与预期冲突时，决定补充上下文、回滚方向、重新拆分还是升级给更强模型。

纯调度的状态空间有限，输入输出也容易结构化。它更像任务队列和状态机，对语言模型的要求并不高。规划、审查和恢复却要处理未写明的约束、跨任务依赖以及不完整证据，错误还会沿后续任务传播。把四种职责统称为编排，再追问编排模型是否需要“同样强”，会掩盖真正的问题。

一个实用的拆分方式是让确定性程序管理队列、锁、超时、重试次数、工作区和终态，让模型只处理无法可靠编码的语义判断。这样既减少调用成本，也避免模型在计数、去重和状态迁移上犯本可消除的错误。

为什么弱编排器的错误更容易累积

代码代理的一次局部错误通常能被编译器、静态检查或测试暴露。编排错误则常常改变后续代理看到的问题。例如，编排器遗漏一个前置依赖，第二个代理可能在错误接口上继续开发；它误判第一项已经完成，第三个代理又会把不成立的假设当成事实。每个执行者的局部修改看起来都合理，最终集成时才集中暴露。

这种风险可以看成“决策扇出”。一次判断只影响一个可撤销动作时，使用便宜模型的代价较低；一次判断会生成五个并行任务、修改共享接口或宣布整个工作完成时，判断的影响范围很大。模型选择应该随扇出、不可逆性和验证难度提高，而不是随代码行数提高。

长任务还会遇到状态压缩。编排器不能无限携带全部对话，通常要把已完成工作压缩成摘要。如果摘要漏掉了失败尝试、隐含约束或未解决风险，后续重规划会建立在错误记忆上。较弱模型首先暴露的未必是工具调用格式问题，而可能是对“哪些信息必须保留”的判断不稳定。

什么情况下可以放心使用较小模型

当任务入口已经标准化时，编排器可以很轻。典型条件包括：任务类型数量有限；每类任务都有明确代理；输入字段固定；执行者必须返回机器可读状态；成功条件能由测试、类型检查或规则验证；遇到未知情况时允许直接升级，而不是强行猜测。

此时，编排器不负责创造方案，只负责执行既定策略。下面的返回协议就比一段自由文本更适合低成本模型：

{
  "status": "completed | blocked | failed",
  "changed_files": ["path/to/file"],
  "checks": [{"name": "unit", "passed": true}],
  "assumptions": [],
  "needs_replan": false,
  "next_capability": "review"
}

协议本身还不够，宿主程序必须校验字段、限制枚举值，并拒绝缺失证据的完成声明。路由规则能用代码表达时就用代码表达，例如测试失败交回实现代理，触及公共接口时增加审查步骤，连续两次失败则升级模型。模型只处理规则无法覆盖的少数分支，成本才会真正下降。

较小模型也适合做候选路由，让确定性规则或更强验证器确认其选择。它可以从任务描述中提取语言、框架和工作类型，但不应独自决定高风险任务已经完成。换句话说，可以让它建议下一步，却不要默认让它拥有最终裁决权。

什么情况下编排器需要强能力

需求只有业务目标而没有技术方案时，编排器必须建立问题模型。它要决定先调查还是直接修改、哪些任务能并行、哪些接口必须先冻结，以及如何把验收条件传给执行者。这类工作依赖架构理解和反事实推理，不能被简单路由替代。

跨仓库、跨服务或涉及数据迁移的任务也应提高编排能力。执行者可能各自完成局部目标，但只有全局角色能发现版本顺序、兼容窗口、回滚路径和共享资源冲突。安全、权限、账务和不可逆数据变更同样不适合由明显较弱的模型自由决策。

另一个判断信号是结果是否容易验证。生成一个纯函数可以靠单元测试约束；修改缓存一致性、并发控制或用户可见工作流时，即使测试通过，也可能遗漏时序和边界条件。验证越依赖语义理解，编排器或独立审查模型就越需要强能力。

注意，“强编排器”并不等于它必须亲自完成所有代码。它可以把实现交给更便宜、专长更明确的代码模型，但应给出边界清晰的任务包，并保留重新规划与拒收的权力。强能力应花在高决策上，而不是消耗在轮询状态和搬运文本上。

如何评估编排模型是否够用

不要只比较一次任务的最终代码质量。编排模型的评估单位应是一整条轨迹，包括任务拆分、路由、上下文传递、失败恢复和完成判定。至少要记录每次决策的输入、输出、依据、影响的任务数量以及后续是否被纠正。

可以从一组固定的真实任务开始，保存相同的初始仓库、预算和执行模型，只替换编排模型。重点观察以下指标：首次计划后需要重写多少次；执行代理因上下文缺失而返回多少次；已经失败的路线是否被重复尝试；并行任务产生多少冲突；错误完成声明的比例；人工介入次数；完成一个被验收任务的总调用成本。单看编排调用价格会产生误导，因为便宜决策可能带来更多返工。

还应主动注入异常，而不是只跑顺利样例。例如让一个代理返回不完整结果，让测试出现间歇失败，让两个任务同时触碰公共接口，或者在中途改变一项约束。观察编排器能否识别证据不足、暂停扩散并选择合理的恢复动作。正常流程主要检验路由，异常流程才检验编排。

评估时要固定协议和工具权限，否则无法判断差异来自模型还是脚手架。每次调整提示词、上下文压缩方式或返回结构，都应重新建立基线。最终目标不是找一个抽象意义上最聪明的模型，而是找出在当前约束下不会让总失败成本失控的最低能力档位。

降级模型时的实施顺序

第一步，列出编排器现有的所有决策，把队列管理、状态迁移、重试和机械校验移到代码中。第二步，为代理输出建立严格模式，并把“未知”和“阻塞”设为合法结果。第三步，为每类决策标记风险等级和升级条件。第四步，用历史任务做离线回放，比较强模型与候选小模型在相同节点的选择。第五步，小流量运行并保留完整日志，确认总成本、返工率和误判率，而不仅是单次调用成本。

降级也不必一次完成。可以先让小模型处理状态摘要和低风险路由，强模型继续负责初始规划、跨模块冲突与最终验收。积累足够轨迹后，再把表现稳定的决策类型下放。如果某类决策的边界始终难以描述，就不要勉强下放；这通常说明它仍然需要更强的语义判断。