昨天凌晨两点半，线上告警把我从床上拽起来。某个Agent服务的计费系统显示用户余额扣了，但任务执行记录里找不到对应的调用事务。两边数据对不上，用户开始投诉。我翻了一遍服务日志，发现问题是自研的Agent调度器在工具调用链路上挂了重试逻辑——用户的一次请求触发了三次LLM调用，但计费系统只认最后一次成功响应的token数，再把中间过程产生的超额输入token直接吞了。这看起来是个计费bug，实际上暴露的是Agent产品化的根本矛盾：你卖的不是一次API调用，而是一个带着不确定性的“尽力而为”的结果，但商业模型要求你把它包装成确定性的可计量服务。这可能是Agent从demo走向产品时最容易被忽视的陷阱。技术侧搞定了Prompt编排、长记忆、多工具协同，觉得只要把模型跑通就有商业价值。真到了收费的那一天，你会发现LLM只是成本里最刺眼的那一部分，更可怕的是那些看不见的碎钞机。比如为了支持用户一句“帮我把上周的销售数据整理成PPT”，Agent内部可能跑了三条链路：先解析意图，再查询数据库，然后调用一个画图的工具，中间每一步都有模型参与，每一步都在烧钱。更麻烦的是，模型有随机性，同一个问题可能今天走三步完成，明天抽风走了七步，其中还有四步是自我纠错。这种波动性让传统的按请求计费变得极其脆弱。我见过一个团队，按单次对话收费，用户提问题，Agent干活，收一块钱一次。结果上线一周亏损惨重。因为用户的问题复杂度差异极大，某些复杂任务会触发几十轮内部推理，成本直逼三块钱，而简单任务是五毛钱成本。均摊下来他们每单倒贴两毛。后来他们改成按会话轮数收费，效果也不理想。因为Agent会在后台自动重试、自我修正，这些都不算用户感知的对话轮数，但都是成本。真正能支撑商业模式的设计，必须让计费口径和Agent的实际资源消耗强相关，同时又要让用户觉得这个价格对应的