AI Agent 如何降低成本｜附配置文件

在过去一年里，AI Agent（智能体）从“概念演示”逐渐走向真实业务场景。无论是自动客服、代码助手、数据分析助手、运营内容生成，还是企业内部知识库问答，Agent 都开始承担越来越多的任务。

但很多团队在落地过程中会遇到一个非常现实的问题：

AI Agent 效果看起来不错，但成本太高。

一次对话可能调用多次大模型；一次任务可能触发搜索、检索、工具调用、代码执行、总结生成；如果再加上长上下文、多轮记忆、向量数据库、日志存储和评估系统，成本很快就会超出预期。

因此，构建 AI Agent 不只是“能跑起来”，更重要的是：

在保证效果的前提下，把每一次推理、每一次调用、每一次检索都设计得更经济。

本文将系统讲解 AI Agent 的成本构成、常见浪费点、降本策略，并附上一份可参考的 Agent 配置文件，帮助你在实际项目中更好地控制成本。

一、AI Agent 的成本主要来自哪里？

很多人以为 AI Agent 的成本就是大模型 API 费用。实际上，这只是其中最显性的部分。

一个完整的 AI Agent 系统，通常包含以下成本：

1. 大模型调用成本
2. Embedding 向量化成本
3. 向量数据库存储与检索成本
4. 工具调用成本
5. 长上下文成本
6. 多轮对话记忆成本
7. 日志、监控、评估成本
8. 失败重试与无效调用成本
9. 工程维护与部署成本

其中，大模型调用成本往往最容易被注意到，但真正造成浪费的，通常是系统设计不合理导致的“隐性成本”。

例如：

• 用户只是问一个简单问题，却调用了最贵的模型；
• 每次对话都带上大量历史消息；
• 检索系统返回了过多无关文档；
• Agent 为了完成简单任务，进行了多轮规划和工具调用；
• 没有缓存机制，重复问题反复调用模型；
• 模型输出过长，生成了大量用户并不需要的内容；
• Prompt 写得过于臃肿，每次调用都消耗大量 token。

这些问题单独看似不严重，但当调用量上升后，成本会被快速放大。

二、AI Agent 成本高的典型原因

1. 默认使用最强模型

很多团队在早期开发时，为了追求效果，会直接使用能力最强、价格最高的大模型。这在验证阶段没问题，但如果上线后仍然所有任务都使用高端模型，成本会非常高。

事实上，大量任务并不需要最强模型。

例如：

如果用户只是问“怎么修改密码”，系统却调用高成本模型进行复杂推理，这就是典型浪费。

2. Prompt 过长

Prompt 是 Agent 的“系统说明书”。很多团队为了让 Agent 更可靠，会不断往系统提示词里加入规则、背景、示例、约束、异常处理说明。

最终，一个简单请求也要携带几千甚至上万 token 的 Prompt。

这会带来两个问题：

1. 输入 token 成本上升
2. 模型注意力被稀释，效果可能反而下降

一个优秀的 Prompt 不一定很长，而是结构清晰、边界明确、任务聚焦。

3. 上下文管理粗糙

多轮对话是 Agent 的重要能力，但如果每次请求都把完整历史对话塞给模型，成本会非常高。

尤其在客服、知识库问答、数据分析等场景中，用户可能连续对话几十轮。如果不做上下文压缩和摘要，后期每一次调用都会越来越贵。

常见错误包括：

• 每次携带全部历史消息；
• 历史消息没有摘要；
• 不区分关键信息与闲聊内容；
• 用户已解决的问题仍然保留在上下文中；
• 工具返回的大段内容直接进入下一轮 Prompt。

4. RAG 检索不精准

RAG（Retrieval-Augmented Generation，检索增强生成）是企业知识库问答中常见架构。它可以让 Agent 基于私有知识回答问题，减少幻觉。

但如果 RAG 配置不合理，也会显著增加成本。

例如：

• 文档切分过大，导致每次检索返回大量 token；
• top_k 设置过高，返回过多片段；
• 没有 rerank，导致无关内容进入上下文；
• 没有相似度阈值，低相关片段也被传给模型；
• 文档元数据缺失，无法精准过滤；
• 用户问题很简单，却仍然触发复杂检索流程。

