OpenResearch 实验证据包设计指南以 nanochat demo evidence 为例解读可审计、可复现的轻量实验产物管理【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch在 OpenResearch 的 demo 项目中demo/nanochat是一个完整的 nanoGPT 风格小模型训练演示而demo/nanochat/evidence则是它沉淀下来的证据包evidence pack。本文围绕 demo/nanochat/evidence/README.md 展开系统讲解这套证据包的设计初衷、目录结构、文件语义、生成机制与复现路径读完本文你将掌握如何在不打包数 GB 训练工作区的前提下保存一份可审计、可复现、可被后续分析直接消费的实验证据。一、为什么需要证据包问题背景与设计目标一次完整的 nanochat 实验会产生多种产物模型权重、优化器状态、训练日志、评估结果、分词器、推理转录等。其中模型权重model_*.pt与优化器状态optim_*_rank0.pt单个文件即可达到数百 MB——以 run-manifest.json 的记录为例一个 base checkpoint 的model_005000.pt为 294,145,379 字节对应的optim_005000_rank0.pt为 545,905,413 字节加上 SFT 阶段的两份同类文件仅权重与优化器就接近 1.7 GB再叠加base_data_climbmix9 个文件约 826 MB、task_data24 个文件约 1.02 GB与eval_bundle77 个文件约 169 MB整个工作区高达数 GB。把这些大文件全部提交进 Git 仓库或项目制品既无必要也不现实。因此 evidence 包遵循一个明确的分层策略打包进证据包体积小、信息密度高、能支撑查看实验结论的小型产物——训练指标、评估指标、checkpoint 元数据、分词器、推理转录、产物清单留在运行工作区模型权重、优化器状态、数据集、评测语料、Python 环境与包缓存——它们体积巨大且可由脚本重新生成。这套设计让任何人 clone 仓库后无需下载数 GB 文件即可快速检视实验的关键结论同时通过run-manifest.json保留了大文件的路径、字节数与哈希保证哪些文件被有意排除这一点完全透明、可追溯。二、证据包目录结构与文件语义demo/nanochat/evidence下的完整结构如下evidence/ ├── README.md # 证据包说明本文主体 ├── training-metrics.csv # 逐 step 训练指标 ├── evaluation-metrics.json # 评估与最终指标 ├── final-inference.txt # 最终 SFT 检查点推理转录 ├── run-manifest.json # 产物清单含哈希 ├── checkpoints/ │ ├── base/ │ │ └── meta_005000.json # 最终 base 检查点元数据 │ └── sft/ │ └── meta_001499.json # 最终 SFT 检查点元数据 └── tokenizer/ ├── tokenizer.pkl # 分词器对象pickle 格式 └── token_bytes.pt # 分词器字节表PyTorch tensor2.1training-metrics.csv逐 step 的训练轨迹CSV 首行为表头phase,step,loss,validation_bpb,tokens_per_second,total_minutesphase取base或sft按 phase 与 step 升序排列。以 base 阶段第 0、100、5000 步为例phasesteplossvalidation_bpbtokens_per_secondtotal_minutesbase010.3975513.19580060720.00base1006.3744921.940739105132.30base50003.7514671.16575811048131.55其中validation_bpb仅在每个eval_every步base 为 100SFT 为 200记录一次SFT 阶段 step 0 的1.0174来自 SFT 开始前的初始验证。整份 CSV 共 6502 行覆盖 base 5000 步与 SFT 1500 步。它直观展示了 base 阶段 loss 从约 10.4 平滑下降至 3.75、吞吐稳定在 1 万 token/秒左右的完整过程是检查训练健康度、复现曲线的主力数据源。2.2evaluation-metrics.json评估结论的单一入口该文件把三块结论浓缩为一个 JSONbaseEvaluationbase 阶段训练的trainBpb1.152185与validationBpb1.119301corebase 检查点在 CORE 任务集上的逐项结果包含bigbench_qa_wikidataaccuracy 0耗时 0.82s、openbook_qa0.251s、winogrande0.5625centered 0.1250.79s、bigbench_operators01.2s四项字段为task、accuracy、centered、secondsfinal最终结论——baseValidationBpb为 1.165758sftValidationBpb为 0.7389chatAnswer为Paris即 SFT 后模型对法国首都提问的回答。注意final.baseValidationBpb1.165758与baseEvaluation.validationBpb1.119301数值不同前者来自训练日志中 base 最后一轮验证即 CSV 中 base step 5000 的 1.165758后者来自base_eval的独立评估二者口径不同在分析时不可混用。2.3 checkpoint 元数据复现训练配置的权威记录checkpoints/base/meta_005000.json 记录 base 阶段第 5000 步val_bpb1.16576、模型结构sequence_len512、vocab_size32768、n_layer6、n_head6、n_kv_head6、n_embd384、window_patternL以及完整的user_config——包括学习率分策略embedding_lr0.3、unembedding_lr0.008、matrix_lr0.02、scalar_lr0.5、批量配置device_batch_size32、total_batch_size16384、warmup/warmdown 计划warmup_steps40、warmdown_ratio0.65、final_lr_frac0.05、数据流状态pq_idx2、rg_idx48、epoch1与循环状态min_val_bpb、smooth_train_loss3.75147、total_training_time7893.22 秒。checkpoints/sft/meta_001499.json 记录 SFT 第 1499 步val_bpb0.73887user_config中load_optimizer为 0SFT 使用全新优化器、init_lr_frac0.8、warmup_ratio0.0、warmdown_ratio0.5、final_lr_frac0.0、eval_every200、mmlu_epochs3、gsm8k_epochs4。这两份元数据不依赖权重即可完整描述模型长什么样、用什么配置训练的是对外复现与审计的核心证据。2.4final-inference.txt推理结论的原始转录final-inference.txt 记录了最终 SFT 检查点的一次真实推理Command: python -m scripts.chat_cli -p What is the capital of France? Checkpoint: chatsft_checkpoints/d6/model_001499.pt Checkpoint step: 1499 Device: mps Prompt: What is the capital of France? Response: Paris Paris is a city known for its historical and cultural significance. ... Run status: completed successfully它保留了设备mps即 Apple Silicon 的 Metal 后端与运行状态其含义是一个在 MacBook 上训练 131 分钟的小模型确实能回答出Paris——但后续文本出现大量重复数字串也如实暴露了小模型在长文本生成上的缺陷。转录如实保存不美化结果这正是证据应有的姿态。2.5run-manifest.json包内与包外的分界清单清单schemaVersion 1记录了本次运行的命令、设备mps、状态completed、base 目录$ORX_RUN_DIR/repo/.cache/nanochat以及每个产物的四元信息path工作区相对路径、kindcheckpoint_metadata/model_checkpoint/optimizer_checkpoint/tokenizer、bytes、sha256并用bundledAt标明是否打包进 evidence 及目标位置。例如base_checkpoints/d6/meta_005000.json的bundledAt为evidence/checkpoints/base/meta_005000.json而 294 MB 的model_005000.pt的bundledAt为null。末尾的omittedDirectories精确列出被排除的三个目录及其文件数与总字节数。这份清单的价值在于哪些文件是证据包主动排除的不再依赖口头约定而是机器可读的事实后续分析可以据此区分仓库里有的文件与本地才有的文件。三、生成机制generate-demo-evidence.mjs是如何工作的README 明确指出training-metrics.csv与evaluation-metrics.json并非手工整理而是由 scripts/generate-demo-evidence.mjs 从 demo/nanochat/run-output.txt 重新生成checkpoint 元数据、分词器文件、推理转录与清单则是从真实运行中直接保留。该脚本的解析逻辑如下以 Supervised fine-tuning 为分界切换phasebase → sft用正则^step (\d)(?:\/\d)? .*?\| loss: ([\d.]).*?\| tok\/sec: ([\d,]).*?\| total time: ([\d.])m解析每步训练日志写入loss、tokensPerSecond、totalMinutes用^Step (\d) \| Validation bpb: ([\d.])解析周期性验证的 BPBbase 阶段另用^train bpb:/^val bpb:解析baseEvaluation用^Evaluating: ([^ ]).*?accuracy: ([\d.]) \| centered: ([\d.]) \| time: ([\d.])s解析 CORE 任务逐项结果最终通过findLast取两个 phase 各自最后一轮验证 BPB 作为final.baseValidationBpb与final.sftValidationBpbchatAnswer固定记录为Paris对应推理转录中的回答。从实现可见两个设计要点其一CSV 与 JSON 是日志的可复算派生品只要保留原始日志任何一步都可以重新推导防止人工转录错误其二JSON 里final段的 BPB 与 CSV 中对应 step 的validation_bpb完全一致1.165758 / 0.7389两处数据互相印证。这也提示读者复现证据包时只需保证run-output.txt中这几类日志行的格式稳定生成脚本即可直接复用。四、有意省略的内容与复现路径README 明确列出不打包的部分模型权重、优化器状态、下载的数据集、评估语料、Python 环境与包缓存。这些内容体积达数 GB且正常保留在运行本地工作区即$ORX_RUN_DIR/repo/.cache/nanochat不应进入 Git 仓库或项目制品。若要在全新环境中完整复现这套工作区README 给出的命令是bash runs/runcpu.sh。该脚本位于 demo/nanochat/experiment/runs/runcpu.shdemo/nanochat/base/runs/runcpu.sh亦存在同源版本其关键流程为环境准备设置NANOCHAT_BASE_DIR与UV_CACHE_DIR到.cache下若无uv则按平台安装Windows 用 PowerShell 安装脚本其余用curl | shuv sync --extra cpu安装 CPU 依赖并激活虚拟环境分词器训练python -m nanochat.dataset -n 8准备数据python -m scripts.tok_train --max-chars2000000000在约 20 亿字符上训练分词器脚本注释提到在 MacBook Pro M3 Max 上约 34 秒随后python -m scripts.tok_eval校验base 阶段python -m scripts.base_train以--depth6 --head-dim64 --window-patternL --max-seq-len512 --device-batch-size32 --total-batch-size16384 --eval-every100 --eval-tokens524288 --core-metric-every-1 --sample-every100 --num-iterations5000训练 6 层小模型注释称该配置在 M3 Max 上约 30 分钟完成随后python -m scripts.base_eval --device-batch-size1 --split-tokens16384 --max-per-task16做 CORE 评估SFT 阶段python -m scripts.chat_sft --load-optimizer0 --eval-every200 --eval-tokens524288 --chatcore-every-1 --num-iterations1500使用全新优化器继续训练 1500 步对话验证python -m scripts.chat_cli -p What is the capital of France?脚本注释提示模型应能答出 Paris也提示先打招呼再提问效果可能更好。脚本开头的注释也对预期做了坦诚限定训练 LLM 需要 GPU 算力与预算在 MacBook 上你不会走太远请把这个运行当作教育/娱乐演示而不是预期能跑出很好效果的东西——这与 demo/nanochat/base/README.md 的定位一致。证据包记录的mps设备与约 1.1 万 token/秒的吞吐也正是这套 CPU/MPS 演示环境的真实写照。五、安全注意事项pickle 格式的加载边界README 特别强调tokenizer/tokenizer.pkl使用 Python 的 pickle 格式必须只通过 nanochat 可信的分词器代码加载。pickle 反序列化存在任意代码执行风险直接pickle.load不可信文件等同于执行其中嵌入的任意代码。实际使用时应当走 nanochat 自身的分词器入口如 demo/nanochat/base/nanochat/tokenizer.py 提供的加载路径由训练代码在同一环境下保存、同一套代码加载形成可信闭环。配合 run-manifest.json 中记录的tokenizer.pkl412,105 字节SHA-256387cfc08...与token_bytes.pt132,649 字节SHA-256409e71bd...的哈希值可以校验文件完整性后再加载。六、小结把证据做成工程资产回顾 nanochat 的 evidence 包可以提炼出四条可迁移到任何研究项目中的工程原则分层打包按体积与信息密度划分入包与留本地避免仓库被数 GB 二进制撑爆派生数据可复算CSV/JSON 由原始日志经 generate-demo-evidence.mjs 确定性生成任何一步结论都能回溯推导清单即审计接口run-manifest.json用路径 字节数 SHA-256 bundledAt四元组划清打包/未打包边界哈希可校验、可区分结论与局限并陈既保留答出 Paris的成功转录也如实保留长文本重复的原始输出不修饰证据。对于使用 OpenResearch 管理实验的用户而言这套 evidence 模式同样适用于 agent-skills/orx-evidence 所倡导的证据留存实践——把小型、高信息密度、可复算的产物沉淀为仓库内的一等公民而把可再生的巨型产物留给运行工作区是让实验结论长期可查、可引、可复现的最经济方案。【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenResearch 实验证据包设计指南：以 nanochat demo evidence 为例解读可审计、可复现的轻量实验产物管理
OpenResearch 实验证据包设计指南以 nanochat demo evidence 为例解读可审计、可复现的轻量实验产物管理【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch在 OpenResearch 的 demo 项目中demo/nanochat是一个完整的 nanoGPT 风格小模型训练演示而demo/nanochat/evidence则是它沉淀下来的证据包evidence pack。本文围绕 demo/nanochat/evidence/README.md 展开系统讲解这套证据包的设计初衷、目录结构、文件语义、生成机制与复现路径读完本文你将掌握如何在不打包数 GB 训练工作区的前提下保存一份可审计、可复现、可被后续分析直接消费的实验证据。一、为什么需要证据包问题背景与设计目标一次完整的 nanochat 实验会产生多种产物模型权重、优化器状态、训练日志、评估结果、分词器、推理转录等。其中模型权重model_*.pt与优化器状态optim_*_rank0.pt单个文件即可达到数百 MB——以 run-manifest.json 的记录为例一个 base checkpoint 的model_005000.pt为 294,145,379 字节对应的optim_005000_rank0.pt为 545,905,413 字节加上 SFT 阶段的两份同类文件仅权重与优化器就接近 1.7 GB再叠加base_data_climbmix9 个文件约 826 MB、task_data24 个文件约 1.02 GB与eval_bundle77 个文件约 169 MB整个工作区高达数 GB。把这些大文件全部提交进 Git 仓库或项目制品既无必要也不现实。因此 evidence 包遵循一个明确的分层策略打包进证据包体积小、信息密度高、能支撑查看实验结论的小型产物——训练指标、评估指标、checkpoint 元数据、分词器、推理转录、产物清单留在运行工作区模型权重、优化器状态、数据集、评测语料、Python 环境与包缓存——它们体积巨大且可由脚本重新生成。这套设计让任何人 clone 仓库后无需下载数 GB 文件即可快速检视实验的关键结论同时通过run-manifest.json保留了大文件的路径、字节数与哈希保证哪些文件被有意排除这一点完全透明、可追溯。二、证据包目录结构与文件语义demo/nanochat/evidence下的完整结构如下evidence/ ├── README.md # 证据包说明本文主体 ├── training-metrics.csv # 逐 step 训练指标 ├── evaluation-metrics.json # 评估与最终指标 ├── final-inference.txt # 最终 SFT 检查点推理转录 ├── run-manifest.json # 产物清单含哈希 ├── checkpoints/ │ ├── base/ │ │ └── meta_005000.json # 最终 base 检查点元数据 │ └── sft/ │ └── meta_001499.json # 最终 SFT 检查点元数据 └── tokenizer/ ├── tokenizer.pkl # 分词器对象pickle 格式 └── token_bytes.pt # 分词器字节表PyTorch tensor2.1training-metrics.csv逐 step 的训练轨迹CSV 首行为表头phase,step,loss,validation_bpb,tokens_per_second,total_minutesphase取base或sft按 phase 与 step 升序排列。以 base 阶段第 0、100、5000 步为例phasesteplossvalidation_bpbtokens_per_secondtotal_minutesbase010.3975513.19580060720.00base1006.3744921.940739105132.30base50003.7514671.16575811048131.55其中validation_bpb仅在每个eval_every步base 为 100SFT 为 200记录一次SFT 阶段 step 0 的1.0174来自 SFT 开始前的初始验证。整份 CSV 共 6502 行覆盖 base 5000 步与 SFT 1500 步。它直观展示了 base 阶段 loss 从约 10.4 平滑下降至 3.75、吞吐稳定在 1 万 token/秒左右的完整过程是检查训练健康度、复现曲线的主力数据源。2.2evaluation-metrics.json评估结论的单一入口该文件把三块结论浓缩为一个 JSONbaseEvaluationbase 阶段训练的trainBpb1.152185与validationBpb1.119301corebase 检查点在 CORE 任务集上的逐项结果包含bigbench_qa_wikidataaccuracy 0耗时 0.82s、openbook_qa0.251s、winogrande0.5625centered 0.1250.79s、bigbench_operators01.2s四项字段为task、accuracy、centered、secondsfinal最终结论——baseValidationBpb为 1.165758sftValidationBpb为 0.7389chatAnswer为Paris即 SFT 后模型对法国首都提问的回答。注意final.baseValidationBpb1.165758与baseEvaluation.validationBpb1.119301数值不同前者来自训练日志中 base 最后一轮验证即 CSV 中 base step 5000 的 1.165758后者来自base_eval的独立评估二者口径不同在分析时不可混用。2.3 checkpoint 元数据复现训练配置的权威记录checkpoints/base/meta_005000.json 记录 base 阶段第 5000 步val_bpb1.16576、模型结构sequence_len512、vocab_size32768、n_layer6、n_head6、n_kv_head6、n_embd384、window_patternL以及完整的user_config——包括学习率分策略embedding_lr0.3、unembedding_lr0.008、matrix_lr0.02、scalar_lr0.5、批量配置device_batch_size32、total_batch_size16384、warmup/warmdown 计划warmup_steps40、warmdown_ratio0.65、final_lr_frac0.05、数据流状态pq_idx2、rg_idx48、epoch1与循环状态min_val_bpb、smooth_train_loss3.75147、total_training_time7893.22 秒。checkpoints/sft/meta_001499.json 记录 SFT 第 1499 步val_bpb0.73887user_config中load_optimizer为 0SFT 使用全新优化器、init_lr_frac0.8、warmup_ratio0.0、warmdown_ratio0.5、final_lr_frac0.0、eval_every200、mmlu_epochs3、gsm8k_epochs4。这两份元数据不依赖权重即可完整描述模型长什么样、用什么配置训练的是对外复现与审计的核心证据。2.4final-inference.txt推理结论的原始转录final-inference.txt 记录了最终 SFT 检查点的一次真实推理Command: python -m scripts.chat_cli -p What is the capital of France? Checkpoint: chatsft_checkpoints/d6/model_001499.pt Checkpoint step: 1499 Device: mps Prompt: What is the capital of France? Response: Paris Paris is a city known for its historical and cultural significance. ... Run status: completed successfully它保留了设备mps即 Apple Silicon 的 Metal 后端与运行状态其含义是一个在 MacBook 上训练 131 分钟的小模型确实能回答出Paris——但后续文本出现大量重复数字串也如实暴露了小模型在长文本生成上的缺陷。转录如实保存不美化结果这正是证据应有的姿态。2.5run-manifest.json包内与包外的分界清单清单schemaVersion 1记录了本次运行的命令、设备mps、状态completed、base 目录$ORX_RUN_DIR/repo/.cache/nanochat以及每个产物的四元信息path工作区相对路径、kindcheckpoint_metadata/model_checkpoint/optimizer_checkpoint/tokenizer、bytes、sha256并用bundledAt标明是否打包进 evidence 及目标位置。例如base_checkpoints/d6/meta_005000.json的bundledAt为evidence/checkpoints/base/meta_005000.json而 294 MB 的model_005000.pt的bundledAt为null。末尾的omittedDirectories精确列出被排除的三个目录及其文件数与总字节数。这份清单的价值在于哪些文件是证据包主动排除的不再依赖口头约定而是机器可读的事实后续分析可以据此区分仓库里有的文件与本地才有的文件。三、生成机制generate-demo-evidence.mjs是如何工作的README 明确指出training-metrics.csv与evaluation-metrics.json并非手工整理而是由 scripts/generate-demo-evidence.mjs 从 demo/nanochat/run-output.txt 重新生成checkpoint 元数据、分词器文件、推理转录与清单则是从真实运行中直接保留。该脚本的解析逻辑如下以 Supervised fine-tuning 为分界切换phasebase → sft用正则^step (\d)(?:\/\d)? .*?\| loss: ([\d.]).*?\| tok\/sec: ([\d,]).*?\| total time: ([\d.])m解析每步训练日志写入loss、tokensPerSecond、totalMinutes用^Step (\d) \| Validation bpb: ([\d.])解析周期性验证的 BPBbase 阶段另用^train bpb:/^val bpb:解析baseEvaluation用^Evaluating: ([^ ]).*?accuracy: ([\d.]) \| centered: ([\d.]) \| time: ([\d.])s解析 CORE 任务逐项结果最终通过findLast取两个 phase 各自最后一轮验证 BPB 作为final.baseValidationBpb与final.sftValidationBpbchatAnswer固定记录为Paris对应推理转录中的回答。从实现可见两个设计要点其一CSV 与 JSON 是日志的可复算派生品只要保留原始日志任何一步都可以重新推导防止人工转录错误其二JSON 里final段的 BPB 与 CSV 中对应 step 的validation_bpb完全一致1.165758 / 0.7389两处数据互相印证。这也提示读者复现证据包时只需保证run-output.txt中这几类日志行的格式稳定生成脚本即可直接复用。四、有意省略的内容与复现路径README 明确列出不打包的部分模型权重、优化器状态、下载的数据集、评估语料、Python 环境与包缓存。这些内容体积达数 GB且正常保留在运行本地工作区即$ORX_RUN_DIR/repo/.cache/nanochat不应进入 Git 仓库或项目制品。若要在全新环境中完整复现这套工作区README 给出的命令是bash runs/runcpu.sh。该脚本位于 demo/nanochat/experiment/runs/runcpu.shdemo/nanochat/base/runs/runcpu.sh亦存在同源版本其关键流程为环境准备设置NANOCHAT_BASE_DIR与UV_CACHE_DIR到.cache下若无uv则按平台安装Windows 用 PowerShell 安装脚本其余用curl | shuv sync --extra cpu安装 CPU 依赖并激活虚拟环境分词器训练python -m nanochat.dataset -n 8准备数据python -m scripts.tok_train --max-chars2000000000在约 20 亿字符上训练分词器脚本注释提到在 MacBook Pro M3 Max 上约 34 秒随后python -m scripts.tok_eval校验base 阶段python -m scripts.base_train以--depth6 --head-dim64 --window-patternL --max-seq-len512 --device-batch-size32 --total-batch-size16384 --eval-every100 --eval-tokens524288 --core-metric-every-1 --sample-every100 --num-iterations5000训练 6 层小模型注释称该配置在 M3 Max 上约 30 分钟完成随后python -m scripts.base_eval --device-batch-size1 --split-tokens16384 --max-per-task16做 CORE 评估SFT 阶段python -m scripts.chat_sft --load-optimizer0 --eval-every200 --eval-tokens524288 --chatcore-every-1 --num-iterations1500使用全新优化器继续训练 1500 步对话验证python -m scripts.chat_cli -p What is the capital of France?脚本注释提示模型应能答出 Paris也提示先打招呼再提问效果可能更好。脚本开头的注释也对预期做了坦诚限定训练 LLM 需要 GPU 算力与预算在 MacBook 上你不会走太远请把这个运行当作教育/娱乐演示而不是预期能跑出很好效果的东西——这与 demo/nanochat/base/README.md 的定位一致。证据包记录的mps设备与约 1.1 万 token/秒的吞吐也正是这套 CPU/MPS 演示环境的真实写照。五、安全注意事项pickle 格式的加载边界README 特别强调tokenizer/tokenizer.pkl使用 Python 的 pickle 格式必须只通过 nanochat 可信的分词器代码加载。pickle 反序列化存在任意代码执行风险直接pickle.load不可信文件等同于执行其中嵌入的任意代码。实际使用时应当走 nanochat 自身的分词器入口如 demo/nanochat/base/nanochat/tokenizer.py 提供的加载路径由训练代码在同一环境下保存、同一套代码加载形成可信闭环。配合 run-manifest.json 中记录的tokenizer.pkl412,105 字节SHA-256387cfc08...与token_bytes.pt132,649 字节SHA-256409e71bd...的哈希值可以校验文件完整性后再加载。六、小结把证据做成工程资产回顾 nanochat 的 evidence 包可以提炼出四条可迁移到任何研究项目中的工程原则分层打包按体积与信息密度划分入包与留本地避免仓库被数 GB 二进制撑爆派生数据可复算CSV/JSON 由原始日志经 generate-demo-evidence.mjs 确定性生成任何一步结论都能回溯推导清单即审计接口run-manifest.json用路径 字节数 SHA-256 bundledAt四元组划清打包/未打包边界哈希可校验、可区分结论与局限并陈既保留答出 Paris的成功转录也如实保留长文本重复的原始输出不修饰证据。对于使用 OpenResearch 管理实验的用户而言这套 evidence 模式同样适用于 agent-skills/orx-evidence 所倡导的证据留存实践——把小型、高信息密度、可复算的产物沉淀为仓库内的一等公民而把可再生的巨型产物留给运行工作区是让实验结论长期可查、可引、可复现的最经济方案。【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考