OmX 0.14.0 交互编排重构指南omx question 统一提问面、Deep-Interview 问题义务与 Autoresearch 校验门控【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex0.14.0是 OmXOh My codeX在0.13.2之后的一次 minor 版本发布核心是把“交互式编排”收敛为一条受控主链路omx question成为 OMX 自有的阻塞式提问入口deep-interview 改用结构化问题义务question obligation推进autoresearch 转向 skill-first 且以 validator 证据作为完成条件同时引入 advisory triage 路由与统一的 runtime run outcome 语义。阅读本文后你将掌握omx question的完整 CLI 契约与输入 Schema、deep-interview 义务状态机的 create/satisfy/clear 流转、autoresearch 硬弃用后的迁移路径与两种校验模式以及 Stop 门控、运行结果归一化与发布门禁的底层实现。版本定位一次聚焦交互编排的 minor 发布根据 release-notes-0.14.0.md0.14.0的核心变化可以用一条主线概括把原来散落各处的“向用户提问”收敛到 OMX 自己掌控的入口。具体落到五个面omx question成为交互提问面Agent 触发的用户提问走结构化 OMX 入口包含 JSON 输入、UI 渲染、持久化 question 状态与结构化答案Deep-interview 交互显式化、可强制每一轮面试不再依赖纯文本兜底而是创建/满足一个问题义务question obligationAutoresearch 更严格、更安全直接omx autoresearch硬弃用hard-deprecated完成条件从“尽力而为的进度”改为必须存在 validator 证据Prompt 路由增加轻量 advisory 通道PASS/LIGHT/HEAVY 三档分诊提示可以在不隐式激活工作流的前提下引导非关键词提示词发布校验在 dev 工作区可复现lint 只针对被跟踪的源码根避免 runtime/worktree 目录下的嵌套本地 Biome 根破坏发布门禁。对应的发布就绪证据记录在 docs/qa/release-readiness-0.14.0.md结论为GO验证基准为v0.13.2..origin/dev。omx questionOMX 自有的阻塞式提问入口0.14.0 之前Agent 需要提问时往往走临时文本或 ad-hoc 提示现在统一收敛到omx question这一条受控路径。入口实现在 src/cli/question.ts其帮助文本QUESTION_HELP定义了完整契约。CLI 用法与参数omx question --input json [--json] omx question --ui --state-path absolute-or-relative-record-path常用参数参数作用--input json/--inputjson携带 question/options 结构的 JSON 对象命令会阻塞直到用户作答完毕--answer-question-id id针对已知 question id 提交一个受限答案载荷--answer jsonJSON 答案对象或{answers:[...]}载荷配合--answer-question-id使用--session-id id提交答案时的可选会话作用域--json机器调用时在 stdout 输出紧凑 JSON--ui内部渲染模式为已存在的 state record 渲染 OMX 提问 UI--state-path path--ui模式使用的 question record 路径--help/-h显示帮助参数解析在 src/cli/question.ts 中实现支持--input、--answer、--session-id、--state-path等号形式与空格形式两种写法未知参数直接抛错。一个值得注意的环境变量是OMX_QUESTION_WAIT_TIMEOUT_MS默认等待超时为 30 分钟DEFAULT_QUESTION_WAIT_TIMEOUT_MS 30 * 60 * 1000可通过该变量覆盖解析逻辑见同文件parseQuestionWaitTimeoutMs。输入 Schema--input 的 JSON 结构来自QUESTION_HELP的完整输入结构如下{ header: Optional short heading, question: What should OMX do next?, questions: [ {id:next-step,question:What should OMX do next?,options:[{label:Proceed,value:proceed}],allow_other:false} ], options: [ {label: Proceed, value: proceed, description: Continue}, {label: Revise, value: revise} ], allow_other: true, other_label: Other, type: single-answerable, multi_select: false, source: deep-interview, session_id: optional-session-id }规则要点源码见 src/question/types.ts 的normalizeQuestionInput/normalizeQuestionItemtype只接受single-answerable与multi-answerable历史字段multi_select仍然兼容二者冲突如typesingle-answerable却multi_selecttrue会直接抛错只有当allow_other为 true 时options才允许为[]纯自由文本提示选项可以是字符串label/value 相同或{label, value, description}对象value缺省时回退为labeldescription可选questions数组内每个 item 的id缺省按q-index1生成且 id 必须唯一顶层header会继承给第一个问题单题场景支持简化的旧式平铺结构顶层question/options归一化后同样转换为内部questions数组。运行流程策略 → 记录 → 渲染 → 等待终态questionCommand的完整链路src/cli/question.ts依次是策略评估evaluateQuestionPolicy决定当前会话是否允许提问义务接入若source deep-interview读取或创建对应的 deep-interview question obligation并尝试 claim autopilot wait创建记录createQuestionRecord写入持久化的 QuestionRecordkind: omx.question/v1并发出question-created事件渲染与等待launchQuestionRenderer启动渲染器markQuestionPrompting置为prompting随后waitForQuestionTerminalState轮询等待终态收尾成功时追加question-answered事件并满足义务失败/超时/中止时写入 terminal error 并清空义务退出码置 1。机器调用者应使用--json读取 stdout。成功载荷包含主批字段questions与answers单题调用还会附带过渡性投影prompt与answer。正常返回示例{ ok: true, question_id: question-2026-04-19T..., session_id: optional-session-id, questions: [ {id: next-step, question: What should OMX do next?, options: [{label: Proceed, value: proceed}], allow_other: false, other_label: Other, multi_select: false, type: single-answerable} ], answers: [ {question_id: next-step, index: 0, answer: {kind: option, value: proceed, selected_labels: [Proceed], selected_values: [proceed]}} ] }提问策略门控谁可以提问提问不是无条件的。src/question/policy.ts 的evaluateQuestionPolicy定义了三条硬性限制worker_blocked环境变量OMX_TEAM_WORKER非空即 OMX team worker 上下文时直接拒绝——只有非 team leader 会话可以提问team_blocked当前会话拥有激活的 team 模式时拒绝返回激活团队列表与 phaseactive_execution_mode_blocked当前激活的工作流模式或 skill 命中BLOCKED_EXECUTION_SKILLSautopilot、autoresearch、team、ralph、ultrawork、ultraqa时拒绝唯一例外是source deep-interview且阻塞项仅为 autopilot且canStartAutopilotDeepInterviewQuestion允许时放行。渲染器与持久化状态渲染器在 src/question/renderer.ts 中按环境选择策略inside-tmux、detached-tmux、inline-tty、windows-console、windows-psmux-shell-pane、test-noop、unsupportedTTY 环境下走inline-tty直接渲染 UIrunQuestionUitmux 环境则支持通过OMX_QUESTION_RETURN_PANE/OMX_LEADER_PANE_ID指定返回 pane回答后通过tmux-send-keys回注答案。QuestionRecord 的状态机定义在 src/question/types.tspending → prompting → answered / aborted / error / superseded。写入与校验在 src/question/state.ts记录按questions/question_id.json落盘会话作用域为sessions/session_id/写入采用原子写提交答案走 submit lock10 秒获取超时、30 秒陈旧锁回收防止并发重复作答答案必须与问题 Schema 严格匹配kindoption/other/multi、selected_values、selected_labels、other_text都要校验越界选项只有在allow_other且恰为other_text时才被接受。Deep-Interview结构化问题义务create/satisfy/clear0.14.0 把 deep-interview 的每一轮交互从“普通文本兜底”升级为可强制的问题义务。状态定义在 src/question/deep-interview.tsinterface DeepInterviewQuestionEnforcementState { obligation_id: string; // 形如 deep-interview-question-iso-rand source: omx-question; status: pending | satisfied | cleared; lifecycle_outcome: askuserQuestion; requested_at: string; question_id?: string; satisfied_at?: string; cleared_at?: string; clear_reason?: handoff | abort | error; }义务流转分为三态createcreateDeepInterviewQuestionObligation生成pending义务同时把 deep-interview state 中的lifecycle_outcome置为askuserQuestion、run_outcome置为blocked_on_user、active置为 false——表示执行被“用户提问”阻塞satisfysatisfyDeepInterviewQuestionObligation在收到answered记录后置为satisfied记录question_id与satisfied_atreconcileDeepInterviewQuestionEnforcementFromAnsweredRecords还会扫描已有 answer 记录自动对账保证即便提交流程中断义务也能被已存在的已回答记录满足clearclearDeepInterviewQuestionObligation在 handoff/abort/error 场景下清空义务仅允许从pending状态清空。义务与 autopilot 的等待声明wait claim联动runDeepInterviewQuestion在发起提问前先claimAutopilotDeepInterviewQuestionWaiting若已有未决 wait claim 则抛出active_execution_mode_blocked结束后通过resolveAutopilotDeepInterviewQuestionWaiting以 satisfied/cleared 收尾见 src/question/autopilot-wait.ts。Stop 门控未完成义务不允许 Stop这套机制最直接的落点就是 Stop 阻塞。src/scripts/codex-native-hook.ts 在 Stop 钩子中检查若 deep-interview 仍 active 且存在pending的 question obligation返回decision: blockstopReason: deep_interview_question_required提示“useomx questionbefore stopping”并要求读取返回的answers[]JSON 后再继续同理autoresearch 未完成 validator 证据时见 src/scripts/codex-native-hook.tsStop 会以stopReason: autoresearch_phase阻塞系统消息为 “continue until validator evidence is complete before stopping”。这就是 release notes 中 “Stop gating now respects pending interactive question obligations and incomplete autoresearch validation” 的源码级对应。Autoresearchskill-first 与 validator 门控CLI 硬弃用0.14.0 起omx autoresearch被硬弃用。src/cli/autoresearch.ts 中除--help外的所有入口都会抛错弃用消息原文omx autoresearchis hard-deprecated. Use the$autoresearchskill for the hook-native persistent loop. Use$deep-interview --autoresearchto create or refine mission artifacts before execution. Direct CLI launch, resume, run, bare mission-dir aliases, and tmux split-pane launch are no longer supported.被禁用的历史形态包括裸命令、init [--topic T] [--evaluator CMD] [--keep-policy P] [--slug S]、run mission-dir、--resume run-id以及 tmux split-pane 启动。迁移路径来自AUTORESEARCH_HELP用$deep-interview --autoresearch澄清 mission并在.omx/specs/autoresearch-{slug}/下写出规范工件用$autoresearch your mission运行有状态、validator 门控的执行循环初始化时选择校验模式mission-validator-script或prompt-architect-artifact完成条件取决于 validator 证据而不是“重复 no-op”或“detached tmux 启动成功”。完成判定validator 证据src/autoresearch/skill-validation.ts 的assessAutoresearchCompletionState定义了完整的完成判定逻辑两种模式分别要求mission-validator-script需要状态中的mission_validator_command或mission_validator.command并读取完成工件默认.omx/specs/autoresearch-{slug}/completion.json也可用completion_artifact_path/validator_artifact_path覆盖工件中passed/complete/valid为 true 或status命中pass/passed/complete/completed/success/succeeded/approved才算通过prompt-architect-artifact需要validator_prompt且output_artifact_path指向的文件真实存在同时完成工件必须带 architect 审批architect_approved/approved为 true或architect_review/architect_validation的verdict为通过值。任何缺失都会得到结构化失败原因例如missing_mode_state、missing_validation_mode、missing_or_invalid_completion_artifact、validator_not_passed、missing_architect_approval——这些 reason 直接成为 Stop 阻塞信息的一部分。Advisory Triage 路由不激活工作流的轻量引导release notes 中 “Prompt routing has a lighter advisory lane” 的实现分布在两个文件src/hooks/triage-heuristic.ts纯同步、无副作用的分类器三档 lanePASS琐碎确认hi/thanks/ok等、显式 opt-out 短语“just chat”、“plain answer”、“no workflow”、“explain only”等、或模糊短提示LIGHT单 Agent 目的地explore / executor / designer / researcher由EXPLORE_STARTERSwhat/why/how does/tell me about…、外部资料信号官方文档、web、GitHub、npm 等等启发式决定HEAVYautopilot较长的、目标型祈使提示词。src/hooks/triage-state.ts会话级状态持久化落盘于.omx/state/sessions/session_id/prompt-routing-state.json无会话时为.omx/state/prompt-routing-state.json。规则只为 HEAVY/LIGHT 决策写入PASS 不写关键字路由不写 triage state。状态含last_triagelane、destination、reason、prompt_signature 的 sha256、turn_id、created_at与suppress_followup布尔——后者即 release notes 中 “persisted follow-up suppression”。关键在于其 advisory 属性分类结果只产生提示hint不会隐式激活任何工作流避免非关键词提示词被意外卷入重流程。Runtime Run Outcome 归一化release notes 提到 “runtime run outcomes are normalized into shared terminal/non-terminal semantics”其规范定义在 src/runtime/run-outcome.tsTerminal run outcomes终态finish、blocked_on_user、failed、cancelledNon-terminal run outcomes非终态progress、continueTerminal lifecycle outcomesfinished、blocked、failed、userinterlude、askuserQuestion归一化要点normalizeRunOutcome/normalizeTerminalLifecycleOutcome会把历史别名统一收口completed/done → finish、blocked-on-user → blocked_on_user、aborted → cancelled、ask-user-question → askuserQuestion等并返回 warning 说明归一化来源双向映射compatibilityRunOutcomeFromTerminalLifecycleOutcome如askuserQuestion → blocked_on_user与terminalLifecycleOutcomeFromRunOutcomeblocked_on_user → blocked可配置为askuserQuestion/userinterludeinferRunOutcome/inferTerminalLifecycleOutcome支持从lifecycle_outcome、run_outcome、current_phase、completed_at、active等字段推断兼容历史 state 文件applyRunOutcomeContract强制一致性终态必须activefalse且写入completed_at非终态必须activetrue且删除completed_at并删除遗留的terminal_outcome字段。这套归一化让 Stop/continuation 行为保持一致——例如 deep-interview 未决提问时blocked_on_useraskuserQuestion的推导hasPendingQuestionEnforcement检测question_enforcement.status pending。发布门禁与验证证据0.14.0 还修复了一个发布可复现性问题lint 从宽松的全目录扫描改为只针对被跟踪的源码根避免 runtime/worktree 目录下的嵌套本地 Biome 根干扰发布判定。当前 package.json 中lint为biome lint srcbuild会先清空dist再执行tsc。发布就绪文档 docs/qa/release-readiness-0.14.0.md 记录了完整验证矩阵全部 PASS检查项命令构建npm run buildLintnpm run lintTS 诊断npx tsc --noEmit --pretty false --project tsconfig.json受影响交互/运行时回归套件node --test dist/cli/__tests__/question.test.js dist/question/__tests__/deep-interview.test.js dist/question/__tests__/renderer.test.js dist/question/__tests__/ui.test.js dist/cli/__tests__/autoresearch-guided.test.js dist/autoresearch/__tests__/skill-validation.test.js dist/hooks/__tests__/keyword-detector.test.js dist/hooks/__tests__/triage-heuristic.test.js dist/hooks/__tests__/triage-state.test.js dist/runtime/__tests__/run-outcome.test.js dist/runtime/__tests__/run-loop.test.js dist/scripts/__tests__/codex-native-hook.test.js dist/team/__tests__/role-router.test.js dist/cli/__tests__/question-helpers.test.js dist/question/__tests__/policy.test.js版本同步契约node --test dist/cli/__tests__/version-sync-contract.test.js目录漂移检查node dist/scripts/generate-catalog-docs.js --check打包安装冒烟npm run smoke:packed-install发布路径打包npm pack --dry-run剩余风险与后续观察面release notes 明确指出了两点已知风险这仍是本地发布就绪验证local release-readiness pass而非完整 CI 矩阵重跑交互式 tmux/UI 行为虽被针对性测试覆盖但真实多会话操作员行为仍是发布后最有价值的观察面——尤其是严格化后的 autoresearch/deep-interview Stop 语义在长会话中是否会造成操作员意外。小结0.14.0 的实质是一次“交互编排控制面”的重构omx question提供了带 Schema 校验、策略门控、持久化状态与多环境渲染的统一提问入口deep-interview 通过可强制的义务状态机与 Stop 阻塞保证了“提问必须被结构化管理”autoresearch 以 validator 证据取代尽力而为的进度判定advisory triage 在关键字路由之外提供了轻量提示通道runtime run outcome 则把历史纷杂的别名统一成 terminal/non-terminal 两套语义。理解这五条主线就理解了 0.14.0 之后的 OmX 交互编排模型。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考