专题 06 成本、延迟与稳定性优化

本专题解决的是 AI Agent 项目进入真实使用阶段后最容易暴露的一类问题：为什么 Demo 看起来一切正常，但一旦请求量上来、链路变长、用户变多，系统就开始变贵、变慢、变不稳定。

对前端工程师来说，这一层其实并不陌生。过去你可能做过首屏优化、接口并发控制、缓存策略、降级方案和线上异常治理；在 Agent 系统里，这些问题仍然存在，只是优化对象从“页面渲染链路”扩展到了“模型调用 + 检索 + 工具执行 + 工作流状态”的全链路。

1. 为什么这三个问题要放在一起看

很多团队会把成本、延迟和稳定性拆开处理，但在 Agent 系统里它们高度耦合：

• 为了提升质量，你可能增加检索证据、增加工具调用或切换更大模型，结果成本上升、延迟变长。
• 为了降低延迟，你可能减少上下文或减少步骤，结果质量下滑、回退增多，反而影响稳定性。
• 为了追求稳定，你可能加大量重试和兜底逻辑，结果成本和总耗时都被拉高。

所以这三个指标不能单独优化，而要作为一个平衡问题来设计。

2. 先拆清楚成本从哪里来

Agent 系统的成本通常不是只有“模型 token 费”，而是由多部分叠加：

• 模型调用成本：输入 token、输出 token、重试次数、模型档位。
• 检索成本：向量检索、重排、索引更新、存储。
• 工具成本：浏览器操作、第三方 API、数据库查询、文件处理。
• 工作流成本：多节点重复调用、失败重试、人工审核等待。
• 运维成本：日志、追踪、监控、缓存、队列和服务资源。

如果只盯住 token 单价，往往会忽略真正的成本大头。

3. 延迟要拆成链路预算

很多团队说“系统很慢”，但不清楚到底慢在什么地方。 建议把总耗时拆成几个部分：

• 用户请求进入前端到服务层的网络耗时。
• 检索召回与重排耗时。
• 模型首次响应时间。
• 工具调用耗时。
• 工作流节点切换耗时。
• 前端流式渲染与状态更新耗时。

一旦拆成预算，你就能回答：

• 第一屏反馈需要在多少秒内出现。
• 总体任务完成时间的上限是多少。
• 哪一层才是当前瓶颈。

4. 稳定性不是“别报错”，而是“出问题也能控”

稳定性至少包含四层含义：

• 正常情况下能稳定成功。
• 边界场景下不会明显漂移。
• 依赖异常时能优雅降级。
• 出问题后能快速恢复并解释。

很多 AI Agent 系统不稳定，不是因为每次都报错，而是因为：

• 有时调用大模型，有时走了错误回退。
• 有时格式正确，有时输出漂移。
• 有时工具超时后没有降级。
• 有时用户看到的状态和系统内部状态不一致。

5. 一套推荐的优化顺序

第一步：先测基线，不要先拍脑袋优化

先记录：

• 单次请求平均成本。
• P50 / P95 延迟。
• 关键链路成功率。
• 重试率。
• 回退触发率。
• 用户取消率。

没有基线，优化容易变成“感觉快了一点”或“感觉好像省钱了”。

第二步：找最大瓶颈，而不是平均优化

例如：

• 如果 70% 的时间花在工具调用上，就不要先盯 Prompt 微调。
• 如果大头成本来自重排和大模型双重调用，就要先看路由策略。
• 如果大部分失败来自外部依赖超时，就要先做熔断和降级。

第三步：优先优化高频路径

不是所有路径都值得同等投入。 先找到：

• 最高频场景。
• 最高价值用户路径。
• 最容易形成成本黑洞的流程。

优化这些路径，收益会更直接。

6. 成本优化的常见方法

6.1 模型分层与路由

并不是每个请求都必须上最贵的模型。 可以按场景设计路由：

• 简单分类、意图识别、格式修复用轻量模型。
• 复杂推理、长文本综合、关键决策用更强模型。
• 先用轻量模型筛，再决定是否升级到更大模型。

6.2 控制上下文长度

上下文长度是成本和延迟的大头之一。 建议控制：

• 历史消息不要全量透传。
• 检索证据先重排再注入。
• 用摘要代替重复上下文。
• 结构化状态不要反复转成自然语言长文本。

6.3 缓存高重复结果

适合缓存的内容包括：

• 高频制度问答结果。
• 固定文档的检索摘要。
• 低变化率的工具结果。
• 某些中间节点输出。

但要注意缓存命中条件和失效策略，尤其是文档更新和权限变化场景。

6.4 减少无效重试

有些重试能提高成功率，有些重试只是浪费钱。 建议区分：

• 临时性超时，可重试。
• 参数错误、权限错误、格式错误，重试意义不大。
• 模型理解偏差，应优先修上下文而不是盲目重试。

