企业官网建设流程全解析

1. 问题现象：Token 用量失控的典型表现

先说结论：Openlaw 网关的 Token 激增不是某一处代码写错了那么简单，它通常是链路中多个环节共同作用的结果。最近我在排查一个实际项目时，发现网关层单日 Token 消耗量从日常的 800 万左右直接飙到 5000 万以上，账单数字看着都心疼。更麻烦的是，这种激增不是一次性的，而是每隔几天就来一轮，完全摸不到规律。后来把日志、计费数据、调用链路全部拉出来对齐，才发现问题远比“某个循环调用了太多次大模型”要复杂得多。

你如果也遇到类似情况，可以先对照一下有没有这几个典型症状：

• 账单显示 Token 消耗量级与业务调用次数不匹配，比如调用次数只涨了 20%，Token 消耗却翻了三倍。
• 个别请求的 Token 消耗异常大，单次请求甚至顶得上平时几十次的消耗。
• 网关内置的限流、配额预警规则频繁触发，但你并没有主动调整过阈值。
• 下游大模型服务返回的 Token 使用量（usage 字段）与网关记录的对不上，或者上游框架统计与下游模型计费端对不上。

这些症状单独出现任何一个，都还算是正常波动。但几个同时出现，基本可以断定网关层已经失去了对 Token 消耗的可见性和控制力。换句话说，你已经不知道每一笔 Token 花在哪儿了，而这恰恰是成本失控的开始。

这里要特别说明一下“网关”在 AI 应用架构里的角色。传统网关管的是流量、鉴权、路由、限流，但在接入了大模型能力之后，网关还多了一个身份：Token 的“计量表”和“阀门”。每次对话请求进来，网关负责把请求转发给大模型服务，模型处理完后返回结果，同时返回这次调用消耗了多少 Token。如果网关层不记录、不聚合、不控制这个数字，那整个系统的成本就是一笔糊涂账。

我在实际项目里遇到过一个更隐蔽的情况：会话上下文管理器会自动把历史消息全部带上，但某一轮对话里用户上传了一个超长文档，前端做了切片处理后推送给了会话接口。结果这轮调用直接吃掉了将近 10 万 Token，而网关完全不知情。后续所有对话都会带着这段文档的上下文继续累积，一直到上下文窗口溢出或账单爆炸才被注意到。这就是典型的“Token 激增”场景。

2. 为什么 Token 消耗会突然激增

把问题拆开看，Token 激增从来都不是某一刻突然发生的，它一定有一个积累的过程。区别只在于你是否及时发现了它。以我排查过的项目为例，Token 激增的原因基本可以归为四大类：上下文无限膨胀、工具调用结果回流、系统提示词被重复注入、以及重试机制把成本放大。

2.1 上下文无限膨胀是最大的隐性杀手

大多数 AI 网关在设计时都会内置一个会话上下文管理器，它负责把多轮对话的历史消息拼装起来一并发送给大模型。这个机制本身没问题，问题出在“全量累积”的策略上。很多团队的初版实现都是：用户每问一句，就把从第一条到当前这一条的所有消息全部打包，然后加上系统提示词一起发给模型。

假设每轮对话平均消耗 800 Token，聊到第 10 轮时，单次请求携带的历史上下文就接近 8000 Token。聊到第 50 轮时，单次请求要携带 4 万 Token 左右。这里还没算上用户偶尔粘贴的长文本、文件内容摘要、工具返回的查询结果。一旦这些内容混入上下文，Token 基数是直线上升的。

我见过一个比较极端的情况：某同事在调试接口时直接用测试脚本连续发了 200 轮相同的请求，每轮都携带全量历史。结果等到发现的时候，单次请求的上下文已经超过 20 万 Token，而下游模型当时的上下文窗口上限也就是 32K。后续所有请求都因为超出窗口限制而报错，但 Token 账单依然在累积。

2.2 工具调用结果回流导致的“连锁膨胀”

Openlaw 这类网关通常还承担着工具/插件调用的编排职责。比如用户问一个法律条文问题，网关先调用检索服务把相关法条拉回来，然后把这些法条塞进上下文再发给大模型做生成。

工具返回的结果往往是很“胖”的。一次数据库查询可能返回上百条记录，每条记录几百个字；一次网页抓取可能返回好几万字符的正文。网关在把这些内容塞进上下文时，如果没有做截断、摘要或结构化压缩，那这部分 Token 消耗会非常惊人。而且它还会随着多轮对话继续累积——第一轮拉回来的法条，第二轮聊到别的话题时依然在上下文里占着位置。

