Token 高效提示模式

Overview

提示词的编写方式显著影响 token 消耗。采用正确的提示模式，可将 token 消耗降低 50–90% 而几乎不影响质量。本文梳理四种技术：Chain of Draft、输出格式优化、Prompt 压缩和语义缓存。

为什么重要

随着 Agent 上下文越来越长（200K / 1M 甚至更高），token 成本成为产品商业化的隐形天花板——一次复杂对话可能轻松烧掉 $0.5+。“提示模式”层面的优化（CoD、输出格式、压缩、语义缓存）能在不改模型的情况下把成本砍 50-90%，这是规模化部署 Agent 的必修课。

Chain of Draft：推理 token 节省 92%

详见 Chain of Draft 独立文章。核心：每步推理只写约 5 个词，token 仅用 7.6%，准确率持平或超越 CoT。

推理模型注意：推理模型已内置 CoT，显式 CoT 提示仅带来 2.9–3.1% 准确率提升，不值得 10–13x token 开销。

输出格式：JSON 的 token 成本是 TSV 的 2.7 倍

相同数据，不同格式的 token 消耗对比：

格式	Token 数	相对 JSON
JSON	~19	基准
YAML	~13	-32%
TSV	~7	-63%

TOON（Token-Oriented Object Notation）

2024 年末发布，去除 JSON 语法开销同时保持机器可解析性，相比 JSON 削减 30–60% token。

Prompt 压缩：长上下文场景 20 倍缩减

LLMLingua 可将 800 token 的提示压缩到 40 token（95% 压缩率）。生产环境中保守估计 2–5 倍压缩。

权衡：

• 压缩增加预处理延迟（使用 GPT-2 等小模型）
• 实时应用可能不可接受，批处理或高流量 RAG 场景值得
• 2026 年研究发现：激进压缩可能在某些任务上导致输出 token 爆炸；代码生成对高压缩率表现良好，推理密集型任务退化更明显

语义缓存：避免重复花费已消耗的 token

语义缓存使用嵌入匹配语义相似的查询，即使措辞不同。在客服等高重复场景中，已实现最高 73% 的成本削减。

最佳策略：双层缓存——提供商级前缀缓存（稳定元素）+ 应用级语义缓存（重复查询）。

See Also

• Chain of Draft — CoD 推理方法的详细解析
• 高效表达指南 — Agent/Skill 编写的整体精简表达体系