PRAXIST 任务初始化实战:把已有可运行科研工程改造成可量化自动研究任务

  • 人工智能
  • AI Agent
  • 多智能体
  • Agent 工作流
  • 深度研究
  • AI 评测

【免费下载链接】PRAXIST

Autonomous research system for measurable, computer-executable research.

项目地址: https://gitcode.com/gh_mirrors/pr/PRAXIST
点击查看 免费下载

PRAXIST(Autonomous research system for measurable, computer-executable research)的核心工作方式,是把用户已经能跑起来的算法、机器人、控制、仿真、SLAM、LLM 优化等科研工程,包装成一个正式的"任务工程(task project)",再交给通用研究循环去自动探索、评估与收敛。本文讲解 skills/praxist-task-initialization/SKILL.md 定义的完整初始化流程:从前置条件检查、项目清单扫描、硬件与运行参数规划,到 task.yaml 的成熟度/前沿通道/收敛策略配置、评估器预检与 35 项强制验证。读完你可以亲手把任意可运行研究仓库改造成可被 praxist start --task-path ... 启动的正式任务,并理解其背后"测量优先、协议归任务所有、证据分级"的设计哲学。

1. 前置条件与中止条件:任务初始化不是"无中生有"

PRAXIST 任务初始化有一个强前提:它只包装已经存在的可运行工程,绝不为不存在的东西编造代码、数据或基线。SKILL 要求在任何扫描或编辑之前,先显著展示如下横幅:

**IMPORTANT PRECONDITION**
Praxist task initialization assumes:
1. You already have all source code for the research project.
2. The project already runs smoothly on this machine in some environment/container.
3. Required datasets, simulators, benchmark fixtures, or control environments are already present or reachable from this machine.

三项中任意一项不成立,就应停下来向用户索要缺失的路径、环境、数据集或仿真器,而不是继续产出弱任务。同样,当出现以下中止条件时,应中止而不是勉强拼凑:

  • 必要源码缺失,例如评估器存在但模型/训练/仿真器接口不存在;
  • 所需数据集、检查点、仿真器、机器人环境或基准夹具缺失;
  • 用户指定的运行时环境/容器缺少必需 import、二进制或仿真器绑定;
  • 找不到可执行的基线或可信的评估路径。

中止时报告三件事:缺什么、为什么它阻塞 PRAXIST、用户应当提供路径、安装依赖、挂载数据还是指定正确的环境。仓库中 docs/getting-started/first-task.md 用一张"就绪判定表"对应了这一原则:研究代码就绪 = 基线与正常入口存在;运行时就绪 = 解释器/环境/容器能导入依赖;数据或仿真器就绪 = 资产可通过项目正常接口本地触达;基线路径就绪 = 训练/优化/仿真/推理/评估在无 PRAXIST 时就能运行。

另外,当通过 praxist-takeover、praxist-takeover-codex 或用户直接调用本 skill 修复一个未通过 task-init 检查的既有任务时,必须保留其已确立的科学目标、评估器协议、指标方向、基线与运行时归属,只修改导致契约失败的 harness 组件,并重新运行同样的验证,避免重建无关任务文件。

2. 输入解析与模板定位:先找到"脚手架根"

初始化首先按顺序解析路径:

  1. 用户提供的研究项目路径;
  2. 当前 Agent 工作目录。

默认输出任务路径为 <research_project>/praxist_task(除非用户另行指定)。除读取项目与(在用户明确要求时)运行其文档化的 smoke/评估命令外,不得改动原始项目。

在读取或复制脚手架之前,必须解析模板根目录,不要假设源码检出一定存在(pip 安装后可能没有源码树):

  • 源码检出时使用 <praxist-repo>/templates/tasks/;
  • 否则用 importlib.resources 定位已安装包内的模板:
python - <<'PY'
from importlib.resources import files

print(files("praxist").joinpath("resources", "templates", "tasks"))
PY

SKILL 明确警告:不要用 examples/ 充当通用脚手架。完整示例保留了任务特有的代码、指标、证据与资源假设;如果用户选定某个捆绑示例,只能在 praxist examples install 生成的可写副本上操作,绝不能在 PRAXIST 源码或包资源内新建/修改 harness。仓库中实际可用的模板骨架包括 machine_learning_template(ML 项目适配基准)、template(最小脚手架/smoke 形态)与 sam_optimizer(领域参考,仅用于灵感)。

3. 用户拥有的协议意图:没有全局"全协议唯一"规则

这是 PRAXIST 任务初始化最容易被误解的一条设计决策:协议严格程度不是普适的,而是任务拥有的。在设计评估器、成熟度策略、通道与收敛门之前,必须从以下三个来源依次推导出一张"协议意图表"(protocol-intent table):

  1. 用户当前的明确指令;
  2. 与该指令不冲突的既有项目协议;
  3. 仅在前两者都无法决定时,采用科学上站得住脚的 Agent 提案。

表格必须列出每个允许的评估器模式/阶段,以及它是否允许:启动、产出可比分数、对候选排名、计入成熟证据、提供持久父代、满足代收敛。这张表存放在既有任务文档/协议文档中,并同步编码进评估器摘要、evaluation.maturity_policy、前沿通道、Gems 与收敛设置——不要为它创建第二个运行时事实注册表。

PRAXIST 不存在全局"必须全协议"规则。如果用户明确要求 partial、reduced-coverage、scout、diagnostic 等不完整协议用于排名/晋升/整轮运行,就保留该选择,在每次结果中暴露其真实 effort/coverage 与阶段,并让下游策略与之对齐;不要静默升级为完整协议、不要因为"不完整"就拒绝、也不要反复要求用户撤销已明确的决定。若用户尚未决定,建议"完整成熟协议 + 明确标注的廉价信号",但以提案而非系统要求呈现。

同时要保留既有 schema 名称以兼容:complete_stage_labels 指"任务声明的成熟标签",不是"全局全协议标签";scored_complete 指结果满足任务声明的可比证据契约,并不抹除降级模式的实际元数据。只有未声明的漂移才是协议完整性失败:实际模式/覆盖率/投入与任务表不一致的 run 必须保留为验证/诊断信号,不得冒充更成熟的类别。验证时应检查结构化评估器模式与输出元数据,而不是命令行关键字——不要因为 argv/路径/源文件里出现 smoke、scout、partial 字样就拒绝启动。

4. 扫描工作流:用捆绑清单工具建立项目事实

SKILL 规定的扫描流程为:

  1. 宣告前置条件横幅;
  2. 识别项目根与输出任务路径;
  3. 运行捆绑的清单工具:
