企业官网建设流程全解析

1. 从一张失控的账单说起：为什么“省Token”这条路走不通了

去年下半年，我帮一家做智能客服的团队做成本复盘，看到他们某个月的模型调用账单时，第一反应是“这数字是不是多打了一位”。那个月他们刚上线了一个多轮对话 Agent，用户量涨了三倍，账单涨了将近七倍。团队的第一反应非常典型：开始省。砍上下文、压缩提示词、把复杂任务降级到小模型、限制单用户调用次数。折腾了一个月，账单确实降了，但用户投诉上来了——回答变笨了、任务做一半断了、体验断崖式下滑。

这件事让我彻底想明白一个道理：Token 成本问题的本质不是“花多了”，而是“没人管”。省，是在需求侧做减法，减到最后一定伤业务；管，是在供给侧做治理，让每一份算力花在刀刃上。这就是我后来一直在推的思路——企业不该只想着怎么省 Token，而应该自建一座属于自己的Token 工厂。

所谓 Token 工厂，不是让你去训练一个大模型，而是把 Token 当作一种内部生产资料来经营：谁在用、用在哪、用了多少、值不值、能不能复用、能不能调度到更便宜的产线上去。这套东西在圈子里有个越来越流行的叫法——TokenOps。它和 DevOps、FinOps 是一个逻辑：把一种稀缺资源的消耗变成可观测、可计量、可优化、可追责的工程体系。

这篇文章适合三类人看。第一类是正在被模型账单追着跑的技术负责人和架构师，你需要一套能落地的治理框架；第二类是正在做Agent 开发的工程师，你的每一个工具调用、每一轮反思循环都在烧 Token，你需要知道钱花在哪；第三类是做成本核算和预算管理的同学，你需要理解 Token 这种新型成本项的计量逻辑。我会从整体设计思路讲到核心实现细节，再到实操步骤和踩坑记录，尽量把“怎么建这座工厂”讲透。

先给一个全局认知：Token 工厂的核心不是省钱，是让成本变得可控、可解释、可优化。省钱只是它顺带产生的结果，而且往往是最不重要的那个结果。真正重要的是，当老板问你“这个月为什么花了这么多”时，你能拿出一张清清楚楚的账单，而不是一句“用户变多了”。

2. Token 工厂的整体设计与思路拆解

2.1 为什么是“工厂”而不是“账本”

很多人一听 Token 治理，第一反应是做个统计报表，把每个团队的用量记下来。这只是账本，不是工厂。账本解决的是“知道花了多少”，工厂解决的是“怎么花得更合理”。

我用一个制造业的类比来解释。一家工厂要管好成本，至少要做四件事：原料入库要计量（每个请求进来先算清楚大概要消耗多少）、产线要能切换（同一个零件，能用贵的精密机床做，也能用便宜的普通机床做，看精度要求）、废料要能回收（缓存命中、结果复用，就是 Token 世界的废料回收）、每个车间要独立核算（哪个部门用了多少，月底要能对账）。

对应到 Token 工厂，就是四个核心模块：计量层、路由层、缓存层、核算层。这四层缺一不可，而且顺序很重要——先有计量，才谈得上路由；先有路由，才谈得上优化；先有核算，才谈得上追责和激励。

我见过太多团队一上来就搞路由，结果因为没有计量数据，根本不知道路由策略有没有效果。也见过团队只做核算不做缓存，账是清楚了，但钱一分没少花。这四层是一个闭环，缺了任何一环，工厂都转不起来。

2.2 核心思路：把“模型调用”抽象成“产线调度”

传统做法里，代码是直接调用某个具体模型的。比如call_gpt4(prompt)，写死了就是 GPT-4。这种写法的问题在于，模型和业务逻辑耦合死了，想换个便宜模型得改代码、测试、上线，成本极高。

Token 工厂的核心设计思想，是在业务代码和模型之间加一层抽象。业务代码只说“我要完成一个什么任务、精度要求多高、能等多久”，由中间层决定用哪个模型、走哪条链路。这就是模型路由的本质。

