Praxist 交互式任务初始化：基于确认优先（Confirmation-First）的五轮人机协作工作流

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

导读

praxist-interactive-task-init是 PRAXIST 为"需要显式人工确认"的任务初始化场景提供的一层薄交互封装：它不定义新的任务格式，而是把完整任务初始化契约包装成"先提案、后确认、再落盘"的对话流程，让用户在写入任何文件之前先对研究目标、约束、指标、排名规则、评估协议、计算预算、基线处理与启动就绪性逐项拍板。读完本文，你将掌握这套技能的五轮确认机制、每一轮必须确认的决策面、它与底层praxist-task-initialization技能的边界划分，以及确认完成后如何用praxist resolve等命令验证任务 harness 并进入启动流程。

技能定位：任务初始化的薄交互层，不是新任务格式

skills/praxist-interactive-task-init/SKILL.md在开头就界定了自身边界：Use this skill when task initialization needs explicit user confirmation. It is a thin interactive layer overpraxist-task-initialization, not a separate task format.

这意味着使用该技能时必须遵守以下继承契约：

• 实际的 task-project 创建步骤仍由 skills/praxist-task-initialization/SKILL.md 完成；本技能只负责在决策确认后把结果注入常规初始化工作流。
• 默认保留agent_runtime:claude_sdk运行时，除非用户批准切换为其他运行时。
• 如果用户选择agent_runtime:codex_sdk，需要套用该技能中的 SDK/MCP/relay 就绪性与任务边界规则；不得把承载本次对话的交互式 Agent CLI 当作对等 peer runtime。
• 运行时版本钉（runtime pins）必须继承并保持：claude-agent-sdk==0.2.136、openai-codex==0.147.0、codex-relay==0.5.5。这些版本在 skills/praxist-takeover/SKILL.md 的启动检查中同样被逐项校验。

交互技能在docs/reference/skills.md的技能索引中登记为“Build a Praxist task project through a confirmation-first interactive agent workflow”，并在 docs/getting-started/first-task.md 中被推荐为“无需启动、只想确认式设计 harness”时的入口；它与praxist-task-initialization（创建/修复 harness，不启动）、praxist-takeover（一条龙到启动）形成三档选择。

运行时与上下文效率的策略归属

交互层明确要求：Provider-specific context efficiency 是运行时所有物（runtime-owned）。当用户选择 Codex-native 模式或 OpenRouter 时，要主动解释 Praxist 会自动合并"仅含 finding 的延续唤醒"（finding-only continuation wakeups），且不删除、不压缩 canonical evidence；不得在任务里提议 task-local cache、memory-store 或 session-batching 字段。直接 DeepSeek 运行保持其既有行为不变。

从源码看，这一策略在 praxist/cli/start.py 的模块 docstring 中有对应说明：codex_sdk运行时对于非 OpenAI provider 会自行启动私有 run/provider 作用域的codex-relaysidecar，praxist start本身不启动 relay——交互层不应生成任务自有的 relay launcher、per-peer relay 端口或运行时传输辅助器。

推理强度（reasoning effort）的继承规则

交互层继承完整 task-init 契约中的推理强度策略：默认提案agent.reasoning_effort: max；仅当用户把推理深度、延迟或成本作为约束提出时才请求确认，并保留任何显式的off、low、high、max回答。

源码佐证位于 praxist/core/runtimes.py：REASONING_EFFORT_POLICIES = frozenset({"auto", "off", "low", "high", "max"})，effective_reasoning_effort()会把不在该集合内的取值归一化为max，并把旧的premium_mode兼容别名映射到max（当新策略缺失或为auto时）。也就是说，交互层确认到的显式取值会直接成为运行时的策略来源。

交互原则：先确认，后输入

技能给出的核心交互原则只有三步：

1. 检视项目，提出一个具体的 harness 决策提案（Inspect the project and propose a concrete harness decision）。
2. 询问用户接受还是修正（Ask the user whether to accept or correct it）。
3. 把被接受的决策应用到常规任务初始化工作流（Apply accepted decisions to the normal task-initialization workflow）。

与之配套的是两条交互纪律：

• 保持对话简短：默认最多5 轮确认（at most 5 confirmation rounds）。
• 限制依据：工作记忆的实证研究通常接近 3–4 个组块（chunks），选择过载（choice overload）会损害决策质量，因此采用渐进式披露（progressive disclosure）——把相关决策归并到同一轮，把罕见边缘情况推迟到需要时才展开。

