多Agent系统如何为每个Agent选对模型

为什么大多数团队用错了模型策略

在多Agent系统中，一个常见却容易被忽视的决策是：每个Agent应该用哪个模型？据Reddit社区的一篇技术讨论指出，大多数团队让所有Agent跑在同一个模型上——这意味着要么为简单的查询支付前沿模型的高昂费用，要么在需要判断力的任务上得到偏弱的回答。

按Agent分配模型的思路，能同时解决这两个问题。原文以一个发票管理产品为例：客户余额查询每小时运行数百次，用小模型足以控制成本；催收邮件需要恰当的语气，交给前沿模型撰写；合同分析涉及不能离开客户云环境的数据，则通过Ollama或vLLM在本地模型上运行。三个Agent、三个模型，共处于同一个系统。

落地时的关键实践

不需要额外的路由器

原文强调，在Team结构下，每个Agent自带模型配置，由leader决定哪个Agent处理哪个请求。这省去了单独搭建路由层的复杂度——模型选择内嵌在Agent定义里，而非外挂一个调度组件。

在Multi-Agent（多智能体）架构中，Leader（领导者）模式指的是一种层级式协作结构：一个主控Agent接收用户请求，根据任务内容将其分派给具备不同专长的子Agent，并汇总结果返回。与“路由器”组件不同，Leader本身也是Agent，拥有自己的模型配置与指令，它的调度决策由模型推理完成，而非预定义的规则或分类器。这种设计的好处是调度逻辑与业务语义天然对齐，新增或调整子Agent时无需改动中心化路由表；代价是Leader本身会消耗token，且其判断质量直接影响任务分派的准确性。因此Leader通常应选用推理能力较强的模型，而子Agent则可根据任务复杂度灵活降档。

为故障切换提前设计

主模型失败时，fallback_models可以把调用转移到另一个供应商，前提是备选模型支持相同的工具与功能。这一点在工程上容易被忽略：降级不只是换个模型名，还要保证工具调用、结构化输出等能力对齐，否则切换会直接失败。

**fallback_models（故障切换模型）**是指在主模型调用失败——如超时、限流、服务不可用或返回格式异常——时，系统自动改用的备选模型列表。在多Agent系统中，降级切换的难点不在于发起重试，而在于能力对齐：Agent依赖的工具定义（function calling schema）、结构化输出格式（如JSON mode）、上下文窗口大小等，在备选模型上必须同样可用，否则切换后调用会因不兼容而失败。工程上通常需要维护一组“能力标签”，在配置fallback时校验备选模型是否满足当前Agent所需的最小能力集，并将切换事件记入可观测性日志，以便区分“优雅降级”与“静默错误”。

切换模型不改Agent逻辑

换模型只需改模型字符串，instructions、tools和memory保持原样。这种解耦意味着团队可以先用强模型验证流程，再逐步把合适的Agent换成更便宜的模型，而不用重写Agent本身。

先跑评测，再切换

原文的建议很明确：先运行你的evals，再动手换模型。凭直觉判断“这个任务小模型应该够用”风险很高，评测数据才是切换的依据。

**Evals（模型评测）**在LLM应用语境下，指针对具体任务构建的自动化测试集：由一组带参考答案或评分标准的输入样本组成，用来量化模型在真实业务场景中的表现。与通用基准测试不同，Agent场景的evals通常需要评估端到端行为，包括工具调用是否正确、多轮对话是否保持状态、输出格式是否符合下游解析要求等。实践中常用“LLM-as-judge”（用强模型给弱模型输出打分）与人工抽检相结合的方式。评测集应在模型切换前建立基线，切换后做回归对比，并随业务变化持续扩充，否则评测本身会迅速失效。

按任务成本而非token单价决策

这是一个反直觉但重要的观点：一个token单价翻倍、但一次调用就能完成任务的模型，往往比需要三次调用的便宜模型总成本更低。只看每token价格会误导模型选择，应该看每个任务的端到端成本。

Token单价是模型API按输入/输出token计费的价格，但它只是成本的一部分。一个任务的真实成本还应计入：调用次数（多步推理会放大消耗）、失败重试的开销、上下文长度带来的输入膨胀，以及人工复核弱模型输出所投入的时间。这正是“每任务成本”（cost per task）视角的价值所在——它把模型选择还原为端到端的业务账。举例来说，单价低但需要三轮工具调用才能完成的模型，其总token消耗与延迟可能都高于单价高但一次命中的模型；而当输出需要人工兜底时，隐性人力成本往往远超API费用差额。

对Agent架构设计的启示

原文的核心判断是：系统中大多数Agent并不需要最强的模型，而真正需要强模型的Agent通常很容易识别——比如对语气、判断力或复杂推理有要求的环节。这个观察把模型选择从“全局配置”变成“逐Agent决策”，也让成本与质量在同一系统内得以分档管理。

对于正在搭建多Agent系统的团队，这意味着在架构初期就应把“模型”视为Agent的一个可配置属性，而非系统级的统一前提。配合评测体系和fallback设计，模型切换可以成为常规运维动作，而不是一次伤筋动骨的重构。

原文还提到其知识库中覆盖了选择模型时的七个问题、不同任务的起点建议以及每种模式的代码示例，可作为进一步实践的参考。