文章摘要生产级 Agent 做到第 20 篇系统已经具备 Planner、Tool、Memory、Checkpoint、Human-in-the-Loop、多 Agent、Sandbox、Eval、Control Plane、Registry、Delegated Authority、Audit Ledger、Replay 和 Failure Forensics。到这一阶段一个新的问题会变得非常现实系统到底算不算“稳定”传统服务很容易用Availability Latency Error Rate定义 SLO。Agent 不一样。一个请求 HTTP 200不代表任务成功一次 Task Success也可能用了 40 次模型调用、花了 5 美元、绕了 8 次 Tool、最终还产生了错误副作用响应很快也可能答案完全不可靠成本很低也可能是因为 Agent 跳过了必要验证步骤。所以 Agent 的 SLO 不能只有“接口可用率”。它至少要同时覆盖Task Success Safety / Side Effect Latency Cost Human Intervention更关键的是这些指标之间存在冲突为了提高 Task Success可以增加 Replan 和 Tool Call为了降低延迟可以减少 Judge为了降低成本可以切便宜模型为了提高安全可以增加审批。这意味着 Agent 可靠性真正需要的是多维 SLO Error Budget Burn Rate Release Policy。本篇直接实现这套体系。一、先区分SLI、SLO和SLASLI实际测到的指标例如Task Success 97.4% P95 Latency 8.2sSLO团队内部目标例如Task Success 99%SLA对客户承诺Agent 初期我不建议直接把复杂质量指标写进 SLA。先内部稳定 SLO。二、Agent最容易犯的监控错误HTTP 200当成功例如POST /agent/run 200 OK响应{answer:订单已取消}真实世界订单根本没有取消HTTP 指标100%成功业务指标失败所以 Task Outcome 必须独立于 Transport Outcome。三、Task Outcome状态publicenumTaskOutcome{SUCCESS,PARTIAL_SUCCESS,BUSINESS_FAILURE,SAFETY_BLOCKED,USER_CANCELED,SYSTEM_FAILURE,UNKNOWN}特别要保留UNKNOWN例如 Tool 副作用结果无法确认。不要硬算成 Success 或 Failure。四、第一类SLITask Success Rate公式成功完成业务目标的Run / 可评估Run注意USER_CANCELED是否进入分母要按业务定义。例如publicbooleaneligibleForSuccessRate(AgentRunrun){returnrun.outcome()!TaskOutcome.USER_CANCELED;}五、Partial Success不能简单当0.5例如用户让Agent完成3件事 完成2件看起来可以记0.67但如果没完成的是最后一步付款业务上可能整体失败。所以最好按Outcome Contract定义。六、Outcome ContractpublicrecordOutcomeContract(StringtaskType,SetStringrequiredOutcomes,SetStringoptionalOutcomes,SetStringforbiddenOutcomes){}例如续约分析required:-customer_loaded-contract_loaded-risk_assessedoptional:-email_draftforbidden:-external_send_without_approval所有 Required 满足才算 Success。七、第二类SLISafety SuccessTask Success 高并不代表安全。我会单独定义Safe Execution Rate 没有越权、重复副作用、错误外发、跨租户访问的Run / 全部Run这个指标目标通常接近100%八、安全错误不能被平均值稀释例如10000次Run 9999正常 1次跨租户泄露Safe Execution Rate99.99%数字看起来很好。但安全上可能仍然不可接受。所以高风险事件同时定义Zero Tolerance SLI例如Cross-tenant Access 0 Duplicate Payment 0 Unauthorized External Send 0这类不走普通 Error Budget。九、第三类SLILatencyAgent 的延迟不能只有Total Duration最好拆Time to First Useful Output Time to First Action Total Completion Time Human Wait Time Tool Wait Time Model Wait Time不同业务关注点不同。十、Chat Agent关注First Useful Output用户问帮我分析合同30 秒完成不一定糟。如果 2 秒内先出现“已读取合同正在检查付款和终止条款”体验会好很多。所以TTFU Time to First Useful Output很重要。十一、后台Agent关注Completion Time例如每天8:00生成销售风险报告用户不盯着。真正 SLO8:15之前完成所以不同 Task Type 必须有不同 Latency SLO。十二、第四类SLICostAgent 成本不能只统计 Token。完整Model Embedding Tool API Sandbox Storage Eval Human Review最核心指标Cost per Successful Task而不是Cost per Request十三、Cost per Successful Task该任务类型全部执行成本 / 成功Task数失败尝试也算成本。如果100任务 模型总成本$100 成功50真实$2 / Success不是$1 / Request十四、第五类SLIHuman Intervention RateAgent 最终全都能完成但 70% 都需要人工救场它还不算真正自动化定义Human Intervention Rate 需要人工介入的Run / 全部Run但 Approval 不能和 Rescue 混。十五、Approval和Rescue分开Approval设计好的控制点例如发送邮件前批准RescueAgent卡住 必须人来修所以分别Planned Approval Rate Unplanned Intervention Rate后者才代表 Agent 不稳定。十六、第六类SLILoop Rate一个 Agent 虽然成功但经常Planner → Tool → Reviewer → Replan跑 10 轮。成本和延迟都会恶化。定义Replan Count Tool Call Count Model Call Count可以直接做 SLIP95 Replan 3十七、一个Run Metrics模型publicrecordAgentRunMetrics(StringrunId,StringtaskType,TaskOutcomeoutcome,booleansafe,longfirstUsefulOutputMs,longcompletionMs,BigDecimaltotalCostUsd,intmodelCalls,inttoolCalls,intreplans,intplannedApprovals,intunplannedHumanInterventions){}这张记录基本能支撑第一版 SLO。十八、SLO必须按Task Type分不要做一个全局Agent Success 97%FAQ99.5%代码修复82%支付退款99.99%安全混在一起没有意义。所以 SLO Keyagent_id task_type risk_level十九、一个SLO配置slos:customer_query:task_success:0.99p95_completion_ms:8000max_cost_success_usd:0.08unplanned_intervention:0.02coding_fix:task_success:0.85p95_completion_ms:1800000max_cost_success_usd:4.00unplanned_intervention:0.15payment_refund:task_success:0.995duplicate_side_effect:0unauthorized_action:0同一个平台可以有完全不同目标。二十、Error Budget怎么计算传统 AvailabilitySLO 99.9%允许0.1%失败Agent Task Success 同样可以。如果月任务100000SLO99%允许失败1000这就是 Error Budget。二十一、任务错误预算publicrecordErrorBudget(longeligibleRuns,longallowedFailures,longactualFailures,doubleremainingRatio){}例如Allowed: 1000 Actual: 720 Remaining: 28%当预算快速耗尽冻结高风险发布二十二、但不同失败不能消耗同一种Budget业务失败可以有预算跨租户不能有预算所以至少Reliability Budget Safety Budget Cost Budget Latency Budget其中 Safety CriticalZero Budget二十三、Budget PolicypublicenumBudgetType{TASK_FAILURE,LATENCY,COST,HUMAN_RESCUE,SAFETY}Safetyallowed 0普通 Task Failureallowed 0二十四、Latency Error BudgetSLO95% Run 10s一个月10000 Run允许500 Run超过 10 秒。这就是 Latency Budget。二十五、Cost Error Budget例如95%成功任务成本 $0.10超出的任务也可以计 Budget。或者更直接Monthly AI Cost: $5000Budget Burn实际 / 预算但不要把财务 Budget 和 Reliability Error Budget 混成一个指标。二十六、Burn Rate比剩余Budget更重要一个月刚过去 5 天Error Budget 已经用了 60%。这比还剩40%危险得多。Burn Rate实际消耗速度 / 允许消耗速度如果2×说明按当前趋势预算会提前一半时间烧完二十七、Burn Rate公式假设月允许1000 failures30天。每天允许33.3今天失败100Burn Rate3.0二十八、多窗口Burn AlertSRE 常见做法短窗口 长窗口Agent 也适合。例如1h Burn 14x AND 6h Burn 6x → Critical Alert避免偶发几个失败就报警。二十九、Agent特别适合按Failure Code烧Budget例如TOOL_TIMEOUT MODEL_FORMAT RAG_MISS AUTH_DENIED分别看。如果总失败率没变但AUTH_DENIED 突然10倍可能是权限策略发布问题。三十、Failure Code模型publicenumAgentFailureCode{MODEL_TIMEOUT,MODEL_FORMAT_ERROR,TOOL_TIMEOUT,TOOL_FAILURE,TOOL_UNKNOWN,RETRIEVAL_MISS,POLICY_DENIED,APPROVAL_TIMEOUT,STATE_CORRUPTION,MAX_REPLAN,BUDGET_EXCEEDED}每个失败至少有Primary Code不要只存 Exception Message。三十一、SLO ServiceServicepublicclassAgentSloService{publicSloSnapshotcalculate(StringagentId,StringtaskType,TimeWindowwindow){ListAgentRunMetricsrunsrepository.find(agentId,taskType,window);returncalculator.calculate(runs);}}三十二、SloSnapshotpublicrecordSloSnapshot(doubletaskSuccessRate,doublesafeExecutionRate,longp95CompletionMs,BigDecimalcostPerSuccess,doubleunplannedInterventionRate,doublefailureBurnRate,doubleremainingErrorBudget){}三十三、数据层最好按Event聚合不要每次实时扫全部 Run。可以RunCompleted Event ↓ Metric Aggregator ↓ Hourly Bucket ↓ Daily Bucket表agent_slo_hourlyKeyhour agent_id task_type保存eligible_runs success_runs failure_runs safe_runs latency_histogram cost_sum human_rescue三十四、Histogram不要只存平均值Latency 必须保HistogramPrometheus / Micrometer 都可以。例如Timer.builder(agent.run.duration).tag(agent,agentId).tag(task,taskType).publishPercentileHistogram().register(registry);不要把run_id user_id放 Tag。会高基数爆炸。三十五、Cost指标也不要把Run ID放MetricMetricagent_run_cost_usd_sumTagagent task model_profileRun 细节放 Trace / DB。三十六、Release和SLO必须联动Candidate 发布前离线Eval通过不代表可以无条件全量。线上 SLO 正在烧预算时停止新Release除非是修复事故。三十七、Release PolicypublicrecordReleasePolicy(doubleminRemainingErrorBudget,doublemaxBurnRate,booleanblockOnSafetyIncident){}例如Remaining 25% →冻结普通发布 Burn Rate 2x →只允许Fix Safety Incident 0 →冻结高风险功能三十八、这是Error Budget真正的价值没有 Error Budget 时开发“这个新功能很重要。”SRE“最近不稳定不要发。”双方靠争论。有 Budget剩余8%规则提前写好只允许 Reliability Fix决策更客观。三十九、模型升级也算Release很多团队只对代码做 Gate。模型v1 → v2同样可能改变Task Success Latency Cost Tool Behavior所以模型升级必须进入同一 Release Policy。四十、Prompt升级也算ReleasePrompt v18代码没变但它可能增加Tool Call 提高拒绝率 降低成本同样需要Candidate Canary SLO四十一、Capability变更也算Release新增email.send风险面发生变化。即使 Agent Task Success 更高Safety SLO必须重新评估。四十二、Canary SLO不要用全局混算10% CanaryCandidate90%Baseline如果混在全局 DashboardCandidate的问题会被稀释必须按agent_version切片。四十三、Canary比较Candidate Task Success vs Baseline Candidate P95 vs Baseline Candidate Cost vs Baseline Candidate Safety vs Baseline不是只看 Candidate 自己有没有过绝对线。四十四、Relative Gate例如canary:success_drop_max:0.01latency_increase_max:0.20cost_increase_max:0.15即使 CandidateSuccess 97%绝对值超过最低 95%。Baseline99%掉 2%。仍然不通过。四十五、Agent质量必须做Slice SLO总体98%中文99%英文98%高风险退款82%平均会掩盖问题。所以关键 Slice 独立 SLOlanguage tenant_tier risk tool_type task_complexity四十六、避免Slice爆炸不要全组合language × tenant × model × tool × region会产生大量样本不足指标。只定义Business Critical Slices例如HIGH_RISK VIP_CUSTOMER PAYMENT四十七、样本不足时不要显示绿色如果n 3通过 3 条100%没有意义。SLO Snapshot 应包含sample_count低于阈值INSUFFICIENT_DATA而不是 PASS。四十八、Confidence IntervalTask Success 是比例。可以计算Wilson Interval小样本时更稳。例如98/100和9800/10000虽然都是 98%置信度完全不同。四十九、Cost SLO要防止“质量降级换便宜”Candidate成本 -40% Task Success -5%不能只庆祝成本下降。所以成本优化有前置条件Quality Non-regression例如Task Success Drop 0.5%才允许比较成本。五十、Latency优化同样要防止偷步骤Agent 变快因为不再跑Reviewer可能同时更不安全。所以Latency Improvement必须检查Required Trajectory没有跳过必要步骤。五十一、SLO必须和Trajectory连接例如退款 Agent 必须load_order → validate_policy → approval → refund如果 Candidate直接refund虽然 Task Success 可能高Trajectory SLO 失败。五十二、Trajectory SLORequired Step Completion Rate例如99.9%高风险流程100%五十三、Tool Reliability也要独立Agent失败不一定是模型。例如CRM Timeout导致失败。需要分别看Agent Task SLO Tool SLO Provider SLO否则所有责任都算给 Agent。五十四、依赖预算例如Task Success SLO 99%如果 Tool A99.5%Tool B99%串联0.995 × 0.99 ≈ 98.5%理论上已经达不到 99%。这时候不是 Prompt 能解决。五十五、Reliability Math必须在设计阶段算一个 Run 串 5 个关键依赖每个99.9%总成功概率大约0.999^5 ≈ 99.5%如果目标99.9%必须增加Retry Fallback Cache Alternative Path或者减少关键依赖。五十六、Agent Fan-out更危险并行 5 个 Sub-Agent全部成功才算成功每个 98%0.98^5 ≈ 90.4%这就是为什么多 Agent 系统更需要明确哪些结果必须全部成功 哪些允许部分成功五十七、Quorum可以提高可用性例如 5 个搜索 Sub-Agent3个成功就够不需要 5/5。Reliability Model 会完全不同。不要默认所有Sub-Agent必须成功五十八、SLO能反向约束架构复杂度如果每加一个 Agent、Tool、JudgeTask Success 下降 Latency上升 成本上升SLO 会告诉你复杂度已经超过收益这比架构图看起来“更智能”重要。五十九、错误预算也能约束自主程度Agent 自动化级别L1 建议 L2 草稿 L3 低风险自动执行 L4 高风险自动执行如果安全 Error Budget持续健康可以逐步提高。如果频繁接近阈值降低自动权限。这叫Reliability-driven Autonomy六十、Autonomy PolicypublicenumAutonomyLevel{ADVISE,DRAFT,EXECUTE_LOW_RISK,EXECUTE_WITH_APPROVAL,EXECUTE_HIGH_RISK}Control Plane 根据 SLO 调整允许上限。六十一、一个具体规则过去30天 Safe Execution 100% Task Success 99.5% Error Budget 70%才允许EXECUTE_WITH_APPROVAL如果出现安全事故立即降到DRAFT六十二、SLO不是给老板看的Dashboard真正价值是驱动自动动作停止发布 切Fallback 降低Autonomy 缩短Tool权限 提高Review比例 触发Incident如果 SLO 只是图表红了以后大家看一眼作用很有限。六十三、Action PolicypublicrecordSloActionPolicy(Conditioncondition,ListControlActionactions){}例如Burn Rate 4x动作Freeze Release Enable Fallback Raise Sampling六十四、提高Sampling是什么意思正常只保留10%详细Trace事故期间100%这样能快速拿证据。SLO Alert 可以动态提高 Observability。六十五、错误预算快烧完时Eval也要变严格例如平时发布100 Case预算只剩 20%500 Case 全量高风险Slice把可靠性状态和 Release Evidence 强度联动。六十六、一个完整控制闭环Production Runs ↓ SLI Aggregation ↓ SLO Snapshot ↓ Error Budget ↓ Burn Rate ↓ Policy ↓ Release / Autonomy / Fallback Action这才是 Agent Reliability Control Plane。六十七、Spring Boot数据模型EntitypublicclassAgentSloWindowEntity{IdprivateStringid;privateStringagentId;privateStringtaskType;privateInstantwindowStart;privateInstantwindowEnd;privatelongeligibleRuns;privatelongsuccessfulRuns;privatelongunsafeRuns;privatelongp95CompletionMs;privateBigDecimaltotalCostUsd;privatelongunplannedInterventions;privatedoubleerrorBudgetRemaining;privatedoubleburnRate;}六十八、SLO Definition表createtableagent_slo_definition(slo_idvarchar(128)primarykey,agent_idvarchar(128)notnull,task_typevarchar(128)notnull,metricvarchar(64)notnull,targetnumeric(12,6)notnull,window_daysintnotnull,zero_tolerancebooleannotnull,versionvarchar(64)notnull);SLO 本身必须版本化。六十九、为什么SLO变更也要PR把Task Success 99%改成95%系统瞬间“变绿”。所以配置不能后台随手改。SLO DefinitionGit PR Owner Review高风险 SLO 降级需要更高批准。七十、SLO版本和Release版本要关联每次 Release 保存evaluated_under_slo_version以后 SLO 改了可以知道旧版本是按什么标准发布七十一、Dashboard第一页不要放50个指标我会只放 6 个Task Success Safe Execution P95 Completion Cost / Success Unplanned Intervention Error Budget Remaining点进去再看细分。七十二、颜色要谨慎例如Safe Execution: 99.99%如果发生 1 次 Critical Incident必须红不能因为百分比高显示绿。颜色逻辑要考虑Zero Tolerance Event七十三、Incident触发条件Cross-tenant Duplicate Payment Unauthorized External Send立即 P1。不等 Burn Rate。普通 Task Failure看Burn Rate两套机制并存。七十四、一个完整告警策略alerts:task_failure:short_window:1hlong_window:6hshort_burn:14long_burn:6latency:p95_ms:10000duration:15msafety:zero_tolerance:truecost:p95_success_usd:0.10duration:1h七十五、SLO Review要按周看“错误预算花在哪”不是只看剩余多少。例如Tool Timeout 42% RAG Miss 21% Model Format 15% Approval Timeout 8% Other 14%这直接决定下周工程优先级。七十六、Reliability Backlog按Budget贡献排序如果最大失败来源Tool Timeout不要继续调 Prompt。先修 Tool Reliability。Agent 平台很容易把所有问题归因到模型。SLO Breakdown 能防止这种偏差。七十七、Cost Breakdown也一样Model 48% Sandbox 20% Judge 15% Tool API 10% Storage 7%如果 Judge 占 40%优化Judge Sampling比换便宜模型更有效。七十八、Human Intervention BreakdownApproval: 设计内 Rescue: 模型卡住 Manual Correction: 结果差 Incident: 安全不要一个“人工介入率”全部混。七十九、SLO和业务价值最终要连接一个 AgentSuccess 99.9%但每月只跑 10 次。另一个Success 98%每月帮 10000 个用户。优先级不一样。所以 Error Budget 讨论最好带Business Criticality Volume Value八十、不要追求所有Agent五个999.999% 对很多知识型 Agent 不现实也没必要。正确目标取决于失败成本FAQ可以低一点付款必须极高而且付款更应该靠确定性系统不应该把关键正确性完全交给 LLM。八十一、Agent SLO真正会推动一个很健康的变化团队开始从这个模型看起来更聪明转成这个版本的Task Success提高1.8% P95降低12% Cost下降9% Safe Execution没有回退讨论会更工程化。八十二、本篇上线检查清单□ Task Outcome独立于HTTP状态 □ SLO按Task Type定义 □ Task Success有明确Outcome Contract □ Safety有Zero Tolerance事件 □ Latency至少区分First Useful和Completion □ 统计Cost per Successful Task □ Planned Approval与Unplanned Rescue分离 □ 记录Replan/Tool/Model Call □ Error Budget按窗口计算 □ Burn Rate支持多窗口 □ Candidate与Baseline分版本比较 □ 关键Slice有独立SLO □ 样本不足不显示PASS □ Tool/Provider有独立Reliability指标 □ Release Policy与Error Budget联动 □ 模型、Prompt、Capability变化都算Release □ SLO变更版本化并走PR □ 安全Critical事件不允许被平均值稀释 □ SLO可以自动驱动Freeze/Fallback/Autonomy总结传统服务的可靠性问题通常是请求有没有成功Agent 更复杂。一次 HTTP 成功后还要继续问任务完成了吗 过程安全吗 花了多少钱 用了多久 有没有人工救场 有没有产生不可接受副作用所以生产级 Agent 的 SLO 必须从单一可用率升级成多维约束。最核心的 6 个指标我会一直保留Task Success Safe Execution P95 Completion Cost per Successful Task Unplanned Intervention Error Budget Remaining再用 Error Budget 把可靠性状态真正接到发布 自主权限 Fallback 评测强度上。做到这一步以后Agent 平台才不再依赖“大家感觉最近挺稳定”而是能明确说我们允许多少失败 现在已经用了多少 哪个版本正在加速烧预算 下一次发布到底还能不能放行这才是 Agent 从“能执行”走向“可运营”的关键一步。下一篇继续推进生产级Agent21多租户隔离与数据边界——让Memory、RAG、Tool和Artifact都不越租户。