python skills/praxist-task-initialization/scripts/project_inventory.py \
  --root /path/to/research-project \
  --out /path/to/output-task/assets/project_scan
  1. 阅读生成的 inventory.json 与 inventory_summary.md;
  2. 深度阅读理解任务所需的项目材料(README、设计文档、论文、notebook、配置、PDF、演示文稿、训练/推理/模型定义/仿真控制环/评估/指标/数据加载代码、数据集清单与解析器、仿真器适配器、既有结果日志等;大历史按目录/时间范围拆分并交给子 Agent,再合并为一份证据摘要);
  3. 检测运行时环境:conda(environment.yml)、venv/uv/poetry/pip(.venv、pyproject.toml、requirements.txt、uv.lock、poetry.lock)、容器(Dockerfile、compose.yaml)、外部运行时(ROS、MuJoCo、Isaac、Gymnasium、MATLAB、数据库服务等);
  4. 用最轻的安全命令验证环境:import 检查、--help、单元 smoke、dry-run、微型夹具或仿真器启动检查;除非用户要求,不运行长训练或评估扫描。

清单工具的实现(project_inventory.py)本身就是一份"项目事实提取器":它跳过 .git、node_modules、site-packages 等目录;按 docs/pdfs/reports/images/code/environment_files/data_candidates/result_log_candidates/simulator_candidates 分类收录文件;并通过正则启发式抓取指标线索(metric|accuracy|auc|f1|reward|success_rate|rmse|iou|bleu|rouge 等)与命令线索(python|bash|conda|pip|docker|roslaunch|make 等),把两类线索连同路径各收录最多 300 条片段。这解释了 SKILL 中"先跑清单、再读摘要、再深读"的顺序——清单负责快速建立覆盖面,深读负责科学理解。

5. 硬件与运行参数规划:先观测"未改动的公共基线"

PRAXIST 任务初始化产出的必须是执行计划,而不只是一堆静态任务文件。默认路径是根据硬件与任务成本估算参数;如果用户明确要求固定默认档位(等价于"跳过测量,用默认参数"),则使用如下固定档位,并注明这是用户选择而非测量结果:

generation_policy:
  cohort_size: 8
  max_generations: 20
  per_generation_hours: 2.0   # 120 minutes

固定档位只是运维便利,不是常规推荐——仍需验证项目可运行、数据/仿真器/运行时资产存在,只是跳过负载推导的规模估算。常规路径的观测纪律非常严格:

  • 硬件检查只用有界只读命令:CPU 用 lscpu//proc/cpuinfo/sysctl;内存用 free -h/vm_stat/sysctl(把 macOS 统一内存当作正常路径,计入共享容量);加速器先推断基线实际使用的后端,再用匹配的只读遥测源,记录后端、设备数、容量与当前负载,不预设厂商、独立 GPU、CUDA 或具体设备型号;磁盘用 df -h,避免全盘扫描。
  • 观测未改动的公共基线程序在其正常运行时下进行。优先既有 smoke、一个正常评估单元或最短的代表性完整协议单元。不要编写合成 CPU-only/GPU-only 竞品、不把基线计算在设备间搬移、不改变数据加载/worker 数/模型代码/精度/加速器可见性。采样的 CPU/内存/IO 压力、加速器显存/利用率、耗时与进度,覆盖进程全生命周期而非单次快照:在启动子进程前开始采样,加速器遥测每 100–200 ms 记一次带时间戳的利用率与显存,子进程退出才停止。短于约 5 秒的负载至少安全重复 3 次完全相同的负载,或改选更长的未改动代表单元,防止启动/收尾主导样本;不要把多次重复拼接成不同的科学协议。
  • 分类观测到的瓶颈,允许多个域与显式 unknown:加速器受限、CPU 受限、统一内存/内存/IO/仿真器/许可证/服务受限、混合受限等。
  • 估算单个实验墙钟时间(GPU 工作另估峰值显存与持续利用率):按完整子进程生命周期做时间加权,用多次重复的稳健上界而非瞬时最大值或最后样本;显存用观测峰值加适度余量。原始带时间戳样本保留在初始化实验目录中,在 assets/resource_plan.md 里汇总样本数、节奏、时长、均值/分位数、峰值与不确定性。只在收尾测到 0、少于 10 个有效样本或不一致短轨迹都不构成"零需求"证据。CPU 工作不声明/预留固定核心数;无法测得 GPU 显存/利用率时,省略这两个字段,让中央调度对该 profile 做独占放置。

6. 中央调度器配置与受管加速器交接契约

当实验是本地子进程、资源可观测、评估器可用 PRAXIST 拥有的启动方式时,配置 compute_budget.resource_scheduler.mode: central,并给出任务拥有的命名 profiles。典型契约:

compute_budget:
  resource_scheduler:
    mode: central
    initial_concurrent_experiments: <conservative measured start>
    min_concurrent_experiments: 1
    max_concurrent_experiments: <hardware/task upper bound>
    supply_signal_enabled: true
    supply_idle_samples: 3
    supply_lease_seconds: 600
    mature_supply_fraction: 0.25
    mature_supply_redundancy: 3.0
    mature_assessment_min_completion_probability: 0.25
    exploration_reserve: 1
    infrastructure_retries: 1
    default_profile: <public evaluator normal profile>
    profiles:
      cpu_ordinary:
        accelerator: cpu
        pressure_domains: [cpu, memory, io]
      gpu_train:
        accelerator: gpu
        gpu_count: 1
        gpu_memory_gb: <observed peak plus modest headroom>
        gpu_utilization_pct: <observed sustained demand>
        pressure_domains: [cpu, memory, io]

该契约在 docs/guides/central-resource-scheduler.md 中有完整展开:调度器拥有排队、最终 Popen、进程环境、基础设施重试与释放;default_profile 必须匹配公共评估器的正常资源形态(因为运行时辅助提交可能省略显式 profile);普通分析/汇总命令不应进入实验队列;CPU profile 不预留每实验核心;GPU 利用率与峰值显存是两个独立相加的逐设备硬限制;未知 GPU 需求 = 独占放置;不设隐式 GPU→CPU 回退,除非任务协议声明两者科学等价。

受管加速器交接契约仅当未改动基线使用 PRAXIST 可通过公共环境契约绑定的离散加速器后端时适用,不要仅为"存在设备"就给 CPU-only、任务自管、统一内存等后端生成这些变量:

  • PRAXIST_ASSIGNED_GPU_UUIDS:权威的有序物理 GPU 分配;
  • CUDA_VISIBLE_DEVICES:PRAXIST 交付的 CUDA 可见性掩码;
  • NVIDIA_VISIBLE_DEVICES:容器/运行时可见性掩码。

当 PRAXIST_ASSIGNED_GPU_UUIDS 非空时,harness 必须在每个子进程边界精确保留该 UUID 列表;任一可见性变量缺失时从前者恢复;可见性变量与分配冲突时,以清晰的加速器绑定完整性错误失败,而不是静默选设备。cuda:0 这类框架局部设备在继承的掩码内部是正确的,但绝不能以宿主序数 0 写回后代的可见性环境。只在独立模式(无 PRAXIST 分配)下才允许用运算符选择的整数设备构造掩码;显式 CPU 模式必须为该子进程清除 PRAXIST/CUDA/NVIDIA 加速器分配。交接逻辑应在最小的既有评估器/启动器 helper 中实现一次并复用整条进程链,并用 AST 感知分析检查 Python 启动器。

