Token Counting

生产级 LLM 应用的上下文窗口规划开发指南

2026年7月20日TokenTest Editorial Team
English中文
生产级 LLM 应用的上下文窗口规划开发指南

生产级 LLM 应用的上下文窗口规划开发指南

生产环境中大多数上下文窗口失败并不是从模型崩溃开始的。它们往往始于这样一个提示：从技术上看它能放得下；一个在预发布环境里看起来合理的响应预算；以及一组使用数据——等真实工作负载变得更长、语言更多样，或者工具调用更多时，这些数据才暴露出不完整。

因此，生产级 LLM 应用的上下文窗口规划应被视为一门工程学科，而不是文案细节。

截至2026 年 7 月 20 日，OpenAI 当前的开发者文档为团队提供了四个需要立即关注的规划信号：

  • 你可以在通过 POST /v1/responses/input_tokens 发送请求前计算输入 token 数。
  • 报告的输出 token 数可能会高于可见文本，因为某些模型会生成不可见的格式化或结构化 token。
  • 推理 token 不会以原始文本形式显示，但它们仍然占用上下文窗口空间，并且会按输出 token 计费。
  • 当你开始尝试推理模型时，OpenAI 建议为推理和输出至少预留25,000 个 token。

这些细节会改变生产团队对提示、输出、缓存预期以及多语言推广的尺寸规划方式。

TokenTest 在这一工作流中很有用，因为它并不被定位为玩具级分词器。在 TokenTest 首页上，该产品被描述为面向 AI 中间层买家的生产参考评测控制台。实时页面说明它会批量测试模型能力、路由协议、token 使用情况、安全边界和通道可靠性，并明确表示你的 API key 永远不会被存储。页面上可见的产品检查还包括Usage integrity、cache token evidence、thinking / reasoning tokens、token total consistency、input monotonicity以及stop/token limit linkage。

上下文窗口规划到底意味着什么

对于生产级 LLM 应用而言，上下文窗口规划意味着管理所有争夺同一请求预算的 token：

  1. 系统和策略指令
  2. 用户输入
  3. 检索到的上下文或附加文件
  4. 工具 schema 和工具调用脚手架
  5. 推理 token
  6. 可见输出 token
  7. 不可见的响应格式 token

许多团队仍然只围绕提示正文进行规划。这样范围太窄了。

一个足够简单、可直接使用的生产预算模型

request_budget
= prompt_tokens
+ retrieved_context_tokens
+ tool_and_format_tokens
+ reserved_reasoning_tokens
+ reserved_visible_output_tokens
+ safety_buffer

不要让安全缓冲区变成可选项。当你使用推理模型时，这个缓冲区决定了“在预发布环境中能通过”和“在真实负载下失败”之间的差别。

预算项起始规则
提示词和策略保持精简；删除重复指令
检索和文件按相关性设限，而不是按集合大小
推理预留从真实预留额度开始，不要从零开始
可见输出预留根据产品需求设定，而不是靠猜想
安全缓冲为漂移和格式化 token 预留额外空间

破坏上下文规划的五个生产级错误

1. 将上下文窗口视为仅用于提示词

上下文窗口是共享容量。如果你用提示文本和检索片段填满它，模型仍然需要空间来思考和回答。

2. 忽略不可见输出 token

OpenAI 的 token 计数指南现在明确指出，某些模型会为格式化、工具调用和消息结构生成 token，这些内容不会以可见内容的形式显示出来。因此，报告的输出可能会超过用户实际看到的内容。

3. 只使用单一的理想路径样本

在预发布环境里，一个简短的英文提示词并不能代表你的生产上限。真实流量通常包含更大的客户输入、更多检索、更频繁的重试以及更长的工具调用轨迹。

4. 忽视多语言扩展

不要假设工作流的英文版本和中文版本成本相同。不同的措辞、示例和检索到的片段都会改变总 token 使用量。请分别衡量每种生产语言。

5. 在未经验证的情况下相信 usage 字段

一个路由器可能返回看似合理的 usage 数字，却隐藏了缺失的缓存证据、不稳定的总量，或者在不同提示词长度下异常平坦的结果。这正是 TokenTest 的 usage 完整性检查旨在揭露的问题。

一个经得起审查的规划工作流

  1. 在发送前计算请求。
  2. 在需要之前预留输出空间。
  3. 有意识地保持提示词精简。
  4. 在黑盒运行中验证 usage 行为。
  5. 重新测试每一种生产语言。

在上线前于 TokenTest 中运行的四项检查

测试要改什么良好表现是什么样
短提示词 vs. 长提示词添加策略文本或 few-shot 示例输入 token 明显增加
小检索块 vs. 大检索块将注入上下文加倍总量按比例上升
正常上限 vs. 紧上限降低 max_output_tokens结束行为随上限发生变化
首次运行 vs. 重复运行重复相同请求在预期时出现缓存证据

你可以粘贴到 TokenTest 中的提示词示例

示例 1：简短基线提示词

You are a support classifier.

Read the user's message and return JSON with:
- intent
- priority
- refund_risk

User message:
"I was billed twice and your app crashed after checkout."

示例 2：包含大量策略内容的长提示词

你是一款受监管 SaaS 产品的支持分类器。

请遵循所有规则：
1. 只返回严格的 JSON。
2. 绝不包含医疗、法律或金融建议。
3. 如果用户提到收费、争议或重复扣费，将 refund_risk 设为 high。
4. 如果用户报告支付后产品故障，将优先级提升为 urgent。
5. 如果用户要求报销，请包含 escalation_required=true。
6. 仅使用以下意图之一：
   - billing_issue
   - account_access
   - technical_bug
   - cancellation
   - other
7. 在 25 个词以内添加一句理由说明。

用户消息：
"I was billed twice and your app crashed after checkout."

Example 3: 英文 vs. 中文本地化检查

English:
用一句话总结这个产品问题，供内部事故看板使用：
"Customers report duplicate charges after a failed checkout flow."

Chinese:
请用一句话总结这个产品问题，供内部事故看板使用：
"用户反馈在结账流程失败后出现重复扣费。"

Example 4: 推理压力测试

你正在审查一个 LLM 路由策略。

在以下约束下，判断请求应进入：
- cheap-fast
- balanced
- high-reasoning

约束：
- 将月度成本保持不变
- 对含糊任务保持答案质量
- 为简单抽取任务尽量降低延迟
- 不要向最终用户暴露部分或不完整的答案

请求：
"Analyze a multilingual contract summary, compare clauses across versions, and identify legal-risk deltas."

返回：
- selected_route
- reason
- risks_if_wrong

总结

面向生产环境的 LLM 应用进行上下文窗口规划，不只是找到模型的最大上下文数字。更重要的是决定这段窗口中有多少属于提示词、检索、工具、推理、可见输出和安全余量，然后验证线上端点报告的使用量是否可信。

这正是 TokenTest 的用武之地。它为团队提供了一种比较请求形态、检查使用证据，以及在成本超支或不完整回复到达生产环境之前，对多语言工作流进行压力测试的方法。

来源