1. 选型之前，先拆解“模型家族”到底意味着什么

第一次听说“GPT-6 模型家族”这个概念的时候，我以为是某个厂商把几个模型打包卖，后来实际调研了一圈才发现，事情比想象中复杂得多。模型家族并不是“一个模型 + 几个阉割版”，而是一整套覆盖不同任务类型、不同性能档位、不同成本区间的模型组合。你可以在同一个接口体系下，根据任务难度动态切换不同规模的模型，而不是像以前那样，一个大模型打天下。

这种做法背后的逻辑其实很现实：不是所有任务都需要顶配模型。一个“给我写一段产品文案”的需求，和“从这份 50 页的合同中提取所有违约责任条款并生成对比报告”的需求，它们对模型的推理能力、上下文长度、指令遵循精度的要求完全不同。如果统一用顶配模型处理，成本会失控；如果统一用轻量模型处理，复杂任务的输出质量又没法保证。模型家族解决的就是这个“按需分配”的问题。

在开始选型之前，我建议你先做三件事：

• 梳理任务类型：把你要用模型处理的任务全部列出来，按“简单/中等/复杂”分档，标注每个任务对上下文长度、推理深度、输出格式的要求。这一步很花时间，但值得做。我当时列了 120 多个任务场景，最后归并成 11 类，选型一下子清晰了。
• 明确调用量级：预估每天的 API 调用次数、单次调用的平均输入 token 数和输出 token 数。如果没有历史数据，按最坏情况估算，宁多勿少。
• 确定质量底线：哪些任务允许模型偶尔“偷懒”，哪些任务必须保证输出结构的完整性？这个判断直接影响你要不要为某个任务专门上最高档位的模型。

做完这三步，你会发现模型家族的选型问题，本质上变成了一个“任务匹配”问题，而不是“哪个模型更强”的问题。这是我踩过坑之后才想明白的：一开始我纠结于 benchmark 分数，反复对比各个版本模型的跑分，后来发现实际业务里根本用不上那么多极端测试集，真正起决定作用的是任务特征和成本预算的匹配度。

2. 模型家族选型的核心维度与对比逻辑

2.1 按任务复杂度分档：轻量、均衡、顶配的选择标准

我习惯把模型家族里的成员大致分成三档，具体名称不重要，重要的是理解每一档的适用边界。

• 轻量档：适合意图识别、关键词抽取、简单格式化、文本分类等任务。这类任务的特征是：输入输出都很短，逻辑链路简单，模型不需要太多“思考”就能给出正确答案。使用顶配模型处理这些任务，就是典型的杀鸡用牛刀，费用高且响应并不更快（部分场景下大模型甚至因为要加载更多参数，首字延迟更高）。
• 均衡档：适合文案改写、摘要生成、结构化数据抽取、中等复杂度的代码生成、多轮对话等。这类任务需要模型具备一定的上下文理解能力和逻辑组织能力，但不能有明显的事实性硬伤。
• 顶配档：适合长文档深度分析、跨章节推理、复杂代码库理解、多步骤规划、高精度指令遵循等任务。这类任务的特点是：如果模型能力不够，输出会“看起来合理但实质错误”，而且错误隐蔽，人工审核成本极高。

这里有一个很关键的实操点：同一条 prompt，在不同档位模型上的表现差异，可能比你想象中大得多。我曾经用均衡档模型跑一个“从年报中抽取所有涉及关联交易的段落并总结风险点”的任务，结果模型漏掉了藏在附注里的两条关键交易；换到顶配档模型后，它能主动溯源到附注部分。这种差异不是靠优化 prompt 能弥补的，是模型本身推理深度的上限决定的。所以涉及财务、法律、合规等高风险场景，别在模型档位上省钱。

2.2 上下文长度档位：长短任务的分水岭

