Agent 选型实操：Token 成本与多模型接入

agent-token-">为什么 Agent 的 Token 消耗容易失控

Agent 与普通聊天的区别在于，它会在一个任务里多次调用模型。每一轮调用都可能重新发送系统提示词、工具定义、历史对话和工具返回结果。一个典型任务的 token 消耗大致由以下部分组成：

总 token ≈ 系统提示词 + 工具定义 + 历史上下文（多轮累积）
         + 模型推理输出 + 工具返回结果回填

历史上下文是最容易被低估的部分。如果每轮都把完整历史发给模型，第 n 轮的输入会随 n 增长，整个任务的输入总量接近平方级增长。因此，同样是“十轮对话”，Agent 的账单可能是聊天的数倍。

本文不引用具体的周调用量排名。榜单数据会随统计口径和时间变化，需要读者到对应来源核对最新结果。本文关注的是可以自己测量和复现的部分。

选型：用真实任务代替榜单分数

公开基准可以帮助筛掉明显不合适的模型，但最终要用自己的业务任务验证。建议按下面几个维度打分：

维度	关注点	为什么重要
任务成功率	在自有任务集上的通过率	决定 Agent 能否独立完成目标
单任务成本	每完成一个任务的总费用	比每百万 token 单价更接近真实账单
延迟	P50 与 P95 响应时间	多轮调用会把延迟逐轮累加
上下文长度	能否容纳长文档与长代码库	影响检索增强与仓库级理解
工具调用稳定性	函数调用格式遵循度	决定编排流程是否容易中断
限流与配额	RPM、TPM 等额度	高频后台调用容易触发限流
接入成本	SDK 兼容性、迁移工作量	切换模型时的隐性成本

小流量验证可以按下面的模板执行：

1. 候选模型：选 2 到 4 个，覆盖旗舰模型和低价模型各一档。
2. 任务样本：每类任务取 50 到 100 条真实样本，并保留标准答案或验收规则。
3. 记录指标：每条任务的成功与否、失败类型、输入输出 token、延迟和费用。
4. 计算结果：每完成一个任务的成本 = 总费用 ÷ 成功任务数。失败任务的费用不能忽略，因为它们同样产生账单。
5. 判定：先排除成功率明显偏低的模型，再比较成本与延迟。

样本量较小时，两个模型的成功率差距可能只是随机波动。如果差距不大，应扩大样本后再做决策。

成本怎么算

单任务成本应区分输入、输出、缓存命中和重试：

单任务成本 = [未命中缓存的输入 token × 输入单价
            + 命中缓存的输入 token × 缓存单价
            + 输出 token × 输出单价] × （1 + 重试率）
月成本 = 单任务成本 × 日任务数 × 30

下面是一个示意算例。其中单价是为计算而设定的数字，不代表任何平台的实际报价，使用时应替换为官网报价。

假设：

• 每百万 token 价格：未命中缓存输入 2 元，缓存命中输入 0.2 元，输出 8 元。
• 一个任务累计输入 60,000 token，其中 70% 命中缓存（42,000 token），其余 18,000 token 未命中。
• 一个任务输出 6,000 token。
• 重试率 10%。

计算：

• 输入费用：18,000 × 2 ÷ 1,000,000 + 42,000 × 0.2 ÷ 1,000,000 = 0.036 + 0.0084 = 0.0444 元
• 输出费用：6,000 × 8 ÷ 1,000,000 = 0.048 元
• 单任务成本：（0.0444 + 0.048）× 1.1 ≈ 0.1016 元
• 若每天 500 个任务，月成本约 0.1016 × 500 × 30 ≈ 1,524 元

如果没有缓存，同样的输入全部按未命中价计算，单任务成本约为 0.185 元，月成本接近翻倍。缓存的收益取决于系统提示词和工具定义是否稳定。每次都改动前缀内容，缓存就无法命中。

公式未包含并发带来的额外开销，也未单列工具调用的网络与执行成本。这些应在上线前通过实际日志补充。

常见的优化方向有四个：

1. 上下文裁剪：只保留必要历史，长对话定期做摘要压缩。
2. 提示词精简：去掉工具定义和系统提示词中的重复描述。
3. 任务分级：简单任务路由到低价模型，复杂任务才使用旗舰模型。
4. 缓存复用：保持系统提示词和工具定义的前缀稳定，提高缓存命中率。

