AI Agent 性能优化教程｜附配置文件

在大模型应用进入深水区之后，越来越多团队开始从“做一个能跑的 AI Agent”转向“做一个稳定、快速、可观测、可持续迭代的 AI Agent”。
同样是调用大模型，有的 Agent 响应慢、成本高、经常跑偏；有的 Agent 则可以稳定完成复杂任务，并在延迟、准确率、成本之间取得较好平衡。差距往往不只来自模型本身，而来自系统设计、提示词结构、工具调用策略、记忆机制、缓存机制、并发控制以及观测体系。

本文将围绕 AI Agent 性能优化 展开，介绍常见瓶颈、优化思路、工程实践，并提供一套可参考的配置文件示例，帮助你从原型阶段走向生产级 Agent。

一、AI Agent 的性能到底指什么？

很多人在讨论 AI Agent 性能时，第一反应是“模型回答得快不快”。但在实际系统中，Agent 性能至少包括以下几个维度：

因此，优化 AI Agent 不能只盯着模型 API 响应时间，而要从 架构、模型、Prompt、工具、记忆、缓存、调度、监控 等多个层面系统优化。

二、AI Agent 常见性能瓶颈

在优化之前，我们需要先定位问题。常见瓶颈主要有以下几类。

1. Prompt 过长，导致响应慢、成本高

许多 Agent 在开发初期会把大量说明、业务规则、示例、历史对话全部塞进 Prompt。这样虽然短期内看起来效果不错，但会造成：

• 输入 Token 暴涨；
• 模型推理变慢；
• 成本显著上升；
• 长上下文中关键信息被稀释；
• 模型更容易忽略重要指令。

2. 工具调用不受控

Agent 的核心能力之一是调用外部工具，例如搜索、数据库查询、代码执行、知识库检索、接口调用等。
但如果缺少策略控制，Agent 可能会出现：

• 明明可以直接回答，却频繁调用工具；
• 同一个工具重复调用；
• 工具参数生成错误；
• 多工具链路过长；
• 调用外部服务超时导致整体失败。

3. 记忆机制混乱

很多 Agent 会保存用户历史对话或任务记录，但如果不加筛选地全部注入上下文，会导致上下文越来越长。
记忆系统设计不当，可能产生以下问题：

• 历史信息污染当前任务；
• 隐私数据不当暴露；
• 无关记忆占用上下文；
• 用户偏好和任务事实混淆；
• 模型基于过期记忆做出错误判断。

4. 缺少缓存机制

不少请求具有重复性，例如：

• 相同问题反复询问；
• 相同文档反复摘要；
• 相同查询反复检索；
• 相同工具结果短时间内不会变化。

如果每次都重新调用模型和工具，就会浪费大量时间和成本。

5. 缺少超时、重试和降级策略

生产环境中，模型 API、向量数据库、搜索服务、业务接口都可能发生异常。
如果 Agent 没有合理的容错设计，用户体验会非常不稳定。

常见问题包括：

• 单个工具调用卡死；
• 模型返回格式不合法；
• 网络抖动导致请求失败；
• 上游服务限流；
• Agent 进入循环推理；
• 多步任务中任一步失败后无法恢复。

三、性能优化总体思路

AI Agent 的优化可以遵循一个基本原则：

能不用大模型就不用大模型；能少给上下文就少给上下文；能并行就并行；能缓存就缓存；能约束就约束；能观测就观测。

具体可以拆成以下几个方向：

1. 减少不必要的模型调用
2. 压缩 Prompt 和上下文
3. 优化工具选择和调用流程
4. 建立缓存与复用机制
5. 合理选择模型和参数
6. 控制最大迭代次数
7. 使用结构化输出
8. 增加超时、重试、降级
9. 完善日志、指标和链路追踪

四、模型选择优化

不同任务对模型能力的要求不同。生产系统中不建议所有请求都使用最强模型，而应采用分层策略。

1. 按任务复杂度选择模型

