健康度报告 41 分不可信？用 4 条 trace 证伪平台结论

导读：一篇用 4 条 trace 逐条证伪平台结论的方法复盘：某纯编排型 Agent 技能被打成健康度 41/100「不健康」，但拉明细后发现 P99 长尾（149.4s、最长 317.6s）来自跨业务定时任务混入采样的噪音，83.8%（150/179）的「中断」大多是业务写成功后收尾轮被平台切掉、并非用户流失。核心结论是分数失真源于采样口径污染 + 中断语义错位，真正可动的是把 read_file 从 4-5 次/trace 压到 ≤1、成功后立即终止这类纯编排优化，零业务改动。适合做 Agent 评测、健康度指标治理的工程师读，最值得借鉴「分数是假设、trace 是证据」的排查顺序。

分类：AI评测 ｜ 标签：Agent、健康度、trace实证、评测

说明：本文是方法复盘，不是整改实录。文内健康度分数、分位耗时、trace 时长等数值均已脱敏示意、仅保留量级；技能名、版本号、业务渠道与业务细节均已泛化。

现象：41 分很吓人

某次平台健康度快照把我们负责的一个 Agent 技能（电话外呼跟进类，纯编排型）打成了 41/100「不健康」。上一期 38 分，这期"涨"到 41，但翻开四维结构，分项与总分矛盾得离谱：

平均耗时 44.5s（达标，≤50s），P50 35s，唯独 P99 飙到 149.4s（P95 的两倍）——时延扣分来自 p95 超过 60s 失败线；可靠性扣分主因是「中断率 83.8%（150/179）」。（表内与行文中的数值均已脱敏，仅保留量级示意。）

单看这个分数，正常的反应是：赶紧查为什么这么慢、为什么用户疯狂流失。先别急，看一眼渠道分布：179 条采样里，176 条来自电话外呼渠道，定时任务 2 条，网页渠道 1 条——98% 是外呼语音渠道。这个渠道的 client_abort 到底意味着什么，报告没说。要下结论，必须实证。

分数是结果，采样与分类才是过程。过程的任一环节被污染，分数就会失真。

方法：4 条 trace 逐条证伪

不猜，直接拉全量明细——4 条 trace 连同每条的时间线摆上桌，报告的吓人结论逐一接受检验。

证伪 1：P99 长尾 317s 不是"慢"，是定时任务混入的采样噪音

P99 149.4s 是被 最长一条 trace（317.6s、21 轮模型调用、29 次工具调用） 拖起来的。拉明细看它的输入：这是一条「定时补打任务」，每 2 小时触发一次、按规则自动发起外呼——随后它翻沙箱里其他技能目录、写探测脚本，最后调用别的脚本发起了新外呼。

这根本不是外呼跟进技能的本职（外呼结果回写跟进记录），是另一个定时任务的 trace 被混进了本技能采样。它只占 179 条里的 2 条，却一个人抬高了 P99 和平均耗时。1 条噪音直接决定了"41 分"里的延迟维度。

证伪 2：正常链路的轮次浪费，集中在 read_file

再拉两条电话外呼正常完成的链路（73.7s / 92.5s），时间线几乎同构：

生成1 → read_file → 生成2 → read_file×2 → 生成3(⚠34s) → read_file → 生成4 → read_file → 生成5 → execute(成功·2.6s) → 生成6(又要读技能说明) → 【被截断】

三个事实：

1. read_file 4-5 次/trace：6 轮模型调用里塞了 5 次读文件，远超预算 ≤2。每多读一次，就多一轮 15-35s 的模型生成。
2. 业务写成功后仍读技能说明：execute 已返回 ok:true，最后一轮生成还在 read_file 技能说明——说明文档里明写着「已注入、禁止 read_file」，注入约束对模型根本没生效，白送一轮 20-40s，还常被平台掐断记中断。
3. execute 恰好只有 1 次且成功：两条 trace 都只有 1 次 execute（2.6-3s）——报告 AI 建议的「合并 execute」，对本技能毫无意义。

模型生成/思考占真实耗时的 90.9%（39.08s/trace），主要来自 5-6 轮 × 单轮 5-35s 的叠加（含全局基础模型推理负载因素）。技能侧真正能压的是轮次数，不是单轮时长。

