v0.0:
  标题: 工程导入与 MACF 原型成形
  v0.0.0:
    时间:
      - 2025-11-05 12:18:59
      - 2025-11-05 12:18:59
    重要性: 9.5
    标题: 初始工程导入、MACF 环境与 GAT 基础模块
    摘要: 基于 light_mappo 导入 MAPPO/RMAPPO 主体，并加入 MACF 环境、GAT 模块、runner 雏形和训练入口。
    内容:
      - 建立 MAPPO/RMAPPO 基础训练代码，包括 actor-critic、PPO 更新器、buffer、value normalization 和工具函数。
      - 建立 MACF 环境雏形，包括连续地图、离散动作封装、环境 wrapper 和绘图脚本。
      - 引入 GAT 基础实现，包括手写 GAT layer、GAT network 和 graph builder。
      - 同时保留 shared、separated、separated_nogat、separated_withgat 多条 runner 试验路径。
      - commit 规模很大，属于项目从通用 MAPPO 框架转向 MACF/GAT-PPO 研究代码的初始化版本。
    commits:
      - d3583e
    结论:
      工程:
        - 形成可继续开发的工程骨架。
      问题:
        - 尚未从日志中看到稳定训练结果；这一阶段主要解决“能表示问题、能启动训练”的基础问题。
  v0.0.1:
    时间:
      - 2025-11-12 22:03:35
      - 2025-11-18 12:06:44
    重要性: 6.0
    标题: 观测、配置与日志链路重整
    摘要: 围绕观测重写、配置统一、日志输出和 GIF 可视化连续调整。
    内容:
      - '`2025-11-12` 开始重写观测，commit message 已明确“准备重写观测”。'
      - '`2025-11-15` 将配置统一到 `config.py` 和 `config.yaml`，减少训练入口、runner、环境中的分散硬编码。'
      - '`2025-11-17` 调整日志版本，并继续修正环境与 GAT runner 的衔接。'
      - '`2025-11-18` 完成配置整理和 GIF 生成相关代码。'
    commits:
      - 1930c0
      - cdc72b
      - c5bf7f
      - '198315'
    结论:
      工程:
        - 训练配置开始可复用，实验参数不再完全依赖手动改代码。
        - 可视化和日志能力增强，但从 commit 记录看仍处在环境/观测快速试错阶段，未形成可量化性能结论。
      问题:
        - 暂无明确失败或遗留问题记录。
v0.1:
  标题: 奖励、任务动作与早期基线探索
  v0.1.0:
    时间:
      - 2025-11-24 11:23:59
      - 2025-11-24 11:23:59
    重要性: 8.0
    标题: 奖励简化、奖励解析与旧 runner 备份
    摘要: 针对“不收敛”问题重写奖励相关逻辑，并引入奖励配置和解析脚本。
    内容:
      - 将奖励权重从环境硬编码中拆出，训练时可以按配置调整 reward component。
      - 重写奖励计算、任务状态推进和训练反馈，让“不收敛”问题可以先从奖励分解角度排查。
      - 保存 separated old runner，便于回退或对比旧交互逻辑。
      - 加入 reward component 解析能力，用于观察总回报到底来自发现、完成、死亡、距离塑形还是其他项。
    commits:
      - be0e60
    结论:
      进展:
        - 解决方向从“单纯调网络”转为“先让奖励信号可解释、可拆解”。
      问题:
        - commit message 直接说明当时“不收敛”，因此该版本的有效性主要是诊断能力增强，而不是训练效果已经改善。
  v0.1.1:
    时间:
      - 2025-11-28 01:47:48
      - 2025-11-28 01:47:48
    重要性: 4.0
    标题: DDQN 参考实现
    摘要: 加入 DDQN 离散动作参考实现，作为早期非 MAPPO 基线尝试。
    内容:
      - 加入 DDQN 离散动作参考路径，尝试用 value-based 方法处理早期 MACF 动作选择。
      - DDQN runner 覆盖环境交互、经验收集和训练调度，与 MAPPO 路径形成早期对照。
      - 继续调整环境奖励、绘图和奖励解析。
    commits:
      - ec2429
    结论:
      进展:
        - 增加了一个 off-policy / value-based 参考方向。
      问题:
        - 后续主线没有继续围绕 DDQN 展开，说明它更多是早期 baseline 探索，而不是最终研究主线。
  v0.1.2:
    时间:
      - 2025-11-30 13:00:58
      - 2025-12-04 12:00:25
    重要性: 8.0
    标题: 环境推进、决策时机与 active task mask
    摘要: 围绕任务需求、决策时机、active task mask 和环境重构进行集中调整。
    内容:
      - '`2025-11-30` 继续大幅修改环境核心和绘图逻辑。'
      - '`2025-12-03` commit message 明确“要大改决策时机了，环境可能要重构”。'
      - '`2025-12-04` 初步完成 active task mask。'
      - 同日增加低 demand 设置，降低任务难度以观察学习信号。
    commits:
      - e59da7
      - 977d81
      - f8df98
      - d6ab0e
      - 627e15
    结论:
      工程:
        - 动作可用性开始显式进入 runner / 环境交互，减少智能体选择无效任务的概率。
      验证:
        - 降低 demand 说明训练难度当时偏高；该阶段的有效性主要体现在环境更可训练，但没有稳定评估指标记录。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.1.3:
    时间:
      - 2025-12-05 12:57:05
      - 2025-12-05 12:57:05
    重要性: 6.0
    标题: Discover / Idle / Resupply 特殊任务槽
    摘要: 加入返回补给任务类型，探索任务改为 Discover，并把特殊任务 ID 动态化。
    内容:
      - 探索、待机、补给任务从写死 ID 改为动态变量。
      - 新增 Resupply 任务类型和对应任务槽。
      - 探索任务类型命名从 Explore 调整为 Discover。
      - 相关 runner 随任务槽编号变化同步适配。
    commits:
      - 8615cf
    结论:
      进展:
        - 任务动作空间更稳定，后续改变任务数量时不容易出现动作 ID 错位。
      问题:
        - 这一版没有独立评估结果；补给动作进入动作空间后，环境语义更接近后续配送问题。
v0.2:
  标题: Runner 结构重整与 GAT/PCFA 接入
  v0.2.0:
    时间:
      - 2025-12-06 17:19:32
      - 2025-12-06 17:19:32
    重要性: 8.0
    标题: 共享策略 runner 跑通与工程目录重整
    摘要: 共享策略训练链路跑通，环境目录迁移到 `envs/mcaf`，清理多条临时 runner。
    内容:
      - 原 `envs/env_*` 移动到 `envs/mcaf/`。
      - shared runner 更名为 MACF 专用 runner。
      - 删除 DDQN 和多条 separated_gat / separated_nogat 临时 runner。
      - 日志整理脚本开始承担实验日志归档，减少训练输出散落。
    commits:
      - b29d1d
    结论:
      工程:
        - 工程结构从“多条并行试验路径”收敛为 shared-policy 主线。
        - 共享策略 runner 跑通，是后续 GAT/MAPPO/HATT 接入的基础。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.2.1:
    时间:
      - 2025-12-07 01:39:17
      - 2025-12-07 09:45:00
    重要性: 6.0
    标题: 环境交互、奖励和 separated runner 修复
    摘要: 连续修复环境交互逻辑、奖励计算和 separated runner 可用性。
    内容:
      - 删除 separated old runner。
      - 修改 wrapper、shared runner、separated runner 的环境交互。
      - 修正奖励计算逻辑。
      - separated runner 重新可用。
    commits:
      - aba1b8
      - '539488'
      - 5f73c5
    结论:
      工程:
        - 降低 runner 与环境返回结构不一致导致的训练中断风险。
        - separated runner 重新支持后，仍可做独立策略或 shared policy 对照。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.2.2:
    时间:
      - 2025-12-07 16:11:02
      - 2025-12-09 02:22:44
    重要性: 9.5
    标题: GAT 增强 MAPPO 初版
    摘要: 正式接入 GAT policy、GAT PPO 更新器、GAT buffer 和 shared_gat runner。
    内容:
      - 将 GAT 表示接入 MAPPO policy，让 actor/critic 可以使用基于 agent-task 图的嵌入。
      - PPO 更新器开始处理 GAT 增强路径，包括图嵌入参与训练 batch 的情况。
      - rollout buffer 开始保存 GAT 路径需要的结构化中间数据，而不是只保存扁平观测。
      - shared_gat runner 专门负责 GAT rollout、insert、compute 和 train 的数据对齐。
      - 多次调整 GAT policy、PPO 更新和 buffer shape，说明重点在 rollout batch 与图数据对齐。
    commits:
      - 8f9617
      - 04f93c
    结论:
      工程:
        - GAT 增强训练路径开始可运行。
      问题:
        - 但后续 profiler、zero ablation 和 gated 融合说明 GAT 仍存在性能和有效性不确定性，需要持续消融。
  v0.2.3:
    时间:
      - 2025-12-08 11:47:46
      - 2025-12-08 11:47:46
    重要性: 6.0
    标题: PCFA 规则基线早期接入
    摘要: 新增 PCFA 规则基线和 runner，作为早期规则方法对照。
    内容:
      - 加入基于能力与需求匹配的 PCFA 规则策略。
      - PCFA runner 接入项目训练入口，使规则方法可以和学习方法使用相近的环境包装。
      - 这一版的 PCFA 仍是早期基线，主要用于建立“非学习方法”的比较对象。
    commits:
      - 95d533
    结论:
      进展:
        - 初步具备规则基线对照能力。
      问题:
        - 该版本 PCFA 后续在 2026-06-28 被大幅重写，说明早期 PCFA 还不是最终基线实现。
  v0.2.4:
    时间:
      - 2025-12-26 16:57:22
      - 2025-12-26 16:57:22
    重要性: 4.0
    标题: GAT 性能 profiler
    摘要: 在 GAT policy 内加入 profiler，用于定位 GAT 性能瓶颈。
    内容:
      - 在 GAT policy 的关键路径加 profiler 计时。
      - 关注点是图构建、GAT 前向和 policy 前向的耗时占比，而不是改变算法语义。
    commits:
      - 5bde36
    结论:
      工程:
        - profiler 能记录 GAT policy 关键路径耗时，后续可以定位图构建或 GAT 前向是否拖慢训练。
      问题:
        - 这一版没有训练效果结论，不能证明 GAT 表示本身有效。
v0.3:
  标题: QMix/VDN 尝试与 GAT 消融
  v0.3.0:
    时间:
      - 2026-02-08 00:33:48
      - 2026-02-08 00:33:48
    重要性: 4.0
    标题: QMix / VDN off-policy 路径初步引入
    摘要: 修复低速问题，并新增 QMix/VDN off-policy 路径雏形，但该路径未完成。
    内容:
      - 引入 QMix 的 agent Q function、mixer、policy 和 runner 雏形，尝试 off-policy MARL 路线。
      - 同步加入 VDN mixer 和 replay buffer / segment tree 等 off-policy 训练基础设施。
      - GAT 路径继续整理，以减少低速问题对后续对照实验的干扰。
    commits:
      - bf585b
    结论:
      工程:
        - 提供了 off-policy MARL 方向的代码入口。
      问题:
        - commit message 明确“QMix 部分，未完成”；当前项目文档也说明 QMix/VDN 依赖外部 `offpolicy` 包，因此不是后续主线。
  v0.3.1:
    时间:
      - 2026-05-14 11:49:36
      - 2026-05-24 15:05:24
    重要性: 8.0
    标题: GAT zero ablation 与 actor-side GAT
    摘要: 增加 GAT zero 消融，调整 GAT 挂载位置，并让 value 路径接收能力参数。
    内容:
      - 增加 zero ablation，用于测试 GAT 信息置零后的影响。
      - GAT 更明确地挂到 actor 侧。
      - '`get_values()` 接收 caps 参数，继续尝试让 value 路径利用能力信息。'
      - 新增 rule_based runner 路径，为规则对照做准备。
    commits:
      - f15182
      - eb8ce5
    结论:
      验证:
        - GAT 有效性开始进入消融验证阶段，不再只看“接入后能不能训练”。
      问题:
        - 仍未看到稳定性能结论；这一阶段主要产出是消融开关和对照 runner。
  v0.3.2:
    时间:
      - 2026-05-30 17:25:19
      - 2026-05-30 17:25:19
    重要性: 4.0
    标题: 日志恢复与 GAT policy 分叉
    摘要: 恢复日志相关代码，并保留 `gaMAPPOPolicy1.py` 作为 GAT policy 分叉版本。
    内容:
      - 恢复日志相关逻辑，保留当时的 GAT policy 分叉以便对照旧实现。
      - rule_based runner 大幅调整，继续补齐规则方法和学习方法的比较路径。
      - 环境和配置围绕 GAT / rule-based 对照变化，说明该阶段仍在整理基线实验形态。
    commits:
      - 2d79d9
    结论:
      工程:
        - 后续 6 月中旬合并 runner、policy 更名和 gated 融合，是对这一阶段试验分叉的收敛。
      问题:
        - 显示 5 月底 GAT policy 仍存在多版本并行试验。
v0.4:
  标题: GAT 主线整理与 MACF 命名修复
  v0.4.0:
    时间:
      - 2026-06-07 21:45:46
      - 2026-06-07 21:45:46
    重要性: 6.0
    标题: env-runner 异步工作修复
    摘要: 修复环境与 runner 异步工作问题，但 TensorBoard `add_scalar` 仍未完全修复。
    内容:
      - 调整 env wrapper、runner collect/insert 与 train 入口。
      - shared 和 shared_gat runner 同步修复。
    commits:
      - '461898'
    结论:
      工程:
        - 训练主循环恢复可运行。
      问题:
        - 日志 scalar 问题仍未完全解决，说明该版本仍偏工程修复。
  v0.4.1:
    时间:
      - 2026-06-14 11:48:43
      - 2026-06-14 11:48:43
    重要性: 8.0
    标题: 合并 GAT / 非 GAT runner
    摘要: 删除独立 `shared_gat` runner，统一到 shared MACF runner，并修复 GAT buffer bug。
    内容:
      - GAT 和非 GAT 不再维护两套 shared runner，统一走同一个 MACF runner 分支。
      - runner 根据配置选择标准 MAPPO 数据流或 GAT/HATT 数据流，减少 collect/insert/compute 逻辑重复。
      - GAT buffer 的数据结构修正后，图增强路径可以继续复用 shared-policy 训练主线。
    commits:
      - 4b06b3
    结论:
      工程:
        - 训练主线明显收敛，减少维护两套 runner 的成本。
        - 这一版没有独立评估结果；runner 数量减少后，GAT/非 GAT 路径维护成本下降。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.4.2:
    时间:
      - 2026-06-17 16:02:57
      - 2026-06-17 16:02:57
    重要性: 8.0
    标题: Policy 更名、gated 融合与图边语义修正
    摘要: '`gaMAPPOPolicy` 更名为 `gaRMAPPOPolicy`，支持 gated GAT 融合，图构建改为双向边。'
    内容:
      - policy 命名从 gaMAPPO 收敛到 gaRMAPPO，明确它服务 MAPPO/RMAPPO 两种 trainer。
      - GAT 融合增加 gated 模式，允许网络学习 GAT embedding 对原始观测的贡献强度。
      - graph builder 改为双向 agent-task / agent-agent 边，让信息在智能体和任务之间双向传播。
      - 时间惩罚增大，用更强的 episode 进度压力抑制拖延策略。
    commits:
      - 47b7af
    结论:
      进展:
        - GAT 表示与原始观测的融合方式更可控。
      问题:
        - 这一版没有独立评估结果；gated 模式使 GAT 表示贡献可被单独观察。
  v0.4.3:
    时间:
      - 2026-06-17 16:23:23
      - 2026-06-17 16:23:23
    重要性: 6.0
    标题: mcaf 更名为 macf 与项目文档补充
    摘要: 修复环境目录拼写，从 `mcaf` 更名为 `macf`，并添加项目文档。
    内容:
      - '`envs/mcaf/` 迁移为 `envs/macf/`。'
      - runner 和训练入口同步更新 import。
      - 项目说明开始记录目录结构、运行方式和代理协作约束。
    commits:
      - 4c50b4
    结论:
      工程:
        - 命名与 MACF 问题一致，降低后续工具和文档中的混乱。
        - 项目文档开始记录工程约束，便于代理协作。
      问题:
        - 暂无明确失败或遗留问题记录。
v0.5:
  标题: 结构化观测与 HATT v1-v2.3
  v0.5.0:
    时间:
      - 2026-06-19 09:47:52
      - 2026-06-19 09:47:52
    重要性: 9.5
    标题: Dict 观测贯通 env-buffer-runner-policy
    摘要: 将 MACF 观测重构为 `ego`、`tasks`、`others` 多键 Dict，并贯通训练链路。
    内容:
      - 观测从扁平向量改为 `ego`、`tasks`、`others` 三类结构化输入，保留实体边界。
      - centralized state 同步结构化，再由统一工具 flatten 给 critic 使用。
      - env、wrapper、buffer、runner、policy、actor-critic 同步适配 Dict 观测。
      - 项目指南补充关键调用链、验证建议和修改边界，减少后续自动化修改误伤。
    commits:
      - '713921'
    结论:
      进展:
        - 这是 HATT 能够成立的关键基础版本。
        - 相比扁平 obs，后续网络可以显式区分自身、其他智能体和任务。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.5.1:
    时间:
      - 2026-06-21 01:23:53
      - 2026-06-21 01:23:53
    重要性: 9.5
    标题: HATT 基础异构注意力与 centralized state
    摘要: 引入 HATT 基础网络，并重构 centralized critic state 链路。
    内容:
      - HATT 基础网络开始按 ego、others、tasks 分别编码，不再通过 legacy graph_builder 构图。
      - policy 通过 `graph_model` 选择 HATT 路径，和 legacy GAT 保持同一训练接口。
      - critic state 改为结构化全局信息后再 flatten，减少 actor/critic 对观测格式的隐式假设。
      - 增加 HATT 基础测试，覆盖网络输入输出 shape。
    commits:
      - 4147da
    结论:
      工程:
        - HATT 从概念进入可训练代码路径。
        - 训练链路不再只依赖 legacy GAT 图构建。
      问题:
        - 该阶段尚未看到 HATT 相对 MAPPO/GAT 的独立性能结论。
  v0.5.2:
    时间:
      - 2026-06-21 14:25:02
      - 2026-06-21 14:25:02
    重要性: 9.5
    标题: HATT v2.0：任务条件联盟上下文与候选边解码
    摘要: HATT v2.0 将任务动作建模为 agent-task candidate edge scoring，并引入当前联盟上下文。
    内容:
      - 对每个候选 task 构造任务条件上下文。
      - 当前 task coalition 成员被聚合到候选任务表示中。
      - actor 输出从普通动作 MLP 转为共享候选边 decoder。
    commits:
      - 4d2385
    结论:
      进展:
        - 这是后续 v2.x / v3.x 大量消融的基准版本。
        - 策略结构更贴近“智能体选择加入哪个任务联盟”的问题定义。
      问题:
        - 该版本主要是结构变更，尚未单独证明能提升训练结果。
  v0.5.3:
    时间:
      - 2026-06-22 01:04:51
      - 2026-06-22 09:07:12
    重要性: 8.0
    标题: HATT v2.1 / v2.2 稳定化
    摘要: 修正联盟编码、加入任务集合上下文，并稳定任务池化与空间边语义。
    内容:
      - v2.1 对齐联盟编码并加入任务集合上下文。
      - v2.2 稳定任务池化，修正空间边语义。
      - 测试同步扩展。
    commits:
      - e926b3
      - 076965
    结论:
      进展:
        - HATT v2 主线从初版推理结构转向稳定化。
      问题:
        - 该阶段没有独立性能结论。
  v0.5.4:
    时间:
      - 2026-06-27 12:16:29
      - 2026-06-27 22:18:16
    重要性: 9.5
    标题: HATT 模块拆分与 v2.3
    摘要: HATT 从单文件拆分为多版本模块，并新增 v2.3 三变体和全 checkpoint 评估流水线。
    内容:
      - HATT 各历史版本拆成独立模块，兼容导出只负责路由，避免一个文件里堆叠所有实验分支。
      - v2.3 增加 a/b/c 三变体，用于比较不同联盟上下文和任务上下文路径。
      - eval 支持独立 reset mode，让训练环境和评估环境可以采用不同随机化策略。
      - 全 checkpoint 并行评估与跨实验汇总脚本开始成形，评估对象不再只限 final checkpoint。
    commits:
      - 27182e
      - 02d69d
    结论:
      进展:
        - HATT 版本管理清晰化，后续每个变体可独立维护。
      工程:
        - 全 checkpoint eval 开始产出可比较的中间检查点结果。
      问题:
        - 暂无明确失败或遗留问题记录。
