企业官网建设流程全解析

1. 1.73 亿 token 这个数字，先拆开看它到底意味着什么

先把结论摆在前面：1.73 亿 token 听起来像个天文数字，但真正决定账单的从来不是这个总量，而是输入、输出、缓存命中三者的比例。我见过太多人拿着一个总 token 数去乘单价，算出来的数字能差出十倍，问题就出在没拆结构。

WorkBuddy 这类工具在 9 月烧掉 1.73 亿 token，这个量级放在个人开发者身上算是重度使用，放在小团队里属于正常偏上。要算清楚它按官方价到底多少钱，得先搞清楚三件事：这些 token 是输入还是输出、有多少走了缓存、用的哪个模型档位。

1.1 输入和输出的价差，是账单里最大的变量

大模型 API 的计费逻辑里，输入（input）和输出（output）是两个完全不同的价格。以主流厂商的定价习惯来看，输出单价通常是输入的 3 到 4 倍，部分推理型模型甚至能到 8 倍以上。这意味着同样 1 亿 token，全是输入和全是输出，账单能差出好几倍。

WorkBuddy 作为一个偏 Agent 形态的助手工具，它的 token 消耗结构和普通聊天完全不一样。普通对话是一问一答，输入输出比大概 1:1 到 2:1。但 Agent 类工具会反复把上下文、工具定义、历史记录、文件内容塞进 prompt，输入侧会被严重放大。我实测过类似的 Agent 工作流，输入输出比经常能到 8:1 甚至 15:1。

所以 1.73 亿 token 里，如果按 10:1 的输入输出比来估，大概是 1.57 亿输入 + 0.16 亿输出。这个结构直接决定了后面所有计算。

1.2 缓存命中率，是能把账单砍半的隐藏开关

这是最容易被忽略、但省钱效果最猛的一项。主流 API 都支持prompt caching（提示缓存），命中缓存的输入 token 单价通常只有正常输入价的 10% 到 25%。WorkBuddy 这种工具因为系统提示词、工具定义、项目上下文高度重复，缓存命中率天然就高。

我拿一个真实场景举例：一个固定的系统提示词加工具定义大概 8000 token，如果每轮对话都重新计费，跑 1000 轮就是 800 万 token 全价。但如果缓存命中，这 800 万里有 700 多万按缓存价算，成本直接掉到原来的两成左右。

所以算账的时候，必须把输入 token 拆成"缓存命中"和"缓存未命中"两部分，否则算出来的数字会严重偏高。

1.3 模型档位决定了单价的天花板

WorkBuddy 支持切换模型，不同模型的单价差距非常大。旗舰模型和轻量模型的输入价差能有 10 倍以上。1.73 亿 token 如果全跑旗舰模型，和全跑轻量模型，账单完全不是一个量级。

现实情况通常是混合的：复杂任务走旗舰，简单任务走轻量。所以下面我会给出几档不同模型组合下的估算，你可以对照自己的实际使用情况去套。

2. 按官方价把 1.73 亿 token 拆成一张账单

这一节直接上计算。为了让结果有参考价值，我用当前主流 API 的典型定价区间来建模，单位统一按"每百万 token 美元"来算，最后再折算。注意：具体单价会随厂商调整，这里用的是常见档位，重点是计算方法和结构，你把自己的实际单价代进去就行。

2.1 先设定三档模型和对应单价

我按常见的三档来设：

这三档基本覆盖了市面上主流的选择。旗舰对应最强推理能力，中端是性价比主力，轻量用于高频简单任务。

2.2 假设一个合理的 token 结构

基于 Agent 类工具的典型特征，我设定这样一组比例：

• 总 token：173,000,000
• 输入占比：90%，即 155,700,000
• 输出占比：10%，即 17,300,000
• 输入中缓存命中率：60%，即 93,420,000 走缓存价
• 输入中缓存未命中：62,280,000 走全价

这个 60% 的缓存命中率对 WorkBuddy 这种工具有点保守，实际可能到 70% 以上。但保守估计更稳妥。

2.3 三档模型下的账单对比

全走旗舰模型：

• 缓存命中输入：93.42 × 0.3 = 28.03 美元
• 未命中输入：62.28 × 3 = 186.84 美元
• 输出：17.3 × 15 = 259.5 美元
• 合计：约 474.37 美元

全走中端模型：

• 缓存命中输入：93.42 × 0.1 = 9.34 美元
• 未命中输入：62.28 × 1 = 62.28 美元
• 输出：17.3 × 4 = 69.2 美元
• 合计：约 140.82 美元

全走轻量模型：

• 缓存命中输入：93.42 × 0.015 = 1.40 美元
• 未命中输入：62.28 × 0.15 = 9.34 美元
• 输出：17.3 × 0.6 = 10.38 美元
• 合计：约 21.12 美元