证伪 3：「中断」的 client_abort，大半是业务完成后的收尾轮被切

电话外呼链路被掐断的实证模式是：execute 把跟进结果写入成功 → 模型收尾轮又去读技能说明 → 平台在此处切断会话 → 记为 client_abort。

「中断」的主体是业务已写成功后的收尾轮被平台切掉，不是用户等不及离开。 报告 AI 给的 P0 建议「流式输出 / 占位话术止血用户流失」，在回调写跟进这种场景根本不成立——这里没有实时等待的用户（另 2 条定时任务同理）。

发现：采样噪音与中断语义

三条实证结论收敛为：

• 采样口径污染：P99 长尾来自跨业务定时任务混入，补打任务不算真实用户，报告却把它计入了本技能的延迟与平均耗时——「健康度 41 分」的时延维度是假的。
• 中断语义错位：83.8% 的中断大多是"业务已完成后收尾轮被切"，不是用户放弃——可靠性维度的扣分口径是错的。真正要修的，是轮次浪费（5-6 轮 vs 应有 3-4 轮）。
• 模型负载是大盘因素：观测窗口内多个技能的生成耗时 p95 同步翻倍，这是基础模型推理服务的全局负载问题，不是本技能可解的。

平台侧口径也留了两条待办（需平台改采样，技能包改不了）：①按技能标识严格过滤采样，定时任务等非真实用户渠道单独分组；②中断判定补充「完成前中断 / 完成后中断」分类，排除业务已成功的收尾轮被切。

只改编排，不动模型

4 条 trace 证伪完，真实结论是：分数失真（采样污染 + 中断语义错位），但技能本身确实存在轮次浪费。于是只做 3 个纯编排优化，零业务逻辑改动——业务写回脚本一个字节都不动（打包时做字节级对比校验）：

验收口径也从证据出发：read_file 次数/trace（目标 ≤2、理想 1）、模型轮次（目标 ≤4、理想 3）、完成链路平均耗时、循环健康保持 1.00——而不是盯着那个被污染的 41 分复测。

附带的凭据治理：分数救不了的坑

发布前静态扫描报了 3 项，其中一项是 P0：明文 API Key/Secret 被打进了发布包。整改四步，全部在编排/文档/安全边界层，零业务改动：

1. 删明文密钥：从参考文档里删掉全部明文密钥和大表。用 grep 实证后确认这些 key 在本技能脚本里零引用，且其中一条的值与配置中心真源不一致——是模板残留的脏值，根本不属于本链路。
2. 立注入规范：静态凭据统一走配置中心（命名空间 + 数据项），沙箱环境白名单随 execute 注入，脚本读不到环境变量直接报错。对齐团队既有惯例。
3. 收紧传输回退：HTTP 客户端默认严格校验证书，仅内部网关域或显式声明才允许跳过校验，消除"默认不校验证书"的中间人面（线上零影响：本链路全部走内部网关域）。
4. 版本统一：消除参考文档头部与技能清单版本不一致的混淆。

方法论小结：什么时候该信分数

把这次复盘压成一条可复用的方法链：

健康度四维拆解 → 逐条 trace 验证/证伪 → 中断语义修正（定义什么算真中断）→ 凭据边界治理

几个可迁移的判断规则：

• 分位数的长尾必须看组成。P99 被几条 trace 拖高时，先问它们是不是同一业务、同一渠道、同一触发源。跨渠道/跨任务的 trace 混入真实用户采样，是典型的采样口径污染。
• 中断语义是 AI 评测里最容易被误读的字段。「client_abort」不等于「用户放弃」。拉时间线看切断点：在业务成功之前的才算数，业务已写完、只是收尾轮被切的，不是真中断。
• 报告里的 AI 建议，要用场景实证后采纳。流式输出、占位话术这类"通用止血"建议，在无实时用户等待的回调场景是无效动作。
• 当你读得懂一条 trace，而分数结论与它矛盾时，相信 trace。分数是假设，trace 是证据。先修采样、再修语义，然后从证据里找可动点——而不是对着失真分数盲目大改。

什么时候该信分数？采样口径干净（无跨业务混入）、中断语义正确（中断=真实用户放弃）、四维结构与 trace 证据自洽，三条同时满足时，分数才配当决策输入。否则，健康度报告只是一份"待证伪的假设集"。