例如，一个 Agent 可以采用如下流程：

1. 先用小模型判断用户意图；
2. 如果是简单问题，直接回答；
3. 如果需要知识库，调用检索；
4. 如果是复杂任务，再切换到强模型规划和执行。

这样可以显著降低平均成本。

2. 合理设置模型参数

常见参数优化建议如下：

对于生产 Agent，建议将参数配置化，而不是写死在代码里。

五、Prompt 优化

Prompt 是 Agent 性能优化中最容易被忽视、但收益很高的部分。

1. 拆分系统指令和任务指令

系统指令用于定义角色、边界、输出规范；任务指令用于描述当前任务。
不要把所有内容混在一个大段文本里。

示例结构：

[系统角色]
你是一个企业级数据分析 Agent，擅长根据用户问题调用工具并生成可靠结论。

[行为规则]
1. 如果问题需要实时数据，必须调用数据查询工具。
2. 如果用户只询问概念解释，不调用工具。
3. 不确定时先澄清，不要编造。

[输出格式]
请使用 Markdown 输出，包含：结论、依据、下一步建议。

[当前任务]
用户问题：{{user_input}}

这种结构可以让模型更清楚地理解优先级，也便于后续维护。

2. 使用短指令替代长说明

很多 Prompt 会写成一大段自然语言，实际可以压缩成规则列表。
例如：

不推荐：

你在回答时要尽可能严谨，如果发现用户的问题涉及一些你不知道的实时信息，你应该先考虑是否需要调用工具……

推荐：

规则：
- 实时信息：调用工具；
- 已知常识：直接回答；
- 信息不足：先澄清；
- 不得编造数据。

3. 控制示例数量

Few-shot 示例确实能提升效果，但示例过多会显著增加 Token。
建议：

• 只保留高价值示例；
• 示例覆盖主要边界情况；
• 定期评估示例是否仍然有效；
• 对不同任务加载不同示例，而不是一次性加载全部示例。

4. 使用结构化输出

结构化输出可以减少模型自由发挥，提高下游解析稳定性。
例如要求模型输出 JSON：

{
  "intent": "search|chat|tool_call|clarify",
  "need_tool": true,
  "tool_name": "web_search",
  "arguments": {
    "query": "string"
  },
  "reason": "string"
}

对于工具调度类 Agent，结构化输出非常重要。它可以减少“模型说了一堆自然语言，但程序无法判断下一步做什么”的问题。

六、上下文与记忆优化

Agent 通常需要上下文记忆，但上下文不是越多越好。高质量记忆应当具备三个特征：

1. 与当前任务相关；
2. 信息准确且未过期；
3. 占用 Token 尽可能少。

1. 使用短期记忆和长期记忆分离

推荐将记忆分为：

• 短期记忆：当前会话上下文；
• 长期记忆：用户偏好、历史任务摘要、业务档案；
• 工作记忆：当前任务执行过程中的中间状态。

短期记忆适合保留最近几轮对话；长期记忆应通过检索按需注入；工作记忆则用于任务规划和工具调用，不一定全部暴露给模型。

2. 对历史对话做摘要

不要把完整历史对话无限追加到 Prompt 中。可以在对话超过一定长度后，生成摘要并替换旧消息。

摘要应包含：

• 用户目标；
• 已确认事实；
• 用户偏好；
• 已完成操作；
• 未解决问题；
• 关键约束。

示例：

会话摘要：
用户正在准备一份 AI Agent 性能优化方案。用户偏好中文 Markdown 输出，要求内容偏工程实践，包含配置文件示例。已讨论模型选择、Prompt 优化、缓存和监控。

3. 检索相关记忆

长期记忆建议存入向量库或数据库，通过当前问题检索相关片段，而不是全部注入。

检索流程可以是：

1. 用户输入向量化；
2. 从记忆库检索 Top-K；
3. 对结果按相关性、时间、权限过滤；
4. 将少量高相关记忆注入 Prompt。

