面试题 · Agent
假设一个Agent的推理链路由3个工具调用组成，且面临高频请求导致系统延迟较高，你会从哪些方面进行性能优化？请从并行化、缓存、调度、资源分配等角度提出解决方案。
asyncio.gather或线程池），理论延迟从T1+T2+T3降到max(T1,T2,T3)| 层级 | 缓存内容 | 失效策略 |
|---|---|---|
| 工具结果缓存 |
学习内容与项目面试，在同一条路上。
| 工具输入→输出映射 |
| TTL+版本号，高频工具设30s-5min |
| LLM输出缓存 | 相似query的完整推理链 | 语义相似度匹配，embedding检索 |
| 前缀缓存 | 多轮对话的KV Cache | vLLM自动管理 |
关键：先埋点定位是LLM生成慢、工具调用慢还是网络传输慢，再针对性投入。
建议系统学习该知识点
场景切入
假设你做个客服Agent，用户问个复杂问题需要调三个工具：查订单、查库存、算价格，结果请求一多就卡得不行。你会怎么优化这个推理链路，让响应快起来？
层层追问
Agent的推理链路如果有多个工具调用，延迟高了你一般怎么搞？……如果这三个工具其实不依赖彼此，能不能并行跑？……那再想想，相同输入的工具输出能不能缓存？……还有请求调度上有什么办法？
直球架构
给你一个Agent，推理链路由三个工具调用组成，高频请求下延迟高。从并行化、缓存、调度、资源分配几个角度，说说你的优化方案。
这道题其实是在问，当[[Agent]]的推理链路里工具调用多了、请求量上来了，怎么在延迟和成本之间做平衡。我的思路是分层优化，先定位瓶颈再动手。
先说并行化。这里有个前提：得先判断三个工具之间有没有数据依赖。如果它们是独立的，比如三个工具分别查订单状态、用户信用和库存，互不依赖，那就可以把串行改成并行，用asyncio.gather或者线程池，延迟就从T1+T2+T3降到max(T1,T2,T3)。但如果有依赖，比如后一个工具需要前一个工具的输出，那就不能简单并行，这时候可以考虑流式规划，让LLM边生成参数边执行，不等完整的JSON，减少空等时间。
再讲缓存。不是所有请求都值得缓存，得看场景。我一般会分三层：工具结果缓存，比如同样的订单号查状态，短时间内结果不变，设个TTL比如30秒到5分钟；LLM输出缓存，对相似的query直接复用整个推理链，用[[Embedding]]做语义匹配；还有[[KV Cache]]，多轮对话时省掉重复计算。这里有个坑：缓存一致性。如果数据更新了，缓存没失效，就可能给用户错误结果。所以我会给高频工具加版本号，数据变了缓存自动失效。
举个例子，客服退款场景。Agent的推理链是：先查订单状态，再查退款规则，最后执行退款。高频请求下，如果每个请求都从头查一遍，延迟很高。我的做法是：把查订单状态和查退款规则这两个独立工具并行调用，同时把常见订单的查询结果缓存起来，比如近5分钟的退款规则缓存。这样大部分请求的延迟就从3次串行降到1次并行加一次缓存命中。
调度和资源分配上，我会做优先级队列，把实时请求和异步任务分开，VIP用户走独立队列。另外，相同工具的请求可以攒批处理，比如把4到8个查订单状态的请求合并成一个批量查询，提升GPU利用率。但要注意背压，队列太长就快速拒绝或降级，别让系统雪崩。工具分级也很重要：慢工具单独部署，比如查外部API超过500ms的，别让它阻塞主链路。动态扩缩容按QPS来，冷启动靠预置实例。
这里其实有个更深的点：缓存和并行只能解决一部分问题，如果LLM生成本身慢，那还得从模型层面优化，比如用更小的模型或者量化。我一般上线前会先埋点，定位到底是LLM生成慢、工具调用慢还是网络传输慢，再针对性优化。
所以我的整体判断是：对于高频请求的Agent，我会先做依赖分析和延迟埋点，然后并行化独立的工具，对重复请求做多级缓存，再配合优先级调度和资源隔离。如果只让我选一个最优先的，我倾向先做缓存，因为性价比最高。