用途
Ensemble Solving 用于在同一个任务上并行生成多个不同的解决方案，再从中评估并选出最佳结果。它的核心流程是：先判断该任务是否值得采用集成式方法，然后生成 3 个差异化的提示，启动 3 个并行子代理各自独立求解，最后用加权标准对全部方案打分，返回胜出方案，并说明选择理由与备选方案。
触发它的典型说法包括："Give me options for..."、"What's the best way to..."、"Explore different approaches..."、"I want to see alternatives..."、"Compare approaches for..."、"Which approach should I use..."。
适合的场景包括：
- 存在取舍的架构决策
- 有多种可行实现的代码生成
- 设计理念不同的 API 设计
- 命名、品牌、文档风格
- 重构策略
- 算法选择
不适合的场景包括：
- 简单查询或语法问题
- 单一原因的缺陷修复
- 文件操作、git 命令
- 确定性的配置变更
- 只有唯一明显解法的任务
主要能力
该技能会分析任务，判断集成式方法是否有价值；使用相应的多样化策略生成 3 个不同提示；并行启动 3 个子代理独立开发方案；用加权标准评估所有方案；返回最佳方案，并附解释与备选方案摘要。
它在内部将任务分为三类：
- 代码生成：函数、类、API、算法
- 架构/设计：系统设计、数据模型、模式
- 创意：写作、命名、文档
使用方式
该技能通过 Task 工具调用集成编排器（ensemble-orchestrator），参数为：subagent_type 设置为 'ensemble-orchestrator'，description 为 'Generate and evaluate 3 parallel solutions'，prompt 为用户的原始任务与完整上下文。编排器负责提示多样化、并行执行、方案评估与优胜者选择。
多样化的策略按任务类型区分：
代码类采用约束变化：
- 简洁性：最少代码、最大可读性
- 性能：高效、经过优化
- 可扩展性：清晰抽象、易于扩展
架构类采用方法变化：
- 自顶向下：需求 → 接口 → 实现
- 自底向上：原语 → 组合 → 结构
- 横向：来自其他领域的类比
创意类采用人设变化：
- 专家：技术精确、权威
- 务实：以交付为导向、实用
- 创新：有创意、不拘一格
评估量表（基础权重）为：正确性 30%、完整性 20%、质量 20%、清晰度 15%、优雅度 15%，权重会随任务类型调整。
示例：用户提问"实现速率限制器的最佳方式是什么？"，该技能将其归类为代码生成，调用集成编排器，生成三种方案：简洁方案（带内存计数器的令牌桶）、性能方案（带原子操作的滑动窗口）、可扩展方案（带可插拔后端的策略模式），评估后选出可扩展方案（得分 8.4），并返回完整实现与解释，同时说明各备选方案的适用场景。
成功标准：生成 3 个真正不同的方案、给出清晰的评估理由、有把握地选出优胜者、给出带使用场景的备选摘要、让用户理解取舍。
适用场景与限制
它的开销约为单次尝试的 4 倍，因此更适合高风险架构决策、首次尝试往往非最优的创意工作、需要看到多种方案的学习场景，以及需要长期维护的代码。它可以与 feature-planning（集成架构决策）、code-auditor（集成分析视角）、plan-implementer（执行胜出方案）配合使用。官方文本未提供价格、平台支持范围等更多细节。