大模型选型与成本控制：从单模型到多智能体工作流实战指南

1. 模型家族选型的底层逻辑与决策框架

1.1 为什么选型比调参更致命

我见过太多团队在模型选型上栽跟头。项目启动时拍脑袋选了个旗舰模型，跑了两周发现成本失控，回头换模型时发现整个提示词体系、工具调用链路、输出解析逻辑全部要重写。这种返工成本，远比一开始花两天做选型评估要高得多。

模型选型的本质是一道多约束优化题。约束条件包括：任务精度下限、单次调用延迟上限、月度预算天花板、数据合规边界、并发吞吐要求。目标函数是综合性价比最大化。很多人只盯着“哪个模型最强”这一个维度，忽略了其他约束，结果就是选出来的方案在纸面上很美，落地时处处掣肘。

一个实用的决策框架是这样的：先把任务按复杂度分层，再按层级匹配模型档位。不是所有任务都需要旗舰模型，就像不是所有运输任务都需要重型卡车。日常的意图识别、格式转换、简单摘要，用小模型完全够用；只有涉及复杂推理、多步规划、跨领域知识整合的任务，才值得调用旗舰模型。

1.2 模型家族的分层逻辑

当前主流模型家族通常按能力与成本分为三到四个档位。以典型的家族结构为例：

选型的核心动作是：把业务流程拆成原子任务，给每个原子任务标注复杂度等级，然后映射到对应档位。这个映射关系一旦确定，后续的成本估算和性能调优就有了基准线。

1.3 选型评估的实操方法

我通常用一套“三周评估法”来做选型决策。第一周做能力基线测试，第二周做成本压力测试，第三周做稳定性验证。

能力基线测试的关键是构建一个覆盖真实业务场景的评测集。不要用公开榜单，那些数据对你的业务没有直接参考价值。从历史工单、用户日志里抽取200到500条真实样本，人工标注期望输出，然后跑一遍候选模型，计算准确率、召回率和格式合规率。

成本压力测试要模拟峰值流量。很多人只算平均成本，忽略了峰值时段的资源竞争和限流问题。你需要知道：当并发请求达到日常峰值的3倍时，各候选模型的响应延迟如何变化，是否触发限流，限流后的降级策略是什么。

稳定性验证至少跑72小时连续请求，观察错误率、超时率和输出质量波动。我遇到过某个模型在连续运行48小时后开始出现输出退化的情况，这种问题在短时间测试中根本发现不了。

注意：评估集一定要包含“边界样本”——那些模棱两可、信息不完整、需要模型说“我不知道”的输入。很多模型在边界样本上的表现差异，比在标准样本上大得多。

2. 成本控制的精细化运营策略

2.1 成本结构的完整拆解

很多人算模型成本只算token单价，这是远远不够的。完整的成本结构至少包括以下几层：

直接成本：输入token费用、输出token费用、多模态处理费用（如图片、音频的编码开销）。这部分最直观，但往往只占总成本的一半左右。

间接成本：重试开销、失败请求的浪费、提示词冗余带来的额外token消耗。我见过一个团队因为提示词里塞了大量重复的示例，导致每次调用的输入token是必要量的3倍，光这一项每月多花好几千。

运维成本：监控告警、日志存储、人工审核、模型切换的工程投入。这部分容易被忽略，但在多模型混用的架构里占比不小。

机会成本：选错模型导致的业务延迟、用户体验下降、市场份额损失。这部分最难量化，但影响最大。

2.2 提示词层面的成本优化

提示词是成本控制的第一道防线。几个实操要点：

精简系统提示词。系统提示词每次调用都会计入输入token。如果你的系统提示词有2000字，每天调用10万次，那就是2亿token的输入消耗。把系统提示词压缩到500字以内，直接省掉75%的输入成本。

动态上下文管理。长对话场景下，不要每次都把完整历史传给模型。用滑动窗口加摘要的方式，只保留最近N轮对话和之前对话的压缩摘要。具体策略是：保留最近5轮完整对话，更早的对话用200字以内的摘要替代。

输出长度控制。在提示词里明确要求“用不超过X字回答”，并在API参数里设置max_tokens上限。很多模型的默认输出长度远超实际需要，不加限制就是浪费。

缓存复用。对于相同或相似的请求，建立结果缓存。比如FAQ类问答，命中缓存直接返回，不调用模型。缓存命中率每提升10%，成本就下降接近10%。