看到差距了吗？同样的 1.73 亿 token，全旗舰接近 475 美元，全轻量只要 21 美元，差了 22 倍。这就是为什么"1.73 亿 token 要花多少钱"这个问题，脱离模型档位根本没法回答。

2.4 混合使用的真实账单估算

现实中 WorkBuddy 用户大概率是混合的。我按一个常见的 2:5:3 比例来分（旗舰 20%、中端 50%、轻量 30%）：

• 旗舰部分：474.37 × 0.2 = 94.87 美元
• 中端部分：140.82 × 0.5 = 70.41 美元
• 轻量部分：21.12 × 0.3 = 6.34 美元
• 合计：约 171.62 美元

按这个结构，1.73 亿 token 的月账单大概在170 美元上下，折合人民币一千出头。这个数字对重度个人用户来说不算离谱，对团队来说更是可控。

注意：如果你的缓存命中率只有 30%，同样结构下账单会涨到 250 美元以上。缓存命中率每降 10 个百分点，账单大概涨 15% 到 20%。这是最值得优化的一个指标。

3. 缓存命中率为什么能决定一半账单，以及怎么把它拉上去

上一节算完账，你会发现缓存命中率是那个"看不见的手"。这一节专门讲清楚它的原理和实操优化方法，因为这是 WorkBuddy 用户最该掌握的一项省钱技能。

3.1 缓存到底缓存了什么

大模型的 prompt caching 机制，本质是把前缀相同的部分缓存起来。当你连续多次请求时，如果开头一大段内容完全一致，服务端就不需要重新计算这部分的注意力，直接复用之前的计算结果，因此给你打折。

关键点在于"前缀相同"。缓存是从 prompt 的最开头往后匹配的，一旦中间有一处不同，后面的全部失效。这就像你寄快递，地址前几行一样可以走同一个分拣通道，但只要有一个字不同，就得重新分拣。

WorkBuddy 这类工具天然适合缓存，因为它的 prompt 结构通常是：

1. 系统提示词（固定）
2. 工具定义（固定）
3. 项目上下文（半固定）
4. 对话历史（变化）
5. 当前用户输入（变化）

前 1、2 项完全固定，第 3 项在同一个项目里也基本不变。这三块加起来往往能占到单次请求输入 token 的 50% 到 70%。只要它们稳定不变，缓存命中率就能维持在高位。

3.2 哪些操作会悄悄打掉你的缓存

我踩过的坑里，最常见的缓存杀手有这么几个：

• 系统提示词里带了时间戳或随机 ID。有些工具会在系统提示里插入当前时间，导致每次请求前缀都不同，缓存全废。这是最隐蔽也最致命的。
• 工具定义顺序不稳定。如果工具列表每次序列化的顺序不一样，前缀就变了，缓存失效。
• 项目上下文频繁重排。比如每次把文件按修改时间重新排序塞进去，前缀就乱了。
• 中途切换模型。不同模型的缓存不互通，切一次模型，之前的缓存全部作废。

提示：如果你发现账单比预期高很多，第一件事就是去查系统提示词里有没有动态内容。把时间戳、随机数、会话 ID 这类东西挪到 prompt 的末尾，缓存命中率能立刻回升。

3.3 把缓存命中率从 40% 拉到 75% 的具体做法

我实测有效的一套组合拳：

1. 固定前缀，动态后置。把所有不变的内容（系统提示、工具定义、项目说明）放在最前面，把变化的（用户输入、时间、临时数据）放到最后。这是缓存生效的前提。
2. 工具定义做稳定排序。按字母序或固定 ID 序排列，别用哈希序或随机序。
3. 项目上下文做增量更新。不要每次全量重塞，只把变化的部分追加到末尾，前面的保持不动。
4. 控制模型切换频率。同一个会话尽量用同一个模型，需要切换时新开会话。
5. 合理设置缓存 TTL。主流缓存有存活时间，太短会频繁失效，太长会占用配额。一般 5 到 10 分钟对连续工作流够用。

按这套做法，缓存命中率从 40% 提到 75% 是现实的。回到上一节的账单，同样 1.73 亿 token，命中率从 60% 提到 75%，中端模型下能再省 20 美元左右，旗舰模型下能省 60 美元以上。

4. 除了缓存，还有哪些地方在偷偷吃你的 token

算完账、优化完缓存，还有几个 token 黑洞值得单独拎出来说。这些是我在实际使用 WorkBuddy 过程中观察到的、常规文档里不会写的消耗点。

4.1 上下文膨胀：Agent 工具最大的隐形开销

普通聊天是一问一答，上下文线性增长。但 Agent 工具会把每一轮的工具调用结果都塞回上下文。一次文件读取可能返回几千 token，一次搜索可能返回上万 token，这些都会累积到后续每一轮请求里。

