一次 Agent 任务可能消耗 3400 倍 Token，AI 中转站该怎么控成本

一次 Agent 任务可能消耗 3400 倍 Token，AI 中转站该怎么控成本

微软负责 Azure 硬件系统与基础设施的 Rani Borkar 在 9 月 1 日提出了一个醒目的数字：单次 Agent 任务使用的 Token，可能超过一次典型聊天交互的 3400 倍。这个比例来自微软 AI Diffusion Report，适合用来理解工作负载量级变化，不能直接当作每个项目的成本预测。不同 Agent 的循环次数、上下文长度、工具返回内容和失败重试差异很大，账单最终仍要靠自己的调用日志计算。

普通聊天往往是一问一答，Agent 会规划步骤、读取文件、检索知识库、调用外部工具，再根据结果继续推理。一次用户请求在后台展开成十几次甚至更多模型调用并不意外。长上下文被每轮重复携带、工具返回整页原文、失败后从头重试，都会让 Token 增长快于任务数量。团队只盯模型输入输出单价，很容易低估一条完整工作流的真实费用。

成本单位要从请求改成任务

对 AI 中转站和大模型 API 中转用户来说，最先要改的是报表口径。每次请求的 Token 与费用仍需保留，但产品负责人更需要看到“完成一张工单”“修复一个缺陷”“生成一份合规摘要”分别花了多少钱。为此，网关要把同一 Agent 运行中的模型调用、工具调用和重试挂到统一 task_id，日志至少记录模型、输入输出 Token、缓存命中、延迟、状态码和上游业务标识。

有了任务级数据，优化才不会变成盲目换便宜模型。规划、代码分析和复杂判断可以保留能力更强的模型；分类、格式转换、摘要和简单校验交给更轻量的模型；确定性计算交给代码工具。长上下文要按需要检索，工具结果只返回相关字段，失败重试设置上限并区分可重试错误。模型路由的目标，是在质量阈值以内减少无效推理，而非让所有请求都走最低单价。

缓存也要结合内容性质使用。稳定的系统提示、工具说明和长文档前缀适合前缀缓存，频繁变化的用户数据则需要明确失效策略。若同一段上下文在多轮中不断增长，可在阶段边界生成结构化状态并丢弃原始过程。压缩前后要用固定任务集回归测试，避免省下 Token 却丢掉关键约束。涉及代码合并、财务或安全决策时，抽样交给独立模型或人工复核，费用应纳入任务成本而非隐藏在“质检”之外。

统一模型网关还要管住异常放大

Agent 成本失控常由异常路径触发。某个工具持续返回空结果，模型不断改写查询；上下文超过限制后，客户端自动缩短再重试；上游接口限流，多个并发任务同时退避重发。单次请求看起来都符合配额，累计消耗却会在短时间内陡升。网关因此需要同时设置用户、项目、模型和任务四个层级的预算，达到软阈值时告警或降级，触及硬阈值时停止自动循环并要求人工确认。

多供应商路由还要处理能力差异。OpenAI 兼容 API 解决了请求格式问题，并不保证不同模型对工具调用、结构化输出、上下文窗口和错误码的行为一致。切换模型前应运行一组真实任务，比较完成率、总 Token、P95 延迟和人工返工，而不是只测一条聊天提示。供应商故障时的备用路由也要限制重放范围，避免已经执行成功的外部动作被重复提交。

微软讨论的是从芯片到数据中心的“有效产出”，应用团队可以把它落到一个更近的指标：每完成一项有用任务，消耗多少模型、工具和人工资源。准备接入多模型的团队，可在 [AnyAIS 模型列表](/models) 对照可用模型，并通过统一接口保留任务级调用记录。先看每项任务的完整曲线，再决定该换模型、缩短上下文还是重做工作流。

来源：[Microsoft：The yield imperative](https://blogs.microsoft.com/blog/2026/09/01/the-yield-imperative-turning-ai-infrastructure-into-useful-intelligence/)