2.3 架构层面的成本控制

分级路由。不是所有请求都走旗舰模型。用一个轻量级分类器先判断请求复杂度，简单请求路由到轻量模型，复杂请求才走旗舰模型。实测下来，这种分级路由能降低40%到60%的综合成本。

批处理。对于非实时任务，把多个请求合并成一个批次调用。很多模型对批处理有折扣，而且批处理能提高吞吐效率。适合批处理的场景包括：夜间数据清洗、批量内容生成、离线分析报告。

流式输出与提前终止。对于长输出任务，用流式输出，并在检测到足够信息时提前终止。比如让模型生成一个列表，你只需要前5项，那就设置停止条件，生成到第5项就中断，不用等它把20项都写完。

降级策略。当旗舰模型不可用或成本超限时，自动降级到标准模型或轻量模型。降级策略要提前设计好，包括降级触发条件、降级后的提示词调整、降级期间的监控告警。

2.4 成本监控与告警体系

没有监控的成本控制是盲目的。我建议至少建立三个维度的监控：

实时消耗看板：按小时统计token消耗和费用，按模型、按业务线、按调用来源拆分。这样能快速定位异常消耗。

预算告警：设置日预算、周预算、月预算三级告警。达到80%时预警，达到100%时触发降级或限流。

成本归因分析：每周做一次成本归因，找出消耗最大的前10个调用来源，分析是否有优化空间。很多时候，20%的调用来源消耗了80%的成本。

3. 长任务工作流的设计与实现

3.1 长任务的核心挑战

长任务工作流和单次调用是完全不同的游戏。单次调用你只需要关心输入输出质量，长任务你要关心的是：状态管理、错误恢复、进度追踪、资源释放、超时控制。

我定义的长任务是：需要超过5次模型调用、跨越多个步骤、执行时间超过30秒的工作流。这类任务在代码生成、研究报告撰写、多轮数据分析、复杂决策支持等场景中非常常见。

长任务最大的挑战是“中间状态丢失”。如果第7步失败了，你不能从头再来，那样成本和时间都受不了。你需要能够从第7步的检查点恢复，只重跑失败的那一步。

3.2 工作流引擎的选型

工作流引擎的选择取决于你的技术栈和团队习惯。几个主流方向：

代码优先：用Python或TypeScript直接编排工作流，用函数调用和状态机管理流程。优点是灵活、可控、调试方便；缺点是需要自己实现重试、持久化、监控等基础设施。

框架驱动：用LangChain、LlamaIndex、AutoGen等框架来编排。优点是开箱即用、社区生态丰富；缺点是抽象层多、调试困难、版本升级容易破坏兼容性。

平台化：用云厂商的工作流服务或低代码平台。优点是运维省心、可视化编排；缺点是灵活性受限、供应商锁定、成本不透明。

我的建议是：核心业务逻辑用代码优先的方式自己控制，辅助功能用框架加速开发。不要把所有东西都押注在一个框架上，保持可替换性。

3.3 状态管理与检查点设计

长任务的状态管理要解决三个问题：状态存什么、存在哪、怎么恢复。

状态内容：至少包括当前步骤编号、已完成步骤的输出摘要、待处理步骤的输入参数、全局变量、错误记录。不要存完整的中间输出，存摘要和引用即可，否则状态会膨胀得很快。

存储选型：轻量级用Redis或SQLite，重量级用PostgreSQL或对象存储。关键是要支持原子写入和快速读取。我通常用Redis存热状态，用PostgreSQL做持久化备份。

检查点策略：每完成一个关键步骤就写一次检查点。检查点要包含足够的信息，使得从该点恢复时不需要重新执行之前的步骤。检查点的写入频率要权衡：太频繁影响性能，太稀疏恢复成本高。

# 检查点写入的简化示例 import json import redis r = redis.Redis(host='localhost', port=6379, db=0) def save_checkpoint(task_id, step, state): checkpoint = { 'task_id': task_id, 'step': step, 'state': state, 'timestamp': time.time() } r.set(f'checkpoint:{task_id}', json.dumps(checkpoint)) # 同时写入持久化存储 db.execute( 'INSERT INTO checkpoints (task_id, step, state) VALUES (%s, %s, %s)', (task_id, step, json.dumps(state)) ) def load_checkpoint(task_id): data = r.get(f'checkpoint:{task_id}') if data: return json.loads(data) # 回退到数据库查询 row = db.query('SELECT * FROM checkpoints WHERE task_id = %s ORDER BY step DESC LIMIT 1', (task_id,)) return row

