一、Agent 很慢，是不是换个更快的模型就行？

面试官问：

你的 Agent 完成一次任务要 30 秒，怎么优化到用户可以接受的程度？

如果第一反应是“换一个更快的模型”，可能还没找对问题。

想象一家餐厅出餐慢。原因可能是厨师炒菜慢，也可能是服务员迟迟没下单、食材还没送到，或者本来可以同时做的三道菜，硬是排成了先后顺序。

换个炒菜更快的厨师，并不能解决所有问题。

Agent 也一样。一次任务往往包括接收请求、准备上下文、模型决策、调用工具、读取结果和生成回答。

它的速度取决于整条执行过程。

先找时间花在哪里，再决定改模型、改工具，还是改编排。

二、先说清楚：你想让哪一种“等待”变短？

“响应很快”可能指不同的事情。

指标	含义	用户感受到什么？
首个可见反馈时间	从提交任务到页面出现有效反馈	系统有没有接到任务
模型首 Token 延迟	从模型请求发出到收到首个输出 Token	模型何时开始返回内容
首个有用结果时间	用户何时看到可用信息	什么时候能开始判断或行动
端到端完成时间	从提交任务到完整结果可用	这件事到底多久做完

模型很快返回一个工具调用，不代表用户已经看到答案。页面立刻显示“正在处理”，也不代表任务实际提速了。

以排障为例：

• 0.5 秒显示“已收到请求”，属于反馈。

• 5 秒显示“错误率从 14:03 开始上升”，可能是有用的阶段性结果。

• 20 秒形成完整分析，才是任务完成。

因此，做性能优化时，应该明确目标：减少总耗时、提前交付有用信息，还是改善等待期间的体验。

三、把一次 30 秒的任务拆开看看

用户要求：

分析 payment-api 在指定时间段的超时问题，结合日志、监控和发布记录给出结论。

假设服务标识和时间范围已明确，测得下面这组教学数据：

阶段	耗时
请求接入与上下文准备	1 秒
模型选择查询动作	3 秒
查询日志	8 秒
查询监控指标	6 秒
查询发布记录	4 秒
模型整合并生成回答	7 秒
结果传输与页面处理	1 秒

如果全部串行执行，总耗时为：

1 + 3 + 8 + 6 + 4 + 7 + 1 = 30 秒。

模型调用加起来用了 10 秒，三个工具用了 18 秒。

即使把模型部分整体减半，任务仍然需要约 25 秒。瓶颈并不会因为“模型更快了”就自动消失。

实际排查时，可以给每个阶段记录开始、结束、排队等待和执行状态，用同一任务标识关联起来。

关键是区分墙上时钟经过的时间与各组件累计耗时：并行阶段的耗时不能简单相加。

四、第一种优化：能同时做的，别排队做

在这个案例里，日志、监控和发布记录都已经有了查询所需的服务与时间参数，彼此不依赖查询结果。

因此，可以同时发起三个查询。

忽略额外调度开销时，工具阶段就从：

8 + 6 + 4 = 18 秒

变成：

max(8, 6, 4) = 8 秒。

总耗时则约为：

1 + 3 + 8 + 7 + 1 = 20 秒。

这里没有更换模型，只改变了独立操作的执行方式。

Claude 的官方文档也介绍了并行工具调用：模型可以提出多个独立调用，由应用侧执行并返回结果。具体是否真正并行，仍取决于执行器，而不只是模型一次输出了几个工具请求。

什么时候不能并行？

操作关系	能否直接并行？	原因
查日志、查监控，参数都已知	通常可以	输入彼此独立
先查订单 ID，再根据 ID 查物流	不可以	第二步依赖第一步输出
先确认退款资格，再执行退款	不可以直接并行	存在业务前置条件
两个操作修改同一份配置	需要协调	可能产生冲突或覆盖

判断并行性，不只是看有没有数据依赖，还要看业务顺序、共享资源和操作副作用。

为什么不是并发越大越好？

厨房只有四个灶台，你同时下发一百道菜，并不会让一百道菜同时出锅。

工具服务也有并发与限流约束。并发过高可能增加排队、超时和重试，使尾部延迟更差。

所以需要设置合理的并发上限，并观察目标负载下的表现。

五、第二种优化：优先缩短关键路径

关键路径，可以理解成决定整个任务最早何时完成的那条依赖链。

在三个查询并行、必须等待全部结果的情况下，8 秒的日志查询决定了这轮查询何时结束。

如果把 4 秒的发布查询优化到 1 秒，整轮仍然要等日志查询到第 8 秒。

如果把日志查询从 8 秒优化到 5 秒，整轮才可能缩短到 6 秒，因为这时监控查询成为最慢的一项。

改动	并行查询阶段耗时
原始：日志 8 秒、监控 6 秒、发布 4 秒	8 秒
仅把发布查询降到 1 秒	8 秒
仅把日志查询降到 5 秒	6 秒