七、工具调用优化

工具调用是 Agent 性能优化的重点。一个优秀的 Agent 不只是“会调用工具”，而是“知道什么时候调用、调用哪个、怎么调用、调用失败怎么办”。

1. 建立工具描述规范

工具描述要简洁、明确，避免模型误用。

示例：

tools:
  - name: web_search
    description: 用于查询实时互联网信息，例如新闻、价格、政策、版本更新。不用于回答通用常识问题。
    parameters:
      query:
        type: string
        description: 搜索关键词，应该简短明确
      limit:
        type: integer
        default: 5

如果工具描述太宽泛，模型容易滥用工具。

2. 工具调用前先做意图判断

不要让复杂 Agent 每次都进入多轮 ReAct。可以先做一个轻量级路由：

判断用户请求属于以下哪类：
- direct_answer：可直接回答；
- retrieval：需要知识库；
- realtime_search：需要实时信息；
- business_api：需要调用业务接口；
- clarify：信息不足，需要追问。

这一步可以使用小模型，甚至用规则完成。

3. 限制最大调用次数

Agent 进入循环是常见问题。必须设置：

• 最大推理轮数；
• 最大工具调用次数；
• 单工具最大重试次数；
• 总超时时间；
• 最大 Token 消耗。

例如：

agent:
  max_iterations: 6
  max_tool_calls: 4
  max_total_tokens: 12000
  timeout_ms: 30000

4. 并行调用工具

对于互不依赖的工具，可以并行执行。
例如用户要求“对比三个竞品近期价格和用户评价”，可以并行调用搜索、评论抓取、价格查询接口，然后汇总结果。
并行可以显著降低总延迟，但需要注意：

• 控制并发数量；
• 设置单任务超时；
• 汇总失败结果；
• 避免对下游服务造成压力。

八、缓存优化

缓存是降低成本和延迟的有效手段，尤其适合高频重复场景。

1. 可缓存内容

常见可缓存对象包括：

• 用户意图识别结果；
• FAQ 答案；
• 文档摘要；
• 向量检索结果；
• 工具 API 返回结果；
• 模型中间推理结果；
• 最终回答。

2. 缓存粒度

缓存粒度可以分为：

其中语义缓存需要结合向量检索和相似度阈值，适合 FAQ、客服、知识库问答等场景。

3. 缓存失效策略

缓存不是永久有效的。需要根据业务设置 TTL：

• 新闻、行情：几分钟；
• 商品库存：几十秒到几分钟；
• FAQ：几小时到几天；
• 文档摘要：文档未变更前长期有效；
• 用户偏好：长期有效但允许更新。

九、RAG 检索优化

很多 Agent 依赖 RAG 获取知识。RAG 性能直接影响 Agent 效果。

1. 优化文档切分

文档切分过大，会导致检索不精准；切分过小，会丢失上下文。
建议：

• 普通知识文档：500～1000 中文字左右；
• 技术文档：按标题层级切分；
• FAQ：按问答对切分；
• 法律、合同类文档：按条款切分；
• 表格数据：保留表头和上下文。

2. 混合检索

单纯向量检索有时对关键词、编号、专有名词不敏感。
可以结合：

• BM25；
• 向量检索；
• 元数据过滤；
• 重排序模型；
• 规则召回。

推荐流程：

用户问题
  -> 查询改写
  -> BM25 + 向量混合召回
  -> 元数据过滤
  -> Rerank 重排序
  -> Top-K 注入上下文
  -> 模型生成答案

3. 控制注入文档数量

不要把检索到的所有文档都塞给模型。
通常建议 Top-K 控制在 3～8 个片段，并根据模型上下文窗口动态调整。

十、并发与队列优化

当 Agent 面向多用户服务时，并发控制非常重要。

1. 设置请求队列

对于耗时任务，例如长文档分析、批量数据处理、复杂报告生成，可以放入异步队列执行。
用户先获得任务 ID，然后通过轮询或 WebSocket 获取结果。

