16 篇博文 含有标签「unit-economics」

财务在月底打开发票。一个供应商。一个数字。它比上个月大，而且下个月还会更大。然后他们提出了唯一重要的问题 —— 这是哪个功能花的钱？ —— 房间里没人能回答。

这是在生产环境中运行 AI 的一种隐蔽失败模式。并不是说账单数额巨大；如果价值匹配，数额大也没关系。失败之处在于账单是无法归因的。它作为一个单一的费用项出现 —— OpenAI、Anthropic、Bedrock、Azure —— 没有任何财务部门真正需要的维度：没有按功能、按团队、按客户，也没有按成功的任务进行拆分。你能看到总额在上升。但你看不出 原因，而当发票寄到时，原本可以解释它的请求上下文早已消失了。

大多数财务团队都把第一张 LLM 账单放错了地方。它出现在实验阶段，当时只有少数工程师正在使用 API 密钥进行原型设计，它看起来确实就是当时的样子：研发支出 (R&D)。每月花费几千美元来弄清楚这项技术是否可行。因此，无论是在认知上还是在实际操作中，它都被归入了研发支出，没有人对此深究。

随后，功能上线，使用量攀升，第一季度还是可以忽略不计的误差项，到了第四季度就变成了云服务账单中增长最快的成本。问题从来不在于金额大小。问题在于成本已经悄然改变了类别——从对构建某项功能的固定投入，变成了服务每一位用户的变动成本——而思维模型却没有随之转变。

这种分类错误是目前 AI 产品中最昂贵的会计错误，而且它本质上甚至不是会计错误，而是预测错误。

某平台发布了一个针对长耗时智能体（agent）任务的 30 分钟实际时间上限，并配套了一项退款政策：任何达到超时上限且未产生交付成果的任务，其消耗的 token 费用将予以退还。其初衷是保护性的：挂起的智能体不应向客户收费。六个月后，超时率翻了一番，工程团队深陷“智能体可靠性”调查，而支持队列中挤满了抱怨智能体“不断超时”的用户——截图显示，用户的浏览器标签页在 29 分多钟时就被关闭了。

在财务模型从未命名的行为群体中，单位经济效益已悄然倒挂。退款人群并非质量不佳的人群。这是一种策略。

在部署后的一个季度，AI 团队报告单次 API 调用平均成本降低了 25%。支持团队报告 AI 分流工单的平均处理时间从 4 轮增加到了 7 轮。这两个数字都是正确的。两个团队都在测量他们被要求优化的系统。夹在中间的财务团队无法核对仪表盘，因为这两个指标都不是以客户实际支付的东西来衡量的：一个已解决的工单。单次调用成本下降了，而单次任务解决成本上升了 40%。由于没有团队负责这个指标，所以没人注意到它的变动。

这是我在智能体（agentic）部署中见到的最常见的单位经济效益（unit-economics）失败，而且这不是一个测量上的 Bug，而是一个定义上的 Bug。供应商的价格页面展示了单次调用成本，因为这是他们计费的单位。由于电子表格的单元格刚好放得下，这个单位就被继承到了表格中。工程团队针对给定的单位进行优化。等到 API 经济与业务经济之间的鸿沟变得清晰可见时，这种影响已经累积了一个季度，而智能体整个时间都在基于错误的损失函数（loss function）被悄悄训练。

你的 AI 功能成本预测是基于一个 50 人的试点项目建模的。那些用户输入了三句话的提示词，因为那是人们在被要求评估测试版时通常会输入的内容。产品上线了，你突破了一万名用户，财务团队指出你的模型账单是计划书中人均成本的三倍。你去寻找 Bug。但根本没有 Bug。你的试点项目是从一个分布中采样，而生产环境是从另一个分布中采样，两者的区别在于一个长尾用户群——他们是在 Twitter 上了解到你的产品，并粘贴了从推文中截取的 30 KB 非结构化上下文。

