日抛软件和燃烧的Token,换回的是资产还是费用?

无招最近在钉钉的大会上抛出了一个观点——“软件正式进入日抛时代”。

图：钉钉无招在木兰年会的分享，提出软件日抛的概念

圈子里骂的人挺多，但说实话，趋势上我一定程度是认同的，AI 让做软件的成本急剧下降，在大量 Agent 场景里(比如 OpenClaw) 也确实涌现出很多用完即弃的代码。但这种极端的表达方式，经过媒体二次传播，还是产生很多误导。站在模型厂商和平台厂商的立场，把”日抛”这个故事讲得越大越好，但作为企业、作为做产品的人，听到这种声音，我还是会多想一想：

如果软件都日抛，那每天烧出去的Token，到底换回来了什么?

这个问题最近在 AI 行业很多角落都已经能看到答案了。我把最近观察到的几个现象拼一下。

一、从 Coding Plan 到 Token Plan

过去半年，几乎所有国产 AI 平台都在推 Coding Plan、阿里百炼、腾讯、智谱、Minimax等等，几十块钱包月，几千次请求，非常划算，属于养龙虾的黄金搭档。

几周前阿里的客服给我电话，说百炼的CodingPlan不能续费和升级了，提醒我一下。我当时还和客服交流，我很好奇，因为我个人的账号注册的百炼，我问他，你会给每一个个人都打电话通知这个事情吗？他说，是的。

我很无奈，但并不意外。算笔账就知道每个用户阿里会亏多少。几十块钱的月费，18000 次包月请求，每次按 1 万 Token 算，一个月就是 1.8亿 Token，如果按照Qwen3.5-Plus模型的费率来算的话，基本上成本就要超过 2000 元。而“养龙虾”，对于 Token 的消耗还是非常没有节制的，用户稍微重度一点使用，基本上一个月下来，厂商就要亏几千块。

一开始基座厂愿意亏，因为按 SaaS 时代的逻辑，亏的是获客成本，后面用户会留下。但这一轮亏完之后大家发现一个尴尬的事实——用户的粘性其实留在了 Agent 应用那一端，不在基座厂自己。用户来，是为了那只”小龙虾”,不是为了你这家平台。基座厂烧的 Token，实际上是给第三方 Agent 应用做嫁衣的获客补贴。

这就是为什么最近各家陆续把 Coding Plan 取消、改成 Token Plan——市场已经用脚投票，告诉所有人这种烧法烧出来的不是资产，是费用。”龙虾热”也在慢慢降温，留下来的是那些真正善用工具、做有价值产出的人。

这件事不是坏事,是行业在自我修正。烧Token这件事，看来也不是越多越好，得看烧出来的是什么。

二、Multi-Agent 的”表演协同”

行业在另一个角落，也在发生类似的事情。

一年半以前，我在我们供应链计划这个领域，设计过一套 multi-agent 方案。让链条上不同的角色(销售、运营、生产、财务)各分配一个 Agent，让它们之间互相 PK、协商、形成共识，在S&OP会议前，让Agent先共识一次。 当时这个想法其实还挺新鲜的，但实践下来，其实会发现这些 Agent 之间只是在表演协同而已。

其实平时从媒体上看到的宣传多智能体协同的，可能90% 以上的场景，一个 Agent 就能解决，甚至都不一定需要Agent。多 Agent 看起来像”协作”，其实大量是为了体现”先进性”在表演。

但表演是要烧 Token 的。一个任务跑 5 个 Agent 互相 review，token 消耗是单 Agent 的 几十倍，在很多场景下，它们并没有带来质量的提升，烧出去的 Token 没换回任何资产，是纯成本。

关于多智能体是不是真的能提升决策效果，最近新加坡国立大学和香港中文大学共同发表了一篇论文，讲的就是这个主题，如果你感兴趣的话，可以去搜索：多智能体系统的多样性坍塌。

Diversity Collapse in Multi-Agent LLM Systems: Structural Coupling and Collective Failure in Open-Ended Idea Generation

现在整个行业在大力推 multi-agent、long CoT、self-reflection 这些重度方案。这些技术本身没问题，问题是把它们无差别套用到所有场景。在高价值决策场景里(科研、医疗、金融等等)，多烧 50 倍 Token 换 30% 准确率提升是值得的。但在 AI 写日报、AI 生成 PPT，套路化的数据分析，这种场景里，这种重度驾驭就也可能是给自己挖坑——因为成本是真实的。

