AI 的成本，应该算到哪里？
Where should the cost of AI stop?上一篇，我先算了企业 AI 经济账的第一边：
AI 提高效率以后，企业到底得到了什么？
Research 里越来越多的证据已经能够证明，一些具体任务确实变快了、产出增加了，甚至直接带来了销售增长。
但从 task improvement 到 enterprise value，中间还要经过：
任务改善 → 工作流兑现 → 产能利用 → 价值捕获。
知道“得到了什么”以后，这一篇想算另一边：
为了稳定得到这些结果，到底完整付出了什么？
这是我最开始想做这轮 research 的原因。
自己开始做 AI 产品以后，一个很直接的感受是：
API 的价格很好查。
但真正把一个功能跑起来以后，账单并不会停在那里。
- 模型之前可能有搜索、数据整理和 context。
- 模型之后可能有 retry、eval、人工检查、监控和失败处理。
接进真实产品以后，还有权限、系统集成、维护、用户 adoption。
所以这一篇我真正想回答的是：
AI 的成本，应该算到哪里才结束？
01｜API 账单是真的，但它不是整份账单
先澄清一件事。
说“AI 的成本不只是 token”，不代表 token 不重要。
Anthropic 在介绍自己的 multi-agent research system 时提到，这套系统消耗的 tokens 大约是普通聊天的 15 倍。
这是 Anthropic 一个特定系统的工程经验，不能理解成“所有 agent 都贵 15 倍”。
但它至少说明了一件事：
单个 token 越来越便宜，不代表完成一个任务一定越来越便宜。
一个更复杂的系统可能调用更多模型、更多工具、读取更多 context，也可能因为失败或不确定性不断重试。
与此同时，另一项真实生产部署研究里，也有团队认为：
相比昂贵的专家劳动，模型运行成本几乎可以忽略。
这两个看起来相反的情况，其实并不矛盾。
如果一次 AI 工作处理的是高价值专家任务，几十美元的模型费用可能很小。
如果面对的是几百万次低价值请求，即使每次只多几分钱，也可能成为很大的运营成本。
所以 research 以后，我觉得比较可靠的结论不是：
模型成本很小。
也不是：
真正贵的是 integration。
而是：
API price 不能代表完整成本。至于哪一项成本最大，要看具体 workflow。
02｜一套 AI 系统的成本，大概会出现在哪里？
完整 research 里，我把成本分得比较细。
真正写成产品和业务语言以后，我觉得可以理解成三个阶段。
第一层：先让它跑起来
这里包括最容易想到的部分：
模型、软件和计算
API、license、算力、搜索、tool call、storage。
数据和检索
清理文档、去重、权限映射、知识库、索引，以及上线之后持续更新这些内容。
系统集成
接 CRM、数据库、内部系统，处理身份、权限、API 和读写流程。
一个 demo 只需要输入一句 prompt。
一个真正进入企业 workflow 的 AI，往往需要先知道：
我可以看什么数据？
可以做什么操作？
哪些数据不能碰？
结果应该写回哪里？
这些工作不会出现在 token price 里。
第二层：再让结果可以相信
这是我自己做产品以后越来越在意的一层。
AI 能生成，不代表结果可以直接进入业务。
还需要：
Eval 和回归测试
什么叫合格？
哪些 case 绝对不能错？
模型、prompt、tool 或业务规则变化以后，要不要重新测试？
监控和运维
失败了能不能发现？
为什么失败？
需要重试、降级还是转人工？
安全、隐私和治理
谁可以访问什么数据？
哪些行为需要审批？
出了问题怎样追踪？
人工复核和异常处理
什么情况交给人？
由谁判断？
核验需要几分钟？
一个错误结果最后要付出多少补救成本？
NIST 的 Generative AI Profile 也把部署前测试、持续监控、来源验证和治理放在生成式 AI 的生命周期里。
它不是一份“成本报告”，但至少说明：
这些工作不是生产系统里的可选装饰。
第三层：让它长期活下去
还有一些成本，在 demo 和早期试点里很容易看不到。
采用和组织调整
培训用户、修改流程、重新分工，让团队真的开始使用系统。
维护
模型变了，API 变了，内部知识库变了，原来通过的 eval 可能需要重新跑。
失败、迁移和退出
试点没有成功怎么办？
供应商切换怎么办？
数据迁移、系统回滚、已经投入的集成成本怎么算？
所以“开发完成”并不是成本结束的时间点。
有些成本一次性发生。
有些持续发生。
还有一些只有规模放大以后才开始明显。
03｜这里有三笔账，特别容易算错
把所有项目都列进 spreadsheet 还不够。
有些成本本身就很容易在定义上算错。
第一，员工时间有成本，但不等于新增现金支出
假设两个内部工程师花一个月完成 AI integration。
他们的工资本来就在付。
所以这一个月不一定意味着企业突然多支出了两个月工资。
但也不能因此写成：
integration cost = 0。
因为他们本来可以做别的事情。
更准确的方式，是把：
现金成本
和
内部 capacity / opportunity cost
分开。
这和上一篇讲“员工每周省两小时”其实是同一个原则。
省下来的员工时间，不能自动全部算成现金节约。
花掉的员工时间，也不能因为没有新发票就算成免费。
第二，要比较两个完整 workflow
有时候谈 AI cost，会变成：
AI 有模型费、集成费、eval、错误、人工审核……
而另一边的人工流程，好像什么成本都没有。
这也不公平。
人工工作同样有：
培训、管理、返工、错误、等待、交接、加班。
真正合理的比较应该是：
在相同的质量、服务水平和业务范围下，AI workflow 和原来 workflow 各自完整需要什么？
不是：
AI 的所有缺点vs.一个完美、零错误、零管理成本的人类流程。
第三，不要重复算供应商的成本
如果企业购买 OpenAI、Anthropic 或其他供应商的 API：
模型训练和基础设施的很多成本已经反映在采购价格里。
不能再把模型公司的全部训练费用重新加到自己的项目成本上。
反过来也一样。
企业自己承担的数据整理、人工审核、系统维护，不会因为 API 发票里没写，就自动消失。
04｜更好的成本单位，也许不是一次调用
Research 里有一个我觉得特别适合留下来的判断：
企业真正购买的，是完成的工作，不是 tokens。
一个具体例子来自 Intercom 的 Fin AI Agent。
截至 research 时间，它的一些聊天和邮件 outcome 按 0.99 美元计费。
“按 outcome 收费”听起来已经比 token 更接近业务了。
但继续看定义，会发现一个很有意思的问题：
供应商定义的 outcome，和企业真正认可的 business outcome，未必完全一样。
例如某些转人工也可以形成计费 outcome。
“解决”有时由用户明确确认，有时根据用户没有继续求助推定。
如果之后用户回到同一个 conversation 继续求助，原先的 resolution 又可能被扣回。
我觉得这里真正值得注意的不是 Intercom 的价格高低。
而是三件东西最好分开：
- 供应商的计费单位
- 企业的业务验收单位
- 为了得到这个结果付出的全部成本
比如客服：
- API 成功返回一个答案，不等于 case resolved。
- case resolved 也不一定代表客户的问题永久解决。
真正的企业结果还可能关心：
- 有没有再次联系？
- 有没有转人工？
- 客户满意度如何？
- 最终每一个真正合格的 case 花了多少钱？
所以对于很多成本型 AI use case，我现在觉得更实用的单位是：
每个通过业务验收的最终结果，完整成本是多少？
不是：
一次模型调用多少钱？
05｜算成本时，还要看“什么时候发生”和“规模放大后怎么变”
还有两个维度很容易被混在一起。
一次性 / 持续性成本
回答：
什么时候发生？
例如：
第一次系统集成是一笔建设投入；
API 和监控则持续发生。
另一组是：
固定 / 随业务量变化的成本
回答：
规模扩大以后怎么变化？
一年平台 license 可以持续发生，但基本不随着每一次请求变化。
模型调用和人工审核，则可能随着业务量一起上涨。
这两组概念最好不要混。
因为它们会直接影响规模化以后单位经济性怎么变化。
如果一项 AI workflow 前期建设很贵，但之后每个合格结果的边际成本很低，那么业务量上升以后，它可能越来越划算。
反过来，如果每增加一个 AI case 都伴随着昂贵人工审核、很多 retry 和异常处理，规模放大可能并不会自然改善经济性。
所以，“AI 很便宜”或者“AI 很贵”，都不太够
做完这一部分 research 后，我反而不太想概括：
AI 真正的大头成本在哪里。
因为公开证据还不足以支持一个统一答案。
- 有些 workflow 里，模型和算力就是重要成本。
- 有些 workflow 里，真正消耗团队的是数据、集成和维护。
- 有些高风险场景里，人工判断和异常处理可能无法省掉。
- 还有一些专家型工作，即使 AI 每次运行并不便宜，相对于原来的专业劳动成本依然非常划算。
所以这一篇最后，我会把问题从：
一次调用多少钱？
换成：
为了稳定得到一个被业务接受的最终结果，这套 workflow 一共付出了什么？
实际评估时，我会继续问四件事：
1. Baseline 是什么？
和 AI 比较的原流程，完整成本到底是多少？
2. 建设和长期运行分别需要什么？
别只算上线前，也别只看上线后的 API 发票。
3. 每一个合格结果还需要多少模型、工具、人工和失败处理？
把不合格、retry、转人工也放进去。
4. Adoption 和真实业务量是多少？
一套系统理论上很便宜，但没人使用，前期固定投入依然摊不下来。
到这里，企业 AI 的两边账终于都有了一个大概轮廓。
第一篇追的是：
我们真正得到了什么？
第二篇追的是：
为了得到这些结果，完整付出了什么？
但即使两边都知道，还不能直接得出一个“AI ROI = X%”的通用答案。
因为不同 use case 的任务、需求、风险、业务量和验收方式差得太远。
所以第三篇我想把两边真正放在一起：
面对一个具体 AI 项目，从试点走向规模化以前，我们至少应该算清什么？
关于这轮 research
这是「企业 AI 的真实经济账」研究系列的第二篇。
这一篇的成本分类主要综合了 FinOps Foundation 的 AI workload 成本框架、NIST 的生成式 AI 生命周期治理要求，以及真实生产部署和工程案例。
一个重要限制是：
现有公开资料能够很好地证明“API 之外还有成本”，却不足以告诉我们这些成本在企业 AI 项目里通常各占多少。
所以文中没有采用“模型只占总成本 X%”或“integration 一定比 inference 贵”这样的说法。
同样，Anthropic multi-agent 系统的约 15 倍 token 使用，只用于说明复杂系统可能放大推理消耗，不代表行业平均水平。
Intercom 的 0.99 美元 outcome pricing，也只用于说明“计费单位”和“业务价值单位”可能不同，不代表客户使用后一定有正 ROI。