智能体面试准备（二十六）：Agent 成本工程------模型路由、缓存、预算控制与大小模型分工
上一篇《多模态 Agent》让 Agent 看得懂图、听得见话，但随之而来一个很现实的问题：每张图几百 token、每段视频上万 token、每轮对话都调一次大模型，账单会爆炸。这是 B 系列第二十六篇，也是本系列收官前的最后一块拼图。成本工程（Cost Engineering）是 2025 年之后 Agent 落地最被甲方在意的主题------模型能力再强，跑一个月烧掉一家公司也白搭。它和 B20 可观测性（成本归因）、A25 推理服务化（单位 token 成本）、B13 记忆（避免重复计算）都强相关。本文按"成本从哪来 → 模型路由 → 大小模型分工 → 缓存策略 → 提示与上下文压缩 → 预算控制与降级 → 成本可观测 → 评测与权衡"展开，结尾给面试速答和高频追问清单。
一、Agent 的成本从哪来
1.1 成本构成
一个 Agent 任务的账单 = Σ (各次模型调用的 token 数 × 单价)
主要花钱点：
1. 输入 token：system prompt + 历史对话 + 检索上下文 + 多模态媒体
2. 输出 token：模型生成的思考/回答/工具参数
3. 调用次数：每轮 ReAct 循环一次 = 一次大模型前向
4. 多模态溢价：图像/视频 token 单价常高于纯文本
5. 长上下文溢价：超长上下文窗口的模型单价更高1.2 成本 vs 质量的典型曲线
| 做法 | 成本 | 质量 | 适用 |
|---|---|---|---|
| 全程旗舰大模型 | 高 | 高 | 高价值、低频次任务 |
| 全程小模型 | 低 | 中低 | 简单、高频、容错任务 |
| 大小模型混合路由 | 中 | 接近旗舰 | 大多数生产场景（目标形态） |
| 无缓存重复调用 | 高 | 同左 | 应避免的反模式 |
核心思想：不是所有 token 都值得用旗舰模型处理。把贵模型用在"难且关键"的地方，把便宜模型用在"简单或已成定局"的地方。
二、大小模型分工：把"判断"和"执行"拆开
2.1 为什么要分工
旗舰模型(如 70B/闭源顶级)：推理强、贵、慢
小模型(如 7B/云端小模型)：快、便宜、能力有限
一个典型的 Agent 循环里：
规划/复杂决策 -> 需要旗舰
简单分类/格式化/抽取 -> 小模型足够
最终综合回答 -> 旗舰（保证质量）
中间步骤校验 -> 小模型（省钱）2.2 分工的两种组织方式
| 方式 | 说明 | 例子 |
|---|---|---|
| 串行：小模型预处理，旗舰终审 | 小模型做粗筛/草稿，旗舰精修 | 小模型先抽实体，旗舰判断是否够 |
| 并行：路由到不同模型 | 路由器按难度分发 | 简单问句走小模型，复杂推理走旗舰 |
三、模型路由：用一个小模型决定"该叫谁"
3.1 路由器的设计
路由器 (Router) 的输入：用户 query + (可选) 元数据
路由器的输出：选择哪个模型/哪条处理链路
路由依据：
- 难度预估：query 长度、是否含代码/数学/多步推理
- 任务类型：闲聊/抽取/生成/推理
- 历史表现：该类 query 在小模型上的失败率
- 用户/场景等级：VIP 直接走旗舰3.2 路由代码示意
python
# 概念示意：基于难度分类的模型路由
def route(query, meta):
# 用一个小而快的分类器/规则判断难度
signals = {
"len": len(query),
"has_code": "```" in query or "代码" in query,
"has_math": any(c in query for c in "+-*/=√∫"),
"multi_step": "步骤" in query or "为什么" in query,
"vip": meta.get("user_tier") == "vip",
}
if signals["vip"] or (signals["has_code"] and signals["has_math"]):
return "flagship" # 难且关键 -> 旗舰
if signals["len"] < 40 and not signals["multi_step"]:
return "small" # 简单短问 -> 小模型
return "small_then_flagship" # 先小模型粗处理，旗舰终审
MODEL = {"small": "MiniLM-route", "flagship": "top-model"}3.3 路由的风险
错路由 (misroute)：简单任务误送旗舰 -> 浪费钱；难任务误送小模型 -> 质量塌方
缓解：设"回退"(fallback)------小模型低置信时自动升级到旗舰；监控各路由的质量。四、缓存：最便宜的 token 是不发的 token
4.1 缓存的几种形态
| 缓存类型 | 存什么 | 命中条件 | 节省 |
|---|---|---|---|
| 精确结果缓存 | (query, answer) 对 | query 完全相同 | 100% 省一次调用 |
| 语义缓存 | query 的 embedding | 语义相近即命中 | 省调用，但需相似度阈值 |
| 前缀缓存 (prefix cache) | system prompt / 公共上下文 的 KV | 前缀相同（见 A25） | 省 Prefill 算力 |
| 检索结果缓存 | 同一 query 的检索结果 | query 相同或相似 | 省检索+重算 |
4.2 语义缓存示意
python
# 概念示意：语义缓存------相似问题直接复用答案，不调大模型
import numpy as np
class SemanticCache:
def __init__(self, sim_threshold=0.92):
self.items = [] # (embedding, answer)
self.thr = sim_threshold
def get(self, q_emb):
for emb, ans in self.items:
if np.dot(q_emb, emb) / (np.linalg.norm(q_emb)*np.linalg.norm(emb)) > self.thr:
return ans # 命中：直接返回，零模型调用
return None
def put(self, q_emb, answer):
self.items.append((q_emb, answer))注意：语义缓存对"事实会随时间变"的问题有踩雷风险（如股价、天气），需带 TTL 或对时效性 query 禁用。
五、提示与上下文压缩：少发 token 也是省钱
5.1 压缩手段
1. system prompt 精简：去掉冗余说明，能省几百 token/次
2. 历史裁剪：只保留最近 N 轮 + 关键摘要（B13 记忆压缩）
3. 检索上下文裁剪：RAG 只取 top-k 相关片段，而非整库
4. 多模态降级：图先缩分辨率/OCR 出文字再送，而非原图直送
5. 结构化输出约束：要求模型少啰嗦，减少输出 token5.2 与多模态成本的关系
一张高清图 -> 几千视觉 token；先 OCR/降分辨率 -> 可能省 70% token
视频先抽关键帧再细看 -> 避免把整段视频都编码
这是 B25 多模态 Agent 必然要配套的成本手段。六、预算控制与降级：兜住最坏情况
6.1 预算维度
| 维度 | 控制方式 |
|---|---|
| 单次任务 token 上限 | 超阈值强制截断/转人工 |
| 单用户日调用上限 | 配额(quota)，防滥用 |
| 单轮工具调用次数 | 防止 Agent 陷入死循环空转烧钱 |
| 模型等级上限 | 按用户等级限制可用最贵模型 |
6.2 降级链路
成本/延迟超阈值时的降级顺序（常见）：
旗舰模型 -> 小模型 -> 缓存/模板 -> 转人工
例：连续 3 次调用超预算 -> 后续步骤强制小模型；
单任务总 token 超 50k -> 中断并提示用户确认是否继续。6.3 预算控制代码示意
python
# 概念示意：带预算守卫的 Agent 循环
class BudgetGuard:
def __init__(self, max_tokens=50000, max_steps=20):
self.used, self.max_tokens = 0, max_tokens
self.steps, self.max_steps = 0, max_steps
def charge(self, in_tok, out_tok):
self.used += in_tok + out_tok
self.steps += 1
if self.used > self.max_tokens:
raise BudgetExceeded("token 预算超限")
if self.steps > self.max_steps:
raise BudgetExceeded("步骤预算超限")
def model_for(self, difficulty):
# 预算吃紧时自动降档
if self.used > 0.8 * self.max_tokens:
return "small"
return "flagship" if difficulty == "hard" else "small"七、成本可观测：先看见，再优化
7.1 与 B20 可观测性的结合
成本可观测要能回答：
- 哪个 Agent/哪个工具/哪个用户最烧钱？ (成本归因)
- 单次任务平均花多少 token？P50/P99？
- 路由分布是否合理（多少走了旗舰）？
- 缓存命中率多少？（命中率每升 10%，成本降一大截）
没有这些指标，成本优化就是盲调。7.2 一个成本看板的最小字段
| 字段 | 用途 |
|---|---|
| trace_id | 串联一次任务的所有调用 |
| model | 用了哪个模型（用于算单价） |
| in_tokens / out_tokens | 计费基数 |
| cache_hit | 是否命中缓存 |
| route_decision | 路由到了哪（诊断错路由） |
| cost_usd | 本次调用成本 |
| step_index | 在 Agent 循环第几步（找空转） |
八、评测与权衡：成本优化的边界
8.1 优化顺序建议
1. 先上缓存（ROI 最高、风险最低） -> 常省 30%~60%
2. 再上路由/大小模型分工（中等 ROI） -> 再省 30%~50%
3. 后做上下文压缩（要小心质量损失） -> 边际收益
4. 最后才上降级（影响体验，兜底用）8.2 权衡陷阱
- 过度路由：为省 1 分钱把难任务误送小模型，导致返工 3 次，反而更贵
- 缓存污染：语义缓存阈值过低，把"相似但答案不同"的问题也命中 -> 质量事故
- 压缩过度：system prompt 砍太狠，模型行为漂移
原则：成本优化必须在"质量不显著下降"的约束下做，用 A/B 评测守住底线。这里的"质量不显著下降"需要有可操作的定义，否则就会变成各说各话。比较稳妥的做法是借用 B23 灰度发布里讲过的非劣性检验思路：事先约定一个可接受的质量损失边界，例如任务成功率下降不超过一个百分点，然后在灰度流量上采集足够样本做统计检验，只有在统计意义上能证明"新方案没有比旧方案差超过这个边界"时才允许全量。这样既避免了因为随机波动误判成本优化有害，也避免了拿"看起来差不多"这种主观判断去掩盖真实的质量退化。成本优化天然带有把质量往下压的动机，正因如此，它比其他类型的变更更需要一套外部的、量化的、不受优化者本人影响的质量门禁。
九、单位经济模型：把成本算到每一次任务上
"降本"如果没有一个可计算的模型，就只能靠感觉。面试里能把这笔账列出来，说服力完全不同。
9.1 单任务成本公式
单任务成本 C = Σ_over_steps ( in_tok_i × p_in(m_i) + out_tok_i × p_out(m_i) )
+ 工具调用费
+ 检索/向量库摊销
+ 人工兜底成本 × 兜底率
其中 m_i 是第 i 步用的模型，p_in / p_out 是该模型的输入/输出单价。
注意两点：
1. 输出 token 通常比输入贵 3~5 倍，所以"控制输出长度"往往比"压缩输入"更划算
2. Agent 是多步的，成本随步数线性增长，控制步数 = 控制成本9.2 拿一个客服 Agent 实际算
假设一个 ReAct 式客服 Agent，平均 4 步完成一个会话，全部用旗舰模型：
基线（全旗舰，假设 p_in=15元/百万tok, p_out=60元/百万tok）：
步骤 输入tok 输出tok 说明
1 意图理解 3500 120 system+工具定义+历史
2 检索后作答 6000 350 带 5 条检索片段
3 工具调用 6500 100 再拼一轮观察结果
4 终答合成 7000 450 全上下文
合计输入 23000 tok -> 23000/1e6 × 15 = 0.345 元
合计输出 1020 tok -> 1020/1e6 × 60 = 0.061 元
单会话成本 ≈ 0.41 元
日均 10 万会话 -> 4.1 万元/天 -> 约 1230 万元/年一年一千多万，这个量级足以让成本工程成为一个独立岗位。现在看优化空间：
优化1 前缀缓存（system+工具定义 3000 tok 常驻，命中率 85%）
输入侧省 ≈ 3000×4步×0.85 = 10200 tok -> 省 0.153 元 (37%)
优化2 路由（60% 简单会话走小模型，单价约为 1/10）
这部分成本降至 1/10 -> 整体再省 ≈ 0.6×0.9 = 54% 的剩余
优化3 历史裁剪（第 3、4 步不重复携带全部历史，省约 25% 输入）
叠加后单会话 ≈ 0.41 × 0.63 × 0.46 × 0.85 ≈ 0.10 元
降幅约 75%，年成本从 1230 万降到约 300 万这套算法在面试里非常好用：先给基线、再逐项列优化、最后给叠加后的数字，比空谈"我们做了缓存和路由"有力得多。
9.3 注意"省的是哪一部分"
| 手段 | 省输入 | 省输出 | 省调用次数 | 备注 |
|---|---|---|---|---|
| 前缀缓存 | 是 | 否 | 否 | 只对重复前缀有效 |
| 语义缓存 | 是 | 是 | 是 | 命中即整次调用归零，收益最大 |
| 模型路由 | 降单价 | 降单价 | 否 | 不减 token，减单价 |
| 历史裁剪 | 是 | 否 | 否 | 注意别裁掉关键上下文 |
| 输出长度约束 | 否 | 是 | 否 | 输出单价高，收益被低估 |
| 减少 Agent 步数 | 是 | 是 | 是 | 从架构上省，最根本 |
最后一行值得强调：减少步数是最根本的降本手段。一个能用 2 步完成的任务被设计成 6 步，后面做再多缓存和路由也只是在给糟糕的架构打补丁。
十、批处理与异步化：用延迟换成本
不是所有请求都需要秒级响应。把"可以慢"的部分挪走，是一笔几乎免费的收益。
10.1 三种时效等级
实时 (< 2s) 用户正在等 -> 必须在线，用最贵的配置保 SLA
准实时 (< 1min) 用户提交后去干别的 -> 可排队合批
离线 (小时级) 报表、批量清洗、知识库预处理 -> 走 Batch API
多数厂商的 Batch API 价格约为实时的 50%，
且不占用在线配额，对大规模离线任务是直接对半砍。10.2 合批的工程要点
python
# 概念示意：把准实时请求攒批，摊薄固定开销
import asyncio, time
class MicroBatcher:
def __init__(self, max_size=16, max_wait=0.2):
self.max_size, self.max_wait = max_size, max_wait
self.queue = []
async def submit(self, item):
fut = asyncio.get_event_loop().create_future()
self.queue.append((item, fut))
# 攒够一批 或 等待超时 就触发
if len(self.queue) >= self.max_size:
await self._flush()
else:
asyncio.get_event_loop().call_later(
self.max_wait, lambda: asyncio.ensure_future(self._flush()))
return await fut
async def _flush(self):
if not self.queue:
return
batch, self.queue = self.queue, []
items = [b[0] for b in batch]
# 关键：一次调用处理多条，system prompt 只发一遍，摊薄到每条
results = await call_model_batch(items)
for (_, fut), r in zip(batch, results):
if not fut.done():
fut.set_result(r)合批省钱的本质是摊薄固定开销：system prompt、工具定义这些每条请求都要带的内容，合批后只发一次。对于 system prompt 占比高的短请求场景（如批量分类、批量打标），收益可以到 50% 以上。
10.3 什么不能合批
- 有严格顺序依赖的多轮对话；
- 不同租户的请求（隔离要求，见 B21）；
- 单条就很长的请求（合批后可能超上下文窗口，反而失败）。
十一、缓存命中率工程：从 20% 提到 60%
缓存是性价比最高的手段，但很多团队上线后命中率只有百分之十几，原因几乎都是工程细节没做对。
11.1 命中率上不去的常见原因与对策
| 问题 | 现象 | 对策 |
|---|---|---|
| 前缀不稳定 | prompt 开头带当前时间戳/随机 id | 把易变内容全部挪到 prompt 末尾 |
| 键设计太严 | 多一个空格就 miss | 归一化：去空白、统一大小写、抽取关键实体 |
| 未做语义归并 | "怎么退货" 与 "如何退货" 各存一份 | 上语义缓存，embedding 相似度匹配 |
| TTL 一刀切 | 时效性内容与静态知识同一个 TTL | 分类设 TTL：政策类 7 天，价格类 5 分钟，实时类不缓存 |
| 未预热 | 冷启动阶段全 miss | 用历史高频问题离线预热缓存 |
11.2 语义缓存的阈值该怎么定
这是最容易出事故的参数，定低了会把"相似但答案不同"的问题错误命中：
典型反例（阈值设 0.85 时的事故）：
"北京到上海的高铁多少钱" vs "北京到上海的飞机多少钱"
embedding 相似度可能高达 0.90 -> 错误命中 -> 给出错误答案
正确做法：
1. 阈值宁高勿低，建议 0.95 起步，再根据 badcase 微调
2. 加"关键实体一致性"二次校验：
抽取查询中的实体(地名/产品名/数字)，实体不一致则强制 miss
3. 分领域设阈值：闲聊类可松，事务类必须严
4. 缓存命中的回答也要抽样质检，不能命中即免检11.3 要上报的缓存指标
cache_hit_rate 总命中率，看趋势
cache_hit_rate_by_type 分精确/语义/前缀，定位哪层在起作用
cache_false_hit_rate 错误命中率 <-- 最重要，靠抽检得到
cache_saved_cost 累计省下的钱，用来向上汇报
cache_staleness_complaint 因缓存过期导致的用户投诉数其中 cache_false_hit_rate 是很多人漏掉的：只报命中率不报错误命中率，等于只报收益不报风险。面试里主动提到这一点，会显得你真的在生产里踩过坑。
11.4 一次真实感的降本复盘
设想这样一个场景：某企业知识问答 Agent 上线三个月后，月度账单从预算的十万涨到了四十万，团队被要求在不影响体验的前提下把成本压回去。这个题目在面试里出现频率很高，因为它同时考察诊断能力和取舍判断。
正确的第一步不是立刻上缓存或换模型，而是先做成本归因。没有归因就优化，等于闭着眼睛砍成本。接入 B20 讲的可观测体系后，通常会发现成本分布极度不均衡：少数几类请求贡献了大部分开销。常见的诊断结论有三种。一是长尾会话吃掉了大头，比如百分之五的会话轮次超过二十轮，每轮都携带完整历史，token 呈平方级增长，这类会话可能只占请求量的百分之五却贡献了百分之四十的成本。二是检索片段给得过多，为了追求召回率把 top-k 设到二十，每次都往上下文里塞一万多 token，但实际有效的往往只有前三条。三是重试与失败调用被完全忽略，工具调用失败后 Agent 自动重试，失败链路的 token 消耗从来没有被统计进成本看板。
针对这三类问题，对应的处理方式完全不同。长尾会话要做历史摘要与滚动窗口 ，超过一定轮次后把早期对话压缩成摘要，只保留最近几轮原文，同时给单会话设置硬性的 token 上限，超限则提示用户开启新会话。检索过量要做重排后截断 ，用一个轻量重排模型把二十条压到三条，重排模型的成本远低于多出来的十七条片段送进大模型的成本，这笔账几乎总是划算的。失败重试要做熔断与预算守卫，同一工具连续失败两次就停止重试并转人工，避免无意义的循环烧钱。
这三项做完，通常能把成本降到原来的四成左右，而且质量指标基本不动------因为砍掉的都是冗余而非有效信息。此时如果还需要进一步压缩，才轮到模型路由和语义缓存这类会引入质量风险的手段。这个顺序很重要：先砍浪费，再砍质量。浪费是纯收益，砍质量是有代价的交易，两者不应该混为一谈。面试时如果能把这个优先级讲清楚，比罗列一堆技术名词有说服力得多。
最后还有一个容易被忽略的维度：成本优化本身也有成本 。搭一套语义缓存需要向量库和运维投入，训一个路由器需要标注数据和持续迭代，这些工程投入如果超过了它们节省的金额，就是负收益。判断标准很简单------先估算优化能省下的年化金额，再对比投入的人力月数，如果一个优化只能省几万而需要两个人做一个季度，那它不该排在优先级前面。能主动提到这一层的候选人，通常已经具备了从工程师视角向技术负责人视角切换的能力。
十二、上线前自检清单与不同阶段的优先级
讲了这么多手段，面试里真正能拉开差距的，是把它们组织成一套可落地的优先级清单，而不是零散地罗列名词。很多候选人能背出缓存、路由、量化，却说不清先做哪个、为什么，这正是面试官区分"用过"和"理解"的关键。下面这版自检清单，是我建议所有 Agent 项目在上线前都过一遍的，顺序本身就代表了性价比高低。
第一步，先确认成本究竟有没有被"看见"。如果连单任务成本、缓存命中率、平均 Agent 步数这些基础指标都还没有，那么任何优化都是盲目的。这一条不通过，后面都不用谈。第二步，砍掉肉眼可见的浪费：检索片段是否过量、历史是否无限累积、失败重试是否无上限、输出是否被无关解释撑长。这些属于纯收益，不影响质量，应当最先做。第三步，再上缓存与路由这类会引入质量波动的手段，并且每一步都配 A/B 评测守住底线。第四步，才是架构层面的重构，比如把原本六步的链路压到两步、把能离线的部分彻底异步化。
不同阶段的团队，优先级也完全不同，这一点在面试里讲出来会显得很 mature。早期原型阶段，成本根本不是问题，真正的约束是"能不能跑通"，这时候为了成本去上向量库做语义缓存是过度工程，反而拖慢验证速度。快速增长阶段，账单开始失控，最该做的是介入可观测和归因，找到那百分之五吃掉了百分之四十成本的长尾请求，针对性治理。规模稳定阶段，才值得为路由器和语义缓存投入专门的工程人力，因为摊薄到海量请求上，单点优化的年化收益才足够覆盖投入。很多候选人一上来就说"我要做模型路由"，却说不清自己处在哪个阶段，这恰恰暴露了经验的缺失。一个实用的判断法是看"成本占营收或人力成本的比例"：比例低于某个阈值时，优先功能迭代；超过阈值时，成本工程才进入核心优先级。
还有一项容易被当成"锦上添花"却极其关键的工作：把成本写进需求评审。当一个新的 Agent 能力被提出时，应当同步评估它的单位经济模型------每次调用额外多少 token、是否增加步数、是否引入昂贵工具。如果一项功能会让单任务成本翻三倍而收益只是体验上的微小提升，那么它在评审阶段就该被质疑。成本工程做得好的团队，不是上线后拼命优化，而是在设计阶段就把浪费挡在了门外。这个观念，比任何具体的缓存技巧都更接近"成本工程"这四个字的本质。
最后提一个反直觉的点：有时候不优化反而是正确决策。当你的月度账单只有几百块、或者成本在整体业务里占比极低时，花两周搭一套成本治理平台，投入产出比是负数。判断标准永远是那句话------先估算能省下的年化金额，再对比投入。成本工程是为了让业务更可持续，而不是为了展示技术复杂度。能守住这条朴素的底线，才是真正理解了这个主题的人。
举个具体的例子帮助理解这个权衡。假设一个内部使用的文档摘要 Agent，每天只有二十次调用，单次成本两毛，月度账单一百二十块。如果有人提议"我们给它上语义缓存加模型路由，预计能省一半"，那么省下来的是每月六十块，而搭这套系统的成本至少是一个人月，按人力成本算就是两三万。这显然是亏的，正确做法是保持简单，等到调用量涨到每天上千次时再做也不迟。反过来，如果是一个面向千万用户的客服 Agent，单次省一厘钱乘以海量请求就是每月几十万的差距，那么任何能降单价的优化都值得投入专人。成本工程的成熟，本质上就是能在一秒钟内完成这种量级的判断，而不是机械地套用每一招。
十三、面试速答 + 高频追问清单
面试速答（60 秒版）
Agent 成本 = 各次模型调用 token 数 × 单价，主要花在输入上下文、输出生成、调用次数和多模态溢价上。成本工程的核心原则是"不是所有 token 都值得用旗舰模型"。手段有四层：第一，大小模型分工，把规划/终审留给旗舰，把抽取/校验交给小模型；第二，模型路由，用一个小而快的路由器按难度/任务类型/用户等级把请求分发到合适模型，并设低置信自动升级的回退；第三，缓存，最便宜的 token 是不发的 token，包括精确结果缓存、语义缓存、前缀 KV 缓存和检索结果缓存；第四，上下文压缩（精简 prompt、历史裁剪、检索 top-k、多模态降级）和预算控制（token/步骤/用户配额上限 + 降级链路）。所有优化必须建立在成本可观测（B20 的归因、缓存命中率、路由分布）之上，并在 A/B 评测守住质量底线。优化顺序建议先缓存、再路由、后压缩、最后降级。
高频追问清单
- 模型路由的"难度预估"用什么信号？误路由的代价是什么，怎么兜底？
- 语义缓存和精确缓存的取舍？语义缓存的相似度阈值设太低会有什么事故？
- 前缀缓存（prefix cache）和语义缓存是同一回事吗？它们在 A25 里分别怎么起作用？
- 大小模型分工里，哪些步骤适合小模型、哪些必须旗舰？给出一个完整 Agent 循环的分工示例。
- 多模态 Agent 的成本怎么压？为什么说"先 OCR/降分辨率再送"能省大量 token？
- 预算控制有哪些维度？降级链路一般怎么排？
- 成本可观测要采集哪些字段才能做归因？没有它会怎样？
- 缓存对时效性问题的风险（股价/天气）怎么处理？TTL 和禁用策略怎么选？
- 如果优化后成本降了 40% 但任务成功率掉了 5%，你怎么判断是否"值得"？
- 把 A25（推理服务化）、B20（可观测性）、B13（记忆）和本篇串起来，说一套完整的"低成本高可用 Agent"架构。
系列结语：到这一篇，A 系列从 RAG、长上下文、VLM、高效推理、后训练、分布式训练、LoRA、量化、评测、MoE、推理时扩展、数据工程、位置编码、推理服务化、幻觉缓解讲了一圈；B 系列从评估、ReAct、记忆、MCP、多智能体、安全、HTN、Function Calling、RAG 评估、可观测性、多租户、长时任务、灰度发布、GUI、多模态到成本工程也铺满了。两条线合起来，基本覆盖了 27 届大模型与智能体面试的高频骨架。