多Agent架构实战：给GPT-6配AI团队，Token消耗直降七成

上个月底我盯着后台的 Token 用量曲线半天没说话。GPT-6 ultra 确实强强到我把所有任务都往里塞塞到月度消耗直接爆表还没算并发重试和上下文反复计费。后来我意识到问题不是这个模型太烧钱而是我让一个顶级专家把前台、资料员、校对、秘书的活全包了按专家时薪付所有人的工资。于是我用两周时间给它配了一个 AI 团队——前台分诊、资料整理、审核校对、记忆管家各司其职只有真正需要顶级推理的活才交到它手里。整套架构跑下来Token 消耗降了六到七成输出质量不降反稳。这篇就把这套配团队的打法完整拆给你适合被长上下文账单吓到的人、跑批量任务的开发者、以及所有想在多 Agent 架构里控制预算的团队。1. 先算一笔账GPT-6 ultra 的烧钱逻辑到底在哪1.1 一次让我肉疼的文档重构起因是一个老项目的重构。我把十几个源码文件整包丢给 GPT-6 ultra让它输出模块拆分方案。单次调用光是输入上下文就接近 4 万 Token输出只有一千多 Token成本大头几乎全压在输入上。更难受的是我在追问第二版方案的时候整包文件又完整计费了一次——模型并没有缓存上一轮的阅读结果。这个场景太典型了。大部分人在用旗舰模型时有个习惯把原始材料一股脑倒进去让模型通读全文。对模型来说这确实能提升回答质量但对账单来说是灾难。大模型计费是输入加输出双向计费长上下文场景下输入占绝对大头而输入里的绝大多数内容模型读完也就用到了几句话。我自己做过统计一周之内所有直接丢给旗舰模型的请求真正被模型有效利用的输入 Token 大概只有三成。剩下七成是背景铺垫、重复文件、日志片段、来回修改时重发的旧消息。说白了你一直在用专家号挂普通号专家却把时间花在读化验单而不是诊断上。1.2 为什么长上下文的成本会超线性地涨很多人的直觉是上下文长一倍价格贵一倍但实际不是。Transformer 的注意力机制里每个 Token 都要跟上下文里的所有 Token 做一次关系计算上下文窗口翻倍计算量和显存占用增长远不止翻倍。服务商为了支撑超长上下文还需要为每个请求预留更大的 KV Cache 资源这部分成本自然转嫁到调用价格上。更深一层的问题是长上下文会放大重试成本。一次 4 万 Token 的请求因为输出 JSON 格式崩了要重来第二次又得完整付一遍 4 万 Token 的输入费用。我在做 Agent 工具调用时经常遇到这种状况模型本身没答错但工具返回的字段格式不对于是整个请求重跑Token 双倍流失。所以结论很直接不是模型单价让你破产是让模型读太多它不该读的东西让你破产。与其想怎么砍单价不如先想怎么砍阅读量。1.3 裸用和配团队的成本对照我按一个月的实际负载算了笔账假设有 1000 个任务每个任务平均输入 12000 Token、输出 2000 Token。价格不需要精确到小数按照旗舰模型输入和输出约为入门模型几十倍的价差来估就够说明问题了。模式大模型调用次数大模型输入总量大模型输出总量小模型/工具开销相对总成本裸用 GPT-6 ultra1000 次1200 万 Token200 万 Token无基准 100%配 AI 团队200 次240 万 Token40 万 Token每次任务约 3000 Token 走廉价模型约 30%这个表里最关键的数字不是大模型调用降了 80%而是输入总量降了 80%。因为长上下文场景里输入是花钱大户砍输入比砍输出有效得多。实测下来我的整体成本不是降到 80%而是降到 30% 左右原因就是大部分任务压根没走到旗舰模型那一步。2. 所谓AI 团队本质是一套任务分层的路由架构2.1 别把 Agent 当噱头组织分工就是 Token 经济学很多人听到给大模型配团队觉得花哨但拆开看它就是一个公司最常见的运转方式。公司里最贵的专家不会自己收发快递、整理档案、检查错别字这些杂活由前台、助理、校对分担专家只做核心判断和最终拍板。套到 AI 系统上就是五类角色前台分诊员负责判断请求难度资料整理员负责压缩信息主力专家只做复杂推理审核校对负责格式和一致性检查记忆管家负责存历史摘要。每个角色背后可以是一个独立模型实例也可以是一段带工具调用的流程封装。重点是让信息按照难度分级流动而不是所有请求都涌向同一扇门。这套架构的第一价值是省钱第二价值是可观测。每一个环节消耗多少 Token、输出了什么全部有日志可查。裸用旗舰模型的时候你根本不知道钱花哪了配了团队之后每个角色的账单都摊在桌面上哪块浪费一眼就能看出来。2.2 先分诊再决策少付大量冤枉钱路由分诊是整个架构的核心。我把它做成一个独立的分类层先把请求分成四类简单查询、结构化生成、复杂推理、长文档处理。前两类走廉价快的模型第三类才升级给 GPT-6 ultra第四类先经资料整理员压缩再交给旗舰模型。这里有一个特别重要的工程细节分诊不能只看关键词要看置信度。如果路由模型对小模型能不能答好没有把握应该直接升级而不是硬答。我踩过的坑是刚开始把置信度阈值设得太高结果大量稍微沾点边的请求全涌向旗舰模型省了个寂寞后来把阈值调得太低小模型硬答胡话用户不满意又重跑大模型反而更费 Token。最终折中的方案是分级处理置信度低于 0.7 直接升级0.7 到 0.85 之间先让小模型出草稿再由旗舰模型做简短的修正性审阅0.85 以上完全交给小模型。这个参数没有绝对标准跟你的数据分布有关但思路是通用的——给每个档位都标好代价边界。2.3 路由模型也要选会思考的早期我做路由只用一个简单分类模型后来发现效果不好。原因很简单有些请求表面上像简单问题实际暗含多步推理。比如把这个函数改成异步并保证调用方不改动分类器可能打成代码生成但实际需要理解调用链属于复杂推理。后来我参考了 DeepSeek 公开的智能体训练新方法——用更细粒度的思维链数据去蒸馏轻量模型让它在做路由和工具调用之前先想一小步。这种做法让路由模型不再是一个僵硬的打标签机器而是会基于我能不能搞定来做决策决策准确率明显提升。工程上的选型建议是路由和分诊模型至少要具备基础的工具调用能力而不是纯文本分类。现在很多 API 通道都提供便宜的工具调用版模型你完全可以用同一个工具链去接不同模型。比如把 Codex 类的编程 Agent 接到千问这类支持 Token Plan 计费的 API 上工具链不用改底层推理通道换成性价比更高的模型跑批量的辅助编程任务非常划算。3. 我的手搓配置五个角色怎么搭、怎么调度3.1 角色卡和选型方向每个角色的模型选型不需要一步到位关键是明确它需要多强的智力、要付出多少 Token。我整理了一张配置表覆盖选型和定位角色核心职责模型选型方向Token 开销档位为什么不需要旗舰级前台分诊员意图分类、置信度判定、请求升级本地 7B/14B 或 API 廉价档要求有工具调用最低每次几百 Token不需要理解内容深度只需要判断要不要升级资料整理员长文档压缩、检索、信息抽取、生成摘要中等模型上下文窗口要够大低到中按文档长度它做的是浓缩和搬运不是创造主力专家复杂推理、终稿生成、争议处理GPT-6 ultra 这类旗舰高但只用在刀刃上它是唯一不能省的省了它整体质量会崩审核校对格式校验、JSON 合法性、事实一致性中等模型或规则脚本低只跑输出机械性检查用不上顶级推理记忆管家存储会话摘要、用户偏好、历史决策向量库加数据库不需要模型几乎为零它是存储系统不是生成系统这里我想强调一下资料整理员的设计。它的职责不是总结而是提炼出后续推理真正需要的材料包。比如代码重构场景里它要把十几个文件转成三类信息对外接口清单、关键函数依赖图、需要修改的代码段定位。旗舰模型拿到这份材料包就不用再通读全文直接基于结构化的依赖关系做方案设计。这一步把输入从几万 Token 压到几千质量反而更高因为模型不会被无关代码干扰。3.2 核心调度流程的伪代码整个团队的调度逻辑不复杂核心就三段分类、升级、交付。下面是我在项目里的简化实现def dispatch(request): # 第一层分诊 route, confidence classifier.analyze(request) # 第二层根据置信度决定走哪条通道 if confidence 0.85 and route in (simple, structured): return cheap_model.generate(request) if route complex: materials document_prep.pack(request) # 资料整理员压缩上下文 return gpt_ultra.generate(request, materialsmaterials) if confidence 0.7: draft cheap_model.generate(request) return gpt_ultra.review(request, draftdraft) # 旗舰做审阅修改 # 第三层拿不准就直接升级 materials document_prep.pack(request) return gpt_ultra.generate(request, materialsmaterials)所有中间产物必须走结构化 JSON 传递比如{type: material_pack, version: 1.2, files: [...], summary: ...}。这么做有两个好处一是下游模型不需要重新转述资料直接从字段里取省 Token二是出了问题能精准定位是哪个环节丢的信息。我见过很多团队在 Agent 里传纯文本字符串模型 A 的输出格式稍微变一变模型 B 就懵了最后只能靠重试兜底消耗全部白付。3.3 提示词设计只让大模型看必须看的配了团队之后GPT-6 ultra 看到的输入结构跟以前完全不同。我现在给它的每条请求最多包含三部分系统角色定义任务边界和输出格式用户消息放压缩后的材料包工作区放需要它直接操作的结构化数据。整包原始文档严格禁止直接传入所有背景材料必须先经过资料整理员。比如在编程辅助场景给 Codex 这类编程 Agent 的提示词不应该带整个仓库。正确的做法是先用工具抽取符号表、改动点、类图摘要组成一个轻量任务包。我在实践里用的模板大概是你是本次重构任务的评审专家。以下是本次任务的完整材料包请基于该材料包给出方案不要自行扩散范围。 【目标】将模块 A 的异步化改造扩展至全部调用方 【接口清单】{由资料整理员生成} 【依赖关系】{由资料整理员生成} 【约束条件】1. 不改变对外行为 2. 兼容旧配置项 【输出格式】改造步骤、风险点、验证清单三部分使用 Markdown这个模板的核心思路是用结构化约束代替全文阅读。你只需要在提示词里声明不要扩散范围模型就不会像以前那样把无关代码也纳入思考实际上也减少了它输出冗余内容的概率。上下文短了、任务边界清晰了输出质量反而稳定。4. 生产环境里最容易翻车的三件事上下文、配额、凭证4.1 上下文管理别让记忆把 Token 吃光多 Agent 跑起来之后最大的隐性消耗不在单次请求而在对话历史。如果每个 Agent 都把之前的完整对话带进下一轮上下文会指数膨胀。我采用的方案是滑动窗口加历史摘要每四轮对话就把前面的内容压缩成摘要存入记忆管家新请求只带摘要加最近两轮原始对话。这里有个容易翻车的细节摘要压缩一定会丢细节。模型在上一轮引用过的文件路径、关键数值、ID摘要里必须原样保留不能改成某个文件配置项二。我给记忆管家加了一层强制保留规则——凡是模型回答里出现过的路径、数字、标识符压缩时必须原样放进摘要字段。没有这条规则后来审核逻辑会莫名出错查半天才发现是摘要把关键 ID 模糊化了。工具调用的记录也要单独管理。Agent 调用工具时工具返回的长文本不应该一直留在上下文里。我的做法是工具结果只保留最近三条更早的调用记录转成一行摘要存到向量库。对模型来说它不需要记得上次搜索的完整结果只需要知道上次已经搜过这个关键词结论是 X这就足够支撑连贯性了。4.2 配额与限流没有预算的 Agent 会失控给每个 Agent 设独立配额是血的教训。我遇到过子 Agent 在死循环里反复请求外部接口几分钟内把当日预算打光的状况。它本身没有恶意只是路由逻辑里工具调用失败就重试写得比较激进失败一次重试一次每次重试都要重新调用主模型Token 就飞速消失了。现在的做法是三段式限制每个角色单独设单请求 Token 上限避免一次请求把预算吃穿每个角色设每分钟请求数上限控制并发全局设日熔断线达到预警线自动降级——把所有流量切到廉价模型人工介入后再恢复。roles: classifier: budget_per_request: 800 rps_limit: 10 document_prep: budget_per_request: 4000 rps_limit: 5 gpt_ultra: budget_per_request: 16000 daily_cap: 400000 fallback_mode: when_daily_cap_reached: route_to_cheap_models这套配置还能帮你做成本审计。每个角色每天花了多少、集中在哪个时段、哪些请求类型在消耗预算全都有记录。裸用时代你只能看着总账单后悔配了团队之后你能精确到昨天资料整理员在压缩一份 3 万行的日志文件上花了 8000 Token而这份文件最后只用到了其中两行——这种浪费马上能纠正。4.3 凭证集中管理Token 失效为什么会拖垮整个任务队列多 Agent 系统里还有一个被低估的坑外部服务的登录态和 API 凭证失效。很多人在本地跑 Agent 时把 key 直接写在配置里觉得能用就行。但放到生产环境只要有一个 Agent 的凭证过期错误信息就会变成一串让人摸不着头脑的报错sign-in could not be completed、token exchange failed、token endpoint returned 403 forbidden。这类报错本质上不是模型能力问题而是认证链路断了。排查链路通常是登录态过期API 网关拒绝请求Agent 收到 403 后重试重试触发频率限制然后整个任务队列开始连锁失败。如果你在每个 Agent 里手动塞 key还得逐个排查到底是谁的凭证先过期非常被动。我的方案是做一个集中的凭证服务所有 Agent 启动时从凭证服务拉取 access token不在本地代码里落任何密钥。凭证服务负责管理刷新逻辑——access token 时效短刷新 token 时效长用定时任务提前续签避免在请求高峰期集中过期。所有对外请求统一走重试组件重试采用退避加抖动策略防止多个 Agent 同时重试把网关打死。这里点一下 JWT 续签的通用机制只要你的认证体系用的是 JWT就需要把刷新和重试做成两个独立环节刷新逻辑与具体业务解耦。刷新失败的告警也要单独拉出来不要混在普通业务日志里。一次刷新失败会拖垮一整批任务它不是普通故障是全局故障。4.4 两种极端省钱路线本地小模型和 Token Plan如果预算压力还是大还有两条路可以进一步压缩成本。第一条是本地部署轻量模型做高频低难度任务。社区里已经有人在 6GB 显存的环境里用 bonsai27b 加 ninfer 推理引擎跑起闪电侠方案本地跑模型 Token 不花钱输出速度还很快。我把前台分诊员和资料整理员的一部分高频任务迁到本地之后API 账单又降了一截。第二条是订阅制的 Token Plan。对于编程辅助这种有固定工作量的场景把 Codex 这类编程 Agent 接到千问的 Token Plan API 上用固定订阅额度换批量用量比按次计费稳定得多。你就把它理解成包月流量包和按流量计费的区别跑量大、频率高、单次消耗可控的任务包月必然更划算。实测下来只要一个月的调用次数超过一定阈值Token Plan 的边际成本优势就很明显。不过要提醒一句本地部署不是没有代价。它需要你花时间维护推理服务小模型的输出质量也明显弱于旗舰。我的建议是能用规则、Medium 模型解决的就别上大模型能本地跑的就别走 API只有真正需要顶级理解力的推理才值得花旗舰价格。5. 实测两周数据对比和踩坑清单5.1 三个真实任务的 Token 消耗对比我把这套架构放到真实工作流里跑了两周挑三个有代表性的任务做了对比。周报生成是典型的高频低难度任务代码重构是中频高难度长文档问答则是长上下文消耗的大户。任务类型裸用输入消耗配团队后输入消耗输出消耗对比主观质量评价周报生成100 次120 万 Token30 万 Token基本持平更稳定格式不跑偏代码重构方案20 次80 万 Token28 万 Token略降质量持平关键依赖反而更清晰长文档问答30 次150 万 Token40 万 Token略降更稳关键数字没丢过长文档问答是收益最大的场景。以前让 GPT-6 ultra 直接读完整份合同再回答每次输入都上万现在资料整理员先把合同里的条款、金额、日期、义务边界抽成结构化材料包旗舰模型只需要基于材料包做判断。回答的准确率没有下降反而因为不被无关段落干扰关键条款的把握更准了。5.2 踩坑清单那些文档里不会写的教训第一坑是置信度阈值。我一开始设 0.9结果大量边界请求全涌向旗舰模型只省了两成后来改 0.6小模型开始乱答用户跑回来重问反而更费。最后的 0.75 也不是一次调出来的是跑了三天数据后根据路由准确率曲线定的。建议你把每一次路由结果都打日志跑一周再回头调参别拍脑袋。第二坑是中间产物的格式漂移。模型偶尔会在输出的 JSON 前后加 Markdown 代码块标记导致下游解析失败。我加了两道防线解析时先剥离代码块标记再加 JSON Schema 校验校验不过就走一次单步重试。这里别省重试的钱格式问题重试一次就能解决比让它带错跑完全程划算。第三坑是并发限流。多 Agent 并行调用同一个 API 时经常触发供应商的频率限制。我给每个角色加了令牌桶限制同时进行的请求数另外把全局并发上限设成 API 限流阈值的 70%留出缓冲。否则一旦触发限流重试风暴会让情况更糟。第四坑是缓存过度激进。有一版我把所有历史对话都压成摘要结果模型在回答里引用过的具体路径被压缩成了某个路径导致审核环节逻辑对不上。之后我加了强制保留规则凡是引用过的具体标识符一律原样保留宁可多花几百 Token 也不丢关键信息。5.3 什么场景不适合这套玩法配团队不是万灵药有些场景强行套这套架构反而亏 Token。一类是一次性简单问答——用户就问一句现在几点你让分诊、路由、审核全跑一遍三份 Token 全花了直接问旗舰模型反而便宜。第二类是延迟极度敏感的交互场景路由和并行处理增加的延迟不可忽略实时对话里体验会打折扣。第三类是创意写作比如让大模型写一篇风格化小说压缩上下文会砍掉风格细节这时候你需要的恰恰是全文阅读的能力省 Token 没有意义。判断标准其实就一条任务里有多少信息是必须完整保留的。必须完整保留的就别压缩可以结构化的才值得走团队分工。想清楚这条边界这套架构才不会变成为了省钱而省钱的过度设计。我在实际跑这套系统的时候最大的感受不是钱省了多少而是重新拿回了对 Token 的掌控感。以前每个月底看账单像开盲盒现在每个角色花在哪、该不该花全都有日志可查。一个小技巧分享给你把所有 Agent 的输入输出打上日志每周花十分钟扫一遍你会惊讶地发现有大量 Token 在做无效加班——某些资料整理员在压缩根本用不到的日志某些路由规则把本该升级的请求压在了小模型上。这些浪费不看日志你永远发现不了看了之后每一轮优化都是实打实的省钱。