我把它叫做“产线调度”，是因为它和工厂排产逻辑几乎一样。一个订单来了，调度系统看：这个订单精度要求高不高？交期紧不紧？当前哪条产线空闲？哪条产线成本低？综合判断后派单。模型路由也是这个逻辑：这个请求对质量要求高吗？延迟敏感吗？当前哪个模型的配额还有余量？哪个模型单位 Token 最便宜？

这个抽象带来的最大好处是成本优化不再需要改业务代码。你发现某个场景用便宜模型也能达到 95% 的效果，只需要改路由策略，不用动业务逻辑。这是 Token 工厂能持续运转的前提。

2.3 方案选型：自建、采购还是混合

这里必须说清楚一个现实问题：不是所有企业都需要从零自建。我见过一些团队，为了“自建 Token 工厂”这个名头，硬生生造了一套轮子，结果维护成本比省下来的钱还多。

我的建议是分层看。计量层和核算层建议自建，因为这两层强依赖你内部的账号体系、组织架构、业务标签，市面上的通用工具很难贴合。路由层和缓存层可以先用开源方案起步，比如一些网关类项目本身就带路由和缓存能力，先跑起来，等业务复杂了再逐步替换成自研。

判断标准很简单：如果市面上的方案能覆盖你 80% 的需求，就别自建那 20%。自建的价值在于贴合业务，不在于技术炫技。我见过一个团队自研了一套极其复杂的路由算法，结果业务方根本不会配置，最后所有人还是写死用同一个模型，这套系统等于白做。

2.4 关键指标：先定义什么叫“管好了”

建工厂之前，得先定义验收标准。我一般用四个指标衡量 Token 工厂的健康度：

这四个指标里，成本可归因率是最容易被忽视但最重要的。如果一笔钱花出去不知道是谁花的，那后面所有的优化都无从谈起。我建议一开始就把归因做到位，哪怕路由和缓存都还没做。

3. 核心细节解析与实操要点

3.1 计量层：把每一次调用都变成一条可追溯的记录

计量层是整个工厂的地基。它的任务很简单：每一次模型调用，都要留下一条结构化记录。这条记录至少包含这些字段：

• 调用时间、调用方标识（哪个服务、哪个用户、哪个项目）
• 使用的模型名称和版本
• 输入 Token 数、输出 Token 数、总 Token 数
• 预估成本和实际成本
• 请求的业务标签（比如“客服问答”“文档摘要”“代码生成”）
• 是否命中缓存、是否经过路由、路由决策结果
• 请求耗时、是否成功

这里有个坑我必须提醒：Token 数的统计口径一定要统一。不同模型厂商对 Token 的切分方式不一样，同一个中文句子，在 A 模型是 20 个 Token，在 B 模型可能是 25 个。如果你直接用厂商返回的数字做汇总，跨模型的成本对比就会失真。

我的做法是在网关层做一次统一的 Token 估算，用一套相对稳定的分词逻辑，作为内部核算的基准。厂商返回的实际数字作为对账依据，两者都记录，但内部报表以统一口径为准。这样跨模型对比才有意义。

注意：计量层一定要做成异步的。如果每次调用都同步写数据库，会显著增加延迟。我的做法是先写本地日志或消息队列，再由后台任务批量入库。这样对主链路的影响可以控制在毫秒级。

3.2 路由层：让每个请求都走“最划算”的那条路

路由层是 Token 工厂的“大脑”。它的核心决策逻辑可以概括成一句话：在满足质量要求的前提下，选择成本最低的模型。

听起来简单，做起来难。难点在于“质量要求”怎么量化。我的经验是，不要试图一开始就做精细的质量评估，先用规则路由跑起来。规则可以很简单：

• 任务类型是“简单分类/抽取”→ 走小模型
• 任务类型是“复杂推理/多步规划”→ 走大模型
• 用户是付费高级用户 → 优先走大模型
• 当前大模型配额剩余不足 20% → 降级到小模型
• 请求延迟敏感（比如实时对话）→ 走响应快的模型

这套规则不需要任何机器学习，配置起来十分钟就能上线，但往往能砍掉 30% 以上的成本。我见过一个团队，光是把“意图识别”这个环节从大模型换成小模型，一个月就省了四成。