SKILL 还要求为托管后端添加聚焦的任务本地契约测试,覆盖:单个 UUID 精确保留、有序多 UUID 掩码精确保留、缺失掩码从 PRAXIST_ASSIGNED_GPU_UUIDS 恢复、冲突掩码大声失败、独立整数选择仍兼容、显式 CPU 清除加速器可见性、评估器→训练器→worker 传播保持同一物理掩码。对选定 PRAXIST 托管 NVIDIA/CUDA 后端且主机至少有两个可用设备的新任务,还要运行一次有界的非零设备启动就绪预检(真实评估器→计算子进程路径传递 UUID,创建微小 CUDA 分配,对比计算 PID 的物理 UUID 与调度器分配),这是绑定测试而非性能基准。实现证据位于 experiment_scheduler.py(含 PRAXIST_ASSIGNED_GPU_UUIDS 环境构造)与 protected_pids.py(受保护进程注册/清单/存活核对)。

7. 运行参数落地:成熟度供给、首波分配与收敛门

在调度器之上,初始化还需落地一组研究运行参数:

  • compute_budget.per_experiment_gpu_hours:仅在 GPU 小时这个核算单位确实适用时填估计值,否则省略或用 0;
  • compute_budget.max_parallel_runs_per_peer:保留为遗留兼容上限,host 级上限以 central 模式为准;
  • generation_policy.cohort_size:让被测瓶颈保持高利用且不越过压力/安全/许可证/服务/仿真器/内存上限的 peer 数;
  • generation_policy.per_generation_hours:足够一个严肃 peer 循环(实现→smoke→评估→发布→drain)的安全上界;
  • generation_policy.max_generations:够数个研究周期,除非用户只要 smoke-only 任务;
  • 任务本地评估器超时与 tier 预期时长:每 tier 的测量/估计运行时间的 2–3 倍,并为卡死的训练/仿真设硬超时。

成熟证据与探索的工作量配比遵循"有界尾部风险冗余"而非"每结果三张 GPU 卡":对 P 个 peer,默认证据目标 Q=max(1, ceil(P*0.25));控制器最多维持 min(P, ceil(3*(Q-M))) 个排队/运行中的成熟计划与成熟优先租约,其中 M 来自规范 effort/coverage 结果。默认值 mature_supply_fraction: 0.25、mature_supply_redundancy: 3.0、mature_assessment_min_completion_probability: 0.25 除非被测量到的任务物理特性证明需要显式覆盖,否则保持。peer 提示词应要求生成早期就提交 --work-class=mature 的完整协议工作,而不是等到评估边界。首波分配让至多 Q 个 peer 开始有依据的直接成熟评估,同时在多 peer cohort 中至少保留一个探索者(其他类用 ordinary/scout)。

正常收敛必须由任务定义的成熟证据门控:只要任务通过比率门、完整阶段、协议完整性契约或成熟父代通道区分收敛级证据,就独立设置 synthesis_trigger.mature_quorum_fraction: 0.25。mature_supply_fraction 只做工作优先级,不能替代这个收敛门。绝不要为了回避死锁把 quorum 设成 0.0——0.0 会让固定/自适应信息密度(包括进度与诊断发现)成为正常收敛条件;安全帽与 cohort 耗尽结果已经在成熟证据不足时提供了有界活性。此外建议准备两个运营商启动档位:smoke profile(小 cohort、短 tier,验证接线)与研究 profile(硬件高效 cohort、完整阶段,正式运行)。

8. 模型与 Agent 运行时默认:DeepSeek V4 Pro + Claude SDK

当主机有 DEEPSEEK_API_KEY 时,除非用户另行指定 provider/model/runtime/agent-system,生成运营商指令、README 启动示例与 assets/resource_plan.md 时推荐如下启动档:

model provider: model_provider:deepseek_alias
model: deepseek-v4-pro
agent runtime: agent_runtime:claude_sdk

理由是该长上下文 DeepSeek 路线在保持 prompt layout 稳定性时成本效益好,适合大型研究运行。DEEPSEEK_API_KEY 未配置时不阻塞初始化,只记录缺失的推荐 key 并保留用户配置的 provider 回退或显式启动覆盖。用户配置永远优先:用户指定 provider/model/runtime/PRAXIST_MODEL_PROVIDER_REF/PRAXIST_MODEL/PRAXIST_AGENT_RUNTIME_REF/PRAXIST_AGENT_SYSTEM 或等价 CLI 标志时,保留该选择并写入 assets/resource_plan.md 与生成的 README。

为 peers、DIG、PIs 与 Chair 生成运行级 agent.reasoning_effort 策略,默认 max(除非用户明确选 auto/off/low/high);auto 显式保持 provider/runtime 行为不变;仅当修复已在使用 premium_mode 的任务时才保留该遗留字段。不把原始 API key 存进任务目录——provider key 属于用户级 PRAXIST 配置或 shell 环境(通常由 runtime-install skill 准备),初始化只记录 DEEPSEEK_API_KEY 这类必需的 key 名。启动示例应为:

praxist start \
  --task-path /path/to/task \
  --model-provider model_provider:deepseek_alias \
  --model deepseek-v4-pro \
  --runtime agent_runtime:claude_sdk

这一命令在 start.py 中实现为"唯一的受支持 detached 启动路径":解析 agent system 及级联默认、做凭据预检、构造 python -m praxist.run run … argv、以 start_new_session=True 派生子进程(等价 nohup setsid)、重定向 stdio 并持久化 RegistryEntry。若用户明确选择 agent_runtime:codex_sdk,则把该 ref 带入启动指令并在 assets/resource_plan.md 记录;验证环境提供 openai-codex==0.147.0、claude-agent-sdk==0.2.136、codex-relay==0.5.5 与 MCP 支持;默认 agent_runtime:claude_sdk 验证 claude-agent-sdk==0.2.136。不要生成任务拥有的 relay 启动器、每 peer relay 端口或运行时传输 helper——PRAXIST 拥有长生命周期本地 app-server 客户端、直接 MCP 挂接与 DeepSeek/OpenRouter 所需的 run-scoped 私有 relay;OpenAI 走直接 SDK 路径。

通过 praxist-takeover-codex 调用本身就是对 agent_runtime:codex_sdk + model_provider:openai_compatible + 已保存 ChatGPT 认证的显式选择:保留该选择,不询问 provider/API key,不用 DeepSeek/Claude 推荐替换,默认用 gpt-5.6-luna;解析或启动前要求 praxist doctor --codex-native --task-path <task> 报告所选模型目录项就绪。