3.4 错误恢复与重试策略

长任务中的错误分三类：瞬时错误（网络抖动、限流）、逻辑错误（模型输出不符合预期）、系统错误（依赖服务不可用）。

瞬时错误：用指数退避重试，最多重试3次。退避基数建议1秒，倍数2，即1秒、2秒、4秒。超过3次失败则标记为需要人工介入。

逻辑错误：不要盲目重试，因为同样的输入大概率得到同样的错误输出。应该做的是：记录错误上下文，尝试用修正后的提示词重新调用，或者切换到备用模型。如果连续两次逻辑错误，触发人工审核流程。

系统错误：立即停止当前任务，保存检查点，将任务标记为“暂停”状态。等依赖服务恢复后，从检查点恢复执行。

实操心得：重试逻辑一定要有上限，并且每次重试都要记录日志。我见过一个任务因为重试逻辑没有上限，在模型持续返回错误的情况下无限循环，一晚上烧掉了半个月的预算。

3.5 超时控制与资源释放

长任务必须有超时控制。没有超时控制的任务就像没有刹车的车，迟早出事。

单步超时：每个模型调用设置独立的超时时间，通常30到120秒，取决于任务复杂度。超时后立即中断，记录超时原因。

整体超时：整个工作流设置总超时时间，比如10分钟或30分钟。达到总超时后，强制终止任务，保存当前状态，返回部分结果。

资源释放：任务终止或完成后，要释放占用的资源：关闭数据库连接、清理临时文件、释放锁、更新任务状态。这些清理动作要放在finally块里，确保无论任务成功还是失败都会执行。

4. 多智能体协作的架构与实战

4.1 多智能体不是万能药

多智能体架构最近很火，但我要泼一盆冷水：不是所有任务都需要多智能体。单智能体加工具调用能解决的问题，不要上多智能体。多智能体带来的复杂度是指数级增长的：通信开销、状态同步、冲突解决、调试难度，每一项都是坑。

多智能体真正适用的场景是：任务可以清晰分解为多个子任务，子任务之间有依赖关系但可以并行执行，且每个子任务需要不同的专业能力或工具集。典型场景包括：复杂代码库的重构、多源数据的研究报告生成、跨领域的方案设计。

4.2 角色设计与职责划分

多智能体架构的第一步是角色设计。每个智能体应该有明确的职责边界和输入输出规范。

规划者：负责将复杂任务分解为子任务，制定执行计划，分配任务给执行者。规划者不需要很强的生成能力，但需要很强的推理和分解能力。

执行者：负责执行具体子任务。可以有多个执行者，每个执行者专注于特定领域或工具集。执行者的提示词要包含明确的输出格式要求。

审核者：负责检查执行者的输出质量，发现错误或遗漏，决定是否需要返工。审核者的标准要明确，不能太主观。

协调者：负责管理智能体之间的通信，解决冲突，汇总最终结果。协调者通常由规划者兼任，也可以独立设置。

角色设计的关键原则是：每个角色的职责要单一，输入输出要标准化，角色之间的依赖关系要清晰。

4.3 通信协议与消息格式

多智能体之间的通信需要统一的协议。我推荐用结构化的JSON消息格式，包含以下字段：

{ "message_id": "唯一标识", "sender": "发送者角色", "receiver": "接收者角色", "task_id": "所属任务ID", "message_type": "request/response/notification/error", "payload": { "content": "消息内容", "metadata": "附加信息" }, "timestamp": "发送时间", "priority": "优先级" }

通信方式有两种：直接消息和黑板模式。直接消息是点对点发送，适合明确的请求-响应场景。黑板模式是共享一个消息队列，所有智能体都可以读写，适合需要多方协作的场景。

我通常用混合模式：关键路径用直接消息保证可靠性，辅助信息用黑板模式提高灵活性。

4.4 冲突解决与共识机制

多智能体系统中，冲突是常态。两个执行者可能给出矛盾的输出，审核者可能对同一输出有不同判断，规划者可能收到冲突的进度报告。

冲突解决的第一原则是：提前定义优先级规则。比如，当执行者和审核者意见不一致时，以审核者为准；当两个执行者输出矛盾时，由规划者裁决。

