企业官网建设流程全解析

如果你在调大模型接口，大概率碰到过这几类怪问题：新建会话的时候它聪明得不行，一聊到第20轮就开始“失忆”，你问它最早聊过什么，它一脸无辜；打开账单一看，没干多少活，费用却高得吓人。要一次把这两件事说清楚，绕不开两个核心概念：Token 和上下文窗口。

Token 是模型读取文本的最小单位，上下文窗口是模型单次能够“同时看到”的最大文本范围。这两个东西决定了你最关心的三件事：模型能看多远、会不会忘事、每次调用要付多少钱。这篇文章不扯高深的数学公式，用大白话把 Token 怎么算、窗口怎么装、钱怎么烧讲透，最后给出一套可以直接上手的防遗忘、省钱实操方案。适合正在调 API 的开发者、AI 产品负责人，以及被“上下文不足”反复折磨的各类用户。

1. Token 是什么：先搞懂模型眼里的“最小文字单位”

1.1 从字符到碎片：Token 化是怎么回事

模型不会直接读文字，它读的是数字。Token 化就是把自然语言切成小块，再映射成编号的过程。现在主流做法是字节对编码（BPE）之类的子词分词算法：先看常见的词或词根，把它们当作整体，不常见的词再继续切成更小的碎片。

拿一段中文文本举例，“这是一个测试用例”，在常见分词器下大概会被切成 7 到 10 个 Token。英文“What a nice day”大概切成 4 到 5 个 Token。但要注意，这不是按字数、按单词数简单换算的。中文一个字有时候就要占 1 个甚至 1.5 个 Token，英文一个常见单词通常 1 到 3 个 Token。代码和特殊符号更是 Token 大胃王，几行配置代码吃掉的 Token 可能比一整段说明文字还多。

这个特性直接决定了跨语言产品的成本差异。我做过一个小实验：同一篇文档，中文版约 600 字，英文版约 480 个单词，用同一款分词器统计，中文版折算出的 Token 数大约是英文版的 1.5 到 2 倍。也就是说，如果你的产品主要面向中文用户，同样的功能，Token 消耗天然就比英文产品高一截，这不是你写代码能解决的，是分词方式决定的。

字数不等于 Token 数，这个认知很重要。很多刚接触 API 的同学喜欢按字数估算费用，一估算就乐观，一结算就被打脸，原因就在这。

1.2 为什么按 Token 计价而不是按字数或字符

先看根本原因：模型的计算开销和 Token 数强相关，而非字数。

输入侧，模型要把所有 Token 两两之间计算“注意力”（Attention），这是个近似 O(n²) 复杂度的操作。Token 数从 1000 涨到 2000，这部分的计算量不是翻倍，而是接近翻四倍。你的输入越长，单位 Token 的均摊计算成本越高。这也是长上下文迟迟不敢把价格打下来的原因之一。

输出侧更夸张。大模型生成文本是逐 Token 自回归的过程，每次生成一个 Token，都要基于前面已经生成的全部内容重新算一遍上下文。也就是说，生成 100 个 Token，本质上是执行了 100 次“小号预测”，每往后写一个字，耗费的计算资源都在增加。这也是为什么几乎所有 API 都把输出价格定得比输入贵，甚至贵出 2 到 3 倍。

类比一下：按 Token 收费就像货车按车次计费，不按包裹个数计费。司机跑一趟的成本取决于总共有多少批货、跑了几趟，而不是包裹本身多大。模型处理的时候，每个 Token 都要走一遍完整计算流水线，它才是真正消耗计算资源的“货物”。

2. 上下文窗口：模型的内存边界，也是遗忘的根源

2.1 窗口里到底装了什么

上下文窗口（Context Window）指的是模型单次请求能够处理的 Token 总量，这是一个“同时可见”的上限。很多人把它理解成“模型记住了多少东西”，其实不对，它更像是“模型当前摊在桌面上能看到多少张纸”。

每次你发一个请求给 API，它接收的内容包括以下几个部分：

• 系统提示词（System Prompt），用来设定人设和固定规则
• 之前的对话历史，每一轮用户问的和 AI 答的都会带上
• 当前这一轮你问的新问题
• 留给模型生成回答的空间

这四个部分共享同一个窗口预算。注意最后一条：很多人以为窗口只是给输入用的，其实模型生成回答也要占窗口空间。你设置的 max_tokens 如果太小，模型回答到一半就可能被硬生生截断；你如果输入太长、把窗口塞满了，模型可能连回答都生成不了或者直接报错。

