成本延迟与缓存优化
智能体一个任务往往要多次调用模型，还要跑一堆工具，token 账单与响应时间都随调用次数线性放大。想把原型变成能长期跑的服务，成本与延迟优化是绕不开的一课。
成本从哪里来
| 构成 | 说明 |
|---|---|
| 输入 token | 系统提示、历史对话、检索内容、工具定义，通常占大头 |
| 输出 token | 模型回复，单价通常高于输入 |
| 推理模型溢价 | 带推理（reasoning）的模型"想得多"也"花得多"，按 token 计费更贵 |
| 工具外部成本 | 调 API、查数据库、跑函数的真实开销，容易漏算 |
成本大体可用公式估算：单轮 token × 轮数。上下文越臃肿、任务拆得越碎，账单涨得越快。
降低成本的四个方向
- 精简上下文：系统提示去冗余，历史只保留最近几轮或用摘要代替，检索只取 Top-K，工具描述写短写准——输入 token 直接减少。
- prompt caching（提示缓存）：同一段稳定前缀（系统提示+工具定义）在多次调用间可被缓存，命中部分按更低价格计费。是否自动生效、有效期多长，各厂商实现不同，以官方文档为准。
- 模型路由：简单任务先用便宜的小模型，难题才升级到大模型，"杀鸡不用牛刀"。
def pick_model(difficulty: str) -> str:
if difficulty == "easy":
return "cheap-small-model" # 小模型先试，成本低延迟小
return "strong-big-model" # 难题再上大模型
- 批处理：不着急出结果的批量任务（如整库打标签）走异步批处理，通常单价更低、吞吐更高。
延迟优化
| 手段 | 作用 |
|---|---|
| 流式输出（stream） | 首字更快到达，体感"边想边答" |
| 并行工具调用 | 多个独立工具同时发请求，减少串行等待 |
| 减少轮次 | 一次能完成的动作不拆成三问三答 |
| 控制上下文 | 输入越长首 token 越慢，及时裁剪历史 |
# 伪代码：多个独立工具并行调用，别等完一个再发下一个
results = await asyncio.gather(
query_weather(city), # 互相独立，可并行
query_flight(city),
query_hotel(city),
)
用观测数据说话
把每次调用的 token 用量与 cost 字段落库，按任务聚合，才能知道钱花在哪一步：
{
"task_id": "t-1042",
"model": "deepseek-chat",
"prompt_tokens": 3600,
"completion_tokens": 640,
"cache_read_tokens": 2400,
"total_steps": 4
}
成本字段的具体含义与是否区分缓存命中，不同平台不同，落地时以所用平台文档为准。
小结
成本来自输入输出 token、推理模型溢价与工具外部调用，延迟来自串行与等待。对策是精简上下文、善用 prompt caching、小模型先行的模型路由、批处理与并行流式，并用 cost/token 观测数据持续复盘。