强制前置横幅

在开始任何扫描或提案之前，技能要求先醒目展示前置条件横幅（Opening Banner），原文如下：

**IMPORTANT PRECONDITION** Praxist task initialization assumes the research project already runs on this machine with all required code, data/simulator assets, runtime/container, and credentials available. If the project cannot run locally, this skill must stop and ask for the missing path or environment.

这与底层技能 skills/praxist-task-initialization/SKILL.md 的 Mandatory Opening Banner 一脉相承：任务初始化假设 (1) 源码齐备、(2) 项目已在本机环境/容器中可运行、(3) 数据集/模拟器/基准夹具可达。任一条件为假，就必须停下并询问缺失路径，而不是生成一个脆弱的任务。

五轮确认流程详解

五轮确认是本文档的骨架，每轮聚焦一个决策面。下面按轮次展开，并补充各决策项在任务配置文件（参考 templates/tasks/machine_learning_template/task.yaml）与 Praxist 核心实现中的落点。

Round 1：项目范围与本地资产

• 提案研究项目根目录与输出任务路径。
• 汇总可用的代码、数据、模拟器、运行时与既往结果。
• 请用户确认或修正缺失/有歧义的资产。

底层技能提供了一条可执行清单工具来支撑该轮：skills/praxist-task-initialization/scripts/project_inventory.py，典型调用为：

python skills/praxist-task-initialization/scripts/project_inventory.py \ --root /path/to/research-project \ --out /path/to/output-task/assets/project_scan

该脚本（skills/praxist-task-initialization/scripts/project_inventory.py）会按docs/pdfs/reports/images/code/environment_files/data_candidates/result_log_candidates/simulator_candidates分类统计、抽取 metric 线索与命令线索，输出inventory.json和inventory_summary.md两份产物，供交互层与用户确认项目全景。它默认跳过.git、.venv、node_modules等目录，文件上限 20000、文本片段上限 300、单文件读取上限 65536 字节——本身就是一个“有界、只读”的项目盘点器。

Round 2：研究目标、约束与允许干预面

• 提案任务目标、硬约束、允许修改的代码面、无效结果条件。
• 确认 Praxist peers 可以改动什么、必须保持什么固定。
• 提案哪些 evaluator 模式可以启动、哪些可以参与排名/算作成熟/成为持久父代/满足关闭。

关键原则：用户的回答是权威的（The user's answer is authoritative）；不要假设每个任务都必须使用 full-only 协议。这与底层技能中"No Praxist-wide full-protocol-only rule"的立场一致——用户显式选择 partial、reduced-coverage、scout、diagnostic 等不完整协议时，必须保留该选择、在结果中暴露真实的 effort/coverage 与 stage，并让所有下游策略与之对齐；只有**未声明的漂移（undeclared drift）**才是协议完整性失败。

Round 3：指标、排名与鲁棒性

该轮决策面最多，核心内容包括：

• 提案主指标、方向、辅助指标、基线定义，以及任务合理的最小 frontier-lane 结构。
• 对 staged/diagnostic/multi-axis 评估，提案严格 confirmed 车道、低准入的持久 incubator 车道、低置信 task-candidate 车道与 diagnostic/control 车道；对廉价单协议任务，不得凭空发明不支持的车道或成熟阶段。
• 优先使用项目证据；有歧义时执行有界、免密钥的 web/literature 检索确定领域排名惯例。
• 显式询问：方差、种子敏感性、置信区间、下置信界、安全/regret 约束或 Pareto 前沿是否应影响排名；若为是，在任务中编码鲁棒指标或 Pareto 轴。
• 当任务需要独立持久的 promising-candidate 车道时，确认incubator 策略：它应是低准入的长期变体库，而非高标准的 confirmed 前沿。推荐默认下，它保留 parent 授权、协议通过、非可疑的 Pareto/new-high 候选，供后续修复、验证、升级、消融或证伪；并确认 incubator 车道设置admit_new_high: true。
• 确认 canonical evaluatorsource labels如何路由到目标车道：当 confirmed 与 incubator 都需要普通 clean parent 授权证据时，提案一个共享的任务自有 source label（通常为performance），而不是强迫用户把每个 parent 授权结果都归类为最终目标车道。启动前完整 task-init 工作流必须生成并通过 lane-routing 回归。