模型家族里的另一个关键区分维度是上下文长度。有些成员支持 32K 甚至 128K 级别的长上下文，有些只有 8K 到 16K。很多人选型时只看“谁最长”，但实际用起来会发现，长上下文不是免费的——上下文越长，单次调用的费用越高，且注意力的分散可能导致模型忽略关键信息。

我的建议是做一个“上下文预算”评估。具体方法是：

1. 统计你任务中最重要的信息是否集中在输入的前半段，还是分散在全文各处。
2. 估算任务有效工作区间的平均长度：比如阅读 10 页合同，真正需要模型重点分析的可能是第 3 页到第 7 页的核心条款。
3. 对“需要全局理解”的任务，才选用长上下文模型；对“局部抽取”类任务，优先用“预处理切分 + 短上下文模型”组合，成本能低很多。

这里要特别提醒一个长上下文的常见陷阱：当输入接近模型上下文上限时，模型对中部内容的注意力会明显下降，也就是所谓的“lost in the middle”现象。我在处理几十份技术文档合并分析时遇到过多次：文档中段的关键参数被遗漏，首尾的信息则被模型当作重点。解决方法是主动在 prompt 中明确指示“请特别注意文章中部第三章和第 5.2 节的数据”，或者预先对输入做结构重排、章节加粗标记，把重要内容往前放。这个现象在短上下文模型上不明显，换成长上下文后必须重新审视任务设计。

2.3 推理深度档位：要不要为“思考过程”付费

模型家族里还会区分是否具备深度推理模式。简单说，普通模式回答快、成本低，适合大多数日常任务；推理模式会在内部生成更长的推理链路，适合数学、逻辑推导、复杂决策类任务。

实操中的选型逻辑很简单：需要确定性答案的任务，用普通模式；需要推导过程或存在多种可能解的任务，用推理模式。不要给所有任务统一开启推理模式，那会成倍拉高延迟和成本。我之前做过一个对比实验：在 200 条数学应用题上，普通模式的正确率是 62%，推理模式是 91%；而在 200 条文本分类任务上，两者正确率几乎持平，推理模式只高了不到 1%，成本却高了 4 倍。那个分类任务后来被我牢牢锁死在轻量档普通模式。

2.4 选型决策表：快速定位你的任务该用哪一档

这张表是我在实际项目里反复调整后沉淀下来的，不能说完全适合你的业务，但作为起步参照是够用的。核心原则是：先用最低档跑通流程，再针对失败案例逐步升档，而不是一上来就给所有任务上顶配。

3. 成本控制：从 token 计价到整体预算的精细化管理

3.1 token 计费的基本盘：你每调用一次，到底花了多少钱

同样支持 128K 上下文，不同档位模型的 token 单价可能差 5 到 10 倍。我见过很多团队在项目初期完全没做成本模型，结果月底账单出来才发现，光是模型调用费就占掉预算的 40%。

先搞清楚 token 计费的基本规则：

• 输入 token 和输出 token 分开计价，输出通常比输入贵一到两倍（不同档位比例不同）。
• 缓存 token 通常更便宜，如果你的系统会在短时间内反复使用相同的系统提示词或长文档前缀，启用缓存机制能省下不少钱。
• 上下文越长，单次费用越高，哪怕模型只是“读了一下”你的长文档。
• 多轮对话中，之前所有轮次的消息都会累计计入下一次调用的输入 token，所以长对话的成本是等比上升的。

我有个项目做“对话式文档问答”，用户和模型来回聊了二三十轮之后，单次调用的输入 token 数已经到了初始的十倍以上，而大部分历史消息模型根本用不上。后来我加了“上下文裁剪”逻辑：超过一定轮次后，把早期对话压缩成摘要，只保留最近几轮原文。这个改动直接让单次调用成本下降了 47%，模型的响应还更快了。

3.2 降低 token 消耗的五个实用手段