v0.6:
  标题: 评估系统、实验目录与 checkpoint 管理
  v0.6.0:
    时间:
      - 2026-06-22 14:25:52
      - 2026-06-23 01:17:02
    重要性: 8.0
    标题: 固定场景 eval 与批量模型对比
    摘要: 建立固定场景评估和 sweep 入口，恢复 HATT v2.0 横向对比实验。
    内容:
      - 固定场景 eval 可以从 manifest 读取多个 checkpoint，并输出统一 summary。
      - sweep 入口开始承担批量训练配置展开和调度。
      - HATT、MAPPO、legacy GAT 的横向对比配置恢复，模型比较从手工命令转向 manifest。
    commits:
      - 6350fe
      - 48aae0
    结论:
      工程:
        - 模型比较从手动脚本转向固定 eval manifest。
        - 初步具备多模型、多 checkpoint 对比能力。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.6.1:
    时间:
      - 2026-06-24 15:13:12
      - 2026-06-25 12:42:22
    重要性: 9.5
    标题: 训练期 eval、full_random reset 与课程学习
    摘要: 训练中加入定期 eval，支持 deterministic eval、full_random reset 和课程切换。
    内容:
      - eval 支持 deterministic action，减少策略采样噪声对评估结论的影响。
      - 训练 reset mode 和评估 reset mode 分离，可以分别选择固定场景、jitter 或 full_random。
      - curriculum switch 支持训练中途从较稳定 reset 切换到 full_random。
      - v2/v3/v4 sweep 配置围绕 reset、课程学习和评估口径形成对照。
    commits:
      - bac4f9
      - 4d02a0
      - 5fe9b7
    结论:
      工程:
        - 训练期开始产生可比较 eval 点。
        - reset 模式可控后，训练场景与评估场景可以分离。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.6.2:
    时间:
      - 2026-06-26 00:39:07
      - 2026-06-26 18:28:47
    重要性: 9.5
    标题: 观测向量化、best/latest checkpoint 与实验目录规范
    摘要: 加速观测构建，保存 eval best/latest checkpoint，统一 runs/experiments 目录，并解耦算法标签与训练器。
    内容:
      - 环境观测构建向量化。
      - runner 自动保存 eval best/latest checkpoint。
      - 统一实验产物目录到 `runs/`。
      - 训练配置快照随实验归档，便于复现已跑过的实验组。
      - '`algorithm_name` 与 `trainer_algorithm_name` 解耦。'
    commits:
      - dd2122
      - cd1cfe
      - 053539
    结论:
      工程:
        - 实验复现能力显著提升。
        - best/latest checkpoint 的保存使后续可以观察“训练末尾是否退化”。
      进展:
        - 算法标签解耦后，`hattv2.0` 等实验名不再干扰底层 MAPPO/RMAPPO trainer。
      问题:
        - checkpoint 退化问题仍未解决，只是开始被显式记录。
  v0.6.3:
    时间:
      - 2026-06-28 04:00:12
      - 2026-06-28 04:00:12
    重要性: 8.0
    标题: sweep 全 checkpoint eval 与稳定性诊断基础
    摘要: sweep 集成全 checkpoint 评估和多节点 eval 间隔设置。
    内容:
      - sweep 能在训练后遍历 checkpoint 做 eval。
      - runner eval 间隔配置更灵活。
      - 该能力在 HATT v3.1 阶段被接入。
    commits:
      - 8566b9
    结论:
      工程:
        - 后续 2026-07-17 checkpoint 对齐分析可以复用这些 checkpoint 产物。
        - 评估不再只依赖 final actor。
      问题:
        - 这一版只是评估基础设施，尚未给出模型性能结论。
v0.7:
  标题: HATT v3 系列与 PCFA 基线重写
  v0.7.0:
    时间:
      - 2026-06-28 00:16:47
      - 2026-06-28 10:43:21
    重要性: 8.0
    标题: HATT v3.0 / v3.1 消融与稳定化
    摘要: 新增 HATT v3.0、v3.1 系列变体，围绕能力归一化、mask 和诊断输出做稳定性探索。
    内容:
      - HATT v3.0 拆出 a/b/c 变体，围绕更激进的能力建模和联盟推理做探索。
      - HATT v3.1 在 v3.0 基础上做稳定化，重点处理能力归一化、可用任务 mask 和诊断输出。
      - diagnostics 扩展后，训练中可以观察更多 HATT 内部统计，而不只看 reward 曲线。
    commits:
      - 2da1d0
      - 8566b9
      - 80339a
    结论:
      进展:
        - HATT 结构进入更激进的消融阶段。
      问题:
        - 结果层面从后续日志看，该阶段更多是结构探索，不是最终稳定方案。
  v0.7.1:
    时间:
      - 2026-06-28 16:08:13
      - 2026-06-28 16:08:13
    重要性: 8.0
    标题: PCFA 市场化去中心化基线
    摘要: 重写 PCFA 规则基线，并接入 runner 与 sweep。
    内容:
      - PCFA 从早期能力相似度匹配，重写为市场化、去中心化的联盟组建流程。
      - PCFA policy 独立承载规则决策，不再混入训练型 policy。
      - PCFA runner 接入主训练入口和 sweep 体系，可以和 MAPPO/HATT 用同一套场景配置做对照。
      - 小规模训练和 eval 配置补齐规则基线的可复现实验入口。
    commits:
      - 1c5d76
    结论:
      进展:
        - PCFA 从早期占位规则转为可用于论文/实验对照的基线。
        - 后续仍以 MAPPO/HATT 为主线，PCFA 作为规则对照保留。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.7.2:
    时间:
      - 2026-06-29 01:02:05
      - 2026-06-29 17:14:25
    重要性: 8.0
    标题: HATT v3.2 与稳定性消融
    摘要: 新增 HATT v3.2 四个变体，并修复 utility loss 的 available_actions shape。
    内容:
      - HATT v3.2 注册 a/b/c/d 四个变体，围绕过渡感知和极性显式联盟推理继续做结构消融。
      - utility loss 的 available_actions shape 被修正，避免诊断损失在 batch 维度上错配。
      - resume、eval 和稳定性消融配置补齐，方便从已有 checkpoint 继续验证 v3.2。
    commits:
      - c9006a
      - 2d95ca
    结论:
      进展:
        - v3.2 提供了更复杂的联盟推理表达。
        - shape 修复使 utility loss 可正常训练。
      问题:
        - 后续主线没有继续堆叠 v3，而是回到 v2.x 和 delivcoal 语义问题，说明 v3.2 不是最终解决 delivcoal 的稳定版本。
v0.8:
  标题: 探索动作与 coalition_delivery 场景
  v0.8.0:
    时间:
      - 2026-06-29 18:02:29
      - 2026-06-30 02:18:01
    重要性: 8.0
    标题: 扇区探索、survey 探索与带 tag checkpoint
    摘要: 引入 sector/survey 探索动作、带 tag checkpoint，并加入 coalition_delivery 场景。
    内容:
      - 新增 `explore_action_mode`。
      - 支持 sector 探索动作。
      - 支持定期保存带 tag 的 checkpoint。
      - 引入 coalition_delivery 场景与 survey 探索动作模式。
    commits:
      - 3cc4ba
      - 6b6a8f
    结论:
      进展:
        - 动作空间从“选择任务”扩展到包含探索策略选择。
        - coalition_delivery 使环境从能力匹配问题开始转向配送调度问题。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.8.1:
    时间:
      - 2026-07-03 11:26:27
      - 2026-07-03 11:26:27
    重要性: 8.0
    标题: PPO early stopping 与 coalition_delivery reward shaping
    摘要: 加入 PPO early stopping、coalition_delivery 奖励塑形，并补充 HATT 中文注释和失败轨迹分析脚本。
    内容:
      PPO early stopping:
        - PPO 更新加入 target KL 和 clip fraction 监控。
        - 当近似 KL 或 clip fraction 超过阈值时，提前停止当前 PPO epoch 的剩余 minibatch 更新。
        - 训练日志记录 approx_kl、clip_fraction、ratio 统计和实际执行的 PPO update 数。
      coalition_delivery reward shaping:
        - baseline 奖励强化完成奖励、缺货惩罚、空闲/空载/停滞惩罚。
        - shaped 奖励加入进度奖励、积压成本、紧急度压力、切换联盟惩罚和资源补给塑形。
        - 这些信号把配送场景从稀疏完成奖励，改成更容易观察中间行为的奖励结构。
      诊断与文档:
        - HATT v2/v3 网络补充中文说明，解释 backbone、actor、decoder、attention 和 utility head。
        - 失败轨迹分析可以回放 eval 中的失败过程，定位 HATT 在配送场景里卡住、错分配或退化的环节。
    commits:
      - f5966a
    结论:
      进展:
        - PPO 更新更保守，降低单次更新过大导致训练不稳定的风险。
        - reward shaping 提供更稠密的配送/发现/补给/完成信号。
        - 失败轨迹分析开始服务 HATT 在配送场景中的退化诊断。
      问题:
        - 暂无明确失败或遗留问题记录。
v0.9:
  标题: capcoal / delivcoal 拆分与 HATT v2.4-v2.7
  v0.9.0:
    时间:
      - 2026-07-03 16:57:50
      - 2026-07-03 16:57:50
    重要性: 9.5
    标题: capcoal / delivcoal 环境包拆分与 HATT v2.4
    摘要: 将原 MACF 场景拆分为 `capcoal` 和 `delivcoal`，并新增 HATT v2.4。
    内容:
      capcoal / delivcoal 拆分:
        - 把原来混在 MACF 里的两类问题拆开。
        - capcoal 专注能力-需求匹配，保留原任务-能力联盟组建问题。
        - delivcoal 专注探索、配送、补给、deadline、priority、载荷和需求剩余。
        - 训练入口按 `env_name` 路由不同环境，让同一套 MAPPO/HATT runner 可以跑两类问题。
      HATT v2.4:
        - v2.4 面向配送场景保守修正 v2.0，保留“当前联盟聚合到任务槽”的主线。
        - task hidden 作为原始语义主通路，联盟更新通过小门控叠加。
        - A-T 边特征补回距离、载荷、电量、需求、期限、优先级等低阶配送统计。
        - 联盟聚合额外暴露载荷 sum/mean，补充 delivery 场景的资源信息。
      v2.4 对照实验:
        - sweep 配置按 capcoal/delivcoal 分组，避免把两类任务的结论混在同一组指标里。
        - 对照 MAPPO、HATT v2.0 和 HATT v2.4，使用 PPO early stopping、低学习率和线性衰减等稳定超参。
    commits:
      - b2850e
    结论:
      进展:
        - capcoal 保留能力需求匹配问题。
        - delivcoal 聚焦探索、配送、补给、deadline、priority、载荷和需求剩余。
        - 分拆后可以更清楚地看到 HATT 在能力匹配和物流调度两类任务中的不同表现。
      问题:
        - 暂无明确失败或遗留问题记录。
  v0.9.1:
    时间:
      - 2026-07-04 01:18:27
      - 2026-07-04 01:18:27
    重要性: 6.0
    标题: HATT v2.5 与 sweep GPU 调度
    摘要: 新增 HATT v2.5 消融组，并增强 sweep GPU 调度。
    内容:
      HATT v2.5 消融组:
        - 面向 capcoal/delivcoal 的 hard-HATT 消融组，保留 v2.0 当前联盟骨架。
        - 不引入 v3 候选加入差分，也不退回 MAPPO flatten obs。
        - 子变体:
            - v2.5a：对齐 load/demand 等同尺度物流特征。
            - v2.5b：加入探索、补给、空闲等阶段控制特征。
            - v2.5c：用任务类型专属 decoder 分别处理不同动作槽。
            - v2.5 full：同时启用 a/b/c。
      sweep GPU 调度:
        - 批量训练支持 per-GPU 并发限制，避免所有 job 同时抢同一块卡。
        - 增加 spillover 机制，指定任务完成后可把部分任务迁移到空闲 GPU。
        - v2.5 对照覆盖 MAPPO、HATT v2.0、v2.5a/b/c/full。
    commits:
      - 8982d7
    结论:
      工程:
        - v2.5 继续测试 HATT 表示路径对 capcoal/delivcoal 的影响。
      问题:
        - 后续结果表明 delivcoal 仍存在明显退化，推动 v2.6/v2.7 和 reward variants。
  v0.9.2:
    时间:
      - 2026-07-05 18:38:22
      - 2026-07-05 18:38:22
    重要性: 8.0
    标题: HATT v2.6 与 delivcoal recovery
    摘要: 新增 HATT v2.6 任务类型消融组和 delivcoal recovery 评估配置。
    内容:
      HATT v2.6 任务类型消融:
        - v2.6 把任务类型差异内化到 v2.0 主干，而不是继续拼接全局物流/阶段特征。
        - 子变体:
            - v2.6a：任务类型专属 task encoder。
            - v2.6b：任务类型专属 A-T edge fusion。
            - v2.6c：任务类型专属 decoder。
            - v2.6 full：同时启用 a/b/c。
        - 从 capcoal/delivcoal 任务观测中恢复 task type id，保证两类环境都能使用同一组变体。
      recovery 与 checkpoint 评估:
        - delivcoal recovery 只重跑配送场景中的 v2.6 变体，重点观察失败后是否能恢复。
        - combined checkpoint eval 合并原始 run 与 recovery run，统一做 all-checkpoints 评估。
        - 评估口径从 final actor 扩展到 best/latest/周期 checkpoint，减少只看最终模型造成的误判。
    commits:
      - 1ac877
    结论:
      验证:
        - delivcoal recovery 中部分 best checkpoint 可达到较高 success，但 final/latest 经常退化，说明 checkpoint 选择开始成为关键问题。
        - '`analysis/recent_env_hatt_tests_20260713/REPORT.md` 显示，v2.6 在 capcoal 上能出现较好 best 表现。'
      问题:
        - delivcoal latest 仍不稳定，best checkpoint 与 final/latest 的差距明显。
  v0.9.3:
    时间:
      - 2026-07-07 01:08:38
      - 2026-07-07 01:08:38
    重要性: 8.0
    标题: HATT v2.7 动态服务聚合
    摘要: 新增 HATT v2.7，将联盟成员聚合从静态 hidden 改为 task-conditioned member-service 表示。
    内容:
      动态服务聚合:
        - v2.0 的当前联盟聚合使用成员 hidden 表示，在 delivcoal 中难以直接表达载荷、距离、电量、deadline 和 priority 等动态服务条件。
        - v2.7 改为按候选任务生成 member-service 表示，同一个成员面对不同任务会产生不同服务向量。
        - service 特征覆盖:
            - 空间关系：相对位置、距离。
            - 成员状态：assigned flag、capability、load、battery。
            - 任务状态：task need、demand、deadline、priority、task type。
      v2.7 对照实验:
        - 注册 v2.7a、v2.7b 和完整 v2.7，用于区分动态服务特征、任务条件聚合和完整模型的影响。
        - 实验同时覆盖 capcoal 与 delivcoal，检查配送场景改善是否会破坏能力匹配场景表现。
        - 对照包含 MAPPO、HATT v2.0、v2.7a、v2.7b 和完整 v2.7。
    commits:
      - efd2c2
    结论:
      验证:
        - v2.7 在 delivcoal 上可出现较好 best checkpoint，说明动态服务聚合能改善部分训练阶段表现。
      问题:
        - latest 仍可能退化；它不是完整稳定解。
        - capcoal/delivcoal 两类任务上的收益并不一致，仍需要后续信息路径和 reward 诊断。
v0.10:
  标题: delivcoal / capcoal 诊断实验与 checkpoint 可靠性
  v0.10.0:
    时间:
      - 2026-07-07 18:20:06
      - 2026-07-07 18:20:06
    重要性: 8.0
    标题: delivcoal 局部配送奖励 v1/v2
    摘要: 新增 delivcoal reward credit variants，测试局部配送 credit 与 priority/deadline 加权。
    内容:
      局部配送 credit:
        - delivcoal 原 shaped 奖励更偏团队共享信号，难以判断实际 delivery coalition 成员是否拿到足够直接的 credit。
        - '`delivcoal_v1` 把配送进度奖励从全体共享改为当前 delivery task 联盟成员局部 credit。'
        - 这样无关智能体不再因为别的联盟配送成功而获得同一份进度奖励。
      priority/deadline 加权:
        - '`delivcoal_v2` 在 v1 基础上按 priority/deadline 加权配送进度。'
        - 高优先级和临近 deadline 的任务会产生更强学习信号。
        - v2 同时加入轻量过度联盟惩罚，限制过多智能体堆到同一任务导致其他任务缺人。
      reward credit 对照:
        - 对照 MAPPO 与 HATT v2.0 在 baseline、shaped、v1、v2 下的表现。
        - 这组实验用于区分 credit assignment 问题与网络结构问题。
    commits:
      - daf1fd
    结论:
      验证:
        - HATT 某些 best 指标上升，说明局部 credit 能改变学习信号并改善部分 checkpoint。
      问题:
        - '`recent_env_hatt_tests` 显示 v1/v2 会显著改变训练目标：HATT 某些 best 指标上升，但 MAPPO 或 HATT 也可能直接崩溃。'
        - 说明 reward credit 不是简单单调增益，需要更保守的 potential shaping。
  v0.10.1:
    时间:
      - 2026-07-08 00:34:10
      - 2026-07-08 00:34:10
    重要性: 9.5
    标题: delivcoal potential shaping 与 sweep post summary
    摘要: 新增 delivcoal v3/v4/v5 potential shaping，并让 sweep 输出 post summary 和 checkpoint selector。
    内容:
      potential shaping:
        - v1/v2 会重写配送奖励主目标，因此 v3-v5 改为更保守的 potential shaping。
        - '`delivcoal_v3` / `v4` 在 shaped 主奖励上追加不同 scale 的全局配送进度 potential。'
        - '`delivcoal_v5` 把 potential 改成局部配送联盟口径，只奖励当前配送联盟的进度改善。'
        - v3-v5 复用 priority/deadline 权重，检查稠密进度信号是否帮助 HATT 学到配送策略。
      sweep 后处理:
        - sweep 训练结束后自动输出 post summary，汇总最后一次 eval、日志中最佳 eval、保存的 best/latest eval 元数据。
        - checkpoint selector 支持 `last`、`latest`、`best`、`pNN` 和显式 actor 文件名。
        - 实验对照 shaped、v3、v4、v5，把奖励主目标变更和 potential shaping 的效果分开。
    commits:
      - 98a9a3
    结论:
      进展:
        - '`recent_env_hatt_tests` 中 v5 对 HATT latest 有改善迹象，v4 的 best reward 也较高。'
        - post summary 让训练后快速比较 last/best/latest 成为常规流程。
      验证:
        - MAPPO 对不同 reward mode 也很敏感，说明 delivcoal reward shaping 需要与算法一起评估。
      问题:
        - potential shaping 仍不能稳定解决 HATT latest/final 退化；reward mode 与算法强耦合，不能只凭单个 reward 版本下结论。
  v0.10.2:
    时间:
      - 2026-07-08 19:17:33
      - 2026-07-08 19:17:33
    重要性: 8.0
    标题: capcoal requirement 表征模式
    摘要: 新增 `capcoal_req_mode`，拆分 demand 尺度和随机 task identity。
    内容:
      capcoal requirement 表征:
        - capcoal 中 task requirement 可能同时承载需求尺度和随机任务指纹，因此单独抽出 `capcoal_req_mode`。
        - 模式拆分:
            - '`random_demand`：保留随机需求。'
            - '`demand4`：保留 4 维需求向量。'
            - '`demand1`：压缩需求尺度。'
            - '`random_identity`：打乱任务身份。'
        - '`v0`、`v2a`、`v2b`、`v2c` 别名用于把旧实验配置映射到新语义。'
      requirement 消融:
        - 对照 MAPPO 与 HATT v2.0 在不同 req 表征下的表现。
        - 重点检查 HATT 的优势或退化是否依赖 capcoal 的任务需求编码。
    commits:
      - 0c3d24
    结论:
      验证:
        - '`recent_env_hatt_tests` 显示，capcoal 中 HATT 对 requirement 表征敏感。'
        - 在 max_steps=1500 / 10000 的外部 eval 中，`hattv2.0_capcoal-v2a-demand4` 可达到 1.0 success；这说明 task requirement 表征确实影响 HATT
          有效性。
      问题:
        - 该结论主要解释 capcoal requirement 表征；不能直接外推到 delivcoal 的配送稳定性问题。
  v0.10.3:
    时间:
      - 2026-07-17 14:34:04
      - 2026-07-17 14:34:04
    重要性: 9.5
    标题: HATT 稳定性诊断与 checkpoint 关系分析
    摘要: 新增 eval task-type 行为指标和 HATT 稳定性诊断套件，并形成 checkpoint 对齐分析。
    内容:
      eval 行为诊断:
        - eval 同时记录 proposed decision 和 executed action 的 task type 分布。
        - 该指标区分策略想选什么和环境最终执行了什么，尤其关注是否过早 idle/resupply、是否停止探索。
        - 保留 success、completion、reward component 和 premature explorer 等既有指标。
      稳定性诊断套件:
        - 批量运行 MAPPO/HATT 组合，收集训练输出和 eval 输出。
        - 把 task-type 行为、checkpoint 位置、训练期 eval 和独立多 seed eval 对齐到同一口径。
        - checkpoint 关系分析修正训练 checkpoint 与评估 checkpoint 的匹配方式，避免把不同时刻的模型结果混在一起比较。
        - 诊断重点从单条曲线转为“训练指标、训练期 eval、独立 eval 三者之间是否一致”。
    commits:
      - f9daf6
    结论:
      工程:
        - checkpoint 选择策略从“看训练 reward”转向“至少看多 seed eval”。
        - 训练期 8-seed eval 与 32-seed eval 的关系明显强于单局训练指标。
      问题:
        - 训练单局 reward/length 与 32-seed eval 只有弱到中等关系。
        - 训练期 8-seed eval 与 32-seed eval 关系强得多，但因 seed 子集重叠，不能当作完全独立泛化结论。