源码佐证这些配置的真实语义：在 praxist/plugins/workflow_stages/research_loop/backend/frontier.py 中，include_lanes被规范化为 token 集合，且车道名不在集合内即被排除；第 2015 行与 4039 行则分别处理admit_new_high的准入语义与require_new_high约束——这印证了“incubator 只保留相对当前 Pareto 面真正改善的候选，而非重放旧点”的行为。

Round 4：评估协议与计算预算

该轮是全文信息密度最高的一轮，可拆解为以下决策簇：

协议意图与阶段决策

• 首先复述已确认的 protocol-intent 表。若用户有意选择 partial/scout/reduced-coverage 等不完整证据用于排名或成熟用途，则保留它并要求透明的 stage 与 effort/coverage 元数据——只有未声明漂移才无效。
• 仅当目标协议昂贵时，才为“用户尚未决定的细节”引入 staged evaluation：任务自有 preliminary、aligned、complete 三种成熟模式；协议廉价时通常只提一个 complete 模式。用户已显式选定缩减协议时，不得再新增或重提 full 模式。字面标签不带全局语义（literal labels carry no global semantics）。
• 存在 aligned 评估时，尽量保持接近完整的数据/评估覆盖，主要通过减少训练/优化步数来节省算力。
• 若成熟定义使用 effort/coverage 比值，确认 canonical evaluator summary 输出精确的effort_ratio与coverage_ratio字段，并确认evaluation.maturity_policy中使用的阈值；仅在该选择下使用require_ratio_gate: true；否则保留用户的显式标签/标志或信息密度语义。仅当存在 staged 协议时才列出任务自有标签用于审计与显式回退。
• 启动前运行通过真实 summary writer 的最短有效打分路径，并用praxist resolve <task_path> --result-summary <summary_path>校验其输出。缺失必需比值时必须修复 evaluator 或获得用户批准的 gate 禁用，不得发明 stage 标签。

praxist resolve --result-summary的底层实现位于 praxist/cli/resolve.py：它会读取真实 summary JSON、用normalized_result_summary规范化、再通过missing_required_ratio_telemetry对照任务的evaluation.maturity_policy检查缺失的比值字段，缺则直接报错——因此交互层要求的“真实 writer 输出 + resolve 校验”是一条可机器验证的硬通道。

车道与成熟度约束

• 对每个配置的车道确认：成熟 parent 车道parent_eligible: true，低级/诊断车道parent_eligible: false；allow_lower_tier: true的车道不得成为持久实现父代车道。
• 启用 Gems 时确认其配置使用selection_policy: mature_evidence_top_k，并从授权用于 Gems 与 parent 的协议（通常为 complete 协议）推导min_mature_eval_units；分级累计需求用evidence_stage_min_units以任务自有标签与评估单元数定义；不生成仅兼容性的历史成熟字段。
• 确认紧凑 summary 以results/**/递归写入，文件名限于summary.json、evaluation_summary.json、eval_summary.json、tiered_eval_summary.json或custom_*_tiered_eval_summary.json（result_summary.json为兼容名）；跨阶段复用稳定的顶层候选身份（或显式 child-result ID），并携带结构化 lane/maturity/protocol/diagnostic 元数据供物化。

源码侧，praxist/plugins/workflow_stages/research_loop/backend/findings_collection.py 的_RESULT_SUMMARY_NAMES元组正是这套递归发现的受支持文件名集合；custom_*_tiered_eval_summary.json的按前缀识别逻辑见同文件 1525 行。

执行契约与关闭边界

• 确认 evaluator 执行优先走同步公共入口；若显式支持后台评估，使用 Praxist submission facade 与文档化的任务自有进度/结果契约。绝不用 runtime 私有tasks/<task-id>.output转写的字节大小作为完成标志——成功命令可能不输出任何文本，完成状态由 runtime 通知/退出码所有。
• 确认evaluation.constructive_peer_mix_enabled与evaluation.constructive_target_ratio、evaluation.launch_guard.estimated_heavy_eval_minutes、单独的estimated_close_grade_eval_minutes，以及区分成熟/完整证据与 preliminary/partial/diagnostic/progress finding 时synthesis_trigger.mature_quorum_fraction是否为正。解释0.0会让原始信息密度成为常态关闭条件——只有用户显式确认任务没有独立的 close-grade 证据契约时才提案它。