RAG 的关键不是“检索越多越好”，而是“检索越准越好”。

5. Agent 工具调用过度

Agent 的魅力在于可以调用工具，比如搜索网页、查询数据库、执行代码、发送邮件、调用 API 等。

但工具调用也有成本：

• 工具本身可能收费；
• 工具调用会增加延迟；
• 工具结果通常会进入模型上下文；
• 工具失败后可能触发重试；
• 多工具规划会增加模型调用次数。

一个设计不佳的 Agent，可能会为了回答一个简单问题，进行如下流程：

1. 调用模型判断意图；
2. 调用搜索工具；
3. 调用数据库工具；
4. 调用模型总结；
5. 发现信息不够，再搜索一次；
6. 再调用模型重新总结；
7. 最后生成回答。

这样的链路成本很高，而且用户体验也不一定好。

三、AI Agent 降低成本的核心思路

AI Agent 降本不是简单地“换便宜模型”，而是一个系统工程。可以从以下几个方向入手：

1. 模型分层
2. 任务路由
3. Prompt 精简
4. 上下文压缩
5. 检索优化
6. 缓存机制
7. 工具调用控制
8. 输出长度控制
9. 失败重试治理
10. 监控与评估闭环

下面逐项展开。

四、模型分层：不要所有任务都用最贵模型

模型分层是最有效的降本方式之一。

可以将模型分为三类：

1. 轻量模型

适合：

• 意图识别
• 分类
• 标签提取
• 简单问答
• 格式转换
• 文本摘要
• 简单改写

特点：

• 便宜
• 速度快
• 适合高频任务

2. 中等模型

适合：

• 普通内容生成
• 常规知识问答
• 简单代码生成
• 多轮对话
• 轻度推理

特点：

• 成本适中
• 效果稳定
• 适合作为默认模型

3. 高端模型

适合：

• 复杂推理
• 多步骤规划
• 高风险决策
• 复杂代码任务
• 严谨文档分析
• 重要客户场景

特点：

• 能力强
• 成本高
• 应该按需调用

推荐策略是：

80% 的任务使用轻量或中等模型，只有 20% 的复杂任务使用高端模型。

甚至可以进一步设计为：

先用便宜模型判断任务难度，再决定是否升级到高端模型。

这比一开始就调用高端模型要经济得多。

五、任务路由：让 Agent 先判断“该怎么处理”

任务路由的目标是：根据用户请求的类型、难度和风险，选择合适的处理流程。

例如，用户输入：

“帮我总结这段文字”

这类任务可以直接调用轻量模型。

用户输入：

“分析这份合同中可能对我不利的条款”

这类任务风险更高，可能需要高端模型，并且需要引用原文依据。

用户输入：

“我们上个月华东区销售额下降的原因是什么？”

这类任务可能需要调用数据库、报表系统，再由模型分析。

一个简单的路由逻辑如下：

router:
  rules:
    - name: simple_rewrite
      description: 简单改写、润色、摘要
      model: cheap_model
      tools: []
      max_tokens: 800

    - name: knowledge_qa
      description: 企业知识库问答
      model: standard_model
      tools:
        - vector_search
      max_tokens: 1200

    - name: data_analysis
      description: 数据查询与分析
      model: standard_model
      tools:
        - sql_query
      max_tokens: 1500

    - name: complex_reasoning
      description: 复杂推理、多步骤规划、高风险问题
      model: advanced_model
      tools:
        - vector_search
        - calculator
      max_tokens: 2000

通过路由，Agent 不再是“一个模型打天下”，而是根据任务动态选择最经济的路径。

六、Prompt 精简：减少每次调用的固定成本

Prompt 的优化非常重要。因为系统提示词通常会在每次调用时重复发送，属于固定成本。

优化前的 Prompt 常见问题

你是一个非常专业、非常认真、非常可靠、非常友好、非常聪明的 AI 助手。
你需要尽可能详细地回答用户的问题。
你要充分理解用户意图。
你不能胡说。
你要一步一步思考。
你要回答得有条理。
你要在必要时使用工具。
你要在不确定时说明不确定。
你要……