我用一个比较形象的比喻：上下文窗口是一张固定大小的会议桌。系统提示词占一块、历史记录占一块、你当前的问题占一块，剩下才是放回答的地方。桌子就这么大，放不下的时候，只能往地上丢东西，丢掉的就是你“遗忘”的内容。

2.2 会“忘”的三种真相

很多人把“模型忘事”归结为模型智力问题，其实大部分情况不是记性差，而是机制决定的。

第一种遗忘是机械性截断。当历史 Token 总数超过窗口上限，API 通常的做法是丢弃最早的内容，只保留最近的部分。比如窗口是 8K，你聊了 20 轮消耗了 12K Token，那最前面的 4K 历史就被直接丢弃。这不是“忘了”，而是这些内容压根没被送进模型。你一上来聊的东西，早就被挤出了会议桌。

第二种遗忘是注意力稀释。就算 Token 总数没超窗口，内容太多也会坏菜。研究表明，模型对长文本中间位置的注意力明显低于开头和结尾，这被称为“Lost in the Middle”现象。你把关键信息埋在 100 条历史记录的中间，模型大概率在回答时找不到它，表现出的效果和“忘了”一模一样。这个现象对 Agent 类应用特别致命：任务中间环节的状态信息最容易丢。

第三种遗忘是输出挤占。窗口被输入占掉 90%，留给输出的空间只剩 10%，模型被迫在窗口边界处截断，回答后半段直接消失。这也常被误读为“模型记忆力不行”，其实是你的输出没地方放了。

我实际调试 Agent 时踩过一个典型坑：让模型参考一份很长的资料文档（大约 6K Token），同时塞入三轮对话历史，窗口 8K，结果每次到第三轮回答就断在中间。查了日志才发现，输入已经占了 7.8K，输出只剩 200 Token 的空间，不截断才怪。之后我把资料文档改成检索后只塞相关片段，问题立刻消失。

2.3 长上下文窗口不是免死金牌

现在各家都在宣传 128K、200K 甚至 1M 的上下文窗口，看起来好像再也不用担心“忘事”了，实际用起来完全不是那么回事。

长窗口贵。窗口越大，处理整个上下文的成本就越高，长窗口的调用通常比短窗口贵出不少。而且不是只有超出部分才贵，是整个输入都要重新计算一遍。

长窗口慢。输入越长，首 Token 延迟越高。模型必须把全部输入先“读”一遍（Prefill 阶段），窗口里有 10 万 Token，光是读完就要花好几秒。你等得越久，体验越差。

长窗口还会掩盖架构问题。如果你的应用设计成“把所有东西都塞进上下文”，程序确实能跑，但每轮都在烧钱、每轮都在变慢，最后你会得到一个能跑但根本没法商用的玩具。长窗口的真正价值，是让你有更大的缓冲区域去设计更好的记忆策略，而不是让你无脑塞东西进去。

3. 为什么贵：钱到底被什么吃掉了

3.1 输入和输出不是统一定价

先看一个普遍现象：几乎所有 API 的定价都是输出比输入贵一大截。以某主流模型当前公开报价为例（具体数字随时变，思路不变）：输入侧大约每百万 Token 几十元人民币，输出侧则是每百万 Token 上百元，输出单价是输入的两到三倍。

为什么这么定价？前面提到过，输出是逐 Token 自回归生成，每生成一个 Token 都要基于整个上下文重新计算一遍，计算量远大于处理一个输入 Token。输出 Token 是“生产出来的东西”，也是用户真正拿走的价值，贵有贵的道理。

这个定价结构带来一个反直觉的结论：让模型多说废话，比让它多读资料更费钱。1000 Token 的回答，成本往往相当于读入 3000 Token 的资料。所以在设计提示词时，除了控制输入长度，控制输出长度同样重要。很多产品喜欢让模型输出“详细的步骤”“全面的说明”，这些漂亮话每一段都在烧钱。

3.2 多轮对话的复利陷阱：越聊越贵的原因

这是最常见也最容易被低估的成本放大器。很多人以为多轮对话是“每次发一句话”，费用应该差不多，实际上完全相反。

因为 API 本身是无状态的，每次请求你都得把全部历史重新发一遍。假设单轮对话平均消耗 1.5K Token（输入 1K，输出 0.5K），我们算一算累积量：