源码佐证：constructive_target_ratio的默认值在 praxist/plugins/workflow_stages/research_loop/backend/generation_boundary.py 被读取（默认 0.75）；mature_quorum_fraction在 praxist/plugins/workflow_stages/research_loop/backend/synthesis_trigger.py 中被解析并用于计算ceil(cohort_size * mature_quorum_fraction)的成熟配额。任务模板中这两项的标准取值可见 templates/tasks/machine_learning_template/task.yaml 与底层技能给出的synthesis_trigger.mature_quorum_fraction: 0.25默认值。

• 关闭需要成熟/完整证据时，展示实测 complete evaluator p90、安全因子、最早有效关闭视界与 drain margin，并要求estimated_close_grade_eval_minutes * safety_factor < effective close horizon - drain margin通过后才批准。不等式不满足时，提案更长的边界或用户授权的协议变更，而不是静默削弱证据。
• 确认内部 evaluator/trainer/config 路径为任务根相对、故意保留的外部绝对路径存在、公共 evaluator 在任务根与类似 run 的子目录下用声明的任务解释器得到一致解析，且不依赖 runner 自有的 Python import 路径。
• 确认 absolute-gen0-only DIG、独立的首代/后续quality_diversity开关、独立的dig_lite.innovation.enforce_forward_slots选择。向用户解释后续 QD 是既有单 PI/Multi-PI 综合路径内的软引导，不再运行 DIG。若用户改变 cohort 大小，需复核这些软混合选择。
• 确认任务 prompt 显式陈述关闭边界：CLOSING_SIGNAL之后既有训练/评估工作自然排空，peer 只能检视结果、发布 finding、更新 notebook/memory，不得再启动 evaluator、脚本、shell launcher 或后台进程。
• 若提案的 complete 协议显著低于项目既有参考 effort 或实测收敛证据，且用户尚未决定，暂停询问：保留、增强还是降级为 aligned 证据。不强加通用 epoch/step/rollout/墙钟阈值，也不重新争论用户的显式选择。

硬件瓶颈与调度

• 估算硬件瓶颈，提案 peers 数量、generation 数与时长、evaluator 并发与基线测量处理方式。
• 展示用于资源观察的未改动基线命令。当 Praxist 能拥有并观察本地进程启动时，提案 central scheduler 命名 profile、初始/最大主机级并发与实测压力。CUDA/NVIDIA/UUID 检查仅在检测并选择了兼容托管后端时适用；CPU-only、统一内存、任务托管及其他加速器后端都是正常路径。否则提案有界的文档化外部/遗留 owner，而非强制 central 模式。绝不提案合成的 CPU-vs-accelerator 重写或 per-experiment CPU 核预留。
• 确认公共 evaluator 的默认 profile、天然独立的 seeds/folds/scenarios 或其他任务自有评估单元、各层并发归属、声明多设备 profile 是否真的使用每台被分配设备。确认定向空闲资源供给反馈（默认 600 秒有界响应窗口，限制提交时序而非已受理工作的运行时长）。提案默认成熟供给目标Q=ceil(peers*0.25)与有界3D在途冗余，同时保留探索首波；有成熟区分的任务保持硬关闭 quorum 独立为正。
• 若实测 generation 可行性不足，提案更长 generation、不同并发或用户批准的证据协议；不为了规避死锁把原始 finding 当作正常成功关闭。

Round 5：最终 harness 与启动就绪

• 展示最终任务路径、基线状态、evaluator 命令、provider/runtime 建议、absolute-gen0 DIG 状态、首代/后续 QD 状态、continuous-evolution/Gems 策略与报告生成设置。
• 请求批准写入/更新任务目录。除非用户单独要求，或本技能正被praxist-takeover使用，否则不得启动运行。

执行规则：五条不可逾越的红线

技能在确认流程之外列出执行规则：

• 决策确认后，使用praxist-task-initialization执行实际的 task-project 创建步骤。
• 缺失必需代码、数据/模拟器、运行时依赖或可执行基线/评估路径时中止（Abort on missing…）。
• 不在任务目录中存储原始 API key。
• 不编辑 Praxist core 或 guard 代码。
• 不在 Praxist 插件中创建任务专属 hack。
• 未经用户批准不启动长基线测量。

其中"不存储原始 API key"与底层技能一致：provider key 属于用户级 Praxist 配置或 shell 环境，通常由praxist-runtime-install技能准备；任务初始化里只记录所需 key 名称（如DEEPSEEK_API_KEY）。praxist/cli/_env.py 的PROVIDER_KEY_MAP列出了 Praxist 认可的各 provider/tool 凭据环境变量，可作为"按名检查、绝不打印值"的参考面。

