Token越烧越多？别让AI成为新时代吞金兽

很多AI工具用着用着就要收费了，所以小伙伴们讨论的时候都会吐槽说“把大家骗进来再杀。” 玩笑归玩笑，这个变化其实并不意外。AI 背后是真实的算力、模型、工程维护和服务成本，长期免费本来就不现实。   

作为在公司里接触AI比较早的一波人，我这两年有个明显感受是，企业从一开始鼓励员工应用AI（各种license只要申请就有），到现在AI越来越普及后，关注点则逐渐转向了AI token的成本控制——

从一两年前的“先用上再说”“我看看是咋回事?”到现在，核心问题变成，ROI（投入产出比）怎么算？在AI方面投入的人力，基础设施，Token等...是不是获得了真正的回报？又如何评估这种回报？

对比起个人使用AI，企业运用AI确实有更大的成本优化必要：

如果只是让每个员工自己打开聊天框，想起来就问几句，短期看起来很灵活，长期一定会出现几个问题：同样的任务反复解释，同样的资料反复上传，简单任务也调用最贵模型，Agent 反复重试，最后账单涨了不少，但流程并没有真正变好。

不要把 AI 当聊天框，要把能力固化成 Skill

企业用 AI 的第一步，不是写一个更长的 Prompt，而是把高频任务固化成 Skill。

这里的 Skill，可以理解成一个可复用的 AI 工作单元。它不只是一个提示词，而是包含了输入格式、输出格式、固定上下文、可调用工具、模型选择、校验规则和失败处理方式。

也就是说，Skill 的本质是把一次性的“临时问 AI”，变成一个可以重复运行、可以统计成本、可以持续优化的任务模块。

举一个更具体的例子。

假设一家企业希望用 AI 自动生成 CAE 仿真报告。以前的流程可能是：工程师跑完仿真，导出云图和结果表，手工整理最大应力、最大位移、危险位置，再写 Word 或 PPT 报告，最后主管审阅。

如果直接把这个流程改成“让 AI 写报告”，很容易失控。

工程师每次都把项目背景、模型说明、边界条件、材料参数、十几张云图、历史报告模板全部上传给大模型，然后说一句：“帮我生成一份仿真报告。”

第一轮可能能写出来。

但第二个项目又要重新解释一遍。第三个项目格式又不一致。第四个项目 AI 把最大应力位置写错了。第五个项目为了改一个结论，又把全部资料重新发了一遍。

这不是 AI 工作流。 这只是把人工混乱搬进了聊天框。

更合理的方式，是把“生成 CAE 报告”拆成几个 Skill。

 

把一次性 Prompt 固化成 Skill

比如第一个 Skill 叫 result-extractor，只负责从结果表中抽取最大应力、最大位移、危险单元编号和对应工况。这个任务不需要最强模型，甚至很多时候用脚本或小模型就够了。

第二个 Skill 叫 image-captioner，负责给云图生成工程说明。它的输入不是全部项目资料，而是单张云图、图名、工况编号和关键数值。它只输出两三句话，例如：“最大等效应力出现在壳体连接筋根部，峰值为 126 MPa，对应工况为 Z 向冲击。”

第三个 Skill 叫 report-writer，负责按企业固定模板生成报告初稿。它不再重新理解所有原始文件，而是读取前面 Skill 已经结构化好的结果：项目摘要、工况表、关键云图说明、结论草稿。

第四个 Skill 叫 review-checker，负责检查报告结论是否和数据一致。例如报告里写“满足强度要求”，但结果表中安全系数低于阈值，它就必须标出来，不能让这类错误进入客户版报告。

这样一拆，成本结构就完全不一样了。

不是所有步骤都调用最强模型。不是每一步都读取完整上下文。不是每次生成报告都从零开始。每个 Skill 的输入、输出、成本、错误率都可以被记录下来。

这才是企业 AI 工作流的基础。

成本优化的核心不是少用 AI，而是做 Router

谈到控制AI 成本，肯定不是“少用一点”。

真正的方向应该是：该用的时候用，但要知道每一步该用什么模型。

这就需要 Router。

Router 可以理解成 AI 工作流里的模型路由器。它决定一个任务应该交给强模型、小模型、本地模型，还是普通规则脚本。

 

成本优化的核心是 Router

继续看 CAE 报告这个例子。

从 CSV 结果表里找最大值，不需要强模型。把固定字段填入报告模板，也不需要强模型。

判断“这个应力集中是否可能来自边界条件设置不合理”，才可能需要更强的推理模型。

把内部技术报告改写成客户能读懂的表达，可能用中等模型就够。检查结论和数据是否矛盾，则需要模型能力加规则校验一起做。

如果没有 Router，企业很容易出现一种浪费：所有任务都走最高等级模型。