这是每家消费级互联网公司在 2010 年代都吸取过的同样财务教训，现在被移植到了 LLM 经济学中。试点项目的中位数用户并非生产环境中的 p99.5，而一个使用平均值作为预测输入的 Token 成本模型，在面对账单时注定会一败涂地。

失败的智能体（Agent）运行成本很低。它可能会误导查询、陷入死胡同、返回“我无法提供帮助”，而执行这些操作可能只消耗几百个 Token。但成功的运行却是一场“灾难”。它检索上下文、进行反思、调用三个工具、再次反思，最后缝合出一个自信的、长达数段的答案——其 Token 消耗是那些几乎不花钱的失败运行的五十倍。

这就是智能体经济学中令人不安的现状：你的理想路径（Happy Path）就是你的高昂路径。你所销售的结果，也就是你在营销页面上承诺的、用户为此向你致谢的结果，正是你的系统所能执行的最昂贵的操作。如果你按照过去十五年 SaaS 的定价方式——按每个席位收取固定月费——那么智能体每出色地完成一次工作，都在悄悄侵蚀你的利润。

大多数团队是后知后觉才发现这一点的。他们观察成本仪表板，看到失败的成本很低，便得出结论：提高可靠性将节省资金。事实并非如此。提高成功率只会增加你的账单。

财务部门对你发布的每个功能都会问一个问题：“每个用户的成本是多少？”对于传统功能，答案是一个数字。页面渲染、数据库查询、推送通知 —— 每一个的边际成本在不同请求之间几乎没有波动。你测量一次，乘以用户数量，预测就能成立。

AI 功能打破了这种契约。问一下“这个智能体（agent）每次请求的成本是多少”，坦诚的回答不是一个数字，而是一张直方图。同一个智能体，处理上一个工单可能只花 2 美分，但在处理下一个工单时可能会烧掉 4 美元。因为用户问了一个模糊的问题，智能体循环调用了 11 次工具，而每次调用都将不断增长的对话全文重新输入模型。这两次请求的平均值 —— 2 美元 —— 既无法描述其中任何一次请求，更无法真实反映最终账单。

这就是陷阱。当你向财务提交一个单一的平均成本时，你并不是在简化混乱的现实。你是在报告一个在特定的、昂贵的方向上完全错误的数字。

一次 10 轮的对话成本并不是单轮对话的 10 倍，而是接近 55 倍。这是大多数团队在建模 AI 功能的单位经济效益（unit economics）时最容易犯的错误，也是为什么一个在表格上看起来有利可图的产品在生产环境中却在不断亏钱的原因。

错误在于将对话视为一系列独立的请求。事实并非如此。由于 LLM API 是无状态的，每一轮对话都会重新发送累积的全部历史记录。第一轮发送 1 个单位的上下文，第二轮发送 2 个，第十轮发送 10 个。整个会话中计费的总 Token 数是 1 + 2 + ... + N 的总和，其增长趋势为 N²/2 —— 即平方级增长 —— 而你的产品几乎肯定收取的是固定的线性价格。

那些最喜欢你产品的用户，正是那些进行最长对话的用户。他们也是在悄无声息中摧毁你利润空间的人。

一个智能体订错了机票。它给错误的客户发送了道歉邮件。它编写了一个数据库迁移脚本，删掉了一个仍有三个服务在读取的列。在每种情况下，模型都生成了一个看起来合理的动作，执行了它，然后继续运行。而在每种情况下，都有人承担了真实的代价——改签费、受损的关系，或是凌晨 2 点的故障排查。

令人不安的地方在于：大多数 AI 产品对于“谁来承担代价”这个问题没有答案。在设计评审中，这个问题从未被提及。它在以后才会显现，以支持工单的形式，一个接一个地出现在支持队列中——因为客户听起来很生气，而客服代表没有可以遵循的政策，只能即兴提供 40 美元的额度。将此乘以每月几千张工单，单位经济效益就会悄然腐烂——不是因为一次戏剧性的失败，而是因为一个无人关注的缓慢漏洞。