这类 Prompt 看起来完整，但很多内容重复、模糊、不可执行。

优化后的 Prompt 示例

你是企业内部 AI 助手。请遵守：
1. 只回答与企业业务、流程、知识库相关的问题；
2. 如果知识库无依据，明确说明“未找到依据”；
3. 回答应简洁，优先使用列表；
4. 涉及制度、流程、价格、合同条款时，必须引用来源；
5. 不编造数据，不输出未经验证的信息。

优化后的 Prompt 更短、更明确，也更便于模型执行。

Prompt 降本建议

• 删除重复形容词；
• 删除不可执行要求；
• 用结构化规则代替长段描述；
• 将低频规则放入条件分支，不要每次都带上；
• 将示例数量控制在必要范围；
• 不同任务使用不同 Prompt，而不是一个巨型 Prompt。

七、上下文压缩：不要把所有历史都发给模型

多轮对话中，最重要的是保留“对当前任务有用的信息”，而不是完整聊天记录。

推荐采用三层记忆结构：

1. 短期上下文

保存最近几轮对话，例如最近 3～5 轮。

适合保留当前任务连续性。

2. 摘要记忆

当对话过长时，将历史对话压缩成摘要。

例如：

用户正在咨询企业报销流程。已确认用户属于市场部，报销类型为差旅报销，金额约 3200 元。用户重点关注需要哪些发票和审批人。

这样可以用几十到几百 token 替代几千 token 的历史记录。

3. 长期记忆

只保存稳定、有长期价值的信息，例如：

• 用户身份；
• 用户偏好；
• 所属部门；
• 常用语言；
• 已授权的业务范围。

但要注意隐私和合规，不应随意存储敏感信息。

八、RAG 检索优化：减少无关上下文

如果你的 Agent 使用知识库，RAG 是重点优化对象。

1. 合理切分文档

文档 chunk 太大，会导致每次输入 token 过高；chunk 太小，又可能缺少上下文。

一般建议：

chunking:
  chunk_size: 500
  chunk_overlap: 80

对于制度文档、FAQ、产品说明，可以按标题、章节、问答对进行语义切分，而不是机械按字数切分。

2. 控制 top_k

很多系统默认 top_k=10，但实际上 3～5 个高质量片段通常已经够用。

推荐：

retrieval:
  top_k: 4
  min_score: 0.72

如果相似度低于阈值，就不要强行把结果传给模型。

3. 使用 rerank

Embedding 检索速度快，但不一定足够精准。可以先召回较多候选，再用 reranker 精排。

例如：

retrieval:
  candidate_k: 20
  rerank_top_k: 4

这会增加一点 rerank 成本，但能减少无关内容进入大模型上下文，整体可能更省钱，回答质量也更好。

4. 加入元数据过滤

如果知识库包含多个部门、产品线、地区和版本，必须加入 metadata 过滤。

例如：

filters:
  department: finance
  region: cn
  version: latest

这样可以避免模型读取错误版本或无关部门的文档。

九、缓存机制：重复问题不要重复花钱

缓存是 AI Agent 降本中非常实用但常被忽视的手段。

适合缓存的内容包括：

1. 高频 FAQ；
2. 相同或相似问题的回答；
3. RAG 检索结果；
4. 工具查询结果；
5. 文档摘要；
6. SQL 查询结果；
7. 模型中间推理结果。

缓存策略示例

cache:
  enabled: true
  semantic_cache:
    enabled: true
    similarity_threshold: 0.92
    ttl_seconds: 86400
  exact_cache:
    enabled: true
    ttl_seconds: 3600

这里包含两种缓存：

• 精确缓存：用户问题完全一致时命中；
• 语义缓存：用户问题表达不同但含义相近时命中。

例如：

“怎么申请差旅报销？”

和

“出差回来报销要怎么走流程？”

语义上非常接近，可以复用相似回答或检索结果。

不过，缓存也要注意失效机制。涉及价格、库存、政策、合同、实时数据的问题，不应长时间缓存。

十、控制工具调用：工具不是越多越好

Agent 能调用工具是一种能力，但不是每个问题都需要工具。

建议设置工具调用原则：

