budget_quality_latency进阶约 80 分钟

资源感知：在质量、速度和费用之间做工程决策

参考：来源 F · 第 16 章

学完你能做到

给 Agent 设置可执行的多维预算
设计模型路由、降级和提前停止
理解最贵模型不应承担每一个步骤

Agent 的资源不只有 token。一次任务还消耗时间、模型费用、工具配额、并发槽位、带宽和人的审核精力。的作用，是让“再查一次也许更好”与“现在已经足够可靠”之间有明确边界。

预算	常用限制	超限后的动作
质量	证据覆盖率、评估分数、风险等级	升级模型或转人工
延迟	首字时间、总时长、单工具超时	并行、缓存、返回阶段结果
费用	每任务金额、token、付费 API 次数	摘要上下文、换便宜模型、提前停止
执行	最大循环、最大工具调用、并发数	停止、重规划或排队
人工	审核队列长度、值班容量	只升级高风险项

不存在同时最便宜、最快、最准确的单点。产品要根据任务风险选择质量-成本前沿上的位置。

模型路由不能只看“贵”和“便宜”

先用规则判断硬边界：是否需要视觉、超长上下文、特定工具或数据驻留。
再估计复杂度和风险：简单抽取可用快速模型，高风险综合交给更强模型并增加验证。
主模型失败时，后备模型必须满足同一输出契约；降级后能力不足要明确告知。
便宜分诊器的误判率也要评估，否则会把困难任务错误地下放。
缓存、批处理、上下文裁剪和结果复用通常比盲目换模型更省钱。

把预算写进循环，而不是只写进报表

budget = {money: 0.20, seconds: 30, tool_calls: 6, steps: 8}
while not done:
  if budget.exhausted(): return partial_result_with_limits()
  action = choose_next_action(remaining=budget)
  result = execute(action)
  budget.consume(result.usage)
  done = success_criteria_met(result)

常见误解

给所有步骤都用最强模型，系统质量一定最高。

实际上

简单步骤会浪费预算，且更多推理并不保证更正确。把预算留给高风险判断、冲突证据和最终验证更有效。

预算设计

15 分钟

为“听力交卷后生成导师报告”设置时间、调用、费用和证据预算。
设计主模型不可用时的两级降级。
说明什么情况下宁可返回部分结果，也不应继续重试。

案例推演：高峰期为什么不能让所有请求都用最强模型

考试周并发暴涨。短问答、论文深读和报告生成同时进入系统。若统一使用最贵模型并无限排队，延迟、成本和超时会一起恶化。

本节追问：如何让质量、速度、费用和可用性成为显式决策？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。

四步案例推演。手机上可左右滑动查看；每个箭头都代表一次需要证据支撑的状态转换。

阶段	本步要做的决定	什么算证据	最常见的失败
任务分级	按复杂度、风险和时效标记请求	分级规则可测且有兜底	按用户问题长度粗暴判断难度
能力路由	轻任务用快模型，复杂任务升级	升级由失败信号或质量门槛触发	价格最低模型处理全部高风险任务
流量控制	设置并发、队列、背压和超时	过载时系统可预测地降级	请求无限堆积直到整体雪崩
预算收口	每任务限制 token、工具次数和总时间	预算耗尽返回可用的部分结果	中途直接报“系统错误”且丢失成果

阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。

常见误解

只做主模型失败后的 fallback

实际上

可观察症状：故障时所有流量同时打向备用模型，备用也被压垮。

更可靠的修复：容量规划、熔断、分级降级和预算路由共同设计。

案例工作坊 · 建议真正动手完成

25 分钟

为三类请求设计模型、超时和工具预算。
画出主模型过载时的熔断与恢复流程。
写一个保留证据基线的降级响应。

查看参考答案

资源感知不是单纯省钱，而是在约束下保持可预测质量。路由、队列、背压、预算、缓存和降级需要联合设计。

迁移检查：换一个场景还会不会

系统过载时，背压的作用是？