Token 告警（非强迫症慎用）
在不中断任务或不声称计费准确性的前提下，追踪近似的 Token 使用量。
开始追踪
- 将任务分解为有意义的、基于结果的步骤。如果已有计划，则保留现有计划。
- 明确说明一次：Token 数值仅为估计值，不包含隐藏的系统、推理和平台开销。
- 从用户的请求中读取一个正整数告警间隔，例如
5000（对应“每 5000 token 告警一次”）。当用户请求告警但未指定间隔时，使用10000。明确说明一次当前使用的间隔。 - 将下一个告警阈值设置为一个间隔，每次告警后将其推进一个间隔。
- 不要为了改善估计值而额外调用工具、重新读取文件或生成额外内容。
报告每个完成的步骤
在报告该步骤的有用结果后，追加以下紧凑检查点：
Token 检查点 · 步骤 {n}: {名称}
当前步骤：≈{低}–{高} token | 累计：≈{低}–{高}
主要驱动因素：{最大的可观察来源}
下次节省建议：{一个可行的建议，或“没有值得改变的改进——保持当前方法。”}
仅在该步骤产生了有意义的结果时才进行计数。不要为状态消息、批准、等待或琐碎的内部操作创建检查点。
显示阈值告警
每次检查点后，将累计范围的中点与下一个告警阈值进行比较。当它达到或超过阈值时，追加以下内容：
> :red_circle: TOKEN 告警 | **{阈值} 估计 token 已使用**
使用红色圆圈加粗数字作为可移植的降级方案。如果宿主支持安全的行内 HTML 颜色，可将值渲染为 <span style="color:#d00"><strong>{阈值}</strong></span>；切勿输出原始的终端转义码。纯技能无法创建操作系统通知或保证文本颜色，因此请将其称为告警，而非系统弹窗。
如果一个步骤跨越了多个阈值，则仅发出一个针对最高跨越阈值的告警，并将下一个阈值推进到累计中点之后。切勿重复已经发出过的阈值。
一致性估算
根据该步骤处理或产生的可观察内容进行估算：
- 英文散文：大约每 4 个字符 1 个 token。
- 中文散文：大约每 1.5–2 个字符 1 个 token。
- 代码和结构化数据：大约每 3 个字符 1 个 token。
- 包括相关的提示文本、新读取的工具输出、生成的内容以及该步骤中明显复用的上下文。
- 避免在一个步骤内重复计算同一工件。
- 使用至少 ±25% 的范围；当上下文复用不明确时，扩大范围。
- 将边界四舍五入为合理的数值。优先使用
≈800–1,200，而不是≈917–1,143。 - 将步骤范围累加到累计范围中。
切勿推断隐藏的推理 token、平台指令、缓存行为、计费或货币成本。如果运行时明确提供了用量，请将其单独作为运行时实际用量报告，不要混入估算值中。
推荐节省方法
每个检查点最多给出一个推荐。针对观察到的最大可避免成本：
- 大文件读取：先搜索，然后只读取匹配的部分。
- 重复读取或搜索：复用已获得的结果。
- 宽泛的工具输出：限定路径、字段、日期范围或结果数量。
- 过大的上下文：在继续之前总结稳定的发现。
- 冗长的生成输出：在不需要细节时请求或生成更紧凑的格式。
- 重复失败：检查错误并改变方法后再重试。
- 过多的示例：除非需要比较，否则只保留一个代表性示例。
不建议仅仅为了减少 Token 而跳过验证、安全检查、必要证据或用户要求的细节。如果没有有意义的节省空间，应如实说明，而不是编造建议。
结束追踪
在任务的最终结果之后，包含一个简短的摘要：
Token 估计摘要
步骤数：{计数} | 总计：≈{低}–{高} token
最大步骤：{步骤名称} (≈{低}–{高})
告警间隔：{间隔} token | 已发出告警数：{计数}
下次运行最佳节省建议：{一个最具影响力的建议}
准确度：仅为估计值；不包含隐藏的系统、推理、缓存和平台开销。
将检查点和摘要始终置于用户实际任务之后，保持其辅助地位。