pjt222 管理 Token 预算
通过追踪每次循环的 token 使用量、审计上下文空间消耗、执行预算上限、在压力下修剪低价值上下文，以及在加载完整流程之前通过元数据路由，来控制智能体系统的成本和上下文占用。核心原则：上下文窗口中的每个 token 都应该赚得它的位置。为决策提供信息的 token 留下；占用空间但不影响输出的 token 被修剪。
社区案例：一个 37 小时的自主会话花费 13.74 美元，原因是 30 分钟的心跳间隔加上冗长的系统指令和不受控制的上下文积累。修复方案是将心跳改写为 4 小时间隔，切换到仅通知模式，并从循环中消除订阅浏览。此技能固化了防止此类事件的模式。
适用场景
- 运行长时间智能体循环（心跳、轮询周期、自主工作流），成本随时间复利增长
- 上下文窗口在执行循环间不可预测地增长
- API 成本超出预期基线，需要事后分析
- 设计新的智能体工作流并希望从一开始就内置成本护栏
- 成本事件发生后审计出错原因并防止再次发生
- 系统提示、记忆文件或工具模式变得足够大，主导了上下文窗口
输入
- 必需：要预算的智能体系统或工作流（运行中或计划中）
- 必需：预算上限（每个周期的美元金额，或每次循环的 token 限制）
- 可选：当前成本数据（API 日志、计费仪表板导出）
- 可选：目标模型的上下文窗口大小（默认：查阅模型文档）
- 可选：可接受的降级策略（达到限制时可以丢弃什么）
步骤
第 1 步：建立每次循环的成本追踪
在每个执行边界记录 token 使用情况的智能体循环工具。
对于每次循环（心跳、轮询、任务执行），捕获：
- 输入 tokens：系统提示 + 记忆 + 工具模式 + 对话历史 + 新用户/系统内容
- 输出 tokens：模型响应（包括工具调用）
- 总成本：输入 tokens × 输入价格 + 输出 tokens × 输出价格
- 循环时间戳：循环运行的时间
- 循环触发：什么触发了它（定时器、事件、用户操作）
将这些存储在结构化日志中（JSON lines、CSV 或数据库）——而非上下文窗口本身：
{"cycle": 47, "ts": "2026-03-12T14:30:00Z", "trigger": "heartbeat",
"input_tokens": 18420, "output_tokens": 2105, "cost_usd": 0.0891,
"cumulative_cost_usd": 3.42}
若系统没有工具，从 API 计费估算：
- 总成本 / 循环次数 = 每次循环平均成本
- 与预期基线对比（模型定价 × 预期上下文大小）
预期结果： 显示每次循环 token 数量和成本的日志，足够细粒度以识别哪些循环昂贵及原因。日志本身位于上下文窗口之外。
失败处理： 若无法获得精确 token 数量（某些 API 不返回使用元数据），使用计费仪表板推导平均值。即使是粗略追踪（每日成本 / 每日循环次数）也能揭示趋势。若完全无法追踪，进入第 2 步从上下文审计入手——你可以从上下文大小估算成本。
第 2 步：审计上下文窗口
测量上下文窗口中消耗了什么，并按大小排名消耗者。
将上下文分解为其组成部分并测量每个：
- 系统提示：基础指令、CLAUDE.md 内容、个性指令
- 记忆：MEMORY.md、通过自动记忆加载的主题文件
- 工具模式：MCP 服务器工具定义、函数调用模式
- 技能流程：为活跃技能加载的完整 SKILL.md 内容
- 对话历史：当前会话中的先前对话轮
- 动态内容：当前循环中的工具输出、文件内容、搜索结果
生成上下文预算表：
Context Budget Audit:
+------------------------+--------+------+-----------------------------------+
| Component | Tokens | % | Notes |
+------------------------+--------+------+-----------------------------------+
| System prompt | 4,200 | 21% | Includes CLAUDE.md chain |
| Memory (auto-loaded) | 3,800 | 19% | MEMORY.md + 4 topic files |
| Tool schemas | 2,600 | 13% | 3 MCP servers, 47 tools |
| Active skill procedure | 1,900 | 9% | Full SKILL.md loaded |
| Conversation history | 5,100 | 25% | 12 prior turns |
| Current cycle content | 2,400 | 12% | Tool outputs from this cycle |
+------------------------+--------+------+-----------------------------------+
| TOTAL | 20,000 | 100% | Model limit: 200,000 |
| Remaining headroom |180,000 | | |
+------------------------+--------+------+-----------------------------------+
标记相对于其决策价值不成比例大的组件。当前任务从未引用的 4,000 token 记忆文件是纯开销。
预期结果： 排名表格，显示每个上下文消耗者、其大小和占窗口的百分比。至少一个组件将作为减少候选脱颖而出——最常见的是对话历史或冗长的工具输出。
失败处理： 若无法获得每个组件的精确 token 数量，使用字符数 / 4 作为英文文本的粗略近似。对于结构化数据（JSON、YAML），使用字符数 / 3。目标是相对排名，而非精确测量。
第 3 步：设置带执行策略的预算上限
定义硬限制和软限制，并指定达到每个限制时会发生什么。
软限制（警告阈值）：通常为硬限制的 60-75%。触发时：
- 记录带当前使用量和剩余预算的警告
- 对最低价值上下文开始自愿修剪（第 4 步）
- 若适用则降低循环频率（例如心跳间隔从 30 分钟到 2 小时）
- 以降级上下文继续操作
硬限制（停止阈值）：绝对最大支出或上下文大小。触发时：
- 立即停止自主操作
- 向人工操作员发送警报（通知、邮件、日志条目）
- 保存当前状态摘要以便恢复
- 在人工审查和授权之前不开始另一个循环
每次循环上限：任何单次循环的最大 token 或成本。防止单个失控循环消耗整个预算：
- 若循环会超过上限，截断工具输出或跳过低优先级操作
- 记录截断以供事后分析
在工作流配置中记录上限：
token_budget:
soft_limit_usd: 5.00 # warn and begin pruning
hard_limit_usd: 10.00 # halt and alert
per_cycle_cap_usd: 0.50 # max per individual cycle
soft_limit_pct: 70 # % of context window triggering pruning
hard_limit_pct: 90 # % of context window triggering halt
enforcement: strict # strict = halt on hard limit; advisory = log only
alert_channel: notification # how to notify the operator
预期结果： 在三个级别（软限制、硬限制、每次循环）有记录的预算上限，每个都有明确的执行操作。策略回答"达到限制时会发生什么？"在达到限制之前。
失败处理： 若设置精确美元限制为时过早（成本状况未知的新工作流），先仅设置上下文百分比限制（软限制 70%，硬限制 90%），在 24-48 小时的成本追踪数据后添加美元限制。在校准期间，建议模式（记录但不停止）是可接受的。
第 4 步：实施紧急修剪
接近限制时，系统性地丢弃低价值上下文以保持在预算内。
修剪优先顺序（先丢弃最低价值的）：
- 旧工具输出：来自已做出决策的先前循环的冗长搜索结果、文件内容或 API 响应。决策持续存在；证据可以丢弃。
- 冗余对话轮：被后来的修正或改进所取代的早期轮次。若第 3 轮要求 X，第 7 轮将其修改为 Y，第 3 轮是多余的。
- 冗长格式：工具输出中的表格、ASCII 艺术、装饰性标题。用一行描述输出包含的内容来替代。
- 已完成子任务的上下文：对于多步骤任务，已完全完成且输出已在摘要或文件中捕获的子任务上下文。
- 不活跃的技能流程：若某技能是为先前步骤加载的但不再被遵循，其完整流程文本可以丢弃。
- 与当前任务无关的记忆部分：关于不相关项目或过去会话的自动加载记忆。
对每个修剪的项目，保留一行墓碑：
[PRUNED: 2,400 tokens of npm audit output from cycle 12 — 3 vulnerabilities found, all patched]
墓碑花费约 20 个 token，但保留了与决策相关的结论。
预期结果： 修剪后上下文窗口使用量降至软限制以下。每个修剪的项目都有保留其结论的墓碑。没有关键决策信息丢失——只有已做决策背后的证据。
失败处理： 若修剪到第 4 优先级后使用量仍超过软限制，工作流从根本上对当前循环频率来说上下文太重。向人工操作员升级："在修剪后上下文使用量为 N%。选项：(a) 增加循环间隔，(b) 减少每次循环范围，(c) 拆分为子工作流，(d) 接受更高成本。"
第 5 步：集成渐进式披露以加载技能
在加载完整技能流程之前通过注册表元数据路由——在路由上花费 token，而非在阅读上。
该模式：
- 先路由：当任务需要技能时，从
_registry.yml读取技能的注册表条目（id、描述、领域、复杂度、标签）——大约 3-5 行，约 50 个 token - 确认相关性：注册表描述是否符合当前需求？若不，检查下一个候选。每次未命中花费约 50 个 token，而非加载错误 SKILL.md 的约 500-2000 个 token
- 匹配时加载：仅在注册表条目确认相关性时，加载完整的 SKILL.md 流程
- 使用后卸载：技能流程完成后，完整文本可以修剪（第 4 步，优先级 5）——只保留完成内容的摘要
对其他大型上下文有效载荷应用相同模式：
- 记忆文件：先读取 MEMORY.md 索引行；仅在主题相关时加载主题文件
- 工具文档：使用工具名称和一行描述路由；仅为正在调用的工具加载完整模式
- 文件内容：先读取文件列表和函数签名；仅为正在修改的函数加载完整文件内容
不使用渐进式披露：
加载 5 个候选技能 → 5 × 1,500 tokens = 7,500 tokens → 使用 1 个技能
使用渐进式披露：
通过 5 个注册表条目路由 → 5 × 50 tokens = 250 tokens
加载 1 个匹配技能 → 1 × 1,500 tokens = 1,500 tokens
总计：1,750 tokens（减少 77%）
预期结果： 技能加载遵循两阶段模式：通过元数据进行轻量级路由，然后仅在确认匹配后完整加载。相同模式应用于记忆、工具模式和文件内容（在适用时）。
失败处理： 若注册表元数据不足以路由（描述太模糊，标签缺失），改进注册表条目而非放弃渐进式披露。修复方案是更好的元数据，而非更多的上下文加载。
第 6 步：设计成本感知的循环间隔
根据成本数据设置执行间隔，而非任意计划。
计算当前循环间隔的每小时成本：
cost_per_hour = avg_cost_per_cycle × cycles_per_hour- 示例：每小时 2 次循环，每次循环 $0.09 = 每小时 $0.18 = 每天 $4.32
与预算对比：
hours_until_hard_limit = (hard_limit - cumulative_cost) / cost_per_hour- 若 hours_until_hard_limit < 预期运行时间，延长循环间隔
确定最小有效间隔：
- 被监控系统中变化的最快速率是多少？若数据源每 4 小时更新一次，每 30 分钟轮询会浪费 7/8 的循环
- 将循环间隔与数据的刷新速率匹配，而非对错过事件的焦虑
- 对于事件驱动的系统，尽可能用 webhook 或推送通知替代轮询
应用间隔：
之前：30 分钟心跳，冗长处理
→ 每天 48 次循环 × $0.09/循环 = 每天 $4.32
之后：4 小时心跳，仅通知
→ 每天 6 次循环 × $0.04/循环 = 每天 $0.24
→ 减少 94% 成本
预期结果： 循环间隔由成本数据证明合理，并与被监控系统的刷新速率匹配。间隔-成本权衡已记录，以便未来调整有基准。
失败处理： 若系统需要低延迟响应且无法承受更长间隔，改为降低每次循环成本（更小的系统提示、更少的工具模式加载、摘要历史）。预算方程有两个杠杆：频率和每次循环成本。
第 7 步：验证预算控制
确认所有控制都在工作，系统在预算内运行。
- 追踪验证：运行 3-5 次循环，验证每次循环日志记录了准确的 token 数量
- 软限制测试：临时降低软限制，验证警告触发且修剪开始
- 硬限制测试：临时降低硬限制，验证系统停止并发出警报
- 每次循环上限测试：注入大型工具输出，验证它被截断而非超出上限
- 渐进式披露测试：追踪技能加载序列，确认它在加载完整 SKILL.md 之前通过注册表路由
- 成本预测：从验证数据，预测：
- 当前设置下的每日成本
- 当前消耗速率下到达硬限制的天数
- 预期月度成本
Budget Validation Report:
+-----------------------+----------+--------+
| Check | Expected | Actual |
+-----------------------+----------+--------+
| Per-cycle logging | Present | |
| Soft limit warning | Fires | |
| Hard limit halt | Halts | |
| Per-cycle cap | Truncates| |
| Progressive disclosure| Routes | |
| Daily cost projection | < $X.XX | |
+-----------------------+----------+--------+
预期结果： 五个控制（追踪、软限制、硬限制、每次循环上限、渐进式披露）全部验证工作正常。成本预测在预期预算内。
失败处理： 若控制未触发，检查执行机制是否接入了实际执行循环，而非只是记录在文档中。没有执行的配置只是计划，不是控制。若成本预测超出预算，返回第 6 步调整循环间隔或每次循环成本。
验证清单
- 每次循环成本追踪为每次循环记录输入 tokens、输出 tokens、成本和时间戳
- 上下文窗口审计识别所有消耗者及大致 token 数量和百分比
- 预算上限在三个级别定义：软限制、硬限制和每次循环上限
- 每个上限都有明确的执行操作（警告、修剪、停止、警报）
- 紧急修剪遵循优先顺序并保留墓碑
- 渐进式披露在加载完整内容之前通过元数据路由
- 循环间隔由成本数据证明合理，并与被监控系统的刷新速率匹配
- 验证测试确认所有控制正确触发
- 成本预测在定义的预算内
- 事后分析：已识别根本原因，有具体的预防措施
常见问题
- 在上下文窗口中追踪：将每次循环日志存储在对话历史中会膨胀你试图控制的东西。在外部记录（文件、数据库、API），上下文中只保留当前摘要。
- 没有执行的软限制：没有人看到的警告不是控制。软限制必须触发可见操作——修剪、间隔延长或操作员通知。若系统可以静默超过软限制，它就会这样做。
- 在决策之前修剪数据：在决策做出之前丢弃工具输出会丢失信息。在告知决策的证据被使用之后修剪，而非之前。墓碑模式在丢弃证据的同时保留结论。
- 将循环间隔与焦虑匹配，而非数据刷新：每 30 分钟轮询一个每 4 小时更新的源会浪费 87.5% 的循环。在设置间隔之前测量数据源的实际刷新速率。
- 为路由加载完整技能：读取 400 行 SKILL.md 以决定"这是正确的技能吗？"比读取 3 行注册表条目贵 10-20 倍。先通过元数据路由；仅在确认匹配后加载流程。
- 忽略系统提示：系统提示、CLAUDE.md 链和自动加载的记忆是不可见的成本——它们在每次循环都会支付。一个 5,000 token 的系统提示在每天 48 次循环的循环中，仅指令就花费每天 240,000 个输入 tokens。先审计和裁剪这些。
- 没有人工升级的预算上限：达到预算限制并静默降级（而非警报人工）的自主系统可能积累损害。硬限制必须包含人工通知渠道。
相关技能
assess-context— 评估推理上下文的结构健康；补充第 2 步中的上下文窗口审计metal— 从代码库提取概念本质；渐进式披露模式适用于 metal 的探勘阶段chrysopoeia— 价值提取和死重量消除；在代码层面应用相同的每 token 价值思考manage-memory— 组织和修剪持久化记忆文件；直接减少上下文预算的记忆组件