企业级 Agent 落地最难的往往不是把模型接进来跑通一个 demo而是你敢不敢对它承诺 SLA。我在过去一年多帮几家公司搭 Agent 平台听到最多的一句话是“Agent 效果不稳定没法上线”。但追下去问几乎没有一家能说清楚“不稳定”到底指什么——是响应慢是任务做错还是经常转圈不干活没有指标稳定性就只能靠感觉靠感觉的东西永远没法交付。这篇文章把我在企业级 Agent 项目里建立可量化 SLA 指标体系的完整思路、分层设计、计算公式和实操踩坑记录写出来给正在做 Agent 落地的团队一个可以直接抄作业的参考。1. 为什么企业级 Agent 必须先谈 SLA1.1 Agent 与传统系统的 SLA 有什么不同传统后端服务的 SLA 很成熟核心就是可用性、延迟、错误率四个九、五个九说清楚监控告警一套全齐。但 Agent 不是传统服务它最大的特点是不确定性同一个 prompt 在不同时间调用可能走完全不同的工具链路输出内容也可能有差异。这种不确定性直接导致传统 SLA 体系失效——你没法用一个简单的 HTTP 状态码判断一个 Agent 任务是否“成功”。传统 API 的成功率高不高看响应状态、看耗时分布就够了。但 Agent 多了一个“过程正确性”的维度它可能所有接口都调通了、也没报错但最后给的答案是错的也可能中间经历了三次重试、绕了很远的路但最终结果是对的。这两个场景在传统监控里都是“成功”在业务视角里质量天差地别。所以企业级 Agent 的 SLA 体系必须是立体的至少要覆盖三层基础设施层API 通不通、实例活不活、任务执行层步骤成不成、整体完不完成、业务结果层答案对不对、用户认不认。只有三层指标都有你才能对一个 Agent 服务做出可信的 SLA 承诺。我在内部培训时经常打一个比方传统 SLA 是给车装仪表盘看速度、油量、水温Agent 的 SLA 不但要看仪表盘还得看司机有没有把乘客送到正确的地方。1.2 不建指标体系的 Agent 项目都会踩哪些坑我见过太多 Agent 项目在 POC 阶段跑得很漂亮一上生产就崩复盘下来几乎都是同一个原因没有预先定义“什么叫做好”。没有指标大家就只能靠主观判断这时候一定出问题。第一个坑是出了问题说不清影响范围。生产环境 Agent 开始乱答业务方说“Agent 坏了”研发看资源占用率都是正常的双方扯皮半小时最后发现是上游模型 API 的限流策略变了导致 Agent 在高并发下降级成了空回复。如果当时有任务成功率趋势图这个问题两分钟内就能定位成功率从 98% 掉到 60%时间点和 API 配置变更完全吻合根本不用吵。第二个坑是优化没有方向。老板问“Agent 这个月表现怎么样”你如果只能回答“还行吧”那你就失去了话语权。反之如果你能拿出数据说“任务成功率 95%但金融场景的意图识别准确率只有 88%人工介入率偏高”老板就知道下一步该优化什么你也更容易争取资源。第三个坑是没法做容量和成本规划。Agent 的调用链比普通接口长得多一个任务可能触发几十次 LLM 调用token 消耗会呈指数级增长。没有成本指标月底账单出来就是惊吓。我见过一个团队上线一周光 API 费用就烧掉六位数原因就是重试逻辑没做上限控制。这些问题都不是技术上多难而是从一开始就没有把 SLA 指标当作交付物的一部分来设计。2. 指标体系怎么搭从可用性到业务价值的五层模型2.1 分层设计思路先能跑再跑快再跑对在给 Agent 设计体系时我习惯用“五层模型”来梳理基础设施层、性能层、任务执行层、质量层、成本层。这五层不是并列关系而是有依赖关系的漏斗——底层出问题上层必然受影响但底层全绿不代表上层一定健康。这个分层逻辑背后有一个很实际的考虑不同的人关心不同的层。运维关心基础设施层研发关心性能层和任务执行层产品关心质量层老板关心成本层和最终的业务效果。如果指标体系不分层把几十个指标平铺在一起每个角色都得自己去翻找关心的指标这个体系是落不了地的。分层之后还有一个附带好处当上层指标异常时你可以沿着漏斗逐层下钻系统性地排查问题出在哪里而不是像无头苍蝇一样到处看日志。五层的递进关系是这样的基础设施层健康Agent 才可能正常执行执行快用户体验才可能好执行成功率高质量才有可能保证质量稳定单位成本才可能可控。这里要特别提醒一点分层不是越细越好。我见过有人把“LLM 调用次数”“工具调用次数”都单拎出来建层结果一半指标没人看成了摆设。分层建到能支撑“告警定位 角色分工 优化决策”这三个目的就够了。2.2 每层指标选什么、怎么定义阈值基础设施层主要看三类指标Agent 服务实例的可用性进程活着、接口可响应、依赖模型 API 的可用性特别是模型调用是否被限流或返回异常、以及 wasm/插件/工具函数执行环境是否正常。这一层的阈值可以沿用传统 SRE 的标准核心服务要求 99.9% 以上辅助能力可以放宽到 99%。性能层需要关注两类时间一个是端到端时延也就是用户从发起到拿到最终结果的总时长另一个是过程时延包括首 Token 时间TTFT、工具调用耗时、重试等待耗时。阈值怎么定要看场景——客服类和 Copilot 类场景用户期望几秒内出结果后台自动处理类任务用户容忍度可以放宽到几十秒甚至分钟级。性能指标最大的坑是平均时延会骗人必须同时看 P95、P99 和最大耗时因为 Agent 任务的重试抖动非常严重平均值往往很漂亮但长尾用户已经被卡到崩溃。任务执行层是 Agent 特有的核心层核心指标包括任务成功率、分步成功率、重试率、死循环发生率。这里的“完成”定义需要产品和技术一起拍板而且必须区分“正常完成”和“通过兜底逻辑完成”——比如超时后走默认答案算不算成功不同业务定义不同但口径必须统一否则数据没法用。阈值建议比传统服务宽松一些初始版本任务成功率超过 85% 就属于可上线状态优化到 95% 以上就是成熟状态因为 LLM 的不确定性决定了很难做到 99% 以上的稳定。质量层的指标要回答“做完了活儿干得好不好”常用的有人工介入率、用户满意度、结果准确率需要标注或抽检。人工介入率是个很灵敏的信号如果超过 30%说明 Agent 的自动完成能力其实很弱本质还是个工单分发系统。成本层则要盯住每个任务的平均 token 消耗、单次 Agent 任务成本、成本/成功率比值。这两层的指标偏软往往需要业务系统配合采集我见过很多团队卡在这一步后面实操部分会展开讲。3. 核心指标的量化定义与计算公式3.1 可用性与性能指标怎么算可用性是最基础的指标熔断算不算故障要看具体约定。我通常用这个口径单次任务在 10 分钟内无法启动或执行中断无法恢复计为一次可用性故障。月度可用率的计算方法是当月可用分钟数除以当月总分钟数。举个例子某 Agent 服务月内发生了两次故障每次 30 分钟当月共 43200 分钟按 30 天算可用率就是 43200 减 60 除以 43200等于 99.86%。这个计算逻辑不复杂但计算口径要想清楚尤其要提前约定“计划内维护”是否扣除否则和客户对账的时候容易扯皮。性能层指标里端到端时延我建议直接取 P95。单次任务响应时间的 P95 计算方式是先把当月所有任务耗时排序取排在 95% 位置的那个值。比如 100 个任务里耗时的第 95 个值就是 P95。P95 比平均值稳健得多不容易被个别极慢请求带偏而且对用户体验更敏感。首 Token 时间TTFT在交互型 Agent 里也建议单列它的计算方法是从用户提交请求到流式响应输出第一个 Token 的时间间隔这个值如果超过 3 秒用户的体感就会非常差。3.2 任务成功率与质量指标怎么算任务成功率是整个体系里最核心的指标但它的定义也最容易产生歧义。我建议用“业务完成率”作为总指标同时把“技术成功率”当作辅助指标。业务完成率等于业务成功完成的 Agent 任务数占总任务数的比例判定标准是是否达到预设的业务目标技术成功率则只看 Agent 执行过程有没有发生未捕获的异常或未完成任务无论结果对不对。举个例子一个做报表分析的 Agent用户问“帮我统计上季度各区域销售额”Agent 成功调用数据库、成功生成图表但统计口径搞错了结果算错——这在业务完成率里是失败在技术成功率里却是成功。两个指标一起看才能识别“假成功”问题。分步成功率更详细是对 Agent 内部每个决策和工具调用步骤做评估。计算方式是统计所有任务在关键步骤上的成功执行次数除以总执行次数。比如一个任务要走三步理解意图、调用工具、生成答案中间任何一步失败整体就算部分失败。分步成功率的核心价值是帮定位瓶颈——如果总成功率低但分步成功率也低问题出在执行链路如果总成功率低但分步成功率挺高问题可能出在目标理解层而不是工具执行层。重试率则是一个辅助信号等于触发重试的任务数占总任务数的比例。超过 20% 就要注意了说明 Agent 的决策经常走到错误分支靠重试在硬撑。质量层的指标里人工介入率计算方式是人工接管 Agent 任务的次数除以总发起次数。满意度的口径我一般推荐用“不满意量占比”即用户主动打低分或投诉次数除以总完成次数——因为企业中主动打高分的用户很少只有差评才是有效信号。结果准确率在没有自动判定能力时可以用抽检的方式由业务专家按置信区间抽检一定比例的已完成任务抽检准确数除以抽检总数。3.3 成本指标怎么算成本是 Agent 落地中被低估最多的部分。单任务平均 token 耗用量等于当日总 token 消耗除以当日总任务数。总 token 消耗要区分输入、输出和缓存三种分别计费。我在实践里发现缓存命中率的优化空间非常大很多团队没有设计缓存策略导致重复的 system prompt 每次都在重新计费。计算时建议把 token 成本转换为单任务成本乘以对应模型单价即可比如某模型输入 0.003 元/千 token、输出 0.012 元/千 token一个任务消耗输入 20000 token、输出 4000 token单个任务成本就是 20000 除以 1000 乘以 0.003 加上 4000 除以 1000 乘以 0.012等于 0.108 元。这个数值要作为常态指标监控一旦单任务成本突然上涨往往意味着重试变多或上下文膨胀是系统劣化的早期信号。4. 实操落地埋点、SLO、看板与告警4.1 关键事件埋点怎么设计指标定义得再好埋点采不到数据也是白搭。Agent 的埋点一定不能在业务代码里到处手动加日志那样太容易漏。我的做法是在 Agent 执行框架里做一层统一的“运行时事件总线”把 Agent 生命周期中的关键节点都作为结构化事件广播出来再统一采集。关键节点我一般定义成四类任务开始、任务结束、步骤完成、步骤失败。任务开始事件至少要带 task_id、session_id、用户所属业务线、目标描述摘要任务结束事件必须带最终状态成功、失败、人工接管、超时、兜底标记、耗时步骤事件要带步骤类型意图识别、工具调用、生成回复、工具名、输入摘要、输出摘要、耗时、是否重试。所有事件统一走事件总线由采集端聚合落库。这里要特别强调给任务带全局唯一 task_id 的重要性。Agent 链路长日志散落在多个服务和调用里没有统一的 task_id排查问题就要用时间加关键词去猜非常痛苦。我习惯在入口网关处生成 task_id然后塞进上下文对象一路透传所有子调用、事件都带上它。这和后端 trace_id 的思路一样但很多人做 Agent 的时候会忽略等出问题了再回头补成本就大了。数据存储上指标类和明细类要分开。明细事件存 Elasticsearch 一类支持全文检索的引擎用于问题排查指标聚合数据存 Prometheus用于告警和绘制趋势。链路数据如果预算够可以接 Jaeger 这类链路追踪系统但至少要保证事件流里有完整的上下文关联。伪代码层面事件采集大概长这样# 统一的 Agent 事件采集示例 import json, time def emit_agent_event(event_type, task_id, payload): event { event_type: event_type, # task_start / task_end / step_done / step_fail task_id: task_id, ts: time.time(), payload: payload } # 异步发送到消息队列或直接写日志避免阻塞 Agent 主流程 kafka_producer.send(agent_events, json.dumps(event))埋点层还有一个非常容易被忽视的点不要在 Agent 主流程里同步打点。阻塞、超时都会反过来影响性能和成功率所有的埋点都应该异步发送或者直接写入本地磁盘由 Agent 采集。我在项目里遇到过因为日志同步写导致 Agent 性能劣化的案例后来把发送改成异步批量后才消除。4.2 SLO 设定与告警分级指标有了下一步就是设定 SLO服务等级目标并把告警分级。我强烈建议不要给所有指标设一条阈值的单一告警那样告警疲劳会拖垮团队。告警我通常分三级P0紧急、P1严重、P2提示。P0 是直接影响业务可用性的比如技术成功率低于 60% 持续 5 分钟、模型 API 大规模返回异常导致可用性跌破 99%P0 必须电话或 IM 强提醒要求 15 分钟内响应。P1 代表服务质量劣化比如 P95 时延超过基准线 2 倍、人工介入率连续 2 小时超过 40%P1 可以走 IM 告警要求 30 分钟内响应。P2 则属于趋势性预警比如单任务成本开始抬头、重试率超过 15%这种不需要立刻处理但要在日报里体现。SLO 的基准线怎么定如果没有历史数据第一阶段先观察两到四周把当前实际水平测出来然后在“实际值”和“业务可接受值”之间取一个偏保守的目标——注意是保守不要一开始就定很高。比如当前成功率 90%业务要求 95%第一阶段的 SLO 可以先定 92%跑通告警和复盘机制后再逐步拉高。一开始就定 95% 的话会陷入频繁告警但大家又处理不过来的尴尬。4.3 看板示例与巡检节奏看板不用做得花哨但布局逻辑要跟五层模型对应起来。我通常会在 Grafana 里建四行第一行放基础设施和性能的实时状态第二行放任务成功率、分步成功率、重试率第三行放人工介入率、满意度、抽检准确率第四行放成本趋势。每一行都支持点击下钻到明细这是排查效率的关键。巡检节奏上建议建立“小时巡检 日报 周报”的结构。小时巡检只需要看自动告警和核心五个指标是否在 SLO 内日报要覆盖全部指标并且和前一日对比环比异常要给出原因周报的重点是指标趋势和待优化事项比如哪种任务类型的成功率在下降、哪个工具调用造成的成本占比过高。这里给一个 Grafana 告警规则配置的简单参考groups: - name: agent_sla_alerts rules: - alert: AgentTaskSuccessRateLow expr: | sum(rate(agent_task_success_total[5m])) / sum(rate(agent_task_total[5m])) 0.60 for: 5m labels: severity: P0 annotations: summary: Agent 任务成功率低于 60%这套看板最核心的价值是让所有角色对齐同一组数据。业务方说“Agent 不好用”研发可以直接打开看板问是哪个指标不好——是成功率掉到 50%还是 P95 时延到了 20 秒还是人工介入率太高数据一摆沟通成本立刻降下来后续的复盘和优化才能有据可循。5. 常见问题与排查技巧实录5.1 典型问题速查表现象大概率原因排查思路任务成功率整体下跌但基础设施无异常业务信息变化或 prompt 任务复杂度上升对比更新前后成功率分布检查是否近期有业务系统升级或 prompt 调整技术成功率正常但业务完成率偏低Agent“假成功”结果质量不合要求抽检失败样本归因重点检查意图识别和工具参数生成是否正确P95 时延突然飙高模型服务限流或工具调度串行阻塞拆分端到端耗时查询模型 API 配额和工具调用耗时单任务成本持续上涨重试次数增加或上下文膨胀检查重试率和 token 消耗明细确认是否有死循环或对话历史无限累计告警频繁但人工介入率没有下降告警阈值设置不贴合实际将告警阈值改为基于历史数据动态基准避免静态阈值误报我在实际运维中遇到最典型的一个问题是“任务成功率 99%但用户感知非常差”。追查下来发现成功率统计把系统兜底答案也算了进去很多复杂问题其实都走了兜底分支。后来我们改了统计口径把“走了兜底分支”的任务单独标记为降级完成再从成功率中剔除。改完之后数据立刻和用户体感对齐了。这个教训就是成功率的定义一定要和业务方反复确认特别是兜底分支到底算不算成功必须在口径里写死。另一个常见问题是“同一指标多个团队各报各的”。研发统计的成功率 95%业务方统计的只有 70%。原因往往是对“成功”的定义不一致研发以任务结束无异常为准业务方以用户是否得到有效回答为准。解决方法是设立全公司统一的指标口径字典写明每个指标的定义、计算公式、采集方式和判定标准并在新人入职时同步宣导。5.2 几个容易被忽视的细节第一个细节是重试逻辑要加次数上限和退避策略。Agent 出问题时会频繁重试如果不加限制不仅影响用户体验还会造成成本雪崩。我在生产环境给所有 Agent 步骤都设置了最多三次重试并且采用指数退避比如 1s、2s、4s超过后标记失败走兜底。第二个细节是高峰期要区分“首次调用成功率”和“重试后成功率”。有时候重试后的成功率很高看起来系统很健康但首次调用成功率已经很低了说明系统存在隐蔽的稳定性问题只是因为重试掩盖了。这个指标能帮你提前发现问题不用等故障真正扩大。第三个细节是人机协同指标要做“移交原因分类”。人工介入不能只统计次数还要记录为什么介入——是 Agent 超时、答错、还是用户主动要求转人工不分类你只知道出了问题不知道是哪一类问题。我见过一个团队优化了一个月人工介入率纹丝不动分类之后才发现真正的大头是用户主动要求转人工Agent 本身没问题方向一开始就错了。第四个细节是全链路压测要做“模型 API 超时恢复”演练。很多 Agent 只做了功能测试没有做依赖模型 API 限流后的降级测试。结果一上线真遇到限流整个服务就雪崩。建议在 SLO 体系跑通后每个月做一次注入式故障演练人为给模型 API 制造超时观察 Agent 的成功率、重试率和兜底逻辑是否符合预期。最后一个小心得指标体系上线后第一个月不要急着优化指标本身先打磨数据准确性。我见过太多团队第一周就大改 prompt结果数据还没对齐根本判断不了改动是正向还是负向。先把埋点、口径、采集、看板这四件事做扎实确保每个数字都能解释清楚、能溯源到明细再开始优化效率会高得多。 企业级Agent落地SLA指标体系构建指南
企业级 Agent 落地最难的往往不是把模型接进来跑通一个 demo而是你敢不敢对它承诺 SLA。我在过去一年多帮几家公司搭 Agent 平台听到最多的一句话是“Agent 效果不稳定没法上线”。但追下去问几乎没有一家能说清楚“不稳定”到底指什么——是响应慢是任务做错还是经常转圈不干活没有指标稳定性就只能靠感觉靠感觉的东西永远没法交付。这篇文章把我在企业级 Agent 项目里建立可量化 SLA 指标体系的完整思路、分层设计、计算公式和实操踩坑记录写出来给正在做 Agent 落地的团队一个可以直接抄作业的参考。1. 为什么企业级 Agent 必须先谈 SLA1.1 Agent 与传统系统的 SLA 有什么不同传统后端服务的 SLA 很成熟核心就是可用性、延迟、错误率四个九、五个九说清楚监控告警一套全齐。但 Agent 不是传统服务它最大的特点是不确定性同一个 prompt 在不同时间调用可能走完全不同的工具链路输出内容也可能有差异。这种不确定性直接导致传统 SLA 体系失效——你没法用一个简单的 HTTP 状态码判断一个 Agent 任务是否“成功”。传统 API 的成功率高不高看响应状态、看耗时分布就够了。但 Agent 多了一个“过程正确性”的维度它可能所有接口都调通了、也没报错但最后给的答案是错的也可能中间经历了三次重试、绕了很远的路但最终结果是对的。这两个场景在传统监控里都是“成功”在业务视角里质量天差地别。所以企业级 Agent 的 SLA 体系必须是立体的至少要覆盖三层基础设施层API 通不通、实例活不活、任务执行层步骤成不成、整体完不完成、业务结果层答案对不对、用户认不认。只有三层指标都有你才能对一个 Agent 服务做出可信的 SLA 承诺。我在内部培训时经常打一个比方传统 SLA 是给车装仪表盘看速度、油量、水温Agent 的 SLA 不但要看仪表盘还得看司机有没有把乘客送到正确的地方。1.2 不建指标体系的 Agent 项目都会踩哪些坑我见过太多 Agent 项目在 POC 阶段跑得很漂亮一上生产就崩复盘下来几乎都是同一个原因没有预先定义“什么叫做好”。没有指标大家就只能靠主观判断这时候一定出问题。第一个坑是出了问题说不清影响范围。生产环境 Agent 开始乱答业务方说“Agent 坏了”研发看资源占用率都是正常的双方扯皮半小时最后发现是上游模型 API 的限流策略变了导致 Agent 在高并发下降级成了空回复。如果当时有任务成功率趋势图这个问题两分钟内就能定位成功率从 98% 掉到 60%时间点和 API 配置变更完全吻合根本不用吵。第二个坑是优化没有方向。老板问“Agent 这个月表现怎么样”你如果只能回答“还行吧”那你就失去了话语权。反之如果你能拿出数据说“任务成功率 95%但金融场景的意图识别准确率只有 88%人工介入率偏高”老板就知道下一步该优化什么你也更容易争取资源。第三个坑是没法做容量和成本规划。Agent 的调用链比普通接口长得多一个任务可能触发几十次 LLM 调用token 消耗会呈指数级增长。没有成本指标月底账单出来就是惊吓。我见过一个团队上线一周光 API 费用就烧掉六位数原因就是重试逻辑没做上限控制。这些问题都不是技术上多难而是从一开始就没有把 SLA 指标当作交付物的一部分来设计。2. 指标体系怎么搭从可用性到业务价值的五层模型2.1 分层设计思路先能跑再跑快再跑对在给 Agent 设计体系时我习惯用“五层模型”来梳理基础设施层、性能层、任务执行层、质量层、成本层。这五层不是并列关系而是有依赖关系的漏斗——底层出问题上层必然受影响但底层全绿不代表上层一定健康。这个分层逻辑背后有一个很实际的考虑不同的人关心不同的层。运维关心基础设施层研发关心性能层和任务执行层产品关心质量层老板关心成本层和最终的业务效果。如果指标体系不分层把几十个指标平铺在一起每个角色都得自己去翻找关心的指标这个体系是落不了地的。分层之后还有一个附带好处当上层指标异常时你可以沿着漏斗逐层下钻系统性地排查问题出在哪里而不是像无头苍蝇一样到处看日志。五层的递进关系是这样的基础设施层健康Agent 才可能正常执行执行快用户体验才可能好执行成功率高质量才有可能保证质量稳定单位成本才可能可控。这里要特别提醒一点分层不是越细越好。我见过有人把“LLM 调用次数”“工具调用次数”都单拎出来建层结果一半指标没人看成了摆设。分层建到能支撑“告警定位 角色分工 优化决策”这三个目的就够了。2.2 每层指标选什么、怎么定义阈值基础设施层主要看三类指标Agent 服务实例的可用性进程活着、接口可响应、依赖模型 API 的可用性特别是模型调用是否被限流或返回异常、以及 wasm/插件/工具函数执行环境是否正常。这一层的阈值可以沿用传统 SRE 的标准核心服务要求 99.9% 以上辅助能力可以放宽到 99%。性能层需要关注两类时间一个是端到端时延也就是用户从发起到拿到最终结果的总时长另一个是过程时延包括首 Token 时间TTFT、工具调用耗时、重试等待耗时。阈值怎么定要看场景——客服类和 Copilot 类场景用户期望几秒内出结果后台自动处理类任务用户容忍度可以放宽到几十秒甚至分钟级。性能指标最大的坑是平均时延会骗人必须同时看 P95、P99 和最大耗时因为 Agent 任务的重试抖动非常严重平均值往往很漂亮但长尾用户已经被卡到崩溃。任务执行层是 Agent 特有的核心层核心指标包括任务成功率、分步成功率、重试率、死循环发生率。这里的“完成”定义需要产品和技术一起拍板而且必须区分“正常完成”和“通过兜底逻辑完成”——比如超时后走默认答案算不算成功不同业务定义不同但口径必须统一否则数据没法用。阈值建议比传统服务宽松一些初始版本任务成功率超过 85% 就属于可上线状态优化到 95% 以上就是成熟状态因为 LLM 的不确定性决定了很难做到 99% 以上的稳定。质量层的指标要回答“做完了活儿干得好不好”常用的有人工介入率、用户满意度、结果准确率需要标注或抽检。人工介入率是个很灵敏的信号如果超过 30%说明 Agent 的自动完成能力其实很弱本质还是个工单分发系统。成本层则要盯住每个任务的平均 token 消耗、单次 Agent 任务成本、成本/成功率比值。这两层的指标偏软往往需要业务系统配合采集我见过很多团队卡在这一步后面实操部分会展开讲。3. 核心指标的量化定义与计算公式3.1 可用性与性能指标怎么算可用性是最基础的指标熔断算不算故障要看具体约定。我通常用这个口径单次任务在 10 分钟内无法启动或执行中断无法恢复计为一次可用性故障。月度可用率的计算方法是当月可用分钟数除以当月总分钟数。举个例子某 Agent 服务月内发生了两次故障每次 30 分钟当月共 43200 分钟按 30 天算可用率就是 43200 减 60 除以 43200等于 99.86%。这个计算逻辑不复杂但计算口径要想清楚尤其要提前约定“计划内维护”是否扣除否则和客户对账的时候容易扯皮。性能层指标里端到端时延我建议直接取 P95。单次任务响应时间的 P95 计算方式是先把当月所有任务耗时排序取排在 95% 位置的那个值。比如 100 个任务里耗时的第 95 个值就是 P95。P95 比平均值稳健得多不容易被个别极慢请求带偏而且对用户体验更敏感。首 Token 时间TTFT在交互型 Agent 里也建议单列它的计算方法是从用户提交请求到流式响应输出第一个 Token 的时间间隔这个值如果超过 3 秒用户的体感就会非常差。3.2 任务成功率与质量指标怎么算任务成功率是整个体系里最核心的指标但它的定义也最容易产生歧义。我建议用“业务完成率”作为总指标同时把“技术成功率”当作辅助指标。业务完成率等于业务成功完成的 Agent 任务数占总任务数的比例判定标准是是否达到预设的业务目标技术成功率则只看 Agent 执行过程有没有发生未捕获的异常或未完成任务无论结果对不对。举个例子一个做报表分析的 Agent用户问“帮我统计上季度各区域销售额”Agent 成功调用数据库、成功生成图表但统计口径搞错了结果算错——这在业务完成率里是失败在技术成功率里却是成功。两个指标一起看才能识别“假成功”问题。分步成功率更详细是对 Agent 内部每个决策和工具调用步骤做评估。计算方式是统计所有任务在关键步骤上的成功执行次数除以总执行次数。比如一个任务要走三步理解意图、调用工具、生成答案中间任何一步失败整体就算部分失败。分步成功率的核心价值是帮定位瓶颈——如果总成功率低但分步成功率也低问题出在执行链路如果总成功率低但分步成功率挺高问题可能出在目标理解层而不是工具执行层。重试率则是一个辅助信号等于触发重试的任务数占总任务数的比例。超过 20% 就要注意了说明 Agent 的决策经常走到错误分支靠重试在硬撑。质量层的指标里人工介入率计算方式是人工接管 Agent 任务的次数除以总发起次数。满意度的口径我一般推荐用“不满意量占比”即用户主动打低分或投诉次数除以总完成次数——因为企业中主动打高分的用户很少只有差评才是有效信号。结果准确率在没有自动判定能力时可以用抽检的方式由业务专家按置信区间抽检一定比例的已完成任务抽检准确数除以抽检总数。3.3 成本指标怎么算成本是 Agent 落地中被低估最多的部分。单任务平均 token 耗用量等于当日总 token 消耗除以当日总任务数。总 token 消耗要区分输入、输出和缓存三种分别计费。我在实践里发现缓存命中率的优化空间非常大很多团队没有设计缓存策略导致重复的 system prompt 每次都在重新计费。计算时建议把 token 成本转换为单任务成本乘以对应模型单价即可比如某模型输入 0.003 元/千 token、输出 0.012 元/千 token一个任务消耗输入 20000 token、输出 4000 token单个任务成本就是 20000 除以 1000 乘以 0.003 加上 4000 除以 1000 乘以 0.012等于 0.108 元。这个数值要作为常态指标监控一旦单任务成本突然上涨往往意味着重试变多或上下文膨胀是系统劣化的早期信号。4. 实操落地埋点、SLO、看板与告警4.1 关键事件埋点怎么设计指标定义得再好埋点采不到数据也是白搭。Agent 的埋点一定不能在业务代码里到处手动加日志那样太容易漏。我的做法是在 Agent 执行框架里做一层统一的“运行时事件总线”把 Agent 生命周期中的关键节点都作为结构化事件广播出来再统一采集。关键节点我一般定义成四类任务开始、任务结束、步骤完成、步骤失败。任务开始事件至少要带 task_id、session_id、用户所属业务线、目标描述摘要任务结束事件必须带最终状态成功、失败、人工接管、超时、兜底标记、耗时步骤事件要带步骤类型意图识别、工具调用、生成回复、工具名、输入摘要、输出摘要、耗时、是否重试。所有事件统一走事件总线由采集端聚合落库。这里要特别强调给任务带全局唯一 task_id 的重要性。Agent 链路长日志散落在多个服务和调用里没有统一的 task_id排查问题就要用时间加关键词去猜非常痛苦。我习惯在入口网关处生成 task_id然后塞进上下文对象一路透传所有子调用、事件都带上它。这和后端 trace_id 的思路一样但很多人做 Agent 的时候会忽略等出问题了再回头补成本就大了。数据存储上指标类和明细类要分开。明细事件存 Elasticsearch 一类支持全文检索的引擎用于问题排查指标聚合数据存 Prometheus用于告警和绘制趋势。链路数据如果预算够可以接 Jaeger 这类链路追踪系统但至少要保证事件流里有完整的上下文关联。伪代码层面事件采集大概长这样# 统一的 Agent 事件采集示例 import json, time def emit_agent_event(event_type, task_id, payload): event { event_type: event_type, # task_start / task_end / step_done / step_fail task_id: task_id, ts: time.time(), payload: payload } # 异步发送到消息队列或直接写日志避免阻塞 Agent 主流程 kafka_producer.send(agent_events, json.dumps(event))埋点层还有一个非常容易被忽视的点不要在 Agent 主流程里同步打点。阻塞、超时都会反过来影响性能和成功率所有的埋点都应该异步发送或者直接写入本地磁盘由 Agent 采集。我在项目里遇到过因为日志同步写导致 Agent 性能劣化的案例后来把发送改成异步批量后才消除。4.2 SLO 设定与告警分级指标有了下一步就是设定 SLO服务等级目标并把告警分级。我强烈建议不要给所有指标设一条阈值的单一告警那样告警疲劳会拖垮团队。告警我通常分三级P0紧急、P1严重、P2提示。P0 是直接影响业务可用性的比如技术成功率低于 60% 持续 5 分钟、模型 API 大规模返回异常导致可用性跌破 99%P0 必须电话或 IM 强提醒要求 15 分钟内响应。P1 代表服务质量劣化比如 P95 时延超过基准线 2 倍、人工介入率连续 2 小时超过 40%P1 可以走 IM 告警要求 30 分钟内响应。P2 则属于趋势性预警比如单任务成本开始抬头、重试率超过 15%这种不需要立刻处理但要在日报里体现。SLO 的基准线怎么定如果没有历史数据第一阶段先观察两到四周把当前实际水平测出来然后在“实际值”和“业务可接受值”之间取一个偏保守的目标——注意是保守不要一开始就定很高。比如当前成功率 90%业务要求 95%第一阶段的 SLO 可以先定 92%跑通告警和复盘机制后再逐步拉高。一开始就定 95% 的话会陷入频繁告警但大家又处理不过来的尴尬。4.3 看板示例与巡检节奏看板不用做得花哨但布局逻辑要跟五层模型对应起来。我通常会在 Grafana 里建四行第一行放基础设施和性能的实时状态第二行放任务成功率、分步成功率、重试率第三行放人工介入率、满意度、抽检准确率第四行放成本趋势。每一行都支持点击下钻到明细这是排查效率的关键。巡检节奏上建议建立“小时巡检 日报 周报”的结构。小时巡检只需要看自动告警和核心五个指标是否在 SLO 内日报要覆盖全部指标并且和前一日对比环比异常要给出原因周报的重点是指标趋势和待优化事项比如哪种任务类型的成功率在下降、哪个工具调用造成的成本占比过高。这里给一个 Grafana 告警规则配置的简单参考groups: - name: agent_sla_alerts rules: - alert: AgentTaskSuccessRateLow expr: | sum(rate(agent_task_success_total[5m])) / sum(rate(agent_task_total[5m])) 0.60 for: 5m labels: severity: P0 annotations: summary: Agent 任务成功率低于 60%这套看板最核心的价值是让所有角色对齐同一组数据。业务方说“Agent 不好用”研发可以直接打开看板问是哪个指标不好——是成功率掉到 50%还是 P95 时延到了 20 秒还是人工介入率太高数据一摆沟通成本立刻降下来后续的复盘和优化才能有据可循。5. 常见问题与排查技巧实录5.1 典型问题速查表现象大概率原因排查思路任务成功率整体下跌但基础设施无异常业务信息变化或 prompt 任务复杂度上升对比更新前后成功率分布检查是否近期有业务系统升级或 prompt 调整技术成功率正常但业务完成率偏低Agent“假成功”结果质量不合要求抽检失败样本归因重点检查意图识别和工具参数生成是否正确P95 时延突然飙高模型服务限流或工具调度串行阻塞拆分端到端耗时查询模型 API 配额和工具调用耗时单任务成本持续上涨重试次数增加或上下文膨胀检查重试率和 token 消耗明细确认是否有死循环或对话历史无限累计告警频繁但人工介入率没有下降告警阈值设置不贴合实际将告警阈值改为基于历史数据动态基准避免静态阈值误报我在实际运维中遇到最典型的一个问题是“任务成功率 99%但用户感知非常差”。追查下来发现成功率统计把系统兜底答案也算了进去很多复杂问题其实都走了兜底分支。后来我们改了统计口径把“走了兜底分支”的任务单独标记为降级完成再从成功率中剔除。改完之后数据立刻和用户体感对齐了。这个教训就是成功率的定义一定要和业务方反复确认特别是兜底分支到底算不算成功必须在口径里写死。另一个常见问题是“同一指标多个团队各报各的”。研发统计的成功率 95%业务方统计的只有 70%。原因往往是对“成功”的定义不一致研发以任务结束无异常为准业务方以用户是否得到有效回答为准。解决方法是设立全公司统一的指标口径字典写明每个指标的定义、计算公式、采集方式和判定标准并在新人入职时同步宣导。5.2 几个容易被忽视的细节第一个细节是重试逻辑要加次数上限和退避策略。Agent 出问题时会频繁重试如果不加限制不仅影响用户体验还会造成成本雪崩。我在生产环境给所有 Agent 步骤都设置了最多三次重试并且采用指数退避比如 1s、2s、4s超过后标记失败走兜底。第二个细节是高峰期要区分“首次调用成功率”和“重试后成功率”。有时候重试后的成功率很高看起来系统很健康但首次调用成功率已经很低了说明系统存在隐蔽的稳定性问题只是因为重试掩盖了。这个指标能帮你提前发现问题不用等故障真正扩大。第三个细节是人机协同指标要做“移交原因分类”。人工介入不能只统计次数还要记录为什么介入——是 Agent 超时、答错、还是用户主动要求转人工不分类你只知道出了问题不知道是哪一类问题。我见过一个团队优化了一个月人工介入率纹丝不动分类之后才发现真正的大头是用户主动要求转人工Agent 本身没问题方向一开始就错了。第四个细节是全链路压测要做“模型 API 超时恢复”演练。很多 Agent 只做了功能测试没有做依赖模型 API 限流后的降级测试。结果一上线真遇到限流整个服务就雪崩。建议在 SLO 体系跑通后每个月做一次注入式故障演练人为给模型 API 制造超时观察 Agent 的成功率、重试率和兜底逻辑是否符合预期。最后一个小心得指标体系上线后第一个月不要急着优化指标本身先打磨数据准确性。我见过太多团队第一周就大改 prompt结果数据还没对齐根本判断不了改动是正向还是负向。先把埋点、口径、采集、看板这四件事做扎实确保每个数字都能解释清楚、能溯源到明细再开始优化效率会高得多。