1. 精简系统提示词：系统提示词会参与每一次调用的计费。把冗长的提示词从 2000 token 压到 500 token，长期跑下来省得非常多。我当时把一套包含大量示例的系统提示词做了“最小化重构”：只保留核心约束和最必要的两个示例，结果输出质量没有下降，token 费用直接砍掉 75%，这里指的是输入侧的费用。
2. 预清理输入内容：很多文档里包含页眉页脚、版权声明、无关图表说明，直接喂给模型等于白烧钱。先用脚本做一轮清洗，把有效内容提取出来再送入模型，既能省钱又能减少注意力分散。我对一批 30 页 PDF 测试过，清洗后输入 token 减少了 38%，而关键信息完整率保持在 95% 以上。
3. 启用缓存：如果在同一会话中多次调用模型且输入的前缀部分保持不变，缓存能显著降低费用。这一点在“固定角色设定 + 动态用户消息”的场景下效果最明显。我做过对比，启用缓存后，高频次短对话场景的费用可以降低大约 30% 到 40%。
4. 控制输出长度：在 prompt 里明确要求“回答不超过 100 字”“用三句话以内概括”“只输出 JSON 不要解释”，输出 token 是计费的大头，压缩输出长度比压缩输入更直接。一个真实数据：我在让模型生成商品描述时加了“字数控制在 80-120 字”的硬约束，输出 token 从平均 400 降到了 150 左右，质量评分没有明显变化。
5. 批量处理而非逐条调用：把 50 条短文本合并成一批请求，虽然单次输入 token 变多了，但避免了重复支付系统提示词的费用，整体费用更低。批量处理的另一个好处是能统一走异步接口，吞吐量更高。我实测过：用批量任务接口处理 5000 条短文本分类，比逐条调用节省了约 55% 的成本。

3.3 成本预算模型：如何算出一套可监控的基线

我建立了一套自己的成本基线模型，很简单，但足够用。核心公式：

单任务预估成本 = ( 单次输入token × 输入单价 × 平均调用次数 + 单次输出token × 输出单价 × 平均调用次数 + 缓存未命中的额外输入token × 输入单价 ) × 日调用量 × 30（月）

用真实场景演示一下：

• 任务类型：文档问答，平均每次输入 8000 token，输出 500 token。
• 日调用量：5000 次。
• 使用均衡档模型，假设输入单价为 1 元 / 百万 token，输出单价为 2 元 / 百万 token（示例数值，仅用于演示计算方式）。
• 单次输入费用：8000 / 1000000 × 1 = 0.008 元
• 单次输出费用：500 / 1000000 × 2 = 0.001 元
• 单次总费用：0.009 元
• 月度总费用：0.009 × 5000 × 30 = 1350 元

如果其中有 30% 的调用可以让缓存生效，假设缓存输入 token 单价打五折，那么节省的费用大约是：

• 每次缓存命中的输入 token 平均 6000，费用 6000 / 1000000 × 0.5 = 0.003 元
• 节省：0.008 - 0.003 = 0.005 元/次 × 5000 × 30 × 30% = 225 元

月度总费用就到了 1125 元左右。这个模型不需要很精确，但能帮你判断“哪个环节的成本优化空间最大”。对我而言，这个计算的价值在于：项目上线前，你就能知道成本会落在什么区间，而不是上线后被账单教育。

3.4 成本控制中的两个反直觉陷阱

陷阱一：轻量档模型不一定省钱。如果你的任务本身很复杂，轻量模型给不出可用结果，你需要反复重试、修复、再调用，总调用次数可能是顶配模型的三到五倍。这时候轻量档的总费用反而更高，还搭进去大量人工审核时间。我的判断标准是：如果同一任务在某个档位模型上连续三次输出都达不到可用标准，立刻升档，不要恋战。

陷阱二：上下文切分不一定省钱。把长文档切分成多个短片段分别调用模型，看起来单次费用降低了，但如果每个片段都需要重复携带系统提示词和任务说明，且下游还需要额外一次调用做聚合汇总，总 token 消耗可能反而上升。正确的做法是：先做一次“文档摘要 + 定位”调用，只把相关章节送入第二轮详细分析，用两次调用完成原本需要五六次调用的工作。我在处理 100 页尽调报告时，用这种“先索引后精读”的策略，比直接全文灌入短上下文模型的方案省了大约 40% 的 token。

