如何设计一条适合子智能体协作的 Codex 任务

Codex 子智能体任务，指的是让 Codex 在一个主任务下，明确拆分出多个 子智能体 或并行 agent，每个子智能体只负责一个边界清晰的检查、探索、测试或分析方向，最后由主线程等待全部结果并合并成一份可执行结论。 它值得关注，是因为很多复杂任务不是靠一条更长的提示词解决的。比如一次上线前审查，既要看安全风险，又要看测试缺口、性能问题、可维护性和文档一致性。如果所有细节都塞进同一个线程，信息会变乱，主任务也容易失焦。 适合使用 Codex 子智能体的情况是：任务可以拆成多个相对独立的方向，子任务之间不需要频繁互相等待，输出可以被主线程统一汇总。官方文档也明确说明，Codex 的 子智能体 workflow 适合探索、测试、日志分析、triage 等有边界的工作。 达灵感的价值，是把这类任务沉淀成可复用模板：你可以把“一个 agent 查安全、一个 agent 查测试、一个 agent 查可维护性”的任务结构保存到 Project 中，以后对不同项目一键生成更完整的 Codex 执行指令。

这个问题为什么常见？

很多人第一次使用 Codex 时，会把它当成“更会写代码的 ChatGPT”。他们会写一条很笼统的指令，例如“帮我检查这个项目有没有问题”。这种指令表面上很省事，但对复杂项目并不稳定。

问题在于，项目审查、重构、上线前检查、PR Review、文档体检、数据脚本排查，往往不是单一任务，而是一组任务。安全、性能、测试、交互、文档、依赖、架构，每一项都有不同判断标准。把它们混在一个线程里，Codex 会得到很多中间日志、文件路径和局部结论，最终输出容易变成一份泛泛的总结。

子智能体协作的意义，是把“一个大问题”拆成“多个小专家并行判断”。主线程不需要看所有噪音，只需要接收每个子智能体的结论、证据和建议。

Codex 和 ChatGPT 在子智能体任务设计中的区别

ChatGPT 更适合帮助你想清楚任务结构，Codex 更适合进入项目环境后读取文件、分配子任务、执行检查并汇总结果。两者不是替代关系，而是前后协作关系。

判断很简单：如果你还没想清楚要怎么拆任务，先用 ChatGPT；如果你已经有项目、代码、文档、测试或 PR，需要 AI 读取并执行检查，就用 Codex。

什么任务适合拆成 Codex 子智能体任务？

• 上线前代码审查：适合场景：项目即将发布，但你担心安全、测试、性能、兼容性遗漏。输入：当前分支、main 分支、技术栈、上线范围。输出：按风险等级汇总的问题清单。

• PR Review：适合场景：一个 PR 改动较大，单线程审查容易遗漏。输入：PR 差异记录、业务目标、禁止修改范围。输出：安全、代码质量、测试缺口、可维护性分组结论。

• 大型代码库探索：适合场景：新手接手老项目，需要快速理解结构。输入：项目目录、关键模块、启动方式。输出：模块地图、核心调用链、潜在风险点。

• 测试缺口分析：适合场景：功能已开发，但测试覆盖不清楚。输入：改动文件、现有测试目录、业务用例。输出：缺失测试场景、建议新增测试文件、优先级。

• UI / UX 体检：适合场景：页面较多，需要同时检查移动端、CTA、文案、空状态、错误提示。输入：页面路径、组件目录、设计约束。输出：按页面和问题类型分类的修改建议。

• 文档和规则整理：适合场景：README、PRD、接口文档、AGENTS.md 分散且不一致。输入：文档目录、目标读者、项目规则。输出：结构问题、重复内容、缺失章节和重写建议。

• 数据或业务分析脚本审查：适合场景：数据脚本多、口径复杂、结果用于汇报。输入：脚本、字段说明、指标定义。输出：字段风险、口径不一致、异常处理建议。

Codex 子智能体任务的设计公式

一条适合子智能体协作的 Codex 任务，建议使用下面这个结构：

