人形机器人大脑体系 · 验证工程专项
人形机器人长稳测试落地
GS-SOAK12H 内存判据 C2/C5 互斥
与沙箱回收踩坑
系列：人形机器人大脑体系 · 验证工程专项
数据边界：本文全部数据来自容器仿真环境实测
"12 小时金标准"为自研长稳验收规范（代号 GS-SOAK12H）的工程实践记录

摘　要
长稳测试的验收逻辑听起来很简单：让系统连续跑 12 小时，看内存涨不涨、输出稳不稳。真做起来，第一个月就会撞上一堆"单看都合理、放一起就打架"的判据。
本文记录我们落地 12 小时长稳金标准过程中踩掉的四个真实的坑：

1. 两个判据在 12 小时尺度上数学互斥——确定性判据要求全量留痕，内存判据要求省内存，按直觉实现必然一个杀死另一个；
2. 预热期增长被外推成 2338%——60 秒冒烟里的正常预热，按线性外推直接误杀任何任务；
3. “涨了"不等于"泄漏了”——一组对照实验区分分配器碎片与对象泄漏；
4. 沙箱空闲回收杀死后台长跑进程——以及长跑进程的管道陷阱。
   每个坑都给出修法与验证方式。最后是这套规范里我们认为最有价值的一个设计：证据分级——连续 12 小时的证据和累计 12 小时的证据，是两种证据，不能混着说。
   边界声明：本文讨论验证工程方法论，涉及的运动安全架构见系列前作；测试对象为仿真环境中的决策层软件，真机长稳属另一课题。

目录
一、先立规矩：五条判据，一条一票否决 1
二、坑一：C2 和 C5 在 12 小时尺度上数学互斥 1
三、坑二：60 秒冒烟，外推出 2338% 1
四、坑三：“涨了"不等于"泄漏了” 1
五、坑四：长跑进程的两种死法 1
六、结语：长稳测试测的是系统，规范测的是自己 1
获取与部署 1

一、先立规矩：五条判据，一条一票否决
长稳测试最容易做成"跑完看一眼没崩就行"。我们把它拆成可机判的规则集，每条规则有明确阈值、超限即停跑：
判据 管什么 一票否决线
C1 功能正确性 验收锚零失败
C2 内存增长 增幅 ≤10% 且 剩余时间外推 ≤10%
C5 输出确定性 同参数重跑的轨迹指纹重复数 == 0
C7 覆盖连续性 采样间隔中断必须记录在案
C8 时延分布 P99 ≤ 50ms（含长尾）
两条设计原则贯穿始终：
 阈值一经锁版不许改。跑出来红了就红，只能修系统，不许修阈值——否则长稳测试会退化成"调阈值游戏"；
 每条判据必须能被负例打红。写一条自证用例：故意构造违反该判据的数据，判定器必须判红。打不红的判据是装饰品。
这两条原则本身没问题。问题出在 C2 和 C5 放在一起的时候。
二、坑一：C2 和 C5 在 12 小时尺度上数学互斥
这是最典型的一个"单看都对、合起来死"的设计缺陷。
C5 的直觉实现：系统每完成一个通行周期，算一条轨迹指纹（64 位哈希）。同一工况下如果出现重复指纹，说明存在未受控的缓存或记忆效应——确定性被破坏。要判定"全过程中重复数为 0"，最自然的写法是把所有指纹放进一个内存集合，新指纹来了先查集合：
if fp in self.seen[key]: # O(1) 成员判定
report_dup()
else:
self.seen[key].add(fp)
C2 的预算：内存增幅 ≤10%。测试进程基线 RSS 约 23MB，预算就是 2.3MB。
互斥点：以实测吞吐约 69 周期/秒计，12 小时累计约 300 万条指纹。Python 集合驻留 300 万个整数，实测推算内存增量约 550MB——是 C2 预算的 200 多倍。
也就是说：把 C5 按直觉实现，C2 必死；把指纹不驻内存，C5 的 O(1) 判定就没了。两者在 12 小时尺度上不是"紧张"，是数学上互斥。
修法：把"判定"和"记录"分离。
运行期（内存敏感）：
只保留最近 60 秒的指纹窗口（有界，几 KB）
→ 窗口内查重：抓"紧挨着的重复"做实时告警
→ 全量指纹顺序追加写磁盘台账（uint64 二进制，12h 约 24MB）