看懂这个表的逻辑了吗？第 20 轮时，单次请求就要发送约 30K Token，其中 28.5K 都是重复的历史。累计消耗 315K Token，但真正“有用”的新内容只有 30K，90% 的钱花在了重复计算历史上。这就是为什么你感觉“没聊几句，账单却爆炸”。

我见过一个实际案例：某内部测试的对话机器人，用户平均会话长度 25 轮，后台统计下来单日 Token 消耗中，历史重复发送占比超过 80%。做了历史压缩之后，同样用户规模的 Token 成本直接砍掉三分之二。在 AI 应用里，多轮对话的成本优化空间，往往比模型选型还大。

3.3 长窗口的预填充：为什么供应商卷窗口反而要注意

“上下文窗口 128K”听起来很爽，但用长窗口是有隐性成本的。每次请求，模型都要先把全部输入处理一遍，这个阶段叫预填充（Prefill），预填充的耗时和成本大致随输入长度线性增长。你想让模型“看到”100K 内容，就得先为这 100K 内容付一次全量计算的钱。

现在有些平台提供上下文缓存，同一段前缀如果多次使用，可以复用计算结果，能省一部分钱。但缓存一般有有效期，命中条件也挺严格，前缀必须完全相同，差一个空格都可能失效。真正常被命中的，也就是 System Prompt 这种固定内容。你把一堆对话历史放进去指望复用缓存？基本别指望。

所以我建议：不要因为供应商送了大窗口就拼命用。长窗口是避险工具，不是日常饭票。日常对话优先保持上下文在几 K 到十几 K 的范围，需要的时候再临时拉长窗口。用 60% 的窗口预算做缓冲，永远比顶着 99% 跑安全，也更省钱。

4. 实战策略：一边省钱，一边让模型少忘事

4.1 滚动摘要：把历史变成一块压缩饼干

对付“越聊越贵”和“越聊越忘”的最实用手段，就是滚动摘要。思路很简单：对话超过一定轮数后，让模型把之前的对话总结成一两段摘要，下一轮开始用摘要替代完整历史。

具体步骤：

• 设定阈值，比如每聊 5 轮触发一次摘要
• 让模型输出结构化的对话摘要：“用户目标、已完成事项、待办事项、关键偏好”
• 后续请求改为：System Prompt + 摘要 + 最近两轮原对话 + 当前问题

这样窗口占用从“全部历史”变成“摘要 + 最近内容”，可能把 30K 的 Token 压缩到 3K 以内。摘要带来的一个副作用是细节丢失，但多数业务场景要的是上下文连续性而不是逐字记忆，这点损失完全可以接受。

我在实际项目中会把摘要更新做成异步任务：每轮对话结束后，不阻塞主流程，后台把最近的对话追加到旧摘要里生成新摘要，存储起来。下次用户继续对话时直接读取最新摘要，全程用户无感。这套流程实施后，产品连续对话能力提升明显，单用户成本则大幅下降。

4.2 外部记忆：RAG 只取相关片段，不整篇硬塞

如果应用需要参考很长的知识库文档，别把整篇文档丢进上下文，用检索增强生成（RAG）的方案：先把知识库切成小块，用向量索引存起来；每次用户提问，先做语义检索，只把最相关的 Top-K 片段塞进上下文。

举个例子，某知识库文档全文 10 万 Token，如果整篇塞进上下文，一次调用光输入就要花不少钱。而通过向量检索，只取 3 个片段、每个 500 Token，总共 1500 Token，成本直接降到原来的百分之一，同时回答质量更高，因为模型不会被 10 万个 Token 的不相关内容分散注意力。

这个模式对“多文档对比”“企业内部知识问答”这类场景尤其有效。需要提醒的是，切块大小和检索结果数量需要调参：块太小语义不完整，块太大一样浪费 Token；Top-K 取少了可能漏掉关键答案，取多了又烧钱。一般建议块大小 500 到 1000 Token、Top-K 取 3 到 5 个，然后根据你的场景微调。

4.3 提示词布局：利用注意力分布规律让关键信息被记住

前面提过“Lost in the Middle”现象：模型对长文本的开头和结尾注意力更强，中间区域容易被忽略。反过来利用这个规律，可以显著改善“记住关键信息”的效果。

实操要点：

