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%的成本。优化手段预期成本降幅实施难度适用场景提示词精简15%-30%低所有场景分级路由40%-60%中请求复杂度差异大结果缓存10%-25%低重复请求多批处理20%-40%中非实时任务输出长度控制10%-20%低所有场景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(hostlocalhost, port6379, db0) def save_checkpoint(task_id, step, state): checkpoint { task_id: task_id, step: step, state: state, timestamp: time.time() } r.set(fcheckpoint:{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(fcheckpoint:{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 row3.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秒。设置死锁检测如果发现两个智能体在短时间内反复交换相同内容的消息立即中断并告警。问题类型典型表现排查方向解决手段格式不稳定输出结构不一致提示词、示例、解析器明确格式要求、加示例、宽容解析任务中断执行到某步停止检查点、依赖服务、超时恢复检查点、重试、调整超时成本飙升费用异常增长调用量、token量、路由限流、降级、修复路由智能体死锁互相等待无进展交互轮次、超时、消息内容设最大轮次、超时、死锁检测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 阶段四体系化运营与持续优化最后一个阶段是把前面建好的能力体系化评测体系、提示词管理、可观测性、安全合规。形成一套可持续运营的机制让模型应用能够持续迭代和优化。关键产出评测流水线、提示词管理平台、可观测性体系、安全合规流程。这个阶段是持续进行的没有明确的结束时间。我在实际推进这些阶段时最大的体会是不要跳步。很多团队在阶段一还没跑稳的时候就急着上多智能体结果基础不牢后面到处补窟窿。每个阶段的核心能力建扎实了下一阶段自然水到渠成。最后分享一个实用技巧在每个阶段结束时做一次“复盘文档”记录这个阶段踩过的坑、有效的做法、遗留的问题。这份文档在后续阶段会反复用到也能帮助新加入的团队成员快速理解上下文。 
长河君 · 2026/10/26 15:06:07 · 阅读 1.2k 大模型选型与成本控制：从单模型到多智能体工作流实战指南
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%的成本。优化手段预期成本降幅实施难度适用场景提示词精简15%-30%低所有场景分级路由40%-60%中请求复杂度差异大结果缓存10%-25%低重复请求多批处理20%-40%中非实时任务输出长度控制10%-20%低所有场景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(hostlocalhost, port6379, db0) def save_checkpoint(task_id, step, state): checkpoint { task_id: task_id, step: step, state: state, timestamp: time.time() } r.set(fcheckpoint:{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(fcheckpoint:{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 row3.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秒。设置死锁检测如果发现两个智能体在短时间内反复交换相同内容的消息立即中断并告警。问题类型典型表现排查方向解决手段格式不稳定输出结构不一致提示词、示例、解析器明确格式要求、加示例、宽容解析任务中断执行到某步停止检查点、依赖服务、超时恢复检查点、重试、调整超时成本飙升费用异常增长调用量、token量、路由限流、降级、修复路由智能体死锁互相等待无进展交互轮次、超时、消息内容设最大轮次、超时、死锁检测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 阶段四体系化运营与持续优化最后一个阶段是把前面建好的能力体系化评测体系、提示词管理、可观测性、安全合规。形成一套可持续运营的机制让模型应用能够持续迭代和优化。关键产出评测流水线、提示词管理平台、可观测性体系、安全合规流程。这个阶段是持续进行的没有明确的结束时间。我在实际推进这些阶段时最大的体会是不要跳步。很多团队在阶段一还没跑稳的时候就急着上多智能体结果基础不牢后面到处补窟窿。每个阶段的核心能力建扎实了下一阶段自然水到渠成。最后分享一个实用技巧在每个阶段结束时做一次“复盘文档”记录这个阶段踩过的坑、有效的做法、遗留的问题。这份文档在后续阶段会反复用到也能帮助新加入的团队成员快速理解上下文。