月底账单来了，没人知道钱花在哪。这不是某家公司的个例，而是过去几年AI行业默认的运行方式：token是别人的问题。
工程团队部署越来越复杂的智能体架构。智能体调用其他智能体，那些智能体去检索文档，文档被塞进上下文窗口，监督者再对结果做综合。可观测系统盯着监督者，又有别的系统盯着可观测系统。到了月底，有人收到一张账单，但没人说得清为什么。
现在，一个叫B-TAP的机构出现了。它的全称是"Token归属与溯源局"，是Vernholt秘书处的第一个下属机构。秘书处特意指出，"第一个"这个词暗示后面还会有别的。秘书处对此不再发表评论。
它管不了你，但会盯着你
B-TAP不能强迫任何人做任何事，这一点它自己说得很清楚。它能做的是发布框架、发布指引、维护一份登记册。而登记册，才是让人开始紧张的东西。
它把AI成本监控往前推了一步。传统工具能告诉你花了多少钱，B-TAP框架建议你额外披露一件更不舒服的事：为什么花掉了这些钱。这就是"归属"的起点。
框架目前承认几大类"token税"，并反复强调：申报完全自愿。
- 上下文税：信息必须穿过活跃的模型上下文时产生。每条指令、检索到的文档、对话轮次、智能体输出、支撑材料，都占用有限的上下文并产生处理成本。
- 检索税：在信息被使用之前找到它所产生的成本。搜索、排序、重排、抓取、过滤、准备候选，这些发生在模型之外，但并不免费。
- 冗词税：信息消耗的表述量超过其有用信息量所需时产生。一份900字的架构愿景声明，审阅后可能只等于一句话——先用小模型。
- 摄入税：把信息转化成日后可用的东西所需的写入侧工作。解析、归一化、去重、分类、富化、嵌入，都有成本。
- 观察者税：你为了搞清系统为什么贵而给它装上监控，结果发现监控本身也很贵。框架对此表示遗憾。
一张对不上账的申报表
框架鼓励每个参与的AI系统每年提交一份"Token归属申报表"。它给了一个假设的申报案例，申报人叫Ken Alger，申报年度2027年。
表上列出的分项数字加起来是855.43美元，而申报的总数是782.06美元。差额来自上下文结转扣除、Schedule R的检索豁免，以及一个B-TAP拒绝解释的数字。框架表示，把归属分项与核定总额对账，"不在当前溯源标准的范围内"。负责复核的官员补充说，数学很难。
结果是，一份本该达到六位数的核定金额，被压到了表上显示的那个数。复核官员的评价是："技术上合规，但令人极度不适。"这张表上的每一项都是被允许的，包括对不上的那部分。问题恰恰就在这里。
申报的截止日期是每年的2月29日。这个日期在框架创立时就定下了，据所有留存下来的说法，当时确立框架的官员看的是一份闰年日历。错误被发现了，但纠正它需要修改创始章程，修改章程又需要确立原始章程的溯源，而这件事已经被提交给委员会了。于是截止日期仍然是2月29日——四年里有三年，这一天根本不会到来。那些年份的申报人既不算迟到，也不算准时。框架认为这可以接受。
不申报没有罚款，没有利息，没有任何法律后果。但它有更糟的东西，框架说，后面会讲到。
可以抵扣，但要留好凭证
框架承认并非每个token都是浪费的。合理且必要的上下文可以适用上下文结转扣除；确实为回答用户请求所需的检索操作，可以在Schedule R上申报。
运行多智能体系统的组织被鼓励附上Schedule AGENT，标明每个智能体、它的职责，以及为什么回答一个重置密码的问题需要十七个智能体。"智能体架构"本身不是可接受的说明，"这是框架生成的"也不是。
接下来是事情变得不那么荒诞的地方。假设一个检索智能体在一次请求中花了0.004美元，这能说明一些东西。再假设这次检索返回了20000个token，而这些token全部被送进了上下文——成本就不止0.004美元了。凭证的意义就在这里：把一次操作的真实代价，从它被埋进去的地方翻出来。
热门跟贴