2. 限流与熔断

需要对以下对象设置限流：

• 单用户请求频率；
• 单租户 Token 消耗；
• 单工具调用频率；
• 模型 API 调用频率；
• 数据库查询频率。

当上游模型或工具异常时，应触发熔断，避免雪崩。

3. 流式响应

对于长回答，建议开启流式输出。
虽然总生成时间未必减少，但用户可以更早看到内容，感知延迟显著下降。

十一、可观测性优化

没有可观测性，就没有真正的性能优化。
生产级 Agent 至少需要记录以下信息：

• 用户请求 ID；
• 模型名称；
• Prompt Token；
• Completion Token；
• 总 Token；
• 模型响应时间；
• 工具调用名称；
• 工具参数；
• 工具耗时；
• 工具错误；
• Agent 迭代次数；
• 最终状态；
• 用户反馈。

1. 关键指标

推荐监控以下指标：

2. 链路追踪

一次 Agent 请求往往包含多步调用：

用户请求 -> 意图识别 -> RAG 检索 -> 工具调用 -> 模型生成 -> 格式校验 -> 返回结果

如果没有 Trace ID，很难定位到底是哪一步慢、哪一步失败。建议为每次请求生成全局 trace_id，贯穿所有日志。

十二、配置文件示例

下面给出一份适合生产环境参考的 agent-config.yaml。你可以根据实际框架进行调整。

app:
  name: ai-agent-service
  env: production
  timezone: Asia/Shanghai
  log_level: INFO

agent:
  name: enterprise-assistant
  mode: tool-augmented
  language: zh-CN
  max_iterations: 6
  max_tool_calls: 4
  max_total_tokens: 12000
  enable_streaming: true
  timeout_ms: 30000

models:
  router:
    provider: openai-compatible
    model: small-router-model
    temperature: 0.1
    max_tokens: 300
    timeout_ms: 5000
    retries: 1

  planner:
    provider: openai-compatible
    model: advanced-reasoning-model
    temperature: 0.2
    max_tokens: 1200
    timeout_ms: 15000
    retries: 2

  generator:
    provider: openai-compatible
    model: general-chat-model
    temperature: 0.3
    max_tokens: 2500
    timeout_ms: 20000
    retries: 2

  summarizer:
    provider: openai-compatible
    model: cost-effective-summary-model
    temperature: 0.1
    max_tokens: 800
    timeout_ms: 8000
    retries: 1

prompt:
  system_template: prompts/system.md
  router_template: prompts/router.md
  planner_template: prompts/planner.md
  response_template: prompts/response.md
  max_history_messages: 8
  enable_prompt_compression: true
  compression_trigger_tokens: 6000

memory:
  short_term:
    enabled: true
    max_messages: 10
    summarize_after_messages: 12

  long_term:
    enabled: true
    backend: vector_db
    top_k: 5
    similarity_threshold: 0.78
    include_user_preferences: true
    max_injected_tokens: 1500

rag:
  enabled: true
  embedding_model: text-embedding-model
  vector_store:
    type: milvus
    collection: enterprise_knowledge_base
    host: localhost
    port: 19530

  retrieval:
    strategy: hybrid
    top_k_vector: 20
    top_k_keyword: 20
    rerank_top_k: 6
    min_score: 0.65
    max_context_tokens: 3000

  chunking:
    chunk_size: 800
    chunk_overlap: 120
    split_by_heading: true

tools:
  max_concurrency: 3
  default_timeout_ms: 8000
  default_retries: 1

  list:
    - name: web_search
      enabled: true
      timeout_ms: 6000
      cache_ttl_seconds: 300
      description: 查询实时互联网信息，不用于通用常识问答。

    - name: database_query
      enabled: true
      timeout_ms: 8000
      cache_ttl_seconds: 60
      description: 查询企业内部结构化数据，只能执行只读 SQL。

    - name: document_retriever
      enabled: true
      timeout_ms: 5000
      cache_ttl_seconds: 600
      description: 查询企业知识库文档片段。