4. 长任务工作流管理：从单次调用到任务编排

4.1 长任务为什么难管：状态、中断与重试

当你的业务场景从“问一句答一句”升级到“给我把这份 200 页的行业报告读完，输出摘要、关键数据表、风险点清单和趋势预测”这种多步骤长任务时，模型调用就不再是单一请求了，而变成一个需要编排的工作流。

长任务工作流的核心难点有三个：

• 状态管理：任务进行到哪一步了？哪些子任务已经完成，哪些还在排队？中间结果存哪里？
• 中断恢复：模型调用超时、网络抖动、接口限流，任务跑到一半挂了怎么办？怎么做到“断点续传”而不是从头再来？
• 质量把关：中间某一步的输出质量不达标，是继续往下走还是回退重做？

很多团队踩坑就踩在这里：把长任务当成“一个巨大的 prompt 丢给模型”，然后等着它一次性输出。实践结果是：模型要么在长输出中途“忘记”了前面的指令，要么输出到一半被截断，要么整体质量失控。正确思路是把长任务拆解成一个可编排的多阶段流水线。

4.2 长任务拆解方法论：把大任务切成可管的小块

拆解的原则是：每个子任务的输出必须可以被独立验证。如果一个子任务的输出质量你无法判断，那这个拆解就是失败的，因为你不知道后续步骤该不该信任它。

以“分析一份 10 万字的行业白皮书并生成深度研报”为例，我拆成了五个阶段：

1. 全文结构识别：用一次顶配模型调用，提取文档目录结构、章节标题、各级主题，输出为结构化 JSON。这一步的输出可以验证——直接和文档目录比对即可。
2. 章节级摘要：把 JSON 里识别出的每个章节内容喂给模型，逐章生成摘要。这一步可以并行批量调用，每章摘要大约 300 到 500 字，输出质量通过“是否涵盖该章核心论点”来验证。
3. 跨章节关键信息抽取：汇总所有章节摘要，再结合具体章节原文，抽取关键数据、术语定义、争议点。这一步是全流程中唯一需要“全局理解”的，所以用顶配模型 + 足够上下文。
4. 研报初稿生成：基于前一步抽取的信息，按照预设的研报框架生成初稿。
5. 事实核查与引用标注：对初稿中每个论点回溯源章节定位，补充引用出处，检查是否存在“看似合理但原文并不支持”的表述。

这个流程看起来比“一个大 prompt 直接输出研报”复杂，但它的好处很明显：每个阶段都有明确的输入输出，任何一步出问题，你都能定位到具体环节，只需要重跑那一部分，而不是整篇重新生成。我最长的一次任务，是分析一份包含 40 多个章节、约 12 万字的行业报告，整个流程跑下来大约 20 分钟，中途有两个章节摘要因为输出格式异常被自动重试了三次，但整体没有影响。

4.3 用提示词模板固化每个子任务的输入输出结构

拆解完成后，下一步是把每个阶段转化成一套可复用的提示词模板。模板是长任务工作流的灵魂，没有模板，你每次都可能因为措辞微调导致输出结构漂移，下游解析代码直接崩掉。

我建议每个模板至少包含以下部分：

• 角色与目标：只占两三句话，不要冗长。
• 输入数据结构说明：告诉模型你会给它什么格式的数据，字段含义是什么。
• 输出格式要求：指定结构化的输出格式，要求模型只输出该格式，不附带任何解释。
• 边界与约束：哪些内容不能编造、哪些必须保留原文措辞。
• 输出示例：给一个短小的示例，帮助模型理解你要的格式。

举个例子，章节摘要阶段的模板核心部分大致是：