判定时（内存无所谓）：
逐工况读台账 → 排序 → 数相邻相等 → 精确重复数
关键认识是：运行期需要的是"快速发现"，判定时需要的才是"精确结论"。两者不必用同一份数据结构。运行期窗口集合只服务告警时效性；最终的一票否决由判定期的排序归并给出——精度一分不丢，运行内存 O(1)。
排序相邻比较的代价是 O(n log n)，300 万条 uint64 在判定时一次性跑完不到一秒——这笔算力放在判定时刻，比放在运行期每一拍便宜得多。
验证：负例自证里专门有一条——构造带重复指纹的台账，判定器必须精确数出重复数并判红；再构造干净台账，必须判绿。两条都过，才算修完。
三、坑二：60 秒冒烟，外推出 2338%
C2 的原始定义是"12 小时内存增幅 ≤10%"。没人会真等 12 小时来验证判定器本身，所以判定器要做外推：拿一段实测数据拟合增长率，外推到 12 小时。
第一版这么做：60 秒冒烟测得增幅 3%，线性外推 12 小时 → 2338%。C2 直接红。
错在哪？错在外推假设了线性增长。真实系统启动后有一个预热期：分配器首次生长、代码路径首次触及、缓存冷启动——这段增长是一次性的，不是持续速率。把一次性爬升当成持续速率外推，任何系统都会被误杀。
修法两层：

