最近在做 AI 应用开发时几乎每天都会看到一个熟悉的报错context length exceeded (36,183 tokens). cannot compress further.一个不算复杂的任务输入加上几轮历史记录就能轻松触到上下文窗口的边界。这个报错背后是 AI 热潮中一个很少有人真正重视的问题——我们都在消费 token但多数人并不清楚 token 如何计算、如何用得更省、如何避免在狂热中不断为模型能力“充值”却得不到稳定的结果。“AI Mania: From Tulips to Tokens”这个标题其实是一个很好的隐喻。它把历史上著名的郁金香狂热和当下 AI 热潮放在同一条时间轴上疯狂、涌入、价格飞涨、后来者接盘。区别在于郁金香交易的是球茎AI 交易的是 token。Token 既是模型理解人类语言的输入单元也是按量计费的输出单元更是衡量上下文长度、成本、性能的统一度量。如果说 AI 是一个新大陆token 就是这片大陆上唯一的货币。这篇文章不打算讨论 AI 会不会取代人、未来会不会有意识这类宏大话题。我更想聊一个更实际的问题当 AI 热潮退去一部分水分真实工具真正落地时我们该怎么管理 token、控制成本、减少幻觉、避免盲目追新。换句话说把 AI 从“话题”变成“工程”。1. 为什么说这是一场从郁金香到 Token 的狂热1.1 郁金香泡沫和 AI 热点的相似之处荷兰的郁金香热发生在 17 世纪。那时一株稀有郁金香球茎的价格可以买下一套运河边的房子。人们买郁金香并不是因为它能开出多漂亮的花而是因为“下一个买家会出更高的价格”。当预期反过来价格崩塌很多人一夜之间背负债务。放到今天的 AI 热潮相似的迹象并不少模型发布会越来越密集每条新功能都被包装成颠覆性突破社交平台上到处是“AI 改变一切”的叙事市场上出现大量只有 PPT 没有产品、只有界面没有场景的“AI 创业项目”甚至出现了靠注册送 token 来拉新用户的模型厂商。并不是说所有 AI 热潮都是泡沫。真正的泡沫往往出现在“概念先行、价值滞后”的阶段。技术是真实的但短期被高估长期又被低估。大模型的能力是真实的但多数普通用户和中小团队真正用到的场景可能只是几轮对话、摘要、写作辅助和简单代码生成。相比之下热词里出现的“AI 编程”“AI Agent”“AI 绘画”等方向确实有工具价值但距离“人人可用、稳定可靠”还有不小的距离。1.2 Token 接力了郁金香的叙事位置郁金香热潮中球茎的价格是围绕稀缺性波动的。而在 AI 热潮里token 是围绕算力和模型能力波动的。不同模型有不同的 token 计价规则输入和输出分开计费上下文越长费用越高。很多普通消费者对“模型有多聪明”没有感知反而对“注册送多少 token”有直接感受。于是token 成了 AI 热潮里最像货币的符号。token 这个单词本身也很有意思。它原意是代币、记号。在加密货币世界里token 代表资产在 AI 世界里token 代表文本片段。两者都有吸引投机者的一面。注册送 token、充值买 token、任务消耗 token这套商业模型和当年郁金香球茎交易的逻辑并没有本质区别都是一种可度量、可交易、能引发预期的东西。区别是郁金香球茎最终会枯萎而 token 一旦被消耗就永久消失不能转卖。1.3 狂热未必是坏事但会放大误判写过一段时间 AI 应用之后我的感受是狂热会让新鲜感快速消退也会让质量问题提前暴露。一个新模型发布时很多人急着注册、体验、写评测。但这些评测大多停留在“能不能答对某道题”“能不能写出一段像样的文案”上很少关心它在生产环境中的稳定性。等到真正做开发时才会遇到上下文溢出、输出格式不稳定、延迟波动、token 成本超出预期等一系列问题。这些不是模型能力不够而是工程化程度不够。狂热还会放大一种误判以为“AI 能力越强应用就越简单”。实际上强模型不等于好产品。一个能够写代码的模型如果被错误地接入业务流程可能会生成有安全隐患的代码一个能够画图的模型如果被用来执行批量任务可能会对成本和版权都造成麻烦。热潮中人容易高估工具的“自主性”低估人的“设计和约束”价值。所以与其一边焦虑一边跟风不如把“AI 狂热”看作一个提醒工具越强大越需要清楚的边界、可控的流程和扎实的工程基础。2. Token 才是 AI 世界的硬通货2.1 先搞清楚 Token 是什么、怎么算模型并不是直接理解文字本身而是把文字切分成一个个片段这些片段就是 token。不同模型切分规则不同英文单词可能一个词是一个 token中文可能一个字或一个词被拆成多个 token。常见的经验是一个英文单词大约 1.3 到 1.5 个 token一个汉字大约 1.5 到 2 个 token。但这不是绝对标准遇到代码、表情符、生僻字时差异更大。计费方式通常按“输入 token 输出 token”计算。比如请求一次模型系统提示词、用户输入、对话历史、工具返回的结果都属于输入模型生成的内容属于输出。一次请求的总 token 数就是两者之和。有些厂商还设置了 TPMTokens Per Minute限制也就是每分钟最多能消耗的 token 总数这会影响并发请求的吞吐量。热词里提到的“tpm 输入 token 输出 token 的总和”就是这个计费限制。2.2 计费、窗口和压缩三个绕不开的概念做 AI 应用时你马上会接触三个概念计费不同模型的价格差异可能很大。同一个任务用 A 模型可能花几毛钱用 B 模型可能花几十块。你需要根据成本选择模型而不是一味追求最强。窗口模型一次能接收的 token 总量叫上下文窗口。窗口大小直接决定了你能放进去多少文字、代码、历史记录。窗口不够用就会出现context length exceeded报错。压缩有些框架会自动压缩历史对话把早期的内容改写成摘要从而腾出空间。但压缩有代价信息丢失、摘要失真、模型可能忘记细节。报错里写着cannot compress further说明已经压无可压只能截断或失败。这三点是 AI 应用开发的底层约束。不理解它们你会写出“看起来能跑、一上线就崩”的应用。2.3 为什么上下文管理这么难很多人以为上下文管理就是“把历史消息都传过去”实际上没那么简单。首先模型并没有无限记忆。即使你有 128K 的上下文窗口模型对长文本中不同位置的注意力也不均匀。放在中间的信息容易被忽略这是模型结构带来的通病。也就是说即使 token 没有超限也不能保证模型真的“记住”了所有内容。其次token 消耗随对话轮次增长得非常快。假设每轮用户输入 200 token模型输出 400 token历史第 10 轮就积累了 6000 token到了 20 轮光历史就已经 12000 token。如果不做裁剪一个简单的客服机器人也能把上下文撑爆。最后压缩策略会影响输出质量。把早期内容压成摘要模型可能失去细节。比如用户说“我的订单号是 12345帮我改地址”如果这段内容被压成“用户要求改地址”之后模型再跟快递系统交互时就不知道订单号是多少。上下文管理不是简单的“省 token”而是权衡信息完整性和成本之间的一套策略。3. AI 编程、绘画和 Agent看起来很美先看账单3.1 AI 编程的效率与隐性成本“AI 编程”是当前最热的几个方向之一。Cursor、IDEA 插件、Spring AI 等工具频繁出现在讨论中。AI 编程的体验确实好它能根据注释生成函数、补全代码、解释报错信息。但实际用于项目开发时隐性成本不小。首先是 token 消耗速度。一个稍大的函数重构可能就需要几千 token 的输入和输出。如果你频繁让它分析整个项目文件一次对话消耗上万 token 很正常。其次是质量问题。AI 生成的代码可能看起来逻辑正确但缺少边界判断、类型约束和异常处理。你还要花时间 review、测试、修改这些时间成本没有计入 token 账单。更典型的是误解。很多人以为 AI 编程就是“提出需求得到完整代码”但现实是模型只理解你描述的需求片段不了解项目的整体架构、历史决策和技术债。你需要把它当成一个“非常熟练但不懂业务的新同事”给它足够上下文同时严格 review 它的输出。否则它能帮你生成 200 行代码也能帮你埋下一颗雷。3.2 AI 绘画的 token 消耗密度AI 绘画看起来不像编程那样需要大量文字但它的 token 消耗集中在描述和反复调整上。你写一段提示词生成一张图然后不满意改几个关键词再来一张。一张图消耗的 token 可能不多但一晚上试下来很容易消耗数十万 token。如果使用更精细的控制网络、局部重绘每一次请求都会拉高消耗。另外AI 绘画的“效率”容易被误读。生成一张图只要几十秒但找到理想构图可能要试几十次。中间还需要人工筛选、修图、拼接最终时间成本并不低。对于批量生成脚本比如“AI 营销视频一键成片”这类工具思路也类似。看起来一键完成实际上模板、素材、脚本、配音、字幕每个环节都需要消耗 token 和算力。如果没控制好参数和用量成本很容易失控。3.3 Agent 的失控风险与 Token 爆炸AI Agent 是一个被讨论很多的方向。它的大致思路是让模型根据任务目标自己规划步骤、调用工具、读取反馈再循环迭代直到完成。听起来像是一个能自主工作的同事但工程实现比想象复杂得多。一个 Agent 任务通常会产生多轮“模型—工具”循环。每一轮调用都包含系统提示词、工具返回结果、模型推理输出Token 消耗比单轮对话高出一个数量级。如果 Agent 陷入死循环或错误分支token 会像流水一样消耗甚至卡在某个cannot compress further的报错上。更麻烦的是Agent 的不可预测性。它可能会调用一个本来不该调用的工具也可能会按照错误的理解反复重试。在缺少严格边界的情况下Agent 既不可控也难排查。我的建议是先用小样本任务测试明确工具列表、调用权限、最大迭代次数并设置 token 预算上限。把 Agent 当成一个有风险的流程而不是一个无脑的自动化工具。3.4 让人头疼的 AI 幻觉和 Token 有什么关系AI 幻觉指的是模型一本正经地给出错误信息。很多人觉得这是模型“不聪明”其实和 token 也有关系。模型生成输出时是根据概率预测下一个 token而不是检索事实。它的知识来自训练数据而不是实时数据库。当输入 token 中包含的问题超出它的知识边界它可能用编造的信息来填补。另外上下文过长也会加剧幻觉关键信息被淹没模型只能根据最近的 token 强行生成错误概率自然上升。减少幻觉的方向不是“换一个更大模型”而是做好检索和约束。你可以把外部资料作为上下文输入让模型基于资料回答你也可以限制输出格式甚至让模型先列出可验证的事实再给出结论。Token 在这里不仅代表成本也代表你能提供给模型的信息质量。信息越干净、越有结构模型的输出就越稳定。4. 把 AI 应用当成工程来做的五个控制点如果只是体验 AI怎么做都行。但如果要放进真实业务里就一定要把它当成工程问题来对待。下面是一套我反复使用的控制框架按优先级排列。4.1 控制点一输入净化与压缩在把文本交给模型之前先做净化。删掉无意义的重复内容、网页模板、广告标签把长文档按章节切分只保留与任务相关的部分如果输入是网页爬取的内容先转成纯文本。这样能直接减少输入 token便宜又有效。对于日志、评论、长文章这类非结构化输入可以用摘要模型先做一轮粗筛。比如先用一个小模型生成摘要再把摘要交给更强的模型。虽然多调用了一次但整体成本可能更低因为小模型速度快、价格低还能提取关键信息。4.2 控制点二上下文裁剪策略不要一次性把全部历史记录塞给模型。常见做法是设定最大轮次比如只保留最近 10 轮对话超过限制时用摘要替换最早的内容对于结构化任务只保留关键字段不保留原始对话。这里有一个容易踩坑的点不要为了节省 token 而压缩掉必要的信息。建议先观察模型在完整上下文下的输出质量再逐步压缩找到“能接受”的平衡点。如果你有一个“订单号、地址、金额”之类的关键槽位永远不要把它合并进摘要里否则后面模型无法完成操作。4.3 控制点三请求频率与并发很多应用会把所有用户请求实时同步发送给模型结果一上线就遇到 TPM 限制。常见做法是在应用层增加队列控制每分钟的请求量对长任务拆成多个短任务分批执行对可缓存的请求做缓存比如同一个提示词生成的固定文案没必要重复调用模型。TPM 限制不只是计费问题它还影响应用的可用性。如果超过限制接口会返回限流错误这时候必须做重试和退避。建议在代码里统一封装一个请求模块包含限流、重试、超时、错误分类而不是在每个业务逻辑里单独调用。4.4 控制点四成本与日志监控先用小样本估算成本再上批量。假设每次请求 1000 输入 token、500 输出 token单价是每百万 token 20 元那一次请求的成本就是 0.03 元。听起来不高但一天跑 10 万次就是 3000 元。这个账一定要提前算。日志方面至少记录以下信息每次请求的模型名、输入 token、输出 token、耗时、状态码每个业务功能消耗的 token 总量和成本出现context length exceeded、限流、超时的次数有了这些数据你才能知道哪些功能是成本大头哪些高频功能可以被简化。4.5 控制点五异常处理与兜底模型接口不稳定网络也可能抖动。一个合格的 AI 应用必须有兜底方案。设置最大重试次数和退避时间避免无限重试当请求失败或超时时返回固定的友好提示而不是让用户看到崩溃栈对于关键业务增加人工审核或规则校验防止模型输出直接进入核心流程。比如 AI 生成的文章在发布前应该经过敏感词过滤、格式校验、事实抽查。AI 生成的代码必须经过编译、测试、代码审查。不要假设模型不会出错机器和流程都会出错。5. 从狂热回归理性现在该怎么用 AI5.1 适合做的事情与不适合做的事情根据我的经验现在的 AI 适合做以下事情文案初稿、内容改写、摘要提炼、翻译代码补全、单元测试生成、简单脚本编写、错误解释非结构化数据的初筛和分类比如判断客户反馈类型在有资料约束的场景下回答问题比如客服机器人。暂时不适合做的事情完全无人值守的金融交易、医疗诊断、法律建议需要高精度事实判断的任务没有规则和权限约束的 Agent 自动化一次生成上百万字的书籍或完整系统。不是模型能力做不到而是风险不可控。尤其在涉及人身安全、财产安全、法律责任的地方AI 应该作为辅助者而不是决策者。5.2 从最小可用流程开始而不是一步到位最稳妥的落地方案是先跑通一个最小可用流程再扩展到批量、再优化成本。第一步用一个小样本验证输入输出是否符合预期。例如 100 条测试数据手动检查输出质量。第二步把流程脚本化加入日志、重试、错误处理。第三步跑一批真实数据观察 token 消耗和失败率。最后才考虑优化成本比如换更便宜的模型、压缩上下文、加缓存。不要一上来就搞“AI 全家桶”语言模型、视觉模型、Agent、向量数据库全上。每多一个环节就多一个失败点也多一层 token 消耗。先从最小闭环开始比什么都重要。5.3 一个可复用的判断清单当你要使用一个 AI 能力时可以按这份清单问自己这个任务必须用大模型解决吗用规则、正则、字典能做到吗输入数据是什么格式最大长度是多少需要预处理吗输出结果会被谁消费需要稳定结构吗是给人看还是给系统看失败后会造成什么后果可以重试吗需要人工介入吗单次成本是多少每天调用量是多少有没有预算上限如果模型升级或调整价格这个流程还能稳定运行吗这些问题没有标准答案但能帮你在热潮中保持清醒。AI 是一种工具不是信仰。工具的职责是解决问题而不是成为话题。5.4 现在最该做的事情回到开头那个context length exceeded报错。它提醒我的是AI 开发的第一课不是“怎么提示词写得更好”而是“怎么理解 token 的边界”。不要把目光只盯在“哪个模型更强”上。多花点时间记录自己的 token 消耗分析任务失败原因建立成本监控设计一层容错缓冲。这些工作看起来不够酷却决定了 AI 应用能不能活过上线后的第三个月。从郁金香到 token浪潮会过去留下来的不是炒作而是真正被沉淀下来的工程能力。如果一个工具让你产生热情下一步应该是耐心而不是冲动。最好的使用方式不是追着热度跑而是把它放在真实的问题里反复打磨直到能稳定地为别人创造价值。所以下一次打开 AI 应用之前可以先想清楚一个问题你准备让它做什么你愿意为它消耗多少 token如果它失败了你的备选方案是什么。想清楚这三点你才算真正开始使用 AI。 AI狂热中的Token硬通货：从上下文爆满到工程化成本控制
最近在做 AI 应用开发时几乎每天都会看到一个熟悉的报错context length exceeded (36,183 tokens). cannot compress further.一个不算复杂的任务输入加上几轮历史记录就能轻松触到上下文窗口的边界。这个报错背后是 AI 热潮中一个很少有人真正重视的问题——我们都在消费 token但多数人并不清楚 token 如何计算、如何用得更省、如何避免在狂热中不断为模型能力“充值”却得不到稳定的结果。“AI Mania: From Tulips to Tokens”这个标题其实是一个很好的隐喻。它把历史上著名的郁金香狂热和当下 AI 热潮放在同一条时间轴上疯狂、涌入、价格飞涨、后来者接盘。区别在于郁金香交易的是球茎AI 交易的是 token。Token 既是模型理解人类语言的输入单元也是按量计费的输出单元更是衡量上下文长度、成本、性能的统一度量。如果说 AI 是一个新大陆token 就是这片大陆上唯一的货币。这篇文章不打算讨论 AI 会不会取代人、未来会不会有意识这类宏大话题。我更想聊一个更实际的问题当 AI 热潮退去一部分水分真实工具真正落地时我们该怎么管理 token、控制成本、减少幻觉、避免盲目追新。换句话说把 AI 从“话题”变成“工程”。1. 为什么说这是一场从郁金香到 Token 的狂热1.1 郁金香泡沫和 AI 热点的相似之处荷兰的郁金香热发生在 17 世纪。那时一株稀有郁金香球茎的价格可以买下一套运河边的房子。人们买郁金香并不是因为它能开出多漂亮的花而是因为“下一个买家会出更高的价格”。当预期反过来价格崩塌很多人一夜之间背负债务。放到今天的 AI 热潮相似的迹象并不少模型发布会越来越密集每条新功能都被包装成颠覆性突破社交平台上到处是“AI 改变一切”的叙事市场上出现大量只有 PPT 没有产品、只有界面没有场景的“AI 创业项目”甚至出现了靠注册送 token 来拉新用户的模型厂商。并不是说所有 AI 热潮都是泡沫。真正的泡沫往往出现在“概念先行、价值滞后”的阶段。技术是真实的但短期被高估长期又被低估。大模型的能力是真实的但多数普通用户和中小团队真正用到的场景可能只是几轮对话、摘要、写作辅助和简单代码生成。相比之下热词里出现的“AI 编程”“AI Agent”“AI 绘画”等方向确实有工具价值但距离“人人可用、稳定可靠”还有不小的距离。1.2 Token 接力了郁金香的叙事位置郁金香热潮中球茎的价格是围绕稀缺性波动的。而在 AI 热潮里token 是围绕算力和模型能力波动的。不同模型有不同的 token 计价规则输入和输出分开计费上下文越长费用越高。很多普通消费者对“模型有多聪明”没有感知反而对“注册送多少 token”有直接感受。于是token 成了 AI 热潮里最像货币的符号。token 这个单词本身也很有意思。它原意是代币、记号。在加密货币世界里token 代表资产在 AI 世界里token 代表文本片段。两者都有吸引投机者的一面。注册送 token、充值买 token、任务消耗 token这套商业模型和当年郁金香球茎交易的逻辑并没有本质区别都是一种可度量、可交易、能引发预期的东西。区别是郁金香球茎最终会枯萎而 token 一旦被消耗就永久消失不能转卖。1.3 狂热未必是坏事但会放大误判写过一段时间 AI 应用之后我的感受是狂热会让新鲜感快速消退也会让质量问题提前暴露。一个新模型发布时很多人急着注册、体验、写评测。但这些评测大多停留在“能不能答对某道题”“能不能写出一段像样的文案”上很少关心它在生产环境中的稳定性。等到真正做开发时才会遇到上下文溢出、输出格式不稳定、延迟波动、token 成本超出预期等一系列问题。这些不是模型能力不够而是工程化程度不够。狂热还会放大一种误判以为“AI 能力越强应用就越简单”。实际上强模型不等于好产品。一个能够写代码的模型如果被错误地接入业务流程可能会生成有安全隐患的代码一个能够画图的模型如果被用来执行批量任务可能会对成本和版权都造成麻烦。热潮中人容易高估工具的“自主性”低估人的“设计和约束”价值。所以与其一边焦虑一边跟风不如把“AI 狂热”看作一个提醒工具越强大越需要清楚的边界、可控的流程和扎实的工程基础。2. Token 才是 AI 世界的硬通货2.1 先搞清楚 Token 是什么、怎么算模型并不是直接理解文字本身而是把文字切分成一个个片段这些片段就是 token。不同模型切分规则不同英文单词可能一个词是一个 token中文可能一个字或一个词被拆成多个 token。常见的经验是一个英文单词大约 1.3 到 1.5 个 token一个汉字大约 1.5 到 2 个 token。但这不是绝对标准遇到代码、表情符、生僻字时差异更大。计费方式通常按“输入 token 输出 token”计算。比如请求一次模型系统提示词、用户输入、对话历史、工具返回的结果都属于输入模型生成的内容属于输出。一次请求的总 token 数就是两者之和。有些厂商还设置了 TPMTokens Per Minute限制也就是每分钟最多能消耗的 token 总数这会影响并发请求的吞吐量。热词里提到的“tpm 输入 token 输出 token 的总和”就是这个计费限制。2.2 计费、窗口和压缩三个绕不开的概念做 AI 应用时你马上会接触三个概念计费不同模型的价格差异可能很大。同一个任务用 A 模型可能花几毛钱用 B 模型可能花几十块。你需要根据成本选择模型而不是一味追求最强。窗口模型一次能接收的 token 总量叫上下文窗口。窗口大小直接决定了你能放进去多少文字、代码、历史记录。窗口不够用就会出现context length exceeded报错。压缩有些框架会自动压缩历史对话把早期的内容改写成摘要从而腾出空间。但压缩有代价信息丢失、摘要失真、模型可能忘记细节。报错里写着cannot compress further说明已经压无可压只能截断或失败。这三点是 AI 应用开发的底层约束。不理解它们你会写出“看起来能跑、一上线就崩”的应用。2.3 为什么上下文管理这么难很多人以为上下文管理就是“把历史消息都传过去”实际上没那么简单。首先模型并没有无限记忆。即使你有 128K 的上下文窗口模型对长文本中不同位置的注意力也不均匀。放在中间的信息容易被忽略这是模型结构带来的通病。也就是说即使 token 没有超限也不能保证模型真的“记住”了所有内容。其次token 消耗随对话轮次增长得非常快。假设每轮用户输入 200 token模型输出 400 token历史第 10 轮就积累了 6000 token到了 20 轮光历史就已经 12000 token。如果不做裁剪一个简单的客服机器人也能把上下文撑爆。最后压缩策略会影响输出质量。把早期内容压成摘要模型可能失去细节。比如用户说“我的订单号是 12345帮我改地址”如果这段内容被压成“用户要求改地址”之后模型再跟快递系统交互时就不知道订单号是多少。上下文管理不是简单的“省 token”而是权衡信息完整性和成本之间的一套策略。3. AI 编程、绘画和 Agent看起来很美先看账单3.1 AI 编程的效率与隐性成本“AI 编程”是当前最热的几个方向之一。Cursor、IDEA 插件、Spring AI 等工具频繁出现在讨论中。AI 编程的体验确实好它能根据注释生成函数、补全代码、解释报错信息。但实际用于项目开发时隐性成本不小。首先是 token 消耗速度。一个稍大的函数重构可能就需要几千 token 的输入和输出。如果你频繁让它分析整个项目文件一次对话消耗上万 token 很正常。其次是质量问题。AI 生成的代码可能看起来逻辑正确但缺少边界判断、类型约束和异常处理。你还要花时间 review、测试、修改这些时间成本没有计入 token 账单。更典型的是误解。很多人以为 AI 编程就是“提出需求得到完整代码”但现实是模型只理解你描述的需求片段不了解项目的整体架构、历史决策和技术债。你需要把它当成一个“非常熟练但不懂业务的新同事”给它足够上下文同时严格 review 它的输出。否则它能帮你生成 200 行代码也能帮你埋下一颗雷。3.2 AI 绘画的 token 消耗密度AI 绘画看起来不像编程那样需要大量文字但它的 token 消耗集中在描述和反复调整上。你写一段提示词生成一张图然后不满意改几个关键词再来一张。一张图消耗的 token 可能不多但一晚上试下来很容易消耗数十万 token。如果使用更精细的控制网络、局部重绘每一次请求都会拉高消耗。另外AI 绘画的“效率”容易被误读。生成一张图只要几十秒但找到理想构图可能要试几十次。中间还需要人工筛选、修图、拼接最终时间成本并不低。对于批量生成脚本比如“AI 营销视频一键成片”这类工具思路也类似。看起来一键完成实际上模板、素材、脚本、配音、字幕每个环节都需要消耗 token 和算力。如果没控制好参数和用量成本很容易失控。3.3 Agent 的失控风险与 Token 爆炸AI Agent 是一个被讨论很多的方向。它的大致思路是让模型根据任务目标自己规划步骤、调用工具、读取反馈再循环迭代直到完成。听起来像是一个能自主工作的同事但工程实现比想象复杂得多。一个 Agent 任务通常会产生多轮“模型—工具”循环。每一轮调用都包含系统提示词、工具返回结果、模型推理输出Token 消耗比单轮对话高出一个数量级。如果 Agent 陷入死循环或错误分支token 会像流水一样消耗甚至卡在某个cannot compress further的报错上。更麻烦的是Agent 的不可预测性。它可能会调用一个本来不该调用的工具也可能会按照错误的理解反复重试。在缺少严格边界的情况下Agent 既不可控也难排查。我的建议是先用小样本任务测试明确工具列表、调用权限、最大迭代次数并设置 token 预算上限。把 Agent 当成一个有风险的流程而不是一个无脑的自动化工具。3.4 让人头疼的 AI 幻觉和 Token 有什么关系AI 幻觉指的是模型一本正经地给出错误信息。很多人觉得这是模型“不聪明”其实和 token 也有关系。模型生成输出时是根据概率预测下一个 token而不是检索事实。它的知识来自训练数据而不是实时数据库。当输入 token 中包含的问题超出它的知识边界它可能用编造的信息来填补。另外上下文过长也会加剧幻觉关键信息被淹没模型只能根据最近的 token 强行生成错误概率自然上升。减少幻觉的方向不是“换一个更大模型”而是做好检索和约束。你可以把外部资料作为上下文输入让模型基于资料回答你也可以限制输出格式甚至让模型先列出可验证的事实再给出结论。Token 在这里不仅代表成本也代表你能提供给模型的信息质量。信息越干净、越有结构模型的输出就越稳定。4. 把 AI 应用当成工程来做的五个控制点如果只是体验 AI怎么做都行。但如果要放进真实业务里就一定要把它当成工程问题来对待。下面是一套我反复使用的控制框架按优先级排列。4.1 控制点一输入净化与压缩在把文本交给模型之前先做净化。删掉无意义的重复内容、网页模板、广告标签把长文档按章节切分只保留与任务相关的部分如果输入是网页爬取的内容先转成纯文本。这样能直接减少输入 token便宜又有效。对于日志、评论、长文章这类非结构化输入可以用摘要模型先做一轮粗筛。比如先用一个小模型生成摘要再把摘要交给更强的模型。虽然多调用了一次但整体成本可能更低因为小模型速度快、价格低还能提取关键信息。4.2 控制点二上下文裁剪策略不要一次性把全部历史记录塞给模型。常见做法是设定最大轮次比如只保留最近 10 轮对话超过限制时用摘要替换最早的内容对于结构化任务只保留关键字段不保留原始对话。这里有一个容易踩坑的点不要为了节省 token 而压缩掉必要的信息。建议先观察模型在完整上下文下的输出质量再逐步压缩找到“能接受”的平衡点。如果你有一个“订单号、地址、金额”之类的关键槽位永远不要把它合并进摘要里否则后面模型无法完成操作。4.3 控制点三请求频率与并发很多应用会把所有用户请求实时同步发送给模型结果一上线就遇到 TPM 限制。常见做法是在应用层增加队列控制每分钟的请求量对长任务拆成多个短任务分批执行对可缓存的请求做缓存比如同一个提示词生成的固定文案没必要重复调用模型。TPM 限制不只是计费问题它还影响应用的可用性。如果超过限制接口会返回限流错误这时候必须做重试和退避。建议在代码里统一封装一个请求模块包含限流、重试、超时、错误分类而不是在每个业务逻辑里单独调用。4.4 控制点四成本与日志监控先用小样本估算成本再上批量。假设每次请求 1000 输入 token、500 输出 token单价是每百万 token 20 元那一次请求的成本就是 0.03 元。听起来不高但一天跑 10 万次就是 3000 元。这个账一定要提前算。日志方面至少记录以下信息每次请求的模型名、输入 token、输出 token、耗时、状态码每个业务功能消耗的 token 总量和成本出现context length exceeded、限流、超时的次数有了这些数据你才能知道哪些功能是成本大头哪些高频功能可以被简化。4.5 控制点五异常处理与兜底模型接口不稳定网络也可能抖动。一个合格的 AI 应用必须有兜底方案。设置最大重试次数和退避时间避免无限重试当请求失败或超时时返回固定的友好提示而不是让用户看到崩溃栈对于关键业务增加人工审核或规则校验防止模型输出直接进入核心流程。比如 AI 生成的文章在发布前应该经过敏感词过滤、格式校验、事实抽查。AI 生成的代码必须经过编译、测试、代码审查。不要假设模型不会出错机器和流程都会出错。5. 从狂热回归理性现在该怎么用 AI5.1 适合做的事情与不适合做的事情根据我的经验现在的 AI 适合做以下事情文案初稿、内容改写、摘要提炼、翻译代码补全、单元测试生成、简单脚本编写、错误解释非结构化数据的初筛和分类比如判断客户反馈类型在有资料约束的场景下回答问题比如客服机器人。暂时不适合做的事情完全无人值守的金融交易、医疗诊断、法律建议需要高精度事实判断的任务没有规则和权限约束的 Agent 自动化一次生成上百万字的书籍或完整系统。不是模型能力做不到而是风险不可控。尤其在涉及人身安全、财产安全、法律责任的地方AI 应该作为辅助者而不是决策者。5.2 从最小可用流程开始而不是一步到位最稳妥的落地方案是先跑通一个最小可用流程再扩展到批量、再优化成本。第一步用一个小样本验证输入输出是否符合预期。例如 100 条测试数据手动检查输出质量。第二步把流程脚本化加入日志、重试、错误处理。第三步跑一批真实数据观察 token 消耗和失败率。最后才考虑优化成本比如换更便宜的模型、压缩上下文、加缓存。不要一上来就搞“AI 全家桶”语言模型、视觉模型、Agent、向量数据库全上。每多一个环节就多一个失败点也多一层 token 消耗。先从最小闭环开始比什么都重要。5.3 一个可复用的判断清单当你要使用一个 AI 能力时可以按这份清单问自己这个任务必须用大模型解决吗用规则、正则、字典能做到吗输入数据是什么格式最大长度是多少需要预处理吗输出结果会被谁消费需要稳定结构吗是给人看还是给系统看失败后会造成什么后果可以重试吗需要人工介入吗单次成本是多少每天调用量是多少有没有预算上限如果模型升级或调整价格这个流程还能稳定运行吗这些问题没有标准答案但能帮你在热潮中保持清醒。AI 是一种工具不是信仰。工具的职责是解决问题而不是成为话题。5.4 现在最该做的事情回到开头那个context length exceeded报错。它提醒我的是AI 开发的第一课不是“怎么提示词写得更好”而是“怎么理解 token 的边界”。不要把目光只盯在“哪个模型更强”上。多花点时间记录自己的 token 消耗分析任务失败原因建立成本监控设计一层容错缓冲。这些工作看起来不够酷却决定了 AI 应用能不能活过上线后的第三个月。从郁金香到 token浪潮会过去留下来的不是炒作而是真正被沉淀下来的工程能力。如果一个工具让你产生热情下一步应该是耐心而不是冲动。最好的使用方式不是追着热度跑而是把它放在真实的问题里反复打磨直到能稳定地为别人创造价值。所以下一次打开 AI 应用之前可以先想清楚一个问题你准备让它做什么你愿意为它消耗多少 token如果它失败了你的备选方案是什么。想清楚这三点你才算真正开始使用 AI。