任务分级的效果取决于任务分布。如果大部分任务本身就很复杂，节省空间有限。应在自有样本上比较分级前后的成功率与费用，再决定上线比例。

多模型统一接入

Agent 应用常常需要多个模型：主推理用一个，简单任务用一个，故障时还要有备用。多套 SDK、多套鉴权和多套计费口径会拖慢开发效率。推荐抽象一层统一调用层，把模型配置、重试、降级和计量集中处理。

下面是伪代码，参数名需以各平台实际文档为准：

import time
import random
import uuid
RETRYABLE = (RateLimitError, TimeoutError, ServerError)
def chat(model_key, messages, timeout=30, max_retries=2, **kwargs):
    request_id = str(uuid.uuid4())
    candidates = [model_key] + fallback_chain(model_key)
    last_err = None
    for model in candidates:
        client = get_client(model)
        for attempt in range(max_retries + 1):
            start = time.time()
            try:
                resp = client.chat(messages=messages, timeout=timeout, **kwargs)
                record(request_id, model, resp.usage,
                       latency=time.time() - start, status="ok")
                return resp
            except RETRYABLE as e:
                last_err = e
                record(request_id, model, None,
                       latency=time.time() - start, status=type(e).__name__)
                # 指数退避加随机抖动，上限 8 秒
                time.sleep(min(2 ** attempt + random.random(), 8))
            except AuthError:
                # 鉴权错误重试没有意义，直接抛出
                raise
    raise last_err

实现时需要注意以下几点：

• 配置化路由：模型名、单价、限流阈值和降级链放在配置文件中，不写死在代码里。
• 统一计量：每次调用记录 request_id、模型名、输入输出 token、耗时和状态，便于后续做成本归因。
• 错误分类：区分可重试错误（限流、超时、服务端错误）与不可重试错误（鉴权、参数错误），避免对所有异常都盲目重试。
• 降级的兼容性：不同模型的工具调用格式和输出结构可能不同。切换到备用模型前，需要验证输出解析逻辑是否兼容。
• 非幂等操作：如果工具调用会发送消息、写数据库或扣款，重试可能造成重复执行。这类操作应在工具层做幂等设计。
• 灰度切换：新模型先接入一小部分流量，用成功率、延迟和单任务成本决定是否扩大比例。

接入时的风险与合规

多模型接入会引入新的风险，上线前应逐项确认：

• 个人信息与数据跨境：请求内容可能包含用户个人信息或企业敏感数据。需要确认供应商的数据存储地点、是否用于训练，以及是否符合所在行业的监管要求。
• 密钥管理：各平台的 API Key 应放在环境变量或密钥管理服务中，不写入代码或日志。应定期轮换，并为不同环境使用不同密钥。
• 供应商锁定：如果业务逻辑深度依赖某个平台的专有功能，迁移成本会很高。统一调用层可以降低这一风险，但不能完全消除。
• 配额与服务等级：应确认各平台的限流规则、可用性承诺和故障赔付条款，并将这些信息纳入降级策略设计。
• 日志与隐私：调用日志可能包含完整的提示词和输出，应做脱敏处理，并设置保留期限。

从调用量看趋势要谨慎

单周或单月的调用量变化，只能说明某一段时间内的使用情况。它无法证明某个模型会长期成为默认选择。在特定 Agent 工作负载下，开发者可能倾向于选择软件工程能力强、单任务成本低的模型。但这种倾向是否持续，需要更长时间的数据验证。

对开发者来说，更可靠的做法有三条：

1. 看单任务成本，不只看单价。 Agent 的账单主要由上下文管理方式决定。
2. 建立自己的评测集。 公开基准只能做初筛，真实业务任务的结果才能作为最终判断依据。
3. 保持接入层可替换。 模型格局变化较快，统一调用层与配置化路由可以降低切换成本。

关于推广信息

本文提及百度智能云词元所及其模型服务，属于推广信息。文中所有成本数字均为示意，实际价格以各平台官网公布的报价为准。读者在做选型决策时，应同时比较其他平台的能力、价格和合规条款，并用自己的业务数据做最终验证。