Agent 的下一场成本战：不是 Token，而是端到端调度

讨论 AI 成本时，行业习惯先看每百万 Token 的价格。但 8 月 5 日一篇基于 Microsoft Azure 生产研究与开源框架实验的论文提醒我们：Agent 不是一次推理请求，而是一串模型调用、工具执行和编排判断。Token 只是账单的一部分，系统如何等待、切换和恢复，正在成为更大的成本来源。

普通在线推理相对规整：请求进入 GPU，模型生成结果，响应返回。Agent 工作流却是碎片化的。模型先做计划，CPU 执行编排，工具可能访问网络或文件，结果再回到模型；中途还会并行子任务、调用不同模型、等待外部服务。CPU 与 GPU 之间反复跨越，任何一处停顿都会拉长尾延迟。

论文的一个重要观察是，CPU 重新进入关键路径。过去模型服务优化主要关注 GPU 利用率，而 Agent 的工具、运行时和决策大量运行在主机端。CPU 在平时负载偏低，却会在工具返回或多个任务汇合时突然出现尖峰。按照稳定平均值配机器，会同时造成闲置和拥塞。

GPU 也不再只是“越多越好”。不同 Agent 可能使用不同模型和上下文长度，工作流结构决定负载何时出现。模型等待工具时，显存里的状态仍然占用资源；多个 Agent 同时恢复，又可能形成突发。传统均匀服务器很难匹配这种异质、间歇的需求。

研究中的 Agora 原型尝试按角色池化 CPU、利用空闲核心、保护工具尖峰下的尾延迟，并通过显存超配和预取容纳更多 Agent。具体收益仍需要在更多工作负载中验证，但方向很清楚：Agent 基础设施要调度的是完整任务图，而不是孤立的模型请求。

这个变化会重写单位经济模型。假设一家产品把模型价格降低 30%，却让 Agent 因工具失败重试三次，整体成本仍可能上升。相反，一个模型单价稍高，但计划更稳定、工具调用更少、恢复更快，最终每次有效交付反而便宜。企业真正应该比较的是 cost per successful task。

因此，成本仪表盘也要改变。除了 Token 与模型费用，还应记录 CPU 时间、GPU 等待、工具时延、重试次数、并行扇出、上下文重建、人工接管和失败任务的沉没成本。没有任务级归因，团队只会看到云账单上涨，却不知道是模型贵、工具慢还是编排失控。

并行尤其需要克制。让十个 Agent 同时探索看起来更快，但它会放大上下文、模型调用和结果合并的成本。如果任务只有一个窄瓶颈，更多并行只会制造重复工作。合理做法是把并行留给相互独立、结果可比较的分支，并给每个分支明确预算和停止条件。

缓存也不能只做提示前缀缓存。Agent 系统需要缓存可验证的中间产物：已解析文档、通过测试的代码片段、工具返回的稳定数据和任务检查点。缓存对象越接近业务事实，模型更换后越能复用；如果只缓存自然语言对话，状态一变化就容易全部失效。

长任务恢复是另一个隐藏成本。进程重启、网络超时或权限过期后，如果系统只能从第一步重新运行，就会重复消耗模型和工具资源。把任务拆成有输入、输出和验证状态的节点，可以从最后一个可靠检查点继续，也让团队知道失败集中在哪里。

调度器最终还要理解质量，而不只是资源。低风险草稿可以走便宜模型，高风险决策需要更强模型和独立验证；工具连续失败时应该停止，而不是无限重试。把质量门槛、风险级别和资源预算放进同一策略，才能避免基础设施为了吞吐牺牲交付可信度。

对产品经理来说，速度指标应从平均响应时间转向完成时间分布。Agent 的首个字出现得很快并不重要，用户关心的是任务什么时候可用。P50 可以体现顺畅体验，P95 和 P99 则暴露外部工具、长尾重试与资源争抢。只有观察尾部，才能避免少数昂贵任务吞掉利润。

基础设施厂商会因此出现新的分层：模型网关负责路由与价格，Agent 运行时负责任务状态和权限，调度层优化 CPU、GPU 与工具并发，可观测平台计算任务级质量和成本。它们可能被整合进云平台，也可能形成跨云、跨模型的独立控制面。

创业团队不需要立即自建 Agora，但可以先做四件低成本的事：给每个任务分配 ID 和预算；区分模型时间、工具时间与排队时间；保存可恢复检查点；用成功交付而不是调用次数计算成本。只要把账算到任务层，许多“模型太贵”的问题会暴露为流程设计问题。

模型价格还会继续下降，推理能力也会继续增强，但这不会自动让 Agent 业务更便宜。能力越强，系统往往会让它承担更长、更复杂的工作。下一轮工程优势来自调度：在正确时间使用正确模型和工具，让空闲资源被复用，让失败局部化，并让每一分钱最终对应一个可验证结果。