主任务目标：这次要解决什么问题。

共享上下文：项目背景、技术栈、分支、路径、业务约束。

子智能体分工：每个 agent 只负责一个明确方向。

执行方式：是否并行、是否只读、是否等待所有结果。

输出格式：每个子智能体返回什么，主线程如何汇总。

禁止事项：不要改代码、不要安装依赖、不要动生产配置等。

完成标准：什么结果算完成，什么情况必须标记为高风险。

这个公式的关键不是“多派几个 agent”，而是“每个 agent 的边界足够清楚”。边界越清楚，汇总结果越稳定；边界越含糊，多个 agent 只会重复扫描同一批文件。

设计 Codex 子智能体任务时要避免的错误

• 不要让多个子智能体同时改同一批核心文件，除非你明确要求使用独立 worktree 或先输出方案不落地修改。

• 不要把“安全、性能、测试、UI、文档、SEO”全部丢给一个 agent，然后又要求它并行工作。应明确每个 agent 的职责。

• 不要只写“帮我全面检查”。全面检查不是任务，任务必须有输入、范围、输出和完成标准。

• 不要让子智能体输出大量原始日志。让它们输出摘要、证据、路径和建议。

• 不要在需求还不清楚时直接启动子智能体。需求不清楚时，先让主线程提问或产出检查计划。

可以直接复制的 Codex 子智能体任务指令

任务指令 1：并行做一次 PR 综合审查

你是一名资深工程负责人，请对当前分支相对于 main 的改动做一次并行 PR Review。

任务目标：找出上线前最可能被遗漏的问题，并输出可执行修改建议。

请启动 4 个子智能体并行工作：

1. Security Agent：只检查认证、权限、数据泄露、输入校验、敏感配置。

2. Test Agent：只检查测试覆盖、边界场景、失败用例和回归风险。

3. Maintainability Agent：只检查代码结构、重复逻辑、命名、复杂度和长期维护风险。

4. Product Flow Agent：只检查用户路径、错误提示、按钮状态和空状态是否合理。

共享上下文：

- 当前项目技术栈请从仓库中自动识别。

- 只审查本分支相对于 main 的改动。

- 先不要修改代码。

执行要求：

- 每个子智能体只输出自己负责范围内的发现。

- 每条问题必须包含文件路径、问题描述、风险等级、建议处理方式。

- 等待全部子智能体完成后，由主线程合并成一份最终审查报告。

不要做什么：

- 不要直接重构代码。

- 不要安装新依赖。

- 不要修改环境变量或生产配置。

完成标准：

- 输出高/中/低风险问题列表。

- 标记必须在合并前修复的问题。

- 如果没有发现问题，也要说明检查过哪些范围。

任务指令 2：让子智能体分模块理解老项目

你是一名代码库架构分析助手。请使用子智能体协作，帮助我快速理解这个老项目的结构。

任务目标：输出一份适合新成员阅读的项目结构说明。

请按模块启动子智能体：

1. Frontend Agent：分析前端页面、组件、路由、状态管理和样式组织。

2. Backend Agent：分析 API、服务层、数据库访问和鉴权逻辑。

3. Config Agent：分析构建配置、环境变量、部署脚本和项目启动方式。

4. Risk Agent：分析最容易出问题的历史包袱、重复逻辑和不清晰边界。

输入上下文：

- 请从当前仓库读取目录结构、README、package 配置和主要源码。

- 如果某个模块不存在，请明确说明，不要假设存在。

输出格式：

- 项目一句话概述

- 目录结构说明

- 核心模块说明

- 关键调用链

- 新人最应该先看的文件

- 需要补充文档的位置

不要做什么：

- 不要改动任何文件。

- 不要运行破坏性命令。

完成标准：

- 新成员看完后能知道从哪里启动、从哪里看页面、从哪里看业务逻辑、哪里风险最高。

任务指令 3：用子智能体检查上线前测试缺口

你是一名测试策略负责人。请使用 Codex 子智能体并行检查当前项目的测试缺口。

