Codex 多 Agent 任务拆分边界
多 Agent 的价值不是“多叫几个人一起想”，而是把原本串行的等待时间压缩掉。任务拆得好，代码搜索、方案比较、独立模块实现和测试补齐可以同时推进；任务拆得差，多个 Agent 会重复读同一批文件、争抢同一个配置，最后由主 Agent 花更多时间解决冲突。
OpenAI 官方文档将 Multi-agent 描述为由根 Agent 创建并协调多个 subagent，再综合结果。官方同时提醒：它适合具体、独立的工作流；对依赖单一顺序推理、频繁写共享可变状态，或主要耗时集中在一个外部操作上的任务，收益可能有限。本文不绑定某个界面按钮，而是把这个原则转成日常编码可执行的拆分边界。
一、先判断瓶颈能否被并行化
不要从“能开几个 Agent”开始，而要先画依赖关系。若 B 必须读取 A 的输出、C 又必须读取 B 的输出，即使把三步分别交给三个 Agent，它们仍只能排队。真正值得并行的是同一层中的独立节点。
| 任务形状 | 是否适合多 Agent | 原因 |
|---|---|---|
| 分别探索前端、后端和测试结构 | 适合 | 读取范围独立，结果可汇总 |
| 比较三种互斥技术方案 | 适合 | 假设与证据可分开维护 |
| 在三个互不重叠模块补测试 | 适合 | 写入所有权可明确划分 |
| 连续修改同一个核心函数 | 不适合 | 后一步依赖前一步代码 |
| 一次数据库迁移 | 通常不适合 | 共享状态且失败代价高 |
| 等待同一条 CI 完成 | 不适合 | 瓶颈是单一外部操作 |
一个简单判断是：假设其中一个子任务晚十分钟完成，其他子任务能否继续并产生有效结果？如果答案是否定的，这些工作并不独立，应保留在主线串行处理。
二、探索可以按问题拆，不能只按目录拆
“你看前端、你看后端”有时过于宽泛。目录边界并不一定对应问题边界：认证逻辑可能同时分布在路由、中间件、数据库和前端状态中。更好的委派方式是一条可证伪的问题，例如“找出 access token 从签发到校验的完整路径，并列出相关文件与入口函数”。
每个探索任务需要四个元素：问题、范围、期望证据和停止条件。示例：
目标：定位订单重复创建的所有可能入口。
范围：只读 src/api、src/jobs 与数据库 schema。
证据：文件路径、函数名、调用关系、去重键位置。
停止：覆盖 HTTP、重试队列和定时任务三个入口后返回。这种写法让不同 Agent 可以分别查入口、数据约束和日志证据，又不会都写一篇泛泛的“系统架构总结”。主 Agent 汇总时也能判断证据是否互补，而不是比较三份措辞不同的同义答案。
三、写代码必须先分配文件所有权
多个 Agent 共享工作区时，最危险的不是 Git 冲突提示，而是没有提示的语义覆盖：一个 Agent 改了类型，另一个仍按旧类型实现，文件可能都能合并，整体却已经不一致。因此写入型委派必须明确所有权。
理想边界是互不重叠的文件集合，例如 Agent A 负责 src/auth/，Agent B 负责 tests/auth/。若两个子任务必须修改同一个 barrel export、路由表或 schema，先指定唯一所有者；其他 Agent 只返回建议或补丁说明，由所有者统一落地。
所有权还要包含“不得做什么”：不要顺手格式化全仓库，不要回退别人刚出现的改动，不要重写共享 lockfile，不要为了让局部测试通过而修改另一位 Agent 的模块。并行窗口越长，这些约束越重要。
四、上下文应按最小充分集传递
把主会话全部历史复制给每个 subagent 看似稳妥，实际上会增加干扰。子 Agent 应拿到完成任务所需的最小上下文：目标、相关规则、候选文件、接口契约和验收命令。与它无关的讨论、失败尝试和其他模块细节可以省略。
但“少给上下文”不能变成省略硬约束。项目的 AGENTS.md、目录级规则、安全边界、用户明确禁止的动作，必须随任务传递。若需要修改接口，还应提供消费者清单或要求先查找调用方，避免局部实现正确、系统集成失败。
上下文的另一条边界是决策权。可以让子 Agent 收集事实、实现明确组件，但涉及跨模块权衡、公共 API 变化和破坏性迁移时，应由主 Agent统一决策。否则多个 Agent 会基于不同假设各自“优化”。
五、依赖型工作采用波次，而非全量并发
复杂功能往往不是完全并行或完全串行，而是分成几波。第一波并行探索，第二波由主 Agent确定接口，第三波并行实现独立组件，第四波统一集成与验证。这种“并行—收敛—并行—收敛”比一次性派发全部任务稳定。
Wave 1: 代码路径探索 | 风险审计 | 测试现状
↓
Gate 1: 主 Agent 确认方案与接口
↓
Wave 2: 模块 A 实现 | 模块 B 实现 | 独立测试
↓
Gate 2: 集成、全量测试、diff 审查每个 Gate 都要产出可检查的事实，而不是“大家都完成了”。Gate 1 至少固定接口、文件所有权和验证方法；Gate 2 至少确认所有结果已合并、没有越界修改、全量测试通过。
六、哪些任务应坚持单 Agent
小改动不值得支付协调成本。修改一个文案、修一个定位清楚的条件分支、更新单一配置，通常由一个 Agent 完成更快。需要反复读取同一份长文并保持一致语义的工作，例如重写核心协议，也适合单一上下文连续推进。
频繁写共享状态的工作更应谨慎，包括数据库 schema、依赖锁文件、全局路由表、统一类型定义和发布版本号。可以并行进行只读评审，但最终写入应有一个所有者。生产发布、删除数据和外部通知也不应因多 Agent 而分散授权判断；这些动作仍需清晰的单点审批与审计记录。
调试时也不要机械并行。如果只有一个稳定复现路径，先由一个 Agent 缩小故障范围；当出现多个独立假设，例如缓存、并发和序列化都可能是根因，再分别验证。过早并行会让每个人都从零复现，浪费相同时间。
七、主 Agent 的工作是集成，不是转发
subagent 返回“完成”不是验收证据。主 Agent需要读取关键 diff，确认修改范围，运行跨模块测试，并处理结果之间的矛盾。若两个探索结论不同，应回到文件、日志或测试，而不是用多数票决定。
建议要求每个子任务返回固定结构：结论、证据、修改文件、已运行验证、未解决风险。实现任务还要说明是否观察到他人并发改动。这样主 Agent可以快速识别缺口，不必从长篇过程叙述里寻找关键事实。
衡量多 Agent 是否有效，至少比较端到端耗时、总 token 或计算消耗、重复探索比例、冲突数和一次集成通过率。并发降低了墙钟时间但让集成返工翻倍，并不一定是成功。官方资料也明确指出，多 Agent 可能增加 token 使用量，团队应以代表性任务实测，而不是默认“越多越快”。
八、一个可复用的拆分检查表
派发前逐项确认：子任务是否有独立输入与输出；是否能在其他任务失败时仍产生价值；写入文件是否互斥；共享接口是否已经固定；是否提供了项目规则；完成条件能否由命令或证据验证；是否指定了回传格式；主 Agent是否保留最终集成责任。
如果其中“文件互斥”“接口固定”“独立产生价值”有任意一项不满足，先改成只读探索或放回主线串行处理。多 Agent 的边界本质上不是角色数量，而是依赖、状态和所有权是否清晰。
九、相关阅读
需要在多 Agent 工作流中统一调用不同模型时，YoTradeApi 可提供兼容常见 SDK 的 API 接入方式，便于集中管理鉴权与用量。