9. 必需的研究循环默认:DIG、QD、建设性 peer 混合与 Gems

除用户明确要求最小 smoke 夹具外,真实研究任务默认启用以下研究循环设置:

  • 初始 DIG:默认仅在绝对第 0 代启用,通过 dig_lite.enabled: true 与 dig_lite.generation_scope: initial_only 实现;除非用户明确要求遗留的全代行为,否则不在后续代启用 DIG。
  • 质量多样性(QD):默认独立启用,quality_diversity.enabled: true,且 initial_generation_enabled: true 与 later_generations_enabled: true 都开。第 0 代对 DIG 候选池应用 QD;后续代关闭 DIG,通过既有 PI 合成路径应用软 QD 引导。定义 evaluation.diversity_dimensions 为任务拥有的轴后,PI/Chair 合约在 planned_dimensions 中声明预期设计,peers 在 design_dimensions 发布已实现/已评估值(这是实现证据,不是计划副本);诊断必须分别比较计划与实现的分布,报告每轴 HHI、样本量、缺失率与计划-执行漂移。维度报告缺失是咨询性证据质量缺口,不阻塞本有效的实验。
  • 建设性 peer 混合:默认由 evaluation.constructive_peer_mix_enabled: true 显式控制,目标 constructive_target_ratio: 0.75;需要不偏向下一代的建设性工作下限时置 false。该开关独立于 dig_lite.innovation.enforce_forward_slots。
  • Gems 重置:新初始化用户任务默认关闭,先走连续演化(gems.enabled: false 或省略 Gems reset 块);初始化期间不猜测重置节奏。若用户明确要求周期性 Gems,或后续诊断检测到显著性能天花板,再启用 Gems reset,并从观测到的平台期起始代或任务所有者的显式选择设置 gems.reset_interval_generations。
  • 前沿通道 / incubator:只定义被测协议与指标空间证明确有必要的 evaluation.frontier_lanes。昂贵、分级、诊断或多轴任务通常应区分严格确认结果、低准入的持久 incubator 与低置信验证候选;廉价单协议单指标任务可用最小"confirmed + durable-promising"结构并依赖 PRAXIST 的紧凑验证候选视图,不要为填模板发明成熟阶段、Pareto 轴或诊断通道。

incubator 是核心的跨代记忆结构而非装饰性排行榜,使用清晰的任务拥有名称(incubator、<task>_incubator、candidate_library)。它对 confirmed 晋升是"低准入",但绝不是低质量或无过滤的垃圾场:默认保留父授权、协议通过、无嫌疑的候选——它们在至少一个重要且不同的评估轴上优秀,或是相对当前 incubator 的 Pareto 前沿/新高点——即使仍需修复、种子升级、消融、证伪或额外验证才能 confirmed 晋升。绝不能把协议意图表标记为不可作父代的模式放进 incubator(scout-only、partial、validation-only、protocol-failed、unscored、late、suspect 证据通常属于 validation-candidate 或 diagnostic 通道)。incubator 多代持续为空而存在完整协议通过变体时,后续 peers 与 PI/Chair 合成可能丢失最佳父代并持续探索无关想法,导致性能停滞。

评估器通道元数据是源路由契约,不是评估器决定最终持久目标:普通 complete、协议通过、无嫌疑的表现证据应同时被严格 confirmed 选择与低准入 incubator 选择考虑时,发出一个共享任务拥有源标签(通常 performance)并把它包含进两个目标通道的 include_lanes;不要把所有父授权结果都盖 confirmed 章(那会让 incubator 不可达并在 confirmed top-k 上限后丢弃强非主 Pareto 父代)。生成的评估器必须在自己的规范结果摘要中拥有该源标签,peers 与 share_finding 引用该摘要,不得凭 Agent 判断把同一结果重新标注为 confirmed/incubator。还要在评估器旁加一个小的任务本地通道路由回归,证明:每个 parent_eligible: true 通道至少有一个可达的、协议通过的、无嫌疑评估器源标签;confirmed 与 incubator 独立消费父授权表现证据时,超过 confirmed.k 个父授权夹具仍可路由;意图表标记不可作父代的模式的夹具无法到达父可授权通道;显式任务拥有 incubator 源标签携带非空 incubator_axis 与 incubator_candidate_reason。新生成任务在配置的持久父代通道不可达时不视为 launch-ready。

10. 标准 task.yaml 字段:一个可复制的现代配置骨架

SKILL 明确:写 ML 项目精确配置前,先看 TASK_TEMPLATE_ROOT/machine_learning_template/task.yaml(源码形式为 templates/tasks/machine_learning_template/task.yaml);只把 template/task.yaml 当最小脚手架/smoke 形态;sam_optimizer/task.yaml 仅作领域参考灵感。当前标准任务本地字段如下(占位符需按测量结果替换):

praxist_plugins:
  tools:
    - tool_server:evaluation_tools
    - tool_server:frontier_tools
    - tool_server:finding_graph_query
    - tool_server:memory_tools
    - tool_server:prior_work_tools
    - tool_server:run_report
    - tool_server:literature_lookup