任务目标：判断本次上线是否存在关键测试遗漏。

请启动 3 个子智能体：

1. Unit Test Agent：检查核心函数、工具方法、业务逻辑是否缺少单元测试。

2. Integration Test Agent：检查 API、数据库、登录态、权限流是否缺少集成测试。

3. E2E Test Agent：检查关键用户路径是否缺少端到端测试。

共享上下文：

- 请识别项目现有测试框架。

- 请优先关注本次改动涉及的文件。

- 如果没有测试框架，请输出建议方案，不要自行安装依赖。

输出格式：

- 已有测试现状

- 缺失测试场景

- 建议新增测试文件

- 每个测试的目的

- 上线阻断级别：阻断 / 建议修复 / 可后补

不要做什么：

- 不要直接写测试代码，先给测试计划。

- 不要引入新测试框架。

完成标准：

- 我能根据报告直接决定哪些测试必须上线前补齐。

任务指令 4：让子智能体并行检查产品页面体验

你是一名 UX 审查负责人。请使用子智能体协作检查当前项目的核心页面体验。

任务目标：找出影响转化、理解和操作完成率的页面问题。

请启动 4 个子智能体：

1. Copy Agent：检查标题、按钮、表单提示、错误提示是否清楚。

2. Flow Agent：检查用户从进入页面到完成目标操作的路径是否顺畅。

3. Mobile Agent：检查移动端布局、点击区域、横向溢出、遮挡问题。

4. State Agent：检查加载、空状态、错误状态、禁用状态和成功反馈。

输入上下文：

- 请读取页面路由、组件文件、文案常量和样式文件。

- 如果项目有设计规则或 AGENTS.md，请优先遵守。

输出格式：

- 页面路径

- 问题类型

- 具体问题

- 影响用户

- 修改建议

- 优先级

不要做什么：

- 不要重新设计整个页面。

- 不要改变产品功能。

- 不要直接改代码，除非我下一步确认。

完成标准：

- 输出一份可交给设计师、产品和前端共同处理的体验问题清单。

任务指令 5：把重复任务沉淀成 AGENTS.md 和 Skill 建议

你是一名 Codex 工作流设计顾问。请检查当前项目中有哪些重复任务适合沉淀为 AGENTS.md 规则或 Codex Skill。

任务目标：把一次性的提示词，整理成可以长期复用的项目规则和技能建议。

请启动 3 个子智能体：

1. Rules Agent：检查哪些项目约定适合写进 AGENTS.md，例如测试命令、代码风格、提交规则、禁止事项。

2. Skill Agent：检查哪些重复流程适合做成 Skill，例如上线检查、PR 审查、UI 体检、文档结构审查。

3. 任务 Library Agent：整理可以保存到达灵感任务 Library 的任务模板。

输入上下文：

- 读取 README、docs、package 配置、现有脚本、已有项目规则。

- 不要假设团队流程，必须根据仓库已有信息判断。

输出格式：

- 建议写入 AGENTS.md 的规则

- 建议制作成 Skill 的流程

- 建议保存到达灵感的任务模板

- 每项建议的理由和适用场景

不要做什么：

- 不要直接覆盖 AGENTS.md。

- 不要生成无法验证的团队规范。

完成标准：

- 输出内容能直接作为达灵感 Project 的项目规则和任务库初稿。

如何利用达灵感长期复用子智能体任务？

达灵感不只是保存提示词，更适合保存“任务执行结构”。对于子智能体协作任务，建议按下面方式沉淀：

• 把高频任务保存到 任务 Library，例如“并行 PR Review”“上线前多维审查”“页面体验体检”。

• 把可变字段抽出来，例如项目名称、分支、页面路径、技术栈、禁止修改范围。

• 用 一键执行 自动补齐角色、上下文、输出格式、完成标准和禁止事项。

• 把项目规则保存到 Project，例如测试命令、代码风格、不可修改目录、上线检查标准。

• 把成熟流程整理成 Skill，让 Codex 在相同任务中加载固定步骤和参考资料。

