有一项研究，研究人员要求一个推理模型比较两个数字：0.9 和 0.11。一个模型花了 42 秒才给出答案。数学计算只花了几毫秒。模型在剩下的 41.9 秒里都在进行糟糕的思考。它重新审视自己的答案，怀疑自己，重新考虑，最后得出了它在前三个 token 中就已经得出的正确结论。
这就是过度思考的问题，它并非个案。当你将推理侧计算（inference-time compute）不加区分地应用于不需要它的任务时，就会发生这种情况。
推理模型（o1、o3、DeepSeek R1、具有扩展思考能力的 Claude）的出现，代表了解决难题能力上的真正飞跃。但它也引入了一类新的生产错误：在快速、廉价的生成完全足够的情况下，部署了昂贵且缓慢的深思熟虑。正确做出这一决策，对于构建真正有效的 AI 系统正变得越来越核心。
大多数生产环境中的 AI 系统在成本管理上都会犯同样的错误：它们上线时仅使用单一的最强模型 (frontier model) 来处理每个请求，眼睁睁看着 API 账单随流量线性增长，然后才手忙脚乱地添加缓存或缩减上下文窗口来补救。真正的解决方法——根据每个查询的实际需求将其路由到不同的模型——事后看来显而易见，但很少能被很好地实现。
数据能够清楚地说明问题。当前的最强模型 (frontier model)，如 Claude Opus，每百万输入 token 的成本约为 5 美元，每百万输出 token 为 25 美元。同系列的高效模型成本分别为 1 美元和 5 美元——比例达 5 倍。使用 RouteLLM 的研究表明，通过合理的路由，你可以在将 85% 的查询路由到更便宜的模型的同时，保持 95% 的最强模型质量，从而根据工作负载实现 45–85% 的成本降低。这不仅仅是边际改进；它改变了大规模部署 AI 的单位经济效益。
大多数基于 LLM 构建产品的团队都多付了 60%–90% 的费用。这并不是因为他们使用了错误的模型或提示词效率低下，而是因为他们在每次请求中都在重复处理相同的 Token。提示词缓存（Prompt caching）可以解决这个问题，且只需大约 10 分钟即可实现。然而，它仍然是生产级 LLM 系统中利用率最低的优化手段之一。
实际情况是：每次你向 LLM API 发送请求时，模型都会对提示词中的每一个 Token 运行注意力机制（Attention）。如果你的系统提示词（System prompt）有 10,000 个 Token，且每天处理 1,000 个请求，那么你每天仅为提示词中的静态部分（即永不变化的上下文）就要支付 1,000 万个 Token 的处理费用。提示词缓存会存储中间计算结果（即 Key-Value 注意力状态），以便后续请求可以完全跳过这部分工作。
大多数团队都会遇到同样的拐点：LLM API 成本的增长速度超过了使用量的增长，而且每一个查询——无论是“总结这句话”还是“审计这个 2,000 行的代码库以查找安全漏洞”——都指向同一个昂贵的模型。解决方法不是挤压 prompt，而是路由。
LLM 路由意味着将每个请求引导至最适合该特定任务的模型。不是能力最强的模型，而是正确的模型——在成本、延迟和质量之间平衡，以满足查询的实际需求。如果做得好，路由可以在质量几乎不下降的情况下将 LLM 成本降低 50–85%。如果做得不好，它会产生隐性的质量倒退，直到用户流失你才会察觉。
这篇文章涵盖了其机制、权衡以及在生产环境中实际会出问题的地方。
大多数团队发现他们上下文管理问题的方式都如出一辙：一个在演示中表现良好的生产级智能体，在对话进行 15 轮后开始出现幻觉。日志显示 JSON 格式正确，模型返回了 200 状态码，且没有人修改代码。变化的是累积效应——工具结果、检索到的文档和对话历史悄无声息地填满了上下文窗口，直到模型需要在 80,000 个相关性参差不齐的 Token 上进行推理。
上下文溢出（Context overflow）是显而易见的故障模式，但“上下文腐化”（context rot）则更具隐蔽性。研究表明，在达到限制之前，LLM 的性能就已经开始下降。随着上下文的增加，模型会出现“中间迷失”效应（lost-in-the-middle effect）：注意力集中在输入的开头和结尾，而中间的内容则变得不可靠。埋藏在 30 轮对话中第 12 轮的指令可能会实际上消失。模型不会报错——它只是悄悄地忽略了它们。
一个 Shopify 规模的商户助手，每天处理 1,000 万次对话，在不进行优化的前提下每月成本高达 210 万美元 —— 而经过优化后，成本仅需 45 万美元。这 78% 的差距并非源于算法上的突破，而是来自缓存、路由以及一些大多数团队在收到账单前都会忽略的工程规范。
AI Agent 并不只是多了几个步骤的聊天机器人。单次用户请求会触发规划、工具选择、执行、验证，通常还有重试循环 —— 消耗的 token 数量大约是直接对话交互的 5 倍。一个运行 10 个周期的 ReAct 循环，其 token 消耗量可能是单次交互的 50 倍。在顶级模型的价格体系下，这种计算开销很快就会变成一项财务负担。
这篇文章将涵盖 Agent 成本的来源机制，以及能够真正产生影响的具体技术（附带数据支持）。
大多数初次发布 LLM 应用的团队都会犯同一个错误：他们将上下文窗口视为免费存储。模型支持 128K tokens？太好了，塞满它。模型支持 1M tokens？更棒了——把所有东西都扔进去。接踵而至的是在产品真正跑通前三周就提前到达的账单冲击。
上下文不是免费的。它甚至一点也不便宜。除了成本之外，盲目填充上下文窗口实际上会让你的模型变得更糟。一个精简的 300 token 上下文通常优于一个松散的 113,000 token 上下文。这不是极端情况——而是一个有明确名称的文档化失效模式：“中间迷失”（lost in the middle）。管理好上下文是你对 LLM 产品做出的最高杠杆的工程决策之一。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