evaluation:
  maturity_policy:
    min_effort_ratio: 0.75
    min_coverage_ratio: 0.80
    require_ratio_gate: true
    # Include labels only when this task actually uses staged evaluation.
    complete_stage_labels: [complete]
    # Omit this field when the task has no early stages.
    preliminary_stage_labels: [preliminary, aligned]
  constructive_peer_mix_enabled: true
  constructive_target_ratio: 0.75
  launch_guard:
    enabled: true
    # Calibrate from observed p90 runtimes. Close-grade is the task-authorized
    # evaluator that can satisfy normal close.
    estimated_heavy_eval_minutes: <estimate_from_resource_plan>
    estimated_close_grade_eval_minutes: <close_grade_p90_from_resource_plan>
    safety_factor: 1.25
  frontier_lanes:
    - name: confirmed
      description: "Fully scored, promotable candidates on the task primary metric."
      k: 3
      cumulative_cap: 10
      axes:
        - {name: <primary_metric>, direction: maximize}
      # Default only: the evaluator emits `performance` for ordinary clean
      # parent-authorized results. Adapt this to the user-owned protocol-intent table,
      # allowing both parent lanes to select independently.
      include_lanes: [confirmed, performance]
      parent_eligible: true
      require_metrics: [<primary_metric>]
      require_truthy_metrics: [scored_complete]
      require_falsey_metrics: [protocol_integrity_failed, suspect_protocol, suspect_leakage]
    - name: incubator
      description: "Lower-admission durable Pareto/new-high retention library for task-authorized, protocol-passed, non-suspect candidates that need follow-up before clean confirmation."
      k: 8
      cumulative_cap: 48
      admit_new_high: true
      axes:
        - {name: <primary_metric>, direction: maximize}
        # Add 2-6 truly distinct task axes here when the evaluator always
        # emits them and they should define Pareto/new-high retention, for
        # example robust lower bound, safety/risk, robustness,
        # compute/cost, constraint success, calibration/generalization, or
        # explanation/simplicity.
      optional_axes:
        # Optional axes are secondary sort/display signals only. Do not place
        # a metric here if missing it would change whether a candidate should
        # be retained on the long-term Pareto/new-high surface.
        - {name: <secondary_tiebreak_metric>, direction: maximize}
        - {name: <diagnostic_display_metric>, direction: minimize}
      include_lanes: [incubator, performance]
      require_metrics: [<primary_metric>]
      require_truthy_metrics: [scored_complete]
      # Remove a stage marker from this default exclusion list only when the
      # user-owned protocol explicitly authorizes that mode as durable evidence.
      require_falsey_metrics: [protocol_integrity_failed, is_smoke_eval, partial, scout_only, validation_only, validation_only_result, late_after_generation_boundary, suspect_protocol, suspect_leakage]
      parent_eligible: true
      allow_non_promotable: true
      allow_missing_tier: true
      allow_risk_violating: true
    - name: task_candidate
      description: "Promising preliminary, aligned, partial, validation, or repair evidence retained for follow-up."
      k: 5
      cumulative_cap: 20
      axes:
        - {name: <primary_metric>, direction: maximize}
      include_lanes: [task_candidate, candidate]
      parent_eligible: false
      allow_lower_tier: true
      allow_non_promotable: true
      allow_missing_tier: true
    - name: diagnostic
      description: "Controls, falsifiers, negative evidence, and process diagnostics."
      k: 2
      cumulative_cap: 10
      axes:
        - {name: <primary_metric>, direction: maximize}
      include_lanes: [diagnostic, control, process, reference, negative_control]
      parent_eligible: false
      allow_lower_tier: true
      allow_non_promotable: true
      allow_missing_tier: true

dig_lite:
  enabled: true
  generation_scope: initial_only
  candidate_count: 8
  min_mechanism_families: 4
  min_intervention_surfaces: 3
  max_attempts: 10
  max_total_runtime_minutes: 40
  fallback_to_direct_on_failure: true
  diversity:
    cell_fields: [mechanism_family, intervention_surface, intent]
    selection: best_within_lane
    reject_near_duplicate: true
    duplicate_threshold: 0.82
  innovation:
    enabled: true
    enforce_forward_slots: true
    max_diagnostic_fraction: 0.20
    max_diagnostic_peers: 2

quality_diversity:
  enabled: true
  initial_generation_enabled: true
  later_generations_enabled: true
  max_same_diversity_cell_peers: 1

synthesis_trigger:
  enabled: true
  min_findings: <derive_from_cohort_size_and_expected_finding_rate>
  min_interval_minutes: <derive_from_implementation_queue_and_first_close_grade_result_time>
  max_interval_minutes: <include_implementation_queue_close_grade_evaluation_publication_and_margin>
  min_contributing_peers: <min(3, cohort_size)>
  mature_quorum_fraction: 0.25  # normal close requires task-defined mature evidence

gems:
  enabled: false  # continuous-evolution default; enable reset after diagnosis or user request
  selection_policy: mature_evidence_top_k
  min_mature_eval_units: <parent_authorized_protocol_required_evaluation_units>
  evidence_stage_min_units:
    <parent_authorized_stage_label>: <parent_authorized_protocol_required_evaluation_units>

对照仓库模板可看到,machine_learning_template/task.yaml 正是这套字段的完整可运行形态:evaluation 定义 maturity_policy、constructive_peer_mix_enabled、launch_guard、staged_protocols(preliminary/aligned/complete 三档)、diversity_dimensions 六轴与四条 frontier_lanes(confirmed/incubator/task_candidate/diagnostic);compute_budget.resource_scheduler.mode: legacy 明确标注"模板不得在观测前发明加速器 profile";dig_lite、quality_diversity、gems.enabled: false、synthesis_trigger.mature_quorum_fraction: 0.25、agent.reasoning_effort: max 与 praxist_plugins.tools 的七个工具服务器全部就位——与 SKILL 的默认一致,且 multi_pi.enabled: true 给出了 Multi-PI 拓扑的默认面板配置。

11. 成熟度比例门:effort_ratio 与 coverage_ratio

当用户批准的成熟度契约使用投入/覆盖率比率时,新生成的任务评估器必须在每个规范机器可读结果摘要中输出 effort_ratio(实际投入相对任务定义参考投入)与 coverage_ratio(已完成必需评估单元相对总必需单元)。PRAXIST 用同一提取器把这些事实投影进自动物化的 finding,任务代码不要重复源拥有的事实;没有规范摘要引用的独立手工结果 finding 必须自行携带比率。只有在契约确实使用比率时才设 require_ratio_gate: true;比率门开启时,即使出现"看起来完整"的标签,缺失比率仍视为 unknown。

启用比率门后,在声明 launch-ready 前必须执行最短的有效打分路径(走评估器真实规范摘要写入器),然后用真实文件验证:

praxist resolve <task_path> --result-summary <summary_path>

对昂贵评估器,确定性契约探针可以在性能声明前停止,但必须调用与真实打分评估相同的序列化路径——手写的仿制 JSON 文件不算证据。require_ratio_gate: true 时预检必须通过有限比率;阶段标签只是可选的任务审计词汇,不能替代缺失的比率。同一预检只在任务拥有策略确实把完成元数据解析为矛盾决定时才拒绝它:配置的终局上限可以是成熟的,提前触达上限是不完整的——验证实际协议与比率,而不是按子串拒绝状态词汇。

12. 评估器扇出预检:启动检查 → 接口验证 → 单单元 canary

在任何 aligned/complete 或昂贵的多单元扇出之前,必须按成本递增顺序证明真实评估器路径:

  1. 在扇出将使用的确切运行时中运行任务适当的构建/加载/启动检查(解释型代码可为编译/import;二进制、库调用、仿真器、容器、notebook 或服务则演练其真实加载/启动边界)——仅源码文本检查不算执行证据;
  2. 在预留昂贵资源前验证评估器真实公共调用契约:有 CLI 就演练其真实 parser/help 路径,否则验证任务实际调用的函数/RPC/仿真器/容器/notebook/服务接口;
  3. 通过同一公共评估器、调度器路径(PRAXIST 拥有启动时)、运行时环境与规范摘要写入器运行单单元 canary——一个单元是任务定义的最小科学有效用例,不暗示通用 seed/epoch/iteration/split/设备模型;无离散单元协议用其最短有效调用;
  4. 验证生成的摘要及其"摘要→finding"投影,之后才扇出。修复过的命令或实现必须通过新的 canary,早先的 canary 不授权更改后的代码。

