# AI Agent 上线前，先把模型路由和成本闸门做出来

很多企业做 AI Agent 试点时，成本问题通常被低估。

Demo 阶段请求量小，大家更关心能不能跑通：模型能不能理解任务，工具能不能调通，答案看起来是不是合理。等系统接入真实业务以后，另一个问题会很快出现：每个请求都在打大模型，每条链路都在走完整推理，失败还反复重试，最后账单、延迟和稳定性一起失控。

这不是单纯的“模型太贵”问题，而是系统没有成本控制面。

生产级 Agent 至少要提前回答 5 个问题：

- 哪些任务可以用小模型、规则或缓存解决？
- 哪些任务必须走高能力模型？
- 工具调用失败后最多重试几次？
- 单个用户、单个客户、单个流程的预算上限是多少？
- 每次成本能不能追到具体任务、工具和模型版本？

如果这些问题没有答案，Agent 上线后很容易变成一个不可解释的成本黑盒。

## 1. 不要让所有任务默认走最贵模型

很多 Agent 的第一版实现很直接：把用户请求、上下文、工具说明全部塞给一个最强模型，让它决定下一步怎么做。

这个方式适合验证能力，不适合生产运行。

真实系统里的任务复杂度差异很大。比如：

- 简单分类：判断用户问题属于售前、售后还是账务；
- 信息抽取：从工单里提取订单号、设备号、错误码；
- 检索改写：把用户问题改写成查询语句；
- 风险判断：判断一个动作是否需要人工确认；
- 多步规划：拆解任务、选择工具、检查结果并给出下一步。

这些任务不应该全部走同一个模型。

可以先建立一个任务分级表：

```yaml
agent_task_tiers:
  tier_0:
    name: deterministic
    examples:
      - format_validation
      - allowlist_check
      - duplicate_request_check
    executor: rules
  tier_1:
    name: low_reasoning
    examples:
      - intent_classification
      - entity_extraction
      - query_rewrite
    executor: small_model
  tier_2:
    name: bounded_reasoning
    examples:
      - policy_match
      - evidence_summary
      - risk_hint
    executor: mid_model
  tier_3:
    name: high_reasoning
    examples:
      - multi_step_plan
      - exception_analysis
      - customer_facing_decision_draft
    executor: strong_model
```

这个表不是为了追求架构漂亮，而是为了避免“所有问题都按最贵路径处理”。

生产环境里，模型能力应该被调度，而不是被默认使用。

## 2. 模型路由要基于任务、风险和证据质量

模型路由不是简单地按价格选模型。便宜模型不等于低风险，贵模型也不等于可以直接放行。

一个更可靠的路由策略，至少要看 3 个维度：

- 任务复杂度；
- 业务风险等级；
- 当前证据质量。

比如同样是“总结客户情况”，如果只是内部客服看摘要，可以走低成本模型；如果摘要会进入客户通知或影响赔付建议，就要提高路由等级，并加人工确认。

可以把路由逻辑做成显式配置：

```json
{
  "route": "customer_support_summary",
  "conditions": {
    "task_complexity": "medium",
    "risk_level": "medium",
    "evidence_quality": "complete"
  },
  "model_policy": {
    "primary": "mid_reasoning_model",
    "fallback": "strong_reasoning_model",
    "max_retries": 1,
    "requires_human_review": false
  }
}
```

再看一个高风险动作：

```json
{
  "route": "refund_decision_draft",
  "conditions": {
    "task_complexity": "high",
    "risk_level": "high",
    "evidence_quality": "partial"
  },
  "model_policy": {
    "primary": "strong_reasoning_model",
    "fallback": "none",
    "max_retries": 0,
    "requires_human_review": true
  }
}
```

注意第二个例子里没有 fallback。

生产系统里并不是所有失败都应该重试，也不是所有证据不足都应该换一个更强模型继续猜。高风险动作证据不足时，正确动作通常是停止、记录、转人工。

## 3. 给每条链路设置预算和熔断

Agent 成本失控通常不是某一次调用特别贵，而是很多小失控叠加：

- 检索结果太多，prompt 变长；
- 工具调用失败后反复重试；
- fallback 模型层层升级；
- 每次请求都重新总结同一份资料；
- 用户刷新页面触发重复任务；
- 多个 Agent 互相调用，没有全局预算。

所以预算不能只看“单次模型价格”，还要按业务链路设置上限。

一个最小可用的预算策略可以这样写：

