延迟、成本与服务扩展
Agent 上线后，面试官最常追问的工程问题是：链路为什么慢，Token 花在哪里，用户和请求增长后怎样扩展。模型调用比普通接口慢一到两个数量级、按 Token 计费、提供方有速率限制，所以通用的后端方法仍然适用，但瓶颈的位置不同。本文讲延迟的组成与优化、成本控制、并发限制和降级；通用的限流、超时和熔断见系统设计中的限流与熔断降级。
1. 面试核心
先记住这几条，再读正文- Agent 的端到端延迟 ≈ 各轮模型调用（首 Token 延迟 + 输出 Token 数 × 每 Token 耗时）+ 工具耗时 + 排队等待。轮数和输出长度通常比单次调用速度影响更大。卡 · 延迟的组成
- 降延迟的顺序：先减少串行的模型轮次（固定步骤改工作流、无依赖的工具并行），再缩短输入输出、利用前缀缓存，最后换更快的模型或流式返回改善感知延迟。
- 成本主要来自输入 Token：多轮对话和 Agent 循环每轮都重发历史。控制手段是压缩上下文、前缀缓存、按任务难度路由到不同模型、缓存可复用的结果，以及为单个任务设置预算上限。卡 · 成本控制
- 并发要限制：模型提供方有每分钟请求数和 Token 数的配额，工具下游有容量上限，失控的 Agent 会放大流量。用队列、信号量和按用户、租户的限流控制，超出时排队、降级或拒绝。卡 · 并发、限流与降级
- 定位变慢要靠追踪：记录每一轮模型调用和工具调用的耗时、Token 数和重试次数，比较慢任务与正常任务在哪一段出现差异。卡 · 延迟的组成
2. 延迟的组成
| 环节 | 决定因素 | 优化手段 |
|---|---|---|
| 首 Token 延迟（TTFT） | 输入长度、排队、是否命中前缀缓存 | 缩短上下文；稳定前缀在前；就近部署 |
| 输出耗时 | 输出 Token 数 × 每 Token 耗时 | 限制输出长度；结构化输出代替长文本；用更快的模型 |
| 模型轮数 | Agent 循环的步数 | 固定流程改工作流；一次调用完成多个判断；设置最大步数 |
| 工具耗时 | 下游接口、检索、代码执行 | 并行调用无依赖的工具；缓存工具结果；设置超时 |
| 排队 | 提供方限速、本地并发上限 | 预留配额；优先级队列；削峰 |
推理模型的思考过程也要逐 Token 生成，会显著增加耗时，简单步骤不需要使用。
感知延迟与实际延迟不同：流式返回让用户在首个 Token 到达时就看到进展；长任务改为异步执行，先返回任务 ID，通过 SSE 或轮询推送进度。
3. 成本控制
一次任务的成本 = Σ（每轮输入 Token × 输入单价 + 输出 Token × 输出单价）+ 工具与检索费用。Agent 循环中第 k 轮的输入包含前 k-1 轮的全部历史，所以总输入随轮数接近平方增长。
| 手段 | 做法 | 注意 |
|---|---|---|
| 上下文压缩 | 历史摘要、工具结果只保留结论 | 保留目标和约束，见上下文压缩 |
| 前缀缓存 | 系统提示、工具定义保持稳定且放在前面 | 前缀任何变化都会失效 |
| 模型路由 | 意图识别、抽取、记忆整理、压缩交给小模型；复杂推理用大模型 | 用评测集确认小模型的效果达标 |
| 结果缓存 | 相同问题直接返回；语义相近的问题用向量相似度命中（语义缓存） | 设置阈值和过期时间；带用户数据的结果不能跨用户共享 |
| 按需加载 | 工具和技能先给摘要，需要时再展开，见 Agent Skills | 减少每轮固定开销 |
| 批处理 | 离线任务使用提供方的批量接口 | 时效要求低才适用 |
| 预算上限 | 每个任务、用户、租户设置 Token 和调用次数上限 | 超限时停止并返回已有结果 |
模型选型时，用同一份评测集比较候选模型的成功率、延迟和单次成功任务的成本。只看单价会误导：便宜的模型如果需要更多轮次或重试，总成本可能更高。
模型网关：多模型、多提供方时，在应用和模型之间放一层网关（如 LiteLLM 或自研），统一接口格式、密钥、路由、重试、限流、用量统计和故障切换。
4. 并发、限流与降级
需要限制并发的原因：
- 提供方按每分钟请求数（RPM）和 Token 数（TPM）限速，超出返回 429；本地不控制并发，会产生大量失败和重试。
- 工具调用的下游（数据库、内部接口、浏览器）有容量上限；多 Agent 或批量任务会同时打满。
- 失控的循环会持续消耗配额，影响其他用户。
常用设计：
- 入口限流：按用户、租户、接口维度做令牌桶限流。
- 任务队列：长任务进入队列，由固定数量的 worker 执行；队列长度和等待时间作为扩容和拒绝的依据。
- 调用并发控制：对每个模型、每个工具用信号量限制同时进行的调用数，429 时按退避重试并遵守
Retry-After。 - 降级：主模型不可用或超时时切换备用模型；高峰期关闭非核心步骤（如反思、重排序），或返回只基于检索的简化回答；最终兜底为转人工或稍后重试。
- 隔离：不同业务、不同优先级的请求使用独立的配额和队列，避免互相拖垮。
5 · 面试题卡片
5.1 一个 Agent 推理链路包含 3 个工具，请求频率也高，整体延迟较高，你会怎样优化？
出现公司：阿里淘天、字节跳动
考察重点
- 先测量再优化：把延迟拆到每轮模型调用、每个工具和排队。
- 减少串行轮次、并行工具、缩短上下文、缓存和流式返回的顺序。
参考回答
先用链路追踪把一次请求拆开：几轮模型调用，每轮的首 Token 延迟和输出长度，三个工具各自的耗时，是否有排队和重试。通常最大的开销是串行的模型轮次。
然后按收益从大到小优化。第一，减少轮次：如果三个工具的调用顺序是固定的，改成工作流直接执行，不需要模型每步决策；三个工具之间没有依赖时，让模型一次输出多个调用并行执行。第二，缩短每轮：压缩历史和工具结果，系统提示和工具定义保持稳定以命中前缀缓存，限制输出长度。第三，减少重复：高频请求中相同或相近的问题用结果缓存，工具结果按参数缓存并设置过期时间。第四，换模型：路由和参数抽取这类简单步骤用小模型。最后改善感知延迟：流式返回，长任务异步执行并推送进度。每一步都用评测集确认效果没有下降。
5.2 在 Token 消耗上做过哪些成本控制？模型选型时怎样权衡能力和成本？
出现公司：字节跳动、百度、安软、药明康德、汇川技术、阿里淘天
考察重点
- 成本主要花在哪里：多轮重发的输入。
- 压缩、缓存、路由、预算等手段，以及用评测集比较“单次成功任务成本”。
相关内容：成本控制、Token 与上下文窗口。
参考回答
先统计成本结构：按任务记录每轮输入、输出和缓存命中的 Token。Agent 每轮都重发历史，输入通常是大头，并随轮数快速增长。
对应的手段：压缩历史和工具结果，只保留结论和引用；系统提示、工具定义保持稳定以命中前缀缓存；工具和技能先给摘要，需要时再加载；意图识别、参数抽取、记忆整理和上下文压缩这类任务简单、调用频繁，交给小模型，延迟和单价都更低；相同或相近的请求用结果缓存；离线任务走批量接口；每个任务和租户设置 Token 与调用次数上限，防止循环失控。
选型时用同一份评测集比较候选模型的成功率、延迟和每个成功任务的平均成本，而不是比较单价，因为便宜模型如果需要更多重试，总成本未必更低。只能用一个模型时，靠更好的检索、更精简的上下文、结构化输出和程序校验来弥补准确率。
5.3 为什么要限制 Agent 的并发？LLM 服务并发太高、很多用户同时使用时怎样限流和降级？
出现公司：百度、小红书、快手、字节跳动
考察重点
- 提供方配额、下游容量和失控循环三个限制原因。
- 入口限流、任务队列、调用级并发控制、降级与隔离。
参考回答
限制并发有三个原因：模型提供方按每分钟请求数和 Token 数限速，超出会返回 429，不控制就会出现大量失败和重试风暴；工具调用的下游有容量上限，多 Agent 或批量任务同时调用会打满数据库或内部接口；失控的循环会持续占用配额，影响其他用户。
设计上分几层：入口按用户、租户和接口做令牌桶限流；长任务进入队列，由固定数量的 worker 消费，用队列长度和等待时间判断扩容或拒绝；对每个模型和工具用信号量限制同时进行的调用数，例如一批 100 个任务最多 3 个并发，429 时指数退避并遵守 Retry-After。高峰或故障时降级：切换备用模型，关闭反思、重排序等非核心步骤，或者只返回检索结果；最后转人工或提示稍后重试。不同业务和优先级使用独立的配额与队列，避免互相影响。
5.4 一个长任务平时 5 分钟结束，这次运行了 15—20 分钟，你会怎样分析原因？
出现公司：字节跳动
考察重点
- 与正常任务对比，把差异拆到轮数、单轮耗时、工具和排队。
- 区分“做了更多步”和“每一步更慢”两类原因。
参考回答
先拿这次任务和一次正常任务的追踪记录对比，先回答一个问题：是步数变多了，还是每一步变慢了。
如果步数变多，看轨迹：模型是否在重复调用同一个工具、反复重试失败的操作、计划被多次推翻，或者因为输入数据量变大而需要处理更多条目。原因可能是工具返回了错误或空结果、上下文被压缩后丢失了进度、提示词或模型版本有变化。如果每一步变慢，再细分：首 Token 延迟变长说明上下文变长或排队，可以检查输入 Token 和前缀缓存命中率；输出变长说明模型生成了更多内容；某个工具耗时变长说明下游变慢或超时重试；大量 429 和退避说明配额不足。
确认原因后，修复并加防护：设置最大步数和总时长预算，同一工具连续失败时提前终止，关键指标（步数、Token、工具耗时）超过基线时告警，把这个任务加入回归集。