子代理委派MOE编排器

要解决的具体问题

面对复杂开发任务时，单一 Agent 会遇到几个瓶颈：任务拆解不够专业导致遗漏关键依赖，技术选型靠猜测而非多视角论证，子代理声称"已完成"却根本没实现功能，以及多个并行改动在集成时互相冲突。

核心工作方式

这个技能将你定位为团队领导和 MOE 决策者，子代理则是各领域专家。

第一阶段：任务拆解

• 对代码项目先做深度探查（跑 3-5 个探查命令），了解技术栈、项目结构、数据库 schema
• 按专业域（后端/API、前端/UI、数据库、基础设施、测试、文档）拆解为互不冲突的子任务
• 输出 ASCII 依赖关系图，明确标注并行与串行关系
• 拆解粒度控制在 3-10 分钟工作量，每个子任务独立可验证

第二阶段：MOE 方案竞争

技术路线不确定时启动 MOE 模式：

• 为每个候选方案派一个专家子代理，互不知道其他专家存在（避免锚定效应）
• 专家只负责出方案，不执行实现
• Orchestrator 汇总所有方案后独立判断，综合出最优解

第三阶段：并行派工与审核

• 使用 delegate_task 按依赖关系分组并行派发
• 每个子代理必须返回：变更文件、验证命令、风险说明
• 审核时必须交叉验证：用 read_file 实际读取文件，用终端实际运行验证命令，用 search_files 确认关键函数存在
• 不符合要求直接打回返工

第四阶段：集成验证

• 合并所有变更，解决文件冲突
• 若修改了 init_db.py，必须执行 --force 重建数据库并跑 --verify
• 跑完整集成测试确保所有改动协同工作

适用边界与注意点

• MOE 不是万能的：方案已明确时（如 JWT 选 HS256），直接派工，不要为 MOE 而 MOE
• 并发限制：delegate_task 默认并发上限是 3，单轮超过 8 个子任务会失控
• 大文件处理：>100KB 的 HTML 文件不要并行派给多个子代理，参考 large-file-handling.md
• 验证命令上下文：有些函数依赖全局配置，直接在终端测试可能返回空结果，需要先调用 configure()