低成本多智能体编程系统的模型分级选型指南

在多智能体编程系统中，“给所有角色一律配上旗舰模型”是一种看似稳妥、实则昂贵的配置思路。一次完整的开发任务往往要经过规划、设计、执行、审查、检索、协调等多个角色的几十次模型调用，任何一处过度配置都会被调用次数成倍放大。本文围绕“预算有限时如何科学配置模型”这一通用问题，给出一套以角色能力画像为基准的分级选型与配置方法，并附可直接套用的示意配置与落地步骤。

一、为什么“全旗舰”配置是性价比陷阱

1. token 成本是乘法，不是加法。 多智能体系统的消耗等于“角色数量 × 调用轮次 × 单次上下文长度”。一套角色齐整的系统，一次任务触发几十次调用是常态；而旗舰档与轻量档之间的单价往往存在数量级差距，这笔差距再乘上调用次数，账单会以肉眼可见的速度膨胀。

2. 高档位不等于高吞吐。 参数量更大、推理链更长的模型，首字时延与生成速度未必占优。把它们塞进检索、格式转换这类高频轻量环节，整条链路的响应时间会被拖长，而质量提升几乎为零。

3. 省过头同样致命。 反过来，如果把主规划角色交给小参数模型，产出的计划往往碎片化、缺乏全局视角，下游执行反复返工——而返工本身就是最贵的 token。分级选型的本质，是在“能力匹配、成本可控、时延合理”这个三角中求系统最优解，而不是简单地挑最贵或最便宜。

二、分级选型的三条基本原则

原则一：先画像，后选型。 为每个角色回答三个问题：它负责什么？它的输入输出长什么样？它出错时损失向哪里放大？由职责推导能力需求（长上下文、深度推理、代码生成、视觉理解等），再由能力需求落到档位。顺序一旦颠倒，选型就会退化成“看着预算挑模型”。

原则二：角色定默认档，任务做二次路由。 角色决定默认档位，但同一角色承接的任务难度差异巨大：同一个执行器，处理一次疑难缺陷定位与处理一次机械改名，成本结构完全不同。正确做法是在调用入口挂一个轻量难度分类器，先分类、再分发。分类本身用最小档位的模型即可，成本几乎可以忽略。

原则三：够用即可，局部奢侈。 预算优先投向高杠杆角色——规划与审查。规划决定全系统方向，审查决定质量下限，这两个环节的错误会向下游成倍放大；而检索、子任务这类跑量环节坚持轻量化，省下的额度恰好覆盖“大脑层”的开销。

三、角色维度：能力画像与档位映射

角色	核心能力要求	建议档位	选型理由
主规划器	长上下文、任务拆解、全局编排	旗舰级长上下文模型	全系统的“总开关”，需吞下全量上下文并输出结构化计划
方案设计器	架构设计、接口定义、技术选型	与主规划器同档	保证“计划”与“技术方案”同源一致，避免两处脱节
深度执行器	复杂实现、跨文件重构	推理与代码均衡的中高端模型	既考验推理深度，又要求稳定代码产出
审查/分析器	代码评审、风险判断	分析特化型模型	审查价值在“判断准”，而非“生成快”
协调/校验类	轻量推理、短上下文处理	推理型轻量模型	任务面窄、输入输出短，用旗舰纯属浪费
检索/探索类	代码理解、符号定位	轻量代码模型	产出是引用与定位，不需要长文本生成，够用即可
子任务执行器	小型独立改动	轻量代码模型	承接拆解后的低复杂度任务，跑量优先
多模态理解器	截图、设计稿、图表解析	大型多模态模型	视觉理解对参数规模敏感，此处不能省

对几个关键角色再展开说明：

• 大脑层（主规划器 + 方案设计器）：规划器要一次性消化任务全量上下文并输出结构化分解，长上下文与规划能力是硬指标；设计器与规划器保持同档，是为了让计划与技术方案在能力与风格上同源，避免档位不一致造成两份产物互相脱节。
• 主力执行层（深度执行器）：复杂实现同时考验推理与代码质量，选“双均衡”的中高端档最划算——纯推理特化的模型写代码未必稳，纯代码模型处理复杂逻辑又欠火候。
• 质量把关层（审查/分析器）：误报浪费人力，漏放引入风险，因此这一档要选分析判断最稳的模型，而不是生成最快的。
• 轻量层（协调/校验、检索/探索、子任务执行）：共同点是任务面窄、上下文短、输出简短。尤其检索类角色，产出只是几十行引用与定位，轻量代码档完全胜任。
• 多模态层：只要系统会接触到截图、设计稿或图表，就必须配置大型多模态档位；视觉能力是这套配置里少数“不能省”的地方。

四、任务维度：按难度分类的路由策略

除了角色维度，还应建立任务难度维度的路由表，作为角色默认档位之外的修正：

任务分类	建议档位	典型场景
超难推理	深度推理特化模型	算法设计、疑难缺陷定位、架构权衡
深度分析	分析型强档模型	性能剖析、安全审查、方案评审
创意/写作	长上下文写作型模型	技术文档、提交说明、命名与文案
快速/低难度	小参数通用模型	格式转换、简单问答、机械性修改

路由策略的要点：

