评估智能体性能：成功率、延迟与成本

一个从“拍脑袋优化”到“数据驱动调优”的真实转型故事——顺便聊聊我这三年烧掉的API费用和熬过的夜去年夏天我们团队做了一个电商智能客服Agent。上线第一周各项指标看起来都挺正常用户满意度4.7分平均响应时间不到2秒。老板很高兴在周会上点名表扬让我们全力推广还说月底要写个成功案例发到公司内网。结果第二周流量翻了三倍。然后各种问题就开始了。先是客服主管在群里发了一长串用户投诉截图。用户问“我的订单到哪了”Agent回答“您好请问您想查询哪个订单”用户把订单号发过去Agent又说“您的订单已发货预计明天送达。”其实那个订单三天前就签收了。用户火冒三丈。然后运维同学发现某些时段Agent的响应时间飙到了十几秒用户等不及直接挂断再打进来就转人工人工又忙不过来客诉量直接翻倍。月底财务把账单发过来我差点从椅子上摔下去。上个月API费用才三千多这个月直接蹦到了两万二。老板把我叫到办公室问了三个问题“这个月的成功率是多少比上个月降了多少”“为什么有的用户等了一分钟平均延迟不是1.8秒吗”“成本为什么超了这么多你们到底调用了多少次模型”我当时一个都答不上来。我虽然知道“成功率、延迟、成本”这三个词但从来没有系统地定义过它们也没有建立持续监控的机制。我们只是在跑通功能之后觉得“效果不错”就上线了。至于“不错”具体是多少有没有变差哪里变差了全靠拍脑袋。那之后我花了三个月时间从零搭建了一套智能体性能评估体系。这篇文章我就把这套体系的核心——成功率、延迟、成本——彻底讲透。不堆理论全是实战中摸出来的门道。你可能也会遇到跟我一样的坑希望你能少走点弯路。一、为什么评估智能体比评估传统软件难得多在开始讲三个指标之前先花点篇幅解释一个根本问题为什么评估Agent这么难我刚开始做的时候天真地以为“不就多写几个测试用例吗”。后来发现完全不是那么回事。传统软件的性能评估你写一个单元测试输入固定的参数检查输出是否符合预期。符合就算成功不符合就算失败。延迟也很好测——调用一次接口记录返回时间。成本更是透明——服务器配置定了每个月的固定开销就是那么多。Agent不一样它有四个让评估变得极其麻烦的特性。第一个是任务的开放性。用户问“帮我查一下订单”Agent可以成功。用户问“我昨天买的那双鞋怎么还没到你们是不是骗子公司”Agent很可能就懵了。同一个功能在不同语境、不同情绪、不同复杂度的输入下表现天差地别。你没法用一个固定的测试集覆盖所有情况。我统计过我们生产环境的用户问题光“查订单”这个意图就有三十多种不同的问法加上各种语气、错别字、中英文混杂根本不可能事先枚举完。第二个是结果的主观性。传统程序输出1就是10就是0。Agent输出是一段自然语言。你怎么判断这段话说得好不好语气对不对信息全不全有没有幻觉比如用户问“这个手机能用多久”Agent回答“正常使用情况下两年没问题”。这个答案对吗从事实角度手机寿命确实因人而异。但从用户满意度角度他可能觉得两年太短了。你没法用简单的“正确/错误”来判定。第三个是依赖外部系统的不可控性。Agent调用天气API天气API今天慢了Agent也跟着慢。Agent依赖的向量数据库偶尔超时Agent就可能返回“我找不到相关信息”。这些都不是Agent自己的问题但都会影响你看到的性能指标。我们有一次排查延迟飙高花了两天才发现是某个上游物流接口增加了50ms的延迟被Agent的多次调用放大了好几倍。第四个是非确定性。同一个问题问两次Agent可能给出不一样的回答。一次成功了一次失败了。因为LLM的推理本身带有概率性temperature0也不能保证百分之百相同。这意味着你跑一次测试集得到的结果可能跟你跑第二次不一样。你怎么定义成功率90%80%取决于你跑多少次测试。正是因为这些复杂性很多团队干脆就不做系统评估了上线之后全靠用户反馈和人工抽检。这种“凭感觉”的做法在小规模试点时还能应付一旦流量上来或者业务复杂度增加很快就会失控——就像我们团队那样。下面我把成功率、延迟、成本这三个核心维度一个个拆开来讲。每个维度我都会讲清楚它到底是什么意思怎么测量哪些因素会影响它以及我花真金白银买来的优化经验。二、成功率你的Agent到底能不能把事办成2.1 成功率的定义——不止是“答没答”我见过很多团队把成功率简单定义为“Agent没有报错的比例”。只要Agent返回了一段话就算成功。这显然不合理——返回的可能是“我不知道”也可能是完全跑题的答案用户根本用不了。一个更合理的成功率定义应该分层任务完成率用户提出的任务目标是否达成了比如用户要“查订单”Agent最终有没有给出订单状态这是最硬的指标。准确率Agent给出的信息是否正确有没有幻觉有没有错误的事实比如用户问“北京今天多少度”Agent回答“25度”实际是23度那就算失败。有用率用户是否觉得这个回答有用这个需要结合用户反馈——点赞/点踩、是否继续提问、是否转人工。有时候Agent给的信息正确但用户觉得没用比如问“怎么退款”Agent把“退款政策”全文贴出来用户还要自己找半天也算失败。在我现在的评估体系里我把“成功”定义为Agent在合理的步数内比如不超过5步以正确的方式完成了用户明确提出的任务目标且用户没有投诉或转人工。你可能觉得这个标准太严了。但说实话用户就是这么严的。他不会因为你的Agent已经努力了99%就原谅那1%的错误。2.2 怎么测量成功率——从人工到自动化测量成功率最可靠的方法当然是人工评估。你把Agent和用户的对话记录抽样出来让标注员逐条打分。我们早期就是这么干的找了两个实习生每天抽100条对话每条按“成功/部分成功/失败”三档打分。结果发现两个问题一是慢两个人一天最多标200条二是主观性强同一个对话两个人可能打出不同分数。2026年的主流做法是自动化评估 人工抽样的混合模式。自动化评估又分几种规则匹配对于有明确答案的任务比如“查订单状态”你可以写规则来验证Agent的回答中是否包含了订单号、状态关键词、物流单号等信息。比如正则匹配“订单号[:]?\s*[A-Z0-9]{10,}”匹配到了就算成功。规则匹配速度快成本低但只能覆盖结构化程度高的任务。我们大概有40%的请求可以用规则自动判定成功率。LLM-as-a-Judge让一个强大的大模型比如GPT-5.5或Claude 4来评估你的Agent的回答质量。你需要给评估模型写一套评分标准——比如“准确性1-5分”“完整性1-5分”“有用性1-5分”。然后把用户问题、Agent回答、上下文一起发给评估模型让它打分。这个方法在2025-2026年已经非常成熟很多团队在用。我们目前每天用GPT-4o-mini做全量评估成本很低一天几千个会话也就几美元。但需要注意评估模型本身也有偏差建议定期用人工评估校准。我们每个月会抽200条让三个人工标然后把人工分数跟LLM分数做对比如果偏差超过0.5分就调整评估Prompt。对比评估同时跑两个版本的Agent让用户或评估模型投票选哪个更好。这是A/B测试的思路适合做版本迭代时的决策。我们每次发新版本之前都会先在小流量上跑对比评估让LLM-as-a-Judge比较新旧版本的回答哪个更好。只有新版本胜率超过55%才会全量。我的经验是先用自动化规则跑全量数据每天统计一个大概的成功率趋势。发现异常时再抽样做人工详细分析。这样既控制了成本又不至于漏掉严重问题。2.3 影响成功率的因素——为什么你的Agent总失败根据我们过去一年对数千个失败案例的分析成功率低的主要原因集中在以下几点。我把它们整理成了一个表格你可以当checklist用失败原因占比基于我们的数据说明与对策意图识别错误约30%用户要退款Agent识别成咨询商品。优化Prompt增加示例或用小模型做前置分类。信息缺失导致无法执行约25%用户没给订单号Agent直接说“查不到”。应反问“请提供您的订单号”。工具调用失败约20%工具挂了或参数传错。加强容错重试、降级、参数校验。模型幻觉约15%Agent编造不存在的信息。需输出过滤和事实核查。超出步数/超时约10%任务太复杂步数内未完成。优化规划策略或提高步数上限。让我们一个个展开讲。意图识别错误是最常见的。用户说“我要退货”Agent却开始介绍商品详情。原因往往是Prompt里的意图分类描述不够清晰或者用户表达方式太特殊比如“这东西我不要了”。我们的解法是用一个轻量分类器比如BGE-small做前置意图识别把用户问题分成几大类然后再把这个分类结果传给LLM。这样准确率从80%提到了92%以上。信息缺失是新手最容易忽略的。你告诉Agent“查订单需要订单号”但它不知道“如果用户没给订单号怎么办”。正确的做法是在Prompt里写死规则“如果用户没有提供订单号回复‘请提供您的订单号我帮您查询’。” 我们把这个规则写进了System Prompt的顶部加了警告“此规则优先级最高”才彻底解决问题。工具调用失败有很多种工具本身挂了、超时、参数类型错误、权限不足。我们遇到过最离谱的一次Agent要查天气传的参数是{city: 北京今天}因为用户说的是“北京今天天气”。工具解析失败返回错误Agent以为是自己调用方式不对换了个参数{city: Beijing today}再调还是错。循环了五次才放弃。解法是在工具调用的代码里加参数校验和清洗比如把用户输入中的“今天”“明天”剥离掉只保留城市名。模型幻觉是最危险的。用户问“我的订单什么时候发货”订单系统返回“未发货”Agent却回答“已发货预计明天送达”。这种错误会直接导致用户投诉。我们用了两招防御一是输出过滤在Agent的回答返回用户之前用规则检查是否包含“已发货”但上下文里没有物流单号二是引入事实核查小模型专门用来验证Agent的输出是否与检索到的信息一致。超出步数限制说明任务太复杂了。我们设置的默认步数是5步超过就强制终止并返回“任务太复杂请简化您的问题”。后来我们发现有些合法任务确实需要6-7步就把步数上限调到了8同时优化了规划策略减少了无效步骤。2.4 优化成功率——从80%到95%的实战路径我们团队把客服Agent的成功率从上线初期的78%提升到了现在的94%大概经历了这几个阶段第一阶段78% → 85%耗时两周主要工作是修复明显的bug和Prompt缺陷。我们把所有失败案例人工过了一遍发现80%的错误都可以通过补充规则解决。比如“信息不足时反问”这条规则加进去之后成功率直接涨了5个百分点。还有几个工具的description写得太笼统改成了“当用户询问订单状态、物流信息时使用此工具”误用率大幅下降。第二阶段85% → 90%耗时三周引入了ReAct模式和短期记忆。以前我们的Agent是单次推理收到问题直接回答没有“思考-行动-观察”的循环。改成ReAct之后它会先判断需不需要工具需要的话调用工具拿到结果再回答。这让复杂任务的成功率提升明显。同时我们把会话历史纳入了上下文Agent不再“失忆”。第三阶段90% → 94%耗时一个月加入了Reflection自我纠错和长期记忆。当Agent不确定自己的回答是否正确时它会触发一个自我检查步骤用另一个Prompt把当前回答再审核一遍发现问题就修正。这个机制把幻觉率从8%降到了3%以下。长期记忆方面我们把用户的历史偏好和成功任务路径存入了向量库下次遇到类似问题时能复用经验。达到94%之后再往上提升的边际效益就很小了。每一分提升都需要大量的case分析和针对性优化有时候改一个Prompt只能提升0.1%。我们现在把目标定在95%剩下的5%留给人工兜底。三、延迟你的Agent够快吗3.1 延迟的构成——时间都花在了哪儿用户感知到的端到端延迟是Agent整个执行链路的总和。拆开来看主要包括用户输入的网络传输时间通常很小几十毫秒Agent服务内部的预处理时间解析输入、加载会话状态、检索记忆LLM推理的时间大头通常占60%-80%工具调用的时间取决于外部系统的响应速度后处理时间格式化输出、保存记忆、写日志其中LLM推理时间和工具调用时间是最主要的两个变量。LLM推理时间取决于模型的大小和复杂度。GPT-5.5这样的大模型单次推理可能需要300-800毫秒。如果Agent需要多次调用LLM比如ReAct模式下每走一步都要调用一次总时间就是累加的。我们一个典型的客服Agent平均需要2-3次LLM调用才能完成一个任务所以光LLM部分就要1-2秒。工具调用时间取决于你调用的外部服务。查数据库可能需要50毫秒调第三方物流API可能需要200-500毫秒如果那个API本身就有延迟抖动可能飙到1-2秒。如果你的Agent依赖一个很慢的外部服务你的延迟就会被它拖死。3.2 怎么测量延迟——百分位数比平均值更重要很多团队只关注“平均延迟”。这是个巨大的陷阱。假设你测量了100次请求99次耗时1秒1次耗时100秒。平均延迟是1.99秒看起来不错。但实际用户体验是99%的人体验很好1%的人体验极差。这1%的用户很可能会流失还会在社交媒体上骂你。所以必须关注百分位数尤其是P95和P99——也就是95%和99%的请求在多少毫秒内完成。我常用的指标组合是平均延迟、P50中位数、P95、P99、最大延迟。监控这些指标的变化趋势一旦P99突然飙升说明有异常情况需要排查。测量延迟的方法很简单在Agent代码的关键节点打点记录时间戳。比如在接收用户输入时打一个在调用LLM前打一个在LLM返回后打一个在调用工具前打一个在工具返回后打一个在最终输出前打一个。把这些时间差记录下来你就知道时间花在哪里了。我们用的是OpenTelemetry自动埋点加上自定义span。每次LLM调用和工具调用都是一个独立的span最后在Jaeger里可以看到完整的调用链火焰图。哪个环节慢一眼就能看出来。3.3 常见的延迟陷阱——为什么有的请求特别慢根据我们的监控数据导致P99飙高的原因主要有这么几种LLM推理的尾延迟。同样的模型同样的输入99次可能很快但有1次因为模型内部的某种原因可能是batch调度、资源竞争、内存分配变得非常慢。这种情况很难根治只能通过超时熔断重试来缓解。我们设置LLM调用超时3秒超时后自动重试一次如果还超时就走降级路径用更小的模型快速回答。工具调用的超时重试。你的Agent调用一个外部API设置了3秒超时。API在3秒后还没返回Agent触发重试又等了3秒。结果就是6秒过去用户还在转圈。更好的做法是设置较短的超时比如1秒快速失败然后降级到备选方案比如用缓存数据或者直接告诉用户“暂时查不到请稍后再试”。我们改了这个策略之后P99延迟从8秒降到了3.5秒。链式调用过长。ReAct模式下每走一步都要调用一次LLM。如果任务需要5步就是5次LLM调用串行。总延迟是5次LLM延迟之和。如果有办法并行调用工具比如同时查两个数据源可以大幅降低延迟。但并行需要仔细设计依赖关系。我们的报告生成Agent就把“收集数据”这个步骤做成了并行——同时去三个数据源拉数据等所有结果返回后再继续。总时间从串行的9秒降到了并行的3秒。上下文过长。如果Agent的短期记忆里塞了太多历史对话每次调用LLM都要处理很长的输入。这会导致推理时间线性增长。解决方案是定期压缩或摘要历史对话只保留关键信息。我们用的是滑动窗口摘要混合最近5轮对话保留全文更早的对话用LLM生成一句话摘要。这样上下文长度从5000 token降到了1500 token推理时间缩短了40%。模型排队。如果你用的是共享的LLM API而不是专有实例高峰期请求可能需要排队等待。这会导致P99大幅上升。解决方案是使用专有部署provisioned throughput或者提前预热。我们后来换了Azure OpenAI的专有部署虽然贵了一点但P99稳定在1.5秒以内。3.4 延迟优化的实用技巧选择更快的模型。GPT-4o-mini比GPT-5快很多虽然质量稍差但很多简单任务够用。我们实现了模型路由简单任务如FAQ、天气查询走GPT-4o-mini复杂任务如多步推理、代码生成走GPT-5.5。整体P95延迟从2.8秒降到了1.9秒。使用流式输出。不要让用户等到完整回答生成后才看到任何东西。流式输出可以让用户边看边等感知延迟会大大降低。用户看到第一个字出现的时间首token时间比完整响应时间重要得多。我们把流式输出打开后用户投诉“慢”的数量减少了70%。缓存常见问题的回答。用户问“你们营业时间是几点”这种问题答案基本不变。第一次查出来后缓存到Redis后续请求直接返回零延迟。我们缓存了大约200个高频问题命中率有15%这部分请求的响应时间从1.5秒降到了50毫秒。工具调用超时设置要合理。根据外部服务的SLA设置超时不要用默认的几秒。快速失败比慢速成功对用户体验的伤害更小。我们把所有外部API的超时都设成了2秒超时后直接返回“服务暂时不可用请稍后再试”而不是让用户等半天。预热与保持连接。LLM API和数据库连接池要提前建立避免冷启动延迟。我们的Agent服务启动时会预先建立10个到LLM API的HTTP连接池第一次请求不会触发TCP握手省了100多毫秒。四、成本别让API账单吃掉你的利润4.1 成本的构成——不只是Token费用智能体的运行成本远比“模型API调用费”要复杂。我把成本分为四类每一类我们都踩过坑。第一类模型API调用费。这是最显性的一块取决于调用次数、每次的token数量、以及模型的单价。输入token和输出token的单价不同输出通常更贵。以2026年5月的定价为例GPT-5.5输入$5/百万token输出$30/百万tokenGPT-4o-mini输入$0.15/百万token输出$0.6/百万token。差了一个数量级。第二类工具调用与外部服务费。如果你的Agent需要调用第三方API比如Google搜索、高德地图、OpenWeather这些服务可能按次收费。我们用的物流查询API是0.01元/次一天几十万次查询就是几千块。还有一些Agent会调用付费的RAG向量数据库如Pinecone按存储量和检索次数计费。第三类基础设施与运维费。如果你自己部署开源模型需要GPU服务器。H100的租赁价格2026年已经涨到了每GPU小时2.35美元。一套推理集群8卡一个月的成本轻松上万。还有日志存储、监控系统、数据库的费用。我们用的向量数据库Qdrant自建每月存储成本约300美元。第四类人工审核与干预成本。如果你设置了“人在回路”机制人工审核员的工资也是成本。虽然这通常归类为运营支出但它确实是Agent系统总成本的一部分。我们每周需要2个人各花半天时间审核高风险操作的Agent建议折算下来每月成本约2000美元。4.2 怎么测算成本——从账单到归因成本测量的第一步是精细化的账单归因。API提供商给你的账单通常是一行总数你看不出来是哪个会话、哪个任务花了多少钱。你需要在自己的系统里做一层代理每次调用LLM API时记录消耗的输入token数、输出token数、模型名称、会话ID、步骤ID。定期汇总你就能知道每个用户/每个会话花了多少钱每个任务类型查订单vs退款的平均成本哪个环节思考vs工具调用消耗了最多的token我们用的是LangSmith的成本追踪功能它会自动记录每次LLM调用的token消耗和费用并且跟会话关联。每周导出一次数据在SQL里做聚合分析。成本预测也很重要。如果你知道日均请求量、平均每请求token消耗你可以估算出月度成本避免月底收到天价账单时措手不及。我们做了一个简单的小工具每天根据当天的调用量预测本月总成本超过预算80%就发告警。4.3 成本失控的常见原因——钱都烧在了哪里我见过不少团队Agent跑了一个月账单高得离谱。复盘原因无外乎以下几种无效的token浪费。System Prompt写得太长每次调用都带上几千token的“废话”。用户输入很短但上下文里塞了太多历史导致每次调用都处理大量无用信息。我们有一次System Prompt写了3000 token后来精简到800 token每请求成本直接降了60%。死循环或过度重试。Agent在一个问题上卡住了反复重试同一个工具调用每次重试都产生token费用。步数限制max_iterations没设置好Agent可以无限跑下去。我们一个测试环境曾经因为一个bug一个Agent跑了8万步消耗了200多美元的token费用才被我们发现。使用过贵的模型处理简单任务。所有请求都走GPT-5.5不管任务多简单。其实70%的请求可以用GPT-4o-mini或Gemini Flash解决。我们做了模型路由之后API费用从每月2万美元降到了1.2万美元。没有利用缓存。重复的用户输入每次都重新计算没有启用prompt caching。缓存命中后输入成本可降低90%。OpenAI和Anthropic都支持prompt caching我们打开之后输入token费用下降了70%。4.4 成本优化策略——花更少的钱办同样的事模型路由。根据任务复杂度动态选择模型。简单问答走便宜模型复杂推理走贵模型。我们实现了一个路由层先用一个轻量分类器判断意图和复杂度然后路由到对应的模型。整体成本下降了约40%。提示词缓存。把System Prompt和一些固定的指令前缀标记为可缓存。绝大多数LLM API都支持prompt caching打开这个开关输入成本能大幅下降。注意缓存只在相同前缀连续出现时生效所以最好把固定部分放在最前面。批处理。对于非实时的任务如批量生成报告使用批处理API。价格通常是实时API的一半。我们把每天的日志分析任务改成了批处理每月省了300美元。压缩上下文。不要无限制地堆砌历史对话。定期摘要只保留关键信息。减少每次调用输入的token数。我们的滑动窗口摘要方案把平均输入token从5000降到了1800。开源模型自建。当日均调用量超过某个阈值比如100万token/天自建开源模型的TCO可能比调用闭源API更低。但这需要硬件投入和运维团队。我们算过超过300万token/天时自己部署Llama 4或Qwen 3.6更划算。五、综合评估怎么平衡三个指标成功率、延迟、成本三者之间存在trade-off就像分布式系统的CAP定理一样你不可能三个都做到极致。追求更高成功率 → 需要更复杂的推理如Reflection、多次重试→ 增加延迟和成本追求更低延迟 → 用更小的模型、更少的步数 → 成功率可能下降追求更低成本 → 用便宜模型、减少重试、不缓存 → 影响成功率和延迟没有一个“完美”的平衡点它取决于你的业务场景。如果你的Agent面向的是企业级客户他们可能愿意为高成功率支付更高的延迟和成本。一次错误的订单处理造成的损失比如发错货、多退款远大于几秒钟的等待和几分钱的API费用。这类场景应该把成功率SLO设为99%以上延迟和成本可以放宽。如果你的Agent是面向普通消费者的实时对话助手用户对延迟极其敏感。超过3秒的响应就会让用户不耐烦很多人会直接关掉页面。这时候你可能需要牺牲一点成功率来换速度。比如用更快的模型即使准确率低几个百分点只要用户等得起就行。如果你的Agent是内部提效工具批量处理任务对延迟不敏感但成本要严格控制。你可以选择便宜模型、批处理、非高峰期运行延迟几十秒都能接受只要每月预算不超。我常用的方法是设定SLOService Level Objective。比如成功率 ≥ 95%P95延迟 P95 ≤ 3秒每个会话成本 ≤ $0.05然后持续监控这三个指标一旦某个指标偏离SLO就触发告警和优化。优化的目标是“在满足SLO的前提下尽可能提高其他指标”而不是盲目地追求每个指标都最优。六、一套可落地的评估框架最后我把自己在用的评估框架整理出来供你参考。这套框架我们已经跑了快一年效果还不错。1. 每日自动批评估每天凌晨从生产日志中抽取前一天的所有会话抽样10%或者全量如果成本允许用LLM-as-a-Judge跑一遍评估。输出成功率任务完成率/准确率/有用率各类失败原因的分布平均延迟、P95延迟、P99延迟平均成本、P95成本、总成本生成一份HTML报告自动发送到团队钉钉群。2. 每周人工抽样深度分析每周随机抽取50个失败案例和20个成功案例由产品经理和开发人员一起人工分析。找出共性问题比如“很多失败是因为订单号提取错误”然后录入bug追踪系统排期修复。这周的分析结果会作为下周的优化重点。3. 每月回归测试在每次版本发布前跑一遍固定的回归测试集约500个用例覆盖核心场景。确保核心功能的成功率没有下降。对比新旧版本的延迟和成本差异。如果新版本成功率下降超过1%就不允许发布。4. A/B测试平台对于重大改动比如换模型、改Prompt结构、调整步数限制先在小流量上做A/B测试。实验组5%流量对照组5%流量跑3-7天。对比三个指标用统计学显著性检验比如t检验判断是否显著提升。只有新版本在至少两个指标上显著优于旧版本才逐步扩大到全量。5. 成本预算与告警在API层面设置月度预算告警。我们用了OpenAI的预算提醒功能当月消耗达到预算的80%时发送预警到钉钉达到100%时自动熔断拒绝新的API调用或需要人工审批继续。熔断很痛苦所以我们设置了90%时就发紧急告警给运维留出处理时间。这套框架运行了大半年我们的Agent性能一直稳定在SLO之内。老板再也不追着我问“为什么又出问题了”——因为在他的仪表盘上绿色的指标说明了一切。七、一些你可能没注意到的细节除了上面讲的三个核心指标还有几个细节值得提一下。关于采样全量评估成本太高但抽样太少可能错过异常。我们的做法是成功率用10%采样延迟和成本用全量这些数据采集成本很低。如果某个时间段成功率出现波动再对该时间段全量回溯分析。关于评估模型的选择用GPT-5.5做Judge当然最准但成本高。我们经过对比发现GPT-4o-mini作为Judge的结果跟人工标注的相关性达到0.92已经够用了。只有在对边缘case做深度分析时才调用GPT-5.5。关于用户反馈的利用用户主动点“踩”或者转人工的会话优先级最高这些一定要全量分析。我们把这些会话自动标记为“高优先级”每天优先处理。关于冷启动新上线的Agent没有历史数据怎么定SLO我们先用离线测试集跑出基准值然后上线后第一周不做自动熔断只监控和记录。一周后根据实际数据调整SLO。结语写到这里我想起去年那个被老板三个问题问得哑口无言的下午。如果当时我能拿出一份报告告诉他“本月成功率为92.3%比上月下降1.2%主要原因是物流API超时导致工具调用失败增加P95延迟2.8秒符合SLO平均每个会话成本0.032美元低于预算。”我想他的反应会完全不一样。他可能会点点头说“那你去把物流API的问题解决一下”而不是拍着桌子问“你到底行不行”。评估不是为了一堆数字。评估是为了让你知道你的Agent到底干得好不好哪里可以改进预算会不会超支。没有评估你就像开着一辆没有仪表盘的车——你只知道它还在跑但不知道油箱还剩多少发动机有没有过热轮胎有没有漏气。