cache:
  enabled: true
  backend: redis
  host: localhost
  port: 6379
  semantic_cache:
    enabled: true
    similarity_threshold: 0.92
    ttl_seconds: 3600
  response_cache:
    enabled: true
    ttl_seconds: 1800
  tool_cache:
    enabled: true
    default_ttl_seconds: 300

rate_limit:
  enabled: true
  per_user:
    requests_per_minute: 20
    tokens_per_day: 200000
  per_tenant:
    requests_per_minute: 500
    tokens_per_day: 5000000

fallback:
  enabled: true
  on_model_timeout: use_smaller_model
  on_tool_error: continue_with_partial_result
  on_rag_empty: ask_clarification
  max_fallback_attempts: 2

observability:
  tracing:
    enabled: true
    provider: opentelemetry
    sample_rate: 1.0

  metrics:
    enabled: true
    export_interval_seconds: 30
    include_token_usage: true
    include_latency_percentiles: true

  logging:
    redact_sensitive_data: true
    log_prompt: false
    log_tool_arguments: true
    log_model_response: false

十三、Prompt 文件示例

1. prompts/router.md

你是一个请求路由器，需要判断用户请求应该如何处理。

请只输出 JSON，不要输出解释性文字。

可选 intent：
- direct_answer：无需工具，可直接回答
- rag：需要查询知识库
- realtime_search：需要实时信息
- business_api：需要调用业务接口
- clarify：信息不足，需要追问

输出格式：
{
  "intent": "direct_answer|rag|realtime_search|business_api|clarify",
  "confidence": 0.0,
  "reason": "简短原因",
  "suggested_tools": []
}

用户请求：
{{user_input}}

2. prompts/planner.md

你是一个任务规划 Agent。你的目标是用尽可能少的步骤完成用户任务。

规则：
1. 不要调用无关工具。
2. 如果已有信息足够，直接生成答案。
3. 如果工具失败，可以基于已有信息给出部分结论，并说明限制。
4. 最大工具调用次数为 {{max_tool_calls}}。
5. 不得编造数据、链接、接口结果。

请输出 JSON：
{
  "steps": [
    {
      "type": "tool_call|reasoning|final",
      "tool": "工具名称或 null",
      "arguments": {},
      "purpose": "该步骤目的"
    }
  ]
}

用户请求：
{{user_input}}

可用上下文：
{{context}}

可用工具：
{{tools}}

3. prompts/response.md

你是一个专业、可靠的中文 AI 助手。

请根据用户问题、检索内容和工具结果生成最终回答。

要求：
- 使用 Markdown；
- 先给结论，再给依据；
- 如果信息不完整，明确说明不确定性；
- 不得编造工具结果中不存在的数据；
- 如适合，给出下一步建议。

用户问题：
{{user_input}}

检索内容：
{{retrieved_context}}

工具结果：
{{tool_results}}

十四、Python 伪代码示例

下面是一个简化版 Agent 调度流程，展示如何将路由、缓存、RAG、工具和模型调用组合起来。