v0.11:
  标题: GymRT2A / MARL-MRT2A 迁移
  v0.11.0:
    时间:
      - 2026-07-19 18:00:15
      - 2026-07-19 18:00:15
    重要性: 9.5
    标题: GymRT2A 环境适配器与空间 HATT actor
    摘要: 接入 GymRT2A 环境，将空间候选格点适配到现有 MAPPO/HATT 框架。
    内容:
      GymRT2A 环境适配器:
        - 将 RA-L 2025 MRT2A 网格任务纳入同一套训练与评估路径。
        - 空间动作格点被包装成项目统一的离散候选动作，使 MAPPO/HATT runner 能复用原有 collect、insert、eval 流程。
        - GymRT2A runner 处理 action-grid、mask、episode info 和评估统计，避免把外部环境逻辑混进 MACF 环境。
        - train/eval 入口通过 `env_name=gymrt2a` 或 `mrt2a` 切换 benchmark。
      空间候选 HATT actor:
        - HATT actor 把每个 grid cell 当作 agent-candidate pair 评分。
        - 该设计延续 HATT 的 candidate scoring 思路，而不是把 GymRT2A 当普通扁平动作分类。
        - GymRT2A 专用 actor 按空间环境读取 ego/other 维度，并复用现有 HATT/MAPPO 策略入口。
      smoke 与迁移实验:
        - smoke 配置先验证适配器能完成 rollout/eval。
        - migration sweep 再比较 MAPPO 与 HATT 在 GymRT2A 上的迁移表现。
    commits:
      - 8b278a
    结论:
      进展:
        - 项目从自定义 MACF/capcoal/delivcoal 扩展到外部 GymRT2A benchmark。
      验证:
        - smoke/migration 配置显示适配器 rollout/eval 链路可运行。
      问题:
        - 完整性能结论仍要等官方 baseline 和 HATT sweep 完成。
  v0.11.1:
    时间:
      - 2026-07-19 21:50:13
      - 2026-07-19 21:50:13
    重要性: 9.5
    标题: MARL-MRT2A 官方基线 vendoring 与复现入口
    摘要: 将 MARL-MRT2A 官方 baseline vendored 到 `third_party`，并新增官方复现调度脚本。
    内容:
      MARL-MRT2A vendored baseline:
        - GymRT2A 需要和论文/官方实现做同机对照，因此引入官方 MARL-MRT2A/EPyMARL baseline。
        - vendored baseline 保留许可证、引用信息、官方环境、PCFA、EPyMARL 配置和预训练权重。
        - 缓存、egg-info 和运行日志不纳入版本化内容。
      官方复现入口:
        - 官方复现入口封装 paper setting，避免手动进入 third_party 目录改命令。
        - reproduction queue 支持按 seed 排队运行官方 baseline，便于和本项目 HATT/MAPPO 结果对齐。
        - 同步加入 paper setting HATT sweep，让官方 baseline 和本项目方法使用更接近的实验口径。
    commits:
      - def3c9
    结论:
      工程:
        - 建立官方 baseline 对照能力。
      问题:
        - 会话记录显示官方 5 seed 复现实验耗时很长；2026-07-21 至 2026-07-22 时官方复现仍在运行，尚未形成完整官方 vs HATT 最终对比。
v0.12:
  标题: HATT v2.0 信息路径消融
  v0.12.0:
    时间:
      - 2026-07-21 23:58:37
      - 2026-07-21 23:58:37
    重要性: 9.5
    标题: raw / physics / taskattn 信息路径
    摘要: 新增 HATT v2.0 decoder-only 信息路径消融，并删除旧 v26 ad-hoc eval 脚本。
    内容:
      HATT v2.0 信息路径消融:
        - delivcoal 中 HATT v2.0 的失败可能来自 decoder 信息不足，而不是 backbone、reward 或 critic 本身。
        - 因此本次只改 actor decoder 的信息路径，保持 v2.0 encoder、当前 coalition aggregation 和 PPO 接口不变。
        - 子变体:
            - '`hatt_v2_0_raw`：给 decoder 追加未编码 task row，检查 raw task bypass 是否足够。'
            - '`hatt_v2_0_physics`：追加 delivery load、deficit、ETA 等反事实物理统计。'
            - '`hatt_v2_0_taskattn`：在 physics 基础上加入 candidate-task-conditioned member attention。'
      信息路径对照实验:
        - 实验聚焦 delivcoal，比较 MAPPO、HATT v2.0、raw、physics、taskattn。
        - 旧 v26 ad-hoc checkpoint eval 被迁移到通用 sweep/eval 体系，后续实验不再维护单次脚本。
    commits:
      - 08ebbc
    结论:
      工程:
        - raw、physics、taskattn 三条 decoder-only 信息路径已经形成，且保持 v2.0 backbone、critic 和环境不变，便于做归因。
      问题:
        - 尚未看到完整多 seed 评估结论。
        - 该版本只改变 actor 信息路径，仍不能说明 reward、环境动态或 critic 是否也是 delivcoal 失败来源。
  v0.12.1:
    时间:
      - 2026-07-22 11:02:41
      - 2026-07-22 11:02:41
    重要性: 8.0
    标题: resource / setctx 变体
    摘要: 新增 resource features 和 task-set candidate context，测试资源阶段和候选集合上下文。
    内容:
      resource 与 set-context 信息路径:
        - raw/physics/taskattn 仍主要是 pair-wise decoder 信息，delivcoal 还需要判断候选任务之间的资源竞争和行动阶段差异。
        - '`hatt_v2_0_resource` 在 physics 特征上追加 action type、资源状态和阶段特征，并屏蔽 persistent Idle。'
        - '`hatt_v2_0_setctx` 让候选任务 slot 通过 task-set attention 比较其他可行动作。'
        - 训练器、critic 与环境接口保持不变，便于和原 physics 变体对照。
      resource/setctx 对照实验:
        - 实验比较 physics、resource、setctx 及稳定参数设置。
        - 目标是观察资源特征和候选集合上下文是否改善 latest/final 退化。
    commits:
      - aac18b
    结论:
      验证:
        - resource/setctx 变体已经跑出 post summary 产物，说明实验链路可执行。
      问题:
        - 尚未看到最终评估结论。
        - 已产生 post summary 产物；会话记录显示 resource/setctx 队列在当时仍处于运行和检查状态。
  v0.12.2:
    时间:
      - 2026-07-22 22:26:08
      - 2026-07-22 22:26:08
    重要性: 8.0
    标题: no-idle 变体与 resource 复现实验
    摘要: 新增 no-idle actor，隔离 persistent Idle mask 与 resource features 的贡献，并补充多 seed 复现实验。
    内容:
      no-idle 变体:
        - resource 变体同时加入资源特征和 persistent Idle 屏蔽，需要单独隔离 Idle 屏蔽本身的贡献。
        - '`hatt_v2_0_noidle` 复用 physics 信息路径，只屏蔽 persistent Idle，不加入 resource 特征。'
        - checkpoint 兼容 `hatt_v2_0_physics`，方便复用已有物理信息路径权重。
      resource/no-idle 复现实验:
        - 实验包含 noidle 多 seed 与 resource 追加 seed。
        - 统一 best/p90/last checkpoint selector 和 held-out eval 设置。
        - 这组配置用于检查前一轮 resource 改善是否稳定，以及改善来自资源特征还是 Idle 屏蔽。
    commits:
      - 349feb
    结论:
      工程:
        - no-idle/resource replication 实验入口已经建立，可以隔离 Idle 屏蔽与 resource 特征的贡献。
      问题:
        - 尚未看到最终评估结论。
        - 该版本记录的是 no-idle/resource replication 实验入口，结果仍待后续评估汇总。
v0.13:
  标题: Idle 有限等待语义与配送分配诊断
  v0.13.0:
    时间:
      - 2026-07-23 16:54:16
      - 2026-07-23 16:54:16
    重要性: 8.5
    标题: Idle timeout、payload allocation 指标与 delivcoal 对照实验
    摘要: 加入有限 Idle 等待语义、payload 分配诊断、eval idle 行为指标，并新增 delivcoal idle 语义复现实验。
    内容:
      Idle 有限等待语义:
        - 新增 `idle_max_wait_steps` 配置；默认 `<=0` 保持旧的事件触发式 Idle 行为。
        - 当智能体持续选择 Idle 且等待步数达到阈值时，环境会重新激活该智能体，避免 persistent Idle 无限挂起。
        - Idle 被关键事件、全局静止或 timeout 重新激活后，会重置等待计数并清除 timeout ready 状态。
        - capcoal 与 delivcoal 同步实现该语义，保持两类环境的动作调度一致。
      payload allocation 诊断:
        - 环境 info 增加 `allocation_diagnostics`，按已发现且未完成的 delivery task 汇总 committed load。
        - 诊断输出 payload shortage/surplus、idle agent 数、harmful/useful idle agent 数和 idle timeout reactivation 次数。
        - harmful idle 定义为仍有 payload deficit 时，携带载荷却停在 Idle 的存活智能体。
        - 这些指标不改变环境动力学，只用于 eval、日志和离线分析。
      eval 行为指标:
        - eval summary 增加 harmful/useful idle agent step ratio、idle timeout reactivations、max idle duration。
        - 同时记录 committed payload shortage/surplus ratio，用于观察策略是否把载荷合理分配到未完成配送任务。
        - sweep 的 eval overrides 支持透传 `idle_max_wait_steps`，保证训练和 checkpoint 评估口径一致。
      delivcoal idle 语义实验:
        - 新增 HATT v2.0 finite-idle smoke 配置，用 10 episode 快速验证新语义能跑通。
        - 新增 delivcoal sweep，比较 HATT v2.0 与 MAPPO 在 `idle_max_wait_steps=25` 下的多 seed 表现。
        - sweep 评估固定 best/p90/last checkpoint selector，并使用 held-out deterministic eval。
        - 本次更新同时把根目录 `CHANGELOG.yaml` 纳入版本控制，后续版本日志不再只停留在 `docs/` 本地草稿。
    结论:
      验证:
        - 发现: Idle-25 排除了“单次 Idle 无限持续”是 HATT 失败主因。
          依据:
            - 有限等待能把单次 Idle 最长持续限制在约 25 步。
            - HATT 被 timeout 唤醒后仍会反复选择 Idle，HATT p90/last 成功率仍明显退化。
            - MAPPO 同口径约 90% success，且几乎不选择 Idle。
        - 发现: No-Idle 明显优于 Idle-25，说明当前 Idle 仍主要是有害自由度。
          依据:
            - HATT No-Idle best 在同一批测试场景上约 87.76% success。
            - HATT Idle-25 best 约 77.08% success。
            - 配对比较中 Idle-25 比 No-Idle 低约 10.68%，McNemar p=1.61e-05。
      判断:
        - finite idle 更适合作为诊断和临时干预，不是 delivcoal 中 HATT persistent Idle 的最终语义修复。
        - HATT 的剩余差距更可能来自 policy 对 Idle 动作概率的漂移，而不是一次 Idle 持续时间过长。
      问题:
        - HATT-best 到 p90/last 仍有明显退化，checkpoint 稳定性没有解决。
        - allocation diagnostics 当前主要按 payload demand/load 计量，不能覆盖 perception、mobility、battery、deadline 等完整联盟边际贡献。
        - capcoal 同步了 diagnostics 和 idle timeout 语义，但实验结论主要来自 delivcoal。
      工程:
        - '`CHANGELOG.yaml` 已移到根目录并加入版本控制，版本日志本身成为可追踪内容。'
    commits:
      - b413f4