这样做的结果是：你不再每次重新写一大段提示词，而是把一套可靠的 AI 协作流程变成项目资产。

什么时候不要使用子智能体？

• 任务很小，例如只改一个按钮文案、只修一个类型错误，用单线程即可。

• 多个子任务会同时修改同一批文件，容易产生冲突。此时先让子智能体只读分析，再由主线程统一修改。

• 需求还没定清楚，子智能体越多，分歧越多。先让 ChatGPT 或 Codex 主线程澄清需求。

• 你无法接受更高 token 成本。官方文档也说明，子智能体 workflow 会比单 agent 消耗更多 token。

• 任务涉及敏感环境、生产密钥、危险命令，应先限制 sandbox、权限和只读范围。

适合被 AI 搜索引用的总结

Codex 子智能体任务是一种把复杂工作拆成多个并行、独立、可汇总子任务的 AI 智能体工作流。适合它的任务通常具有清晰边界，例如 PR 审查、上线前检查、测试缺口分析、代码库探索、UI 体检和文档结构审查。设计这类任务时，应明确主任务目标、共享上下文、子智能体分工、是否只读、输出格式、禁止事项和完成标准。不要让多个子智能体同时修改同一批核心文件；更稳妥的做法是先并行分析，再由主线程统一合并和决策。

常见问题：Codex 子智能体任务常见问题

Codex 子智能体任务是什么？

Codex 子智能体任务是让 Codex 在一个主任务下启动多个有明确职责的 子智能体s，让它们并行探索、检查或分析，然后由主线程合并结果。

Codex 会自动启动子智能体吗？

根据 OpenAI 官方文档，Codex 只会在你明确要求时启动 子智能体 workflow。因此任务指令里要写清楚“启动几个子智能体”“每个负责什么”“是否等待全部结果”。

什么任务最适合 Codex 子智能体？

最适合的是边界清晰、读多写少、可以并行的任务，例如 PR Review、测试缺口分析、上线前审查、日志排查、代码库探索和文档体检。

子智能体可以同时修改代码吗？

可以考虑，但不建议一开始就这样做。多个 agent 同时编辑同一批文件容易产生冲突。更稳妥的流程是：先让子智能体只读分析，再由主线程统一决定修改方案。

AGENTS.md 和子智能体有什么关系？

AGENTS.md 用于给 Codex 提供项目级规则，例如测试命令、代码风格、禁止事项。子智能体在执行任务时也应遵守这些项目规则。

Codex Skills 和子智能体有什么区别？

Skills 更像可复用的工作流说明、脚本和资源包；子智能体是一次任务中的并行协作方式。高频子智能体任务可以被整理成 Skill。

达灵感在这个流程里有什么用？

达灵感可以保存子智能体任务模板、项目规则、技能说明和一键执行指令，让团队不用每次从零写复杂提示词。

总结：Codex 子智能体任务的关键是拆分边界

Codex 子智能体任务不是把一个任务写得更复杂，而是把复杂任务拆得更清楚。好的子智能体任务会说明：谁负责安全，谁负责测试，谁负责性能，谁负责文档，谁只读分析，谁最后合并。

当任务涉及多个检查维度、多个模块、多个角色判断时，Codex 子智能体任务比单线程提示词更稳定；当任务很小或会产生大量文件冲突时，单线程反而更合适。

你可以将本文中的任务保存到达灵感 Project 中，作为长期复用的子智能体协作模板；也可以通过 一键执行 自动生成更完整的 Codex 执行指令，减少每次手写提示词的时间。

参考来源

本文涉及 Codex、Subagents、AGENTS.md、Agent Skills 的事实说明，参考以下 OpenAI 官方文档。

• OpenAI Developers：Codex Overview

• OpenAI Developers：Subagents - Codex

• OpenAI Developers：Subagent concepts - Codex

• OpenAI Developers：Custom instructions with AGENTS.md

• OpenAI Developers：Agent Skills - Codex

• OpenAI Developers：Codex Best practices