更要命的是循环调用。某些逻辑设计里，大模型为了回答问题会连续触发多次工具调用，每次调用返回的结果都追加到上下文，模型基于新结果再决定下一次调用。这个过程如果缺乏熔断机制，模型可能陷入“调用—看结果—再调用—再看结果”的循环，一次用户提问能引出几十次工具调用，Token 消耗自然爆炸。

2.3 系统提示词被反复注入，看似不起眼实则积少成多

系统提示词是很多团队容易忽略的隐形消耗点。初版可能只有几百 Token，但随着功能迭代，提示词里逐渐加入了角色设定、输出格式要求、few-shot 示例、安全约束、动态规则……最终轻松超过 2000 Token。

问题在于，这 2000 Token 是每轮请求都要带着的。如果日均调用量是 10 万次，光是系统提示词一天就要消耗 2 亿 Token。这就是为什么有些团队明明感觉调用次数没怎么涨，Token 账单却居高不下。

更隐蔽的是动态提示词注入。有些网关会在请求处理链路中根据用户画像、会话状态、业务类型动态拼接额外的指令片段，而这些片段也会进入每次请求。如果没有统一的提示词版本管理和增量统计，这部分消耗基本处于“失控”状态。

2.4 请求重试机制把成本放大数倍

网关层通常都会配置重试策略：当下游服务返回超时、限流或 5xx 错误时，自动重试同一请求。这个机制本身没有错，但很多团队在配置重试时忽略了一个事实：大模型调用是计费的，重试意味着同一笔逻辑消耗要重新付一次钱。

如果你配置的重试次数是 3 次，而下游服务因为瞬时过载连续超时，那一次用户请求的实际 Token 消耗就是正常情况的 3 倍甚至更多。在某些极端场景下，重试风暴甚至会把系统拖进雪崩状态：重试越多，下游压力越大，超时越多，重试就更多。

所以，网关层的重试策略必须与成本控制联动。重试前要确认上游请求是幂等的，重试次数要控制到最低必要值，重试退避策略要设置合理的递增间隔，同时还要对单请求最多消耗 Token 设置硬性上限。

3. 网关层 Token 成本治理的四个优化方向

搞清楚了原因，接下来就是怎么治理。我整理了几个经过验证的优化方向，均已在生产环境跑通过。这些方向的核心思路其实就一句话：让 Token 消耗变得可视、可控、可优化。

3.1 方向一：建立精细化的 Token 计量与用量统计

如果连用量数据都没有，优化就无从谈起。所以第一步一定是在网关层建立完整的 Token 计量体系。

具体来说，网关需要从下游模型服务的返回结果中提取 usage 字段——它通常包含 prompt_tokens、completion_tokens、total_tokens——并且按维度做聚合统计。至少要覆盖以下维度：用户维度、会话维度、请求路径/接口维度、模型维度、时间维度。这样当你看到 Token 账单异常时，能第一时间定位到是哪个用户、哪个会话、哪个接口、哪个模型产生的。

我实际项目中用到的统计方案是：在网关的响应拦截器里读取 usage 数据，然后异步写入时序数据库，配合一个简单的聚合任务按小时粒度更新各维度用量。这套方案不需要复杂的实时计算引擎，也足够支撑到千万级日调用量的分析需求。

除了统计，还要做超额预警。设定分级阈值：日用量达到总额度的 60% 时告警到负责人，达到 80% 时通知整个研发群，达到 100% 时自动触发限流或降级策略。阈值最好做成可配置的，不同业务线可以参考不同的告警水位。

3.2 方向二：采取直接有效的 Token 削减技术

统计和告警只是前提，真正把成本降下来还是要靠技术手段。这里分享几种在网关层可直接落地的削减方案。

上下文窗口滑动与消息裁剪：不再把全量历史发给模型，而是按时间或轮次做滑动窗口。比如只保留最近 10 轮对话，或者按 Token 数裁剪到最多保留 6000 Token 的历史上下文。结合消息重要性做取舍——系统消息和最近几轮用户消息优先保留，中间过程性消息可以合并或丢弃。

历史消息摘要：当会话轮次很多、上下文快接近上限时，先调用一次小模型把早期对话压缩成摘要，后续请求只携带摘要加最近几轮完整消息。这种做法会牺牲一些信息密度，但能大幅降低 Token 消耗。我测试过一个典型的客服场景，用摘要方案后上下文 Token 直接削减了 70% 以上，回答质量几乎没有明显变化。

