跳到主要内容

成本-延迟-质量权衡

核对日期：2026-05-09。

1. 定义与边界​

成本、延迟、质量权衡是把 Agent 的业务目标转化为模型、工具、上下文和运行时预算的过程。不能只看单次模型调用价格；真实成本包括重试、工具调用、检索、缓存、人工审批、失败返工和观测存储。

2. 为什么重要​

Agent 往往是多轮、多工具、多模型链路。一个看似便宜的模型如果导致更多重试或人工修复，实际成本可能更高；一个更强模型如果让 p95 延迟超出用户容忍，也无法上线。

3. 核心机制​

变量影响成本影响延迟影响质量
模型大小/推理预算高高复杂任务通常更好
输入上下文高高证据充分但可能噪声增加
工具调用次数中到高高外部事实更准
重试策略高高可恢复临时失败
人类在环人力成本高高风险任务更可靠
缓存低低需避免陈旧数据

4. 架构模式​

5. 工程实现​

定义任务预算：

budgets:
  support_answer:
    max_total_cost_usd: 0.05
    max_latency_ms_p95: 4000
    min_groundedness: 0.95
  code_change_plan:
    max_total_cost_usd: 1.00
    max_latency_ms_p95: 45000
    min_task_success_rate: 0.85
    human_review: true

运行时计算：

cost = sum(call.input_tokens * call.input_price + call.output_tokens * call.output_price for call in trace.model_calls)
latency = trace.finished_at - trace.started_at
if cost > budget.max_total_cost or latency > budget.deadline:
    raise BudgetExceeded()

6. 生产实践​

  • 用“每个成功任务成本”而不是“每次调用成本”做决策。
  • 对高频低复杂任务使用快速模型、缓存和批处理。
  • 对复杂高风险任务允许高成本，但必须有验收标准和人工升级。
  • 将模型输出 token、工具次数、重试次数作为报警指标。
  • 将 token 预算拆分到系统、任务、证据、历史和输出保留。

7. 常见反模式​

反模式问题
只压模型单价失败率上升，总成本更高
不设 max_steps循环调用导致成本失控
过度长上下文证据噪声、延迟和费用上升
只优化平均延迟p95/p99 用户体验失败
缓存所有内容隐私、陈旧和权限问题

8. 评测方法​

离线评测要同时输出质量、成本和延迟三列。线上评测应按 route、模型、工具、租户和任务类型分桶，避免平均值掩盖某个高风险路径。

score = success_rate * business_value
        - cost_per_task * cost_weight
        - p95_latency_penalty
        - safety_violation_penalty

9. 安全与治理​

成本优化不能降低安全边界。不要为了省钱跳过脱敏、权限检查、审计日志和人工审批。对供应商缓存和日志保留策略要按企业数据政策核对。

10. 决策框架：三角权衡不是口号​

成本、延迟、质量要落到不同任务等级上，而不是全局追求“又便宜又快又好”。

任务等级例子优先级推荐策略
A: 高风险高价值生产变更、资金、法务质量和安全优先推理模型 + 审批 + 完整 trace
B: 中风险业务客服退款判断、销售线索处理成功率和延迟平衡分层模型 + verifier
C: 低风险高频摘要、分类、改写成本和吞吐优先快速模型 + 缓存 + 批处理
D: 探索分析数据分析、调研草稿质量和可解释异步执行 + 成本上限

11. 预算模型与容量规划​

成本预算应按 trace 聚合：

{
  "run_id": "run_123",
  "budget": {
    "max_cost_usd": 0.50,
    "max_latency_ms": 30000,
    "max_model_calls": 4,
    "max_tool_calls": 8
  },
  "actual": {
    "model_cost_usd": 0.18,
    "tool_cost_usd": 0.03,
    "retry_cost_usd": 0.02,
    "latency_ms": 18420,
    "success": true
  }
}

容量估算：

daily_budget =
  daily_tasks
  * expected_model_calls_per_task
  * avg_tokens_per_call
  * provider_price
  / expected_success_rate

但上线容量更应关注 p95/p99：

指标触发动作
p95 latency 超 SLA降低上下文、异步化、分层路由
retry rate 升高检查工具、schema、供应商状态
cost per success 升高检查失败重试和路由误判
approval queue 积压调整风险分级或增加审批人

12. 质量门禁​

质量不能只用人工主观评分。建议把质量拆成可自动和人工结合的指标：

质量维度自动评测人工评审
格式正确schema pass rate无
事实一致引用覆盖、工具结果匹配抽样核查
任务完成断言检查、业务模拟器专家验收
安全合规policy violation count红队样例复核
用户体验延迟、澄清次数话术和流程评审

13. 成本优化的安全红线​

以下优化不应通过：

  • 为省 token 删除系统安全规则和审批说明。
  • 为降延迟跳过权限检查、脱敏、审计写入。
  • 为省钱把高风险写操作路由到未经评测的小模型。
  • 缓存含敏感数据的上下文且不按租户隔离。
  • 降级时从合规供应商切到不满足数据政策的供应商。

14. 实验设计​

每次优化只能主要改变一个变量：

实验改变量固定项
模型替换model idprompt、schema、数据集
上下文压缩evidence/history 预算model、prompt
推理预算reasoning effort/thinking budgetroute、tools
工具 schema字段描述和约束model、prompt
缓存prompt/context cachemodel、数据权限

输出报告必须包含成功率、成本、延迟、安全违规和样例失败分析。

15. 权威资料​