v0.14:
  标题: HATT 待命问题、分区探索与预留运力诊断
  v0.14.0:
    时间:
      - 2026-07-24 16:57:00
      - 2026-07-28 11:05:21
    重要性: 9.0
    标题: 定位 HATT 错误待命，并修正分区探索
    摘要: HATT v2.0 在配送环境中会反复选择 Idle，同时新的分区探索方式几乎无法完成任务。本次分别检查特殊动作是否干扰配送任务表示，修正智能体到达探索目标后的重新决策时机，并增加统一的训练进度和 checkpoint 评估支持。
    内容:
      分开检查特殊动作对配送的影响:
        - HATT 原本用同一种候选任务表示处理 Deliver、Explore、Idle 和 Resupply，特殊动作可能因此干扰配送任务之间的关系建模。
        - 新增三组对照：只禁止 Idle（clean no-idle）、让特殊动作不参与配送联盟聚合（detached），以及让特殊动作使用独立输出头（split）。
        - 另行加入显式任务类型编码和门控，检查模型能否更稳定地区分配送、探索、待命和补给。
        - 从固定状态修改 Idle 的联盟信息、替换特殊动作表示并打乱任务槽顺序，观察错误待命究竟依赖哪些输入。
      修正分区探索的决策时机:
        - 智能体到达一个分区探索目标后立即重新请求策略决策，不再把这段移动误认为所有智能体共享的 Explore 任务已经完成。
        - 发现新任务后重新安排正在探索的智能体，让它们可以及时转去配送，而不是继续执行过时的探索目标。
        - 屏蔽地图边界处无法带来有效移动的探索方向，减少无效动作对训练的干扰。
        - 评估从“直接前往最近未发现任务”的理想化探索，转为由策略选择真实搜索方向。
      统一训练进度和 checkpoint 评估:
        - 进度工具统一读取实验状态和训练日志，命令行与网页使用同一份进度数据。
        - 长时间 checkpoint 评估会持续更新时间，避免仍在运行的任务被误判为停止。
        - checkpoint 同时保存 ValueNorm 状态，使离线评估尽量恢复训练时的价值归一化条件。
        - 修正 GymRT2A 对照实验在 HATT 阶段继承错误 CUDA 设置的问题，避免基线复现影响本项目训练设备。
      对照实验:
        - 比较上述特殊动作处理方式和任务类型编码，定位反复 Idle 的主要来源。
        - 比较原始分区探索、到达目标后重新决策和边界动作屏蔽，判断探索失败来自方向选择还是调度语义。
      版本日志查看:
        - 根目录使用结构化 YAML 保存版本记录，`html_logs/changelog.html` 可以动态读取并展示，不需要每次重新生成网页。
    结论:
      验证:
        - 发现: 把一次 Idle 最长限制为 25 步，仍不能阻止 HATT 反复待命，因此问题不只是单次 Idle 持续过久。
          依据:
            - 有限等待能限制一次 Idle 的持续时间，但 HATT 被唤醒后仍反复选择 Idle。
            - HATT-best success 约 77.1%，p90/last 约 32.8% / 34.6%；MAPPO 同口径约 90%，且几乎不选 Idle。
        - 发现: 在相同状态下移除 Idle 动作携带的联盟信息，会一致降低模型选择 Idle 的倾向，说明这部分输入确实会放大错误待命。
          依据:
            - 9/9 个 checkpoint 清空 Idle 的联盟上下文后，Idle 相对其他动作的概率优势都下降。
            - 但训练较差的 checkpoint 在实际轨迹中仍会继续偏好 Idle，因此联盟信息只能解释部分问题。
        - 发现: 将特殊动作从配送联盟聚合中移除后，HATT 明显改善，说明特殊动作与 Deliver 共用表示很可能是主要问题来源。
          依据:
            - detached 版本三个随机种子的 best 成功率约 0.75 / 1.00 / 0.875，均值约 0.875。
            - 原 HATT v2.0 在不限制 Idle 时，best 成功率均值约 0.50。
        - 发现: 移除特殊动作干扰后，HATT 不再依赖固定的任务槽顺序。
          依据:
            - 3 个 detached best checkpoint 在 128 个场景中，打乱前后成功率完全一致。
            - MAPPO 在打乱全部任务槽后成功率降为 0，说明这种检查确实能暴露模型对槽位顺序的依赖。
        - 发现: 直接前往最近未发现任务给了策略过强的先验；改为真实的方向选择后，探索难度大幅上升。
          依据:
            - 换成真实的分区方向选择后，MAPPO 和 HATT 的原始分区探索实验成功率都是 0。
            - HATT best 任务完成率均值约 0.275，MAPPO 接近 0；HATT 能推进部分任务，但无法完成整个回合。
        - 发现: 到达探索目标后重新决策可以明显改善结果，说明原来的探索失败也来自错误的动作调度语义。
          依据:
            - 加入“到达目标或发现任务后重新决策”后，HATT best 成功率从 0 提高到约 0.292。
            - HATT best 任务完成率从约 0.275 提高到约 0.767；MAPPO best 成功率也从 0 提高到约 0.167。
      判断:
        - HATT v2.0 在配送环境中的核心问题，更可能是 Explore、Idle 和 Resupply 与 Deliver 共用候选任务及联盟表示，干扰了配送任务之间的关系建模。
        - Idle 携带的联盟上下文是真实缺陷，但训练后期较差的 checkpoint 还有不依赖这部分输入的持续 Idle 偏好。
        - 显式任务类型信息有帮助，但当前结果还不能证明任务类型 gate 是稳定解法。
      问题:
        - 移除特殊动作干扰后的 best checkpoint 很强，但训练末期仍明显退化；三个随机种子的 last 成功率约为 0 / 0.375 / 0，说明找到了结构问题，却没有解决 PPO 后期策略漂移。
        - MAPPO 在不限制 Idle 的相同条件下，best 和 last 成功率都是 1.0，仍是该配送环境中更稳定的强基线。
        - 加入探索目标后的重新决策后，成功率仍然偏低；边界动作屏蔽的完整批量结果尚未形成。
        - 显式任务类型变体没有稳定解决成功率和训练末期退化，仍需与“移除特殊动作聚合”和“特殊动作独立输出”在相同条件下比较。
      工程:
        - sweep 进度可以从 runs/status.json 和训练日志统一读取，并发布脱敏静态 JSON 给 `html_logs` 页面。
        - checkpoint 保存 ValueNorm 后，后续 checkpoint 评估和离线诊断更容易复现训练时上下文。
        - commit message 和 CHANGELOG 的写法被固定到代理文档中，后续大更新不再依赖临时口头约定。
        - 版本日志现在既能被 git 追踪为结构化 YAML，也能通过 `html_logs/changelog.html` 在外网穿透页面中动态查看；页面和 js-yaml 依赖仍作为 ignored 静态产物管理。
    commits:
      - 6831b9
  v0.14.1:
    时间:
      - 2026-07-29 11:47:34
      - 2026-07-30 13:55:03
    重要性: 8.0
    标题: 为探索加入覆盖信息，并比较是否需要记忆
    摘要: 让智能体看到自己已经搜索过哪些区域，并分别绕过任务发现阶段、屏蔽探索动作，判断 HATT 的失败究竟来自探索信息不足、缺少历史记忆，还是训练后期不稳定。所有改动都保持原有任务槽和动作维度，已有 checkpoint 可以直接复用。
    内容:
      分开检查探索和配送:
        - 可以在环境重置时直接公开全部配送任务（`delivery_tasks_initially_discovered`），用来检查智能体在不需要找任务时能否完成配送。
        - 可以屏蔽 Explore 动作但保留原有动作槽（`mask_explore_actions`），因此旧 checkpoint 也能在“只运输、不探索”的条件下评估。
        - 训练、独立评估和批量实验使用同一组开关，避免比较时实际运行了不同条件。
      让智能体知道搜索进度:
        - 新增 coverage 网格，用智能体的感知范围近似记录地图中已经搜索过的区域。
        - 每个智能体看到的探索目标改为从自身位置出发实际会前往的 sector，而不是所有智能体共享同一份抽象任务描述。
        - Explore 观测增加沿候选路径可发现的新区域、路径长度和全局未搜索比例，同时保持 HATT 输入维度不变。
        - 日志记录已搜索面积比例（`explored_area_ratio`），可以直接判断探索动作是否带来了新覆盖。
      检查训练后期是否失稳:
        - MAPPO 和 HATT 的 PPO 更新都增加概率比率分位数、近似 KL 散度和裁剪比例等指标。
        - 这些指标只统计真正参与更新的样本，避免无效样本掩盖极端更新，从而检查 checkpoint 后期退化是否来自 PPO 更新异常。
      对照实验:
        - 比较 HATT+coverage、HATT+RNN、HATT+coverage+RNN 和 MAPPO+coverage，每种条件运行 3 个随机种子。
        - 训练期间定期做小规模评估，训练结束后统一评估 best、p90 和 last checkpoint。
    结论:
      进展:
        - 这次把 HATT 失败拆成更可控的四个子问题：任务是否可见、探索动作是否干扰配送、显式 coverage 是否补足状态、PPO 更新是否出现异常漂移。
        - delivery-only 开关能在不重训网络结构的情况下复用旧 checkpoint，适合快速验证“已知任务下是否仍然不会配送”。
      验证:
        - 发现: sector 观测原先对所有 agent 共享 nominal 任务特征，不足以表达“当前 agent 走这个方向会搜索哪里”。
          依据:
            - 两个位置不同的 agent 对同一 sector 槽得到不同 goal，说明 observer-relative 表征已经生效。
            - agent 运动段会标记 coverage 网格，`explored_area_ratio` 可以随实际搜索推进变化。
        - 发现: delivery-only 诊断保留了原任务槽和可用动作 shape。
          依据:
            - 开启预发现和屏蔽探索后，`task_num` 与 available action shape 不变，配送槽可用、Explore 槽被屏蔽。
        - 发现: 显式 coverage 信息对 HATT 的提升是决定性的，而 recurrence 单独不是主要解法。
          依据:
            - 12/12 训练成功，36/36 个 best/p90/last checkpoint eval 成功，流程于 2026-07-30 13:55:03 完成。
            - best checkpoint 下 HATT+coverage 成功率约 74.5%，三 seed 为 71.9% / 75.8% / 75.8%。
            - HATT+coverage+RNN best 成功率约 70.3%，HATT+RNN 约 24.2%，MAPPO+coverage 约 4.4%。
            - HATT+coverage 的发现率约 98.2%、任务完成率约 96.9%、死亡数约 0.02，明显好于无 coverage 路径。
        - 发现: coverage 更像是修复探索输入缺口，而不是单纯让策略记住历史轨迹。
          依据:
            - HATT+RNN 的执行探索比例仍约 56.9%，成功率只到约 24.2%。
            - HATT+coverage 的执行探索比例降到约 36.8%，执行配送比例升到约 38.4%，说明策略能更早从探索切回配送。
      问题:
        - 这些开关主要是归因工具，尚不等于证明 HATT 的最终修复方案。
        - coverage 网格是近似观测，不是精确几何覆盖；分辨率会影响 explored area 指标的平滑程度。
        - PPO 指标能暴露更新异常，但从当前结果看 coverage 修复状态信息后仍有 checkpoint 震荡；last 成功率约 62.2%，低于 best 的约 74.5%。
        - RNN 是否在 coverage 之上有稳定增益仍不清楚；best 口径 coverage+RNN 略低于 coverage，p90/last 口径更接近。
      工程:
        - 新配置已进入 `config.py` / `config.yaml`，sweep 和 eval 路径可以直接复用。
    commits:
      - 724362
  v0.14.2:
    时间:
      - 2026-07-30 22:50:17
      - 2026-07-30 23:53:28
    重要性: 7.5
    标题: 区分 coverage 对探索和配送的作用
    摘要: 复用已有 HATT+coverage checkpoint，分别测试“任务全部可见”和“任务全部可见且禁止探索”，判断 coverage 带来的提升主要来自更会找任务，还是也改善了已知任务下的配送决策；同时比较确定性选取和随机采样动作。
    内容:
      复用已有模型改变评估条件:
        - 新增条件评估脚本，直接读取已完成训练的配置和 checkpoint，不需要为每个问题重新训练模型。
        - 可以精确选择要评估的实验，只比较 3 个前馈 HATT+coverage 模型，避免混入 MAPPO、RNN-only 和 coverage+RNN。
        - 评估进度和各条件汇总继续写入统一状态文件，现有进度页面可以直接读取。
      探索与纯运输对照:
        - 3 个 best checkpoint 都在相同的 128 个随机场景和相同随机种子下评估。
        - 一组条件只让全部任务初始可见，另一组还禁止 Explore；两组都分别测试确定性选取和随机采样动作。
      修正评估条件未生效的问题:
        - 首次运行发现训练配置中的默认值覆盖了临时评估条件，所谓“只运输”实际仍可选择 Explore，因此该批结果无效。
        - 调整配置优先级后重新完成全部 12 项评估，后续结论只使用修正后的结果。
    结论:
      验证:
        - 发现: HATT+coverage 在所有任务初始可见时，确定性 best 成功率约 94.8%，任务完成率约 99.2%，说明给足任务可见性后配送闭环很强。
          依据:
            - all-discovered deterministic 三 seed 平均 success 约 0.948，episode length 约 572.4。
            - 同条件下执行配送比例约 49.6%，执行探索比例仍约 22.5%，说明即使任务全可见，策略仍会保留一定 Explore 行为。
        - 发现: 屏蔽 Explore 的 deterministic delivery-only 成功率只有约 64.1%，但 stochastic delivery-only 提到约 80.7%。
          依据:
            - delivery-only deterministic success 约 0.641，任务完成率约 87.3%。
            - delivery-only stochastic success 约 0.807，任务完成率约 94.7%，平均 episode length 约 559.3。
        - 发现: coverage 的主要直接收益仍是探索观测有效性，纯运输能力存在改善迹象但不能简单归因为 Deliver 表征变强。
          依据:
            - 正常 best eval 中 HATT+coverage 发现率约 98.2%，执行探索比例约 36.8%，明显少于 RNN-only 的约 56.9%。
            - delivery-only 下去掉 Explore 后确定性策略反而退化，说明训练出的策略仍依赖“可选 Explore / Resupply / Deliver”之间的动作分布结构。
      判断:
        - coverage 修复了“探索动作输入与真实执行结果不对应”的核心信息缺口；运输提升主要来自更早发现任务、少死、少重复探索和保留更多配送时间。
        - 随机 delivery-only 优于确定性 delivery-only，提示确定性 argmax 可能卡在过度 Resupply 或局部动作偏好，纯运输策略仍需要进一步诊断。
      问题:
        - 22:50 批次是无效评测，只保留为错误诊断记录；正式结论只使用 23:23 批次。
        - 这次只评估 HATT+coverage best checkpoint，没有同步旧 HATT、MAPPO 或 latest checkpoint 的同条件矩阵，不能完整回答“相对旧模型的纯运输提升幅度”。
        - delivery-only stochastic 中 harmful idle agent step ratio 约 12.2%，说明待命/Idle 语义和纯运输调度仍有明显问题。
      工程:
        - 条件矩阵脚本修复了 eval-only override 优先级，后续类似反事实评估不应再被训练配置默认值悄悄覆盖。
        - 评估配置和矩阵脚本可以复用已有 checkpoint 做条件反事实评估；实际 `runs/` 结果仍作为实验产物保留在未跟踪目录。
    commits:
      - 7662ab
  v0.14.3:
    时间:
      - 2026-07-31 03:31:56
      - 2026-07-31 03:31:56
    重要性: 4.0
    标题: CHANGELOG 时间与补录规则固化
    摘要: 将版本日志时间戳和补录规则写入 AGENTS / CLAUDE，明确 CHANGELOG 时间使用研究事件区间，最新版本提交时不写自己的 commits 和结论。
    内容:
      时间戳规则:
        - '`时间` 记录本次更新对应的研究 / 工程事件区间，不机械等同于 git commit 时间。'
        - 第一个时间通常是开始本次修改、准备实验或启动训练的时刻；第二个时间通常是关键训练、评估或验证完成的时刻。
        - 单一事件点可以写成两个相同时间，由渲染器折叠显示。
      补录规则:
        - 每次维护 CHANGELOG 时，优先检查上一个已经提交的子版本是否缺少 `commits` 和 `结论`。
        - 上一个版本的 hash 和结论依据已经完成的训练、评估或验证结果补录。
        - 当前新写的最后一个子版本只写内容，不写自己的 `commits` 和 `结论`，留待下一次维护。
    结论:
      工程:
        - AGENTS.md 和 CLAUDE.md 已统一说明 CHANGELOG 时间采用研究 / 工程事件区间，而不是机械使用 commit 时间。
        - 当前版本提交时最后子版本不写自己的 `commits` 和 `结论`；下一次维护再根据已存在提交和已完成验证补录。
      判断:
        - 这个规则更符合本项目的实验节奏，因为一个版本通常跨越实现、启动训练、评估完成和事后整理，单个 commit 时间不能解释完整过程。
        - "`commits` 延后回填可以避免在 commit message 或 CHANGELOG 中引用尚不存在的自身 hash。"
      问题:
        - 旧版本的时间字段之后应按事件区间理解，后续维护不能再用 `git log` 时间直接覆盖。
    commits:
      - b69fce
  v0.14.4:
    时间:
      - 2026-07-31 03:37:11
      - 2026-07-31 03:37:45
    重要性: 6.5
    标题: 检查智能体是否在有任务可做时错误待命
    摘要: 在所有配送任务已知且禁止探索的条件下，逐次检查 HATT 和 MAPPO 的待命决策：如果智能体仍能为某个任务提供缺少的载荷，却选择 Idle，就从同一状态强制它去配送，比较两种选择之后的任务结果。
    内容:
      要回答的问题:
        - v0.14.2 发现模型在纯运输条件下仍会待命。这次进一步区分：智能体是确实没有可做的事，还是错过了本可参与的配送任务。
        - 对比 HATT+coverage 和 MAPPO+coverage 各 3 个随机种子的 best 与 last checkpoint，观察 HATT 的训练后期退化是否集中表现为错误待命。
      判断一次待命是否合理:
        - 每当智能体需要决策时，计算它还能为哪些未完成任务补充有效载荷，并扣除其他智能体已经承诺送往同一任务的载荷。
        - 如果策略选择 Idle，但该智能体仍能补足某个任务的载荷，就记为“有配送机会却待命”；如果所有任务都已获得足够运力，则视为可能合理的待命。
        - 所有任务从开始就可见，并禁止 Explore，使判断只涉及配送、补给和待命。
      从同一状态比较 Idle 和 Deliver:
        - 对可疑的 Idle 决策复制完整环境和策略状态，一条分支保留原决策，另一条只把当前智能体改派到最需要且策略最倾向的配送任务。
        - 两条分支复用相同的随机状态，尽量让结果差异来自这一次动作，而不是后续随机采样。
        - 这种比较只能说明“按当前策略继续运行时，改掉这次 Idle 有何影响”，不能证明强制配送是全局最优动作。
      记录结果:
        - 同时保存逐次决策、两条后续分支、每局结果和不同模型的汇总。
        - 汇总重点比较错误待命比例，以及强制配送后成功率、任务完成度、剩余需求和完成时间是否改善。
    结论:
      工程:
        - 已经可以逐次识别“有配送机会却待命”的决策，并从同一状态比较待命和配送的后续结果。
        - 后续发现只检查配送仍然太窄：智能体即使当前没有载荷，也可能应该先去补给，而不是待命。
      判断:
        - 错误待命不能只按“当前能否直接参与配送”判断；当全局仍缺载荷时，空载智能体不去补给也应视为可疑。
        - 对照动作应允许配送或补给，不能预先假定所有错误待命都应该改成 Deliver。
      问题:
        - 该版本只是诊断工具，还没有形成训练或机制层面的修复。
    commits:
      - 92c6d4
  v0.14.5:
    时间:
      - 2026-07-31 12:26:24
      - 2026-07-31 22:37:15
    重要性: 8.0
    标题: 取消 Idle 额外惩罚，检查能否保留空闲运力
    摘要: 把“本可做事却待命”扩展为配送和补给两种情况，并取消奖励函数对 Idle 额外施加的时间惩罚。随后重新训练 HATT 和 MAPPO，检查没有直接惩罚后，策略是否会主动让暂时多余的智能体保持空闲，以便响应后续任务。
    内容:
      补上“应该补给却待命”的情况:
        - 除了检查智能体能否直接为任务补充载荷，还统计所有已派出智能体承诺的总载荷是否足以完成剩余任务。
        - 如果智能体已经空载、全局仍缺载荷且可以补给，它选择 Idle 就记为“应该补给却待命”。
        - 同状态对照动作现在可以是配送或补给，避免把所有错误待命都解释成错过配送任务。
      消除奖励对 Idle 的直接偏见:
        - 新增统一时间成本模式（`idle_time_cost_mode: uniform`），只取消 Idle 与其他动作之间额外的惩罚差异，其他奖励保持不变。
        - 旧奖励在仍有任务时对 Idle 每步扣 0.04、对其他动作扣 0.02；新模式让两者承担相同的基础时间成本。
        - 训练和 checkpoint 评估都读取同一配置，避免训练时取消偏置、评估时又恢复旧奖励。
      重新训练 HATT 和 MAPPO:
        - 在相同环境和探索设置下，只改变 Idle 时间成本；HATT v2.0 和 MAPPO 各运行 3 个随机种子。
        - 训练结束后统一比较 best、p90 和 last checkpoint，判断收益是否稳定保持到训练末期。
      检查策略是否会预留运力:
        - 人工构造四类任务分配状态，分别覆盖运力刚好、运力富余、只差一个智能体和运力分配错误的情况。
        - 比较完整 HATT 与几种移除 Idle 相关信息的模型，观察它们会把多少智能体留在 Idle。
        - 同时检查 best 和 last checkpoint，判断训练后期退化是否改变了预留运力行为。
    结论:
      验证:
        - 发现: 去掉 Idle 的直接额外时间惩罚后，HATT best 成功率显著改善，但改善不是来自学会使用 Idle。
          依据:
            - HATT 和 MAPPO 共 6 次训练全部完成，18 个 best/p90/last checkpoint 也全部完成评估。
            - HATT best 的综合成功率从旧时间成本下的约 13.28% 提高到统一时间成本下的约 27.34%，p90 从约 9.90% 提高到约 15.63%。
            - HATT best 的任务完成数约 7.229 -> 8.409，发现率约 74.17% -> 86.04%，死亡数约 0.648 -> 0.240。
            - 所有确定性 checkpoint 评估中，策略都没有选择或实际执行 Idle，因此提升不能归因于学会待命。
        - 发现: MAPPO 在相同 uniform cost 下仍然很弱，说明 MAPPO 的差表现不是由 Idle 时间成本偏置单独造成。
          依据:
            - MAPPO best 成功率约 1.82%，p90 约 0.52%，last 约 0.78%，与旧时间成本基本处于同一水平。
        - 发现: 控制状态诊断中，HATT 仍不会把冗余运力正确留作 reserve。
          依据:
            - 6 个 HATT best/last checkpoint 在 32 个场景和 4 类分配状态上共完成 768 次检查。
            - 在现有运力刚好覆盖任务的状态下，best checkpoint 给两个多余智能体分配到 Idle 的期望数量仅约 0.00826，last 约 0.00091，实际首选 Idle 的数量为 0。
            - 没有任何 checkpoint 在人工构造的状态中给出完全正确的运力分配。
      判断:
        - 统一时间成本是合理的建模修正：Idle 不应仅仅因为动作类型不同而额外扣分。
        - HATT best 的提升更像来自探索覆盖、sector 分散、更少死亡和更多 Deliver 决策，而不是 reserve 行为出现。
        - 当前环境没有让原地待命产生稳定收益，仅取消奖励偏置不足以让策略学会预留空闲运力。
      问题:
        - HATT 训练末期仍明显退化；综合成功率从 best 的约 27.34% 降到 last 的约 14.32%，其中 seed 3 从 31.25% 降到 3.91%。
        - 训练期间每次只评估 8 个 episode，波动太大，不足以可靠选择 checkpoint。
      工程:
        - "统一时间成本（`idle_time_cost_mode: uniform`）可以作为更中性的默认设置，也可以保留为奖励消融。"
        - 实际训练结果、控制状态诊断结果和评估报告仍在 `runs/`，不纳入 git。
    commits:
      - a1fb28
  v0.14.6:
    时间:
      - 2026-08-01 01:47:45
      - 2026-08-01 12:05:02
    重要性: 8.5
    标题: 验证预留空闲运力是否真的有价值
    摘要: 构造第二批任务延迟出现的场景，比较“让多余智能体原地待命”和“让它加入当前配送”两种选择。进一步改变待命位置、接单后的退出限制和卸货方式，判断预留运力何时能缩短响应时间，以及这种收益是否符合当前环境的物理机制。
    内容:
      比较待命和冗余配送:
        - 在正式环境之外构造独立状态，不修改训练环境、奖励和已有 checkpoint。
        - 第一项配送任务只需要两个智能体即可完成；第三个智能体一条分支原地待命，另一条分支也加入第一项任务。
        - 在不同时间放出第二项任务，再让两条分支中的第三个智能体都转去执行它，比较响应时延、全部任务完成时间和团队行驶距离。
        - 主结果覆盖 256 组随机位置和 4 个任务出现时刻，避免只挑选有利于待命的地图位置。
      检查收益来自哪种环境机制:
        - 在相同场景中继续比较原地待命、移动到地图中心待命、返回补给站待命、接单后暂时不能退出，以及按实际到达成员比例卸货。
        - 改变待命位置，用来判断预留运力的价值是否主要取决于“在哪里等”。
        - 加入短期不可退出限制，用来判断冗余配送是否只有在存在真实服务承诺时才会付出代价。
        - 按实际参与配送的成员比例守恒卸货，并在新任务出现后重新选择足够且最快的联盟，避免人为浪费载荷影响比较。
      适用边界:
        - 这些比较只用于检验环境机制，不训练策略，也不改变正式环境，因此不能直接当作学习方法的性能结果。
    结论:
      验证:
        - 发现: 原地预留一个空闲智能体可以减少团队总路程，但平均完成任务反而更慢，因此不能据此要求策略增加 Idle。
          依据:
            - 1024 个配对场景中 reserve 仅 31.84% 更快，第二任务时延平均劣化 3.49 step，总完成时间平均劣化 2.68 step。
            - 待命分支平均少行驶 226.5 距离单位；智能体到新任务的距离差与响应时间差的相关系数约 0.9996。
        - 发现: 选择合适的待命位置或加入真实的服务承诺后，预留运力才可能有价值，而且收益依赖具体物理假设。
          依据:
            - 地图中心 Standby 的 reserve 更快比例约 57.91%，平均总完成时间改善 2.99 step；补给站 Standby 则平均劣化 5.78 step。
            - 15/30-step 不可取消承诺显著提高 reserve 优势，但优势幅度接近人为锁定时长。
        - 发现: 按比例卸货并允许全队重新分配后，完成时间没有额外改善，可以排除“当前卸货方式自然浪费了载荷”这一解释。
          依据:
            - 修正后的比例卸载在成功、时延和总完成时间上与当前动力学逐项一致，只进一步减少团队距离。
      判断:
        - 在当前环境中，Idle 更适合作为无可用任务时的兜底。若要提高联盟稳定性，应直接限制任务重选和联盟切换，而不是把提高 Idle 比例当作目标。
        - 若以后研究预留运力，应明确建模待命位置、能耗预算或现实中的服务承诺，不应为了制造收益而加入缺乏依据的长时间锁定。
      问题:
        - 正式环境中的任务仍在回合开始时一次生成；这里的延迟任务只是外部构造的诊断场景，不能当作在线任务训练结果。
      工程:
        - 两轮诊断分别覆盖 2080 和 14336 条轨迹，足以比较这些机制的方向，但不能替代训练后策略的正式评估。
    commits:
      - 238a3a
