oh-my-codex v0.8.9 深度解析团队 Worker 路由角色端到端落地与 Scale-Up 任务身份保真【免费下载链接】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导读oh-my-codex v0.8.9 是一个聚焦团队Team模式正确性的热修复hotfix版本核心解决了两个启动路径上的身份断点一是规划阶段推断出的路由角色routed role此前只停留在计划层面没有真正进入 worker 的启动指令与运行期元数据二是动态扩容scale-up新增 worker 时任务在 worker 引导前未经过规范化的团队状态持久化导致任务 id、角色、inbox 元数据与初始团队启动时的运行时契约不一致。读完本文你将掌握路由角色如何从规划一路传递到 worker 的AGENTS.md与 identity 文件、动态扩容如何先持久化任务再引导 worker以保证任务身份保真以及升级后需要执行的omx setup刷新操作与对应的测试回归覆盖。版本背景与发布范围本版本发布于 2026-03-08包含v0.8.8..dev之间的 2 个非合并提交贡献者为 Yeachan-Heo对应 PR #643。完整的提交记录如下11b2640 fix(team): persist scaled tasks before worker bootstrap 5591cf6 fix(team): persist routed roles into startup instructions (#643)从提交信息可以看出v0.8.9 的改动全部集中在src/team团队运行时模块属于对上一版本团队启动与扩容路径的缺陷修复与契约收口。核心修复一路由角色在 Worker 启动路径上的端到端落地问题本质角色只在规划层被推断团队模式下leader 会对任务做角色路由role routing即根据任务描述的关键词与意图启发式地将任务分配给特定专业角色如test-engineer、writer、debugger等。v0.8.9 之前路由结果主要停留在规划阶段worker 真正启动时拿到的指令面与运行期身份信息并没有完整携带这一角色导致 worker 实际执行行为与计划分配的角色脱节。修复后的三条链路v0.8.9 将路由角色落到了三个相互印证的位置运行期团队配置与 worker 身份identity持久化worker 的role字段被写入 live team config 以及 worker 目录下的identity.json使角色成为运行期元数据而非一次性计划结果。这在 src/team/scaling.ts 中体现为ScaleUpWorkerInfo携带role: runtimeRole并经writeWorkerIdentity写入team_state_root/team/team/workers/worker/identity.json。逐 worker 的启动AGENTS.md组合启动时为每个 worker 组合一份专用指令文件将解析出的角色 prompt 内容嵌入其中。核心实现在 src/team/worker-bootstrap.tswriteWorkerWorktreeRootAgentsFile当 worker 运行在 git worktree 中时在 worktree 根目录生成AGENTS.md其中包含!-- OMX:TEAM:ROLE:START --与!-- OMX:TEAM:ROLE:END --包裹的角色块writeWorkerRoleInstructionsFile非 worktree 场景下将团队级指令worker-agents.md与角色 overlay 组合写入.omx/state/team/team/workers/worker/AGENTS.mdgenerateWorkerRootAgentsContent生成的指令中明确写出You are operating as the **${workerRole}** role for this team run. Apply the following role-local guidance.并跟随rolePromptContent。inbox 指令面generateInitialInbox会输出**Role:** workerRole并在存在角色 prompt 时生成## Your Specialization小节将行为准则直接呈现在 worker 的收件箱指令中。角色 prompt 的加载与合成路由角色要变成可执行指令需要先加载对应的角色 prompt 文件。在 src/team/role-router.ts 中loadRolePrompt(role, promptsDir)从 prompts 目录读取role.md文件并要求角色名匹配^[a-z][a-z0-9-]*$安全模式查找顺序为 leader 项目内.codex/prompts优先其次为仓库内置的codexPromptsDir()即仓库根下的 prompts 目录内含executor.md、test-engineer.md、writer.md等专业角色定义随后经composeRoleInstructionsForRole定义于 src/agents/native-config.ts结合解析出的模型覆盖model override合成最终角色指令内容。该加载与合成逻辑在初始团队启动路径 src/team/runtime.ts约 L3717-L3786与扩容路径 src/team/scaling.ts约 L1151-L1169中保持一致这正是路由角色端到端的代码级保证。角色默认推理分配与启动覆盖v0.8.9 同时明确了角色与模型推理参数reasoning effort的关系除非显式传入启动覆盖launch override否则按角色保持默认推理分配。在 src/team/scaling.ts 的buildScaleUpWorkerLaunchPlans中runtimeRole的计算规则是若某 worker 被分配的任务角色唯一则采用该任务角色否则回退到agentType随后resolveAgentReasoningEffort(runtimeRole, codexHomeOverride)按角色解析首选推理强度失败时再回退到agentType的默认值。也就是说角色既驱动指令面也驱动默认推理策略且显式启动参数始终拥有更高优先级。核心修复二Scale-Up 任务引导先持久化后引导 Worker问题本质合成式 inbox 元数据破坏任务身份v0.8.9 之前动态扩容新增 worker 时新任务在 worker 引导前没有经过规范化团队状态canonical team state的写入而是临时重建了一份仅存在于 inbox 中的任务元数据。后果是扩容 worker 拿到的任务 id、角色、inbox 信息与初始团队启动时的运行时契约不一致容易造成任务身份漂移与生命周期状态错乱。修复后的顺序保证修复后scaleUp的执行顺序被调整为先持久化任务再引导 worker先冻结启动策略launch policybuildScaleUpWorkerLaunchPlans在任务持久化之前构建并校验全部 worker 启动计划计划成为唯一的启动策略来源再通过规范化团队状态写入任务对每个传入任务调用createStateTask来自 src/team/team-ops.ts以pending状态写入team_state_root/team/team/tasks/task-id.json携带subject、description、owner、blocked_by、role等完整字段见 src/team/scaling.ts L1033-L1053 的scale_up_task_materialization段用持久化后的任务清单生成 inbox 与身份materializedTasks await listTasks(...)读取规范化的任务列表worker 的 inboxgenerateInitialInbox、identitywriteWorkerIdentity与任务文件全部基于这份持久化状态生成保证角色、owner、任务 id 三者一致。由此扩容 worker 与初始启动 worker 共享同一套任务读写契约任务文件是tasks/task-id.jsonAPI 与状态层使用裸task_id如1而非task-1前缀。扩容启动计划的角色保真细节ScaleUpWorkerLaunchPlansrc/team/scaling.ts L317-L324记录了workerIndex、workerName、runtimeRole、workerLaunchArgs、workerCli与mixedTaskRoles。其中runtimeRole从已持久化任务的role字段聚合而来taskAssignments.filter(t t.owner workerName).map(t t.role)这保证了扩容时角色判断建立在持久化任务之上而不是建立在临时构造的合成数据上。若一个 worker 的任务角色不唯一则回退到 agentType并打印mixed task roles提示。失败回滚的契约化保障扩容路径还配套了完善的失败回滚机制rollbackScaleUp同文件 L778 起包括通过commitTeamMembershipTaskTransaction/recoverTeamMembershipTaskTransaction做成员与任务的事务化持久化回滚、基于 pane 身份pid、session、window、team owner tag的授权清理、worktree 回滚以及 cleanup debt 事件上报。这些机制确保先持久化再引导的每一步都处于可恢复的事务边界内。升级注意事项项目级安装需刷新配置如果你使用的是项目级project-scopedOMX 安装升级到 v0.8.9 后需要重新执行omx setup --force --scope project以刷新受管的项目配置与 native-agent 路径。该命令在 src/cli/setup.ts 中的语义为--force是对 catalog 已知项的显式破坏性选择在备份后进行替换setup 输出中也提示omx setup ${scopeFlag} --merge-agents可用于保留本地指引--force则备份后整体替换--scope project限定安装范围到项目根scope project分支管理项目根下的.codex配置、skills 收据与 native-agent 路径。注意--force会替换已存在的托管配置升级刷新前请确认项目中不存在需要保留的本地手写指引或改用--merge-agents保留合并语义。测试回归覆盖与验证v0.8.9 的两个修复均有对应的自动化测试支撑主要位于 src/team/tests/scaling.test.ts规范化任务状态与 inbox id 的回归测试约 L910 起persists scaled-up task roles in canonical task state and inbox ids断言扩容创建的任务经readTask读取后role writerworker 的identity.json中role writerinbox 中携带任务角色与正确 id。非 worktree 扩容的角色指令组合测试约 L1843、L1924 起断言生成的.omx/state/team/team/workers/worker-2/AGENTS.md包含You are operating as the **writer** role与identityYou are Writer./identity验证writeWorkerRoleInstructionsFile的输出。worktree 扩容的根级 AGENTS 引导测试约 L1976 起uses canonical root AGENTS bootstrap for scaled worktree workers断言 worktree 根目录.omx/team/team/worktrees/worker-2/AGENTS.md同样包含 writer 角色指令与身份内容。frontier 角色测试约 L2083 起验证test-engineer角色的组合结果同样正确落入 worker 的 AGENTS 文件。此外src/team/tests/runtime.test.ts、src/team/tests/tmux-session.test.ts 与 src/team/tests/worker-bootstrap.test.ts 共同覆盖了 live worker 启动路径上的运行时、tmux 会话与 worker 引导三个阶段与发布说明中runtime、tmux-session、worker-bootstrap 三层覆盖的描述一致。小结v0.8.9 虽然只有两个提交却堵住了团队模式下两个关键的身份断裂点角色端到端路由角色从规划、启动指令AGENTS.md/inbox到运行期元数据identity.json/config全程保真并驱动默认推理分配扩容身份保真动态扩容先经规范化团队状态持久化任务再引导 worker使扩容 worker 与初始 worker 遵循同一运行时契约任务 id、角色、owner 不再漂移。对团队模式重度用户而言升级后务必执行omx setup --force --scope project刷新项目级安装并可通过上述测试用例与 src/team 目录下的worker-bootstrap.ts、scaling.ts、runtime.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），仅供参考 oh-my-codex v0.8.9 深度解析：团队 Worker 路由角色端到端落地与 Scale-Up 任务身份保真
oh-my-codex v0.8.9 深度解析团队 Worker 路由角色端到端落地与 Scale-Up 任务身份保真【免费下载链接】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导读oh-my-codex v0.8.9 是一个聚焦团队Team模式正确性的热修复hotfix版本核心解决了两个启动路径上的身份断点一是规划阶段推断出的路由角色routed role此前只停留在计划层面没有真正进入 worker 的启动指令与运行期元数据二是动态扩容scale-up新增 worker 时任务在 worker 引导前未经过规范化的团队状态持久化导致任务 id、角色、inbox 元数据与初始团队启动时的运行时契约不一致。读完本文你将掌握路由角色如何从规划一路传递到 worker 的AGENTS.md与 identity 文件、动态扩容如何先持久化任务再引导 worker以保证任务身份保真以及升级后需要执行的omx setup刷新操作与对应的测试回归覆盖。版本背景与发布范围本版本发布于 2026-03-08包含v0.8.8..dev之间的 2 个非合并提交贡献者为 Yeachan-Heo对应 PR #643。完整的提交记录如下11b2640 fix(team): persist scaled tasks before worker bootstrap 5591cf6 fix(team): persist routed roles into startup instructions (#643)从提交信息可以看出v0.8.9 的改动全部集中在src/team团队运行时模块属于对上一版本团队启动与扩容路径的缺陷修复与契约收口。核心修复一路由角色在 Worker 启动路径上的端到端落地问题本质角色只在规划层被推断团队模式下leader 会对任务做角色路由role routing即根据任务描述的关键词与意图启发式地将任务分配给特定专业角色如test-engineer、writer、debugger等。v0.8.9 之前路由结果主要停留在规划阶段worker 真正启动时拿到的指令面与运行期身份信息并没有完整携带这一角色导致 worker 实际执行行为与计划分配的角色脱节。修复后的三条链路v0.8.9 将路由角色落到了三个相互印证的位置运行期团队配置与 worker 身份identity持久化worker 的role字段被写入 live team config 以及 worker 目录下的identity.json使角色成为运行期元数据而非一次性计划结果。这在 src/team/scaling.ts 中体现为ScaleUpWorkerInfo携带role: runtimeRole并经writeWorkerIdentity写入team_state_root/team/team/workers/worker/identity.json。逐 worker 的启动AGENTS.md组合启动时为每个 worker 组合一份专用指令文件将解析出的角色 prompt 内容嵌入其中。核心实现在 src/team/worker-bootstrap.tswriteWorkerWorktreeRootAgentsFile当 worker 运行在 git worktree 中时在 worktree 根目录生成AGENTS.md其中包含!-- OMX:TEAM:ROLE:START --与!-- OMX:TEAM:ROLE:END --包裹的角色块writeWorkerRoleInstructionsFile非 worktree 场景下将团队级指令worker-agents.md与角色 overlay 组合写入.omx/state/team/team/workers/worker/AGENTS.mdgenerateWorkerRootAgentsContent生成的指令中明确写出You are operating as the **${workerRole}** role for this team run. Apply the following role-local guidance.并跟随rolePromptContent。inbox 指令面generateInitialInbox会输出**Role:** workerRole并在存在角色 prompt 时生成## Your Specialization小节将行为准则直接呈现在 worker 的收件箱指令中。角色 prompt 的加载与合成路由角色要变成可执行指令需要先加载对应的角色 prompt 文件。在 src/team/role-router.ts 中loadRolePrompt(role, promptsDir)从 prompts 目录读取role.md文件并要求角色名匹配^[a-z][a-z0-9-]*$安全模式查找顺序为 leader 项目内.codex/prompts优先其次为仓库内置的codexPromptsDir()即仓库根下的 prompts 目录内含executor.md、test-engineer.md、writer.md等专业角色定义随后经composeRoleInstructionsForRole定义于 src/agents/native-config.ts结合解析出的模型覆盖model override合成最终角色指令内容。该加载与合成逻辑在初始团队启动路径 src/team/runtime.ts约 L3717-L3786与扩容路径 src/team/scaling.ts约 L1151-L1169中保持一致这正是路由角色端到端的代码级保证。角色默认推理分配与启动覆盖v0.8.9 同时明确了角色与模型推理参数reasoning effort的关系除非显式传入启动覆盖launch override否则按角色保持默认推理分配。在 src/team/scaling.ts 的buildScaleUpWorkerLaunchPlans中runtimeRole的计算规则是若某 worker 被分配的任务角色唯一则采用该任务角色否则回退到agentType随后resolveAgentReasoningEffort(runtimeRole, codexHomeOverride)按角色解析首选推理强度失败时再回退到agentType的默认值。也就是说角色既驱动指令面也驱动默认推理策略且显式启动参数始终拥有更高优先级。核心修复二Scale-Up 任务引导先持久化后引导 Worker问题本质合成式 inbox 元数据破坏任务身份v0.8.9 之前动态扩容新增 worker 时新任务在 worker 引导前没有经过规范化团队状态canonical team state的写入而是临时重建了一份仅存在于 inbox 中的任务元数据。后果是扩容 worker 拿到的任务 id、角色、inbox 信息与初始团队启动时的运行时契约不一致容易造成任务身份漂移与生命周期状态错乱。修复后的顺序保证修复后scaleUp的执行顺序被调整为先持久化任务再引导 worker先冻结启动策略launch policybuildScaleUpWorkerLaunchPlans在任务持久化之前构建并校验全部 worker 启动计划计划成为唯一的启动策略来源再通过规范化团队状态写入任务对每个传入任务调用createStateTask来自 src/team/team-ops.ts以pending状态写入team_state_root/team/team/tasks/task-id.json携带subject、description、owner、blocked_by、role等完整字段见 src/team/scaling.ts L1033-L1053 的scale_up_task_materialization段用持久化后的任务清单生成 inbox 与身份materializedTasks await listTasks(...)读取规范化的任务列表worker 的 inboxgenerateInitialInbox、identitywriteWorkerIdentity与任务文件全部基于这份持久化状态生成保证角色、owner、任务 id 三者一致。由此扩容 worker 与初始启动 worker 共享同一套任务读写契约任务文件是tasks/task-id.jsonAPI 与状态层使用裸task_id如1而非task-1前缀。扩容启动计划的角色保真细节ScaleUpWorkerLaunchPlansrc/team/scaling.ts L317-L324记录了workerIndex、workerName、runtimeRole、workerLaunchArgs、workerCli与mixedTaskRoles。其中runtimeRole从已持久化任务的role字段聚合而来taskAssignments.filter(t t.owner workerName).map(t t.role)这保证了扩容时角色判断建立在持久化任务之上而不是建立在临时构造的合成数据上。若一个 worker 的任务角色不唯一则回退到 agentType并打印mixed task roles提示。失败回滚的契约化保障扩容路径还配套了完善的失败回滚机制rollbackScaleUp同文件 L778 起包括通过commitTeamMembershipTaskTransaction/recoverTeamMembershipTaskTransaction做成员与任务的事务化持久化回滚、基于 pane 身份pid、session、window、team owner tag的授权清理、worktree 回滚以及 cleanup debt 事件上报。这些机制确保先持久化再引导的每一步都处于可恢复的事务边界内。升级注意事项项目级安装需刷新配置如果你使用的是项目级project-scopedOMX 安装升级到 v0.8.9 后需要重新执行omx setup --force --scope project以刷新受管的项目配置与 native-agent 路径。该命令在 src/cli/setup.ts 中的语义为--force是对 catalog 已知项的显式破坏性选择在备份后进行替换setup 输出中也提示omx setup ${scopeFlag} --merge-agents可用于保留本地指引--force则备份后整体替换--scope project限定安装范围到项目根scope project分支管理项目根下的.codex配置、skills 收据与 native-agent 路径。注意--force会替换已存在的托管配置升级刷新前请确认项目中不存在需要保留的本地手写指引或改用--merge-agents保留合并语义。测试回归覆盖与验证v0.8.9 的两个修复均有对应的自动化测试支撑主要位于 src/team/tests/scaling.test.ts规范化任务状态与 inbox id 的回归测试约 L910 起persists scaled-up task roles in canonical task state and inbox ids断言扩容创建的任务经readTask读取后role writerworker 的identity.json中role writerinbox 中携带任务角色与正确 id。非 worktree 扩容的角色指令组合测试约 L1843、L1924 起断言生成的.omx/state/team/team/workers/worker-2/AGENTS.md包含You are operating as the **writer** role与identityYou are Writer./identity验证writeWorkerRoleInstructionsFile的输出。worktree 扩容的根级 AGENTS 引导测试约 L1976 起uses canonical root AGENTS bootstrap for scaled worktree workers断言 worktree 根目录.omx/team/team/worktrees/worker-2/AGENTS.md同样包含 writer 角色指令与身份内容。frontier 角色测试约 L2083 起验证test-engineer角色的组合结果同样正确落入 worker 的 AGENTS 文件。此外src/team/tests/runtime.test.ts、src/team/tests/tmux-session.test.ts 与 src/team/tests/worker-bootstrap.test.ts 共同覆盖了 live worker 启动路径上的运行时、tmux 会话与 worker 引导三个阶段与发布说明中runtime、tmux-session、worker-bootstrap 三层覆盖的描述一致。小结v0.8.9 虽然只有两个提交却堵住了团队模式下两个关键的身份断裂点角色端到端路由角色从规划、启动指令AGENTS.md/inbox到运行期元数据identity.json/config全程保真并驱动默认推理分配扩容身份保真动态扩容先经规范化团队状态持久化任务再引导 worker使扩容 worker 与初始 worker 遵循同一运行时契约任务 id、角色、owner 不再漂移。对团队模式重度用户而言升级后务必执行omx setup --force --scope project刷新项目级安装并可通过上述测试用例与 src/team 目录下的worker-bootstrap.ts、scaling.ts、runtime.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），仅供参考