Codex app 把并行代理、Skills 和 Automations 放进同一个工作台后,日常协作的重点开始从单次问答转到任务分工。这篇按任务顺序拆开三层能力各自适合放的位置。
OpenAI 在 2026 年 2 月发布 Codex app 之后,Codex 这套工具已经从终端里的命令行代理扩展成桌面工作台。到了 3 月 4 日,Windows 版也开始进入包含 Codex 的 ChatGPT Business 工作区。表面上的变化是入口从终端扩到桌面,实际影响更大的地方在于任务组织方式。一个人同时盯多个 agent,开始进入比较常规的使用场景。
如果把 Codex app 里的能力拆开看,最容易混在一起的是三样东西:并行代理、Skills 和 Automations。它们都在减少重复动作,但承担的不是同一段工作。并行代理处理的是同一轮任务里的分工,Skills 处理的是重复指令的固定写法,Automations 处理的是已经稳定下来的周期任务。把这三层放在同一处看,会觉得功能很多;按任务顺序拆开以后,什么时候用哪一层会清楚很多。
并行代理最适合那些已经能拆成几段,而且几段之间不用一直互相等待的任务。比如先让一个 agent 读目录结构和关键模块,另一个 agent 去找测试缺口,第三个 agent 处理一组边界明确的小改动。官方把 Codex app 定义成一个可以同时管理多个 agent 的工作台,这个说法是成立的,因为它真正改变的是你安排任务的方式。以前一个会话里只能顺着往下做,现在更像是先把事情分给几个人,再回来合并结果。
这里有个前提,任务边界要先圈清楚。并行代理并不会自动把一个模糊的大任务变简单,如果起点就是一句“帮我把项目重构一下”,最后还是会在不同线程里一起发散。比较稳的起点,通常是文件范围已经大致确定、每段任务都能独立验证,而且你能说清楚每个 agent 这轮只负责哪一块。
Skills 解决的是另一类问题。OpenAI 在介绍 Codex app 时提到,他们内部已经积累了很多可复用的 Skills,用来跑评估、盯训练任务、写文档和整理实验。这个思路放到日常开发和内容协作里也很实用。只要你发现自己总在重复解释同一类要求,比如代码审查口径、测试检查顺序、文档输出格式、博客改写规则,就说明这段要求已经可以从临时提示词收成固定技能文件了。
把要求收成 Skill 之后,最大的变化不是看起来更高级,而是每次开新任务时不必重新交代一遍。团队里不同人用起来,输出也会更接近同一套口径。对内容团队来说,这一点尤其重要,因为文风、结构顺序和禁用表达这类要求,如果每次都临时复制,最后总会在不同会话里慢慢走样。
Automations 适合处理那些已经稳定,而且你明确知道要周期性重复的任务。OpenAI 在官方介绍里给的例子包括每日 issue triage、CI 失败摘要、发布简报和 bug 检查,这些任务有个共同点:输入来源比较固定,输出格式也容易复用。如果一件事你还在反复换步骤、反复改口径,就先不要急着做成自动化。真正适合排进 Automations 的,通常是已经跑顺了很多次,只是人还在机械重复。
这一层放得越晚,后面返工越少。因为自动化一旦建起来,后面每次改动都不只是改一段提示词,还会牵动时间安排、输入规则和输出位置。先把任务本身跑顺,再决定要不要交给 Automation,通常比一开始就追求定时运行更省事。
比较稳的顺序通常是这样:先用一个 agent 读项目和定范围,再把能并行的部分拆给多个 agent;当某类指令开始稳定重复时,把它收成 Skill;等这类任务本身也不再频繁变动,再考虑交给 Automation 定时跑。这样排下来,Codex app 承担的是任务调度和 review,Skill 承担的是方法复用,Automation 承担的是周期执行。三层分开以后,很多“要不要全交给 agent”的问题就会简单很多。
还有一处容易忽略,就是权限和配额并不是一刀切的。OpenAI 的帮助文档写得很直接,Codex 的使用消耗会跟任务规模、代码库大小、执行时长和执行位置一起变化,小脚本和长任务不是同一种消耗。另一点是,Codex app 本身沿用现有的 Codex 控制,没有再起一套完全独立的权限模型。也就是说,团队里如果本来就在管理 CLI、IDE extension 和 cloud delegation,app 更像是把这些能力搬到一个更好盯的界面里。
如果你现在准备试 Codex app,不必一上来就把整个开发流程都交给它。更实在的起点,是先拿一件本来就能拆成几步的小任务试一次:一个 agent 读代码,一个 agent 修局部问题,一个 agent 整理说明。做到这一步以后,再决定哪些要求要收成 Skill,哪些事情已经稳定到可以排进 Automation。