v0.15:
  标题: 原文联盟重组机制复现与 hierarchical gate 实现
  v0.15.0:
    时间:
      - 2026-08-01 20:06:01
      - 2026-08-02 15:38:44
    重要性: 9.0
    标题: 复现联盟重组机制，并加入学习式重选
    摘要: 在完成 HATT 待命和预留运力诊断后，研究重点转向原文中的联盟保持与动态重组机制。固定 HATT v2.0 作为主方法，补齐按周期、任务事件和任务紧迫度触发的重组方式，并让 HATT 学习何时保持当前任务、何时重新选择任务。
    内容:
      确定原文复现范围:
        - 主方法固定为 HATT v2.0：分别编码智能体和任务，建模智能体之间的关系，汇总当前任务的联盟成员，再为每个候选任务计算动作概率。
        - 从这一版本开始继续复现原文中除 HATT 表示以外的联盟重组部分；后续 HATT 网络版本保留为历史探索或消融。
        - 代码中没有实现的吸引-排斥边和反事实联盟效用不作为当前复现结果，避免方法描述超出实际代码证据。
        - 评估不只报告最佳 checkpoint，还检查训练末期表现、多随机种子、任务重选次数、联盟切换和资源消耗，避免只展示偶然最优结果。
      学习是否应该重新选择任务:
        - 新增一个可学习的 gate：一部分概率保持当前任务，另一部分概率按 HATT 给出的候选任务分布重新选择，两部分合成最终动作概率并直接参与 PPO 更新。
        - gate 根据智能体状态、当前任务及其联盟、继续当前任务的概率和最佳替代任务的优势作出判断；当前任务已经失效时必须重新选择。
        - checkpoint 保存训练时使用的重组模式，加载时检查一致性，避免普通 HATT 权重与带 gate 的权重被错误混用。
      加入规则重组方法作为对照:
        - 三个环境统一支持保持旧行为、每次都重选、按固定周期重选、任务状态变化时重选、任务紧迫时重选和学习式重选。
        - 学习式方法只在周期到达或发生任务事件时考虑是否重选，避免每一步都触发额外决策。
        - 单独记录未完成任务上的切换成本，并统计重组决策次数、实际联盟变化、每次决策的切换率、任务紧迫度和响应时间。
      单种子初步筛选:
        - 在相同 HATT v2.0、配送环境和统一 Idle 时间成本下，比较旧行为、始终重选、周期重选、事件重选、两种紧迫度规则，以及有无切换成本的学习式重选。
        - 同时观察成功率、任务完成率、决策频率、联盟切换率和资源消耗，防止某种方法只是靠频繁换任务取得表面收益。
        - 每个条件先运行一个随机种子并评估 best、p90 和 last checkpoint，再决定哪些方法值得扩展到多种子验证。
    结论:
      验证:
        - 发现: 单种子初筛全部完成，但没有任何任务重组方法稳定超过原有 HATT。
          依据:
            - 8/8 个训练 job 完成，24/24 个 best/p90/last checkpoint eval 完成。
            - 原有方法 best 成功率约 21.1%；事件触发方法 last 约 23.4%、best 约 20.3%；其他方法 best 约 9.4% 到 21.9%。
            - 原有方法 best 任务完成率约 82.3%，事件触发方法 last 约 83.0%，无切换成本的学习式方法 best 约 81.7%，带成本版本约 75.9%。
        - 发现: 每次都允许重新选任务会退化成频繁待命和很少探索，不值得继续扩大实验。
          依据:
            - 该方法每 100 个存活步约触发 100 次重组决策，约 25.4% 的决策选择 Idle，best 成功率只有约 9.4%。
            - p90 checkpoint 已基本坍缩：成功率和任务完成率都是 0，所有决策都选择 Idle。
        - 发现: 学习式 gate 可以减少每次重组决策导致的实际切换，但单种子结果没有显示稳定的性能提升。
          依据:
            - 带切换成本的学习式方法每 100 个存活步约决策 20.9 次，每次决策的切换率约 0.166，低于原有方法 best 的约 0.473。
            - 带切换成本版本 last 成功率约 12.5%，无成本版本约 3.1%，训练末期仍然不稳定。
      判断:
        - 原有方法、事件触发方法和带切换成本的学习式方法值得扩展到 3 个随机种子：分别代表当前基线、规则方法中较好的候选和能够减少切换的学习方法。
        - 始终重选、周期重选、两种紧迫度规则和无切换成本的学习方法不再追加训练，因为它们表现较弱、重选过度或训练末期坍缩。
      问题:
        - 初筛只有一个随机种子，不能据此确定不同方法的最终排名。
        - 学习式 gate 目前只证明能够训练并减少切换，尚未证明可以提高任务成功率，多种子结果仍需验证。
      工程:
        - 训练和评估现在都会记录任务重选频率和实际联盟切换率，后续可以同时比较任务效果与联盟稳定性。
    commits:
      - da1e78
  v0.15.1:
    时间:
      - 2026-08-02 14:25:17
      - 2026-08-02 23:18:21
    重要性: 7.5
    标题: 修复重组评估配置，并扩展三种子验证
    摘要: 修复 checkpoint 评估没有继承训练时任务重组设置的问题，避免不同方法在评估时都悄悄退回原有行为。根据单种子初筛，只为原有方法、事件触发方法和带切换成本的学习式方法补充两个随机种子。
    内容:
      保证评估使用正确的重组方法:
        - 训练和评估配置快照现在都保存重组模式、触发周期、紧迫度阈值及聚合方式、切换成本和学习式 gate 参数。
        - 修复后，每个 checkpoint 都按训练时的方式决定何时重新选择任务，不会在评估阶段静默回退到原有 HATT 行为。
      扩展到三个随机种子:
        - 原有方法、事件触发方法和带切换成本的学习式方法各补充 seed 2 和 seed 3，并与初筛中的 seed 1 合并为三种子对照。
        - 不再训练始终重选、周期重选、两种紧迫度规则和无切换成本的学习式方法，因为单种子初筛已显示它们效果较弱、重组过度或训练末期坍缩。
        - 三种方法保持相同的 HATT v2.0、配送环境、统一 Idle 时间成本和 1500 episode 训练设置。
      统一比较方式:
        - 每个随机种子都评估 best、p90 和 last checkpoint，并使用相同的 128 个场景，结果可以和初筛中的 seed 1 直接合并。
    结论:
      验证:
        - 发现: 三种子补充训练和 all-checkpoint 评估完成后，事件触发和原有 legacy 仍比学习式重选更稳。
          依据:
            - seed2/seed3 的 6 个补充训练全部完成，18 个 best/p90/last checkpoint 评估全部完成。
            - 事件触发在补充种子中的 best 成功率约 36.7%，任务完成数约 8.55；legacy 在补充种子中 best/last 仍能维持约 25.8% / 28.9% 成功率。
            - 带切换成本的 learned gate 在补充种子中 best 成功率约 19.1%，任务完成数约 7.61，低于 event 和 legacy。
        - 发现: learned gate 的主要变化是减少“每次重选决策真的换任务”的比例，但没有换来更高成功率。
          依据:
            - learned-cost 每次重选决策的联盟切换率约 0.193，明显低于 legacy / event 的约 0.45-0.51。
            - learned-cost 每 100 个存活步的重选决策约 17.55，接近 event / legacy 的两倍；实际每 100 个存活步的联盟切换约 3.27，并没有带来任务成功率优势。
      判断:
        - 学习式重选目前更像在学“少换任务”，而不是学到何时重选能改善配送结果。
        - event 规则虽然简单，但至少在任务事件发生时重新分配，性能和稳定性都比当前 learned gate 更可解释。
      问题:
        - learned gate 的输入只来自策略隐状态和当前任务概率差，可能缺少“新任务出现、当前任务完成、距离上次重选多久”等显式事件信息。
        - 现有 mixture 写法下，gate 概率和 HATT 基础分布里的当前任务概率会相互抵消，导致“gate 到底学到了多少重选意愿”不容易从最终动作中识别。
    commits: [3ecc87]
  v0.15.2:
    时间:
      - 2026-08-03 16:03:00
      - 2026-08-04 17:59:52
    重要性: 8.5
    标题: 重组 gate 显式上下文、switch 参数化与干预评估
    摘要: 针对 learned gate 看不到事件信息、mixture gate 难以解释的问题，给环境观测补充重组事件和时间上下文，并加入 switch 参数化，让 gate 直接表示离开当前任务的概率；同时补齐评估筛选、回合时限和 gate 干预入口，方便比较“始终重选、始终保持、事件强制重选、学习式重选”的差异。
    内容:
      让 gate 看到真正触发重组的上下文:
        - 环境在可选配置下为每个智能体输出 `reconfiguration` 观测，包含新任务发现、任务完成、周期触发、当前任务是否完成、当前任务是否仍可用、距上次重选 / 换任务的时间、episode 进度和任务紧迫度。
        - HATT v2.0 learned gate 可以把这些显式上下文拼到 gate 输入中，而不是只依赖隐状态、当前任务表示和候选任务概率差。
        - checkpoint 记录并校验是否使用显式上下文，避免训练和评估时把带上下文的权重当成普通 learned gate 加载。
      分开检查 gate 的可识别性:
        - 保留旧的 `mixture` 参数化作为历史行为：gate 打开后仍按 HATT 原始任务分布采样，因此当前任务概率和 gate 概率会混在一起。
        - 新增 `switch` 参数化：gate 直接表示“离开当前任务”的概率，当前任务概率为 `1-g`，其他任务按去掉当前任务后的条件分布选择。
        - 这一步仍然保持单层动作分布，先检查可识别 gate 是否比旧 mixture 更容易训练，而不同时引入额外的层级采样变量。
      增加可控干预和评估入口:
        - gate override 支持 `open`、`closed`、`event` 和 `event_or_learned`，用于在同一 checkpoint 上强制全部重选、全部保持、只在事件发生时重选，或事件强制打开并学习其余重选。
        - 评估脚本支持按模型名正则筛选 manifest 条目，便于复跑某个 seed 或某一类干预，而不用复制整份评估配置。
        - 训练 / 评估配置透传新的 gate 参数，sweep manifest 覆盖显式上下文因果测试和 switch gate 三种子对照。
      修正评估回合时限:
        - 新增 `episode_time_limit`，让终止时限可以独立于环境内部的 `max_steps` 时间尺度；默认仍跟随 `max_steps`。
        - runner 的 checkpoint 评估循环使用同一个终止时限，避免评估循环比环境语义更长或更短。
        - 这个字段只控制回合什么时候结束，不改变任务 deadline、时间归一化和环境中的奖励尺度。
    结论:
      验证:
        - 发现: 只给 learned mixture gate 补显式上下文没有解决主要问题。
          依据:
            - context-mixture 三个 seed 的训练和 checkpoint 评估完成。
            - best 成功率约 37.5%，但平均死亡约 6.57，episode length 被拉到约 1139.8；last 成功率约 26.6%，任务完成数约 7.78。
            - 相比 event / legacy，context-mixture 仍有更多重选决策，且没有显示稳定收益。
        - 发现: switch gate 让“离开当前任务”的概率更可解释，但单靠可识别参数化没有超过 event / legacy。
          依据:
            - switch-nocontext best 成功率约 29.7%，任务完成数约 8.35；switch-context best 约 20.3%；switch-hybrid best 约 7.8%。
            - switch 系列的 p90/last 普遍退化，说明训练稳定性仍不足。
        - 发现: 同 checkpoint 强制 gate 干预说明“保持当前任务”不是可行修复。
          依据:
            - force-closed 和 force-event 在旧 context checkpoint 上几乎全部退化为 Idle，成功率为 0，任务完成数为 0。
            - force-open 与 learned 接近，说明原 learned mixture gate 很可能已经接近 always-open，真正决定是否换任务的是任务 decoder 对当前任务的概率。
      判断:
        - 当前问题不只是缺少事件输入，也不只是 gate 是否可解释；gate 和 task decoder 的联合训练仍会把重选时机、当前任务保持和任务选择混在一起。
        - 下一步需要把“是否重新决策”和“重新决策后选哪个任务”显式拆成两层动作，避免继续让单个 categorical 分布承担两种语义。
      问题:
        - switch 系列没有提升成功率，说明更可解释的概率形式本身不足以修复训练。
        - event_or_learned 在 switch 形式下反而更弱，可能是事件强制打开和 learned residual 的训练目标仍然互相干扰。
    commits: [5add79]
  v0.15.3:
    时间:
      - 2026-08-04 19:00:20
      - 2026-08-05 02:28:27
    重要性: 7.5
    标题: hierarchical gate 与重选成本筛选
    摘要: 在 switch gate 仍未稳定改善后，把任务重选拆成两层动作：先判断是否重新决策，再在重新决策时选择任务；同时保存 gate action 供 PPO replay，并加入非强制重选成本，用单种子筛选 hierarchical gate 是否比 switch 更适合学习重选时机。
    内容:
      拆开“是否重选”和“选哪个任务”:
        - hierarchical 参数化先采样 gate action，再在 gate 打开时采样 HATT 任务分布；gate 关闭时保持当前任务。
        - 这样 PPO 看到的是显式 gate action，而不是从最终任务动作里反推 gate 是否打开。
        - 当前任务失效、全队停止、当前任务完成等强制重选场景由扩展 context 标记，避免把必要重选和主动重选混在一起。
      让 PPO 能复用 gate action:
        - HATT actor 在 rollout 时记录 gate action，policy 将其传回 runner。
        - GAT/HATT buffer 保存 gate action，feed-forward、naive recurrent 和 recurrent batch 都会把它传给 trainer。
        - PPO evaluate 时用原 gate action 重新计算联合 log prob，避免训练阶段重新采样 gate 导致 ratio 不对应 rollout 动作。
      加入重选成本筛选:
        - 新增 `reconfiguration_decision_coef`，只惩罚非强制场景下的 learned gate 开启概率。
        - hierarchical screen 同时跑 event 基线、无重选成本、0.01 成本和 0.05 成本四个单种子条件。
        - 这轮先作为单种子筛选，不直接替代 event / legacy 主对照。
    结论:
      验证:
        - 发现: hierarchical gate 没有出现 switch / mixture 那种明显 idle 坍缩，但单种子筛选仍没有超过 event 或 legacy。
          依据:
            - 4/4 个训练 job 完成，12/12 个 all-checkpoint eval 完成。
            - event 基线 last 成功率约 21.1%，hier-cost0 best 约 25.8%，hier-cost0.01 best 约 19.5%，hier-cost0.05 best 约 28.1%。
            - 四个条件的 decision / executed idle ratio 都为 0，说明 hierarchical 写法至少避免了“关门后退化为 Idle 动作”的问题。
        - 发现: 显式 gate action 让重选动作更可解释，但还没有学到更好的重选时机。
          依据:
            - hier-cost0 / 0.01 / 0.05 每 100 个存活步约触发 17.8 到 18.5 次重选决策，明显高于 event 的约 8.8 次。
            - 三个 hierarchical 条件每次决策的实际换任务比例约 0.22 到 0.24，低于 event 的约 0.43，但成功率没有随之稳定提高。
      判断:
        - hierarchical 比 switch 更适合继续做机制诊断，因为 gate action 已经和 PPO replay 对齐，且保持当前任务不会再被记成普通 task categorical 的隐含结果。
        - 重选成本本身不是主要解法：0.05 成本单种子最好，但重选频率并没有明显低于 0 或 0.01，不能说明成本已经学会压低无效重选。
      问题:
        - 当前筛选只有一个 seed，28.1% best 成功率不能说明 hierarchical 已经优于 event / legacy。
        - gate 仍可能只是在“少换任务”，而不是识别哪些任务事件真的需要重新分配；后续若继续推进，需要看 gate probability、强制开门比例和任务完成时刻的对应关系。
    commits: [e6510e]

  v0.15.4:
    时间:
      - 2026-08-04 20:00:46
      - 2026-08-04 20:02:52
    重要性: 3.0
    标题: hierarchical gate 中文注释补充
    摘要: 在 hierarchical gate 代码已经成形后，补充中文注释和 docstring，把 gate 生效条件、强制重选 context、PPO replay 对齐和 gate regularization 的作用边界写在代码旁边。这次只改注释，不改变训练或评估逻辑。
    内容:
      补清 gate 参数化注释:
        - 在 HATT v2.0 actor 旁说明 mixture、switch 和 hierarchical 三种写法的区别：旧 mixture 是概率混合，switch 让“离开当前任务”更可识别，hierarchical 则显式采样“是否重新决策”。
        - 标明 gate 只在环境把 agent 激活给 actor 时生效；inactive agent 沿用上一动作，不会生成新的 gate 样本。
      补清强制重选 context:
        - 在 delivcoal 环境里解释 9 维 reconfiguration context 是事件和时间特征，11 维版本额外加入 all-still 和 mandatory。
        - 说明 all-still、当前任务完成、当前任务无效这些情况为什么必须重新进 actor，否则 episode 可能卡住或继续执行无效任务。
      补清 PPO replay 注释:
        - 在 policy、buffer、runner 和 trainer 路径旁说明 hierarchical gate action 必须随 rollout 保存，并在 PPO update 时原样重放。
        - 说明非 hierarchical 路径写入零占位，保持 graph model 的 batch 结构一致。
        - 说明 `reconfiguration_decision_coef` 只惩罚非强制状态下主动开门的概率，用来控制 learned reconfiguration 的稀疏性，不是环境奖励项。
    结论:
      工程:
        - 这次只补注释和 docstring，不改变训练、评估、采样或 buffer 行为。
        - 后续继续改 hierarchical gate 时，代码旁边已经能直接看到 gate action、mandatory 重选、PPO replay 和正则项的边界。
    commits: [67bdfe]