canary 验证的是接线与发布,不是性能或成熟度。保留有效低分与负面科学结果,只在执行、schema、发布或已声明的协议完整性失败时停止扇出。若任务声明证据来自外部/独立可信评估器,还要证明任务声明的信任边界:peer 不能替换权威结果,验证器必须拒绝被修改或未证明的结果(认证机制任务拥有,不要把签名方案/文件系统属主/数据集划分/服务硬编码进初始化)。

结果摘要可嵌套在 results/**/ 下,使用紧凑名 summary.json、evaluation_summary.json、eval_summary.json、tiered_eval_summary.json 或 custom_*_tiered_eval_summary.json(result_summary.json 仍是受支持兼容名)。每个摘要必须携带稳定顶层 variant_id(或单评估器多候选时的显式子结果 ID),同一候选的重复阶段必须复用该身份。通道、成熟度、effort/coverage 比率、协议与诊断元数据放进结构化顶层、metrics、current_aggregate 或 extra 字段,让物化器能把 frontier_lane、promotion_lane、evidence_stage、evidence_valence、diagnostic_role、failure_mode、parent_candidate、next_step_intent 等字段转进规范 finding。中央调度拥有启动时,每次提交都必须通过 --out-dir/--output-dir/--result-dir 等显式输出选项传入结果专属目录,不能依赖进程 cwd 或把运行级 results/ 根当作某个 peer 的输出;canary 必须确认"摘要→finding"物化保留了调度器的规范代与 peer 归属,并把调度器提供的 generation_id/peer_id 作为结构化交叉核对字段写入摘要。

对要求成熟/完整证据才正常收敛的任务,测量未改动完整评估器足够次数以估计 p90 墙钟时间,并强制如下 launch-readiness 不等式:

estimated_close_grade_eval_minutes * safety_factor
  < effective_generation_close_horizon_minutes - drain_margin_minutes

drain 余量至少 30 分钟(除非实测发布/关停延迟需要更多)。不等式失败时提高相关代与合成上界,或请用户授权不同协议;绝不把不完整 run 重新标注为 complete。

13. 分级评估对齐:preliminary / aligned / complete

当目标任务评估对每次早期尝试都太贵时,默认构建三级任务拥有评估契约(用户也可显式选择更简单或有意不完整的协议)。对昂贵的重复用例、种子、情节、仿真、基准套件或多数据集任务,除非协议意图表另有说明,使用如下默认:

  • Preliminary check(初步检查):最便宜的可行健全性检查,默认可用微型夹具、单划分、单情节、极低投入或仅失败检查。用途是接线验证、不可能想法过滤、失败诊断与定性验证候选。不得用于对变体排名、选择干净父代、Gems reset、成熟前沿晋升、性能天花板检测或"迄今最佳"声明,除非用户拥有协议意图显式授权并在结果中透明报告降级协议。
  • Aligned evaluation(对齐评估):完整评估前唯一可对变体排名/优先化的早期协议。必须与完整协议使用相同的评估器代码路径、主指标方向、聚合语义、无效结果规则、泄漏检查与协议完整性检查。默认保留完整协议的评估单元覆盖(尽量相同的 folds、数据集、任务用例、场景、seed、情节或运行体制),主要通过减少优化预算省算力——epochs、梯度步、rollout horizon、仿真器步数、内环迭代、检查点扫描或重复重启。减少评估单元是最后手段而非默认;若完整覆盖确实不可能,aligned 评估仍须使用近完整、固定、分层覆盖集,保留所有主要体制与困难用例,并记录覆盖率与省略单元理由。覆盖率实质较小或便利采样时,标为 preliminary/partial 而非 aligned。
  • Complete evaluation(完整评估):默认最高证据任务协议。此阶段(或用户拥有意图显式声明等价/足够的任何降级协议)可创建干净实现父代、confirmed 前沿条目或 Gems 父代。

任务可自选字面标签;preliminary/aligned/complete 只是推荐中性默认,既有分级任务可把其既定名称列进 preliminary_stage_labels/complete_stage_labels 保留。标签本身不携带全局的投入、覆盖、顺序或父可授权语义。生成评估器摘要与 findings 必须报告足够字段让人分辨产生结果的协议:extra.evidence_stage、extra.protocol_name/extra.eval_mode、metrics.evaluation_units 或 extra.completed_required_eval_units(及 n_seeds/n_episodes 等任务本地计数)、固定预算字段(epochs、环境步、墙钟上限、仿真 horizon)、覆盖字段(extra.coverage_ratio、extra.complete_protocol_evaluation_units、extra.aligned_evaluation_units)、精确成熟度字段(effort_ratio/coverage_ratio)、metrics.scored_complete、协议完整性标志,以及每个 finding 的结构化负面证据元数据(extra.is_negative 必须显式,extra.evidence_valence 取 positive/neutral/negative/mixed,负面/混合结果附紧凑 extra.failure_mode 与 extra.disconfirming_claim_ids)。

对可改变处理方式的非代码启动设置,还要提供无秘密顶层 effective_config 对象(含全部影响结果的 CLI 参数、环境覆盖、协议选择与任务本地配置值,且是评估器应用默认/解析/别名/类型转换之后的值)加 effective_config_complete;派生工作由评估器/启动 helper 读取选中父摘要、按同一 schema 解析子项,在昂贵执行前报告无秘密 key 级不匹配。任务声明的精确复制使用 replication_of_effective_config_sha256,且仅在 PRAXIST 报告 replication_effective_config_status: matched 时才可用"精确复制"标签。

14. 工件所有权、指标发现与任务目录构建

工件所有权是生成任务的纪律:peers 与任务 harness 通过评估器结果摘要和 share_finding 发布任务证据;PRAXIST 拥有前沿/incubator 状态、Gems 状态、prompt-layout 工件、PI 证据包、研究记忆、诊断表与代边界标记。当前事实来自结果/finding 证据、frontier/frontier_manifest.json、提交的 gems/gems_state.json 与 gen_N/generation_boundary.json。验证候选是非前沿信号(partial、lower-stage、失败但信息量、preliminary、aligned、repair、ablation、diagnostic 及代收敛后被保留的 late-after-boundary 摘要),经结构化 findings/结果摘要路由,不经新 side files。排行榜、PI 证据包、渲染 prompt、prompt-layout 清单、诊断与行为报告都是派生视图或审计快照,生成提示不得让 Agent 手写它们或用它们覆盖评估器证据。

