AI Day 23: Agent系统工程化(2)：成本控制与性能优化 — 让Agent又快又省

日期：2026-04-24 阶段：第二阶段 — 工程实践 (Day 16-30) 标签：Cost Optimization Token Budget Model Routing Semantic Cache Prompt Compression Latency Parallel Tool Calls Speculative Execution Budget Guard Agent Benchmarking

---

学习路径树

AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│   ├── Day 1:  Transformer架构与LLM基础 ✅
│   ├── Day 2:  模型量化与本地部署 ✅
│   ├── Day 3:  训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│   ├── Day 4:  Prompt Engineering与上下文学习(ICL)原理 ✅
│   ├── Day 5:  RAG架构：检索增强生成全链路 ✅
│   ├── Day 6:  向量数据库与Embedding模型 ✅
│   ├── Day 7:  Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│   ├── Day 8:  推理优化：vLLM / TensorRT-LLM / SGLang ✅
│   ├── Day 9:  长上下文技术：RoPE扩展 / Ring Attention ✅
│   ├── Day 10: 多模态模型：Vision-Language架构 ✅
│   ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│   ├── Day 12: Agent框架：ReAct / Tool Use / Planning ✅
│   ├── Day 13: MCP协议与Tool生态 ✅
│   ├── Day 14: 模型评估：Benchmark / Arena / 安全评估 ✅
│   └── Day 15: 阶段复习与架构总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30)
│   ├── Day 16: LLM应用架构设计 — API Gateway/路由/缓存 ✅
│   ├── Day 17: LLM安全与Guardrails — 生产环境防护体系 ✅
│   ├── Day 18: LLM可观测性 — 日志/Tracing/指标/告警 ✅
│   ├── Day 19: 生产级RAG(1) — 文档解析与Chunking工程 ✅
│   ├── Day 20: 生产级RAG(2) — Retrieval优化与Reranking ✅
│   ├── Day 21: 生产级RAG(3) — 评估框架与持续迭代 ✅
│   ├── Day 22: Agent系统工程化(1) — 状态管理与错误恢复 ✅
│   ├── Day 23: Agent系统工程化(2) — 成本控制与性能优化 ← 你在这里
│   ├── Day 24: Agent系统工程化(3) — 多Agent协作架构
│   ├── Day 25: Agent系统工程化(4) — 测试与部署
│   └── Day 26-30: 多模型编排/部署策略/端到端项目
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│   ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│   ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│   └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
    ├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
    ├── Day 47-49: 产品/架构面试模拟
    └── Day 50: 总结与作品集

---

核心概念

一句话定义

Agent成本 = LLM调用单价 x 调用次数 x 每次Token复杂度。一个没有成本控制的Agent就像一张没有限额的信用卡——一个失控Agent一分钟能花$100。优化的核心不是"少用LLM"，而是"让每一次调用都物有所值"。

金融类比

Agent成本控制 = 银行的费用路由 + 限额管理 + 成本会计

银行费用路由:                              Agent模型路由:
├── 大额汇款走SWIFT($30/笔)               ├── 复杂推理走Opus($15/1M tokens)
├── 小额转账走ACH($0.10/笔)               ├── 简单分类走Haiku($0.25/1M tokens)
└── 内部转账走核心系统($0)                 └── 缓存命中走本地($0)

银行限额管理:                              Agent预算管理:
├── 单笔限额: 最大$50,000                  ├── 单任务: 最大$2.00
├── 日累计: 最大$100,000                   ├── 每用户/日: 最大$10.00
└── 异常检测: 超出模式自动拦截              └── 失控检测: 循环超N步自动终止

为什么Agent成本比普通LLM调用严重100倍

普通LLM调用: 1次调用 → 成本$0.01-$0.05
Agent多步执行: N次调用，每次累积历史 → 成本$0.10-$5.00(正常) / $10-$100+(失控！)

关键放大因素:
  1. 每步重复发送System Prompt+工具描述 → Token浪费
  2. 对话历史累积，越到后面越长 → 成本递增
  3. 可能陷入循环不断重试 → 成本爆炸
  4. 使用复杂推理模型(o3/Opus)→ 乘数效应

真实案例: 同一个金融分析任务
  正常执行: 8步, $1.20 │ 工具重试: 15步, $3.50 │ 陷入循环: 50步, $47.00
  → 成本差异40倍！

---

Token成本分析：钱花在哪了

每步Token消耗Breakdown

