背景
高级编排听起来很适合“一键让 team 执行计划”，但运行面不一样时，体验会完全不同。桌面版 Codex 适合日常编辑、验证和总结；OMX 的 team、hud、question 更依赖 WSL、tmux 和运行时状态。
这次解决了什么
这个复盘要把边界说清楚：不是不能从 Codex 调 WSL，而是不要把需要 tmux 附着的交互面，当成普通后台命令随手启动。
关键过程
稳妥路径是先把任务切成可执行计划，再决定是否需要团队编排。对于新站脚手架这种顺序依赖很强的工作，先由一个主代理做最小可用版本更稳。等结构稳定后，再把文章迁移、脱敏检查、视觉审查这类独立任务交给子代理或 OMX team。
如果确实要用 OMX team，更好的方式是在 WSL 里进入 tmux 会话，再启动 OMX 运行时。桌面版 Codex 可以负责生成计划、观察文件变化、读取日志和检查 Git diff，但不要假设它能自然接管所有 tmux 内的交互。
踩坑
常见误区有两个：
- 看到
team这个词，就立刻启动多代理，结果协调成本超过任务本身。 - 在桌面外层直接跑需要 tmux 语境的入口，导致状态、问题弹窗或 HUD 行为不可控。
最后方案
先直接实现最小闭环：新建站点、做样稿、跑构建、看页面。之后再把“内容批量迁移”和“私有案卷生成器”拆给并行执行。
以后怎么做
判断是否使用 team，不看任务听起来多大，而看是否能拆成互不冲突的独立写入面。能拆、能验收、能减少等待时，再开 team。