工具返回结果截断与压缩：对工具返回的内容做 Token 预算控制。比如设置单次工具调用结果最多占用 800 Token，超出部分按“开头保持 + 结尾保持 + 中间截断”的策略裁剪，或者直接让大模型对原始结果做摘要后再进入上下文。对结构化数据（JSON、表格），可以压缩成 key-value 的紧凑格式——省去的空格、缩进、引号加起来的 Token 总量非常可观。

系统提示词瘦身：定期审计系统提示词，删除冗余表述和无用的 few-shot 示例。把动态拼接的指令改为静态模板+少量占位符，避免每个请求都带着大段重复文本。这一步虽然“技术含量”不高，但通常是性价比最高的优化手段。

3.3 方向三：在协议层做请求级别控制

削减小技巧是治标，协议层的控制才是治本。网关需要在请求进站时和出站前做两道检查。

进站时检查：根据会话历史 Token 消耗和当前请求的预估 Token 消耗，判断是否超出配额。如果超出，直接返回 429 或自定义错误码，让客户端降级处理。预估 Token 的方法不要求精确，粗估即可——中文字符按 1 个汉字约等于 1.5 到 2 个 Token 估算，英文字符按 1 个单词约等于 1.3 个 Token 估算。误差在 20% 以内都不会影响配额控制效果。

出站前检查：在请求发给下游模型前，对拼装好的完整请求体做 Token 计数。如果超出模型上下文窗口或超出该用户/会话的剩余配额，则拒绝发送或做自动降级——比如改用更小的模型、切到更便宜的模型版本、或者直接返回缓存结果。

这套双检查机制能兜住大多数异常场景。比如前文提到的那位连续发 200 轮请求的同事，如果是先经过进站检查，在第 N 轮超出会话配额时就会被拦下，根本走不到下游。

3.4 方向四：架构层面做多级缓存与请求合并

最后是架构层面的优化，思路是减少对大模型的真实调用次数。

多级缓存包括：结果缓存、语义缓存、部分推理缓存。结果缓存最简单，KV 形式直接存用户问题与模型回答的映射，命中即直接返回；语义缓存稍微复杂些，需要把用户问题做向量化后与历史问题做相似度匹配，相似度超过阈值的直接复用历史回答（可以搭配“这个问题的答案由缓存提供”的提示标识）。

请求合并则适用于对实时性要求不高的场景。比如多个用户在同一时段问了极其相似的问题，网关可以把它们合并为一次模型调用，拿到结果后分别返回给所有用户。这个方案实现复杂度较高，但效果非常显著，尤其适合高频问答类的业务场景。

另外还有一条思路是模型分级。把简单的意图识别、文本分类、格式转换放到小参数模型上，只有复杂推理、长文本生成才调用大模型。小模型的单 Token 成本通常只有大模型的几十分之一。通过网关按请求复杂度自动路由模型，整体成本能下降一个数量级。这条路线值得深入研究。

4. 实操落地：从排查到优化的完整路径

理论和方向都有了，具体怎么落地才是关键。下面我把实际项目里从发现异常到完成优化的完整操作流程拆开讲。

4.1 第一步：锁定激增发生的精确时刻

排查问题之前，先把“激增”的定义量化。不是单看某一天的总额高了，而是要看小时级别的数据曲线。方法很简单：从网关日志里把每日请求量和每日 Token 消耗按小时拉出来做对比，找出两者的背离点。

我遇到的那个项目，请求量曲线一直是平稳的，但 Token 消耗曲线在凌晨 2 点到 4 点之间出现了陡峭的尖峰。后来查日志发现是某个离线任务在批量调用网关接口，且没有做任何限速。单线程跑还好，但这个任务开了 50 个并发，每个请求都携带完整的对话历史，结果 2 小时就烧掉了平时 5 天的 Token 量，成本自然就爆了。

4.2 第二步：确定最大消耗来源

锁定了时间段，接着要看具体是哪类请求在消耗 Token。我用的是“抽出 Top 100 高消耗请求”的办法：在网关日志里记录每个请求的 total_tokens，按降序排列，查看前 100 条请求的特点。

结果发现高消耗请求集中在两类场景，一类是携带了超长上下文的会话续接请求，另一类是工具调用繁多的复合请求。前者单次请求普遍在 2 万 Token 以上，后者虽然没有那么夸张，但调用频次很高，累计消耗也非常可观。据此我就能确定优化优先级——先解决“超长上下文”这个大头。

4.3 第三步：实施上下文优化组合方案

优先级排定后，我落地了两个核心优化：