• 系统提示词（角色设定、核心规则）放在最开头，它会被稳定关注
• 当前这一轮的具体任务、目标要求，放在请求的最末尾，紧挨着生成位置
• 参考资料、不太重要的历史信息，放在中间位置
• 如果要引用的关键数字或结论，在开头和结尾各提一次，双保险

这个技巧在调试 Agent 时特别有用。我遇到过很多次：模型把工具调用规则忘了，症状像是“记忆退化”，其实只是因为规则埋在很长的历史中间。把它挪到开头，问题立刻减轻。别小看这种“排布学”，它不花钱，却常常比调整提示词本身更有效。

4.4 系统设计层面的省钱清单

除了上面的三类招数，还有几个系统层面的习惯，长期下来能省不少。

第一，系统提示词保持稳定。如果提示词经常变，上下文缓存的命中率会很低；把固定不变的 Prompt 放在最前面，后面接每次变化的部分，命中率能明显提升。

第二，限制输出长度。max_tokens 设成你真正需要的长度，而不是让模型自由发挥。一个 500 Token 就能说清的答案，模型自由发挥到 1500 Token，成本直接翻三倍，还更容易出现废话和幻觉。

第三，及时开启新会话。对话超过 20 轮后，哪怕有摘要，上下文质量也在下降。适时给用户“开启新对话”按钮，或者系统检测到上下文过载时自动清理历史，是对用户体验和成本的双重保护。

第四，对 Token 消耗做计量。在客户端或服务端统计每个请求的 Token 数、每用户每天的平均消耗，设置异常告警。很多人不是不想优化成本，是压根不知道钱花在哪，有了计量才有优化的起点。

5. 常见问题排查与避坑记录

5.1 为什么窗口明明没满，回答却被截断

查了几种原因。最常见的是输出空间没留够。max_tokens 设太小，模型生成到一半就触及上限，于是硬停。另一个原因是 API 内部会预留一部分 Token 作为输出空间，你在界面上看到的窗口大小和实际可用输入大小不是同一个值。比如窗口 8K，某些服务实际允许的输入可能只有窗口的一半多一些。

排查方法：看 API 返回的 finished_reason 字段，如果是 length 而不是 stop，说明是被长度截断，把 max_tokens 调大，或者缩短输入给输出腾地方。

5.2 为什么同样的文本，两次计费 Token 不一样

理论上同一款分词器对同一段文本的 Token 化结果是确定的。但实际中你会发现变化，常见原因是：文本细节变了，可能是多了个空格、换行符，或者引号变成了全角。中文尤其敏感，全角逗号和半角逗号的 Token 结果可能差出几个 Token。还有的 API 会自动在文本前面附加一段隐藏的元描述或不需要的格式标记。

所以精确对比成本时，不要靠肉眼数长度，直接本地用同一版本的分词器数一遍 Token，结果最可靠。

5.3 为什么窗口越大的请求，首 Token 越慢

这是 Prefill 阶段的必然结果。窗口越大、输入 Token 越多，首 Token 延迟越高，用户感受到的就是“模型反应变慢”。如果你的应用对延迟敏感，比如聊天机器人要快速回话，宁可多用几个短请求，也不要一个超长请求。短请求的 Prefill 总时间和长请求相比往往更低，何况还能省 Token。

5.4 避坑速查表

这个表我建议直接贴在项目文档里，团队里无论谁在处理上下文问题时，先对照一遍，能省下不少排查时间。

我自己的体会是，Token 和上下文窗口这两个概念，理解起来不难，难的是把它内化成工程直觉。做项目的前期，我也经常“能用就行”，结果账户账单一旦拉出来，再回头改架构，改造成本比一开始就设计好要高得多。现在每接手一个新项目，我会先问一个问题：这个产品的对话历史到底需要保留多少？能不能压缩？能不能检索？想清楚这三件事，后面的费用和体验问题基本就解决了一大半。

最后再分享一个小技巧：在开发时，把 Token 计数直接打在每一轮请求的日志里，肉眼就能看到每次调用在不同阶段的消耗，比事后看账单直观得多。等这个数据积累起来，你会发现哪些功能是吃 Token 的大户、哪些提示词在慢性放血，顺着数据改，成本下降是水到渠成的事。

Token 和上下文窗口管理没有太多玄学，无非是把“模型看到什么”这件事重新捡起来，管好输入、压缩历史、分清主次，省下来的每一分钱都是利润。希望这篇整理对你有用，有问题可以去评论区聊聊你踩过的坑，正好我也在收集各种奇怪场景。