智能体开发中的token消耗控制与工程化实践

把 2026 年称为智能体元年现在看并不夸张。真正先被感知到的不是智能体有多聪明而是它的 token 消耗比想象中快很多。这个话题里最常被引用的一个判断是智能体完成任务的 token 消耗可能是人类直接写一段文字的 5 倍以上。实际做项目之后你会发现这不是用来吓人的营销数字而是在提醒你重新做预算、做监控、做上下文控制。下面围绕智能体开发中的 token 问题从消耗构成、框架选型、工程配置到常见报错整理一套可以直接用的经验。1. 智能体元年为什么先卡在 token 上1.1 智能体从“问答”变成了“多轮任务执行”普通聊天气模是单轮问答用户提出问题模型直接生成回答。整个过程通常只发生一次接口调用token 花费相对可控。智能体不一样。它把用户给的目标拆成多个步骤每一步都可能调用模型。比如让智能体查天气并安排日程至少要经历解析用户请求、决定调用哪个工具、把天气接口返回值交给模型判断、处理冲突、选出备选时间、生成最终结果。每一步都可能产生新的模型请求每一次请求都在计费。这也是为什么智能体项目的成本模型不能套用“一次问答多少钱”的思路。你更应该把它理解成“一个任务跑了多少次模型调用每次调用带了多少输入产出了多少输出”。我一般会在设计阶段先画一条主链路数一遍模型调用次数。如果一条普通任务动不动就触发 8 到 10 次模型调用那再便宜的模型也扛不住长期批量跑。1.2 “消耗超人类 5 倍”的本质是上下文放大效应很多人对“5 倍”这个数字有误解以为是在拿智能体和人的打字速度比。其实真正的原因是上下文放大效应。人类写一段话只需要考虑自己的表达。智能体执行任务时每次调模型都要把下面这些内容作为输入送进去系统提示词和角色设定已经发生过的历史消息可用工具列表和工具描述工具返回的结果前几步生成的内容这几个部分放在单轮里不算重但智能体是多轮循环。系统提示词每一轮都会重新计费工具列表每一轮都会重新计费历史消息还在不断增长。到了最后一轮模型看到的是整条链路叠加之后的上下文。所以 5 倍这个说法并不夸张。如果任务复杂、工具多、历史消息不裁剪真实消耗可能远不止 5 倍。实际倍数受三种因素影响模型本身对中文和 JSON 的编码效率智能体框架是否做了上下文裁剪任务到底要循环多少轮才能结束做预算的时候不要用一个固定倍数去乘。更好的做法是拿自己的任务跑一次把每一轮调用的 token 都打出来再算平均成本。2. token 到底花在哪四类消耗要分开算2.1 输入侧上下文重复和工具描述是大头模型计费通常分成输入 token 和输出 token。很多新手只盯输出觉得生成结果越长越贵。但在智能体场景里输入 token 往往才是成本大头。输入 token 主要有四个来源消耗位置计入方式常见坑系统提示词每轮模型请求都会包含写得越长每轮都重复计费不是只算一次工具定义模型需要知道有哪些工具可用工具越多、描述越长每次请求都增加历史消息随对话轮次增长不裁剪的话上下文越来越长成本不是线性增长工具返回结果工具执行结果拼进对话大段 JSON 直接放进去是隐藏的成本点这里要注意token 不是字符数而是模型编码后的单元。中文可能一个字对应多个 tokenJSON 里的键名也会占用。不要用“大概几百字”去估要用工具或接口返回的实际数值。工具返回是最容易失控的地方。比如查用户信息接口返回了一个 2000 字段的 JSON实际模型只需要 name、email、status 三个字段。直接把整个 JSON 丢进去每轮都要多花一大截 token。2.2 输出侧多轮、重试和多智能体协作输出 token 也不只是最终答案。智能体每产生一次推理、每写一个中间计划、每生成一次工具调用的参数都可能产生输出。如果模型还返回 reasoning_content 这类过程内容这些同样可能计入输出 token。更隐蔽的是重试。智能体执行任务时如果工具调用参数格式错误或者模型生成内容不符合预期框架往往会自动重试。重试一次等于把新的请求和历史错误再次送入模型。相当于同一个步骤烧了两次甚至三次 token。多智能体场景更明显。两个智能体相互协作时A 给 B 的消息是 B 的输入B 返回的结果又是 A 的下一轮输入。角色越多消息在多个上下文之间复制次数越多。所以优化 token 不能只看单次请求要看整条链路的累计调用量。3. 框架选型和提示词优化先压输入再谈并发3.1 低代码平台Dify、Coze 适合快速验证但要检查上下文组装Dify、Coze 这类平台可以快速搭建智能体流程适合先验证业务能不能跑通。但需要注意低代码不代表不需要关心 token。这类平台一般会提供调试面板能看到一次运行的完整 prompt。很多人跳过了这一步直接开始调模型参数。我更建议先展开一次调试记录重点看三件事system prompt 每一轮是否都重复出现历史消息是否被完整保留工具返回结果是否被原样塞进上下文有些平台默认会把会话历史全部传给模型看起来方便实际上会话拉长后 token 消耗会快速增长。如果只是学习或者做原型可以不管如果准备长期使用就要考虑是否开启上下文裁剪或会话摘要。模型选择也一样。很多验证项目会接 DeepSeek 这类性价比比较高的模型跑流程成本压力小一些但 token 消耗结构不会变。后续换更强模型时还是要重新测一次消耗。3.2 自研框架上下文裁剪、缓存、工具返回精简如果团队选择自研智能体框架第一优先级不是把架构做得复杂而是把每次模型调用的输入控制住。最简单的做法是在构造请求前用 tokenizer 估算一下输入长度。OpenAI 生态里可以借助 tiktoken 做估算但要注意不同模型的编码方式不完全一样。# 示例用 tiktoken 估算一段文本的 token 数 # 不同模型可能有不同编码表这里只用于估算 import tiktoken enc tiktoken.get_encoding(cl100k_base) prompt 这是系统提示词和工具返回内容拼接后的文本 print(len(enc.encode(prompt)))这种估算只是为了提前发现异常不能当作精确计费依据。真正确认消耗要看接口返回的 usage 字段。自研框架里最值得做的三件事历史消息裁剪只保留最近的几条消息更早的内容用摘要替代。工具返回精简只保留模型判断需要的字段不完整的 JSON 直接过滤。结果缓存对相同或高度相似的任务做语义缓存命中后直接返回不重复调用模型。这套逻辑听起来简单实际落地时最容易忽略的是摘要本身也在消耗 token。如果对话已经 200 轮每次做摘要都要把整段历史送入模型也是一笔不小的开销。所以裁剪策略要提前规定触发条件比如超过多少条消息之后才启用摘要。4. 工程侧的 token 管理模型计费与访问凭证要一起设计4.1 模型 token 预算单任务上限 每日配额 告警智能体项目里比“一次任务消耗多少 token”更需要关注的是失控风险。一旦智能体进入死循环或者工具返回异常触发无限重试预算可能在一个晚上就被打穿。我在工程侧一般会准备四层控制控制层作用建议策略max_iterations限制智能体最大循环轮数先设为 5 到 10根据任务复杂度调整max_output_tokens限制单次输出长度按结果需要设置不要直接拉满context_window_limit限制送入模型的上下文长度超限后裁剪历史或终止任务daily_token_budget控制整个应用每天的总消耗达到阈值后停止新任务或降级这些参数不是越大越好。max_iterations 给得太大确实能提高复杂任务完成率但也会放大失败成本。比较好的方式是先跑 20 条任务观察成功任务平均循环几次再留 30% 裕量作为上限。还要加告警。当单日 token 消耗到达预算的 70%、90% 时分别给出提醒。不要等到月底看账单智能体项目几天就能跑出明显差异。4.2 访问凭证 token 的过期、续期和报错边界智能体开发里token 这个词有两层含义。除了模型计费 token还有身份认证和接口访问凭证 token。两者经常被混在一起排查导致问题定位越来越偏。访问凭证 token常见的是 JWT。JWT access token 通常有过期时间过期后接口会返回 401。很多团队只处理了重新登录没有做静默续期用户使用体验很差。一个自然的做法是维护 refresh token在 access token 失效时自动换取新 token再重发原请求。流程示例 1. 请求返回 401错误码包含 token_expired 2. 判断 refresh token 是否仍然有效 3. 调用刷新接口换取新的 access token 4. 使用新 token 重发原请求设置最大重试次数 5. 刷新失败则清理登录状态跳转重新登录如果你遇到的是类似 sign-in could not be completed token exchange failed 的报错不要第一时间去改前端。它通常发生在 OAuth/SSO 的 token exchange 环节。先看服务端返回的完整 error code再检查 client_id、redirect_uri、scope、密钥配置和服务端时间。403 forbidden 也不一定是 token 写错更常见的是客户端配置和服务端策略不一致。把能看到的配置项逐个对一遍比反复换 token 更有效。4.3 把两种 token 的状态分开监控建议在日志和监控面板里把模型计费 token 和身份认证 token 分成两个维度。维度模型计费 token身份认证 token含义模型处理文本的计量单位客户端访问服务的凭证失败表现超出上下文长度、额度不足、费用超支401、403、token invalid、token expired排查方向提示词长度、历史消息、工具返回、循环次数过期时间、刷新机制、OAuth 配置、密钥同步监控指标单任务消耗、日消耗、任务平均成本过期频率、刷新失败率、登录失败率只监控一种 token 很容易漏问题。比如任务大量失败日志里全是 401业务却说模型费用没超。这时候你查看的是认证配置不是提示词优化。分开监控后判断成本会低很多。5. 常见报错与排查链路5.1 模型相关 token 报错先查什么如果你看到的报错是“maximum context length exceeded”或者“context length exceeded”通常表示提示词长度已经超过模型上限。排查顺序先看 usage 字段确认真实请求的 prompt_tokens 和 completion_tokens。再看是不是历史消息太长优先裁剪历史而不是急着降低输出长度。检查工具返回结果是否把大段 JSON 放进了上下文。最后才看系统提示词它虽然每轮重复但通常不是超限的主因。如果你看到的报错是“insufficient balance”或“out of quota”先确认账户余额、模型访问权限和当前 key 归属。很多团队同一个 key 被多个环境共用结果开发环境把生产环境额度跑完了。5.2 认证相关 token 报错先查什么认证相关报错一般集中在登录页或 API 入口。常见错误码包括 token invalid、token expired、token exchange failed 和 403 forbidden。排查顺序确认完整错误信息不要只看前半段。确认服务端时间和本地时间是否同步JWT 对时间偏移很敏感。确认 OAuth 配置包括 client_id、client_secret、redirect_uri 和 scope。确认服务端证书、密钥是否需要轮换。看刷新 token 的逻辑是否只处理 access token 过期而没有处理 refresh token 过期。如果错误出现“token endpoint returned status 403 forbidden”先重点查客户端应用是否被服务端允许以及 scope 是否覆盖本次请求所需权限。5.3 一套通用排查顺序不管是模型 token 还是认证 token我习惯用同一套顺序先复现用最小输入跑一次确认问题可稳定出现。再看完整报错很多框架只展示最后一行真正的 error code 在日志里。然后看输入检查是不是历史太长、工具返回太大、参数配置不对。再看环境时间同步、依赖版本、key 配置、网络权限。最后才改代码不要一开始就调 token 续期逻辑或模型参数。按这个顺序排查大部分问题都能定位到具体层而不是反复试。6. 落到自己的项目先跑最小任务再放大6.1 第一次测 token 消耗的正确姿势新建智能体项目后不要直接拿超长文档、超大任务去测。我的建议是先选一条能代表核心流程的任务预设连续跑 5 次每次记录同一组字段总轮数、输入 token、输出 token、工具调用次数、是否重试。这样做的原因是单次任务的结果波动很大。第一次成功不代表稳定第三次可能因为工具返回格式变化触发重试第五次可能因为历史消息累积导致上下文变长。只有连续跑几次才能看到真实分布。刚开始调参数时不要一上来就开最大并发。先让一个任务完整跑通确认输入、输出、日志都正常再逐步增加并发。并发上来之后如果 token 消耗异常问题往往不在模型本身而在任务队列、重试策略和上下文管理。6.2 生产化之前必须完成的 token 优化清单我整理了一份自己的检查清单项目上线前会逐项过一遍[ ] 系统提示词是否精简到必要信息是否每轮都重复[ ] 工具描述是否足够简短模型能否快速判断该用哪个工具[ ] 工具返回是否只保留必要字段原始 JSON 是否被精简[ ] 历史消息是否有裁剪或摘要策略触发条件是否明确[ ] 是否设置了单任务最大轮数防止死循环[ ] 是否设置了单日 token 预算和告警阈值[ ] 认证 token 是否实现了自动续期刷新失败是否有降级方案[ ] 日志是否能看到每次请求的 usage 明细和错误码[ ] 相似任务是否有缓存避免重复调用模型[ ] 是否在上线前用真实数据做了连续 20 次以上的试运行如果只是学习默认配置通常够用。如果要长期使用就要把日志、输出目录、任务队列和 token 预算提前整理好。踩过几次之后我发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。智能体元年的机会不在于又多了一个框架而在于谁能把上下文成本和工程边界管住。把 token 消耗拆开看把认证 token 和模型 token 分开监控先把单任务跑稳再谈批量、并发和更多智能体协作。这套思路放到 2026 年依然是最实际的做法。