details/<state>/<readable-task-id>--<sha256>/ 目录。<state> 按所有 attempt 最终问题的最高等级取 normal、error 或 fatal，仅含 warning 的结果属于 normal，尚未完成的任务位于 running。哈希根据原始 task ID 计算，字符替换和截断只影响可读前缀。
文件
问题保存在结果内部，不再通过
_error_ 文件名前缀区分；状态目录只用于分组。报告、复用、结果浏览器和离线分析通过索引重建逻辑任务记录。下面展示的是重建后的记录；磁盘上的完整 attempts 内容分别保存在各自文件中。
task.json 落盘示例
下面是已分配三次 attempt 后的 task 层task.json。新建目录使用 attempt-<n>，其中 n 为从 1 开始的逻辑 attempt 序号。执行期间先写入身份映射，attempt 内容落盘后再发布共享结果信息。
result.json。任务 retry 总数及稀疏 retry_counts 映射由各 attempt 保存的 retry_count 计算。仅分配身份而没有结果的 attempt 不算已完成观测；没有结果内容的终态失败可以保留只含 retry 次数的记录。
attempt 目录名必须与逻辑序号一致，例如 "1": "attempt-1"。跨 run 复用时，新 run 使用 attempt-<n> 并同步更新产物引用，不修改来源结果。失败重试仍属于同一个逻辑 attempt，旧执行产物归档到该目录的 retries/ 下。旧目录结构和复用支持情况见 Legacy。
任务详情示例
null、"" 或 {}。示例中的 ... 仅表示组件专属内容；命名空间没有内容时写为 {}。
任务级字段
attempt 级字段
每次 attempt 都会写入全部标准字段。空值也会保留，确保所有任务详情具有相同字段集合。meta 命名空间
两个命名空间始终存在，为空时使用
{}。它们内部由组件定义的特殊字段不属于公共任务详情结构。
解析后的 Environment、Recipe 和网络计划统一存放在 run_info.json.resolved_execution_plans，详见运行记录与诊断。
trajectory 结构
存在trajectory 时，它采用 AgentCompass 的 ACTF_v1.0 结构：
常见步骤字段包括
step_id、prompt、assistant 内容、工具调用、观测、时间戳，以及 metric 中的 token 与耗时数据。Harness 可以省略自身不产生的数据。
分析结果
analysis_result.<analyzer-family> 可以包含 is_badcase、score、details、error 和 extra。这些是分析器诊断，不会改变 attempt.metrics 或状态。运行级分析文件会在 Benchmark 指标聚合之外单独合并各次 attempt 的分析输出，详见汇总与分析。
retry 详情
失败命中 retry 规则且仍有预算时，AgentCompass 会先写入agentcompass.retry.v1 诊断，再重做当前逻辑 attempt：
attempt 标识不变的逻辑尝试，retry 是该 attempt 内从 1 开始的重试编号。stage 定位失败阶段，scope 说明 runtime 会重做完整 attempt 还是只重做评测。discarded_result 仅用于诊断，无需符合严格的任务详情结构。
已经完成的同任务 attempt 会继续保留 checkpoint。例如，第 3 次尝试发生 retry 时不会重做第 1、2 次。最终任务详情记录已消耗的 retry 次数，只有终态 attempt payload 才提供指标观测。