1. 规范层：C2 明确"剔除预热再拟合"，预热窗口固定 300 秒；
2. 实现层：增幅基线取预热结束后的第一个采样点，而不是进程启动首点。判定书里明确记录基线取的是哪个（baseline: warmup / first），防止实现和规范再次脱节。
   第二条是真实的二次踩坑：规范修订版写了"剔除预热"，实现却一直用全序列首末点。规范和实现分家，是验证工程里最常见也最危险的腐烂方式——判定书里把口径写出来，让不一致可见。
   四、坑三：“涨了"不等于"泄漏了”
   预热修完，冒烟跑 5 分钟，内存还在涨：约 10–14 MB/h。线性外推 12 小时照样超预算。这次是真泄漏吗？
   先说结论：不是。但结论不是猜的，是四组对照实验排出来的：
   实验 做法 结果 排除了什么
   纯负载对照 只跑业务负载，不带任何测试插桩 300 秒 +0.41MB，持平 业务代码本身无泄漏
   tracemalloc 归因 Python 对象级内存追踪 活跃对象仅 +1.3MB（基本是 import） Python 对象无泄漏
   malloc_trim 对照 强制 C 层归还空闲页 斜率不变 不是"已释放未归还"
   arena 上限对照 限制 glibc arena 数 斜率不变 不是多 arena 碎片
   四组做完，剩下的解释只有一个：C 层分配器的少量碎片化——属于分配器行为，不是对象泄漏。而更有说服力的证据来自更长时间窗：把采样拉长后，内存斜率呈现清晰的单调衰减：
   0–4 分钟： 11.6 MB/h ← 预热爬升
   4–9 分钟： 0.4 MB/h
   9–14 分钟： 0.2 MB/h
   14 分钟之后： 0.0 MB/h ← RSS 数值完全不变，连续 11 分钟
   RSS 封顶在 +3.29%，之后跨过一次 3 小时的进程中断再续跑，数值纹丝不动（24.20 → 24.32MB）。泄漏的特征是随时间单调累积，不可逆；预热爬升的特征是一次性、之后封顶。这个形态对比，比任何单点斜率都可靠。
   方法论收获：判断内存问题，先分清三个问题——谁在涨（业务/插桩/分配器）、涨多久（一次性/持续）、可不可逆（封顶/单调）。单看一个 5 分钟斜率数字做结论，两头都会错。
   五、坑四：长跑进程的两种死法
   长稳测试的执行环境本身就是一个坑源。两个真实案例：
   死法一：沙箱空闲回收。长稳进程在后台跑，22 分钟后被宿主环境静默回收——会话空闲即回收后台任务，无告警、无日志。3 小时后发现采样文件时间戳停在了 22 分钟处。
   处置不是"悄悄重启当作没发生"：中断窗口由 C7 判据如实记录（gap=11328 秒入告警账），中断段不计入有效覆盖；用断点续跑从哈希链断点恢复，证据链连续可审计。
   更重要的是这一课引出了本文想强调的最后设计——证据分级。中断之后，“连续 12 小时"已经不可得，能拿到的是"累计 12 小时”。这两者是不同的证据：
   等级 定义 能证明什么
   A_golden 真实时钟 + 真实负载 + 12h 连续 完整连续运行能力
   B_cumulative 同环境，12h 累计（中断留痕） 长时间尺度上的稳态行为
   C_reference 压缩时钟 / 合成负载 / CI 自证 逻辑正确性，不证明时长
   D_failed 判定失败 —
   等级由判定器按实际数据自动裁定，人工不指定、不覆盖。我们这轮在容器环境里只能拿到 B_cumulative——那就如实标 B_cumulative，A_golden 留给真正的长驻硬件。把"什么证据能证明什么"说清楚，比拿到一个含糊的"通过了"有价值得多。
   死法二：管道自杀。续跑命令写成 python soak.py | tee log | head -8——只想看前几行输出。但 head 读满 8 行就退出，管道断裂，下游 SIGPIPE 会顺着管道杀死整个长跑进程。长跑任务的输出重定向只有一种安全写法：直接写文件（>> log 2>&1），不挂任何会在中途退出的管道段。
   这一类坑的共性是：长跑进程死于"观测它的人"。观测代码（管道、采样、日志轮转）必须比被观测进程更保守。
   六、结语：长稳测试测的是系统，规范测的是自己
   12 小时长稳，表面上是测系统稳不稳；做下来发现，规范本身也在被测试：
    C2/C5 互斥，测出的是判据设计时没算尺度账；
    2338% 误判，测出的是外推假设没审；
    碎片误报，测出的是归因流程不严谨；
    沙箱回收，测出的是对执行环境的假设太乐观。
   我们的应对方式是把这一切都变成结构：阈值锁版不许改、每条判据有负例自证、判定书暴露口径、证据自动分级。修过的每个坑，最后都变成判定器里一条带负例的规则——踩坑的价值不在记仇，在变成机器可判的约束。
   目前容器环境的 B_cumulative 累计采集仍在进行；连续 12 小时的 A_golden 留给下一个真正的长驻环境。到那天，这套规范会先在真机上重新校一遍——按照本文的原则，新环境、新假设、判据重新对表。
   获取与部署
   ⚠ 重要说明：软件包托管于我方阿里云 ECS 静态服务节点，链接为配套文章专属访问地址。服务仅用于本次文稿配套评估试用，链接会按需维护，我方有权随时关停访问。文件禁止二次分发、转存商用；如需商用正式包与持续技术支持，请联系我方商务对接获取正式发布渠道。
   版本边界：本文所述长稳金标准属内部验证体系，其执行 harness（判定器、证据打包、指纹链）不随评估包分发；本文定位为工程方法论分享，判据设计、互斥解法与证据分级思路可直接移植到任意长跑测试场景。当前评估包版本为 v3.1.2（配套《急停优先》一文发布），包含急停优先、质量门、仲裁等基础安全链路机制，可用于验证本文第 2/3 节所依据的运行环境。V3.3 能力的配套评估包将随版本发布节奏另行提供，届时在本节更新下载地址与 MD5。
   当前可获取（v3.1.2 评估包）
   http://47.119.135.145:8080/lumina_pmd_v3.1.2_so_publish.tar.gz
    总包 MD5：eab169edc7a6d31ee636c8edc0f6c99c
    部署步骤与文件级验真方法见《急停优先：安全链路为什么必须独立于智能决策主线》一文"获取与部署"节，两包一致；
    环境要求：Ubuntu 22.04 LTS · Python 3.10 · x86_64 · 内存 8GB 起（推荐 16GB）。
   系列文章：《急停优先：安全链路为什么必须独立于智能决策主线》｜《人形机器人三级牺牲通行体系：预标→重定位→兜底》｜本文｜（下一篇）PSSAC 契约：让运动规划读懂台阶与电梯边界