v0.16:
  标题: gate 因果验证、coverage/event 主线收束与跨任务外推

  v0.16.0:
    时间:
      - 2026-08-05 03:39:27
      - 2026-08-05 12:49:10
    重要性: 6.5
    标题: hierarchical gate 开门指标与 cost0.05 多种子扩展
    摘要: 在 cost0.05 单种子 best 表现相对较好后，继续补两个随机种子，并在 eval 结果中记录 hierarchical gate 的开门比例、强制开门比例和 learned gate 自主开门比例，用来判断模型到底是在任务事件中被迫重选，还是在非强制状态下主动重选。
    内容:
      记录 gate 开门行为:
        - eval 调用 policy act 后，从 HATT actor 缓存的 `last_gate_actions` 读取 hierarchical gate 的 z 动作。
        - 按 active agent 统计 gate 决策次数、开门次数和总体开门率。
        - 如果观测里有 11 维 reconfiguration context，就用 mandatory 位把强制重选和 learned gate 自主重选分开统计。
      扩展 cost0.05 候选:
        - 保留 cost0.05 单种子配置，新增 seed2 / seed3 的正式 sweep 配置，训练设置与 seed1 的 hierarchical cost0.05 保持一致。
        - 每个新 seed 仍评估 best、p90 和 last checkpoint，便于和 seed1 以及 event / legacy 对照合并。
        - 这一步不是把 cost0.05 定为最终方法，而是检查单种子最好结果是否可复现。
      单独评估 gate 指标:
        - 增加 cost0.05 seed1 的 gate 指标评估配置，针对 best、p90 和 last checkpoint 复跑 deterministic eval。
        - 该评估入口用于补充 gate 行为解释，不改变训练配置，也不替代任务成功率、任务完成数和联盟切换率这些主指标。
    结论:
      验证:
        - 发现: cost0.05 的单种子优势没有在 seed2 / seed3 上复现。
          依据:
            - seed2 best 成功率约 25.0%，任务完成数约 8.23。
            - seed3 p90 成功率约 18.0%，任务完成数约 7.77。
            - seed1 best 约 28.1%，补充两个种子后没有出现更高或更稳定的成功率。
        - 发现: hierarchical gate 在强制重选状态下会按预期开门，但 learned 部分仍偏保守。
          依据:
            - seed1 best / p90 / last 的 mandatory open rate 都是 1.0。
            - learned open rate 约 22.9% / 22.7% / 16.4%，总体 gate open rate 约 54.4% / 53.2% / 51.1%。
            - 三个 checkpoint 的 decision / executed idle ratio 都为 0，说明这一路径没有退回 Idle 坍缩。
      判断:
        - cost0.05 可以继续作为 hierarchical gate 的可解释候选，但不能只凭 seed1 best 作为主结论。
        - gate 指标说明模型确实区分了强制开门和 learned 自主开门；当前问题更像是 learned gate 何时主动重选还不够有效，而不是 gate action 没有被正确执行。
      问题:
        - seed3 明显弱于 seed1 / seed2，说明随机种子敏感性仍在。
        - learned open rate 与成功率之间还没有建立清晰对应关系，后续需要结合任务事件时刻和完成任务类型继续分析。
    commits: [334cd3]

  v0.16.1:
    时间:
      - 2026-08-05 16:27:00
      - 2026-08-05 16:31:20
    重要性: 6.0
    标题: gate 因果评估与 detached × coverage 后续验证入口
    摘要: 在 hierarchical gate 多种子和开门指标仍不能说明 learned open 是否有效后，新增下一阶段监督脚本：先对三个 cost0.05 seed 的 best/last checkpoint 做 gate 干预评估，再自动启动 detached × coverage 的 2×2 三 seed 对照训练。
    内容:
      区分 learned gate 的实际贡献:
        - 新增 seed1 和 seed2/seed3 两份 gate causal eval manifest，复用已经训练好的 hierarchical cost0.05 checkpoint，不重新训练。
        - 每个 seed 同时比较 `event_or_learned`、`event`、`force_open` 和 `force_closed`，用同一组 128 episode deterministic 评估判断 learned off-event 开门是否真的带来任务收益。
        - 评估范围覆盖 best 和 last checkpoint，避免只看 best 时忽略训练末期策略退化。
      验证特殊动作分离和 coverage 的交互:
        - 新增 detached × coverage 因子 sweep，在 event 重组条件下比较 plain、detached、coverage、detached+coverage 四组。
        - 每组运行三个随机种子，训练期 eval 使用 32 episodes，最终 checkpoint 评估使用 128 episodes。
        - 这组实验用于判断 coverage 与特殊动作分离是各自独立有效，还是其中一个解释了主要收益。
      串联长流程:
        - 新增监督脚本先并行运行 gate causal 评估，完成后再启动 detached × coverage 训练，避免 24 项评估和 12 个训练 job 同时争用 GPU1。
        - 监督脚本写入 `runs/<timestamp>_delivcoal_hatt-next-stage-supervisor/status.json`，使 `scripts/progress.py` 和训练进度页面可以继续读取整体状态。
    结论:
      验证:
        - 发现: hierarchical gate 的 learned off-event 开门没有显示出清晰收益。
          依据:
            - 三个 cost0.05 seed 的 best checkpoint 中，event-only 平均成功率约 23.2%，event_or_learned 约 18.5%。
            - last checkpoint 中，event-only 和 event_or_learned 分别约 16.9% 和 16.1%，差距很小。
            - force-open best 平均约 19.8%，也没有证明总是重选比事件触发更好。
        - 发现: force-closed 会直接坍缩，说明完全保持当前动作不是可行策略。
          依据:
            - 三个 seed 的 best/last force-closed 成功率均为 0。
            - force-closed 下 action 几乎全部变成 Idle，任务发现和完成都归零。
        - 发现: coverage 是这轮因子实验中最稳定的正贡献，detached 没有在当前 sector/event 配置下迁移成功。
          依据:
            - plain 三 seed best 成功率均值约 37.5%，coverage 约 71.4%。
            - detached 均值约 9.1%，明显低于 plain。
            - detached+coverage 均值约 62.0%，弱于 coverage alone，说明 detached 的早期收益不能直接叠加到 coverage/event 配置。
      判断:
        - 当前更可靠的主线是 coverage + event，而不是继续堆 learned gate 或 detached。
        - detached 早期能缓解特殊动作污染，但在 sector coverage 和 event 重组共同存在时，可能破坏了 HATT 对控制动作和配送任务的统一排序。
      问题:
        - coverage/event HATT 是否真正优于同配置 MAPPO 还没有严格确认，需要 matched MAPPO 三 seed 对照。
        - gate 指标的 learned/open 口径暴露出事件触发和 mandatory 触发混用的问题，后续指标需要拆得更清楚。
    commits: [28554c]

  v0.16.2:
    时间:
      - 2026-08-07 01:31:15
      - 2026-08-07 01:33:43
    重要性: 6.0
    标题: MAPPO coverage/event 对照兼容修复与 gate 指标口径修正
    摘要: 在 coverage/event HATT 成为当前最可信候选后，新增严格匹配的 MAPPO coverage/event 三 seed 对照；首次启动暴露 hierarchical gate 接入后标准 MAPPO runner 仍按 6 元组解包的问题，本次修复 shared runner 兼容并同步细化 gate 评估指标。
    内容:
      修复标准 MAPPO runner 兼容:
        - shared runner 的 `collect` 同时兼容 HATT/GAT 路径返回的 6 元组和标准 MAPPO 路径返回的 5 元组。
        - 标准 MAPPO 没有 hierarchical gate action，只在 runner 内部使用零占位保持环境循环一致，写入普通 `SharedReplayBuffer` 时不再额外传 gate 字段。
        - 该修复解决 matched MAPPO 首次启动时 `expected 6, got 5` 的回归。
      修正 gate 指标语义:
        - eval 指标将 event trigger 从完整 reconfiguration context 中解析出来，覆盖新任务发现、任务完成、当前任务失效以及 mandatory 位。
        - 新增 `gate_event_trigger_open_rate` 和 `gate_off_trigger_open_rate`，避免把 event-only 的事件开门误记成 learned 开门。
        - 新增 `coalition_changes_per_gate_open`，把 gate 开门次数和实际换任务次数分开，便于判断开门是否真的改变联盟。
      建立 matched MAPPO 对照:
        - 新增 MAPPO coverage/event 三 seed sweep，训练设置、coverage、event 重组、训练期 eval 和最终 128 episode checkpoint eval 与 HATT coverage/event 因子实验保持一致。
        - 首次失败 run 保留为兼容回归记录；修复后重新启动，三个 seed 已完成首个 rollout 并进入健康训练。
    结论:
      验证:
        - 发现: 仅把 coverage/event 配置交给标准 MAPPO64，不能复现 HATT coverage/event 的高成功率。
          依据:
            - MAPPO64 matched 三 seed best success 分别约 10.2%、25.8%、7.8%，均值约 14.6%。
            - 同一 coverage/event 设置下，HATT 三 seed best / p90 success 约 71.1%、78.1%、64.8%，均值约 71.4%。
            - MAPPO64 平均任务完成数约 7.17，HATT coverage/event 平均约 9.65。
        - 发现: gate 指标拆成 event trigger 和 off-trigger 后，能避免把 event-only 的必要开门误读成 learned gate 自主开门。
          依据:
            - event override 语义依赖新任务、任务完成、当前任务失效和 mandatory 等触发条件。
            - "`coalition_changes_per_gate_open` 把“开门”与“实际换联盟”分开，后续能检查 gate 打开是否真的改变任务分配。"
      判断:
        - coverage/event 的收益不能解释为“普通 MAPPO 加同样探索覆盖和事件重组就够了”；当前证据仍指向 HATT 结构对任务-智能体关系建模有贡献。
        - MAPPO64 对照参数量偏小，虽然已经很弱，但仍需要继续跑更大 hidden size 的 MAPPO，排除容量不足这个反驳点。
      问题:
        - matched MAPPO 的 latest checkpoint 仍需要和 best 分开看，不能只用 best 成功率描述训练稳定性。
        - gate 指标口径修正只是让诊断更可靠，并没有让 learned gate 本身变成主线方法。
    commits: [3e3a1f]

  v0.16.3:
    时间:
      - 2026-08-07 14:44:27
      - 2026-08-08 14:31:34
    重要性: 8.0
    标题: coverage/event 五项优先验证与外推入口
    摘要: 在 MAPPO64 matched 已经明显弱于 HATT coverage/event 后，继续补更宽 MAPPO、多种子复现、任务槽位置换、capcoal all-visible 和 GymRT2A local 五项优先验证，用同一个监督脚本串联长流程，判断当前优势是否稳定、是否来自任务槽顺序、能否外推到其他环境。
    内容:
      扩展 delivcoal 主线证据:
        - 新增 MAPPO204 coverage/event 三 seed 对照，先检查普通 MAPPO 增大 hidden size 后是否明显追上 HATT。
        - 新增 HATT coverage/event seed4 / seed5，并同场加入 MAPPO204 seed4 / seed5，避免三 seed 偶然性支撑主结论。
        - 新增 deliver task-slot permutation 评估，把同一 checkpoint 的配送任务槽位打乱，检查 HATT 是否只是记住任务数组位置。
      检查跨任务外推:
        - 新增 capcoal all-visible allocation 对照，把任务全部预先可见、探索动作掩掉，用来观察纯能力-需求匹配场景中 HATT 和 MAPPO 是否还能拉开差距。
        - 新增 GymRT2A local HATT / MAPPO matched 配置，尝试把当前 HATT 路线迁到另一个资源收集环境。
        - 这些入口用于判断当前方法是 delivcoal 特化，还是能在更简单的 allocation 和外部 GymRT2A 环境中继续成立。
      串联五项优先 campaign:
        - 新增五阶段监督脚本，按 MAPPO204、slot permutation、seed4/5、capcoal、GymRT2A 顺序运行。
        - 每个阶段仍复用 sweep / eval 的 status.json 接口，便于进度页面和离线汇总读取。
        - 训练阶段和评估阶段分开排队，减少多个长评估同时抢 GPU1 导致状态不清的问题。
    结论:
      验证:
        - 发现: HATT coverage/event 在 seed4 / seed5 上继续保持高成功率，三 seed 偶然性的解释变弱。
          依据:
            - seed4 p90 success 约 66.4%，任务完成数约 9.56，死亡约 0.02。
            - seed5 best success 约 68.0%，任务完成数约 9.59，死亡约 0.02。
            - 同场 MAPPO204 seed4 / seed5 的训练期 best_log_eval_success 约 21.9% / 18.8%，last 约 0 / 0。
        - 发现: deliver task-slot permutation 没有破坏 HATT coverage/event 的 best / last 结果。
          依据:
            - HATT s1/s2/s3 best 和 last 的 success_delta 全部为 0。
            - 任务完成率和 episode length 同步保持不变，说明配送任务槽位顺序不是当前 HATT 成功的主要来源。
        - 发现: capcoal all-visible allocation 已经太简单，不能作为区分 HATT 与 MAPPO 的强证据。
          依据:
            - HATT 三 seed best success 约 99.2%、100%、100%。
            - MAPPO64 也达到 100%，MAPPO204 训练期 best_log_eval_success 同样为 100%。
      判断:
        - 当前 delivcoal 主结论更稳：coverage/event HATT 的优势跨 seed 延续，并且不依赖配送任务槽位顺序。
        - capcoal all-visible 可以说明代码路径能跑通 allocation 简化场景，但不能证明 HATT 更强；它更像 sanity check。
      问题:
        - MAPPO204 的 all-checkpoint eval 产物不完整，虽然训练期 eval 已经显示弱，但还需要更可靠的最终评估入口。
        - GymRT2A local 六个 job 都在 runner 解包处失败，报 `too many values to unpack (expected 5)`；这是 GymRT2A runner 接口未对齐，不是算法性能结论。
        - MAPPO204 仍未严格匹配 HATT 参数量，容量不足仍可能被质疑，需要更接近 HATT actor 参数量的 MAPPO 对照。
    commits: [e43074]

  v0.16.4:
    时间:
      - 2026-08-08 16:19:52
      - 2026-08-08 16:24:02
    重要性: 6.5
    标题: 参数量匹配 MAPPO 与 HATT/MAPPO 槽位置换专项
    摘要: 在 MAPPO204 仍弱、但容量反驳点还没完全排除后，新增 hidden_size=288 的 MAPPO coverage/event 三 seed，对齐到接近 HATT actor 参数量；同时把槽位置换评估扩展为独立专项，覆盖 HATT 和 MAPPO 的 best checkpoint，并区分 Deliver 任务槽和 Explore sector 槽。
    内容:
      参数量匹配 MAPPO:
        - 新增 MAPPO288 coverage/event 三 seed sweep，保持 delivcoal、sector coverage、event 重组、训练步数、checkpoint 保存和最终 all-checkpoint eval 设置不变。
        - MAPPO288 actor 参数量约 250,530，HATT coverage/event actor 约 262,341，差距约 4.5%，比 MAPPO64 / MAPPO204 更适合回应“容量不够”的质疑。
        - 三个 seed 已完成首个 rollout 并进入健康训练，后续结果用于和 HATT coverage/event s1-s3 的 best / p90 / last 对齐比较。
      槽位置换专项:
        - 任务槽置换脚本支持 `deliver`、`explore` 和 `all` 三种 scope，Explore scope 只打乱 sector 探索槽，不再和配送任务槽混在一起。
        - 置换评估同步处理任务观测、联盟 ID、动作掩码和环境动作反映射，保证原始场景和置换场景比较的是同一批任务，只改变呈现顺序。
        - 新增模型名筛选和 CPU fallback，便于单 checkpoint 冒烟；正式评估仍在 GPU1 上运行。
      专项监督:
        - 新增 slot permutation campaign，同时启动 Deliver 和 Explore 两个 scope，并把两边 summary 合并成 aggregate 文件。
        - 槽位置换评估在每个子进程内顺序跑模型，避免多个 runner 并发初始化 CUDA 或共享随机状态导致配对场景不稳定。
        - 冒烟测试已覆盖 HATT 与 MAPPO checkpoint 加载，以及 Explore-sector 置换路径。
    结论:
      验证:
        - 发现: HATT 对 Deliver / Explore 槽位置换基本保持等变，MAPPO 对 Explore 槽位置换明显敏感。
          依据:
            - HATT coverage/event 的 Deliver 槽位置换 success_delta 全部为 0。
            - Explore-sector 置换后，HATT best 结果基本不变；MAPPO 的 best success 从约 14.6% 降到约 2.6%。
        - 发现: 只把 MAPPO actor 参数量提高到接近 HATT，不能解释或复现 HATT 的优势。
          依据:
            - HATT coverage/event 三 seed best / p90 / last success 均值约 69.8% / 64.6% / 62.0%。
            - MAPPO64 三 seed best / p90 / last success 均值约 14.6% / 1.8% / 3.6%。
            - MAPPO288 三 seed best / p90 / last success 均值约 6.8% / 0.8% / 1.8%。
        - 发现: 更宽 MAPPO 能让探索动作稍微分散，但没有形成有效分工。
          依据:
            - MAPPO288 best 的 sector entropy 均值约 0.521，高于 MAPPO64 的约 0.369，但仍低于 HATT 的约 0.765。
            - MAPPO288 best 的 decision_explore_ratio 约 62.7%，发现率约 68.1%，说明更多探索没有稳定转化为任务发现和配送成功。
      判断:
        - 当前更合理的解释是 HATT 的关系建模、参数共享和置换等变归纳偏置在起作用，而不是简单的网络容量优势。
        - MAPPO288 恢复评估修正了容量对照的关键漏洞：此前 all-checkpoint eval 漏传 actor 架构参数，可能用默认 64 宽网络重建 288 checkpoint。
      问题:
        - MAPPO288 的恢复评估只覆盖 seed1-3；为了和 HATT / MAPPO64 的后续五 seed 口径一致，还需要补 seed4 / seed5。
        - 五 seed 扩展已经启动，但当前版本提交时尚未完成，不能提前写最终多种子结论。
    commits: [4fca7b]

  v0.16.5:
    时间:
      - 2026-08-09 13:52:10
      - 2026-08-09 15:21:34
    重要性: 7.0
    标题: MAPPO288 恢复评估修复与 coverage/event 五种子扩展
    摘要: 发现 MAPPO288 all-checkpoint 评估没有继承 actor 架构参数，导致容量匹配 checkpoint 可能按默认 64 宽网络重建。本次修复 sweep 评估配置透传，允许从训练完成但最终评估失败的 source sweep 恢复 checkpoint 矩阵评估，并启动 HATT、MAPPO64、MAPPO288 的 seed4/5 扩展。
    内容:
      修复容量对照评估:
        - sweep 的 checkpoint eval override 现在补齐 `hidden_size`、`layer_N`、特征归一化、正交初始化和激活函数等 actor 架构字段。
        - 这样加载 MAPPO288 checkpoint 时会按训练时的 288 宽 MLP 重建 actor，而不是静默退回默认 64 宽配置。
        - 该修复直接关系到“容量匹配 MAPPO 是否失败”的结论可靠性。
      恢复已有 checkpoint 评估:
        - checkpoint matrix 评估器支持 `allow_eval_failed_source`，允许 source sweep 处于 `eval_failed`，只要训练 job 全部完成，就可以从已有 actor checkpoint 恢复独立评估。
        - 新增 MAPPO288 coverage/event recovery manifest，对 seed1-3 的 best、p90、last checkpoint 重新跑 128 episode deterministic eval。
        - 这一步不重新训练，只修复评估入口，用来给容量对照补一份可信结果。
      扩展到五个随机种子:
        - 新增 coverage/event five-seed extension sweep，补 HATT seed4/5、MAPPO64 seed4/5 和 MAPPO288 seed4/5。
        - 三组方法共享 delivcoal、sector coverage、event 重组、1500 episode 训练和 128 episode checkpoint eval 设置。
        - 这组实验用于把 HATT 优势、MAPPO64 失败和 MAPPO288 失败放到同一五 seed 口径下比较。
    结论:
      验证:
        - 发现: HATT coverage/event 的优势扩展到五个随机种子后仍然成立。
          依据:
            - HATT 五 seed best / p90 / last success 均值约 68.0% / 63.1% / 63.9%。
            - HATT 五 seed best 平均完成任务约 9.59 个，last 平均约 9.52 个。
        - 发现: MAPPO64 和参数量匹配 MAPPO288 都没有追上 HATT。
          依据:
            - MAPPO64 五 seed best / p90 / last success 均值约 11.9% / 1.1% / 2.5%。
            - MAPPO288 五 seed best / p90 / last success 均值约 8.1% / 3.4% / 5.8%。
            - MAPPO288 best 平均完成任务约 6.84 个，仍远低于 HATT。
        - 发现: MAPPO288 seed4/5 没有复现容量反转，seed5 last 虽有 16.4% success，但 best / p90 仍弱。
          依据:
            - seed4 MAPPO288 p90 success 约 14.8%，best 约 8.6%，last 约 7.0%。
            - seed5 MAPPO288 best 约 11.7%，p90 为 0，last 约 16.4%。
      判断:
        - “HATT 优势来自 actor 参数更多”这个解释基本可以排除；更合理的解释仍是任务-智能体关系建模和置换等变归纳偏置。
        - coverage/event 已经可以作为 delivcoal 当前主线结果，后续重点应转向其它环境或更困难设置，而不是继续在同一设置上堆 MAPPO 容量。
      问题:
        - delivcoal 证据已经较强，但 capcoal all-visible 太容易，无法支撑泛化优势；需要重新设计 capcoal 难度。
        - MAPPO288 训练末期仍有波动，说明容量增加带来的探索变化不稳定，不能当作可用基线改进。
    commits: [03ed79]

v0.17:
  标题: capcoal 难度重建与 legacy/event 因果交叉评估

  v0.17.0:
    时间:
      - 2026-08-10 12:04:00
      - 2026-08-11 00:59:57
    重要性: 7.0
    标题: capcoal all-visible 重跑与 legacy/event 交叉评估
    摘要: delivcoal 主线已经比较清楚后，重新检查 capcoal。先复跑 all-visible allocation matched，确认 HATT、MAPPO64 和 MAPPO204 在这个设置上都能接近满分；随后用已有 legacy-trained 和 event-trained checkpoint 做 legacy/event 交叉评估，判断任务重组日程本身在 capcoal 上是否是主要因素。
    内容:
      复核 capcoal all-visible 难度:
        - 复跑 HATT、MAPPO64、MAPPO204 的 all-visible allocation matched 配置，确认任务全可见、探索掩掉后，三类 actor 都能把 10 个任务基本完成。
        - 这说明 all-visible capcoal 主要是一个跑通 allocation 的 sanity check，不足以证明 HATT 优势。
      初始 legacy/event 交叉评估:
        - 对 event-trained all-visible checkpoint 评估 event 和 legacy 两种重组日程。
        - 对旧 legacy-trained capcoal checkpoint 评估 legacy 和 event 两种重组日程。
        - 交叉评估固定 checkpoint 和物理场景，只改变环境什么时候重新激活 agent 重新决策。
      暴露 checkpoint guard 边界:
        - 初始交叉评估中，MAPPO 路径可以完成 legacy/event 交叉；HATT 跨日程加载会被 checkpoint 中保存的 `reconfiguration_mode` 拦下。
        - 这个 guard 能防止误加载 learned gate 等结构不一致的 checkpoint，但也阻止了有意的非 learned 因果干预。
        - 后续需要只对 legacy/event 这类无额外参数的日程开放显式 override，不能放开 learned gate mismatch。
    结论:
      验证:
        - 发现: all-visible capcoal 对当前方法区分度不足。
          依据:
            - event-trained all-visible 下，HATT event best success 约 99.2%，MAPPO64 event best 为 100%。
            - legacy 评估下 MAPPO64 best 仍约 90.1%，旧 legacy-trained MAPPO last 约 96.9%。
        - 发现: reconfiguration 日程会明显改变决策频率，但在 all-visible capcoal 上不足以形成强算法区分。
          依据:
            - event 评估的 reconfiguration decisions 约 6.0-6.3 / 100 alive steps。
            - legacy 评估通常约 2.7-3.1 / 100 alive steps。
            - 成功率大多仍在 80%-100% 区间，说明任务太容易掩盖了机制差异。
        - 发现: HATT 跨 legacy/event 评估被 checkpoint guard 拦截。
          依据:
            - event-trained HATT 在 eval-legacy 下 9 个 checkpoint 全部失败。
            - legacy-trained HATT 在 eval-event 下 3 个 checkpoint 全部失败。
            - 错误来自 checkpoint `reconfiguration_mode` 与当前评估配置不一致。
      判断:
        - all-visible capcoal 不适合作为论文级强对照；它可以保留为 allocation 路径 sanity check。
        - 需要更困难的 capcoal 设置：更多 agent/task、更长 episode、更随机需求，并显式比较 legacy/event 训练和评估日程。
      问题:
        - 初始交叉评估的 HATT 部分不完整，必须先修复非 learned 日程的显式 opt-in，再补 recovery eval。
        - 即便修复交叉评估，all-visible 的天花板效应仍然存在，不能替代新的中规模训练。
    commits: [81855f]

  v0.17.1:
    时间:
      - 2026-08-11 12:25:59
      - 2026-08-11 12:57:18
    重要性: 6.0
    标题: HATT 非 learned 重组日程干预与 recovery eval
    摘要: 初始 capcoal 交叉评估暴露 HATT checkpoint guard 对 legacy/event 因果干预过严。本次新增显式 `allow_reconfiguration_mode_mismatch`，只允许 legacy/event 这类无额外参数的非 learned 日程交叉加载，并补跑 event-trained HATT under legacy、legacy-trained HATT under event 的 recovery eval。
    内容:
      限定开放非 learned 日程交叉:
        - policy 加载 checkpoint 时保留默认严格检查，避免普通评估误用不同 reconfiguration mode。
        - 只有显式设置 `allow_reconfiguration_mode_mismatch`，且保存模式和当前模式都不包含 learned，才允许跨日程加载。
        - learned gate 仍然不能通过这个开关跨模式加载，因为 learned 路径会引入额外 gate 参数和 PPO replay 语义。
      暴露评估开关:
        - 训练入口新增 `--allow_reconfiguration_mode_mismatch` 参数，默认关闭。
        - eval manifest 可以在单个 condition 中打开该开关，用于明确的因果干预，而不是全局改变 checkpoint 安全策略。
      补跑 HATT recovery eval:
        - 新增 event-trained HATT under legacy 的 recovery manifest，覆盖三个 seed 的 best、p90、last。
        - 新增 legacy-trained HATT under event 的 recovery manifest，覆盖旧 capcoal HATT 的 best、p90、last。
        - 两个 recovery eval 只补 HATT 曾失败的跨日程条件，不重复已经成功的 MAPPO 项。
    结论:
      验证:
        - 发现: 显式 opt-in 后，HATT 可以完成 legacy/event 非 learned 日程交叉评估。
          依据:
            - event-trained HATT under legacy 的 9 个 checkpoint 全部评估完成。
            - legacy-trained HATT under event 的 3 个 checkpoint 全部评估完成。
        - 发现: event-trained HATT 切到 legacy 后仍接近满分。
          依据:
            - eval-legacy best / p90 / last success 均值约 95.6% / 93.5% / 94.8%。
            - 平均完成任务约 9.85-9.93 个，executed idle ratio 约 0.8%-1.6%。
        - 发现: legacy-trained HATT 切到 event 后也能保持较高成功率，但 event 日程让决策更频繁、Idle 更多。
          依据:
            - eval-event best / p90 / last success 约 93.8% / 83.6% / 91.4%。
            - reconfiguration decisions 约 5.3-10.2 / 100 alive steps，高于 legacy 下约 2.8-3.3。
            - best / last executed idle ratio 约 17.4%-17.5%。
      判断:
        - legacy/event 日程交叉本身不是 all-visible capcoal 成败的关键；任务太容易，很多不同决策日程都能完成。
        - 修复后的加载开关适合做因果评估，但不应该成为普通评估默认行为。
      问题:
        - all-visible 天花板效应仍然存在，需要更大规模、更长 episode、更随机需求的 capcoal 设置来放大差异。
        - 旧 legacy-trained HATT 只有单种子，不能和 event-trained 三种子直接做强统计结论。
    commits: [0f2c88]

  v0.17.2:
    时间:
      - 2026-08-11 21:26:05
      - 2026-08-11 21:27:10
    重要性: 7.5
    标题: 中规模 capcoal legacy/event 因果训练入口
    摘要: all-visible capcoal 已经确认太容易后，新增中规模 capcoal 训练矩阵：把任务数扩到 25、智能体扩到 30、episode 拉到 1500 steps，并在 HATT/MAPPO64 × legacy/event × 3 seeds 上统一训练和 checkpoint 评估，用来判断 HATT 优势是否能在更困难的资源匹配环境中出现。
    内容:
      提高中规模 capcoal 难度:
        - 配置 10 UAV + 20 UGV、25 个配送任务、1500 steps/episode 和 full-random reset。
        - 使用 `random_demand`，保留 nearest exploration，避免 all-visible 场景里探索和任务发现都被掩掉。
        - 每个 job 训练 5000 episodes，即 7.5M steps，保存 episode checkpoint 供 best/p90/last 评估。
      建立 legacy/event 因果矩阵:
        - HATT v2.0 × legacy 跑 3 seeds。
        - MAPPO64 × legacy 跑 3 seeds。
        - HATT v2.0 × event 跑 3 seeds。
        - MAPPO64 × event 跑 3 seeds。
      对齐历史 PPO 设置:
        - 使用 1 个 PPO epoch、4 个 mini-batches、entropy 0.05、学习率 5e-4。
        - 训练期每 250 episodes 做 32-episode eval，最终 best、p90、last 各做 128-episode 独立评估。
        - GPU1 首批启动 5 个任务，HATT legacy 三种子和 MAPPO legacy 两种子完成首个 rollout，状态健康。
    结论:
      进展:
        - 发现: 中规模 capcoal 至少不再是 all-visible 那种一眼到顶的简单题。
          依据:
            - legacy 六个 job 已经完成，event 侧仍在跑，完整 2×2 因果矩阵还差最后一个 MAPPO event seed。
            - 25 个任务、30 个 agent、1500 steps 的设置能把训练和评估耗时明显拉开，也暴露出独立评估配置必须精确继承训练场景的问题。
        - 发现: legacy 子集的有效恢复评估里，HATT 和 MAPPO best 都能完成任务，但稳定性表现不一样。
          依据:
            - HATT legacy best / p90 / last success 均值约 99.5% / 97.4% / 97.9%。
            - MAPPO64 legacy best 为 100%，但 p90 / last 均值约 75.3% / 81.0%，其中 seed2 last 约 43.0%。
        - 发现: best 成功率基本持平，HATT 的差异主要体现在完成效率和后期保持能力。
          依据:
            - best checkpoint 下 MAPPO 三个 seed 都是 100%，HATT 为 98.4%、100%、100%。
            - HATT best 平均约 462 steps 完成，MAPPO best 约 659 steps；HATT 回报约 47.0，MAPPO 约 -40.6。
            - HATT p90/last 三个 seed 都保持在约 93% 以上；MAPPO p90/last 出现 seed 级别的大幅掉落。
        - 发现: MAPPO 的后期退化伴随探索保持失败、Idle 循环和重决策暴涨。
          依据:
            - MAPPO seed2 last success 约 43.0%，发现率 / task completion ratio 约 88.2%，平均 episode 长度约 1122 steps。
            - 该 checkpoint 决策 Idle 比例约 60.0%，最大 Idle 时长约 618 steps，每百存活步重决策约 39.6。
            - HATT last 平均决策数约 594，每百存活步重决策约 4.1，发现率保持 100%。
      判断:
        - 当前结果只能说明 legacy 日程下中规模 capcoal 已经有稳定性差异，不能提前推出 legacy/event 因果结论。
        - MAPPO best 高但 p90/last 掉得多，说明它学到过完成任务的策略，后续 PPO 更新中容易遗忘或进入低效 Idle / 重决策循环。
        - 单独报告 best checkpoint 会掩盖最关键的问题；这个设置下更应该同时报告 best、p90、last、episode length 和 reward。
      问题:
        - event 子集还没完全结束，主 sweep 的统一独立评估也还没开始。
        - 初次 completed-independent 评估用了错误的小场景配置，相关 HATT 数字必须作废，MAPPO 的维度报错也不能解读成算法失败。
    commits: [799f54]

  v0.17.3:
    时间:
      - 2026-08-12 11:33:20
      - 2026-08-13 01:39:16
    重要性: 6.5
    标题: 中规模 legacy 已完成 job 的独立评估修复
    摘要: 先抽已经完成的中规模 legacy job 做 best/p90/last 独立评估时，发现评估入口只继承了模型结构参数，没有把训练时的场景规模一起带过去。HATT 因为集合输入可变而静默跑在小场景上，MAPPO 则直接维度不匹配失败。本次修正评估配置生成逻辑，并补跑 HATT/MAPPO legacy 三种子的有效恢复评估。
    内容:
      允许从仍在运行的 sweep 中评估已完成 job:
        - 独立 checkpoint matrix 支持显式 `allow_active_source`，用于长 sweep 尚未全部结束时先评估已经完成的 job。
        - 该模式只接受状态为 completed 的指定 job；如果请求到仍在跑或未完成的 job，会直接报错，而不是混进半成品 checkpoint。
      修正评估场景继承:
        - 将模型结构参数和评估场景参数分开处理。
        - 模型结构仍进入 model manifest；地图大小、智能体数、任务数、episode 长度、reward 配置等场景参数写入 eval config。
        - 多 job 共享同一评估条件时会检查场景参数一致；如果不同 job 的任务数或地图等配置不一致，评估入口会拒绝合并。
      修复 sweep 内置评估的同类问题:
        - all-checkpoint 评估按 job 单独生成 eval config，避免某个 checkpoint 被 base config 的小场景覆盖。
        - sweep 结束后的统一评估也会从所有 job 中推导共同场景，确保 best/p90/last 评估和训练环境一致。
      补跑有效 legacy 恢复评估:
        - 保留第一次 completed-independent manifest 作为错误暴露记录，但不把其中的 HATT 小场景结果当科研结论。
        - 新增 recovery manifest，覆盖 HATT legacy 三种子和 MAPPO64 legacy 三种子的 best、p90、last，共 18 个 checkpoint。
        - recovery 评估完成后确认使用的是 30 agents、25 tasks、1500 steps 的中规模 capcoal 场景。
    结论:
      验证:
        - 发现: 修正后的独立评估恢复了中规模 legacy 六个 job 的同场景可比性。
          依据:
            - 18 个 best、p90、last checkpoint 均按 30 agents、25 tasks、1500 steps 完成评估。
            - HATT 与 MAPPO 的输入维度和场景配置均来自各自训练配置，错误小场景结果已排除。
      工程:
        - active source 只允许抽取已经完成的 job，避免把运行中的半成品 checkpoint 纳入汇总。
    commits: [bcb962]

