让 Codex 像一个小团队一样工作，而不是在复杂任务里单线程硬扛。
这是一套轻量机制，不是万能提示词。它的目标是让 Codex 在接到任务时先判断复杂度，再决定是否需要子 agent，并且由主线程保持 Lead 职责：拆解、派工、回收、冲突裁决、最终整合。
这套机制参考了公开的 multi-agent / subagent 工程实践，但没有照搬任何一个大厂框架。我们保留了适合 Codex 日常项目协作的部分，例如 Lead + Worker、上下文隔离、并行探索、任务合同、派工/回收日志；也刻意没有采用重型图工作流、全自动多轮群聊、递归子代理、长期后台自治等机制。取舍说明见 REFERENCES.md。
- 多文件代码改动：探索、实现、测试、审查可以拆开。
- 资料研究：搜索、事实核验、观点整理、最终写作可以并行。
- 文档/知识库整理：原始材料提炼、结构化、质量检查可以分工。
- PR/CI 修复：日志分析、代码定位、测试验证可以分轨推进。
- 一句话解释。
- 简单命令。
- 单文件小修。
- 几分钟内主线程就能完成的事。
子 agent 不是越多越好。小任务硬开多线程，往往只会增加协调成本。
-
先判断任务复杂度
简单任务直接做；中等任务考虑 1 个辅助 agent；复杂任务再拆成 Lead + 多个 Worker。 -
主线程永远是 Lead
Lead 负责拆任务、派工、回收、冲突裁决、最终整合。子 agent 只做边界清楚的中间任务。 -
子 agent 只接收明确上下文
子 agent 可能不继承完整主线程历史，所以派工时要把必要的目标、文件路径、约束和已知决策写进任务卡。 -
每个子 agent 都要有任务合同
至少写清：角色、输入范围、预期输出、完成标准、文件所有权、禁止事项。 -
交付物要可追踪
子 agent 的大段结果优先交摘要和证据路径。只有 Lead 明确分配文件/目录所有权时，子 agent 才写入 artifact，避免把主线程上下文塞满或制造文件冲突。 -
每轮保留派工和回收
复杂任务至少回显：派工摘要、回收摘要、未回收项与缺口。 -
线程偏好要持续生效
如果用户在线程开头说过“使用多线程 / 子 agent / 并行”，后续同一线程默认持续按这个偏好评估，不需要每轮重复提醒。 -
防止假多 agent
检查是否真的有 agent id、是否有并行执行痕迹、是否有明确交付物、是否经过 Lead 整合。 -
防止失控 fan-out
默认从 1-3 个子 agent 开始。只有任务确实存在多个独立方向时，才扩大并行数量。
本线程启用多 agent 默认机制。
请你在每个非简单任务开始时先判断复杂度：
- 简单：主线程直接完成
- 中等：必要时派 1 个辅助 agent
- 复杂：使用 Lead + 子 agent 并行
如果任务适合子 agent，请先给出派工摘要：
- 哪些 agent 做什么
- 每个 agent 的输入范围和交付物
- 主线程自己负责什么
- 什么结果算完成
- 子 agent 需要知道哪些上下文、文件路径和禁止事项
回收时请给出：
- 哪些结果被采用
- 哪些结果被忽略
- 还有哪些缺口
- 下一步怎么做
主线程始终作为 Lead，负责最终判断和整合。不要把最终结论交给子 agent 直接决定。
不要让子 agent 继续派生子 agent，除非当前工具明确支持且用户明确要求。
任务名：
角色：
目标：
输入范围：
输出物：
完成标准：
文件/模块所有权：
禁止事项：
必须知道的上下文：
可写 artifact 路径：
遇到阻塞时：
任务：整理一个新技术主题，并输出一篇可读报告。
- Lead：定义问题边界、派工、最终写报告。
- Explorer：找权威来源和事实材料，只交来源清单和关键事实。
- Analyst：整理核心概念、利弊、适用场景。
- Reviewer：检查事实错误、逻辑跳跃、遗漏问题。
Lead 最后只吸收有证据的内容，统一写成最终版本。
- 一开始开太多 agent，结果管理成本超过收益。
- 子 agent 没有明确交付物，只是在聊天里泛泛回答。
- 主线程把多个 agent 的结果直接拼接，没有统一判断。
- 用户开头要求了多线程，但后续轮次忘记保持这个偏好。
- 跨线程切换时没有交接包，导致上下文漂移。
从这三个角色开始就够了：
- Lead：主线程，负责总控。
- Explorer：事实收集。
- Reviewer：质量检查。
等这个稳定后，再增加 Worker 或领域专家 agent。