exp-probe

Exp 探测：必要时只询问一次 → 运行 → 记录 → 一行报告

探测的目的是低成本地回答一个问题。除诚实以外，其他一切都应尽量精简。

• 先明确唯一的问题（“配置 X 能否放入内存”“这个 NaN 能否复现”“缺失的锚点值是多少”）。如果说不清问题是什么，这就不是探测。
• **缩减，不要扭曲：**减少样本数和步数，但绝不改变测量对象的语义（序列长度、批次语义、数据类型）。报告时准确说明缩减了什么。
• **复现真实入口：**探测必须通过与真实运行相同的启动器和标志运行（例如预检模式），而不是改写成临时路径——绕过真实路径的探测无法证明任何关于真实路径的结论。探测代码应放在项目的临时／实验目录中，每个探测彼此隔离，并遵循所有研究代码的同一规则：不做防御式编程——代码越少越好；真实错误应原样退出；环境故障（设备争用、磁盘已满）应诊断为环境问题，而不是通过绕行来修补。
• **即使成本低，也要先做预检：**与真实运行相同的一轮检查，只检查一次——确认环境已激活，并使用平台自带工具（nvidia-smi、npu-smi、mthreads-smi，等等）实时读取设备，选择空闲设备，再通过平台的可见设备变量显式指定它（绝不使用默认设备）。探测若占用了别人的设备，会白白浪费对方和自己的运行时间。
• 探测的目标是低成本，因此通常可以在当前流程中等待。如果探测运行时间较长（检查完整尺寸模型的运行状态、数据集加载缓慢），则使用与 exp-batch 相同的委派模式：后台启动，再通过 later 唤醒，而不是一直占用当前轮次。
• 最多只向用户提一个问题，而且仅当问题本身有歧义时才提问。不要写计划文档，不要一轮轮盘问，不要使用子 Agent。
• **记录在项目可找到的位置：**按照项目规则放在临时目录中，记录配置、观测结果和退出状态。如果探测结果会从实验批次中剔除某些单元，就应将结论及其证据记入该批次的剔除记录，并说明影响哪些单元。
• **用一行报告：**问题、观测到的答案、成本，以及因此可以推进或排除的事项。如果答案是“未知／无法得出结论”，就如实说明，并提出下一个成本最低的探测方案——不要悄悄将其升级为批量实验。