你是一个专业文档分析师。我给你一个章节的标题和正文，请输出该章节的摘要。 输出格式：{"chapter_title": "...", "summary": "..."} 要求： 1. 摘要不超过 400 字。 2. 必须包含该章节的核心论点、关键数据和结论。 3. 不得包含你的个人评价。 4. 如果章节中包含术语定义，请在摘要中保留术语原文。

这个模板我一开始没有加“术语保留”这条，导致下游抽取术语定义时总是丢词，后来在真实任务中发现了这个问题才补上。模板一定是从实际失败中迭代出来的，别指望一次设计就完美。

4.4 状态管理与进度跟踪：至少能让任务“断点续传”

长任务工作流如果只是线性跑一遍，那“状态管理”似乎没必要。但实际工程中，你总要面对超时、限流、服务故障。这时候如果没有状态记录，整个任务就只能从头再来，非常痛苦。

我的做法是引入一份简单的任务状态文件，用 JSON 记录：

• 任务 ID、任务名称、创建时间
• 每阶段的执行状态：pending / running / success / failed
• 已生成产物的存储路径或 ID
• 重试次数与失败原因

当某个阶段失败时，我只需要读取状态文件，找到失败点，把该阶段以及它之后的内容标记为 pending，然后重新启动执行器。执行器会跳过已有成功产物的阶段，直接从失败点继续。

另外，我强烈建议在长任务中加入“检查点”设计。检查点是一段独立代码，负责校验该阶段的输出结果是否符合预期。如果不符合，就自动触发重跑或升档重跑，而不是把错误结果传给下游。检查点的实现要简单，但覆盖面要够。我做成本控制项目时，检查点的主要工作是验证输出 JSON 的合法性、必填字段的完整性，以及引用来源是否真实存在于原文档中。这套设计看起来不起眼，但在实际运行中节约了大量人工纠错时间。

4.5 并行与限流：长任务的加速策略

长任务执行慢，很多时候不是模型推理慢，而是大量子任务串行执行。章节摘要、批量分类、逐段翻译这类子任务天然可以并行。我把并行度设置在 5 到 8 之间，实测整个流水线的耗时能减少一半以上。

但并行会带来两个新问题：限流和乱序。API 对每分钟请求数和每分钟 token 数都有限制，超过就会返回限流错误。我的建议是做一个简单的“令牌桶”控制，动态调整并行度，确保请求量在配额线以下。乱序问题则靠“阶段输出 + 状态记录”解决：每个子任务完成后写入独立记录，全部完成后统一汇总。不要依赖子任务返回顺序。

5. 真实场景实录：一次完整的模型家族选型与工作流落地

5.1 项目背景与目标

为了让你更直观地理解前面这些方法论怎么串起来，我分享一个虚构但典型的项目。项目代号“模拟项目X”，需求是做一个面向企业内部客户的智能文档分析平台：用户上传 PDF、Word、Excel 文件，系统自动完成内容解析、关键信息抽取、按模板生成分析报告。

初期我们评估的需求包含：

• 文档类型：合同、财报、技术方案、会议纪要，单份最长约 200 页。
• 输出形态：结构化的 JSON + 自然语言段落混合报告。
• 用户规模：内部约 50 个并发用户，每日任务量约 800 个。
• 质量要求：关键数据不能错，引用必须能溯源到原文。

5.2 选型落地的判断过程

我们对任务类型做了归并和分级。最终划分为四类：

• 文档解析与预处理：规则脚本完成，不调用模型。
• 实体抽取与表格识别：轻量档模型。
• 章节级摘要与信息汇总：均衡档和顶配档组合使用。
• 跨文档对比与风险识别：顶配档模型，必须开推理模式。