• 超难推理宁慢勿错。 这类任务占比低，但一旦出错返工代价最大，值得用特化档位兜底。
• 高频流量全部挡在低档位。 快速响应类任务调用次数最多、单价敏感度最高，用小参数档跑量，是整张成本表里收益最明显的一格。
• 写作任务看连贯性而非推理深度。 文档与说明类内容更依赖上下文连贯与文风一致，交给长上下文写作型档位即可，不必占用推理资源。
• 分类器要轻。 难度判断只依赖任务描述与输入规模，用最小档位模型实现三到四分类即可，不要为分类本身引入额外成本。

五、可直接套用的示意配置

下面是一份与具体模型解耦的配置骨架，只描述档位画像与绑定关系：

# ===== 档位定义：只声明能力画像，不绑定任何具体模型 =====
tiers:
  flagship_long:      { profile: "长上下文 + 强规划" }   # 大脑层
  balanced_code:      { profile: "推理与代码均衡" }      # 主力执行
  analyst:            { profile: "分析判断精准" }        # 质量把关
  reasoning_special:  { profile: "深度推理特化" }        # 超难任务兜底
  light_reason:       { profile: "轻量推理、低时延" }    # 协调 / 校验
  light_code:         { profile: "轻量代码理解" }        # 检索 / 子任务
  vision_large:       { profile: "大型多模态" }         # 视觉理解
  small_fast:         { profile: "小参数快速响应" }      # 高频轻量
# ===== 角色绑定 =====
role_bindings:
  planner:     flagship_long
  architect:   flagship_long
  executor:    balanced_code
  reviewer:    analyst
  coordinator: light_reason
  retriever:   light_code
  sub_worker:  light_code
  vision:      vision_large
# ===== 任务路由：入口分类后再分发 =====
task_routing:
  expert_reasoning: reasoning_special
  deep_analysis:    analyst
  writing:          flagship_long
  quick:            small_fast
# ===== 降级策略（示意） =====
fallbacks:
  - { from: flagship_long, to: balanced_code }   # 限流 / 超时时临时接管

落地时，只需为每个档位绑定实际接入点：可以直接使用云端托管的大模型推理服务（例如在百度智能云的模型服务中选取与档位匹配的模型），也可以指向自建推理端点——对上层配置而言，两者只是一个可替换的调用地址。这种“档位抽象”带来三个好处：换模型不动结构、可以按档位灰度切换、多个接入点互为备份。

六、落地六步

1. 角色盘点：列出系统内全部角色，逐个写清职责、输入输出形态与失败影响面，形成能力画像表——这张表是后续所有决策的依据。
2. 档位绑定：按画像表把角色映射到档位，再为档位绑定具体接入点与鉴权；所有调用统一收敛到一个路由网关，避免配置散落。
3. 路由接入：在网关前挂难度分类器，实现“角色默认档 + 任务修正档”的双层路由。
4. 降级与重试：为高档位配置降级路径（如旗舰档限流时由均衡档临时接管）；但对设有质量红线的环节（如最终审查）显式关闭降级，宁可排队也不降档。
5. 成本基线：压测并记录每个角色的 token 用量、单价、时延与成功率，算出“每任务成本”和“每返工成本”两个基准值。
6. 周期性复盘：按周或按迭代执行“质量不达标→升档、高档低效→降档”，让配置随任务结构动态演进，而不是一次配完就束之高阁。

七、把成本再往下压的四个工程手段

1. 上下文治理。规划器与执行器的上下文最贵也最臃肿：检索结果先摘要再入上下文，历史对话按时序裁剪，代码类输入只传必要的 diff。上下文长度每降一档，成本近似线性下降。
2. 结果缓存与复用。相同的检索、摘要与分类结果直接命中缓存；对确定性强的中间产物建立幂等键，避免重复计算。
3. 采样参数收紧。代码生成类任务调低温度、限制输出上限，减少冗长解释与无效重试；创意写作类再按需放开。
4. 观测闭环。把各角色的调用量与 token 明细接入日志服务，并配置监控告警盯住异常突增；按角色输出一张“成本—质量”对照看板，作为升降档决策的唯一依据。云上通用的日志与监控告警类产品即可满足这类需求，例如百度智能云上的对应类目。

八、常见的五个坑

1. 用旗舰模型做检索：成本翻倍、时延拉长，产出却只是几十行引用——典型的花大钱办小事。
2. 在规划环节省预算：小模型的计划碎片化，下游反复返工，返工消耗的 token 远超省下的差价。
3. 审查环节用廉价档：漏检直接流入交付链路，质量问题在最后一公里爆发，修复成本成倍上升。
4. 多模态临时补救：平时不配视觉能力，遇到截图、设计稿才临时顶替，输入结构对不上，效果不可控。
5. 只看单价不看返工率：真实的成本公式是“单价 × 调用量 ×（1 + 返工率）”，返工率往往才是最大的变量。

九、小结

低成本配置多智能体编程系统，靠的不是把每个环节都换成便宜模型，而是把最贵的能力精准花在最不能出错的地方：角色画像决定默认档位，任务路由决定实际档位，降级与观测保证系统在预算内稳定运行。当预算再次收紧时，优先压缩的应当是检索与子任务这类跑量环节；而规划与审查这两个高杠杆环节，永远是最后才该省的地方。