当前位置：首页>面试真题>Agent面试真题10:AI Agent开发工程师必会的10道性能优化面试题(附详细答案)

Agent面试真题10:AI Agent开发工程师必会的10道性能优化面试题(附详细答案)

2026-07-18 22:50:29

大家好，我是大志。

前面几篇文章中，我们整理了 Agent 架构、提示词工程、工具调用、记忆管理和 RAG 等面试题。这些内容主要在讲如何搭建和开发一个 Agent 应用，但在项目真正落地之后，往往还要解决一些性能和成本问题，比如如何降低 Token 成本、如何优化 Agent 响应速度、如何定位 Agent 故障等。

这些问题也是面试官经常会考查的点。因此，本文系统地整理了 Agent 性能优化相关的高频面试题和详细答案。

另外，完整的 AI Agent 面试题文档也已经同步到了 aiflowline.cn，大家可以结合文章一起阅读。

1、如何降低 `Agent` 应用的 `Token` 成本？

LLM 的 Token 消耗来自输入和输出，所以降低 Agent 应用的 Token 成本，本质上就是减少无效的输入和输出。

可以从以下几个方向进行优化：

精简 System Prompt：去掉一些重复、无意义的提示词。规则校验不要写在提示词中，使用代码校验的成本更低。
减少无关上下文：不要把所有的历史消息、文档都放到提示词中，只放与当前问题最相关的部分。
会话摘要：当会话内容过长时，可以对早期的聊天内容进行摘要和压缩，再放入提示词中。
RAG Rerank 重排序：进行 RAG 检索时，会检索出数量较多的文档。可以通过 Rerank 重排序，找到最相关的文档片段并放入提示词，避免大量不相关的文本片段进入 Prompt。
限制输出长度：如果只需要输出问题答案，就明确要求 LLM 只输出答案，不输出分析过程。
不同模型处理不同任务：将复杂的分析和决策交给能力较强的 GPT、Claude 模型；对于分类、意图识别等简单需求，使用小参数模型即可。

2、如何提高 `Agent` 响应速度？

Agent 的整个调用流程包括 LLM 调用、工具调用、RAG 检索等步骤，因此提高 Agent 响应速度主要可以从以下几个方面入手。

意图识别

Agent 执行任务时，并非每个任务都需要执行所有流程。比如用户提问“你好，你是谁？”，这类简单问题直接交给 LLM 回答即可。因此，在用户提问后，要先判断用户意图。

减少提示词长度

输入的提示词越长，LLM 响应越慢，因此要精简提示词，减少无关的历史记忆和 RAG 文档。

优先使用流式输出

这里的流式输出，不仅指 LLM 生成内容的流式返回，也包括流式展示记忆召回、工具调用、RAG 检索等过程，这样可以显著改善用户体验。

工具并行执行

对于执行结果互不依赖的工具，可以并行调用来减少等待时间。

热点数据缓存

缓存相同文本的 Embedding 向量、热点问题的 RAG 检索结果、长期记忆等信息。

设置工具超时时间

调用外部工具是 Agent 响应速度慢的重要原因之一，因此一定要设置超时时间，不能无限期等待。

3、在 `Agent` 应用中，哪些部分可以使用缓存，如何设计缓存？

在 Agent 应用中，可以缓存热点数据来提升响应速度，同时要分层设计缓存。

常见缓存如下：

回答缓存：对于完全相同的提问，可以将最终答案进行缓存。
RAG 检索缓存：对相同问题进行 RAG 检索的结果可以缓存一段时间，尤其是针对热点问题。
Embedding 缓存：同一段文本通过 Embedding 生成的向量数据可以进行缓存，使用时直接取出。
工具结果缓存：对于天气、汇率、商品等信息查询工具，可以对结果进行缓存，并根据业务设置合适的过期时间。
用户画像缓存：用户偏好、组织信息等需要频繁读取的数据可以放入缓存中。

使用缓存时需要注意，在设计缓存 key 时，应按用户隔离私有数据。不同用户的权限、知识库数据和记忆数据有所不同，答案也会不同。此外，还要设置合适的缓存过期时间，避免出现数据污染。

4、如何监控 `Agent` 运行状态？

在 Agent 运行过程中，不能只看接口请求是否成功，还要监控 Agent 的一些关键指标。

可以从以下层面对 Agent 进行监控：