第二原则是：引入投票机制。对于需要共识的决策，让多个智能体独立判断，然后投票。投票可以是多数决，也可以是加权投票（根据智能体的历史准确率加权）。

第三原则是：设置升级路径。当冲突无法在智能体层面解决时，升级到人工审核。不要试图让智能体自己解决所有冲突，有些冲突就是需要人类判断。

4.5 多智能体工作流的实操案例

以一个“技术调研报告生成”任务为例，展示多智能体工作流的完整流程：

任务输入：调研某个技术方向的最新进展，输出一份3000字的报告。

规划者：将任务分解为四个子任务——收集资料、整理要点、撰写初稿、审核修订。分配给四个执行者。

收集者：调用搜索工具，收集20到30篇相关文章和论文，提取关键信息，输出结构化的资料摘要。

整理者：接收收集者的输出，按主题分类，提取核心观点和数据，输出要点列表。

撰写者：接收整理者的要点列表，按照报告模板撰写初稿，输出完整的报告文本。

审核者：检查报告的完整性、准确性、逻辑性，标记需要修改的地方，输出审核意见。

协调者：根据审核意见，决定是否需要返工。如果需要，将修改任务发回给撰写者；如果不需要，汇总最终报告。

这个流程中，每个智能体的输出都是下一个智能体的输入，形成流水线。关键控制点是审核环节，它决定了报告的质量下限。

注意事项：多智能体工作流的调试非常困难。建议在开发阶段给每个智能体的输入输出都打上详细日志，并且提供一个“单步执行”模式，方便定位问题。

5. 常见问题与排查技巧实录

5.1 模型输出格式不稳定的排查

这是最高频的问题。模型有时候输出JSON，有时候输出Markdown，有时候夹杂解释性文字。排查思路：

首先检查提示词是否明确指定了输出格式。如果提示词里只说“输出JSON”，模型可能理解为“用JSON格式回答”，而不是“只输出JSON”。要明确写“只输出JSON，不要包含任何其他文字”。

其次检查是否有示例。在提示词里给一个输出格式的示例，比单纯描述格式有效得多。示例要覆盖边界情况，比如空值、多值、嵌套结构。

最后检查解析逻辑。解析器要能容忍常见的格式偏差：多余的换行、缺失的引号、中文标点。用宽容的解析策略，而不是严格的schema校验。

5.2 长任务中途失败的恢复

长任务失败后，第一件事是查看检查点。如果检查点存在且完整，直接从检查点恢复。如果检查点丢失或不完整，需要评估重跑成本。

恢复时要注意：检查点之后的外部依赖是否发生了变化。比如，检查点之前调用的某个API返回了数据，恢复时这个数据可能已经过期。需要在恢复逻辑里加入依赖检查。

如果检查点机制失效，退而求其次的方案是：从最近的稳定状态重新开始，但跳过已经确认完成的步骤。这需要每个步骤都有幂等性保证。

5.3 成本突然飙升的应急处理

成本飙升通常有三个原因：调用量突增、单次调用token量突增、模型路由错误。

排查顺序：先看调用量，再看单次token量，最后看路由配置。调用量突增可能是业务增长，也可能是爬虫或异常请求。单次token量突增可能是提示词被意外修改，或者上下文管理失效。路由错误可能是分级路由的阈值设置不当，导致大量请求走了旗舰模型。

应急处理：立即启用限流，把非核心业务的调用暂停，核心业务降级到轻量模型。同时排查根因，修复后再逐步恢复。

5.4 多智能体死锁的预防

多智能体死锁的典型表现是：两个智能体互相等待对方的输出，或者一个智能体反复请求另一个智能体但没有进展。

预防措施：设置最大交互轮次。比如，两个智能体之间的对话最多进行5轮，超过5轮没有达成一致就升级到人工。设置超时机制，每个智能体的等待时间不超过30秒。设置死锁检测，如果发现两个智能体在短时间内反复交换相同内容的消息，立即中断并告警。

5.5 模型切换的平滑过渡

业务发展过程中，切换模型是常态。平滑过渡的关键是：抽象层隔离、灰度切换、回滚预案。

抽象层隔离：不要让业务代码直接调用特定模型的API。加一层适配器，把模型调用统一成内部接口。切换模型时只需要改适配器，业务代码不动。

灰度切换：新模型先接10%的流量，观察一周。指标正常后逐步增加到30%、50%、100%。灰度期间要对比新旧模型的输出质量、延迟、成本。

