--- layout: post.njk source: https://yage.ai/share/ai-cost-subsidy-retreat-agent-design-20260628.html speaker: yage.ai title: AI 补贴退潮后，agent 开始按每美元智能计价 date: '2026-06-28' summary: 随着大模型早期补贴退潮，企业对 AI 的关注点正从单纯的 token 消耗转向以每美元交付可靠任务结果的工程实践。文章探讨了在成本结构变化下，Agent 架构需要引入专门的成本控制面（如提示词缓存、上下文精简和动态路由）来平衡性能与财务弹性，强调建立内部智能账本的重要性。 area: tech-engineering category: ai-application tags: - cost-control - agent-architecture - model-routing - prompt-caching people: [] companies_orgs: [] products_models: [] media_books: [] draft: true status: evergreen --- 大模型的 token 预算管理，已经从技术预测变成了开发团队每天面对的工程现实。企业开始给 AI 用量设预算、做额度、算 ROI，这个现象本身已经不需要再证明。之前讨论 Meta token 账单和 quota 管理 时，我把它概括成一句话：不要用 token 消耗衡量进展，要用真实产出衡量进展。 现在更有意思的问题往下了一层：为什么这股账单压力会在这个时间点集中浮出水面？它不是简单的“token 变贵了”，而是早期补贴结构开始退潮。这个变化会反过来改写 agent 架构，因为生产要素的相对价格一旦改变，旧的最优策略就需要重新评估。 在这个转折点上，agent 的设计目标函数正在发生改变。开发团队过去可以追求采用率、增加 seat、默认调用最强模型。接下来要回答的是另一件事：在同样预算里，每一美元能交付多少可靠任务结果。这种转变并不是通过限制员工使用来省钱，而是把 AI 从试验性资源，重新理解成按量计费的基础设施。 ## 为什么 token 补贴会在今天退潮？ 大模型 token 过去之所以廉价，主要是因为产业链多方的隐性补贴，而不仅是算力成本的自然下降。过去两年里，几股力量共同压低了 token 价格。一方面，模型厂商为了争夺市场份额并绑定开发者，提供的 API 定价往往低于真实的折旧成本。另一方面，SaaS 与 Copilot 产品的固定席位订阅制带来了隐性交叉补贴，轻度用户的低频使用消化了重度用户的超额消耗，使企业真实的用量成本隐藏在固定账单背后。此外，在试点期，企业管理层通常出于探索目的给予团队极高的预算宽容度，并不急于审计投资回报率（ROI）；同时，宽松的融资环境也支持着厂商通过价格战来维持低价。 如今，这几股支撑低价的因素正迎来改变。2026 年 6 月 1 日，GitHub Copilot 开始转向基于用量的计费模式（usage-based billing），引入了 GitHub AI Credits，按输入、输出和缓存的 token 以及具体模型的费率进行收费，并为企业管理员提供了预算控制功能。这种计费模式的调整，把原本打包在固定年费里的隐性支出转为了透明、按量计费的资源。 与此同时，OpenAI、Anthropic、Google Gemini 和 AWS Bedrock 集中更新了各自的 prompt caching 计费规则。缓存命中与未命中之间的数倍价差，让计费分层变得更加复杂，也促使企业从财务角度重新计算每次调用的性价比。 当按需计价成为行业常态，加上管理层要求审计产出效率，原本隐藏在后台的成本问题开始显露。据 Business Insider 报道，Uber COO Andrew Macdonald 在内部追问 AI token 开支与用户实际功能产出之间的关联；Anthropic 的 Boris Cherny 也在相关报道中指出，尽管成本控制应主要在后台解决，避免惩罚员工试用，但他同样认为算清 ROI 是正确的提问方向。原本的成本经济学已经成为开发团队在架构设计时不可忽略的约束条件。 为了规范这一领域的实践，Linux Foundation 在 2026 年 6 月 3 日宣布计划成立 Tokenomics Foundation，为 AI 成本管理、评测和最佳实践制定开放标准。这表明，给每一次推理算账已经从小众的工程自救，演变成了行业级的财务规范。 AI 从试点期进入生产期后，agent 目标函数从使用量切换到每美元可靠任务结果 在这种新常态下，不应将过去开发中常见的“多喂上下文、默认最强模型、频繁重试”等做法简单归结为浪费。在原先的价格结构中，所谓 tokenmaxxing 有其合理性。当服务商通过补贴降低 token 价格，而开发时间与用户反馈的获取成本相对较高时，用低成本、高供给的 token 换取确定性，并加速产品上线，是符合商业逻辑的选择。 而当相对价格发生变化、隐性补贴消退，这些做法便转为了系统架构上的设计负债。每一轮冗长的上下文、工具调用产生的冗余文本、由于设计漏洞导致的出错重试，都开始以真实账单的形式实时扣除成本。 ## Builder 应该如何改 Agent 架构？ 应对成本压力的方向，并不在于因为省钱而减少 AI 的使用，关键在于需要在 agent 的系统架构中引入专门的成本控制面（cost control plane）。要构建这套控制面，开发团队需要回答四个工程问题。 ### 别为同一段前缀反复付钱 在典型的 agent 运行流中，大量的请求前缀（包括系统指令、工具接口描述、业务背景文档）是静态且高度重复的。如果在每次轮询中都把这些前缀原样发给模型重复计算，就等于在为相同的服务反复支付费用。 目前，各大模型厂商提供的 prompt caching（提示词缓存）技术为这一问题给出了现成解法。一旦缓存命中，token 价格通常可以降到原价的十分之一甚至更低。我之前在《Prompt Caching 作为 Harness 工程的一等约束》里单独写过这件事：cache hit rate 不只是成本优化指标，它会反过来约束 prompt、工具列表、compaction 和 sub-agent 的设计。在工程实践中，这意味着 agent 的 prompt 编排不能再随意地动态拼接。设计者需要将提示词结构进行分层和模块化改造，确保静态前缀在时间轴上保持稳定，从而提升缓存命中率。 ### 别把工具垃圾倒进上下文 许多 agent 系统在运行时容易显得臃肿，原因在于其上下文窗口中积压着大量无意义的噪声，例如工具调用返回的未经格式化的长日志、上一次失败尝试的冗余历史，以及检索机制检索出的无关文档。 针对这一问题，开发团队需要引入上下文精简与治理机制。Anthropic 在其关于有效上下文工程的研究中提供了实用的建议。例如，在设计 agent 的工具链时，应避免将环境的原始输出直接扔回上下文窗口，而是设计专门的轻量级序列化逻辑，仅提取决策所需的关键字段。在任务阶段发生切换时，系统需要主动清空不再需要的历史交互，或者将它们压缩为任务状态摘要。 这种上下文精简的需求，也是智能体记忆技术走向商业化的推手。在风投机构 Kleiner Perkins 投资记忆服务商 Engram 的案例中，投资方明确将记忆能力定位成节省企业 token 成本的手段；而 Engram 自己在 9800 万美元的融资声明中，也将“让 AI 拥有组织记忆”作为卖点。虽然这些宣传带有明显的商业包装色彩，不能当作中立的 benchmark，但它印证了一个工程常识：上下文的精细治理不仅是为了让模型更聪明，更是为了让它的每次运行都符合商业合理性。 ### 别让旗舰模型做所有杂活 在 agent 复杂的决策树中，并非每一个推理步骤都需要动用旗舰级大模型。对于初始的意图分类、状态参数提取、或是最终的输出格式校验，轻量级模型通常可以胜任，且成本往往只有旗舰模型的几十分之一。 这就是模型动态路由（model routing）发挥作用的地方。目前，Azure Model Router 和 OpenRouter Auto Router 已经在云端提供了开箱即用的路由支持，学术界和工业界也在围绕 RouteLLM 探讨动态分配请求的策略，论文和产品都在探索这条路线。在工程落地时，动态路由面临的挑战在于防止由于轻量模型误判引起的质量波动，这要求在路由层与执行层之间建立清晰的边界和容错机制。 ### 省钱策略要有 eval 托底 任何成本优化方案如果不经过严格的质量验证，在生产环境中都容易产生隐患。为了衡量精简上下文和切换模型后系统表现是否下滑，agent 架构需要引入基于评测的动态路由（eval-driven routing）。 这种设计要求系统在后台持续运行自动化的内部评测集（evals）。一旦检测到精简版上下文或轻量模型导致任务成功率降低，路由控制面应能在运行中自动 fallback，回退到更强的模型或完整的上下文。 Agent 成本控制面位于模型外部，由缓存、上下文选择、工具输出治理、模型路由和 eval fallback 共同决定 cost per accepted task ## 建立属于自己的智能账本 实施上述控制策略的前提，是开发团队有能力测量自己系统的真实用量。 目前，行业中还缺乏衡量每美元智能的统一标准。虽然 Artificial Analysis 推出的 Coding Agent Benchmarks 以及 SWE-bench 软件工程排行榜在代码生成等特定场景下提供了成本效率参考，但它们测试的任务往往局限在特定的代码修复场景中。传统的 HELM 框架或 MLPerf 则更侧重于基础模型能力或底层硬件能效，无法反映复杂 agent 在业务流程中的真实成本。 因此，更实用的策略是结合企业自身的实际任务分布，在内部建立一套清晰的核算账本。 账本的基本公式可以写为： ``` cost_per_accepted_task = (model_api_cost + tool_cost + infra_cost + human_review_cost + retry_cost) / accepted_task_count ``` 在这个公式中，除了通过 API 账单直接获取的模型成本（model_api_cost）之外，其余变量都需要依靠精细的遥测（telemetry）系统来收集： 工具成本 (tool_cost)：包括调用第三方 API、运行沙箱环境或检索外部向量数据库消耗的费用。 出错重试成本 (retry_cost)：记录由于生成偏差或工具失效，在 agent 内部自动重跑或修正执行路径所耗费的额外 token 与算力。 人工复核成本 (human_review_cost)：当 agent 无法自主闭环、需要将控制权转交给人类操作员时，根据审核人员的花费时间折算的人工成本。 采纳任务数 (accepted_task_count)：最终由业务系统采纳，或者由终端用户标记为满意并实际使用的任务总量。 与之相匹配，开发团队可以在看板中追踪一组主要指标：预算内任务成功率（success rate under budget）、P95 响应延迟、自动回退率（fallback rate）、重试率（retry rate）、缓存命中率（cache hit rate）、人工介入率（escalation rate）以及人工作业时长（human review minutes）。 这套内部测量体系不需要等待行业标准出台才开始建立，任何准备深度部署 agent 的团队，从早期就应在系统内部理清这笔账。 ## 结语 随着大模型早期补贴消退，AI 的工程化应用正在走向成熟。 在新的阶段，如果一个开发团队仍然将 agent 架构绑定在单一旗舰模型上，等于将自身的业务生存空间和财务弹性交由外部模型厂商决定。一旦厂商调整 API 定价、更改缓存逻辑或升级模型，开发团队将缺乏优化余地。 相反，在架构中设计了成本控制面的 agent 系统，才能在模型费率、缓存策略和任务分布发生变化时，找到更具性价比的平衡点。 未来的 AI-native 产品，不再需要通过标榜消耗了多少 token 或调用了多大规模的模型来证明自身的先进。真正的差异化在于：在相同的一美元预算下，你的系统能稳定、可靠地交付多少个符合预期的任务结果。