最终输出：一份结构化的确认报告

确认与落盘完成后，技能要求报告以下内容（即 Final Output 清单）：

• 已确认的决策与任何用户修正；
• 任务目录路径；
• 基线状态：existing / measured / zero placeholder / blocked；
• 指标/排名规则（含鲁棒性处理）；
• incubator 策略与用于 Pareto/new-high 保留的不同指标族；
• evaluator source-lane 契约与 lane-routing 回归结果；
• 任务自有评估阶段、成熟度比值字段与预期预算/完整性字段；
• 用户批准的启动/排名/成熟/父代/关闭协议意图；
• 选定的成熟度策略、constructive target、launch guard 与 mature quorum 设置；
• 选定的 Praxist 运行参数与启动建议；
• 选定的 provider/runtime，以及 runtime 所有无损上下文效率的预期（Codex-native 模式/OpenRouter）、不变（直接 DeepSeek）或由操作者显式禁用；
• 已执行的验证命令与结果；
• 剩余问题（如有）。

这套输出结构恰好覆盖 skills/praxist-control/SKILL.md 启动前需要的全部事实：任务目录门（task.yaml 存在、可解析、workflow_stage:research_loop、praxist resolve通过）、运行时门（按名检查DEEPSEEK_API_KEY/OPENROUTER_API_KEY等、codex_sdk 需openai-codex==0.147.0与claude-agent-sdk==0.2.136、DeepSeek/OpenRouter 需codex-relay==0.5.5）、以及praxist doctor --codex-native --task-path <task>等就绪门。

从确认到启动：与 takeover/control 的协同路径

交互式初始化完成后，启动路径有两种选择：

1. 走 takeover 一键流：praxist-takeover在用户要求"确认式交互"或"任务目标/约束有歧义"时，会调用praxist-interactive-task-init，但交互路径的任务构建与最终验证仍须委托给当前 task-init 工作流（见 skills/praxist-takeover/SKILL.md 的步骤 4）。
2. 走 control 常规启动：先验证再启动：

praxist resolve /path/to/task praxist start --task-path /path/to/task --daemonize --json praxist status --json praxist --monitor --run-id <run_id>

其中praxist resolve（praxist/cli/resolve.py）是"不发起任何 LLM 调用"的插件清单解析冒烟测试，等价于python -m praxist.run run --task-path <path> --resolve-only --local；praxist start则是唯一受支持的分离式启动路径，负责凭据预检、构建 run argv、以start_new_session=True派生子进程并持久化 registry 条目（praxist/cli/start.py）。

需要特别强调的启动纪律：未经用户单独请求，交互式初始化本身绝不启动运行；只有 takeover 语境下才可以在完成全部门禁后进入启动。此外，若交互层最终报告中的任务使用require_ratio_gate: true，启动前还必须让praxist resolve <task_path> --result-summary <summary_path>通过——summary 必须来自 evaluator 真实 writer 的产物，手写 lookalike JSON 不构成证明。

常见误区与设计要点小结

• 标签≠语义：complete_stage_labels指"任务声明的成熟标签"而非"全局全协议标签"；scored_complete表示结果满足任务声明的可比证据契约，但不抹掉缩减模式的真实元数据。validate 时校验结构化 evaluator mode 与输出元数据，不要因为 argv/路径/源码里含smoke、scout、partial字样就拒绝启动。
• 不要制造哑车道：若 confirmed 与 incubator 都想消费普通 parent 授权性能证据，就采用共享performancesource label 并让两条车道的include_lanes都包含它；把每个 parent 授权结果都盖confirmed章会让 incubator 变成不可达的哑车道（dead lane）。
• 0.0是语义选择，不是救火工具：mature_quorum_fraction: 0.0让原始信息密度成为常态关闭条件；若任务区分 close-grade 证据，就不能用它规避死锁——safety-cap 与 cohort-drained 关闭已提供有界活性。
• 五轮是上限而非模板：相关决策归并、罕见边缘延迟披露；廉价单协议任务不得发明 staged 车道或成熟阶段。整个流程的产出质量底线是：每个配置的parent_eligible: true车道都必须可到达——不可到达即未启动就绪，须回炉修复 evaluator 输出与车道include_lanes后重跑回归，而不是删车道凑验证。

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