跳到主要内容

AI Agent 的延迟、成本与稳定性优化

做 Agent 原型时，最先看到的通常是“效果能不能跑通”。

一旦进入真实使用，另外三个问题很快就会浮出来：

  • 延迟是不是太长
  • 成本是不是太高
  • 稳定性是不是不够

这三件事往往是绑在一起的。

这篇文档主要回答 5 件事：

  • Agent 的延迟主要来自哪里
  • 成本通常是怎样堆起来的
  • 稳定性问题最常见在哪里
  • 优化时应该优先看哪些指标
  • 第一轮优先落地的优化策略是什么

1. 延迟、成本、稳定性为什么要放在一起看​

因为它们经常相互拉扯。

例如：

  • 多查几轮工具，效果可能更稳，但延迟会上升，成本也会上升
  • 强行压低步数，延迟会下降，但成功率可能也会下降
  • 把所有请求都打到最强模型上，效果可能稳定，但成本会明显变高

所以这里更适合的不是“单指标优化”，而是：

在效果前提下，找到可接受的延迟、成本和稳定性平衡。

2. Agent 的延迟通常来自哪里​

2.1 模型推理时间​

这是最直接的一层。

影响因素包括：

  • 模型大小
  • 输出长度
  • 推理复杂度
  • 是否多轮循环

2.2 工具调用时间​

很多系统真正慢的地方，不在模型，而在：

  • 搜索
  • 数据库
  • 外部 API
  • 网页加载
  • 文件读写

2.3 编排层开销​

例如：

  • 多步 graph
  • agent handoff
  • 状态序列化
  • tracing
  • 审批等待

2.4 上下文膨胀​

上下文一旦过长，会同时带来：

  • token 增多
  • 推理变慢
  • 成本上升
  • 出错概率增加

3. 成本主要由什么构成​

3.1 模型 token 成本​

最常见，也最容易被忽略。

尤其是这些情况会把成本拉高：

  • 长上下文
  • 多轮循环
  • 每轮都带大量历史
  • 工具结果原样塞回上下文

3.2 工具与外部服务成本​

例如：

  • 搜索接口
  • 数据库查询
  • 浏览器运行环境
  • 代码执行环境
  • OCR / embedding / rerank 服务

3.3 失败重试成本​

如果系统稳定性不足，重复重试本身就会放大成本。

3.4 观测与存储成本​

例如：

  • 全量 trace
  • 会话存档
  • artifact 存储
  • 评估任务批量跑分

4. 稳定性通常在哪些地方出问题​

4.1 模型决策不稳定​

表现包括：

  • 同样问题选不同工具
  • 参数偶发漂移
  • 停止条件不一致

4.2 工具层失败​

表现包括：

  • 超时
  • 429 / 5xx
  • 参数格式错误
  • 依赖服务不可用

4.3 上下文污染​

表现包括：

  • 历史内容过多
  • 错误工具结果残留
  • 检索资料和当前目标不匹配

4.4 编排层边界不清​

表现包括：

  • 该停止时不停
  • 该人工确认时自动继续
  • 错误分支没有回退

5. 第一批优先观测的指标​

如果系统还在第一轮工程化，先把这些指标看起来最有价值：

5.1 延迟指标​

  • 总响应时间
  • 模型耗时
  • 工具耗时
  • 每步平均耗时
  • P50 / P95 / P99

5.2 成本指标​

  • 单任务 token 消耗
  • 单任务平均模型成本
  • 单工具调用成本
  • 失败重试额外成本

5.3 稳定性指标​

  • 任务成功率
  • 工具成功率
  • 超时率
  • 回退率
  • 人工接管率

6. 最先该做的延迟优化​

6.1 限制无意义循环​

例如：

  • 设置最大步数
  • 对重复工具调用做短路
  • 对相同查询做去重

6.2 缩小上下文​

例如：

  • 历史摘要替代原始历史
  • 工具结果只保留关键字段
  • 检索结果做裁剪与重排

6.3 分层模型​

不是所有步骤都需要同一个模型。

例如：

  • 路由与分类用轻模型
  • 最终综合输出用强模型
  • 工具参数抽取用结构化能力强的模型

6.4 并行化独立步骤​

如果多个查询互不依赖，优先并行而不是串行。

7. 最先该做的成本优化​

7.1 避免把所有内容都喂回模型​

很多系统的成本问题，本质上不是模型太贵，而是输入太浪费。

7.2 给工具调用加缓存​

例如：

  • 搜索结果缓存
  • 静态文档缓存
  • 用户画像缓存

7.3 区分探索阶段和生产阶段​

探索阶段可以保留更多 trace 与 verbose 输出。

生产阶段则更适合按需采样，而不是全量保留。

7.4 把失败控制在更早层​

如果能在：

  • 参数校验
  • 权限判断
  • 输入分类

这些更便宜的环节拦住问题，就不要等到强模型推理后再失败。

8. 最先该做的稳定性优化​

8.1 明确停止条件​

每类 Agent 都应该写清：

  • 什么时候继续
  • 什么时候停止
  • 什么时候转人工

8.2 给工具错误分级​

并不是所有错误都要同样处理。

例如：

  • 临时网络错误可以重试
  • 参数校验错误应立刻停止
  • 权限错误应转人工或拒绝

8.3 做好 fallback​

例如：

  • 搜索失败时切到备用源
  • 强模型失败时降级到保守回答
  • 浏览器失败时回退到 API 工具

8.4 建立最小回归集​

每次改动后，至少用一组固定任务回跑：

  • 成功样例
  • 失败样例
  • 边界样例
  • 高成本样例

9. 一个很实用的优化顺序​

如果系统目前已经能跑，但不够稳，推荐按这个顺序优化：

  1. 先看总成功率和失败类型
  2. 再看最长耗时都卡在哪里
  3. 再看 token 和工具成本最高的任务
  4. 最后才做复杂模型路由或高级调度

原因很简单：

  • 先修明显失败
  • 再修明显慢点
  • 再修明显贵点

这通常比一上来就追求复杂优化更有效。

10. 和这个专题里的哪些内容最该一起看​

最适合一起看的有：

11. 小结​

对 Agent 系统来说，延迟、成本和稳定性不是收尾问题，而是设计问题。

更稳的做法通常不是：

  • 先把系统做得极复杂
  • 再想办法整体压缩

而是从一开始就把这些问题拆开看清楚：

  • 哪些步其实不需要强模型
  • 哪些上下文其实没必要带
  • 哪些工具结果应该裁剪
  • 哪些失败应该更早拦截