我做过一个测试：一个 20 轮的任务，如果每轮都带上完整历史，到第 20 轮时单次请求的输入可能已经膨胀到 5 万 token 以上。而如果做了上下文压缩或滑动窗口，能控制在 1 万以内。这中间的差距，乘以轮数，就是几百万 token 的差别。

应对方法有几个：

• 开启上下文压缩。让工具自动总结早期历史，只保留关键信息。
• 用滑动窗口。只保留最近 N 轮完整对话，更早的做摘要。
• 及时清理工具返回的大块内容。文件读完了，内容用完后可以从上下文里移除。

4.2 重试和失败请求，也在计费

这一点很多人不知道：失败的请求如果已经产生了 token 计算，有些情况也是要计费的。尤其是输出被截断、超时、格式错误导致重试的场景，token 是实打实消耗掉的。

WorkBuddy 在跑复杂任务时，工具调用失败、模型输出格式不对、需要重新生成的情况并不少见。如果重试率有 10%，那 1.73 亿里就有 1700 万是"白烧"的。

降低重试率的做法：

• 给工具调用加严格的参数校验，别让模型瞎猜格式。
• 输出用结构化格式（JSON schema）约束，减少解析失败。
• 设置合理的超时，别让请求卡死重试。

4.3 不同任务的 token 效率差异巨大

同样是让 WorkBuddy 干活，不同任务的 token 效率能差好几倍。我总结了几类：

批量重复任务如果缓存做得好，效率其实不差。真正烧钱的是长文档处理和多轮 Agent，这两类任务要特别关注上下文管理。

5. 把账单压下来的完整实操清单

前面讲了原理和结构，这一节给一份可以直接照着做的清单。我按"投入产出比"从高到低排，你先做前面的，效果最明显。

5.1 第一优先级：缓存优化（省 30% 到 50%）

• 检查系统提示词，移除所有动态内容（时间戳、随机 ID、会话标识）。
• 工具定义固定排序，序列化结果保持稳定。
• 项目上下文增量更新，不重排、不全量重塞。
• 同一会话不频繁切模型。
• 监控缓存命中率，目标 70% 以上。

这一项做完，账单基本能砍掉三分之一。而且它不需要改业务逻辑，纯配置层面的事。

5.2 第二优先级：上下文管理（省 15% 到 30%）

• 开启自动上下文压缩。
• 设置滑动窗口，保留最近 10 到 15 轮。
• 工具返回的大块内容用完即清。
• 长文档先切分再处理，别整篇塞。

上下文管理是 Agent 工具省钱的核心。我见过一个案例，光是把上下文从"全量保留"改成"滑动窗口 + 摘要"，月账单从 400 多美元降到 200 出头。

5.3 第三优先级：模型分级（省 20% 到 40%）

• 简单任务走轻量模型，复杂任务才上旗舰。
• 用路由规则自动分流，别全靠手动切。
• 定期 review 哪些任务其实不需要旗舰模型。

模型分级的关键是别用大炮打蚊子。很多日常任务，轻量模型完全够用，效果差异用户根本感知不到，但成本差 10 倍以上。

5.4 第四优先级：减少无效消耗（省 5% 到 15%）

• 加严工具调用的参数校验，降低重试率。
• 输出用结构化约束，减少解析失败。
• 设置合理超时，避免卡死重试。
• 定期看日志，找出高频失败的任务类型。

这一项省得相对少，但它是"止损"，能防止账单因为异常情况突然飙升。

6. 回到那个问题：1.73 亿 token 到底该花多少钱

把前面所有分析收拢一下。1.73 亿 token 按官方价的合理区间是：

• 全旗舰、低缓存：500 美元以上
• 混合模型、中等缓存：150 到 200 美元
• 优化到位、高缓存、模型分级：80 到 120 美元
• 全轻量、高缓存：20 到 30 美元

所以"到底要花多少钱"这个问题，答案不是一个数字，而是一个区间，取决于你的使用结构。WorkBuddy 这种工具，如果配置得当，1.73 亿 token 的月成本控制在 100 到 150 美元是完全现实的。如果放任不管，冲到 400 美元以上也不奇怪。

我个人在实际操作中的体会是：先别急着换便宜模型，先把缓存和上下文这两件事做好。这两项是纯工程优化，不影响输出质量，但省钱效果最直接。等这两项做到位了，再考虑模型分级，那才是锦上添花。很多人一上来就想着换轻量模型省钱，结果任务质量下降、重试率上升，最后算下来反而没省多少，还把体验搞差了。

最后分享一个小技巧：每周花十分钟看一下 token 消耗的分布，按任务类型和模型档位拉个表。你会发现，往往 20% 的任务类型吃掉了 80% 的 token。把这 20% 优化好，比全面铺开改要高效得多。