模型路由、成本与延迟要如何设计？

面试官：模型路由的目标是什么？第二层追问：是不是就是省钱？

我：路由不是只为了省钱。模型路由要同时满足 quality、tool capability、context window、latency、cost、stability、compliance 和 data policy。高风险代码修改、生产配置分析这类任务，宁可贵一点也要稳；摘要、分类、检索改写这种辅助任务，可以交给便宜模型。我的理解是，模型路由不是省钱小技巧，而是 Agent runtime 的资源调度和质量控制面。选模型时要看任务风险和能力需求，而不是简单用最便宜或最贵的。

面试官：Provider abstraction 怎么设计？第二层追问：内部消息格式选什么？

我：我会让内部说一种稳定语言，对外再翻译成 OpenAI、Anthropic、Bedrock 等格式。主循环不依赖某家 SDK 类型，而是使用 provider-neutral message 和 tool contract；transport 层负责适配 Responses、Chat Completions、Anthropic message、Bedrock 等。内部格式要支持 role、tool call/result pairing、stream events、usage、artifact refs 和 provider-specific extension。这样换 provider、fallback、replay、eval 都有统一语义，同时高级能力也能通过 extension 暴露。

面试官：模型元数据从哪里来？第二层追问：上下文长度和价格经常变怎么办？

我：模型元数据不能写死，因为价格、窗口和能力经常变；但生产运行也不能每次都依赖联网查询。我会分层：用户配置优先，provider /models 或官方元数据其次，models.dev 或本地缓存再其次，最后才用保守默认。每条 metadata 都带 source、updatedAt、confidence 和 override。trace 记录实际 usage、latency、tool 能力表现，用来校准估算。比如模型窗口标称很大，但实际 max output 或 tool calling 不稳定，路由策略要能从 trace 里发现。

面试官：主模型和辅助模型怎么分？第二层追问：摘要用小模型会不会丢关键事实？

我：我会把主模型和辅助模型分开。主模型负责高风险推理、工具行动和最终决策；辅助模型负责摘要、分类、检索改写、轻量 judge。小模型摘要很省钱，但风险是丢用户约束、丢未完成事项、误写关键错误，所以要有结构化要求、protected facts、source refs 和 verification。比如压缩 coding agent 的上下文时，必须保留“不要改 public API”、当前失败测试和未完成文件。高风险摘要或连续失败时升级到强模型，而不是为了省钱硬用小模型。

面试官：Fallback 怎么设计？第二层追问：模型失败后换模型会不会改变行为？

我：Fallback 不能是 try/catch 里随便换模型。要先分故障类和质量类：429、timeout、5xx 可以同级重试或切 provider；402 余额耗尽走支付或降级策略；schema/tool calling 不兼容不能盲切，要先检查 capability；质量失败才升级强模型。每次 fallback 都要记录 model id、settings、fallback reason、fallback chain 和 quality signal。换模型可能改变工具调用格式、role 语义和输出风格，所以 fallback 是一次可观测的策略决策，不是黑盒补救。

面试官：成本优化先做什么？第二层追问：是不是先换小模型？

我：成本优化我会先减少无效轮次和上下文，再换小模型。顺序大概是：减少工具选错，做 capability discovery，精简工具描述，用 artifact refs 代替大结果，把 5MB 日志留在 artifact，不进 prompt；再做 prompt caching、摘要触发阈值、并行可并行的只读工具，最后才做小模型分层。原因是上下文脏、工具选错、循环无效时，换小模型只会更差，甚至让失败率和人工接管上升，真实成本更高。

面试官：延迟优化怎么做？第二层追问：强模型慢，小模型快，直接路由不就行了吗？