1. 能直接回答的，不调用工具；
2. 需要实时数据时，才调用外部接口；
3. 需要私有知识时，才调用知识库；
4. 需要计算时，才调用计算器或代码工具；
5. 工具失败时，不无限重试；
6. 工具返回内容必须压缩后再进入上下文。

例如：

tools:
  vector_search:
    enabled: true
    max_calls_per_turn: 1
    result_max_tokens: 1200

  sql_query:
    enabled: true
    max_calls_per_turn: 2
    timeout_ms: 3000

  web_search:
    enabled: false

如果企业内部知识库已经足够，就不应默认开启网页搜索。网页搜索不仅增加成本，还可能引入不可靠信息。

十一、输出长度控制：别让模型写过头

很多模型调用成本包含输出 token。若不限制输出长度，模型可能生成大量冗余内容。

可以从两个层面控制：

1. 参数控制

generation:
  max_output_tokens: 1200
  temperature: 0.3

2. Prompt 控制

回答不超过 500 字；除非用户要求详细说明，否则优先给出简明步骤。

对于客服、FAQ、企业内部助手，简洁回答通常比长篇大论更有效。

建议根据场景设置不同输出长度：

十二、失败重试治理：避免无效调用滚雪球

很多 Agent 系统为了提升稳定性，会设置自动重试。但如果缺乏限制，失败调用会造成成本放大。

例如：

• 模型超时后连续重试 3 次；
• 工具失败后 Agent 继续重新规划；
• 检索无结果时反复检索；
• 输出格式错误后多次让模型修复。

建议：

retry:
  max_retries: 1
  backoff: exponential
  retry_on:
    - timeout
    - rate_limit
  no_retry_on:
    - invalid_user_request
    - permission_denied
    - empty_retrieval_result

对于“用户权限不足”“知识库无结果”等确定性失败，不应重试。

十三、监控成本：没有监控就没有优化

降本不能只靠经验，必须有数据。

建议记录以下指标：

模型调用指标

• 每次调用输入 token；
• 每次调用输出 token；
• 每次调用模型名称；
• 每次调用耗时；
• 每次调用成本估算；
• 调用成功率；
• 重试次数。

Agent 任务指标

• 每个用户请求触发多少次模型调用；
• 每个请求调用了哪些工具；
• 工具调用耗时；
• RAG 返回文档数量；
• 缓存命中率；
• 用户满意度；
• 人工接管率。

成本分析维度

• 按用户统计；
• 按部门统计；
• 按任务类型统计；
• 按模型统计；
• 按时间统计；
• 按工具统计。

有了这些数据，就能发现真正的成本黑洞。

例如：

• 某个任务类型占用了 60% 的 token；
• 某个 Prompt 固定消耗过大；
• 某个工具经常失败导致重试；
• 某个部门大量重复询问相同问题；
• 某个模型在简单任务上被过度使用。

十四、附：AI Agent 成本优化配置文件

下面是一份可参考的 YAML 配置文件，适用于企业知识库问答、内部助手、客服 Agent 等场景。

agent:
  name: cost_optimized_enterprise_agent
  version: 1.0.0
  language: zh-CN
  default_mode: cost_saving

models:
  cheap_model:
    provider: openai_compatible
    model_name: gpt-4o-mini
    usage:
      - intent_classification
      - simple_rewrite
      - short_summary
      - faq_answer
    max_input_tokens: 8000
    max_output_tokens: 800
    temperature: 0.2

  standard_model:
    provider: openai_compatible
    model_name: gpt-4.1-mini
    usage:
      - knowledge_qa
      - normal_reasoning
      - data_explanation
    max_input_tokens: 16000
    max_output_tokens: 1200
    temperature: 0.3

  advanced_model:
    provider: openai_compatible
    model_name: gpt-4.1
    usage:
      - complex_reasoning
      - high_risk_analysis
      - multi_step_planning
    max_input_tokens: 32000
    max_output_tokens: 2000
    temperature: 0.2