等规则路由跑稳了，再考虑引入基于历史数据的智能路由。比如统计每个场景下不同模型的实际表现，用数据驱动决策。但这一步一定要在规则路由之后，因为你需要先有数据，才能谈智能。

提示：路由策略一定要支持灰度和回滚。新策略先放 5% 流量，观察质量和成本，没问题再逐步放量。我踩过的坑是，一次性全量切换路由策略，结果某个边缘场景质量暴跌，用户投诉了一周才发现。

3.3 缓存层：Token 世界里的“废料回收”

缓存是投入产出比最高的一环，但也是最容易被做错的。很多人理解的缓存是“把相同的问题缓存起来”，但实际业务里，完全相同的请求少之又少。真正有效的缓存策略要更聪明。

我一般分三级做缓存：

第一级是精确缓存。请求的输入完全一致，直接返回缓存结果。这一级命中率低，但实现简单，适合 FAQ 类场景。

第二级是语义缓存。把请求做向量化，相似度超过阈值就认为可以复用。这一级命中率高很多，但要注意阈值设置——设太高没效果，设太低会返回错误答案。我的经验是阈值设在 0.92 到 0.95 之间比较稳。

第三级是片段缓存。这是最容易被忽视但价值最大的一级。很多请求里有一部分是重复的，比如系统提示词、知识库片段、历史对话摘要。把这些片段缓存起来，只对新增部分做推理，能省下大量 Token。

这里有个关键细节：缓存一定要设置合理的过期策略。知识库类内容可以缓存久一点，实时性要求高的内容要短。我见过一个团队把股票行情问答缓存了 24 小时，结果用户问“现在股价多少”，返回的是昨天的数据，直接出了事故。

3.4 核算层：让每一分钱都能找到主人

核算层的任务是把计量数据变成可对账、可追责、可激励的成本报表。它的核心是归因——把每一笔成本归属到具体的团队、项目、甚至个人。

归因的粒度取决于你的组织架构。我一般建议至少做到项目级，有条件做到用户级。项目级归因靠的是请求里带的业务标签，用户级归因靠的是账号体系。

核算层最容易踩的坑是只算模型调用成本，不算其他成本。实际上，Token 工厂的完整成本还包括：网关服务器的算力成本、缓存存储成本、向量检索成本、日志存储成本。这些加起来可能占到总成本的 10% 到 20%。如果只算模型账单，优化方向会跑偏。

注意：核算报表一定要定期和厂商账单对账。我遇到过内部统计和厂商账单差 15% 的情况，排查后发现是某些异步任务没走网关，直接调用了模型。这种“漏网之鱼”不查出来，核算层就是自欺欺人。

4. 实操过程与核心环节实现

4.1 第一步：搭一个最小可用的计量网关

不要一上来就搞大而全。我的建议是先用一周时间搭一个最小可用的计量网关，把数据采起来。

技术选型上，如果团队有 Go 或 Rust 背景，建议用高性能语言写网关，因为网关在主链路上，性能很关键。如果团队以 Python 为主，可以用 FastAPI 起步，但要做好压测，确保不会成为瓶颈。

网关的核心逻辑就三步：接收请求、转发给模型、记录日志。伪代码大概是这样：

async def handle_request(request): # 1. 解析请求，提取业务标签和调用方信息 meta = parse_metadata(request) # 2. 估算输入 Token input_tokens = estimate_tokens(request.prompt) # 3. 转发给目标模型 response = await call_model(request) # 4. 记录计量日志（异步） log_usage({ "caller": meta.caller, "project": meta.project, "model": request.model, "input_tokens": input_tokens, "output_tokens": response.usage.output_tokens, "timestamp": now(), "cached": False, "routed": False }) return response

这个版本没有任何路由和缓存，但已经能回答“谁花了多少钱”这个问题。先跑起来，再优化，这是我反复强调的原则。

4.2 第二步：接入规则路由

计量跑稳两周后，你手里就有数据了。这时候可以开始做路由。第一步是分析数据，找出优化空间。

具体做法是：把过去两周的请求按业务标签分组，看每个标签下的平均 Token 消耗和调用次数。你会发现，往往 20% 的场景消耗了 80% 的 Token。这些就是重点优化对象。

