智能体任务模型分层选型：成本、速度与可靠性

一、为什么需要模型分层

智能体系统通常同时承载两类负载。一类是高频、短链路的操作，例如页面点击、表单填写、数据字段抽取。这类任务单次判断简单，但调用次数多，对延迟和单位成本敏感。另一类是低频、长链路的任务，例如跨文档综合分析、复杂代码改造、多步规划。这类任务单次决策难度高，错误代价大，对推理能力和上下文处理能力的要求更高。

如果全部使用同一个高端模型，成本会随调用量线性上升。如果全部使用小模型，复杂任务的失败率会拉高整体成本，因为重试和人工修复的开销往往超过模型差价。分层的目标是让每类任务落在”刚好够用”的模型上，并且有明确的依据。

分层前需要回答三个问题：任务的失败代价是多少，任务的调用频次是多少，任务是否依赖长上下文。这三个问题的答案决定了模型档位和后续的监控指标。

二、选型的四个维度

1. 单位任务成本

模型的标价是每百万 token 的单价，但业务真正关心的是完成一个任务的成本。两者差异主要来自三个方面。

第一，任务步数。同一目标在不同模型上可能需要不同的调用次数。推理更强的模型有时用更少的步骤完成任务，小模型则可能需要多次试错。

第二，重试率。输出格式错误、工具调用参数不合法、结果需要人工复核，都会产生额外调用。

第三，缓存命中。系统提示词、工具定义、固定文档等前缀内容若能命中缓存，输入成本会显著下降。缓存策略需要在架构层面设计，不能只依赖模型本身。

因此，选型应以”每完成一个任务的期望成本”为基准，而不是比较单价表。

2. 任务完成时延

延迟有两种度量方式，结论可能相反。

• 单 token 生成速度：反映模型输出的吞吐量，适合衡量长文本生成。
• 任务端到端耗时：从接收指令到任务结束的挂钟时间，包含所有推理、工具调用与等待时间。

智能体场景更应关注第二种。一个生成速度较慢但步骤更少的模型，端到端耗时可能更短。测量时应记录每个任务的步数、每步耗时和总耗时，并按任务类型分别统计。

3. 推理与长上下文能力

上下文窗口的数值只说明模型能接收多少输入，不说明它能否有效利用这些输入。长上下文场景要评估两件事：关键信息的召回率，以及在信息分散时的推理一致性。

常见的验证方法是在长文档中埋入已知事实，再提出需要综合多处信息才能回答的问题，统计正确率随文档长度的变化曲线。如果曲线在某个长度后明显下降，系统应在该长度前切分文档或引入检索环节。

4. 幻觉与误操作代价

在对话场景中，幻觉主要影响答案质量。在智能体场景中，幻觉可能直接导致错误的点击、错误的字段写入或错误的接口调用。两者的代价不对称：不执行操作的失败通常可以重试，错误执行的操作可能需要回滚，甚至造成数据损失。

衡量幻觉应使用与业务相关的评测集，而不是通用榜单。评测集可以包含以下内容：

• 页面状态与目标元素不一致的样本
• 参数缺失或格式模糊的指令
• 需要拒绝执行的越权或高风险请求

对于高风险操作，建议在执行前增加确认步骤，由系统校验目标对象、参数范围和权限边界，而不是完全依赖模型的自我判断。

三、单任务成本测算

1. 计算公式

设输入单价为 P_in，输出单价为 P_out，单位为每百万 token。若输入与输出的 token 比例为 r（输入占比），则混合单价为：

混合单价 = r × P_in + (1 − r) × P_out

若业务的输入输出比约为 3:1，则 r 取 0.75。若存在缓存，应将缓存命中部分的输入单价替换为缓存单价，再重新加权。

单任务期望成本为：

单任务成本 = 平均步数 × 每步 token 数 × 混合单价 ÷ 1,000,000 × (1 + 重试率)

这一公式把步数、重试和缓存纳入同一框架，便于对比不同模型的实际支出。

2. 示例代码

下面的代码给出一个可复用的计算函数。单价参数应替换为所用服务的实际报价，且需要定期核对。

from dataclasses import dataclass
@dataclass
class ModelPricing:
    name: str
    price_in: float        # 每百万输入 token 的单价
    price_out: float       # 每百万输出 token 的单价
    price_cached_in: float # 每百万缓存命中输入 token 的单价
    avg_steps: float       # 该模型完成同类任务的平均步数（来自评测）
    retry_rate: float      # 因格式错误或校验失败导致的重试比例
def cost_per_task(
    model: ModelPricing,
    tokens_in_per_step: int,
    tokens_out_per_step: int,
    cache_hit_ratio: float = 0.0,
) -> float:
    """计算单任务期望成本（单位：货币单位）。"""
    effective_in_price = (
        cache_hit_ratio * model.price_cached_in
        + (1 - cache_hit_ratio) * model.price_in
    )
    per_step = (
        tokens_in_per_step * effective_in_price
        + tokens_out_per_step * model.price_out
    ) / 1_000_000
    return model.avg_steps * per_step * (1 + model.retry_rate)
def compare(models: list[ModelPricing], tokens_in: int, tokens_out: int) -> None:
    for m in models:
        cost = cost_per_task(m, tokens_in, tokens_out, cache_hit_ratio=0.6)
        print(f"{m.name}: 单任务期望成本 {cost:.6f}")