这就像企业内部所有计算任务都丢到最贵的高性能服务器上跑。能跑，但不经济。

所以成本优化不是简单地压缩 AI 使用量，而是建立分层调用：

便宜模型用错地方，会带来返工成本。强模型用在低价值步骤上，会带来浪费成本。

企业要优化的不是单次调用价格，而是整个流程的单位产出成本。

真正烧钱的往往是 Context 膨胀

企业 AI 工作流里，另一个容易被低估的成本是 Context。

也就是每次让模型读取多少背景材料。

很多 AI 项目一开始都很粗放：为了保险，把所有资料都塞进去。项目说明、历史报告、客户需求、测试记录、仿真设置、材料参数、会议纪要，全都给 AI。

这样做短期省事，长期很贵。

因为大模型的成本很大一部分来自输入和输出 token。你每次让模型重新读一遍长文档，本质上就是每次重新付一遍理解成本。

在 CAE 报告场景里，如果每次生成一段结论都把完整项目资料上传进去，就是典型的 Context 膨胀。

更好的方式是做 Context Engineering。

 

真正烧钱的往往是 Context 膨胀

企业可以把项目资料分成三层：

第一层是长期固定信息，比如公司报告模板、术语规范、客户表达风格。这些内容应该固化在 Skill 中，不要每次重复输入。

第二层是项目级信息，比如产品结构、材料、工况定义、评价标准。这些内容可以整理成项目摘要，在一次项目周期内复用。

第三层是任务级信息，比如某一个工况的最大应力、某一张云图、某一段需要改写的结论。这些才是每次调用模型时真正需要传入的内容。

如果这三层不分开，每一次 AI 调用都会变成“重新学习整个项目”。

这不仅贵，而且不稳定。因为上下文越长，模型越容易抓错重点；输入越杂，输出越难控制。

所以企业做 AI 工作流时，应该把 Context 当成一种工程资源来管理，而不是随手复 制粘贴。

Agent 必须有 Loop Budget

现在很多企业开始尝试 Agent。

Agent 的吸引力在于，它不只是回答问题，而是可以自己拆任务、调用工具、读文件、写代码、修改结果、继续验证。

这确实很有价值。 但 Agent 也带来一个新的成本风险：循环失控。

比如我们让一个 Agent 自动生成 CAE 报告。它可能会读取结果文件、生成报告、发现缺少一张图、回去搜索图片、重新生成、发现格式不一致、再修改、再检查、再重写一遍摘要。

如果没有限制，它可能在这些循环里反复调用模型和工具。最后报告是生成了，但成本可能远高于人工预期。

所以企业引入 Agent 时，必须设置 Loop Budget。

 

Agent 必须有 Loop Budget

Loop Budget 至少应该包括：最大模型调用次数、最大工具调用次数、最大上下文长度、最大重试次数、单个任务的成本上限，以及失败后转人工的条件。

例如一个 CAE 报告 Agent 可以规定：同一个章节最多生成两次；如果第二次仍然无法通过数据一致性检查，就不再继续重写，而是交给工程师确认。

这不是限制 Agent 的能力，而是让 Agent 进入工程系统。

工程系统不能无限尝试。仿真有收敛条件，优化有迭代上限，AI Agent 也应该有预算边界。

成本要和质量一起看

企业控制 AI 成本，不能只看账单。

如果一个 AI 流程每月多花 3000 元，但节省了 10 个工程师日，并且报告一致性更好，那可能是划算的。

反过来，如果一个流程模型调用费很低，但经常写错结论、漏掉风险、导致工程师反复返工，那它并不便宜。

所以每个 Skill 都应该有自己的指标。

不是只看调用了多少次，而是看单次运行成本、平均节省人时、人工修改比例、结果通过率、错误类型、返工次数，以及是否进入客户交付环节。

以 review-checker 这个 Skill 为例，它可能调用的是较强模型，单次成本不低。但如果它能提前发现“报告结论和仿真数据不一致”这种问题，它的价值就不是几毛钱或几块钱的调用费能衡量的。

企业最终要看的不是 AI 花了多少钱，而是：

AI 工作流的成本，本质上是架构问题

AI势必是未来每个企业都必须重点投资的方向，所谓控制成本，不是少用AI，而是沉淀 AI 工作流架构，追求更高的ROI。

• 高频任务要固化成 Skill；

• 不同任务要通过Router 分配模型；

• 上下文进行分层管理；

• Agent 要设置 Loop Budget；

• 关键结果要有 Evaluation；

• 成本和质量要一起考虑。

• ......

这套东西搭起来以后，才有可能把 AI 放到正确的位置，用合适的成本，完成可验证的工作。不用被模型，工具的涨价牵着鼻子走。