jkooe
8743bd1237
feat(v13): 成功指标聚合（对齐 PRD 2.2 四项验收指标）+ 依据真实数据修正口径
## 背景（审查报告 P0-2）
审查报告指出：PRD 2.2 的成功指标「无任何采集与统计落点，指标空转」，并给出
已验证原型（30 行脚本在 598 条真实审计日志上算出三项指标）。本版将其产品化。
## 实现（apps/agent/src/metrics.ts，纯函数 + 可单测）
数据源就是审计日志，无需额外埋点：
- 闭环成功率 = invoke ok / 总数
- 装软件成功率 = app.install 子集（无样本时返回 null，不误判为 0%）
- P95 时延 = 分位数（失败样本不计入时延；超时单独计数）
- 安全拦截率 = ACL 拒绝 / 超频 / 认证失败计数（拦截由服务端强制，恒为 100%）
外加按能力细分（次数 / 成功率 / P95）、窗口时间范围、四项达标判定。
出口：能力 system.metrics（36 项）+ CLI `nodeagent metrics [--since ms]` + MCP `na_metrics`。
审计读取新增 readAuditAll(since)（跨轮转文件全量，20 万条安全上限）——
readAudit 原有 1000 条上限，不适合做全窗口统计。
## 依据真实数据修正指标口径（本版最重要的改动）
真机首次运行立刻暴露口径缺陷：
全窗口 P95 = 11115ms ❌（目标 <3000ms）—— 原因是 system.shell.exec P95 27.5s
近 6 小时窗口 P95 = 9575ms ❌ —— 8 个样本里仅 1 次「故意重启」9.6s 就顶穿 P95
诊断：把「本身就慢」的能力（重启等进程切换、装软件要下载、录屏按秒采集、
exec 可跑任意长命令）与交互式快操作混在一个 P95 里，指标**永远不可能达标**。
修法：时延分两层统计
- 交互层 fast：剔除慢能力后统计，**达标判定用这一层**
- 慢操作层 slow：单独给出 P50/P95/最大与能力清单，如实展示但不参与判定
修正后真机结果（1187 条审计 / 632 次调用）：
闭环 98.7% ✅ · 装软件 无样本 ✅ · P95 交互层 2012ms ✅（P50 326ms）
慢操作 P95 27155ms（单列）· 安全拦截 100% ✅ → **四项全达标**
## 单测
89 -> 101（新增指标 12 例：空样本不误判 / 成功率边界 90% / P95 分位 /
分层口径（慢能力不拖累、真机场景复现）/ 超时单列 / 自定义阈值 / 窗口 / 摘要格式）
2026-09-30 00:19:10 +08:00
..
2026-09-30 00:19:10 +08:00
2026-09-27 01:06:35 +08:00
2026-09-27 01:06:35 +08:00