使用时应注意两点。第一，avg_steps 与 retry_rate 必须来自自有评测数据，不能沿用其他团队或公开报告的数字。第二，cache_hit_ratio 取决于提示词结构是否稳定，前缀内容频繁变化会导致缓存失效。

3. 结果解读

一个模型的单价低，不代表单任务成本低。若小模型的平均步数是大模型的两倍，重试率又更高，它的单任务成本可能反而更高。反过来，若大模型在复杂任务上只需一半的步数，即使单价较高，总成本也可能更低。因此，分层决策应基于同一评测集上的完整成本数据。

四、路由策略与分层架构

分层的实现依赖一个路由层。路由层根据任务特征选择模型档位，并在失败时升级到更强的档位。

常见的路由规则包括以下几类：

• 任务类型：页面操作、信息抽取等固定模式的任务进入小模型，开放式分析进入大模型。
• 风险等级：涉及写入、删除、支付、权限变更的操作必须经过强模型复核，或由规则引擎直接校验。
• 上下文长度：超过阈值的输入先经过检索或切分，再决定模型档位。
• 失败升级：小模型输出未通过校验时，自动重试一次，仍失败则升级到大模型。

下面是一个简化的路由示例。

from dataclasses import dataclass
@dataclass
class TaskProfile:
    expected_steps: int   # 预计调用步数
    is_write_op: bool     # 是否包含写入或删除操作
    context_tokens: int   # 输入上下文长度（token 数）
def select_tier(task: TaskProfile, context_limit: int = 32_000) -> str:
    if task.is_write_op:
        return "large"
    if task.context_tokens > context_limit:
        return "large"
    if task.expected_steps <= 5:
        return "small"
    return "medium"
def run_with_escalation(task, call_model, validate):
    tier = select_tier(task)
    result = call_model(tier, task)
    if validate(result):
        return result
    # 校验失败时升级一档，避免小模型的错误直接进入后续步骤
    next_tier = {"small": "medium", "medium": "large"}.get(tier, "large")
    return call_model(next_tier, task)

路由规则应与评测结果保持一致。如果某类任务在小模型上的校验通过率长期稳定在较高水平，可以将其固定到小模型。若通过率波动较大，应保留升级路径。

五、可靠性控制

1. 结构化输出与校验

智能体的每一步输出都应符合预定义的结构，例如 JSON Schema 或强类型的工具参数定义。校验器应独立于模型运行，检查字段类型、取值范围和必填项。校验失败时返回明确的错误信息，供模型修正，而不是直接忽略。

2. 操作前的状态确认

在页面操作类任务中，点击前应确认目标元素的状态，包括可见性、可交互性和文本内容。若目标与预期不一致，系统应暂停并重新获取页面快照，而不是依赖模型猜测。

3. 不可逆操作的人工确认

删除数据、发送消息、修改权限等操作应设置确认门槛。门槛可以是人工审批，也可以是基于规则的二次校验。确认环节的设计应保证操作目标与用户意图一致，并记录完整的审计日志。

4. 评估与回归

每次更换模型版本或修改提示词，都应在评测集上重新运行。关注的指标包括任务成功率、误操作率、平均步数和单任务成本。若误操作率上升，即使成本下降，也应视为回归。

六、上下文窗口的正确用法

长上下文能力容易被高估。窗口越大，系统越容易把无关内容一并塞入，导致模型注意力分散，推理质量下降，同时输入成本也随之增加。

更稳妥的做法是先检索，再推理。常见流程如下：

1. 将长文档切分为语义完整的片段，并建立索引。
2. 根据问题检索最相关的若干片段。
3. 把检索结果与必要的背景信息一起送入模型。
4. 要求模型给出引用位置，便于人工核对。

只有在检索难以覆盖全文关系的场景，例如跨章节的因果推理，才值得使用完整长文输入。此时仍需用召回率测试验证效果，而不是默认长窗口一定更好。

七、落地步骤

建议按以下顺序推进分层改造。

第一步，梳理任务类型。列出系统中所有智能体任务，按调用频次、失败代价和上下文长度打标。

第二步，构建评测集。每类任务至少准备数十条样本，覆盖正常情况、边界情况和应拒绝的情况。评测集应由业务人员参与标注。

第三步，跑基线。对候选模型运行评测，记录成功率、步数、重试率、端到端耗时和单任务成本，形成可比的数据表。

第四步，设计路由与校验。根据基线结果确定分层规则，并为高风险操作增加独立校验。

第五步，灰度上线。先让小比例流量走新路由，同时保留旧方案作为对照，观察误操作率与用户反馈。

第六步，持续监控。设置成本、成功率和误操作率的告警阈值，并在模型或价格变化时重新评估分层方案。

八、常见误区

只看单价。 单价忽略了步数、重试和缓存，容易得出错误结论。

只看通用榜单。 通用榜单与具体业务的任务分布可能差异很大，应以自有评测集为准。

忽略重试成本。 重试会同时增加费用和延迟，还可能放大错误操作的影响。

把窗口大小当作能力。 能接收更多输入，不等于能有效利用这些输入。

忽略提示词稳定性。 频繁修改的前缀会让缓存失效，成本优化会被抵消。

跳过高风险确认。 为了省成本而取消人工或规则校验，通常会在首次事故中付出更高代价。

智能体的模型分层是一项工程决策，核心是用可复现的数据替代经验判断。团队应把评测、成本核算和风险控制放在同一套流程中，让每次模型选择都有明确依据。