回滚预案：切换过程中如果发现严重问题，要能快速回滚到旧模型。回滚时间控制在5分钟以内。回滚后要保留新模型的调用日志，用于事后分析。

6. 工具链与基础设施选型建议

6.1 可观测性建设

模型调用的可观测性比传统服务更重要，因为模型的输出是不确定的。你需要记录每次调用的完整上下文：输入提示词、输出内容、token消耗、延迟、模型版本、调用来源。

我通常用三层可观测性：指标层（Prometheus）记录量化的数据，日志层（ELK或Loki）记录详细的调用日志，追踪层（Jaeger或OpenTelemetry）记录跨服务的调用链路。

关键指标包括：P50/P95/P99延迟、错误率、token消耗速率、缓存命中率、降级触发次数。这些指标要能按模型、按业务线、按调用来源下钻。

6.2 提示词管理

提示词是模型应用的核心资产，需要像代码一样管理。版本控制、变更记录、A/B测试、回滚能力，一个都不能少。

我建议把提示词存在数据库或配置中心，而不是硬编码在代码里。每次修改提示词都要记录：修改人、修改时间、修改内容、修改原因、影响范围。提示词的变更要经过审核，重要提示词的变更要经过A/B测试验证。

6.3 评测体系建设

没有评测体系，你就不知道模型切换或提示词修改是变好了还是变坏了。评测体系包括：评测集管理、自动评测流水线、人工评测流程、评测报告。

评测集要持续更新，把线上发现的bad case补充进去。自动评测流水线要能一键跑完所有候选模型，输出对比报告。人工评测用于评估自动评测覆盖不到的维度，比如创造性、语气、文化适配性。

这套体系建起来需要投入，但一旦建成，后续的模型迭代效率会大幅提升。我自己的经验是，评测体系建成后，模型切换的决策时间从两周缩短到两天。

6.4 安全与合规检查

模型应用的安全检查包括：输入过滤（防止提示词注入）、输出过滤（防止敏感信息泄露）、权限控制（防止越权调用）、审计日志（满足合规要求）。

提示词注入是当前最突出的安全风险。防护手段包括：输入清洗（移除特殊字符和指令性语言）、提示词加固（在系统提示词里加入防注入指令）、输出校验（检查输出是否包含敏感操作）。

审计日志要记录：谁在什么时候调用了哪个模型、输入是什么、输出是什么、消耗了多少资源。日志保留时间根据合规要求确定，通常不少于6个月。

7. 从单点到体系：能力建设的路线图

7.1 阶段一：单模型跑通核心场景

这个阶段的目标是验证可行性。选一个模型，跑通一个核心场景，把端到端的流程走通。不要追求完美，先让流程跑起来。

关键产出：可运行的demo、初步的评测数据、成本基线。这个阶段通常需要2到4周。

7.2 阶段二：多模型分级与成本优化

在单模型跑通的基础上，引入分级路由和成本优化。把简单任务分流到轻量模型，复杂任务保留给旗舰模型。建立成本监控和告警。

关键产出：分级路由策略、成本监控看板、优化后的成本基线。这个阶段通常需要4到6周。

7.3 阶段三：长任务工作流与多智能体

当单次调用和简单链路都稳定后，开始建设长任务工作流和多智能体协作。先从一个具体的长任务场景入手，把状态管理、检查点、错误恢复这些基础设施建好。

关键产出：工作流引擎、检查点机制、多智能体协作框架。这个阶段通常需要6到10周。

7.4 阶段四：体系化运营与持续优化

最后一个阶段是把前面建好的能力体系化：评测体系、提示词管理、可观测性、安全合规。形成一套可持续运营的机制，让模型应用能够持续迭代和优化。

关键产出：评测流水线、提示词管理平台、可观测性体系、安全合规流程。这个阶段是持续进行的，没有明确的结束时间。

我在实际推进这些阶段时最大的体会是：不要跳步。很多团队在阶段一还没跑稳的时候就急着上多智能体，结果基础不牢，后面到处补窟窿。每个阶段的核心能力建扎实了，下一阶段自然水到渠成。

最后分享一个实用技巧：在每个阶段结束时，做一次“复盘文档”，记录这个阶段踩过的坑、有效的做法、遗留的问题。这份文档在后续阶段会反复用到，也能帮助新加入的团队成员快速理解上下文。