YAOTU INSIGHTS

omx v0.8.7 发布解析:提示系统契约清理、团队运行时加固与 MCP stdio 生命周期统一

omx v0.8.7 发布解析:提示系统契约清理、团队运行时加固与 MCP stdio 生命周期统一
omx v0.8.7 发布解析提示系统契约清理、团队运行时加固与 MCP stdio 生命周期统一【免费下载链接】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-codexv0.8.7 是 oh-my-codexOmX在 2026-03-08 发布的一个以「工程收敛」为主题的版本核心工作是三件事把分散在多个提示面上的行为契约收拢成一份可校验的统一约定Prompt-system contract cleanup 与 XML normalization对团队team运行时做了一次以租约过期恢复与 worktree 卫生为主题的加固以及把 state、memory、code-intel、trace、team 等 MCP 服务器的 stdio 启动与退出路径统一到一个幂等关闭的共享辅助函数上。读完本文你将能理解 OmX 提示面「一源多面、契约校验」的组织方式、团队任务租约过期后的恢复机制、MCP stdio 服务的统一生命周期设计以及 Windows 平台能力探测与 npm 全局安装 bin 契约修复的细节。版本概览v0.8.7 从v0.8.6..dev共合并12 个非 merge commit时间窗口 2026-03-07 至 2026-03-08提交者包括 Yeachan-Heo、HaD0Yun、marlocarlo。从 CHANGELOG.md 对应的 diff 快照看本次改动规模为91 个文件变更3,486 / -1,747 行属于一次中等规模、以重构与加固为主的发布。完整的提交清单v0.8.6..dev如下3a42dc6 refactor: centralize prompt guidance contract validation 9b3b336 fix(platform): replace win32 hard-block with tmux capability check; add psmux support 379f52e refactor: extract shared prompt guidance fragments 9ab2f55 refactor: convert all agent prompts from Markdown headers to XML tag structure e53c915 docs: document GPT-5.4 prompt guidance contract (#620) 3c461ba chore: lower analyst and planner reasoning effort 4a93de1 chore: lower fast-path agent reasoning effort 810549a docs(prompt): clarify 2-layer orchestrator and role prompt model 7b193d7 fix(prompts): enforce leader-only orchestration boundaries adcc5b6 feat(team): harden expired-claim recovery and worktree hygiene (#624) 577c416 fix(mcp): centralize stdio lifecycle teardown for OMX servers (#626) (#627) 50619d7 Fix npm bin path contract for global install (#633)提示系统契约清理与 XML 规范化一张契约约束所有提示面本次发布最重要的结构性变化是OmX 的所有「指令面」instruction surfaces——根编排器AGENTS.md、模板、生成的 guidance、提示目录prompt catalog——现在共享一份更干净、可被机器校验的契约。改动集中体现在四个层面集中化提示引导契约校验commit3a42dc6契约校验逻辑从分散处收敛到 src/hooks/prompt-guidance-contract.ts该文件以「表面 必现正则」的数据结构描述契约抽取可复用的提示引导片段与同步脚本commit379f52e公共行为描述被抽成 docs/prompt-guidance-fragments/ 下的共享片段并由同步脚本灌入各个提示面提示目录从 Markdown 标题改为 XML 标签结构commit9ab2f55prompts/*.md中的角色提示统一采用 XML 标签化结构文档化两层编排器 / 角色提示模型commit810549a与leader-only 编排边界commit7b193d7并在仓库内直接记录了 GPT-5.4 提示引导契约commite53c915对应 PR #620。从仓库当前状态看这份契约文档已演进为 docs/prompt-guidance-contract.md其范围声明了所有需要遵守该契约的表面项目根AGENTS.md、templates/AGENTS.md、prompts/*.md 下的 XML 标签化角色提示、skills/*/SKILL.md 下的工作流技能、src/config/generator.ts 生成的顶层 Codex 配置引导以及 src/hooks/tests/ 下的回归测试。契约校验的源码实现src/hooks/prompt-guidance-contract.ts 将提示面划分为多个契约组每组用「id 文件路径 必现正则」描述ROOT_TEMPLATE_CONTRACTS针对templates/AGENTS.md要求出现 outcome-first、目标结果/成功标准/约束/可用证据/期望输出/停止条件等关键表述CORE_ROLE_CONTRACTS针对executor、planner、verifier三个核心角色例如 executor 必须包含outcome-first.*quality-focused execution与target result.*constraints.*success criteria.*validation path.*stop conditionSCENARIO_ROLE_CONTRACTS约束continue、make a PR、merge if CI green等场景措辞如 executor 必须覆盖merge to dev if CI green与verify the exact CI condition before mergingWAVE_TWO_CONTRACTS/CATALOG_CONTRACTS覆盖architect、debugger、researcher、explore等第二波角色以及analyst、designer、writer等目录角色要求出现output|report|verdict与evidence类表述SKILL_CONTRACTS与PROMPT_REFACTOR_INVARIANT_CONTRACTS约束team、worker、ultraqa、autopilot、ralplan等工作流技能的固定状态机词汇如claim-task、transition-task-status、mailbox-mark-delivered。这些正则只校验「提示面的文字行为」不执行运行时行为正如文件注释明确声明的Textual guidance contract only: these patterns prevent prompt-surface drift; they do not enforce runtime harness behavior.也就是说契约的作用是防止提示面在演进中漂移而非替代运行时的状态机逻辑。共享片段与同步脚本src/scripts/sync-prompt-guidance-fragments.ts 是「一源多面」的关键实现它以 docs/prompt-guidance-fragments/ 下的片段为唯一事实源通过成对的 HTML 注释标记如!-- OMX:GUIDANCE:OPERATING:START --与!-- OMX:GUIDANCE:OPERATING:END --把内容灌入AGENTS.md、templates/AGENTS.md、prompts/executor.md、prompts/planner.md、prompts/verifier.md。脚本同时支持--check模式当目标文件与期望内容不一致时抛出prompt_guidance_fragment_drift:file错误。这一模式被接入package.json的verify:prompt-guidance脚本node dist/scripts/sync-prompt-guidance-fragments.js --check再被 package.json 中test/verify:generated等脚本串联进 CI从机制上保证片段源与各提示面永不脱节。以 docs/prompt-guidance-fragments/core-operating-principles.md 为例共享片段覆盖了 outcome-first 响应、简洁可见的前言preamble、对清晰低风险可逆步骤的自动跟进AUTO-CONTINUE / ASK 分支、局部任务更新覆盖、证据预算与停止条件等行为条目——这些正是契约文档中「5 个核心模式」的落地文本。两层编排器 / 角色提示模型与 leader-only 边界commit810549a与7b193d7澄清了 OmX 的编排模型根编排器templates/AGENTS.md/ 项目根AGENTS.md负责模式选择与分工角色提示prompts/*.md负责具体角色的行为边界。其中「leader-only 编排边界」意味着选择模式$deep-interview、$ralplan、$team或直接 solo 执行、拥有验证责任、整合工作成果这些编排动作属于 leader而 worker 只执行分配到的切片并将阻塞上报 leader。当前 docs/prompt-guidance-contract.md 的「Orchestration sharpness rules」一节延续了这一约束并额外要求 leader/worker 职责分离、停止/升级规则显式、输出契约紧凑、bootstrap 保持最小化。团队运行时加固过期租约恢复与 worktree 卫生加固目标PR #624 对团队编排做了一次系统性加固聚焦三个方向更安全的租约过期expired-claim / expired-lease恢复行为当任务 claim 或锁的租约过期时恢复路径不再冒险操作更好的 worktree 清理与卫生路径减少团队多 worker 协作场景下残留 worktree 导致的污染更广的回归覆盖补齐 runtime / state / worktree / 端到端回归测试并新增一个专门的加固基准脚本对应 src/scripts/team-hardening-benchmark.ts。租约机制的源码证据团队状态模块 src/team/state/locks.ts 是租约机制的核心锁目录下有一个lease文件isLockStale通过比较Date.now() - leaseInfo.mtimeMs lockStaleMs判断租约是否过期续租则通过utimes(leasePath, now, now)刷新 mtime。这解释了「过期恢复」的实现基础一旦持有方停止续租超过阈值锁即被视为过期其他成员可以安全接管。与 claim 恢复相关的状态与测试分布在 src/team/state/、src/team/state.ts、src/team/runtime.ts 以及 src/team/tests/、src/team/tests/state.test.ts 等测试文件中。本次加固的意图可以从提交信息feat(team): harden expired-claim recovery and worktree hygiene (#624)与测试命名如hardening-e2e.test.ts交叉印证团队并发场景下任务认领claim与锁租约的过期必须可恢复且恢复过程不得破坏工作区一致性。MCP stdio 生命周期统一从重复样板到单一幂等关闭路径此前每个 MCP stdio 服务都自带一份「创建 transport 挂事件 关闭」的样板代码。v0.8.7PR #626、#627在 src/mcp/bootstrap.ts 中新增了autoStartStdioMcpServer共享辅助函数并让state、memory、code-intel、trace、teamhermes 等的 MCP 入口全部迁移到该函数。从当前源码看src/mcp/state-server.ts、src/mcp/memory-server.ts、src/mcp/code-intel-server.ts、src/mcp/hermes-server.ts 均已以autoStartStdioMcpServer(state, server)/(memory, ...)/(code_intel, ...)/(hermes, ...)的方式接入。autoStartStdioMcpServersrc/mcp/bootstrap.ts#L495-L754把以下生命周期事件统一收敛到同一个幂等shutdown(reason)路径stdin 的end事件stdin_endstdin 的close事件stdin_closetransport 的onclosetransport_close进程信号SIGTERMsigterm与SIGINTsigint父进程消失parent_gone由父进程看门狗检测检测到重复兄弟进程后的自我退出superseded_*系列原因。shutdown内部先置shuttingDown true防重入再清理看门狗定时器与所有事件监听await server.close()后process.exit(0)保证任意入口触发的关闭都走同一条清理链。幂等退出与重复兄弟进程管理为了让 stdio 服务在长期驻留场景下不泄漏、不重复autoStartStdioMcpServer内置了两类看门狗父进程看门狗默认每 1000msOMX_MCP_PARENT_WATCHDOG_INTERVAL_MSsrc/mcp/bootstrap.ts#L27探测process.ppid是否存活父进程消失则自行关闭避免孤儿进程堆积重复兄弟看门狗通过进程表分析同一父进程下同入口点的兄弟进程src/mcp/bootstrap.ts#L222-L290判定自己是unique、newest还是older_duplicate。若判定为被取代的旧进程则依据流量与空闲窗口决定是否自我退出未收到任何 stdin 流量时采用「流量前宽限」默认 2000ms收到过流量后采用更保守的「流量后空闲」窗口默认 60000ms避免误杀已被客户端初始化的服务。相关可调环境变量默认值见 src/mcp/bootstrap.ts#L8-L32包括环境变量默认值作用OMX_MCP_SERVER_DISABLE_AUTO_START未设置设置1即全局禁用全局禁用所有一方 MCP 服务自动启动OMX_STATE_SERVER_DISABLE_AUTO_START等未设置设置1即禁用按服务名禁用state / memory / code_intel / trace / wiki / hermesOMX_MCP_TRANSPORT_DEBUG未设置设置1开启输出[omx-server-server]生命周期调试日志OMX_MCP_PARENT_WATCHDOG_INTERVAL_MS1000父进程看门狗探测间隔OMX_MCP_DUPLICATE_SIBLING_WATCHDOG_INTERVAL_MS5000重复兄弟扫描间隔OMX_MCP_DUPLICATE_SIBLING_PRE_TRAFFIC_GRACE_MS2000无流量场景下的自我退出宽限OMX_MCP_DUPLICATE_SIBLING_POST_TRAFFIC_IDLE_MS60000有流量场景下的自我退出空闲窗口OMX_MCP_MAX_SIBLINGS_PER_ENTRYPOINT4同一父进程下同入口点保留的最大兄弟数OMX_MCP_ENTRYPOINT_MARKER无显式指定入口点标记辅助兄弟进程识别此外还有生命周期遥测写入writeMcpLifecycleTelemetrysrc/mcp/lifecycle-telemetry.ts在每个bootstrap_start、shutdown、duplicate_sibling_observed等节点记录 server 名、入口点、pid、ppid 与原因便于排障。跨平台进程表读取为支撑兄弟进程检测autoStartStdioMcpServer依赖进程表读取非 Windows 平台通过ps axww -o pid,ppid,command解析src/mcp/bootstrap.ts#L211-L215Windows 平台通过powershell.exe执行Get-CimInstance Win32_Process并ConvertTo-Json -Compress输出src/mcp/bootstrap.ts#L176-L201再按ProcessId / ParentProcessId / CommandLine / Name解析且设置了 2000ms 超时与 4MB 缓冲上限防止异常进程表拖垮服务。Windows / tmux 能力处理commit9b3b336PR #616修复了一个平台策略问题此前 OmX 会因为平台是win32而直接硬阻断原生 Windows 支持。v0.8.7 改为按实际能力探测检查实际 tmux 能力而非以平台名一刀切支持psmux作为 tmux 的替代实现在 Windows 上合适的场景使用where进行命令定位在 README.md 中更清晰地文档化各平台的安装路径。从当前源码看这一思路已沉淀为 src/utils/platform-command.ts 中的平台命令解析层WINDOWS_COMPATIBLE_COMMAND_ALIASES明确把tmux的命令别名定义为[tmux, psmux]src/utils/platform-command.ts#L39-L41即在 Windows 上解析tmux时会顺带探测psmuxresolveWindowsCommandPath按PATHEXT.exe、.com、.cmd、.bat、.ps1优先级与 PATH 逐项解析真实可执行文件并对.bat/.cmd走cmd.exe /d /s /c包装、对.ps1走powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -File包装src/utils/platform-command.ts#L177-L287classifySpawnError将ENOENT归类为missing、EPERM/EACCES归类为blockedsrc/utils/platform-command.ts#L202-L207为「能力缺失 vs 被阻断」的区分提供依据对应测试位于 src/utils/tests/platform-command.test.ts。fast-path 角色姿态微调两个轻量提交3c461ba降低 analyst 与 planner 的 reasoning effort与4a93de1降低 fast-path agent 的 reasoning effort表明analyst、planner 等快速路径角色默认推理强度被下调以匹配「轻量工作走快速路径」的既定路由姿态——即轻量任务不必动用高推理档位从而减少不必要的延迟与开销。这类姿态由 native agent 配置承载可参考 src/agents/native-config.ts 与 docs/shared/agent-tiers.md 中角色/层级/姿态元数据的组织方式。npm 全局安装 bin 契约修复v0.8.7 还包含一个临发布前的打包修复commit50619d7PR #633修正 package.json 中发布的 npm bin 路径契约并新增 src/cli/tests/package-bin-contract.test.ts 保证全局安装的omx入口在 CI 中始终受覆盖。从当前仓库看该契约的当前形态为bin: { omx: dist/cli/omx.js }package.json。测试文件 src/cli/tests/package-bin-contract.test.ts 的核心断言包括pkg.bin必须精确等于{ omx: dist/cli/omx.js }且dist/cli/omx.js必须以#!/usr/bin/env node开头package.json 的build脚本会在tsc后chmodSync(dist/cli/omx.js, 0o755)通过npm pack --dry-run --json校验打包产物必须包含dist/cli/omx.js、dist/mcp/*-server.js等运行时文件与Cargo.toml/Cargo.lock/crates//plugins/等资产同时不得包含bin/native/下的平台特定原生二进制与构建期临时产物对每个一方 MCP 插件目标执行node dist/cli/omx.js mcp-serve target并发送 MCPinitializeJSON-RPC 请求断言退出码为 0、stdout 非空且返回serverInfo.name匹配/^omx-/从而保证 bin 包装器能保持mcp-serve存活到完成 stdio 初始化。小结v0.8.7 没有引入炫目的新功能但它在工程层面价值显著提示系统从「多面漂移」走向「一源 契约校验」团队运行时在并发租约与 worktree 卫生上更稳健MCP 服务的启动与退出不再各写一套样板Windows 支持从平台硬阻断走向真实能力探测npm 全局安装的 bin 契约也被测试钉死。对于想要继续深入源码的读者建议按以下路径阅读提示契约与片段同步src/hooks/prompt-guidance-contract.ts、src/scripts/sync-prompt-guidance-fragments.ts、docs/prompt-guidance-contract.md、docs/prompt-guidance-fragments/core-operating-principles.md团队租约与状态src/team/state/locks.ts、src/team/runtime.ts、src/team/tests/hardening-e2e.test.tsMCP 生命周期src/mcp/bootstrap.ts、src/mcp/state-server.ts、src/mcp/lifecycle-telemetry.ts平台命令解析src/utils/platform-command.ts、src/utils/tests/platform-command.test.tsbin 契约package.json、src/cli/tests/package-bin-contract.test.ts。【免费下载链接】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),仅供参考