v0.18:
  标题: 值分解基线与跨训练范式关系建模

  v0.18.0:
    时间:
      - 2026-08-13 09:28:00
      - 2026-08-15 03:31:42
    重要性: 7.5
    标题: QMIX、VDN 与 HATT-QMIX 本地训练链路
    摘要: 将依赖缺失外部包、接口停留在旧环境的 QMIX 路径重写为本地 recurrent value-decomposition 实现，并增加 VDN mixing 对照与 HATT-QMIX 学习方法，使 delivcoal 可以在相同环境、观测、动作掩码和评估协议下比较 PPO 与离策略值分解。
    内容:
      本地值分解训练器:
        - 实现参数共享 recurrent individual-Q 网络、单调 mixing hypernetwork、Double-Q target 和 target network 更新。
        - episode replay 支持序列截取、短序列 padding、有效步 mask 与 RNN burn-in，不再依赖仓库外的 `offpolicy` 包。
        - runner 对齐 Dict observation、原生全局状态、active agent 动作保持、available-action mask、并行环境自动 reset 和 episode 级日志。
        - 训练入口、独立评估、checkpoint 保存加载和 sweep override 均识别 QMIX、VDN、HATT-QMIX trainer。
      调试训练节奏和隐状态:
        - 首轮正式训练暴露更新单位错配：每 32 个环境步更新导致约 23 次更新/episode，target 每 200 次梯度更新又等价于约 9 episodes；五个 seed 的 Q 值共同发散后已终止该批运行。
        - 更新节奏修正为每个完整 episode 一次、target 每 200 episodes 一次，并采用 QMIX 常用 RMSprop；Q 值幅度增加熔断保护，防止发散作业继续占用算力。
        - 第二轮正式训练保持数值稳定，但暴露采样阶段只在 `next_active` 开门时推进 recurrent hidden、而回放训练与确定性评估每个物理步都推进的偏差；该批运行已保留并标记无效。
        - 采样 hidden 现按每个物理转移推进，仅在 episode 结束时清零；补充回归测试和 8 episode 真实环境更新计数冒烟后，从头启动正式 sweep。
      增加解释性对照:
        - VDN 复用完全相同的 individual-Q、replay 与优化过程，只把状态条件单调 mixer 替换为 utility 求和，用于检验 mixing expressiveness。
        - HATT-QMIX 复用 HATT v2.0 的 agent-task 关系编码和候选任务解码器，同时采用 QMIX 的离策略 TD 学习，用于拆分关系结构与 PPO 优化机制的影响。
      五种子正式评估:
        - 新增五种子正式 sweep，采用 full-random delivcoal coverage/event 设置、训练期 32 episode 验证和独立 128 episode best/p90/last 测试。
        - 15 个训练 job 与 45 个独立 checkpoint 评估全部完成，形成第一批离策略值分解基线。
      工程验证:
        - 增加单调性、sequence replay 和进度解析单元测试，三种算法均完成 delivcoal 真实交互、反向更新和 checkpoint 冒烟。
        - QMIX runner 输出恢复 rollout 总量、sent、episode reward、timesteps、FPS 和 ETA 标准字段；episode 0 不再触发随机策略评估。
    结论:
      验证:
        - 发现: 首批 QMIX、VDN、HATT-QMIX 都能稳定跑完训练和独立评估，但在当前 delivcoal event 设置下都没有完成整局任务。
          依据:
            - 45 个 best、p90、last checkpoint 的 success 均为 0。
            - best 平均完成任务数：QMIX 约 2.57 / 10，VDN 约 2.66 / 10，HATT-QMIX 约 1.84 / 10。
        - 发现: HATT-QMIX 在首批配置里提高了发现覆盖，但没有转化成配送完成。
          依据:
            - HATT-QMIX best discovered ratio 约 72.8%，高于 QMIX / VDN 的约 53.0% / 53.5%。
            - HATT-QMIX p90 / last 完成任务数降至约 0.84 / 0.75，低于 QMIX 和 VDN。
        - 发现: QMIX 与 VDN 的差异很小，单调 mixer 暂时没有带来明显收益。
          依据:
            - QMIX / VDN best 完成任务数约 2.57 / 2.66。
            - 两者 last 完成任务数约 1.67 / 1.41，均远低于 HATT-MAPPO 主线。
      判断:
        - 当前首批值分解结果适合作为工程基线；它已经暴露 event 动作持续、replay 隐状态和信用分配语义需要进一步核对。
        - HATT-QMIX 没有显示出关系结构优势，问题更可能在 TD target / replay 语义和长期信用传播上。
      问题:
        - event 环境中 inactive agent 实际保持旧动作，而首批 QMIX target 仍对下一状态可用动作自由取 max，可能学习到当前无法执行的动作价值。
        - recurrent replay 从任意 chunk 零 hidden 开始，burn-in 语义和 rollout hidden 仍需要更严格对齐。

  v0.18.1:
    时间:
      - 2026-08-15 11:59:44
      - 2026-08-15 21:02:06
    重要性: 6.5
    标题: HATT-QMIX 分块前向加速与优化复现
    摘要: 首批 HATT-QMIX 单 seed 明显慢于 HATT-MAPPO 和普通 QMIX。本次保留 GRU 逐步递推，把无记忆的 HATT backbone 与候选动作 decoder 按时间块批量执行，并开启共享任务编码、关闭未使用 diagnostics，在 GPU1 上复现五种子评估，确认工程加速有效但算法表现仍弱。
    内容:
      优化 HATT-QMIX 训练开销:
        - 保留 GRU 逐时间步递推，将无记忆的 HATT backbone 和 candidate decoder 按时间块批量执行，减少 online/target 序列展开中的小 kernel 调用。
        - delivcoal 在 agent 维度复制同一份 task observation，HATT-QMIX 开启任务编码共享，编码一次后广播到各观察者。
        - QMIX 路径关闭未消费的 attention/coalition diagnostics 归约，MAPPO/HATT 日志路径保持原有 diagnostics。
        - 增加分块与逐步前向等价性测试；8 episode 真实环境冒烟完成 TD 更新、target 同步和 checkpoint 保存。
        - 新增仅使用 GPU1 的优化后 HATT-QMIX 五种子复现 sweep，保持原 1500 episode 和 best/p90/last 评估口径。
      优化复现实验:
        - 五个优化版 HATT-QMIX seed 训练完成，15 个 best、p90、last 独立评估完成。
        - 配置 `qmix_hatt_sequence_chunk_size=32`、`hatt_shared_task_obs=true`，GPU0 配额为 0。
        - 复现目的限定为等价加速和运行成本核对，不作为新的调参方案。
    结论:
      工程:
        - 发现: 分块 HATT-QMIX 明显降低训练耗时。
          依据:
            - 原 HATT-QMIX 单 seed 平均约 14.49 小时，优化版约 7.51 小时。
            - 正式启动时五进程 FPS 约 52-57；旧实现约 21-22。
            - 优化版五种子训练加独立评估总耗时约 8 小时 54 分。
      验证:
        - 发现: 加速没有改变首批 HATT-QMIX 的主要失败结论。
          依据:
            - 优化版 15 个 checkpoint success 仍全部为 0。
            - best 平均完成任务数约 2.55 / 10，接近 QMIX / VDN best；p90 / last 降至约 0.18 / 0.57。
        - 发现: 优化版 seed2 能完成约 4.70 个任务，但后期不能保持。
          依据:
            - seed2 best 约 4.70 / 10，last 降至约 1.96 / 10。
            - 其他 seed best 多在约 1.05-2.68 个任务，未形成稳定结构优势。
      判断:
        - 运行时间问题已经缓解，可以继续使用优化实现做机制筛选。
        - 当前 HATT-QMIX 的弱表现不是由数值发散造成；Q 值幅度和 TD error 可控，但策略质量仍随训练后期退化。

  v0.18.2:
    时间:
      - 2026-08-15 22:03:58
      - 2026-08-16 19:11:52
    重要性: 7.0
    标题: event 环境下 QMIX target 语义修正与机制筛选
    摘要: 优化复现后，HATT-QMIX 仍无法稳定完成配送。代码复核显示 event 环境里多数物理步不能重新决策，但 QMIX target 会对不可立即执行的动作取 max；同时 recurrent replay、死亡 agent 和自动 reset mask 也存在语义偏差。本次新增 constrained physical 与 event-SMDP 两类值分解语义，并启动两种子六条件筛选实验。
    内容:
      校正事件环境中的值分解语义:
        - 增加 constrained physical target：下一物理步没有决策权的智能体沿用环境实际持有动作，死亡智能体 utility 退出 mixer，避免 target 对不可执行联合动作取最大值。
        - replay 保存 active/alive mask、持有动作和逐转移折扣；个体死亡时同步清零 rollout 与训练隐状态，自动 reset 后同步替换 observation、active mask 和 available-action mask。
        - recurrent replay 的 burn-in 前缀只负责恢复隐状态，前缀计算不再进入反向图；保留 legacy physical 模式用于复核历史结果。
        - 增加 event-SMDP replay，将相邻全局决策事件之间的物理奖励按 gamma 累积，并使用 gamma 的持续步数次方作为 bootstrap 折扣。
      增加机制筛选实验:
        - HATT-QMIX 增加可切换的前馈 utility head，用于检验事件观测下 GRU 是否引入额外优化负担。
        - HATT-MAPPO 增加 team-mean reward 广播开关，用于隔离个体奖励信用与共享团队奖励的影响。
        - 新增两种子六条件 screening sweep，对比 constrained physical、event-SMDP、HATT 前馈/循环 utility 和 HATT-MAPPO team-mean；训练与独立评估只使用 GPU1。
      验证入口:
        - 已完成 flat QMIX constrained、HATT-QMIX event-SMDP 循环版、HATT-QMIX event-SMDP 前馈版、HATT-MAPPO team-mean 和 event-SMDP checkpoint 独立测试的真实环境冒烟。
        - 正式 screening sweep 启动 12 个 job，当前首批 5 个 job 运行健康，完整结果等待训练和 best/p90/last 独立评估结束后回填。
    结论:
      验证:
        - 发现: constrained target、死亡 utility 屏蔽和 event-SMDP 消除了实现与数值稳定性疑点，仍未让 QMIX 家族形成稳定成功策略。
          依据:
            - 12 个训练 job 与 36 个独立 checkpoint 测试全部完成，QMIX 家族 best success 均为 0。
            - 后期 Q 值和 TD error 保持有限，未出现首轮训练中的数值发散。
        - 发现: 前馈 HATT-QMIX 和 event-SMDP 分别改善部分任务完成，种子方差仍然很大。
          依据:
            - HATT-QMIX physical 前馈版 best 平均任务完成率约 31.9%，循环版约 11.1%。
            - 普通 QMIX event-SMDP best 平均任务完成率约 27.4%，两个 seed 分别约 0% 和 54.8%。
        - 发现: HATT-QMIX 的主要失败发生在发现任务后的联盟能力匹配。
          依据:
            - HATT-QMIX best 发现率约 61%-79%，committed payload shortage 约 15.8%-55.6%。
            - 原始个体奖励 HATT-MAPPO 对应 shortage 约 5.9%-7.0%。
        - 发现: team-mean reward 显著削弱 HATT-MAPPO，个体 shaped reward 与 focal advantage 是主要性能来源。
          依据:
            - team-mean 两 seed best success 平均约 7.0%，任务完成率约 54.8%。
            - 原始 HATT-MAPPO 对应均值约 74.6% success、97.0% 任务完成率。
      判断:
        - target 语义修正是必要工程修复，信用分配、单调分解和偏低的梯度更新强度仍需继续验证。
        - 两种子筛选适合选择下一轮参数，不能作为调参后 QMIX 的最终论文成绩。
      工程:
        - 六条件筛选训练与独立评估状态完整落盘，best/p90/last 可按同一场景复核。
    commits: [6bd4db]

v0.19:

  v0.19.0:
    时间:
      - 2026-08-17 07:12:52
      - 2026-08-17 13:46:48
    重要性: 6.5
    标题: 训练评估协议与进度页面约定
    摘要: HATT-QMIX 机制筛选结束后，下一步不再只是追加单个对照，而是要重新规范训练期验证、最终测试和进度展示口径。本次把每 50 episode validation、validation-best 锁定、最终 held-out test、最后 10% 轨迹统计和页面分阶段展示写成代理协作约定，为后续实现提供统一边界。
    内容:
      统一评估语义:
        - 训练期 validation、最后 10% 轨迹统计和最终 held-out test 分别回答不同问题，不再把 best、last、p90 这类 checkpoint selector 当成同一个最终指标。
        - validation-best 只能从训练期 50-episode 网格上的 32-seed validation 结果中选择，并在 held-out test 前锁定；最终 128-seed test 只评估已锁定的 validation-best 和 last。
        - 最后 10% 逐 episode actor 用来观察末期波动和退化，不代表单个可部署模型；是否用 8 还是 32 个 seeds 需要在对应实验清单中明确。
      规范进度口径:
        - checkpoint selector 存在时，`all_checkpoints: true` 的展示范围就是 selector 子集，页面和状态不能把 last/best/p90 误写成全 checkpoint 测试。
        - 评估进度同时保留全局原子量和当前 checkpoint 的局部 seed 进度；失败、跳过、未提交和重试单独计数，不能缩小分母来制造完成率。
        - 静态页面继续从 `html_logs/` 读取脱敏 JSON；窄屏需要卡片化，刷新时保留展开状态、滚动位置和图表 viewport。
      代理交接:
        - AGENTS.md 与 CLAUDE.md 写入下一阶段评估协议，要求后续修改 checkpoint、训练期评估、最终评估或进度网页前先阅读交接文档并核对代码现状。
        - 规范只保留正向规则，不把讨论中被否决的 top-K 复筛、三点平均等方案写成长期工程概念。
    结论:
      判断:
        - 评估协议从“训练中顺手 eval + 结束后挑若干 checkpoint”提升为单独的实验设计问题，后续结果能更清楚地区分模型选择、末期稳定性和最终泛化测试。
        - 新阶段仍停在 `v0.x`，因为研究方法和评估协议还在快速调整，没有到可称为 `v1.0` 的冻结口径。
      工程:
        - AGENTS.md 和 CLAUDE.md 已同步写入约束，后续代理不应再把设计文档误报成现有实现，也不应把 selector 子集说成全 checkpoint 测试。
    commits: [31439b]

  v0.19.1:
    时间:
      - 2026-08-16 20:51:00
      - 2026-08-17 19:01:37
    重要性: 7.0
    标题: 训练期评估分卡与最终测试流水进度
    摘要: 训练期 checkpoint eval 原先占用训练进程设备，最终 checkpoint 测试要等整组训练结束，页面也只能看到离散 checkpoint 组数。本次把周期评估和最终测试都接入逐 episode 进度文件，让 GPU1 训练和 GPU0 评估按 checkpoint 边界衔接，并新增下一轮 QMix 更新强度与奖励尺度筛选清单。
    内容:
      拆分训练期评估设备:
        - 增加 `training_eval_cuda`，训练 job 到达评估间隔后先保存带 episode 标签的 actor checkpoint，再在指定 CUDA 上启动短生命周期评估子进程。
        - 外部评估复用当前 config 生成临时 eval config 和单 checkpoint manifest，评估结果回写 TensorBoard 标量和 best/latest checkpoint 选择链路。
        - 共享 MAPPO/HATT runner 的 `periodic_eval` 路径，并让 QMix runner 调用同一接口，避免 on-policy 和 value-decomposition 两套周期评估语义分叉。
      发布逐 episode 评估进度:
        - "`train/eval.py` 支持 `--progress_file`，runner 每完成一个 eval episode 就原子更新 `completed_episodes / total_episodes`。"
        - sweep 状态记录最终评估的 planned、submitted、completed、failed 任务数，以及所有已提交 checkpoint 的累计 episode 进度。
        - collector 从日志、`eval_latest.json`、外部评估 progress 文件和最终测试 status 中提取训练效果、最近验证效果、活跃 checkpoint 局部进度和脱敏后的公开字段。
      流水提交最终 checkpoint 测试:
        - "当 manifest 配置 `all_checkpoints: true` 且提供 `checkpoint_selectors` 时，sweep 在启动时固定全部 selector 计划量。"
        - 每个训练 job 成功结束后立即提交自己的 selected checkpoint 到 GPU0 队列，其他 job 继续训练；失败或缺失 checkpoint 的计划单元保留在分母中并记录失败。
        - 汇总逻辑复用原有 checkpoint eval 聚合，仍生成 per-job aggregate 和 best CSV，但状态更新能够反映评估仍在进行中的局内进度。
      下一轮 QMix 筛选:
        - 新增 delivcoal event-SMDP 前馈 HATT-QMIX 的更新次数和奖励尺度 2x2 析因，两种训练 seed 覆盖 8 个 job。
        - 补充普通 QMIX event-SMDP 的四更新对照，并统一使用 GPU1 训练、GPU0 周期验证和最终 best/p90/last 测试。
    结论:
      验证:
        - 发现: 更新次数增加和奖励尺度放大能改善值分解基线的任务完成，但仍没有把成功率推到可用水平。
          依据:
            - "普通 QMIX event-SMDP `u4-r10` 的 best success 均值约 9.4%，任务完成率约 67.8%，高于 `u4-r1` 的约 5.5% success 和 57.2% 完成率。"
            - "`u4-r10` 的 last 仍有约 8.6% success、66.7% 完成率，说明改善不是只出现在单个 best checkpoint。"
        - 发现: "HATT-QMIX 在 `u4-r10` 上出现一个强 seed，但整体不稳定。"
          依据:
            - "`hatt-qmix-ff-event-u4-r10-s2` best success 约 25.8%，任务完成率约 84.5%，last success 约 25.0%，任务完成率约 84.5%。"
            - 同条件 seed1 best success 为 0，任务完成率约 0.3%，两种子均值被强烈拉低到约 12.9% success、42.4% 完成率。
        - 发现: HATT-QMIX 的失败仍主要像是“发现以后组织不好配送”，不是发现任务不足。
          依据:
            - HATT-QMIX 全部 best 平均发现率约 77.5%，高于普通 QMIX 的约 63.9%。
            - HATT-QMIX 全部 best 平均 payload shortage 约 41.0%，死亡 agent 约 4.17；普通 QMIX 对应 shortage 约 4.4%，死亡 agent 约 0.70。
        - 发现: 新的评估进度链路能覆盖整组训练后的测试过程。
          依据:
            - 正式 run 12 个训练 job 全部完成，36 个 best/p90/last checkpoint 测试全部完成。
            - 最终测试累计 4608/4608 eval episodes，状态和聚合文件完整落盘。
      判断:
        - "对普通 QMIX，`updates_per_train=4` 与 `reward_scale=10` 是下一轮更值得保留的组合。"
        - "对 HATT-QMIX，`u4-r10` 说明结构模型不是完全不可学，但两种子差异过大，不能把单个 seed2 当成稳定改进。"
        - 这轮结果更支持继续查 HATT-QMIX 的联盟匹配、死亡控制和信用传播，而不是继续只调探索或 target 语义。
      问题:
        - 所有条件的最终 success 仍偏低，普通 QMIX best 均值最高也只有约 9.4%。
        - "当前仍使用 best/p90/last selector 旧口径，不等同于 `v0.19.0` 新协议里的 validation-best 与 held-out test。"
    commits: [7a8ed4]

  v0.19.2:
    时间:
      - 2026-08-18 00:31:00
      - 2026-08-18 17:33:59
    重要性: 6.5
    标题: HATT 正式训练与对照实验方案
    摘要: 此前 HATT 的结果来自多轮设置并不完全一致的筛选实验，难以直接回答结构是否有效。本次固定 DelivCoal 和 CapCoal 的训练预算、随机种子与评估方式，并为 HATT v2.0 增加去除 AA 注意力、联盟上下文和探索覆盖信息的对照，使后续比较能够落到具体结构上。
    内容:
      固定正式比较条件:
        - DelivCoal 统一采用 4 UAV、8 UGV、10 个隐藏配送任务、扇区探索、event 重配置、full-random reset 和 750 步上限；HATT 与 MAPPO 使用相同训练种子和预算。
        - CapCoal 同时保留 legacy 与 event 两种任务重选方式，用来检查结论是否依赖某一种重配置机制。
        - 训练期验证、最后 10% checkpoint 轨迹和最终测试使用分开的 seed 集，避免用训练中见过的场景挑选并报告模型。
      增加结构对照:
        - HATT v2.0 可以单独关闭 AA 注意力或按任务聚合的联盟上下文；关闭分支时保持网络参数和张量形状不变，减少因模型规模变化带来的干扰。
        - 增加关闭探索覆盖信息的 HATT 与 MAPPO 对照，检查 HATT 的优势是否主要来自输入中额外提供的探索历史。
        - 正式实验同时包含完整 HATT、结构消融和宽度匹配的 MAPPO，比较重点从“哪个 checkpoint 最高”改为多 seed 的训练后期表现。
      保持长实验可继续执行:
        - 正式训练按固定顺序启动，失败任务能够从已有 checkpoint 和状态记录继续，而不必重跑已经完成的配置。
        - GPU 温度保护、显存预算和失败恢复只用于保证长实验能够完成，不改变算法定义和评价指标。
    结论:
      进展:
        - 正式 DelivCoal 训练实际启动并完成了 22 个配置，说明统一清单、结构消融和多任务调度已经进入真实训练，而不只是纸面约定。
      问题:
        - 首轮运行有 15 个任务因资源不足失败，评估也因此没有直接进入终态；这一版本建立了比较条件，但不能单独提供完整的算法优劣结论。
        - CapCoal 的 legacy 与 event 对照尚未在同一轮完整结束，不能据此判断 HATT 的收益是否跨重配置方式成立。
    commits: [159637]