router:
  enabled: true
  default_model: standard_model
  classification_model: cheap_model
  escalation:
    enabled: true
    conditions:
      - low_confidence
      - high_risk_domain
      - complex_multi_step_task
      - user_explicitly_requests_detailed_analysis

  routes:
    - name: faq
      description: 高频 FAQ、简单政策问答
      model: cheap_model
      tools:
        - vector_search
      max_tool_calls: 1
      max_output_tokens: 600

    - name: simple_text_task
      description: 摘要、改写、润色、格式转换
      model: cheap_model
      tools: []
      max_output_tokens: 800

    - name: knowledge_base_qa
      description: 企业知识库问答
      model: standard_model
      tools:
        - vector_search
      max_tool_calls: 1
      max_output_tokens: 1000

    - name: data_query
      description: 业务数据查询与解释
      model: standard_model
      tools:
        - sql_query
        - calculator
      max_tool_calls: 2
      max_output_tokens: 1200

    - name: complex_analysis
      description: 合同、风险、策略、复杂推理
      model: advanced_model
      tools:
        - vector_search
        - calculator
      max_tool_calls: 3
      max_output_tokens: 1800

prompt:
  system_prompt: |
    你是企业内部 AI 助手。请遵守以下规则：
    1. 优先基于知识库和工具结果回答；
    2. 没有依据时，明确说明“未找到可靠依据”；
    3. 不编造制度、价格、合同、数据和流程；
    4. 回答应简洁、结构化，优先使用列表；
    5. 涉及制度、流程、合同、财务数据时，必须引用来源；
    6. 如果问题超出权限或业务范围，请说明无法处理并建议联系人工。

  response_style:
    default: concise
    max_bullets: 6
    include_sources: true
    avoid_unnecessary_explanation: true

context:
  memory_strategy: hybrid
  recent_messages_limit: 6
  enable_summary_memory: true
  summary_trigger_tokens: 6000
  summary_model: cheap_model
  max_summary_tokens: 500
  long_term_memory:
    enabled: true
    store_user_preferences: true
    store_sensitive_data: false

rag:
  enabled: true
  embedding:
    provider: openai_compatible
    model_name: text-embedding-3-small
    batch_size: 64

  chunking:
    strategy: semantic
    chunk_size: 500
    chunk_overlap: 80
    split_by_heading: true

  retrieval:
    vector_store: milvus
    candidate_k: 20
    top_k: 4
    min_score: 0.72
    enable_metadata_filter: true

  rerank:
    enabled: true
    model_name: lightweight-reranker
    top_k: 4

  context_budget:
    max_retrieval_tokens: 1400
    compress_long_chunks: true
    compression_model: cheap_model
    max_compressed_tokens: 800

tools:
  vector_search:
    enabled: true
    max_calls_per_turn: 1
    timeout_ms: 2000
    result_max_tokens: 1400

  sql_query:
    enabled: true
    max_calls_per_turn: 2
    timeout_ms: 3000
    require_permission_check: true
    result_row_limit: 100

  calculator:
    enabled: true
    max_calls_per_turn: 2

  web_search:
    enabled: false
    reason: 企业内部助手默认不使用公网搜索，避免额外成本和不可靠信息。

cache:
  enabled: true

  exact_cache:
    enabled: true
    ttl_seconds: 3600

  semantic_cache:
    enabled: true
    similarity_threshold: 0.92
    ttl_seconds: 86400
    exclude_domains:
      - pricing
      - inventory
      - real_time_data
      - legal_contract

  retrieval_cache:
    enabled: true
    ttl_seconds: 43200

  tool_result_cache:
    enabled: true
    ttl_seconds: 600

generation:
  default_temperature: 0.3
  default_max_output_tokens: 1000
  stop_when_answer_complete: true
  prefer_short_answer: true

retry:
  enabled: true
  max_retries: 1
  backoff: exponential
  retry_on:
    - timeout
    - rate_limit
    - transient_network_error
  no_retry_on:
    - permission_denied
    - invalid_user_request
    - empty_retrieval_result
    - policy_violation

budget:
  enabled: true
  per_request:
    max_model_calls: 3
    max_tool_calls: 3
    max_total_input_tokens: 12000
    max_total_output_tokens: 2500

  per_user_daily:
    max_requests: 200
    max_estimated_cost_usd: 5

  alert:
    enabled: true
    notify_when_request_cost_exceeds_usd: 0.1
    notify_when_daily_cost_exceeds_usd: 100

