一个 token 计数器不是成本透明。
给用户看"142,000 tokens"，没有告诉他任何可以据以行动的东西，因为没人拿 token 做预算——而多数团队接着会发的那个界面，一个不带任何控制件的滚动金额，还要更糟：它制造的是一份带数字的焦虑。成本交互设计要奏效，那块表必须以用户自己选定的单位计价、连着一个他够得到的控制件，并在事后与你当初告诉他的价格对上账。
用什么单位计价，就是全部的设计问题。
你展示的单位决定了这个数字是信息还是噪音。token 是厂商的单位；美元是财务的单位；两者都不是用户的单位。用户的单位是他要的那个东西——一份报告、一个迁移完的文件、一份审过的合同、一小时的调研——而每一个有用的成本界面都以它计价。
- 差："已用 142,000 tokens。"无法解读。用户判断不出这算多还是算少。
- 好一点："本次运行 $0.94。"可以解读，但没有锚——比什么多，比什么少？
- 好："$0.94——约为一份普通报告的 3 倍，因为它检索了 40 个来源，而通常是 12 个。"锚在一个基线上，并归因到一个用户能改变的原因上。
第三种是唯一一种能让用户做点什么的形式。而且它并不额外增加你的成本：这个任务类的运行中位数你已经从单位经济里拿到了，那个驱动因素就在轨迹里。
三个界面，三份不同的差事。
成本会在三个时刻出现，而每一个都需要不同的设计。团队们通常只造中间那个，而它恰恰是三个里单独拿出来最没用的。
- 运行前的估价。它的差事是取得同意。它出现在用户做出承诺的地方——与任何其他确认同一个位置——而且它是三者中唯一一个能阻止开销、而不只是叙述开销的。
- 运行中的仪表。它的差事是控制，不是信息。一个没有停止按钮的实时计数器是一场压力测试，不是一项功能。如果用户对它无法行动，就别显示它。
- 运行后的账单。它的差事是校准——教会用户他的哪些请求是贵的，好让下一次的估价可信。这是几乎没人去造、却会不断复利的那个界面。
如果只能造一个，造那份账单。在用户有理由相信估价之前，估价一文不值；而这份相信来自见过十几次预测与结果被对上账。一个展示估价却从不对账的产品，等于教会了用户忽略估价。
估价是一份承诺，所以要设计那个区间，并信守它。
智能体的成本是重尾的：同一个请求，可能花中位数，也可能花中位数的二十倍，取决于循环走了多少步。在重尾分布上给一个点估计，是一份你必定会毁掉的承诺，而用户对一份被毁掉的成本承诺的体验，是"计费出错"，而不是"建模有极限"。
- 给区间，不给点。"通常 $0.60–$1.10"是诚实的，用户也容忍得了。"$0.85"后面跟着一笔 $4.20 的账，是一张工单。
- 用一个真实的上限把区间封住。区间的顶端应当在请求路径上被强制执行，而不是一种愿望。一个上限不是限制的估价，是穿着承诺外衣的猜测。
- 每一次超出都在发生的当下解释，用那个驱动因素的话来说："这次跑得久，是因为文档有 340 页。"超支期间的沉默，正是把一个成本界面变成一个信任问题的东西。
- 让用户能预先选择便宜的那条路。"快速一遍（$0.20）还是彻底一遍（$1.40）？"是比任何上限都更好的成本控制，因为用户是在权衡摆在眼前的情况下做的选择。
每一块仪表都需要一个够得到的控制件。
一个在用户眼皮底下往上涨、而他什么也做不了的数字，是这份手册里最糟的界面——它让产品显得贵，却没让它变便宜。给每一块实时仪表至少接上其中一个：
- 停下，并保留已有成果。最有价值的控制件，也最难做，因为它要求智能体能够返回半成品。如果一次运行无法被有用地打断，那是成本界面暴露出来、而不是制造出来的架构问题。
- 降档。以更便宜的配置继续——小一号的模型、更少的来源、更窄的范围。在把曲线掰弯的同时保住结果。
- 批准后继续。一个软上限，它暂停并询问，而不是直接失败。这是渐进自主的模式，只是作用在预算而非权限上。
请注意它与服务端控制件的不对称。你的急停开关保护的是业务免于一次失控；这个控制件保护的是用户免于一次意外。它们在不同的阈值上、为不同的人触发，谁也替代不了谁。
教人的额度，与罚人的额度。
多数智能体产品都需要一个按用户或按租户的上限。"用户绕着走的那种"与"用户照着规划的那种"，设计上的差别全在边界附近发生了什么。
- 用用户的单位展示剩余预算，而不是某个不透明池子的百分比。"这个月大约还能出 14 份报告"是能规划的；"额度剩余 72%"不是。
- 按趋势告警，而不是按阈值。"照这个速度，你会在 22 号前后用完"到来时，还有决定可做。90% 时的告警，到来时那个导致它的行为已经发生了。
- 先降级，再拒绝。接近上限时，切到更便宜的配置并明说。拿到一个更慢更便宜答案的用户会继续干活；撞上一堵墙的用户会开工单或者找绕道。
- 绝不静默地降级到更差的模型。为了不超预算而悄悄降低质量，是唯一一个会永久摧毁信任的动作，因为用户体验到的是"产品无缘无故变差了"。见为信任而设计。
用哪个指标判断你有没有做对。
最顺理成章的成功指标是开销下降了。它是错的，而且照着它优化，会做出一个悄悄压制自己最有价值用例的产品。
失败模式是这样的。由财务发起的成本交互设计会变成一个劝退界面：每一个贵的动作都被挂上警示，用户学会了"彻底"那条路是不被鼓励的那条，用量于是转向便宜的那条。开销下降了，看板很好看——而实际发生的是，那条回报 55 倍的工作流，和那条在亏钱的工作流一起被掐住了，因为用户看得见成本，看不见价值。你在一块屏幕的尺度上，原样复制了那个让组织去砍掉整个部署而不是单个工作负载的不对称。
改去量校准度：用户对一个请求要花多少钱的预测，与结果对得上吗？这个差距会随使用而收窄吗？一个造得好的成本界面，应该让"贵但值得"的运行变得更笃定，而不是更犹豫。去追踪估价与实际之间的误差、用户在多大比例上是动用了控制件而不是干脆放弃，以及高价值的贵工作流在上线之后有没有守住自己的用量。
先发那份账单，用用户自己的单位，附上那个解释了差异的唯一驱动因素——那是一周的活，效果却胜过人人都在造的实时仪表。然后在承诺点加上一个区间形状的估价，并把区间的顶端作为真实上限强制执行。在实时计数器接上"停止"或"降档"之前，不要发它；一个无法据以行动的数字比没有数字更糟，而它恰恰是这个品类里最常被发出去的东西。
相关：智能体成本控制——你正在展示的那些数字背后的杠杆；成本归因——首先怎么拿到按次运行的成本；以及等待与延迟的交互设计——用户在一次运行中盯着的另一块表。