我：延迟不只来自模型，还来自上下文、工具、网络、重试和多轮交互。优化要看端到端：减少轮次，缩短上下文，选择合适 reasoning effort，辅助任务并行，给工具设置 timeout 和 cache，流式输出，必要时用小模型预处理或生成草稿。比如一次代码修复慢，可能是反复读同一日志，不是模型本身慢。高风险最终决策仍可能需要强模型，不能为了 p50 latency 牺牲验证和安全；要同时看 p95/p99 和任务成功率。

面试官：不同模型工具调用能力不同怎么办？第二层追问：不支持 parallel tool calls 呢？

我：Model registry 必须记录能力，不只是价格和上下文窗口。至少要有 toolCalling、parallelToolCalls、structuredOutput、vision、maxOutput、contextWindow 等字段。runtime 根据能力投影不同 tool schema 和 execution plan；不支持并行 tool calls 就串行；不支持 structured output 就加 validation 和 repair；不支持工具就不能路由到行动任务。比如一个模型很便宜但不会稳定产出 tool call，就不能拿去跑需要 shell、edit_file 的 coding agent。

面试官：如何避免 vendor lock-in？第二层追问：统一抽象会不会损失高级能力？

我：避免 vendor lock-in 不是把所有 provider 抹平成最低公分母。核心路径 provider-neutral，provider 特性通过 capability flags 和 extension fields 暴露；主循环不依赖某家 SDK 类型，但具体 transport 可以使用 prompt caching、reasoning、computer use 等高级能力。抽象的目标是让差异显式、可测试、可路由。配合 conformance tests，才能保证 provider 差异不会污染 core。否则统一接口看起来很美，边界行为一变就击穿主循环。

面试官：路由策略怎么评测？第二层追问：怎么证明新策略更好？

我：路由策略要用同一批任务比较 baseline 和新策略，看 success rate、failure taxonomy、cost、p50/p95 latency、tool error、safety regression、user takeover。不能只看平均数，要按任务类型、风险等级分段看；低风险摘要便宜了，但高风险代码修复退化，是不能接受的。路由决策 trace 要记录 candidate models、selected model、selection reason 和 fallback chain。这样才能证明策略更好，而不是只说“成本下降了”。

面试官：多租户企业环境模型路由要注意什么？第二层追问：数据能不能发到任意 provider？

我：多租户企业环境里，路由器不是只看质量和成本，还要看合同和合规边界。data policy 要纳入路由：tenant allowed providers、region、data retention、PII、行业合规、private model priority、local model requirement。比如某个租户规定客户数据只能走企业指定模型或本地模型，那再便宜、再强的外部 provider 也不能选。路由决策要带 tenant policy 和数据分类，这样模型选择才是 runtime policy 的一部分，而不是工程师随手配置。

面试官：一次路由决策要记录哪些字段？第二层追问：线上发现成本突然上涨怎么归因？

我：一次路由决策要能解释和回放。我会记录 task_class、risk_level、candidate_models、selected_model、policy_version、reason、estimated_cost、actual_usage、latency、cache_hit、fallback_chain、provider_error 和 quality_signal。线上成本突然上涨时，就能归因：是任务分布变了、context 变长、cache 失效、fallback 变多、模型价格变化，还是策略阈值让更多任务升级到强模型。没有这些字段，成本问题最后只能靠猜账单。

面试官：Router 用规则还是让 LLM 自己选模型？第二层追问：LLM router 会不会被 prompt injection 影响？

我：第一版我会用可解释规则和 eval 校准阈值。LLM 可以做辅助分类，比如 task classification、risk tagging、routing hint，但最终 provider、预算、合规、数据边界必须由 deterministic policy 控制。LLM router 如果读了不可信内容，也可能被 prompt injection 影响；用户一句“用最便宜模型处理我的敏感客户数据”，不能直接决定 provider。智能路由可以给信号，但 policy engine 必须兜住安全、预算和租户边界。

面试官：Provider conformance tests 具体测什么？第二层追问：只测能返回文本够吗？