第一个是给会话上下文管理器加上了 Token 预算机制。每个会话预设 8000 Token 的上下文预算，超出后触发“摘要+裁剪”逻辑。具体实现是：把前几轮对话发给一个小模型，让它生成一段不超过 300 Token 的总结，之后的所有请求都携带这段总结代替早期原始消息。

第二个是给工具调用结果加上了截断逻辑。在工具返回进入上下文之前，做一个预算检查；超过 1500 Token 的结果，截断到 500 Token 并补一句提示：“以下内容因长度限制做了截断，如需完整数据请联系技术支持。”这一步对回答质量的影响很小，因为大模型即使看到全量数据，真正用到的也只是关键字段。

4.4 第四步：设置配额与告警联动

优化做完之后，还要防止下一次激增。我在网关里追加了两个配置项：用户级日配额与会话级单请求配额。默认值是日配额 100 万 Token，单请求配额 3 万 Token，超出拒绝并返回明确错误码。同时接入了内部告警平台，用量达到阈值的 70% 和 90% 时分别发出预警。

这里给一个实测数据作为参考：优化前日均消耗约 1200 万 Token，优化后稳定在日均 350 万 Token 左右，降幅超过 70%。整个优化周期只花了两周，一次上线完成。

4.5 第五步：建立成本运营常态机制

优化上线不是终点，Token 成本治理应该是一个持续运营的过程。我的建议是每两周固定做一次 Token 消耗复盘，拉出本周 Top 消耗来源、环比变化、异常波动时间点，逐项审视是否有优化空间。

同时，把 Token 成本纳入网关的版本发布评审。任何修改了提示词、会话策略、工具调用逻辑的变更，都要附带 Token 影响评估，避免优化上线后又因为一个小改动把成本打回原形。

5. 常见问题与避坑实录

这节集中回答我收到的共性问题，以及我在实际踩坑后总结的经验。

5.1 为什么 OpenAI 的 usage 数据和网关统计的数据对不上

这是最容易让人困惑的问题。如果你发现网关记录的总 Token 数和模型服务账单对不上，大概率是统计口径不一致。比如有些推理框架把输入输出分开计费，有些把历史上下文单独计费，还有些缓存命中的 Token 不体现在 usage 中。建议统一以模型服务返回的 usage 字段为准，并在网关层做一次手工校验：对比网关统计总量和平台账单总量，误差控制在一定范围内可接受。

5.2 重试机制导致 Token 代码双倍扣费怎么办

重试导致的双倍扣费，可以从两个层面解决。第一，把重试开关默认设为关闭，只在幂等接口上显式开启；第二，在重试请求中打上“重试”标记，网关记录消耗时单独归类，月末账单核对时可以直接看到重试产生的额外消耗。

5.3 提示词瘦身会不会影响模型回答质量

会有影响，但通常是可以接受的。关键是要做 A/B 测试：同一批测试集分别用原提示词和瘦身后的提示词跑一遍，对比回答的准确率和用户满意度。只要指标稳定在一个可接受区间，瘦身就可以上线。个人经验是，提示词的语气词、重复强调、过度冗余的格式说明是最值得删的部分，影响最小，收益最大。

5.4 网关只做简单透传，Token 统计能放到业务侧吗

可以，但不推荐。真实环境里业务侧会很多很杂，你很难保证每个服务都统一实现了 Token 统计逻辑。放在网关层的好处是只做一遍，所有流量都经过它，统计维度自然统一。前期投入不算大，但后期的运维收益非常明显。

5.5 一些容易被忽略的隐性消耗

最后提醒几个大家容易忽略的消耗点：

• 心跳检测请求：有些客户端实现每隔几秒发一个空请求保活，如果网关把这些请求也转发给大模型了，成本就白白流失了。建议对这类请求直接返回空响应，不进入模型调用链路。
• 联调环境与生产环境共用网关：联调时打印日志、重复请求、模拟数据都会真实消耗 Token。建议用独立的沙箱网关，或者给联调请求打上特殊标记并限制用量。
• 日志打印完整请求和响应体：如果在日志中打印完整的大模型请求/响应报文，日志存储成本先不说，单是日志系统对字符串的处理开销就能让网关吞吐量明显下降。建议只打印 usage 元数据和请求摘要。

以上方案都是我在实际生产中验证过的，项目不同、业务不同，具体的参数阈值和裁剪策略需要你根据实际情况调整。但核心思路是通用的：让 Token 消耗变得可视化、可控制，再通过持续优化把它降下来。