接口层：请求数量、成功率、错误率、平均响应时间。
LLM 层：LLM 调用次数、首个 Token 响应时间、LLM 总体响应时间、输入和输出 Token 数量。
工具层：调用次数、成功率、重试次数、平均耗时、调用失败原因。
业务层：任务完成率、用户点赞/点踩、转人工率。

在生产环境中，可以使用 Prometheus 和 Grafana 展示监控数据，使用 ELK 进行日志查询，使用 OpenTelemetry 采集完整的链路信息。在 LangChain 或 LangGraph 项目中，也可以使用 LangSmith 查看 LLM 调用、工具调用等节点的执行过程。

5、如何统计 `Agent` 的 `Token` 消耗？

Agent 执行一次任务的过程中，可能会多次调用模型。因此，要计算一次任务使用的 Token 数量，需要统计每次 LLM 调用的用量并求和，得到最终消耗的总量。LLM 响应一般会返回本次调用的输入 Token、输出 Token 和总 Token 数量，因此可以在每次调用后记录这些 Token 信息。

之后再根据所用模型的输入 Token 单价和输出 Token 单价进行计算：

本次调用费用 = 输入 Token 数量 × 输入单价 + 输出 Token 数量 × 输出单价

现在大多数模型都支持缓存。如果命中缓存，就需要按照模型缓存命中的价格计算，最终得到实际花费金额。需要注意的是，本地的 Token 分词器适合用于费用估算，不适合直接用于账单计算，因为不同模型厂商的 Token 计算方法并不相同。

6、如何统计 `Tool` 调用成功率？

统计 Tool 调用成功率时，要区分技术调用成功和业务调用成功。技术成功是指工具正常返回结果；业务成功是指不仅正常返回结果，还表示业务也执行成功，例如查询到指定订单、成功创建商品等。

Tool 调用成功率的基本计算方式如下：

Tool 技术成功率 = 技术成功次数 / 总调用次数 × 100%Tool 业务成功率 = 业务成功次数 / 总调用次数 × 100%

比如一天调用天气查询工具 10000 次，成功 9900 次，失败 100 次，Tool 调用成功率就是 99%。

可以通过埋点、日志和统计系统来计算 Tool 调用成功率。每次工具调用完成后，生成一条如下的 Trace 信息：

{"trace_id": "trace_001","tool_name": "search_docs","success": true,"duration_ms": 320,"error_type": null,"retry_count": 0}

然后通过 Prometheus 和 Grafana 进行指标监控，就可以完成对 Tool 调用成功率的监控。

7、如何定位 `Agent` 故障？

Agent 出现故障通常涉及模型、Prompt、RAG、工具等多个环节。定位问题时，不能只关注报错信息，还要根据 trace_id 排查整条链路中出现的异常。

可以对下面的环节进行重点检查：

用户输入：问题是否完整，是否缺少关键信息，或者有歧义。
Prompt：系统提示词是否正确，记忆信息和 RAG 文档是否与问题相关。
LLM 推理：LLM 是否选择了正确的工具，工具参数是否正确。
RAG 检索：文档是否被正常召回，检索出的文档 Chunk 的语义是否完整，重排序是否将最相关的内容排在前面。
工具执行：工具执行是否超时或被限流，用户是否具有工具执行权限，工具调用是否因参数校验失败或接口异常而失败。
状态流转：执行图运行时，是否进入错误的分支，是否重复执行同一个节点，是否超过最大步骤数。
最终回答：LLM 是否正确使用工具执行结果和 RAG 检索结果，是否遗漏信息，是否出现幻觉。

定位到出错的环节后，再使用相同的问题、Prompt、LLM 和工具配置进行复现。不过，Agent 的输出具有较强的不确定性，可能需要多次执行，以判断是必现问题还是偶发问题。

8、如何做 `Agent` 链路追踪？

在 Agent 应用中，链路追踪主要通过 Trace ID 和 Span 记录一次 Agent 的执行过程。首先，为一次用户请求生成唯一的 Trace ID；Agent 应用内部的各个步骤，如 LLM 调用、RAG 检索、工具调用和记忆召回，都会生成 Span。这样就可以清楚地查看整个执行过程，方便分析每个步骤的耗时并定位故障。

在 Span 中可以记录如下信息：

{"trace_id": "trace_001","span_id": "span_002","name": "search_docs","type": "tool","start_time": "...","end_time": "...","duration_ms": 320,"status": "success","input": {},"output": {},"error": null}