然后针对这些场景，设计路由规则。比如你发现“客服问答”场景占了 60% 的 Token，但其中大部分问题都很简单，那就可以配置：客服问答场景，先用小模型试答，如果置信度低于阈值，再升级到大模型。

这个“先小后大”的策略我实测下来非常有效。它本质上是把大模型当成“兜底”，只在必要时才用。很多团队一开始就全量走大模型，其实是在为大量简单问题付高价。

4.3 第三步：实现语义缓存

语义缓存的实现需要一个向量数据库和一个嵌入模型。流程是：请求进来先做向量化，去向量库检索相似问题，如果相似度超过阈值，直接返回缓存答案。

这里的关键参数是相似度阈值和缓存过期时间。我的经验值：

阈值越高，缓存越安全但命中率越低。我一般从 0.95 起步，观察一周，如果发现误命中（返回了不相关的答案），就调高；如果命中率太低，就适当调低。

提示：语义缓存一定要有人工审核机制。定期抽样检查缓存命中结果，确认没有返回错误答案。我见过一个团队因为阈值设太低，用户问“怎么退款”，返回了“怎么退货”的答案，虽然相似度很高，但业务上完全是两回事。

4.4 第四步：建立成本看板和告警

数据采了、路由做了、缓存上了，最后一步是让成本可见。我建议做一个实时看板，至少包含这几个视图：

• 总览视图：今日/本周/本月总消耗，同比环比
• 项目视图：各项目的消耗排名和趋势
• 模型视图：各模型的消耗占比和单位成本
• 缓存视图：缓存命中率和节省的成本
• 路由视图：路由决策分布和降级比例

告警也很重要。我一般设置三类告警：日消耗超阈值告警、单项目消耗突增告警、缓存命中率骤降告警。前两个防的是“钱花超了”，第三个防的是“优化失效了”。

告警阈值怎么定？我的经验是用过去 30 天的日均值乘以 1.5 作为日告警线。这个系数既能容忍正常波动，又能及时发现异常。如果某天消耗突然翻倍，大概率是出了问题，而不是业务正常增长。

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

5.1 计量数据和厂商账单对不上怎么办

这是最常见的问题，我遇到过好几次。排查思路是从粗到细逐层核对。

先核对总量。如果总量差得不多（5% 以内），可能是统计口径差异，比如厂商算的是实际 Token，你算的是估算 Token。如果差得多，就要往下查。

再按模型核对。看是不是某个模型的差异特别大。我遇到过一次，某个模型的差异达到 30%，最后发现是这个模型的流式响应在网关层没被正确统计——流式返回的 Token 是分片到达的，如果统计逻辑没处理好，会漏算。

最后按时间核对。看是不是某个时间段的差异特别大。这通常意味着有“绕过网关”的调用。排查方法是检查所有服务的模型调用代码，看有没有直接调用厂商 SDK 而没走网关的。

注意：对账一定要自动化。我建议写一个定时任务，每天自动拉取厂商账单和内部统计做对比，差异超过阈值就告警。人工对账迟早会漏。

5.2 路由降级后质量下降怎么平衡

路由降级的本质是用质量换成本，所以质量下降是必然的，关键是把下降控制在可接受范围内。

我的做法是建立质量监控指标。每个场景定义一两个核心质量指标，比如客服场景看“用户追问率”，摘要场景看“人工抽检通过率”。路由策略上线后，持续监控这些指标。

如果质量下降超过阈值，有两个调整方向：一是收紧降级条件，比如把置信度阈值调高，让更多请求升级到大模型；二是优化小模型的提示词，很多时候小模型表现差不是能力问题，而是提示词没针对它优化。

我踩过的坑是，一开始只看成本不看质量，结果路由降级后成本是降了，但用户满意度掉了 20 个点，最后不得不回滚。成本优化一定要和质量监控同步做，这是血的教训。

5.3 缓存命中率上不去怎么办

缓存命中率低，通常是三个原因：阈值太高、缓存内容太窄、请求太分散。

先看阈值。如果阈值设在 0.98 以上，命中率低是正常的，适当调低试试。但调低之前一定要确认业务能接受一定的误命中风险。

