1. Agent性能概述
聊到Agent性能，我先说说自己的体会。几年前我刚接触Agent系统时，总觉得能跑起来就行。结果呢？一个简单的问答Agent，用户等响应等了十几秒，直接弃用。那次教训让我明白——性能不是锦上添花，而是生死线。
什么是Agent性能
说白了，Agent性能就是衡量你的智能体干活快不快、准不准、省不省资源。它不像传统软件那样只盯着响应时间，Agent系统更复杂——你想想看，它要调用LLM、要检索知识库、要执行工具调用，每一步都可能成为瓶颈。
我个人习惯把Agent性能拆成两个维度看：
- 用户体验维度：用户等多久、回答对不对、交互顺不顺
- 系统效率维度：资源吃多少、并发扛不扛得住、成本高不高
核心观点：Agent性能不是单一指标，而是一组相互制约的平衡点。你优化了延迟，可能牺牲了准确率；你提升了吞吐量，资源消耗可能飙升。
为什么需要调优
我在项目中遇到过这样一个场景：一个客服Agent上线后，准确率高达95%，但每次响应要8秒。用户反馈说"这AI还不如人工快"。你看，光有准确率是不够的。
调优的必要性，我总结为三点：
- 用户耐心有限——研究表明，超过3秒的响应，用户流失率增加40%
- 成本控制——一个没调优的Agent，API调用次数可能是优化后的3-5倍
- 系统稳定性——高并发下，没调优的Agent直接崩溃，我踩过这个坑
避坑提醒：我曾经接手过一个项目，团队花了两周调模型准确率，结果上线第一天就被流量打垮了。调优一定要从全局出发，别只盯着一个指标。
性能指标分类
聊指标之前，先看一张图，帮你建立整体认知：
嗯，这张图基本把性能指标的框架讲清楚了。下面我逐个展开说说。
延迟
延迟就是用户发出请求到收到回复的时间差。在Agent系统里，延迟通常分三段：
- 感知延迟：用户输入被系统接收的时间
- 处理延迟：Agent思考、调用LLM、检索知识库的时间
- 输出延迟：生成结果并返回给用户的时间
我记得有一次优化一个文档问答Agent，发现80%的延迟都耗在知识库检索上。后来加了缓存，延迟从6秒降到了1.2秒。所以调延迟，先找瓶颈在哪。
小技巧：用链路追踪工具（比如LangSmith、Arize）把每个环节的耗时打出来，一眼就能看出谁在拖后腿。
吞吐量
吞吐量衡量的是系统在单位时间内能处理多少请求。对于Agent来说，常见单位是QPS（每秒查询数）或TPM（每分钟Token数）。
我见过一个典型的翻车案例：某Agent单机测试时QPS能到50，上线后实际流量一冲，直接降到5。为什么？因为没考虑LLM的并发限制和API限流。你想想看，一个LLM接口每秒只允许10次调用，你前端再快也没用。
吞吐量的关键影响因素：
- LLM服务的并发上限
- 知识库的检索速度
- 工具调用的外部依赖响应
- 系统自身的线程/协程模型
准确率
准确率是Agent的"智商"指标。但这里有个坑——准确率不能只看最终答案对不对。
我曾经踩过一个坑：一个代码生成Agent，测试集上准确率92%，但上线后用户反馈"经常答非所问"。后来一查，问题出在意图识别环节——用户问A，Agent理解成了B，然后给出了B的正确答案。你说这算准确还是不准？
所以我把准确率拆成三层：
- 意图理解准确率：Agent是否理解了用户真正想问什么
- 工具选择准确率：是否调用了正确的工具/知识库
- 答案生成准确率：最终输出是否正确、完整
| 层级 | 评估方法 | 常见问题 |
|---|---|---|
| 意图理解 | 人工标注 + 分类测试 | 歧义输入、多轮上下文丢失 |
| 工具选择 | 调用链路日志分析 | 工具误调用、参数传递错误 |
| 答案生成 | BLEU/ROUGE + 人工评估 | 幻觉、信息遗漏、格式错误 |
资源消耗
资源消耗是容易被忽视的指标。很多团队只盯着延迟和准确率，结果月底一看账单傻眼了。
资源消耗主要包括：
- 计算资源：CPU、GPU、内存的占用率
- 存储资源：知识库索引大小、缓存占用
- API成本：LLM调用次数 × 每次调用的Token数
- 网络开销：数据传输量、带宽占用
我个人习惯用成本/有效请求这个指标来衡量资源效率。举个例子，一个Agent每次请求平均消耗5000个Token，成本是0.015美元。如果优化后降到3000个Token，成本就降了40%。别小看这个数字，日活10万的系统，一个月能省几万块。
总结一下：四个指标不是孤立的。延迟高了，用户体验差；吞吐量低了，扛不住流量；准确率低了，用户不信任；资源消耗高了，老板不高兴。调优就是在这四个维度之间找平衡。
好了，这一章就聊到这。记住一句话：没有测量就没有优化。先把这些指标埋点打上，拿到数据再动手调。下一章我会讲具体的调优工具和方法，到时候见。
公众号:蓝海资料掘金营，微信deep3321