指标发现先从项目本身推导(评估器代码、论文/文档、结果表、基准脚本、日志);缺失或含糊时,用无 key 公共文献/数据库/开放获取查找,否则用 Agent 主机 web 搜索该领域标准基准指标,在 assets/literature/research_directions.md 引用来源并标注为"文献/上下文信号"而非测得任务事实。还要研究领域排名惯例而不只是指标名:单均值、均值+风险权衡、置信区间、下置信界、统计显著性、Pareto 效率、安全/遗憾约束还是多目标支配。领域关心方差/seed 敏感/尾部风险/仿真随机性/置信区间/下界稳健性时,通过任务拥有轴或显式稳健指标(如 primary_metric_lower_confidence_bound、primary_metric_std、seed_robustness_std、risk_metric、constraint_violation_rate)编码进 evaluation.frontier_lanes。记录:主指标与方向;每个比较锚指标的方向(经 anchor_metrics 或通道 axes/optional_axes,绝不假定主指标方向适用于辅助指标);主排名规则;incubator 轴族;辅助指标;约束与无效结果条件;跨评估单元的聚合方式;方差/置信区间/下置信界是否影响前沿排序;preliminary 健全性协议及其权限;aligned 协议及其权限;aligned 的预期覆盖比与更便宜的预算;用户授权为成熟的协议;未来诊断如何分阶段比较而不把廉价 preliminary 检查混入排名统计。

任务目录构建:ML 项目按 TASK_TEMPLATE_ROOT/machine_learning_template 形状创建并适配;非 ML 项目只用 TASK_TEMPLATE_ROOT/template 的文件/目录布局作为最小形状。目标布局:

task.yaml
README.md
description.md
prompt_base.jinja2
prompt_generation.jinja2
prompt_task.jinja2
.gitignore
.praxist/plugins/panel_topologies/<task_topology>/plugin.yaml
roles/
audit_rules/
evaluations/<primary_eval>/run.py
assets/harness/
assets/baselines/
assets/dataset_metadata/
assets/literature/
assets/project_scan/
assets/task_context/
assets/resource_plan.md
assets/regression_fixtures/

task.yaml 引用任务本地面板拓扑(如 panel_topology:<task_topology>)时,生成目录必须包含匹配的 plugin 文件,不能留下指向未复制/未生成 plugin 的悬空 ref。基线代码系统保持紧凑:优先一个公共评估器加少量 harness 文件,只复制/包装训练或拟合、推理或 rollout、模型/控制/策略定义、仿真器或数据接口、指标计算、数据/仿真器路径解析、小型 smoke 夹具所需的最少代码;不复制原始数据集、大检查点、大日志或仿真器安装,改为写指向既有本地路径或必需环境变量的元数据/解析器文件。

15. 基线要求与基线性能记录

基线代码必须在检测到的环境中本地运行,公共 PRAXIST 面向命令应为:

evaluations/<primary_eval>/run.py

该命令至少接受:变体路径/变体目录;输出目录;可选数据/仿真器根;可选 preliminary/complete 模式;昂贵评估时的显式分级协议模式(preliminary、aligned、complete mature,用任务拥有字面标签;aligned 必须调用与 complete 相同的评估器路径与指标聚合语义,保留近完整数据/评估覆盖,优先减少训练/优化预算,无法保留近完整覆盖就标 preliminary/partial);干净完整证据的显式预期预算字段(epochs、梯度步、环境步、rollout horizon、仿真器情节、重启数、seed 数、fold 数、评估单元数或墙钟上限);机器可检查的协议完整性结果——若完整协议是 3 个 epoch 而 run 只完成 2 个,评估器必须设置失败完整性标志、解释不完整预算并避免把结果标记为干净晋升证据。

若提议的最高证据协议投入实质小于项目既定基线/已发布任务惯例/测得收敛证据,而用户未显式决定,先暂停并让用户确认:保留该预算为完整协议(任务小或项目证据已证明);提升到用户提供的完整预算;或降级为 aligned 证据并定义更高投入的完整协议。不施加普适的 epoch/step/rollout/墙钟阈值——门槛是任务证据与声明的 effort/coverage 比率。

基线性能记录放 assets/baselines/:

  • results.jsonl:机器可读基线指标(已知时);
  • curated_baseline_summary.md:人读基线证据;
  • baseline_performance_status.md:说明数值来自既有项目工件还是仍需测量。

这些资产文件是溯源记录而非隐式运行时基线。验证测得值后,在 task.yaml:baselines 声明对应指标名、值与方向;运行 praxist resolve <task_path> 并修复"存在测得的基线资产但 baselines 列表为空"的警告——不要用未验证数字复制进任务契约来静默该警告。若既有项目工件已有可靠基线性能,只复制紧凑测得事实并记录源路径、时间戳、命令与指标定义;若缺失,先判断当前机器是否具备测量条件(基线代码/忠实基线命令存在、公共评估器或基准命令存在、数据/仿真器/检查点/许可证/环境变量齐备、检测环境可执行评估器、预期耗时可接受或可被文档化 smoke/分级协议缩减)。条件不满足时不要发明数字,写清 missing-baseline 状态并报告缺失项。条件满足但无可靠基线记录时,暂停让用户二选一:Zero placeholder(每个基线指标写 0.0 并把状态标 user_selected_zero_placeholder,明示为占位符而非测得证据)或 Measure baseline now(在输出任务目录内创建 experiments/baseline_bench_<timestamp>/ 并写小型基线基准运行器,调用任务公共评估器或文档化基线命令,用与 task.yaml 相同的指标与聚合,保存原始日志加紧凑 summary.json;测量完成后写入 results.jsonl 并在两个 md 中总结溯源)。未经用户选择不得开始基线测量;选择测量且运行长时,先报告预计时长、并发、输出目录与精确脱敏命令再启动。

16. 角色提示词设计

创建注入领域专长又不至于过度约束探索的任务本地角色:

  • roles/peer_generalist/skill.md:实现/评估变体、保留证据、遵循评估协议;
  • roles/starter/skill.md:从任务证据与广泛适用的科学/工程知识构建强可编辑起点系统;
  • roles/solver/skill.md:通过聚焦实现与评估改进任务目标与解质量;
  • roles/analyst/skill.md:测试提案前分析数据、前沿方法、尝试、日志与失败;
  • roles/pi_builder/skill.md:综合有前途机制并提出下轮合约;
  • roles/pi_skeptic/skill.md:发现泄漏、脆弱假设、无效指标、仿真器/数据工件;
  • roles/pi_portfolio/skill.md:跨机制族保护多样性与分配方向;
  • roles/chair/skill.md:把 PI 视图合并成简洁的每 peer 议程;
  • 仅当领域需要时加可选专家角色,如 simulator_specialist、data_validity_reviewer、literature_scout。

对 literature_scout 写任务本地检索策略:首选源、禁用的易泄漏源、筛选标准与先前艺术风险所需的精确输出字段;panel.optional_roles 条目保持禁用除非拓扑实现可选角色执行;tool_server:literature_lookup 默认留在活动 praxist_plugins.tools 列表。角色策略还必须说明:外部检索结果不得在运行期间触发下载、安装、数据集获取、仿真器设置、许可证请求或运行时供给,应转化为当前资源方案或缺失资源笔记。避免过窄的角色定义——角色引导专长与风险检查,不强制单一算法族。