把工程逻辑直接套在市场上,往往不是聪明，而是傲慢。

三、一个小小的工程决策

最近有个开发中的小场景，一个客户每个月通过离线表格月传销售数据，各家表头格式都不一样 ——”产品代码”、”SKU 编码”、”商品 ID”，五花八门。过去要让客户按我们的模板改,体验差；现在直接让大模型去理解客户的原始表头，翻译成系统能用的结构，搞定。

第一版做完，体验很挺爽的。但我很快意识到一个问题 —— 客户每个月都上传一次，数据结构其实是固定的，这个月和上个月的表头一模一样，它只是和我们预设的表头不太一样。如果不做额外设计，系统每次都会重新调一遍模型，把同样的表头识别一遍，得到同样的答案。

所以加了一层缓存。第一次识别后存下来，后续上传先命中缓存，只有结构变了才重新跑。这个做法不复杂，但当时讨论的时候我想了挺多。

第一次让模型识别表头，这次烧的 Token 是有价值的 —— 它把一个不规则的客户输入，变成了系统能复用的结构化映射。这次烧的 Token,烧出来的是“资产“。

但如果不做缓存,第十二次还在重新跑模型，每次给出的答案跟第一次是一样的，尽管这个场景不大，但Token 是真实在烧的。这种烧法，烧出来的就是费用。

而且这两种烧法，客户在产品体验上感知不到任何区别，甚至我在加了缓存之后，下一次上传时的识别速度变得更快了。但对我们这家公司来说，成本差别巨大。

四、有人烧成了资产，有人烧成了费用

把前面三件事拼到一起看，我自己心里那把尺子大概清晰了，资产能复用、能复利;费用烧完就没了,每次都得重新烧。同样是烧 Token,这两件事完全不是一回事。最近听说硅谷一些公司在面试 AI 工程师时，直接发 1000 美金的 token quota，看候选人多快能烧完——这是用烧 Token 测能力。还有些公司鼓励员工敞开烧，谁烧得多谁奖励。这些公司不傻，他们在烧 Token 烧出人才能力 + 公司 know-how 沉淀，这两样东西能复利。

这个判断，我自己最近在用一个概念去描述它 ：

VPT，Value Per Token，每个 Token 换回来的价值。

这不是一个精确的会计指标，它甚至不需要算到小数点后几位 —— 判断到数量级就够用了。一次复杂的供应链规划决策，可能消耗几十万Token，但产出的决策价值在万元甚至十万元级别，VPT极高。

有些所谓的“日抛软件”，每天消耗几百万Token，做的是同样套路的数据分析，或者是可能老板也不愿意自己看的日报，VPT 接近于零。这中间是几个数量级的差距，根本不需要精确测量，粗略一估就知道账算不算得过来。

把这把尺子放大，你会发现它适用于很多层面：

• 看产品设计：同一个功能,设计得好(做缓存、做沉淀)是高 VPT，设计得不好(每次重跑)就是低 VPT。
• 看工程范式：Multi-Agent 在高价值决策场景里可能 VPT 高，但多数用一个Agent 就能解决的场景，那它们的 VPT也是趋零。
• 看公司战略：ChatGPT/豆包 烧 Token 烧出了数据 + 用户习惯 + 品牌，这些能复利，长期 VPT 是正的；早期 Coding Plan 烧 Token 烧的是给 Agent 应用做嫁衣的获客补贴，VPT 是负的，所以市场最终会修正。
• 看个人和团队：用 Token 学习、做研究、沉淀方法论，VPT 高；用 Token 重复跑你自己都不会看的内容，VPT 趋零。

这件事再往下推,其实有一个更有意思的问题——为什么整个行业在大力推那些 VPT 不高的工程范式?这背后可能不只是工程问题,可能是利益结构的问题。这个想法我还没想清楚,改天再聊。

软件本身可以日抛，Token也可以烧，但如果连“这次烧的Token换回来的是什么”都不去问，那就是把自己变成了模型厂商的的提款机。

所以我相信你也能理解，我讲这个故事不是看衰 Agent，而是真正希望它能够被大规模、持久的地应用在价值更高的场景下。

如果你对我写的内容感兴趣，欢迎一键三连、转发给朋友。

如果您想要有更多的交流，我也有组建 AI 交流群，可以加我，我邀请您进群。