```yaml
budget_policy:
  per_run:
    max_model_calls: 6
    max_tool_calls: 12
    max_total_tokens: 24000
    max_estimated_cost_usd: 0.35
  per_customer_per_day:
    max_runs: 300
    max_estimated_cost_usd: 80
  circuit_breakers:
    tool_failure_rate_10m: 0.15
    avg_latency_ms_10m: 8000
    budget_burn_rate_1h: 1.5
```

关键是熔断必须能影响运行，而不是只在报表里展示。

当工具失败率过高时，系统应该暂停相关流程；当预算燃烧速度异常时，系统应该降级到只读模式或人工处理；当某个客户的调用量异常时，系统应该先限流再排查原因。

## 4. 缓存不是可选项，而是成本控制的一部分

很多 Agent 成本高，是因为系统在反复做同一件事。

常见重复包括：

- 每次都重新总结同一份合同；
- 每次都重新解析同一批设备日志；
- 每次都重新生成同一个客户画像；
- 每次都重新检索同一组政策文件；
- 每次都重新判断同一个权限边界。

这些工作应该有缓存和版本策略。

但缓存不能粗暴做。生产 Agent 的缓存至少要带上：

- 输入 hash；
- 数据版本；
- 权限上下文；
- 模型版本；
- 有效期；
- 是否允许跨用户复用。

示例：

```json
{
  "cache_key": "contract_summary:contract_7319:signed-v3:model-a",
  "scope": "tenant",
  "allowed_roles": ["legal", "account_owner"],
  "source_version": "signed-v3",
  "model_version": "model-a-202606",
  "ttl_minutes": 1440,
  "contains_sensitive_fields": false
}
```

没有权限上下文的缓存很危险。它可能把 A 用户能看的内容复用给 B 用户，也可能把旧版本资料继续用于新决策。

缓存的目标不是只省钱，而是在省钱的同时保持证据链可信。

## 5. 成本必须能追溯到业务动作

上线前最容易漏掉的是成本审计。

很多团队只看总账单：这个月模型费用多少，调用次数多少，平均 token 多少。但这些指标不够。业务负责人真正需要知道的是：

- 哪个流程最贵？
- 哪类任务最容易触发强模型？
- 哪个工具失败导致了最多重试？
- 哪个客户或用户的调用量异常？
- 哪些调用没有产生业务价值？

建议每次 Agent run 都记录一份成本明细：

```json
{
  "run_id": "run_20260622_001",
  "workflow": "customer_support_refund_draft",
  "tenant_id": "tenant_42",
  "steps": [
    {
      "step": "intent_classification",
      "executor": "small_model",
      "tokens_in": 820,
      "tokens_out": 64,
      "estimated_cost_usd": 0.002
    },
    {
      "step": "policy_match",
      "executor": "mid_model",
      "tokens_in": 4200,
      "tokens_out": 520,
      "estimated_cost_usd": 0.028
    },
    {
      "step": "decision_draft",
      "executor": "strong_model",
      "tokens_in": 6800,
      "tokens_out": 1100,
      "estimated_cost_usd": 0.19
    }
  ],
  "total_estimated_cost_usd": 0.22,
  "business_outcome": "human_review_required"
}
```

这种记录的价值很直接：如果某个流程贵但产出低，就要拆任务、降级模型、增加缓存或改成人工触发。

没有成本审计，优化只能靠感觉。

## 6. 一个上线前的成本验收清单

我会把 Agent 成本上线检查压缩成 8 项：

| 检查项 | 通过标准 |
|---|---|
| 任务分级 | 至少区分规则、小模型、中模型、强模型 |
| 路由策略 | 路由依据包含任务复杂度、风险、证据质量 |
| 预算上限 | 有 per-run、per-user、per-tenant 或 per-workflow 限制 |
| 重试规则 | 每个工具和模型调用都有最大重试次数 |
| 熔断策略 | 成本、延迟、失败率异常时能降级或停止 |
| 缓存策略 | 缓存带数据版本、权限上下文和 TTL |
| 成本日志 | 单次 run 能追到步骤级成本 |
| 复盘机制 | 每周能看到高成本流程和无效调用 |

这 8 项不需要一开始做得很复杂，但不能没有。

如果没有这些控制，Agent 只要请求量上来，就会从“能用”变成“不可控”。

## 一句话总结

生产级 AI Agent 不是把最强模型接进流程就结束了。

真正要做的是把模型变成可调度资源：低风险任务走低成本路径，高风险任务走强模型和人工确认，失败时能停止，异常时能熔断，成本能追溯到具体业务动作。

AgentKick 做 AI Agent Production-Readiness Review 时，会把模型路由、预算熔断、工具调用、审计日志和可观测性放在同一组检查里看。因为生产系统的问题通常不是模型单点能力，而是这些控制面有没有立住。