一个典型Agent调用的Input构成:
┌──────────────────────────────────────────────────┐
│ System Prompt          ~500 tokens   (每步重复)   │
│ Tool Descriptions      ~2,000 tokens (每步重复!)  │
│ 对话历史(前N轮)        ~1,000-10,000 (线性增长)   │
│ 当前输入/工具结果       ~200-2,000   (每步不同)   │
├──────────────────────────────────────────────────┤
│ 总Input/步             ~3,700-14,500              │
└──────────────────────────────────────────────────┘

8步Agent任务估算(GPT-4o):
  Input随步数增长: 3,700→4,700→...→10,700 tokens
  总计: ~62,600 tokens → 成本~$0.19

  同样任务换Claude Opus: → 成本~$1.24 → 差6.5倍！

隐藏杀手：工具描述膨胀

20个工具 x 100 tokens/工具 = 2,000 tokens/步
8步 = 16,000 tokens → 占总Input的28%！大部分工具可能根本没用到

"万能Agent"50个工具: 7,500 tokens/步 → 光工具描述就花$0.90(Opus)
而且工具太多还会让Agent选错工具 → 导致更多步骤 → 更多成本

优化: 动态工具加载(只给相关5-8个) / 描述压缩 / 两阶段路由

---

成本优化策略

策略一：模型降级路由(Model Routing)

不是所有步骤都需要最贵的模型:

┌─────────────────┬──────────────┬────────┐
│ 步骤类型        │ 推荐模型     │ 成本   │
├─────────────────┼──────────────┼────────┤
│ 意图分类/路由   │ Haiku/Mini   │ $      │
│ 工具参数提取    │ Haiku/Mini   │ $      │
│ 工具结果摘要    │ Sonnet/4o    │ $$     │
│ 复杂推理/决策   │ Opus/o3      │ $$$$   │
│ 最终回答生成    │ Sonnet/4o    │ $$     │
└─────────────────┴──────────────┴────────┘

成本节省: 全部Opus $1.24 → 智能路由 $0.26 → 节省79%！

策略二：Prompt压缩(Prompt Compression)

问题: 对话历史随步数线性增长

方案1: 滑动窗口 — 只保留最近K轮，丢弃更早的
方案2: 摘要压缩 — 每N步用小模型压缩历史为200 token摘要
方案3: LLMLingua — 算法自动删低信息量Token，压缩2-5x，质量损失<5%
方案4: 工具结果裁剪 — API返回2000 tokens → 提取关键字段200 tokens

推荐组合:
  步骤1-5:   完整历史 + 工具结果裁剪
  步骤6-10:  步骤1-5摘要 + 后续完整 + 裁剪
  → Token增长从O(N)降到O(K + 固定摘要长度)

策略三：语义缓存(Semantic Cache)

传统缓存: 完全相同输入 → 返回缓存
语义缓存: 语义相似输入 → 返回缓存(Embedding余弦相似度>阈值)

三层缓存:
  Layer 1 任务级: "ETH价格"≈"以太坊现价" → 命中(TTL: 30s)
  Layer 2 工具结果: 同API同参数 → 命中(TTL: 30s-24h)
  Layer 3 推理结果: "分析AAVE风险" → 命中(TTL: 1h)

命中率30% → 节省~28%成本 / 高频客服Agent可达40-60%

注意: 阈值太低→误命中(错答案) / 底层数据变了要失效 / 错误答案要过滤

策略四：Early Stop与预算上限(Budget Guard)

三层预算控制:

Layer 1: 步数上限
  简单任务5步 / 中等10步 / 复杂20步 / 绝对上限30步

Layer 2: Token预算
  每任务累计跟踪: max_cost_usd = $2.00
  每步执行前预估，超限则拒绝执行

Layer 3: 循环检测
  ├── 连续相同Action+参数 → 明显循环
  ├── LLM输出余弦相似度>0.95 → 思维循环
  └── 连续3步无进展 → 卡住了
  → 先尝试换策略，仍循环则强制终止

策略五：自适应复杂度(Adaptive Complexity)

先简单试，不行再升级:

Phase 1: Haiku直接回答(不走Agent)  → $0.005
Phase 2: Agent + Sonnet + 有限工具  → $0.10
Phase 3: Agent + Opus + 全工具 + CoT → $1.00
Phase 4: 转人工

80%任务在Phase 1-2解决 → 平均成本大幅下降
类比银行: 小额贷款自动审批($0.5) / 大额才上信审委员会($50)

---

延迟优化：让Agent更快

延迟在哪里

单步延迟: LLM推理500-3000ms + 网络50-200ms + 工具100-5000ms
8步总延迟: 最好5s / 平均20s / 最差66s
→ 用户等1分钟在金融场景不可接受

优化一：并行工具调用(Parallel Tool Calls)