def handle_request(user_id: str, user_input: str):
    trace_id = create_trace_id()

    # 1. 请求级缓存
    cached = response_cache.get(user_id, user_input)
    if cached:
        log_event(trace_id, "cache_hit", {"type": "response"})
        return cached

    # 2. 意图路由
    route = call_model(
        model="router",
        prompt=render("prompts/router.md", {
            "user_input": user_input
        }),
        trace_id=trace_id
    )

    # 3. 根据意图处理
    context = ""
    tool_results = []

    if route["intent"] == "clarify":
        return "为了更准确地处理你的请求，请补充更多背景信息。"

    if route["intent"] == "rag":
        context = retrieve_knowledge(user_input, top_k=6, trace_id=trace_id)

    if route["intent"] == "realtime_search":
        result = call_tool(
            name="web_search",
            arguments={"query": user_input, "limit": 5},
            timeout_ms=6000,
            trace_id=trace_id
        )
        tool_results.append(result)

    if route["intent"] == "business_api":
        plan = call_model(
            model="planner",
            prompt=render("prompts/planner.md", {
                "user_input": user_input,
                "context": context,
                "tools": get_available_tools(),
                "max_tool_calls": 4
            }),
            trace_id=trace_id
        )
        tool_results = execute_plan(plan, trace_id=trace_id)

    # 4. 最终回答
    answer = call_model(
        model="generator",
        prompt=render("prompts/response.md", {
            "user_input": user_input,
            "retrieved_context": context,
            "tool_results": tool_results
        }),
        stream=True,
        trace_id=trace_id
    )

    # 5. 写入缓存和日志
    response_cache.set(user_id, user_input, answer, ttl=1800)
    log_event(trace_id, "request_done", {
        "route": route["intent"],
        "tool_count": len(tool_results)
    })

    return answer

十五、性能优化落地清单

最后给出一份可直接用于项目评审的检查清单。

架构层

• [ ] 是否区分简单任务和复杂任务？
• [ ] 是否使用小模型做路由？
• [ ] 是否支持流式响应？
• [ ] 是否支持异步任务？
• [ ] 是否设置最大迭代次数？

Prompt 层

• [ ] 系统指令是否简洁？
• [ ] 是否使用结构化输出？
• [ ] 是否减少无关示例？
• [ ] 是否按任务加载 Prompt？
• [ ] 是否有输出格式校验？

工具层

• [ ] 工具描述是否清晰？
• [ ] 是否限制工具调用次数？
• [ ] 是否设置工具超时？
• [ ] 是否有工具重试机制？
• [ ] 是否缓存工具结果？

记忆与上下文层

• [ ] 是否限制历史消息数量？
• [ ] 是否对长对话做摘要？
• [ ] 长期记忆是否按需检索？
• [ ] 是否避免注入无关记忆？
• [ ] 是否处理敏感信息？

RAG 层

• [ ] 文档切分是否合理？
• [ ] 是否使用混合检索？
• [ ] 是否使用 Rerank？
• [ ] Top-K 是否可配置？
• [ ] 是否记录检索命中率？

稳定性层

• [ ] 是否设置模型调用超时？
• [ ] 是否设置有限重试？
• [ ] 是否有降级策略？
• [ ] 是否有熔断机制？
• [ ] 是否处理部分失败结果？

观测层

• [ ] 是否记录 Trace ID？
• [ ] 是否监控 Token 消耗？
• [ ] 是否统计延迟分位数？
• [ ] 是否记录工具调用耗时？
• [ ] 是否收集用户反馈？

十六、总结

AI Agent 的性能优化不是单点优化，而是一套系统工程。
如果只更换更强模型，可能短期内提升效果，但也会带来更高成本和更长延迟。真正可持续的优化方式，是将 Agent 拆解为多个可控模块：路由、规划、工具、记忆、RAG、缓存、生成、观测和降级。

一个生产级 AI Agent 应该具备以下能力：

1. 能判断任务复杂度，选择合适模型；
2. 能控制上下文长度，避免 Token 浪费；
3. 能准确选择工具，而不是盲目调用；
4. 能缓存高频结果，降低成本和延迟；
5. 能处理异常，支持重试、超时和降级；
6. 能记录完整链路，方便持续优化；
7. 能通过配置文件灵活调整策略。

建议你在项目中优先从以下三步开始：

1. 先加可观测性：记录延迟、Token、工具调用和失败原因；
2. 再做上下文瘦身：压缩 Prompt、摘要历史、限制注入内容；
3. 最后做系统优化：模型路由、缓存、并发、降级和自动评估。

当这些基础能力完善后，AI Agent 才能从“能演示”真正走向“能生产”。