上一篇我们把垂直 agent 的确定性框架搭完了：状态机管流程，schema 管输出，幂等管重试。听起来滴水不漏了？

但做过线上系统的都知道——长尾永远存在，总有插槽和校验都罩不住的情况。这一篇讲两件事：罩不住的时候怎么办（逃逸舱），以及怎么知道系统有没有在变好（评测）。顺便给整个系列收个尾。

开头先抛个悖论。第一集我说过：一个从不逃逸的系统，不配叫 agent，它就是个 workflow。可反过来，要是动不动就逃逸，说明框架是个摆设。那问题来了——

01  先把悖论摆上台面

从不逃逸，等于 workflow：所有规则都定死了，模型的自主性一分没留，你还白扛着模型的不稳定性。

动不动就逃逸，等于框架是摆设：主流程都罩不住，骨架形同虚设。

▲ 两个极端都错，健康区间在中间——而且可以设计出来

所以逃逸率不是一个要消灭的指标，它是一个要管理的指标。下面三件事，一件管出口，一件管阈值，一件管回流后的沉淀。

02  逃逸舱的正确姿势：出口 + 回检

触发条件就两个：插槽输出低置信，或者被 schema 反复打回。这两种情况说明一件事——这个 case 超出当前框架的能力圈了。

这时候切到自由 agent 模式，通用能力全部解禁，让它去处理长尾。这在第一集叫「逃逸舱」，是垂直 agent 成立的前提。

▲ 逃逸舱是「出口 + 回检」，不是绕开框架的后门

03  阈值别拍脑袋，用反推法

我见过最常见的做法是拍脑袋：写个 0.7、0.8，完事。这个数凭什么？没人答得上来。

正确姿势是反推：先把阈值放宽，放量跑一阵，统计线上的真实逃逸率；然后按你业务能承受的度，反推出阈值该卡在哪。

▲ DropLink 真实曲线：长尾一类类被收编，曲线一路往下走

拿 DropLink 的真实曲线说：刚上线那阵逃逸率很高，随着一类一类长尾 case 被收编成插槽，曲线一路往下走。这条往下走的曲线，就是系统在学习的证据。反过来，逃逸率太高说明框架罩不住，回去补插槽；压到零——恭喜，你写的其实就是个 workflow。

04  逃逸 → 沉淀 → 收编：日志是数据资产

所以逃逸日志千万别当报错垃圾删了——那是你最好的数据资产。

闭环长这样：长尾 case 在逃逸舱里被解决，日志沉淀下来；同一类攒够了，就收编成新的插槽规则——写 schema、写原语、写输入清单。

▲ 收编要用的活儿，正好是 EP2 写原语 + EP3 造上下文 + EP4 写 schema 的全套

这个闭环一转起来，系统就越用越垂直——而且是线上数据喂出来的垂直，不是你关起门猜的。

05  加分项兑现：插槽边界就是评测点

最后兑现第一集埋的一个加分项：评测。这么搭出来的系统，插槽边界就是天然的评测点——输入清单是固定的，输出 schema 是固定的，对着插槽分层写评测集就行，不用对着整条黑盒链路干瞪眼。

想验证系统在变好？看两条线就够了：逃逸率曲线下行，评测集通过率上行。

总结：五集，一张地图

整个系列到这儿就齐了：第一集立框架，第二集换原语，第三集造上下文，第四集写骨架，第五集——逃逸和迭代。五集拼起来，就是一张完整的垂直 agent 工程地图。