我：Provider conformance tests 不能只测能不能返回文本。统一接口最大的风险是看起来统一，边界行为全不一样。我要测 message roundtrip、tool call/result pairing、parallel tool calls、structured output、stream event order、usage stats、finish reason、timeout、rate limit、error normalization、max output、long context、unicode 和 artifact refs。每个 provider 升级 SDK 或模型版本前都跑契约测试。这样才能知道差异被 adapter 吸收了，而不是漏到主循环里。

面试官：Prompt caching 怎么进成本策略？第二层追问：缓存失效会不会导致成本抖动？

我：Prompt caching 适合稳定长前缀，比如 system rules、tool descriptions、project context、long document summaries。路由时要估算 cacheable_tokens、cache_hit_rate、首轮写入成本和后续节省。cache key 要包含 model、provider、prompt version、tool version 和关键 context hash。trace 里记录 cacheable tokens、hit rate、miss reason 和 cost delta。否则缓存一失效，成本突然抖动，你不知道是 prompt 版本变了、工具描述变了，还是上下文 hash 变了。

面试官：遇到 429 和配额不足怎么做？第二层追问：所有请求都 fallback 会不会把成本打爆？

我：限流不是无限 fallback，而是资源调度。要有 rate-limit aware scheduler，按 tenant quota、任务优先级、模型池和 provider 配额做 queue、concurrency limit、backoff、budget guard。低优先级任务可以延迟或降级，高风险交互任务才选择性 fallback。fallback 也要受预算和 capability 约束，不是一路换更贵模型把成本打爆。超过上限要给用户透明反馈，比如“当前模型池拥塞，可等待、降级或暂停”，而不是静默失败。

面试官：长上下文任务怎么路由？第二层追问：直接选最大窗口模型可以吗？

我：最大窗口不是默认答案。长上下文任务先判断是否真的需要全量原文：能用 retrieval、artifact refs、summary、structured index、compact boundary 解决，就不要把所有内容塞进 prompt。只有必须全局推理、跨文档关系强依赖全文时，再选长上下文模型。路由要比较压缩后质量、fact retention、cost、latency 和 window risk。大窗口会让成本和注意力风险都上升，不是万能保险。先治理上下文，再选择模型。

面试官：模型版本漂移怎么处理？第二层追问：provider 悄悄更新模型导致质量变了怎么办？

我：同名模型不等于行为稳定。生产要尽量 pin 具体 model id 或 dated version，metadata 记录 release、deprecation 和能力变化。每次模型版本变更都跑路由 eval 和 canary；线上 trace 要能按 model_version 聚合，看成功率、成本、tool error、安全回归有没有漂移。发现 drift 时可以 rollback、degrade、提高 guardrail 或更新 prompt。不能因为 provider 还叫同一个模型名，就默认工具调用、推理风格和输出格式都没变。

面试官：预算怎么强制执行？第二层追问：Agent 已经做到一半了，预算快没了怎么办？

我：预算要作为 runtime 状态强制执行，分 per-turn、per-run、per-tenant、per-tool。路由前做 preflight estimate，执行后用 actual usage settlement 扣减。接近上限时触发 replan：压缩上下文、停掉低价值辅助任务、切便宜模型、请求用户确认或缩小目标。但高风险任务不能为了省钱跳过验证，比如代码改完不跑测试。超预算要可恢复地暂停，记录当前状态和剩余选项，而不是静默失败或继续烧钱。

面试官：Model routing MVP 怎么做？第二层追问：第一版别做什么？

我：Model routing MVP 先可解释、可测试，再智能化。第一版做 provider transport、model registry、task class、static policy、usage/cost tracing、basic fallback 和 conformance tests。先不做自动学习路由、复杂实时竞价、全 provider marketplace、凭证池高级策略。重点是先让主推理和辅助任务分开，能解释为什么选这个模型，fallback 为什么发生，能在 eval 里比较效果。等 trace 和评测稳定，再让策略逐步自动化。