角色提示必须保留 PRAXIST 机器契约词汇:引用 preliminary/aligned/partial/incomplete/repair-only 等验证候选证据作为 parent_candidate 时,其 parent_usage 必须是成熟动作(validate、complete_validation、repair、complete_scored_validation、falsify、compare、ablate、ablate_or_falsify、ablation_followup、audit);preserve/combine/pivot 语言属于 next_step_intent 或理由,不要生成教 parent_usage: preserve/combine/none 且父为非空验证候选的角色提示。

17. 高价值研究方向

写 assets/literature/research_directions.md 并把紧凑版本镜像到 task.yaml: research_direction。先本地项目证据,再用 PRAXIST 科学/文献查找技能或 tool_server:literature_lookup,公共查找无法回答的缺口用有界 web 搜索。包含:8–15 个高价值探索方向;每个方向为何 plausible;预期指标签名;实现表面;风险/泄漏/失败模式;是否可用当前本地数据、仿真器、依赖、硬件与评估器实现(不行就描述如何适配到当前资源,而不是要求新下载/安装);多样性标签(机制族、干预表面、意图、语义族、父系、新颖性轴)。这些方向强烈塑造 PRAXIST 的多样性与性能天花板,倾向跨机制与干预表面的广度。多样性标签由初始代 QD-DIG 与后续 PI 合成 QD 共享,宽到足以探索、具体到足以区分候选机制,又不把单一领域编码进 PRAXIST 本身。

18. 交付前的 35 项强制验证与最终报告

SKILL 收尾列出 35 项"Required Validations"。要点可归并为以下几组:

  • 运行类:评估器 smoke/resolve 模式;praxist resolve(或等价 resolve-only,resolve.py 是 python -m praxist.run run --task-path <path> --resolve-only --local 的便捷包装);praxist doctor --task-path <task>;最短有效打分路径 + --result-summary 验证 + 摘要→finding 往返,确认精确有限 effort_ratio/coverage_ratio 保留;多设备契约夹具的 source_result_effective_config_sha256 三连测试与精确复制 matched 验证。
  • 路径/安全类:task.yaml 路径相对任务项目;数据集/仿真器是元数据引用而非复制的原始资产;无原始 API key 或私有凭据;.gitignore 排除 experiments/、原始数据、日志、检查点、缓存与本地秘密。
  • 配置默认类:真实研究任务默认 dig_lite.enabled: true、dig_lite.generation_scope: initial_only、quality_diversity.enabled: true(两代开关均开)、gems.enabled: false;praxist_plugins.tools 显式列出七个工具服务器;evaluation.maturity_policy/constructive_peer_mix_enabled/constructive_target_ratio/launch_guard 存在;区分收敛级证据时 synthesis_trigger.mature_quorum_fraction 为正且 ceil(cohort_size * fraction) >= 1 物理可达;agent.reasoning_effort: max;默认运行时 claude-agent-sdk==0.2.136。
  • 通道/契约类:frontier_lanes 含成熟结果、持久 incubator、验证候选与诊断/控制通道;运行任务本地通道路由回归并确认每个父可授权通道可达;incubator 不比 confirmed 更严格、多轴是真正不同指标族、空 incubator 的停滞风险写进任务提示;planned_dimensions/design_dimensions 分离;评估器摘要与 findings 携带结构化负面证据与 effective_config。
  • 调度/交接类:central profiles 与并发来自未改动基线观测;调度器/评估器集成预检在真实 peer guard 环境完成 READY/GO、最终评估器与一个后代保留调度器分配 UUID 掩码;CPU profile 无每作业核心预留、GPU 利用率与峰值显存独立检查、未知 GPU 需求独占、生命周期 running 与瞬时资源活动分开报告、无未声明科学等价的加速器回退;托管 NVIDIA/CUDA 后端时 UUID/多设备/缺失掩码恢复/冲突拒绝/独立/CPU 契约测试通过,非零 UUID 父子 CUDA 预检比对计算 PID 与驱动观测 UUID。
  • 收敛/活性类:成熟度债反馈(Q/M/D/A_target 可见,排队/运行成熟语义作业与成熟租约只计一次,每个缺失结果最多三个有界承诺且仅在有物理容量时尝试,达到 Q 收回多余成熟租约不删普通 Pareto 跟进);供给反馈契约(N 个空闲槽至多 N 个定向单实验租约,只唤醒选定生产性空闲 peer,Closing/Stop 后无可用租约);轻量收敛策略生命周期回归(零成熟结果时原始 finding/peer/时间阈值不得产生正常成功的 CLOSING_SIGNAL,低于 quorum 时保留成熟补足,达到配置成熟 peer quorum 才允许正常收敛,安全帽/cohort 耗尽收敛显式记录成熟不足,受保护工作允许 drain)。

完成后以简洁报告收尾,表项包括:研究根、输出任务路径、运行时环境、数据/仿真器、基线代码、基线性能、指标(主+辅)、角色文件、研究方向(数量+来源)、资源计划(瓶颈+cohort+每代小时)、收敛策略(成熟 quorum+所需 peer 数+生命周期回归结果)、加速器交接、PRAXIST 模型/运行时、前沿通道、DIG/QD、Gems reset、验证命令与结果、阻塞项(精确下一步动作)。除非用户明确要求,不要启动长 PRAXIST 运行。

19. 从初始化到启动:完整的价值链

总结整条链路:project_inventory.py 建立项目事实 → 观测未改动基线建立资源事实 → 协议意图表建立科学事实 → task.yaml 把这些事实编码为可执行契约(成熟度、前沿通道、收敛门、调度 profiles)→ 评估器 canary/比率门/通道回归/调度预检证明契约可执行 → praxist resolve/praxist doctor 做最终校验 → praxist start --task-path ... 进入正式研究循环。

从源码结构看,这条链路在仓库中有完整闭环支撑:task_project.py 负责 resolve_task_project 与 build_task_project_manifest 的任务工程解析与清单构建;start.py 是规范注册表式启动器;protected_pids.py 与 experiment_scheduler.py 实现受保护进程与中央调度;machine_learning_template/task.yaml 是这套默认的"可运行最小全集"。进一步参考可阅读 docs/guides/central-resource-scheduler.md、docs/guides/task-projects.md、docs/guides/deep-innovation-gate.md、docs/guides/qdig-cohort-allocator.md 与 docs/getting-started/first-task.md。

一句话总结:PRAXIST 任务初始化的本质,是把"可运行"这一最低事实,升级为"可测量、可排名、可收敛、可溯源"的完整研究契约——而这条升级路径的每一步都要求用测量与用户授权说话,而不是用模板、猜测或营销词汇填空。

  • 人工智能
  • AI Agent
  • 多智能体
  • Agent 工作流
  • 深度研究
  • AI 评测

【免费下载链接】PRAXIST

Autonomous research system for measurable, computer-executable research.

项目地址: https://gitcode.com/gh_mirrors/pr/PRAXIST
点击查看 免费下载

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值