Codex 子 Agent 怎么分工：让并行工作有边界、有交付、有复核

X 用户 goan999999 在 Codex 子 Agent 原帖中分享了给不同 Agent 分配实现、测试、文档和排错工作的做法，并附带一个 Luna worker 配置示例。原帖发表于 2026 年 8 月 16 日。模型 ID、可用性和账户限额都会变化；配置示例应视为当时的个人设置，使用前先检查当前 Codex 文档和可用模型。汇总帖：五项方法索引。

子 Agent 的收益来自任务拆分

子 Agent 适合处理能够明确限定输入和输出的并行工作，例如：分别检查几个独立模块、整理测试失败证据、更新彼此无依赖的文档，或让一个 Agent 实现、另一个 Agent 做只读审查。它们不会自动让工作更便宜或更快：协调、重复读取、结果冲突和主 Agent 的复核都会产生额外开销。

通常不适合委派的任务包括：需要持续共享同一组未决设计选择、改动高度重叠文件、或缺少可验证完成条件的工作。遇到这些情况，先由主 Agent 把目标和接口决策说清楚，再拆分独立部分。

给每个子任务一份可验收的说明

目标：完成哪一个独立结果
范围：允许读取和修改的文件或目录
输入：已有设计、代码位置、日志或决定
约束：不能改变的接口、安全边界和依赖
交付：代码、测试结果、文档或发现的问题
验收：需要运行的命令及通过条件
停止条件：遇到什么冲突或不确定性时先汇报

任务说明越清楚，主 Agent 越容易判断输出是否完整。不要只说“检查一下这个目录”，要要求提供问题位置、证据、影响和建议；也不要让多个 Agent 同时编辑同一文件而没有合并责任人。

主 Agent 负责的部分

一套稳妥的流程是：主 Agent 先理解需求并确定接口边界；把可独立的工作分发出去；等待结果后核对证据与实际文件；解决冲突并运行必要验证；最后汇报哪些工作由谁完成、哪些命令确实执行过。主 Agent 不能把未经检查的子 Agent 输出当成事实或测试通过证明。

对代码实现任务，应检查实际 diff、未覆盖的边界条件、依赖变化和测试日志。对只读审查任务，应确认发现对应当前代码，而不是通用建议。若子 Agent 的结论影响设计，就保留判断依据，避免只传递压缩后的结论。

关于模型配置和套餐额度

原帖给出的 worker 配置含特定模型名称和推理强度。这类设置可能随版本变化，也不保证所有账户或环境都能使用。先查看当前可用模型、子 Agent 配置格式和本账户用量说明，不要为了复现旧示例把配置文件盲目覆盖。

更重要的是，委派不会凭空创造订阅权益或无上限 Token。子 Agent 消耗、并发和请求限制受当前产品计划、模型与系统政策约束；具体数字应以账户界面和官方说明为准。把“无限子弹”当作比喻可以，把它当成额度保证则不可靠。

延伸阅读：多 Agent 协作工作流与Codex 入门工作流。

来源：goan999999，Codex 自定义 Agent 分工与配置经验，2026-08-16；五项方法汇总帖。