选型时我们用了一批真实业务文档做盲测，每个任务在三个档位的模型上各跑一遍，对比输出质量和失败率。测试结果是：轻量档在实体抽取上的准确率达到 93%，满足要求；章节摘要的语义保留程度均衡档比轻量档好一个档次，直接用均衡档；跨文档对比的风险识别任务，轻量档几乎不可用，均衡档有 20% 的漏报率，顶配档漏报率降到了 5% 以内，所以果断选顶配档。整个选型过程大约花了两周，但换来了后续几个月不再纠结模型选择。

5.3 成本模型搭建和上线后实测对比

按照前面给出的公式，我们做了一个月度成本预估：

• 轻量档：日均 3000 次调用 × 平均 1200 token 输入 + 200 token 输出。
• 均衡档：日均 2600 次调用 × 平均 5000 token 输入 + 800 token 输出。
• 顶配档：日均 300 次调用 × 平均 25000 token 输入 + 2000 token 输出。

带入单价测算后，预计月成本约 6200 元（此处按项目内部模拟单价测算，仅作为方法演示，不代表任何实际价格）。上线后第一个月实测成本为 5400 元，主要差异来自两点：一是文本清洗比预期更有效，实际输入 token 比预估低 18%；二是缓存命中率比预期高，因为企业内大量文档存在重复模板前缀。这个案例验证了一个道理：成本模型的意义不是精准预测，而是帮你建立对费用结构的敏感度。

5.4 长任务工作流的代码骨架参考

以下是一段经过大幅简化的伪代码，演示长任务工作流的核心控制逻辑。它不依赖任何特定框架，你可以照着这个思路用自己熟悉的语言实现。

# 简化版长任务工作流骨架，用于展示控制逻辑 import json, time TASKS = [ {"id": "structure", "depends_on": [], "model": "top", "template": "struct_prompt"}, {"id": "summary", "depends_on": ["structure"], "model": "mid", "template": "summary_prompt"}, {"id": "extract", "depends_on": ["summary"], "model": "top", "template": "extract_prompt"}, {"id": "report", "depends_on": ["extract"], "model": "top", "template": "report_prompt"}, ] def run_workflow(input_file): state = load_state(input_file) for task in TASKS: if state[task["id"]]["status"] == "success": continue # 如果前置依赖未完成，则跳过等待 if not all(state[d]["status"] == "success" for d in task["depends_on"]): continue result = call_model(task["model"], task["template"], state) if validate(result, task["id"]): save_state(task["id"], result) else: retry_or_escalate(task, state) return build_final_output(state) def retry_or_escalate(task, state): # 同档位重试两次，仍失败则升档重跑，最多三次 for attempt in range(3): model_for_run = task["model"] if attempt < 2 else "top" result = call_model(model_for_run, task["template"], state) if validate(result, task["id"]): save_state(task["id"], result) return mark_failed_and_alert(task["id"])

这个骨架虽然简单，但已经覆盖了依赖管理、状态记录、重试与升档、校验这四件事。你们在实际项目中可以基于这个框架扩展出：并行执行、限流控制、监控告警、任务取消与回滚等功能。我的经验是，工作流框架越简单越好，能跑通再加功能，别一开始就上重型架构。

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

6.1 任务超时，整个流程被中断，怎么办

我遇到过最典型的情况是：一个长篇报告分析任务跑了一半，模型调用超时，整个流水线崩溃，所有中间结果全部丢失。这是因为早期的设计没有状态持久化。排查思路是确认超时发生在哪个阶段，把这个阶段的输出单独保存，后续从断点续跑。另一个手段是把单次调用设置更保守的超时阈值，比如 90 秒无响应就主动断开并重试，避免无限等待把整个线程卡死。

6.2 模型输出总是“长了翅膀”——结构化输出不稳定

用 JSON 格式约束模型时，偶尔会出现多出解释性文字、字段名大小写错误、数组嵌套层级不对等问题。我的排查思路是先做输出清洗：用正则把代码块标记和多余文字剥掉，再用 JSON 解析器尝试修复常见错误（如末尾多逗号、单引号替代双引号）。更进一步的办法是在模板里给出一个“只输出 JSON”的强调语句，然后在业务层强制校验格式。如果仍然频繁失败，再考虑升级到顶配模型或切换到支持结构化输出的模式。