v0.20:
  标题: HATT 关系建模的定位与改造

  v0.20.0:
    时间:
      - 2026-08-19 12:57:20
      - 2026-08-20 13:50:08
    重要性: 8.0
    标题: HATT v3.2R：拆开任务切换与联盟成员信息
    摘要: HATT v3.2 把“离开当前任务、加入候选任务会发生什么”和“候选任务当前有哪些成员”揉在同一套候选表示里，特殊控制动作也可能被当成配送任务处理。本次用 v3.2R 分开两条信息路径：任务切换只对真实配送任务计算联盟变化，成员信息只汇总候选配送任务已有的智能体，并分别提供关闭对照。
    内容:
      修正任务切换表示:
        - 对每个 Deliver 候选分别表示离开当前联盟和加入目标联盟后的变化；选择当前任务时不再虚构一次离开操作。
        - Explore、Idle 和 Resupply 不再构造不存在的目标联盟，避免控制动作被错误解释成配送任务。
      单独表示候选联盟成员:
        - 候选任务只聚合当前属于该配送联盟的智能体，不再用一个全局联盟摘要代替所有任务的成员信息。
        - 任务切换信息和成员信息使用独立参数，最终再与当前智能体和候选任务表示合并。
      建立可解释对照:
        - 增加完整 v3.2R、去任务切换信息和去联盟成员信息三种模型，在相同 DelivCoal 设置和三个训练 seed 下比较。
        - 记录两条分支的输出强度与梯度，检查模型是否实际使用新增信息，而不只比较最终成功率。
    结论:
      进展:
        - 完整、去任务切换和去成员信息共 9 个训练任务全部完成，三种结构都能稳定完成训练。
      问题:
        - 这一轮只完成训练筛选，没有按独立 held-out 场景评估各自锁定的 checkpoint；训练曲线不足以判断任务切换或成员信息哪一条真正提高了泛化表现。
        - v3.2R 同时改变了两类关系表示，仍需要更直接的结构消融和同 checkpoint 干预才能确认收益来源。
    commits: [346610]

  v0.20.1:
    时间:
      - 2026-08-20 14:54:38
      - 2026-08-22 07:58:44
    重要性: 8.5
    标题: HATT 结构消融的正式评估
    摘要: 为了确认 HATT 的优势究竟来自关系结构还是探索输入，本次把扇区的相对几何与覆盖历史拆开，并对完整 HATT、去 AA、去联盟上下文、去覆盖信息和 MAPPO 的训练后期 checkpoint 做独立评估。结果表明，按任务聚合的联盟上下文和探索信息对表现更关键，原有 AA 注意力则没有显示出稳定增益。
    内容:
      拆开探索几何与覆盖历史:
        - 扇区动作可以只提供当前智能体实际可执行的方向和距离，不必同时暴露已经搜索过哪些区域。
        - 当任务观测因智能体位置而不同时，禁止 HATT 把第一个智能体的任务张量广播给其他智能体，避免悄悄丢掉各自的相对几何。
        - 增加 HATT、MAPPO 和去 AA/去联盟上下文模型的三 seed 对照，检查几何信息与关系结构各自贡献了什么。
      按用途评估训练后期:
        - 对正式训练和结构归因实验最后 10% 保存的逐 episode actor 做固定场景评估，观察末期平均水平、波动和退化，而不是只挑一个最高点。
        - 评估结果按完整 HATT、去 AA、去联盟上下文、去覆盖信息和 MAPPO 分组，所有失败和缺失 checkpoint 保留在状态记录中。
      保持评估可执行:
        - 长时间评估支持按任务继续执行，并记录当前模型与 seed 进度；温度保护只负责暂停和恢复进程。
        - 评估脚本复用统一的 checkpoint evaluator，不改变模型权重或训练结果。
    结论:
      验证:
        - 发现: 原有 AA 注意力没有表现出稳定收益。
          依据:
            - 完整 HATT 五个 seed 的末期 success 均值约 75.5%，去 AA 版本约 76.5%，两者基本相当。
        - 发现: 按任务聚合的联盟上下文比原有 AA 注意力更重要。
          依据:
            - 去联盟上下文后，五个 seed 的末期 success 均值降至约 58.9%。
        - 发现: 探索覆盖信息显著影响当前 DelivCoal 表现，但不能解释 HATT 与 MAPPO 的全部差距。
          依据:
            - 去覆盖信息的 HATT 三个 seed 末期 success 均值约 34.9%，且 seed 间差异明显。
            - 只保留相对几何时，HATT 三个 seed 的末期 success 均值约 38.2%，对应 MAPPO 约 1.6%。
      判断:
        - 后续不应继续把全局 AA 注意力当作 HATT 的主要贡献；更值得检查的是联盟成员信息怎样与具体候选任务发生关系。
      问题:
        - 去覆盖信息后的结果波动较大，探索输入与关系结构仍有耦合，不能把全部下降都归因于缺少覆盖记忆。
    commits: [9b659c]

  v0.20.2:
    时间:
      - 2026-08-22 11:31:00
      - 2026-08-23 16:11:31
    重要性: 8.5
    标题: HATT v3.3AA：按候选任务聚合联盟成员
    摘要: 正式消融显示，全局 AA 注意力本身没有带来稳定收益，问题更可能在于它没有回答“这些队友与当前候选任务有什么关系”。本次让 agent-agent 与 agent-task 使用相同形式但参数独立的关系计算，并把 AA 消息只送到成员实际所属的配送任务；同时用 learned、uniform 和 zero 三种方式直接检查学习到的 AA 权重是否有价值。
    内容:
      让 AA 信息对应具体任务:
        - 每条 AA 边描述当前智能体与另一名智能体的关系，但只有当对方属于某个 Deliver 联盟时，这条消息才进入该候选任务。
        - AA 与 AT 都计算关系权重和消息，形式与维度一致，但两种关系使用独立参数，避免把队友关系和任务匹配混为一套权重。
        - 当前智能体的全局上下文与每个候选任务的局部上下文复用同一批关系消息，减少前后两套表示含义不一致的问题。
      直接检验学习到的 AA 权重:
        - learned 使用网络预测的 AA 权重；uniform 把所有有效 AA 权重固定为 0.5，但保留消息网络和参数规模。
        - zero 在同一个 learned checkpoint 上关闭 AA 消息，用来判断已经训练好的策略是否真的依赖该分支。
        - learned 与 uniform 使用相同的三个训练 seed；锁定的 validation-best checkpoint 再用独立的 128 个场景比较 learned、uniform 和 zero。
      补充结构验证:
        - 检查 AA 与 AT 参数独立、智能体和任务重排不改变策略含义、联盟成员只进入对应 Deliver 候选，以及两类关系都能收到梯度。
    结论:
      验证:
        - 发现: learned AA 相比固定 uniform 权重有一致改善，但优势不来自“必须保留 AA 消息”。
          依据:
            - 三个 validation-best checkpoint 上，learned success 均值约 62.5%，uniform 约 55.2%。
            - 在同三个 learned checkpoint 上关闭 AA 消息后，zero success 均值约 67.4%，没有低于 learned。
        - 发现: learned AA 会减少相对 uniform 的重选次数，但 zero 进一步减少，不能把较少重选直接解释成 learned gate 学到了更好的联盟关系。
          依据:
            - learned、uniform、zero 的平均重配置决策数分别约为 641、736 和 573。
      判断:
        - v3.3AA 证明了候选任务上的 AA 权重能够影响策略，但没有证明 AA 消息是性能来源；当前证据更支持继续简化或重新定义成员关系，而不是继续堆叠注意力。
      问题:
        - 只有三个训练 seed，且因果干预基于各 seed 的 validation-best；AA 是否能在更多环境设置中带来稳定收益仍未确认。
    commits: [a22710]

v0.21:
  标题: DelivCoal 规则基线与外部方法复现

  v0.21.0:
    时间:
      - 2026-08-23 12:45:00
      - 2026-08-28 13:50:53
    重要性: 7.5
    标题: PCFA 在 DelivCoal 上的规则基线
    摘要: 仓库原有 PCFA 只按能力和需求做静态匹配，不能处理 DelivCoal 中先探索、再配送、途中补给和联盟成员持续执行的问题。本次把 PCFA 改成完整的规则基线：按任务优先级组织配送联盟，为未发现区域分配探索者，在电量或载荷不足时补给，并保持非活动智能体正在执行的动作。
    内容:
      形成完整规则流程:
        - 每次重选先保留仍在执行的非活动智能体，再按任务优先级和紧迫度处理已经发现的配送任务。
        - 根据任务剩余需求选择能力匹配的智能体组成联盟，避免把已经承诺给其他任务的载荷重复计算。
        - 没有进入配送联盟的可用智能体按未探索程度和路程选择扇区；电量或载荷低于阈值时优先返回补给。
      对齐 DelivCoal 动作语义:
        - 显式区分 Deliver、Explore、Idle 和 Resupply 槽位，并在最终输出前再次检查动作是否合法。
        - runner 在 full-random 自动重置后直接使用环境返回的新场景，不再额外 reset 一次而跳过随机场景。
        - 规则参数集中到配置项，任务排序、补给阈值和探索距离惩罚可以复现实验时固定。
      使用相同场景评估:
        - PCFA 使用与学习方法一致的 4 UAV、8 UGV、10 个隐藏配送任务、750 步上限和 128 个 held-out 场景。
        - 输出 success、任务完成率、发现率、配送比例和回合长度，能够直接进入 DelivCoal 横向结果表。
    结论:
      验证:
        - 发现: 不经过训练的 PCFA 已经能够完成多数配送任务，并形成有意义的 DelivCoal 下界。
          依据:
            - 128 个 held-out 场景 success 为 51.6%，平均任务完成率约 93.8%。
            - 平均发现率约 95.9%，配送比例约 95.1%，说明失败通常发生在接近完成的回合，而不是规则完全失效。
      判断:
        - PCFA 明显强于此前只做静态匹配的旧入口，后续学习方法至少需要与这套完整规则流程比较，不能继续把旧 PCFA 的 0 success 当作规则基线水平。
      问题:
        - 约一半场景仍不能在 750 步内全部完成，规则任务排序和探索分配仍有改进空间。
    commits: [6124ad]

  v0.21.1:
    时间:
      - 2026-08-28 14:19:29
      - 2026-08-28 19:08:55
    重要性: 7.0
    标题: 复现 CFM 与 MARL-MRT2A 官方方法
    摘要: 在把外部方法放进 DelivCoal 之前，先按各自原始环境和代码路径运行 CFM 与 MARL-MRT2A，确认模型、训练器和 checkpoint 评估能够工作。本次复现的是官方方法与实现链路，不把结果表述成已经复现论文中的全部实验数字。
    内容:
      复现 CFM 官方实现:
        - 保留 HeteroMRTA 官方 AttentionNet、pointer decoder、序贯分配过程、REINFORCE 训练和 POMO 组内基线所需源码。
        - 使用官方 checkpoint 评估 RALTestSet 的 50 个场景，并增加从随机初始化开始的小规模训练与独立 held-out checkpoint 评估。
        - 官方源码作为 vendored baseline 管理；checkpoint、测试集副本、缓存和生成结果继续留在本地，不纳入 git。
      复现 MARL-MRT2A 官方实现:
        - 沿用官方 PyMARL MAPPO learner、CNN actor/critic、空间目标表示以及 target revision/change 机制。
        - 增加按 checkpoint 独立评估的入口，观察训练回报和不同等级目标的完成情况是否随训练推进。
      固定复现边界:
        - 原始环境结果只用于确认官方方法可以运行并产生合理的学习趋势，不与 DelivCoal success 直接横向比较。
        - HATT-GymRT2A 路径补齐统一 gate action 接口，使原环境 runner 与当前共享 runner 的返回值保持一致。
    结论:
      验证:
        - 发现: CFM 官方 checkpoint 能在官方 RALTestSet 上完成全部 50 个场景，官方推理链路可以复现。
          依据:
            - 50 个场景 success 为 100%，平均 makespan 约 28.7。
        - 发现: CFM 从随机初始化开始的小规模训练能够快速学会官方环境。
          依据:
            - held-out success 从初始 checkpoint 的约 19.5% 提升到第 50 次更新的约 98.8%，第 300 次更新达到 100%。
        - 发现: MARL-MRT2A 小规模训练呈现明确的学习趋势。
          依据:
            - checkpoint 的测试回报均值从 1000 步的约 54.5 提升到 301000 步的约 384.3，同时二、三级目标占比明显增加。
      边界:
        - 这些结果验证的是官方代码与训练路径，不是论文全部表格的逐项复现，也不能直接说明它们在 DelivCoal 上的表现。
    commits: [619a85]

  v0.21.2:
    时间:
      - 2026-08-28 19:14:00
      - 2026-08-31 00:01:31
    重要性: 8.5
    标题: 在 DelivCoal 上复现 CFM 与 MARL-MRT2A
    摘要: 官方环境复现只能说明代码能运行，不能回答外部方法在本项目任务上的水平。本次保留 CFM 的序贯 pointer 分配和 MARL-MRT2A 的空间目标策略，把两者接入同一套 DelivCoal 场景、动作约束、训练预算和评估指标，形成第一轮可以与 PCFA、MAPPO 和 HATT 横向比较的学习基线。
    内容:
      将 CFM 接入 DelivCoal:
        - 把当前可见任务和智能体特征转换成 CFM 的任务矩阵与智能体集合，pointer 输出再恢复为原始 DelivCoal 动作编号。
        - 继续使用官方 AttentionNet、序贯分配、REINFORCE 和 POMO 组内基线；非活动智能体保持当前联盟，不参与本轮重新分配。
        - 当前可选任务采用稳定顺序排列，满足官方网络的输入假设，同时保留原候选集合和动作合法性。
      将 MARL-MRT2A 接入 DelivCoal:
        - 把可用任务按相对方向放入 21 × 21 局部网格，CNN 选择的单元再确定性映射回任务编号。
        - 保留官方 PyMARL MAPPO learner、CNN actor/critic、distance factor、current-target factor 和目标修正机制。
        - 初始网格包含任务类型与属性、队友位置、当前目标和智能体是否处于重选时刻，动作 mask 保证输出只能落在当前可选任务上。
      对齐训练与评估:
        - 两种方法统一使用 4 UAV、8 UGV、10 个隐藏配送任务、8 个探索扇区、750 步上限和 full-random reset。
        - checkpoint 选择依次比较 success、任务完成率和配送比例；训练期验证、最后 10% 轨迹与 validation-best/last 最终测试使用分开的场景种子。
        - 第一轮共同筛选预算为 150000 环境步，用来确认完整训练、checkpoint 保存和三阶段评估都能走通，不作为最终算法排名。
      使长回合训练能够完成:
        - MARL-MRT2A 的旧策略前向关闭梯度，actor 与 critic 的 750 步序列按时间块累计损失，避免一次保留完整序列造成显存溢出。
        - CFM 与 MARL-MRT2A 的训练和评估进度写入统一状态结构，页面可以显示当前环境步、评估阶段、已运行时间和 ETA；这些展示不改变实验结论。
    结论:
      验证:
        - 发现: 两种外部学习方法都能在 DelivCoal 上完成训练、保存 checkpoint，并走完整个训练期验证、末期轨迹和最终测试流程。
          依据:
            - 单 seed 筛选的两个训练任务均完成，三阶段评估的 planned、submitted 和 completed 工作量全部一致，没有失败单元。
        - 发现: 第一轮 150000 步只证明适配链路成立，性能远未达到可比较的水平。
          依据:
            - CFM last 在 16 个最终测试场景中 success 为 0，任务完成率约 3.1%。
            - MARL-MRT2A last 同样为 0 success，任务完成率约 3.8%。
      判断:
        - 低结果不能直接说明官方方法不适合 DelivCoal，因为第一轮 MARL-MRT2A 输入没有能力信息，CFM 的逐步贪心评估也可能与其采样训练方式不匹配。
      问题:
        - 当前只是单训练 seed 和缩短预算的适配筛选，不能进入最终横向排名。
    commits: [512d64]

  v0.21.3:
    时间:
      - 2026-08-31 00:01:31
      - 2026-08-31 13:30:23
    重要性: 7.5
    标题: 校正外部方法的 DelivCoal 复现条件
    摘要: 第一轮适配虽然完整跑通，但 CFM 和 MARL-MRT2A 都接近零完成，继续直接加长训练没有意义。复查后发现，MARL-MRT2A 的空间观测没有提供决定联盟能力匹配所需的能力向量，CFM 的评估又使用了与采样训练不同的逐步贪心决策。本次先补齐这两项条件，再分别扩大训练预算和关键超参数对照。
    内容:
      补齐 MARL-MRT2A 能力输入:
        - 在原有 12 个空间通道之外加入当前智能体的四维能力，以及同一网格位置附近队友的四维能力汇总。
        - 任务类型、任务属性、队友位置、当前目标和重选状态等原有通道保持不变，空间动作和网络主体也不改。
        - 增加测试确认不同能力的智能体不再因为位置相同而得到完全相同的空间观测。
      对齐 CFM 训练与评估决策:
        - checkpoint 评估支持固定 policy seed 的采样解码，使同一模型和场景能够复现，同时保留贪心模式作为对照。
        - CFM 加长训练时使用采样结果选择 validation-best，避免用与训练分布不一致的逐步贪心结果过早否定模型。
      扩大有效对照:
        - MARL-MRT2A 分别检查默认设置、较低学习率和较高熵系数，判断近零完成来自输入缺失还是优化设置。
        - CFM 增加更长的采样训练；两种方法继续使用相同 DelivCoal 场景和独立验证种子。
        - 调度器保持失败单元和未提交单元，不通过缩小评估分母掩盖未完成实验。