observability:
  logging:
    enabled: true
    log_prompt_tokens: true
    log_completion_tokens: true
    log_model_name: true
    log_tool_calls: true
    log_cache_hit: true
    mask_sensitive_data: true

  metrics:
    enabled: true
    track:
      - request_count
      - model_call_count
      - input_tokens
      - output_tokens
      - estimated_cost
      - latency
      - cache_hit_rate
      - retrieval_hit_rate
      - escalation_rate
      - user_feedback_score

evaluation:
  enabled: true
  sample_rate: 0.05
  metrics:
    - answer_accuracy
    - citation_quality
    - helpfulness
    - hallucination_rate
    - cost_per_successful_request

十五、配置文件说明

上面的配置文件体现了几个核心思想。

1. 默认节省模式

default_mode: cost_saving

这表示系统默认优先考虑经济性，而不是无条件追求最强能力。

2. 分类模型使用轻量模型

classification_model: cheap_model

任务路由本身不应该太贵。用轻量模型做意图识别、任务分类，通常已经足够。

3. 高端模型只在必要时升级

escalation:
  enabled: true

只有在低置信度、高风险、复杂任务等情况下，才升级到高级模型。

4. 限制每次请求的调用次数

max_model_calls: 3
max_tool_calls: 3

这是非常重要的成本护栏。否则 Agent 可能在复杂任务中不断规划、调用、反思、重试，导致成本不可控。

5. 检索内容有 token 预算

max_retrieval_tokens: 1400

RAG 不是把所有相关文档都塞给模型，而是在预算内提供最有价值的信息。

6. 开启缓存

semantic_cache:
  enabled: true

对于高频问题，缓存可以显著降低调用量。尤其是企业内部助手，用户常问的问题高度重复，例如报销流程、请假制度、账号权限、产品资料位置等。

十六、一个推荐的低成本 Agent 调用流程

一个成本优化后的 Agent，可以采用以下流程：

用户输入
  ↓
轻量模型判断意图与难度
  ↓
检查缓存是否命中
  ↓
根据任务类型选择模型和工具
  ↓
必要时执行 RAG 或工具调用
  ↓
压缩工具结果和检索内容
  ↓
调用合适模型生成回答
  ↓
记录 token、成本、延迟和反馈
  ↓
将高频结果写入缓存

这个流程的关键是：
先判断，再调用；能缓存就缓存；能用小模型就不用大模型；能少传上下文就少传上下文。

十七、实践中的降本优先级

如果你已经有一个 Agent 系统，并且成本偏高，可以按以下顺序优化：

第一优先级：监控

先知道钱花在哪里。没有数据就无法判断哪个环节最值得优化。

第二优先级：模型分层

将简单任务迁移到轻量模型，通常能立刻看到成本下降。

第三优先级：上下文裁剪

检查每次调用是否携带了过多历史消息和工具结果。

第四优先级：RAG 优化

降低 top_k，增加 min_score，使用 rerank 和 metadata filter。

第五优先级：缓存

对 FAQ、检索结果和工具结果进行缓存。

第六优先级：限制工具调用和重试

设置 max_tool_calls、max_retries、timeout 等保护机制。

十八、总结

AI Agent 降低成本的本质，不是牺牲质量，而是减少无效消耗。

一个成熟的 Agent 系统，应该具备以下能力：

• 简单任务用便宜模型；
• 复杂任务再升级模型；
• Prompt 简洁清晰；
• 上下文按需保留；
• RAG 检索精准而克制；
• 工具调用有边界；
• 重复问题优先命中缓存；
• 输出长度可控；
• 失败重试有限制；
• 全链路成本可观测。

如果只关注模型能力，而忽视系统设计，AI Agent 很容易变成一个“昂贵但低效”的自动化系统。相反，如果在架构层面做好路由、缓存、检索、上下文和监控，即使使用同样的大模型，也能显著降低成本，并提升稳定性与用户体验。

真正高质量的 AI Agent，不只是会回答问题，更应该知道：

什么时候该思考，什么时候该检索，什么时候该调用工具，什么时候该停下来。

这正是 AI Agent 从 Demo 走向生产系统的关键。