Codex 高级用法：工程协作工作流 · 组织专业能力与角色交接
什么时候用 Skill，什么时候拆 Agent
Skill 适合保存可重复触发的稳定工作方法，Agent 适合承担需要独立判断、隔离上下文或独立产物的职责；先识别复用对象，再决定保留单 Agent、沉淀 Skill 或拆出专业 Agent。
一个内容项目每次都要经历主题调研、正文写作和独立质检。我们可以把整套流程写成一个 Skill，也可以给三个 Agent 各起一个名字。两种方案都能跑起来，但很容易出现另一种问题：Skill 越写越像总指挥，Agent 只是换了称呼继续做同一件事。
小编现阶段的判断是：先看我们想复用的是工作方法，还是想分离一份责任。稳定方法交给 Skill；需要独立判断、独立上下文或独立产物的责任，才值得拆成 Agent。 两者可以组合使用，没有“简单版”和“高级版”的层级关系。
上一篇已经为任务划出了工具和权限范围。本文继续往下解决能力组织问题，只做选型，不展开 Skill 的完整开发流程，也不提前定义 Agent 的详细字段和跨角色交接协议。
一、先把四种承载位置分开
很多选型困难来自对象混用。一条临时要求、一个仓库约定、一套重复方法和一份独立职责，本来就不该放在同一个地方。
- 临时指令服务当前任务。例如“这次只检查登录模块，不修改代码”。任务结束后，它通常没有继续生效的理由。
- 项目规则记录跨任务成立的仓库约束。例如生成目录不能手工修改、提交前要运行哪个检查。它回答“在这个项目里一直要遵守什么”。
- Skill保存某类任务可重复使用的方法、材料和可选脚本。例如每次审阅文章都按相同维度读取规划、检查正文并生成报告。
- Agent承担一份值得独立完成和判断的工作。例如质检者重新读取正文，形成自己的结论，不沿用写作者的自我评价。
产品层面，OpenAI 的Build skills 官方说明把 Skill 定义为由指令、资源和可选脚本组成的任务能力包，用于让 ChatGPT 或 Codex 稳定执行一类工作流。Codex 会先看到 Skill 的名称与描述，在选中后再读取完整的 SKILL.md；Skill 既可以被显式调用，也可以根据描述匹配任务而触发。
这段定义说明 Skill 的复用单位是“工作流”。至于哪套业务方法值得做成 Skill、边界该画在哪里，仍然是项目自己的设计决定。本文只讨论这个决定，不进入目录、脚本、引用资源和发布方式等开发细节。
二、什么时候一套方法值得成为 Skill
“这次提示词很长”只能说明当前上下文复杂，不能证明方法值得复用。一次性任务即使有十页说明，做完后不再出现，沉淀只会增加维护对象。反过来，一套方法文字不多，只要会反复使用，而且每次都要求相同的边界和产物，就可能值得保存。
判断时可以看三个信号。
2.1 重复的是步骤和约束
不同任务虽然材料不同，但总要执行同样的读取顺序、检查动作和停止条件。例如文章质检每次更换标题与正文，审阅维度、事实来源优先级和“不直接修改正文”的边界保持不变。此时复用的是方法，适合交给 Skill。
若重复的只是“帮我看一下”这句话，实际目标和判断标准每次都不同，Skill 很难提供稳定价值。它会逐渐塞入大量例外，最后仍然要靠当前对话解释一遍。
2.2 输入变化，产物形态保持稳定
一套 Skill 不要求所有输入完全相同。有用的复用往往是把不同文章、不同代码目录或不同数据文件，转成同一种可检查产物。输入路径可以变化，报告结构、状态更新方式和失败返回应相对稳定。
这里的“输入输出明确”只用于判断是否值得沉淀，不展开完整接口设计。怎样写触发描述、组织 SKILL.md、拆脚本和引用资料，属于“SKILL 工程化”系列的内容边界。
2.3 方法已经足够稳定
刚做过一次的流程通常还带着大量偶然选择。先在真实任务里重复使用，确认哪些步骤不能少、哪些只是当时的补丁，再沉淀会更稳。
方法仍在频繁变化时，可以先把它留在任务计划或项目规则中观察。每次修改 Skill 都不是坏事，但如果核心目标、步骤和产物持续重写，说明复用对象还没有形成。
三、什么时候单 Agent 已经不够
Skill 能让同一个 Agent 按稳定方法工作，却不会天然制造第二份独立判断。需要分离责任时，Agent 才进入选项。
OpenAI 的Subagents 官方说明显示，Codex 可以启动专门的 subagent 处理具体任务，并在独立 agent thread 中运行，再由主线程收集结果。官方文档强调它适合可独立处理的探索、测试、日志分析和总结，也提醒并行写入可能产生冲突；每个 subagent 都会进行自己的模型与工具工作，因此会增加 token 和协调成本。
基于这些官方能力，本文再给出一组更克制的 Agent 选型建议：
3.1 需要一份不继承原结论的判断
写作者完成自审后，再让同一工作过程宣布“独立质检通过”，责任没有真正分开。质检角色需要重新读取事实并形成自己的结论，这类工作适合交给另一个 Agent。
两份独立判断完全可能得到相同结论。关键在于检查过程重新读取事实，没有把上游声明换一种说法复述。
3.2 中间过程会污染主上下文
大规模代码搜索、日志分析或资料整理会产生很多中间内容。主任务只需要结论和证据索引时，把这部分放到独立 Agent，可以让主线程继续保留目标、约束和关键决策。
但上下文长并不自动等于要拆 Agent。若后续每一步都依赖这些原始细节，分出去后还要反复补传材料，拆分反而增加遗漏风险。
3.3 工作可以形成独立产物
一个职责最好有可以单独检查的结果，例如调查报告、审阅结论或候选方案比较。只有“帮主 Agent 想一想”的角色，返回内容既没有边界也无法验收，通常留在单 Agent 内部处理更省事。
Agent 拆分与并行没有绑定关系。独立质检必须等正文完成后再开始，虽然是不同 Agent，仍然应该串行。是否并行取决于依赖关系，具体交接信息留到 03-03。
四、用决策树完成一次选型
这份决策树属于本文的工程建议。Skill 与 Agent 分别沿两条轴判断，任何一条都不能成为另一条的前置条件。
1轴一：本次工作是否需要独立判断、隔离大量中间上下文或独立产物？
2├─ 否 → 保持单 Agent
3└─ 是 → 拆出 Agent
4
5轴二：步骤、边界和产物形态是否已经稳定，而且会重复使用？
6├─ 否 → 保留为当前任务指令；长期仓库约束写入项目规则
7└─ 是 → 使用现有 Skill，或沉淀为项目 Skill
8
9组合两条轴的结果：
10├─ 单 Agent + 无 Skill：一次性且无需责任隔离的工作
11├─ 单 Agent + Skill：同一 Agent 反复执行稳定方法
12├─ 拆 Agent + 无 Skill：一次性工作也可能需要独立判断或上下文隔离
13└─ 拆 Agent + Skill：独立 Agent 使用稳定方法完成阶段责任两条轴都走完后，再做一次反向检查：
- 两个 Skill 是否只是名称不同，实际步骤和产物相同；
- 两个 Agent 是否只换了语气，没有独立判断或产物；
- 某个长期仓库规则是否被误塞进只有特定任务才触发的 Skill；
- 某个 Agent 是否承担了从规划到执行再到自我放行的整条链路；
- 拆分带来的上下文传递和协调成本，是否高于它隔离的风险。
有重叠时先合并，有责任空缺时再补。不要靠增加角色数量掩盖边界模糊。
五、Skill 定义方法，Agent 承担阶段责任
当前 JVS 项目提供了一个可以核对的组合。jvs-write 保存单篇写作的方法：读取文章规划和前置内容、按风格与结构成稿、执行第二遍自审、更新草稿状态。它可以被不同写作任务反复调用，所以适合作为 Skill。
article_master 承担文章写作这一阶段责任，可以使用 jvs-write。article_reviewer 则调用另一套审阅方法，独立生成审阅结论。这里拆 Agent，是因为实现者自审不能替代独立质检，与写作或审阅谁更“高级”无关。至于两个 Agent 需要哪些字段、怎样限制写入、如何传递路径和授权，后两篇再处理。
这个组合也说明一种常见错误：把“文章大师”“质检大师”写成两个只改变口吻的角色，却让它们读取相同指令、生成相同产物。名字不同没有产生责任边界。反过来，把调研、写作和质检全部塞进一个巨型 Skill，也会让方法包同时负责决策、执行和放行，出了问题很难定位是哪一段责任失效。
选择时先保留单 Agent 这个默认选项。稳定、可重复、输入变化但产物形态明确的方法出现后，再沉淀 Skill；只有工作确实需要独立判断、上下文隔离或独立产物，才增加 Agent。选型结果应能压缩成一句清楚的话：哪个 Agent 承担什么阶段责任，它使用哪套 Skill 完成这类任务。