产品 01
为智能体省下
每一次思考。
TokenBurn 是智能体运行时的成本层。它不改变你的任务，只改变完成任务的价格。
上下文会重复，模型会错配，成本会失控。
一个多智能体任务，通常会把同一段历史复制很多遍：规划者读一遍，执行者读一遍，复核者再读一遍。工具返回的结果层层叠加，真正被用到的部分越来越少。
同时，绝大多数步骤并不需要最贵的模型。把简单判断交给前沿模型，是另一端的浪费。
问题不是单个请求太贵，而是结构上重复。
- 重复上下文同一段历史在规划、执行、复核之间被复制多遍。
- 模型错配简单判断交给最贵的模型，困难步骤反而没有预算。
- 成本不可见账单按天汇总，无法定位到任务和智能体。
四个动作，发生在每一次请求之前。
01
观察
识别任务类型、上下文结构，以及每一步真正需要的信息。
02
压缩
保留语义，丢掉重复、过期和无关的内容。
03
路由
按难度和成本，把请求交给合适的模型。
04
预算
为任务设定上限，在超支之前先做取舍。
压缩的是上下文，不是任务。
TokenBurn 以任务成功率为约束，而不是以压缩率为目标。下面是一个结构示意。
原始上下文
任务所需
示意图，非实测数据。蓝色为保留内容，灰色为被丢弃内容。实际策略会随任务类型和模型窗口调整。
目标不是把上下文压到最短，而是在不改变结果的前提下，去掉不该被重复付费的部分。
能力
- 语义压缩保留任务需要的语义，丢掉重复、过期和无关的上下文。
- 上下文预算为每个任务设定 Token 上限，在超支之前先做取舍。
- 模型路由简单步骤交给更便宜的模型，困难步骤才升级。
- 成本可观测按会话、任务和智能体拆解消耗，知道钱花在了哪里。
- 接入方式测试中的网关与 SDK。具体接口会在第一批接入中确定。
现在可以做什么。
TokenBurn 处于内测阶段。我们正在和第一批团队一起确定接入方式、评估指标和计费模型。
如果你有长上下文或多智能体任务，欢迎一起做一次基线测量：用你现在的任务，量出当前的 Token 结构和成本，再判断值不值得优化。
会改变任务结果吗？
我们的目标是保持任务结果不变。压缩策略以任务成功率为约束，内测阶段会先建立基线，再逐步调整。
支持哪些模型？
模型无关。路由层按任务和成本选择模型；具体支持列表会在内测中确定。
数据会离开我的环境吗？
内测阶段提供网关和本地部署两种形态。具体的数据边界会在接入时确认。
怎么开始？
发邮件说明任务类型、平均上下文长度和当前使用的模型。我们会安排一次基线测量。