为什么代理型人工智能的成本会飙升：一种以架构为核心的成本模型

当人们谈论控制大型语言模型的使用成本时，讨论通常都围绕令牌价格展开。

“这个模型的每百万个令牌费用是多少？”

这是个合理的问题，但对于生产级智能代理系统而言，它忽略了真正的挑战。

用户的单个请求并不会对应一次语言模型的调用。

智能代理的处理流程通常如下：

User Request
     ↓
Router
     ↓
Planner
     ↓
Retrieval
     ↓
Tool Call
     ↓
Tool Result Interpretation
     ↓
Validator
     ↓
Final Response

一个进入的请求在得到处理之前，可能会触发五次、六次、十次甚至更多次对模型和工具的调用。

正因如此，需要追踪的成本并非仅仅是：

每次模型调用的成本

而是：

每完成一项任务的成本。

究竟是什么决定了智能代理的成本

运行智能代理工作流的总成本远不止原始令牌消耗那么简单：

Agent Cost
=
LLM inference
+ Embeddings
+ Reranking
+ Vector/Search infrastructure
+ Tool/API calls
+ Compute
+ Storage
+ Observability
+ Evaluations

即便在“LLM推理”模块中，也需要处理输入令牌、输出令牌、缓存令牌，还可能有在流程不同阶段运行的多种不同模型。

这一现实状况要求我们以不同的方式来做出架构决策。

1. 将每个请求发送到合适规模的模型

并非所有任务都值得使用最强大的模型来处理。

Request
   ↓
Router
   ├── Simple extraction → Small model
   ├── Moderate reasoning → Mid-tier model
   └── Complex reasoning → Strong model

另一种实用的策略是分级处理。

先使用轻量级、成本较低的模型，只有当置信度较低、验证失败或任务复杂度超出预期时，才转而使用更强大的模型。

目标并非始终选择最便宜的方案，

而是找到在保证所需质量与可靠性的前提下成本最低的架构。

2. 停止在确定性逻辑上消耗模型调用资源

这一点看似显而易见，但一旦在大规模环境中运行时就显得极为重要。

只要普通代码能够可靠地回答某个问题，就让普通代码来处理。

诸如权限检查、算术运算、模式验证、过滤、确定性路由决策以及大多数业务规则通常都不需要通过大语言模型来处理。

一个实用的准则：

永远不要将那些确定性软件已经能更好处理的任务交给大语言模型。

把概率推理留给工作流中真正需要其价值的环节。

3. 将上下文视为支出预算

长期运行的智能体在运行过程中会不断积累上下文信息。

如果不加以控制，每多一步操作都可能将完整的对话历史、之前的工具输出、获取的文档以及早期的推理轨迹重新传回模型中。

与其让上下文无限制地扩大，不如保持在一个较为合理的范围：

Recent Context
      +
Compact Summary
      +
Relevant Memory
      +
Task-Specific Retrieved Context

诸如摘要生成、生存时间限制、滑动上下文窗口以及基于相关性的内存检索等做法，不仅用于控制上下文大小。

它们还起到成本控制的作用。

4. 你的RAG Top-K设置是控制成本的关键

假设你检索了20个片段，每个片段约700个标记。

这样总计就有大约14,000个标记的检索内容。

但实际上可能只有其中的四个片段对生成答案真正重要。

设计更合理的检索流程应如下所示：

Query
  ↓
Retrieve broader candidate set
  ↓
Rerank
  ↓
Select best 4–6 chunks
  ↓
LLM

虽然可以引入大量的候选者，但并不意味着所有候选者都必须被纳入模型的上下文窗口中。

因此，检索质量与推理效率是相互关联的架构设计要素，而非独立的议题。

5. 在多层实现缓存

缓存并非单一技术——有多种不同的缓存方式可以组合使用。

例如：

Exact Cache
Semantic Cache
Prompt/Context Cache
Tool Result Cache
Retrieval Cache

如果大量用户提出语义上完全相同的查询，每次都从头开始重新运行整个智能体处理流程往往会造成资源浪费。

同样，庞大的静态系统提示语、工具定义以及规则文本也无需在每次调用时都重新处理，只要您的平台或模型提供商支持相应的缓存机制即可。

6. 为自主智能体设定严格限制

代理程序自身也存在风险：失控的循环。

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
...

一个编排错误就可能同时导致可靠性问题与成本激增。

正因如此，生产环境中的代理程序需要明确的约束机制来应对以下问题：

Maximum agent steps
Maximum tool calls
Maximum tokens
Maximum wall-clock time
Maximum cost per run

一旦这些预算中的某一项被用尽，工作流应根据实际情况选择停止运行、切换到备用路径、平滑降级其功能或交由人工处理。

7. 将成本纳入可观测性体系

生产环境中生成的每条追踪数据都应能够帮助回答如下问题：

Which application?
Which workflow?
Which agent?
Which model/provider?
How many input tokens?
How many output tokens?
How many tool calls?
How long did it take?
How much did it cost?
Did the task actually succeed?

通过这些数据，仪表板可以展示诸如以下的指标：

Cost / request
Cost / successful task
Cost / workflow
Cost / model
Cost / application
Cost / team
Cost / customer

此时，优化人工智能相关支出更类似于平台工程与FinOps，而非仅仅调整提示词。

成本与质量必须协同优化

价格最低的工作流程并不一定就是最好的。

如果一个低成本的模型频繁出错，需要反复尝试、启用备用方案或人工干预，其实际成本最终可能会超过那些能一次就完成任务的更优质模型。

因此，值得优化的指标应更接近于：

Successful Tasks
Value = --------------------
        Cost + Latency + Risk

这并非一个绝对通用的公式——而是一种工程思维方式。

对于生产环境中的智能代理系统，需要转变的思路是：

停止单独优化token数量，转而优化成功完成任务的经济性。

因为一旦智能代理具备推理、获取信息、调用工具、重新尝试、验证以及循环执行的能力：

1个用户请求不再等同于1次模型调用。

正是在这里，成本不再仅仅是定价细节，而变成了一个系统设计挑战。