7. 延迟优化的常见方法

7.1 让用户尽早看到反馈

从体验角度看，“第一段可见反馈时间”通常比“总完成时间”更关键。 前端可以先展示：

• 正在检索。
• 正在读取资料。
• 正在生成计划。
• 正在等待确认。

这会显著降低用户对“卡住”的感知。

7.2 并行化可并行的步骤

如果多个工具调用互不依赖，可以考虑并行执行。 例如：

• 同时拉多个数据源。
• 同时做检索与某些预处理。

但前提是你能控制并发上限，并处理部分失败。

7.3 把高耗时步骤后移

有些步骤不是每次都需要立即执行。 例如：

• 先给出初步结果，再补充详细分析。
• 先展示计划，再在确认后执行写入类操作。
• 先做粗召回，再决定是否触发重排。

7.4 避免前端二次等待

后端明明已经返回阶段性结果，但前端如果仍等全部结束才展示，用户仍会觉得慢。 因此要把服务端阶段状态和前端展示状态严格对齐。

8. 稳定性优化的常见方法

8.1 设计降级路径

当大模型不可用、工具超时或检索异常时，系统至少要知道如何降级：

• 换到更轻量或备用模型。
• 跳过非关键工具。
• 返回保底结果或解释性提示。
• 转人工处理。

8.2 明确熔断与超时规则

不是每个请求都值得无限等下去。 建议对模型调用、工具调用、工作流节点分别设置：

• 超时阈值。
• 最大重试次数。
• 熔断条件。
• 回退策略。

8.3 控制工作流扩张

很多系统变慢、变贵、变不稳，根因是工作流步骤越堆越多。 新增一个节点前，先问三个问题：

• 它是否真正提升成功率。
• 它是否引入新的失败点。
• 它是否值得这部分成本和耗时。

8.4 做幂等和恢复设计

对执行型 Agent 尤其重要。 否则一旦超时或前后端状态错位，就可能导致重复执行、重复写入或重复通知。

9. 前端工程师最有价值的切入点

9.1 体验上的“快”和系统上的“快”要一起设计

前端可以通过：

• 流式输出。
• 分阶段反馈。
• 可取消操作。
• 延迟感知提示。 帮助用户感受到系统“没有失控”。

9.2 把性能问题可视化

前端不只是消费结果，也可以帮助暴露问题：

• 展示当前阶段。
• 标明是否在等待外部工具。
• 对长时间步骤给出提示。
• 对回退或降级做可理解说明。

9.3 识别“技术成功但体验失败”的情况

例如系统 20 秒后成功返回，但用户在第 6 秒就取消了。 从技术指标看这是成功，从体验角度看却是失败。 这类问题需要前端埋点和行为分析来发现。

10. 一组推荐指标

建议至少追踪以下指标：

• 单次请求平均成本。
• P50 / P95 总延迟。
• 第一段可见反馈时间。
• 关键路径成功率。
• 重试率。
• 回退触发率。
• 用户取消率。
• 高风险节点确认通过率。

如果是 RAG 场景，还可以补：

• 每条回答平均证据条数。
• 检索命中率。
• 重排触发率。

11. 常见失败模式

11.1 为了追求质量无限加步骤

结果往往是成本、延迟和失败点一起增加。

11.2 一上来就优化最贵模型单价

但真正的大头可能是无效检索、过长上下文或重复工具调用。

11.3 只看平均值，不看长尾

很多用户真正感知到的是 P95 的慢，而不是平均值。

11.4 只做技术降级，不做产品降级

后端回退了，但前端没有解释，用户仍然觉得系统坏了。

11.5 把稳定性交给运气

没有超时、熔断、幂等、回退规则的系统，规模一上来就会暴露问题。

12. 可复用模板

12.1 性能预算模板

场景名称：
第一段可见反馈目标：
总完成时间目标：
检索预算：
模型调用预算：
工具调用预算：
前端渲染预算：

12.2 成本分析模板

场景名称：
日请求量：
平均单次模型成本：
平均单次工具成本：
平均单次检索成本：
平均重试次数：
总日成本：
可优化环节：

12.3 降级策略模板

异常类型：模型不可用 / 工具超时 / 检索异常 / 输出解析失败
当前策略：
回退路径：
用户提示：
是否转人工：是 / 否

13. 面试表达

你可以这样讲：

“我把 AI Agent 的成本、延迟和稳定性当成一个联动问题来做，而不是只盯模型效果。我的方法是先建立基线，再拆链路预算，区分模型、检索、工具和前端展示的耗时与成本来源，然后通过模型路由、上下文控制、缓存、降级和前端阶段反馈去平衡效果和体验。这样项目不只是能跑，而是能长期稳定运行。”