藏书第一次有专篇讲「准确率之外的上线门槛」。两个可直接抄走的工件：退款 Agent 的 SLO 模板（功能/可靠/安全/延迟/成本/防失控一组门槛，硬软门禁混合，阈值从业务反推）和防失控的故障注入测法（喂无解任务、让工具持续报错、诱发派生爆炸）。「内层没超、外层失控」那笔账，是单层限步数团队最容易栽的坑。
先修：a19（实战 02 harness Control 面）与 a20（实战 03 loop engineering）——本篇的「两层失控」正是那对概念在评测上的落地；配 a24（实战 16 统计严谨性）读「看尾部」的方法论基础。准备给 Agent 定上线标准的团队，第五节的 SLO 模板直接抄；已经有限速/限步护栏的，用第三节自查「外层缰绳」是不是忘了设。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
平均成功率掩盖分布：一个每次稳定在 90% 水平，另一个一半 100%、一半 80%——后者「飘」，生产上无法预期任何一次的表现。要用 pass^k（多次试验全过的比例）从可靠性视角测，它是独立于准确率的一维。
典型场景：一个因上游 bug 永远失败的任务，外层循环每天重试——单次只花 $0.3、只跑 5 步，内层缰绳（步数上限、单次成本）全合规；但跑一年累计烧几百刀、长期占着队列。单次运行的评测天然看不到跨多次运行的累积与重试，必须在外层专门评「有没有对反复失败的任务无限重试」，缰绳是重试上限、总预算、派生深度。
不上线。死循环是零容忍硬红线，一票否决；就算没有死循环，P95 破线也得先把延迟压回去。SLO 的意义就是防止「准确率涨 2 个点」掩盖「延迟崩了、还带个死循环」——任何一条硬红线破了，准确率的进步都救不了。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
到这里，我们花了大量篇幅在测「对不对」——任务完成、工具调用、事实性、安全。但有一整类维度，同样致命、却常被忽略：非功能维度——成本、延迟、稳定性、防失控。
这一讲的核心，一句话：一个又对又安全、但慢、贵、飘、还停不下来的 Agent，照样不能上线。非功能维度不是「锦上添花」，是和准确率并列的上线硬门槛。
举个例子你就懂了。假设你的退款 Agent 准确率高达 99%——听起来该上线了吧？但如果它：
这个「99% 准确」的 Agent，一个都上不了线。准确率高，从来不等于能上线。这些非功能维度，对应第 5 讲全景图里「安全与成本」那一维——它们和「任务完成」是并排的门槛，任何一个不过关，其余再好也白搭。
一、成本（cost）。单次任务烧多少 token、多少钱。关键是看分布、尤其尾部（第 16 讲）——平均便宜没用，如果偶尔有一次失控烧掉 100 倍，那才是要命的。还要拆清楚成本花在哪：多步推理本身、每步的工具调用、以及——别忘了——评测/裁判自己的开销（第 22 讲线上跑 LLM 裁判也烧钱）。成本失控最常见的诱因是「步数暴涨」：一个本该 5 步的任务跑了 50 步，token 就是 10 倍。
二、延迟（latency）。端到端响应时间。Agent 是多步的，延迟天然比单轮模型高得多。而且要看尾延迟（P95 / P99），不是平均——用户体验是由「最慢的那部分请求」决定的，平均延迟很好看、但每 20 个用户就有 1 个等了半分钟，照样是灾难。还有一点：别用「首字延迟」掩盖「完成延迟」——流式输出能缓解等待感，但对会动手的 Agent，用户真正等的是任务办完，不是第一个字蹦出来。
三、稳定性 / 可靠性（stability）。同一个任务多次跑，结果一致吗？这正是第 7、16 讲的 pass^k——可靠性视角：不是「平均能做到」，而是「稳不稳定地做到」。飘，就是不可靠；对生产系统，飘本身就是一种失败。
这里有个反直觉但重要的点：两个 Agent 平均成功率都是 90%，可靠性可能天差地别。一个是「每次都稳定在 90% 水平」，另一个是「一半时候 100%、一半时候 80%」——后者飘得多，对生产更危险，因为你没法预期任何一次的表现。平均成功率看不出这个差别，pass^k 才能。所以稳定性是独立于准确率的一维，必须单独测。
四、防失控（runaway）。Agent「停不下来」或「越滚越大」，具体有几种形态：死循环（反复调同一个工具原地打转）、步数失控（一个简单任务跑了几十上百步）、无限重试（对一个永远失败的任务反复重试）、成本雪球（派生子 agent 指数膨胀、或累积开销失控）。这是 Agent 特有的、单轮模型根本没有的风险——单轮模型答完就结束，不会「自己把自己卷进去」。它也是这一讲里唯一「零容忍」的一类：其他指标可以谈「多少算够」，失控只能是「绝不允许」。
| 指标 | 怎么量 | 从哪读 |
|---|---|---|
| 成本 | 单次 token / 金额（看分布 + 尾部） | trace（第 21 讲） |
| 延迟 | 端到端耗时（看 P95 / P99） | trace |
| 稳定性 | 多次跑的一致性（pass^k） | 多次 trial（第 16 讲） |
| 防失控 | 步数 / 重试 / 累积成本是否越界 | trace + 预算断言 |
这些指标有个共同的好处：几乎全是客观、确定的数字，能直接从 trace 读、用代码型评分器算（第 12、21 讲），不用 LLM 裁判。非功能评测，是所有评测里最「硬核可算」的一类。
你可能会说：成本、延迟，传统的 APM（应用性能监控）不早就有了吗？对，但 Agent 多了两样传统监控没有的东西：
所以别以为「我们有 APM 就够了」——Agent 的非功能评测，是在传统监控之上，加了「步数」和「防失控」这两层专门针对循环的关注。
标题里的「循环健康度」，其实跨了两个层次——这正是第 2、3 讲那对 harness / loop 的区分在评测上的落地：
内层：单次运行的失控（harness 的 Control 面，第 2 讲）。一次 Agent 运行内部的失控：陷入死循环反复调同一个工具、步数无限增长、单次运行超时。对应的「缰绳」是 harness 的 Control 面——步数上限、超时、单次成本天花板。
外层：自驱循环的失控（loop engineering，第 3 讲）。跨多次运行的失控：对一个永远失败的任务无限重试、派生子 agent 时指数级膨胀、一整天的累积成本滚雪球。对应的「缰绳」是外层循环的护栏——重试上限、总预算、派生深度限制。
两层都要设缰绳、都要评「缰绳有没有真的勒住」。一个常见的疏忽是只管了内层（单次限了步数）、却忘了外层。
举个外层失控的账：一个订单因上游 bug 永远失败，外层循环每天重试它，单次只花 $0.3、只跑 5 步——每次单看都合规，内层缰绳一点没超。但它天天重试、跑了一年，累计烧掉几百刀、还长期占着处理队列。这就是典型的「内层没超、外层失控」——单次评测永远抓不到它，必须在外层专门评「有没有对一个反复失败的任务无限重试」。评非功能，两层都得盯。
方法上，非功能评测比前面几讲都简单——因为它客观：
从 trace 直接读（第 21 讲）：成本、延迟、步数都是 trace 里现成的数字，不需要判断。
看分布，别看平均（第 16 讲）：这是非功能评测最容易踩的坑。平均成本、平均延迟都很好看，却掩盖了「5% 的请求烧了 10 倍、慢了 5 倍」。决定能不能上线的，是尾部（P95/P99、最坏情况），不是平均。对稳定性，同理——用 pass^k 看「最差情况下稳不稳」，而不是平均成功率。
设预算断言（第 12 讲）：把「缰绳」写成硬断言——步数 ≤ N、成本 ≤ C、延迟 ≤ T、重试 ≤ R。超了，就是失控，一票否决式地拦（第 11 讲）——防失控这类是零容忍的，不是「扣点分」，是「直接判失败」。
怎么在评测里测「防失控」？失控不会在顺利场景里出现，得主动制造（呼应第 17 讲故障注入）：给一个「无解 / 自相矛盾」的任务，看它会无限打转还是及时放弃；让某工具持续返回错误，看外层会不会无限重试；喂一个会诱发大量派生的任务，看子 agent 会不会指数膨胀。只在顺利场景测，你永远发现不了失控——因为失控恰恰发生在不顺利的时候。
这一讲还得讲清一个绕不开的现实——功能和非功能常常是矛盾的：想更准，往往更贵、更慢（多跑几步、多调工具、用更大的模型、多次采样投票）。
所以上线决策不是「准确率一个数说了算」，而是一个多维的取舍：在可接受的成本和延迟内，准确率和可靠性够不够。落地的做法是定一组 SLO（服务水平目标），把功能和非功能的门槛一起写清楚。
退款 Agent 的 SLO 可能长这样：
退款 Agent 上线 SLO： 功能： 整体任务成功率 ≥ 95%（软门禁，看显著性） 可靠： 关键动钱任务 pass^8 ≥ 90%（即这类任务单次成功率需 ≳99%，第 7/16 讲） 安全： 越权动作 = 0（硬门禁，一票否决） 延迟： P95 ≤ 5s 成本： 单次 ≤ $0.5，日累计 ≤ 预算 防失控：无死循环、单次步数 ≤ 15、重试 ≤ 3
注意这里面硬门槛和软指标混在一起（第 11 讲）：安全越权、死循环是零容忍的硬门禁；延迟、成本是「尽量低、但有明确红线」；准确率是看显著性的软门禁。准确率再高，只要破了任何一条硬红线（比如出现死循环、或 P95 延迟爆表），就不上线。SLO 把「能不能上线」从一个模糊的感觉，变成一组可检查的条件。
举个用 SLO 做上线判断的走查：新版退款 Agent 准确率从 94% 升到 96%（诱人！），但 P95 延迟从 4 秒变成 7 秒、且出现了 1 例死循环。怎么判？死循环是硬红线（零容忍），一票否决——不上线；就算没有死循环，P95 破了 5 秒的红线，也得先把延迟压回去再谈。SLO 的意义正在这：它让你不会因为「准确率涨了 2 个点」就忽略「延迟崩了、还带了个死循环」。任何一条硬红线破了，准确率的进步都救不了它。
这些阈值从哪来？从业务约束反推，不是拍脑袋。延迟红线来自「用户能忍多久」（在线客服可能 5 秒、后台批处理可能几分钟都行）；成本红线来自「单均能花多少还不赔本」；可靠性红线来自「一次失败的代价」（动钱的场景，pass^k 要求自然更高）。先问业务「什么情况下这个 Agent 就不该上线」，再把答案翻译成一个个数字。脱离业务定的 SLO，要么松得没用、要么严得没人能过。
对照自查一下，这几个坑很普遍：
非功能维度的归宿，是和功能维度一起，进两个地方：
举个线上非功能漂移的真实味道：某次例行的模型升级后，退款 Agent 的准确率一点没降、大家都觉得「没问题」，可 P95 延迟从 4 秒悄悄涨到了 9 秒、单均成本涨了 60%——因为新模型更「话痨」、平均多跑了几步。准确率的仪表盘一片绿，成本和延迟的仪表盘已经在报警。如果你只监控准确率，这次劣化会一直烧钱、拖慢用户，直到财务或用户投诉才被发现。
所以，把非功能指标当成和准确率同等重要的一等公民，从门禁到监控全程盯住——这是「生产级」和「demo 级」评测的一条分水岭。
回头看模块六到这里，其实补的都是「上线前那张体检表上、准确率之外的项」：安全（第 25）、分领域的特有失败（第 26）、以及这一讲的成本/延迟/稳定/防失控。它们共同回答一个问题——「这个 Agent 除了『答得对』，还『扛得住生产』吗？」一个只测准确率就上线的团队，迟早会在这些没测的维度上栽跟头。
到这里，安全、分领域、非功能都补齐了。模块六还剩最后一讲——第 28 讲：前沿与趋势，动态环境、长程上下文，以及评测与训练的融合。