“模型犯了错”不只是一个支持升级。它是一个计费事件。而在智能体时代生存下来的产品，将是那些在收到第一张愤怒的工单之前就为这类事件做好了设计的产品，而不是那些靠感觉即兴退款，直到毛利变为负值的产品。

每个人都在看的成本仪表盘是一个周滚动平均值，而那个平均值正在对你说谎。并不是说数字本身是错误的——它是计费事件流的忠实算术平均值——而是它隐藏了底层的成本曲线形态。周五晚上到周一早上之间的 token 消耗方式，与周二上午 10 点到周四下午 4 点之间截然不同。周六凌晨 3 点活跃的群体与周二上午 11 点活跃的群体并非同一拨人，这些群体的单用户经济效益（per-user economics）差异巨大，但没人记录这一点，因为仪表盘通过平均值将其抹平了。

大多数团队第一次发现这一点，是在周末自动化脚本烧光预算的时候。一个 LangChain 智能体在周五晚上陷入了无限对话循环，运行了大半周才被人发现，导致产生了一张五位数的账单，周一早上不得不向财务部门解释。事后回顾将其视为一次性事件——糟糕的重试逻辑、缺失的预算上限、没有触发值班报警。但是，那个隐藏了失控循环的仪表盘，同时也隐藏了同一现象的稳态版本：每周都会出现的非工作时间流量基准，其单位经济效益在结构上比工作时间基准更差，而周平均值让这一切变得不可见。

要发现你的 AI 功能定价模型出错了，最直接的方法就是看哪位工程师正在半夜重写截断逻辑。他们并不是在交付什么新功能 —— 他们是在修补一个 PRD 从未提及的单位经济效益（unit-economics）漏洞，而且由于产品规格告诉他们预算是无限的，这个补丁必然是对用户不友好的。在固定费用的 SaaS 方案中，任何时长超过中位数的对话都在实时抽走公司的利润。唯一的问题在于，产品团队是否能在财务部门发现之前承认这一点。

传统的 SaaS 经济模型建立在近乎零的边际用户成本之上：一旦软件构建完成，服务下一个客户几乎不会增加基础设施开支。但 AI 功能打破了这一假设。对话中的每一次交互都会消耗推理算力，其成本随着 Prompt 大小、输出长度、工具调用（tool-call）的扇出量以及检索量而增加 —— 而且对话没有自然的终点。一个重度用户可以在一个计费周期内消耗 50 倍于中位数的成本，且完全不出产品设计的正常路径。在固定定价模式下，这种用户实际上是由其他用户群供养的，而公司通常要到三个月后的销货成本（COGS）报告出来时才会发现这一点。

这就是为什么 AI 功能的定价不是一个等到发布后再处理的财务问题。它是一个架构输入，决定了产品被允许做什么。如果拒绝在产品规格中将其透明化，只意味着它稍后会被那些没有产品决策权的人以更糟糕的方式解决。

一个团队发布了一款面向用户的 AI 助手。他们将其定价为每席位每月 49 美元，根据一份假设“每次查询平均 500 个 token”的电子表格，目标毛利率为 70%。三个月后，财务部门指出，他们的重度用户在每个会话中消耗了 15,000 个 token。定价模型之所以崩溃，并不是因为功能失败，而是因为产品团队为他们尚不了解的东西定了价。

这并非预测失败。这是一个结构性问题：大模型驱动产品的成本基准与传统 SaaS 定价所设计的处理方式根本不同。每一次 API 调用都有不可预测且实质性的 token 成本。输入因用户、任务和时间段而异。输出以各种方式复合增长，而这些影响直到几周后才会出现在你的云账单上。一旦你引入了智能体模式 (Agentic patterns) —— 工具调用、多轮推理、子智能体编排 —— 单次用户交互的成本可能是 0.02 美元，也可能是 20 美元，这完全取决于模型的决定。