串行: LLM→工具A→LLM→工具B = T_A + T_LLM + T_B + T_LLM
并行: LLM一次决定调A和B → 同时执行 = max(T_A,T_B) + T_LLM

示例"对比AAVE和Compound利率+TVL":
  串行8步13s → 并行3步5s → 节省62%！

优化二：流式输出(Streaming)

Level 1: 最终回答流式输出(用户看到逐字出现)
Level 2: 步骤状态推送("正在查询AAVE利率...")
Level 3: 思考过程流式(Extended Thinking，调试用)
→ 实际延迟不变，但感知延迟大幅降低

优化三：预计算与Prompt Caching

1. 常用数据预取: 用户持仓/余额启动时加载
2. 工具结果定时刷新: Top 50 Token价格每30s更新到缓存
3. Prompt Caching(最划算的优化！):
   Anthropic: 缓存读取只要0.1x价格
   3000 tokens System Prompt, 10次调用:
   无缓存: 30,000 tokens全价
   有缓存: 6,450等效tokens → 节省78%

优化四：推测执行(Speculative Execution)

在LLM推理的同时，猜测性执行最可能的工具调用

传统: LLM推理(1s) → 决定查A → 执行查A(2s) = 3s
推测: LLM推理(1s) + 同时猜测性执行查A(2s) → LLM确认 → 结果已有 = 1s
  猜对 → 工具调用时间完全隐藏
  猜错 → 丢弃预取结果，正常执行(无损)

适用: 只读工具(查询价格/余额/数据) + 高概率可预测
不适用: 有副作用(转账/发邮件) + 工具调用昂贵 + 完全不可预测

---

Agent性能基准：如何量化"好不好"

四维指标体系:

┌──────────┬──────────────────┬──────────┬──────────┐
│ 维度     │ 指标             │ 基准值   │ 优秀值   │
├──────────┼──────────────────┼──────────┼──────────┤
│ 质量     │ 任务完成率       │ >85%     │ >95%     │
│          │ 答案正确率       │ >80%     │ >90%     │
├──────────┼──────────────────┼──────────┼──────────┤
│ 效率     │ 平均步数/任务    │ <10步    │ <6步     │
│          │ 冗余步骤率       │ <20%     │ <10%     │
├──────────┼──────────────────┼──────────┼──────────┤
│ 成本     │ 平均成本/任务    │ <$0.50   │ <$0.10   │
│          │ 失控率(超预算)   │ <5%      │ <1%      │
├──────────┼──────────────────┼──────────┼──────────┤
│ 速度     │ 平均延迟/任务    │ <30s     │ <10s     │
│          │ P95延迟          │ <60s     │ <20s     │
└──────────┴──────────────────┴──────────┴──────────┘

成本效率比(CER) = 完成率 / 平均成本
  如: 90% / $0.20 = 4.5 完成/美元 → 越高越好

Baseline建立流程:
  Step 1: 收集50-100个代表性任务(简单30%/中等50%/困难20%)
  Step 2: 跑基准测试，每任务记录: steps/tokens/cost/latency/success/quality
  Step 3: 计算四维汇总指标 = "v1.0 Baseline"
  Step 4: 每次优化后重跑 → 对比变化 → 确认质量未回退
  Step 5: 每周/每次部署后跑一次 → 持续跟踪趋势

优化对比示例:
  任务完成率: 88% → 92% (+4%)  ✅
  平均成本:   $0.25 → $0.12 (-52%) ✅
  平均延迟:   18s → 22s (+22%) ⚠️ (变慢了，需权衡)
  → 多维指标间存在Trade-off，不能只看单一维度

---

监控与告警：实时成本仪表盘

综合成本优化架构

生产级Agent的完整成本控制链路:

用户请求
  → [语义缓存] 命中→直接返回($0) / 未命中↓
  → [复杂度评估(Haiku)] 简单→小模型直接答($0.005) / 中等↓ / 复杂↓
  → [Agent执行层]
      ├── Prompt Caching(System Prompt走缓存)
      ├── 模型路由(每步动态选最优模型)
      ├── 工具结果缓存+裁剪
      ├── 并行工具调用
      ├── 历史压缩(超N步后)
      └── 预算守卫(每步检查)
  → [结果写入缓存] → [成本记录(按用户/任务/模型归因)]

预期效果:
  平均成本: $0.80 → $0.12 (-85%)
  平均延迟: 25s → 8s (-68%)
  失控率:   8% → 0.5% (-94%)

Dashboard核心指标