6.3 长上下文任务中，模型“忽略”了关键信息，怎么办

前面提到过 lost in the middle 现象。我的排查方法是先确认这份文档的关键信息是否分布在中间位置。如果是，建议把关键内容重新组织到输入的开头或者结尾，或者用“先抽取再分析”的方式，先用一轮调用抽取所有可能相关的段落，把抽取结果作为第二轮输入的上下文，而不是一次性把全文灌入第二轮。这个调整对降低遗漏率非常有效。我还试过在 prompt 中显式声明“请优先关注第 N 章到第 M 章”，也有帮助，但不如结构重排来得稳定。

6.4 成本突增，账单翻了一倍，怎么快速定位

成本突增的排查建议按以下顺序来：

1. 看调用次数是否异常上升：是否存在循环调用、重试风暴。有一次我们某个子任务校验逻辑写错，导致每条结果都被判为不合格，触发了无限重试，调用量翻了 20 倍。
2. 看平均输入 token 是否变大：是否有用户上传了超长文档触发了长上下文模型。给模型设置“超出长度先截断再分析”的策略，避免一切长文本都走完整上下文。
3. 看缓存命中率是否下降：如果系统提示词改了，缓存会大量失效，导致短期成本上升。发布提示词变更时，手工清掉旧缓存并预加载新缓存，能降低冲击。

6.5 轻量档模型“幻觉”严重，怎么在不上顶配的情况下改善

几个偏方：一是给模型提供明确的出处引用要求，要求每个结论附上原文片段，幻觉数量会大幅下降；二是把任务改成“先抽取再判断”两段式，让模型先抽取关键证据，再基于证据做判断，减少凭空编造的空间；三是在边界处加限制，明确告诉模型“如果原文中没有相关信息，输出未知，不要猜测”。这些手段不能完全消除幻觉，但能把率值压低一截，对于轻量档场景够用。

6.6 常见问题速查表

7. 几点实操体会与长期建议

聊到最后，分享几个我在真实项目里沉淀下来的经验。

第一个体会是：选型、成本、工作流管理，这三件事不能分开做。只选型不管成本，预算会失控；只抠成本不管质量，模型输出会拖垮下游；只搭工作流不注重可选型优化，相当于在沙地上建大厦。我见过一些团队，工作流编排做得非常精美，但因为顶层模型选型偏差，导致整体质量和成本长期处于不健康状态。好的做法是以“任务-模型-成本-流程”四个维度作为一个整体来评估，任何一次调整至少要考虑其中两个维度的影响。

第二个体会是：监控指标里，除了延迟和成功率，一定要加上“单任务成本”和“输出重试率”。这两个指标能提前暴露很多问题。比如发现某个任务的输出重试率持续走高，往往说明模型档位和任务难度不匹配，或 prompt 模板有缺陷；发现单任务成本异常，则说明上下文管理或缓存策略有优化空间。

第三个体会是：尽量保持工作流核心逻辑的“可替换性”。今天你用的是某个模型家族，明天可能因为成本或质量原因切换到另一个平台。依赖抽象只放在模型调用层，即使底层芯片或云端服务发生变化，也不影响业务流程的稳定运行。我早期犯过依赖具体模型名称写硬编码的错，后来切换模型时改了三天代码。现在所有模型名都放在配置表中，切换只需要更新配置。

最后再分享一个小技巧：在每个任务的 prompt 模板版本上打个标签，记录它的效果、成本和失败案例。很多人优化完 prompt 就把旧版本覆盖掉，等发现回归时找不回原版。我的习惯是保留最近三版模板，每一版都记录“什么时候改的、为什么改、上线后效果如何”。这个习惯在排查问题和复现结论时帮了我大忙，也是模型家族选型之后最值得做的基础工程。