再看缓存内容。如果只缓存完整请求，命中率肯定低。要扩展到片段缓存，把系统提示词、知识库片段这些高频重复内容单独缓存。

最后看请求分布。如果请求本身就很分散，那缓存效果有限，这时候应该把精力放在路由优化上，而不是死磕缓存。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是过早追求完美。我一开始想做一个能自动学习、自动优化的智能路由系统，结果做了三个月还没上线，业务方早就不耐烦了。后来改成先上规则路由，两周就见效。先跑起来，再迭代，这个原则我后来一直坚持。

第二个坑是忽视冷启动。缓存刚上线时命中率是 0，需要时间积累。如果这时候就下结论说“缓存没用”，那就错了。我一般会给缓存至少两周的观察期，等它积累足够的缓存条目后再评估。

第三个坑是没有和业务方对齐。Token 治理不是技术部门自己的事，它涉及预算、涉及业务体验。我见过技术团队闷头优化，结果业务方觉得“回答变差了”，两边闹矛盾。优化前一定要和业务方对齐目标和底线，哪些场景可以降级，哪些绝对不能碰，要提前说清楚。

6. 从 Token 工厂到 Token 经营：一些延伸思考

6.1 Token 工厂的边界在哪里

Token 工厂能解决“怎么花得合理”，但解决不了“该不该花”。这是两个层面的问题。前者是效率问题，后者是价值问题。

我见过一些团队，Token 工厂建得很好，成本控制得很漂亮，但业务本身没有增长。这时候再省 Token 也没意义，因为问题不在成本，在业务模式。Token 工厂是放大器，不是发动机。它能让好的业务更高效，但救不了本身就不成立的业务。

所以我的建议是，建 Token 工厂的同时，一定要有人盯着“投入产出比”。每花一块钱 Token，能带来多少收入或多少价值？这个账算不清楚，工厂建得再好也是白搭。

6.2 多 Agent 协作场景下的 Token 治理

现在越来越多的系统是多个 Agent 协作完成任务的。这种场景下，Token 消耗会成倍增长，因为 Agent 之间要互相通信、要反思、要重试。一个任务可能触发几十次模型调用。

这种场景下的治理思路和单 Agent 不一样。核心是控制协作轮次和设置预算上限。我一般会给每个任务设置一个 Token 预算，超过预算就强制终止或降级。同时限制 Agent 之间的最大协作轮次，防止无限循环。

还有一个技巧是让 Agent 之间传递摘要而不是全文。Agent A 给 Agent B 传递信息时，不要传原始的长文本，而是传一个压缩后的摘要。这样能省下大量 Token，而且往往不影响效果。

6.3 给准备自建 Token 工厂的团队几条建议

第一，从计量开始，不要从优化开始。没有数据支撑的优化都是瞎猜。先花两周把数据采起来，后面所有的决策都有依据。

第二，规则优先，智能其次。规则路由能解决 80% 的问题，而且实现简单、可控性强。等规则跑稳了，再考虑引入更复杂的策略。

第三，质量监控和成本优化同步做。只盯成本会翻车，只盯质量会破产。两个指标要一起看，找到平衡点。

第四，和业务方共建，不要闭门造车。Token 治理涉及业务体验，一定要让业务方参与决策，至少让他们知道你在做什么、为什么这么做。

第五，接受不完美。Token 工厂不是一次建成的，它是一个持续迭代的过程。先建一个能用的版本，然后在运行中不断优化。追求一步到位，往往一步都迈不出去。

我个人在实际操作中的体会是，Token 治理最难的不是技术，而是让所有人达成共识。技术方案再漂亮，如果业务方不配合、如果团队不执行，都是空中楼阁。所以我现在做这类项目，第一步永远是沟通，把目标、边界、收益讲清楚，让所有人知道这件事对大家都有好处。技术只是工具，共识才是基础。

最后分享一个小技巧：把 Token 成本换算成业务语言。不要跟业务方说“这个月省了 500 万 Token”，要说“这个月省了 8000 块钱，够给团队加两台服务器”。人对抽象数字没感觉，对具体的东西才有感觉。这个转换做得好，推动起来会顺利很多。