┌─────────────────────────────────────────────────────┐
│ 今日累计: $124/$500 (24.9%) 🟢                       │
│ 本小时:   $8.2/$50  (16.4%) 🟢                       │
│ 活跃Agent: 23                                        │
├─────────────────────────────────────────────────────┤
│ 模型使用分布:                                        │
│   Haiku:  45%调用 / 5%成本                           │
│   Sonnet: 40%调用 / 35%成本                          │
│   Opus:   15%调用 / 60%成本  ← 优化机会!             │
├─────────────────────────────────────────────────────┤
│ 缓存命中率: 34% │ 平均步数: 6.2 │ 失控率: 1.8%      │
└─────────────────────────────────────────────────────┘

告警规则

P0(立即响应):
  单任务>$10 → 终止+通知 │ 小时成本>日预算20% → 限流
  Agent循环>20步 → 终止  │ LLM API持续错误 → 切Provider

P1(1小时内):
  缓存命中率<10% → 检查缓存服务 │ 平均步数比Baseline高50% → 检查变更
  单用户日成本>$20 → 检查滥用   │ 完成率<80% → 检查模型/工具

P2(日报告):
  日成本超预算80% │ Opus使用>30% │ 成本环比增长>20%

失控检测

三种失控模式:

无限循环: 连续相同Action → 强制终止
发散探索: 步数增加但离目标越远(每步评估进展分) → Early Stop
错误雪崩: 错误率>50%持续>5步 → 降级或转人工

统一框架: 每步后检查→步数超限?→成本超限?→循环?→发散?→错误率高?
  任一触发 → 对应处理; 全部正常 → 继续

---

今日思考

思考一：成本优化是否有"质量下限"

很多优化不降质量反而提升: 缓存返回验证过的好答案更稳定/循环检测防无效重复/
工具结果裁剪去噪后LLM推理更准。但模型降级/历史截断/Early Stop确实可能降质。
关键原则: "先设质量下限(完成率>X%/正确率>Y%)，在约束内最大化成本节省"
→ 类比银行: 不能为省成本放松风控

思考二：金融场景的特殊成本考量

1. 正确性成本>调用成本: 一次错误金融建议的损失>>Agent运行成本
   → 金额>$10K的决策永远用最好的模型
2. 合规审计成本: 每步审计日志不可省(但可复用做成本归因)
3. 实时性代价: 交易场景需"用钱买速度"(预留算力/更快API)
4. 长尾风险: 1%失控任务消耗30%预算 → 熔断必须极严格

思考三：Agent成本优化的未来趋势

1. 模型价格年降50-70% → 但需求增长更快，优化仍需
2. Prompt Caching成标配 → 优化重心转向历史管理和工具结果
3. 本地SLM做路由预处理 → API调用次数和延迟同降
4. Agent-Native定价 → 从按Token计费到按任务完成计费
5. 专用AI芯片(Groq/Cerebras)→ 延迟被硬件解决，架构思想仍有价值

---

面试题

Q: 如何设计Agent系统的成本控制方案？

1. 成本建模: 分析每步Token消耗(System Prompt/工具描述/历史/推理)
2. 多层优化: Prompt Caching + 模型路由 + 语义缓存 + 历史压缩 + 工具裁剪
3. 预算控制: 步数上限 + Token预算 + 循环检测 + 用户限额
4. 监控迭代: 实时仪表盘 + 成本归因 + 定期评测防质量回退
金融补充: 正确性优先(高风险不降级) / 审计合规 / 熔断机制

Q: Agent延迟瓶颈在哪？如何优化？

瓶颈: 80%来自LLM推理(每次500ms-3s x N次) + 外部API(100ms-5s)
四板斧:
  1. 减调用次数: 并行工具调用/语义缓存/简单问题不走Agent
  2. 加速每次调用: 小模型做推理步/Prompt Caching/低延迟Region
  3. 隐藏延迟: 流式输出/推测执行/步骤进度展示
  4. 减工具延迟: 结果缓存/数据预取/批量API
目标: 简单<3s / 中等<10s / 复杂<30s / 超60s转异步

---

资源推荐

---

明日预告

Day 24: Agent系统工程化(3) — 多Agent协作架构

预习问题:
1. 什么场景需要多Agent协作？单Agent无法解决的问题有哪些？
2. 多Agent之间如何通信和协调？有哪些模式(串行/并行/分层/辩论)？
3. 多Agent系统的成本和复杂度如何控制？

连接点:
  Day 22: Agent的"可靠性" — 状态管理/错误恢复
  Day 23: Agent的"经济性" — 成本分析/优化/性能
  Day 24: Agent的"扩展性" — 多Agent协作/编排
  → 单Agent做到可靠+经济之后，如何组建高效团队

---