这解释了一个常见现象：某个接口明明快了一大截，用户却几乎感觉不到变化。

组件提速多少，与端到端提速多少，不是同一个数字。

如果某项结果并非完成任务的必要条件，还可以按明确的业务策略先返回已确认的部分，标明缺失证据。

不能为了快，就把缺少关键证据的猜测包装成完整结论。

六、第三种优化：减少没有必要的模型往返

有些 Agent 的时间消耗在反复“请示”模型上：

查询日志完成了，下一步怎么办？

查询监控完成了，下一步怎么办？

查询发布记录完成了，下一步怎么办？

如果这些查询本来就是业务要求的固定步骤，而且彼此独立，可以在一次决策后由程序组织执行，再让模型统一分析。

工作	可以考虑的处理方式
已知字段映射、时间格式转换	程序处理
按固定规则过滤和聚合数据	程序处理
根据证据判断异常原因	模型或领域逻辑
面对未知情况选择下一步	保留模型决策

这里优化的是分工。确定性的工作交给程序，真正需要理解和判断的环节再使用模型。

同样，中间结果也不必每次都生成一篇长报告。可以保留必要事实、引用和状态，在最后统一组织面向用户的回答。

但减少输出应以保留关键信息为前提。输出上限设得过低导致结果截断，反而可能触发额外调用。

七、第四种优化：缓存，但先分清缓存了什么

“加缓存”是面试里容易说、也容易说空的一句话。

缓存类型	复用什么？	典型场景
提示词前缀缓存	重复输入前缀的相关计算	稳定的长指令或背景材料
工具结果缓存	相同条件下的查询结果	更新较慢的配置、产品信息
最终答案缓存	已经生成好的回答	条件、权限与时效均匹配的问题

提示词缓存不是把上一条答案拿来重复播放。Claude 官方文档将它描述为对可复用提示词前缀的缓存，以减少重复处理的时间和成本。

工具结果缓存则要回答另一组问题：

• 结果多久会变？

• 缓存键包含哪些条件？

• 当前用户有没有权限读取？

例如，日志查询的缓存键只写“payment-api”，就会混淆不同环境、时间窗口甚至租户。

在排障任务中，实时指标和当前故障数据对时效敏感，不宜为了命中率直接复用过时结果。

缓存命中率、有效期和冷启动表现，也应该一起测量。

八、流式输出，是提速还是“看起来更快”？

流式输出让应用在完整响应结束前逐步接收输出，Claude 官方 API 就提供了对应事件流机制。

它通常有助于提前展示内容，但不会自动缩短前面那次慢数据库查询。

可以分成三种体验：

展示方式	用户得到什么？
只有转圈	知道系统未结束，但不知道进展
真实进度信息	知道哪些步骤已经完成
有依据的阶段性结果	可以提前开始理解问题

例如：

“监控查询已完成，日志仍在查询”是进度。

“错误率从 14:03 上升，原因仍待日志确认”是带边界的阶段性结果。

它们都比长时间没有反馈更有帮助，但需要与最终完成时间分别统计。

对于还没校验完成的结构化数据或关键结论，也不能因为已经流式显示，就提前交给下游执行。

九、最后再决定：是否换模型、做降级？

如果测量表明模型决策或生成确实占主要时间，可以比较不同模型、输出长度和适用的推理配置。

简单字段提取可能适合较轻量的模型，复杂证据分析可能更依赖能力强的模型。具体分工需要用任务测试验证。

还可以给任务设置总时间预算：必要结果优先，可选补充按剩余时间决定。

超过预算时，返回已经确认的内容和未完成部分，而不是无限等待。

但降级结果需要单独统计质量和完整性。

提前返回一个不完整答案，不能被当作“同等质量下提速”。

十、怎么证明优化有效？

使用同一批任务，在相近环境和负载下比较：

• 端到端 P50 与 P95 延迟。

• 首个有用结果出现的时间。

• 任务成功率与回答完整性。

• 每次任务的模型调用次数和费用。

• 超时率、限流情况与缓存命中情况。

P95 可以理解为：按耗时排序，大约 95% 的请求在这个时间内完成。

它能帮助发现“多数时候还行，偶尔特别慢”的问题。

各阶段的 P95 不能直接相加来代替整体 P95，因为它们不一定发生在同一次请求中。应从每个任务的端到端记录计算。

十一、面试精简总结

我会先明确优化的是首个反馈、首个有用结果还是端到端完成时间，再把任务拆成接入排队、模型调用、工具执行和结果处理等阶段，找到关键路径。

优先并行执行输入独立且没有业务冲突的操作，减少确定性步骤之间不必要的模型往返。然后针对瓶颈考虑工具优化、合适的缓存、模型选择和时间预算。流式输出用于提前交付信息，但不等于后台执行自动变快。

最后在相同任务和负载下比较 P50、P95、成功率、完整性与费用，确认提速没有靠降低任务质量实现。

一句话记忆：先找到决定完成时间的那条链，再减少它上面的等待和重复工作。