关于 ensemble-solving
ensemble-solving 是一项适用于需要比较多种方案的 Agent 技能。它让 3 个子 Agent 并行生成方案，按加权标准评估，并说明入选结果及其取舍。
主要功能
- 01判断任务是否适合多方案处理
- 02生成 3 个差异化提示词
- 03并行运行 3 个子 Agent
- 04评分并选出方案
- 05总结备选方案及取舍
适用场景
- 01比较软件架构方案
- 02评估不同代码实现
- 03探索命名或文档风格
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/ensemble-solving确认已加载。
附带文件references/diversification-strategies.mdreferences/evaluation-rubrics.md
详细介绍
集思广益解决问题
通过生成 3 个采用不同方法的子 Agent 并行提出多种方案，然后评估并选出最佳结果。
适用场景
触发短语：
- “给我一些……的选项”
- “……的最佳做法是什么？”
- “探索不同的方法……”
- “我想看看其他方案……”
- “比较……的不同方法”
- “我该采用哪种方法……”
适用场景：
- 存在权衡取舍的架构决策
- 有多种有效实现方式的代码生成
- 采用不同理念的 API 设计
- 命名、品牌塑造、文档风格
- 重构策略
- 算法选择
以下情况不适用：
- 简单查询或语法问题
- 单一原因导致的 Bug 修复
- 文件操作、Git 命令
- 确定性的配置更改
- 只有一种明显解决方案的任务
功能说明
- 分析任务，判断是否适合采用集思广益的方法
- 生成 3 个不同的提示词，采用适当的多样化策略
- 并行启动 3 个子 Agent，独立制定方案
- 使用加权标准评估所有方案
- 返回最佳方案，并说明原因、概述备选方案
方法
步骤 1：对任务分类
确定任务所属类别：
- 代码生成：函数、类、API、算法
- 架构/设计：系统设计、数据模型、模式
- 创意：写作、命名、文档
步骤 2：调用集思广益协调器
Task tool with:
- subagent_type: 'ensemble-orchestrator'
- description: 'Generate and evaluate 3 parallel solutions'
- prompt: [User's original task with full context]
协调器负责：
- 提示词多样化
- 并行执行
- 方案评估
- 选出最佳方案
步骤 3：呈现结果
协调器会返回：
- 获胜方案（完整内容）
- 所有 3 种方法的评估分数
- 选择获胜方案的原因
- 哪些情况下可能更适合采用其他方案
多样化策略
代码（约束变化）：
| 方法 | 侧重点 |
|---|---|
| 简洁 | 代码精简，最大限度提高可读性 |
| 性能 | 高效、经过优化 |
| 可扩展性 | 抽象清晰，便于扩展 |
架构（方法变化）：
| 方法 | 侧重点 |
|---|---|
| 自顶向下 | 需求 → 接口 → 实现 |
| 自底向上 | 基本元素 → 组合 → 结构 |
| 横向 | 借鉴其他领域的类比 |
创意（角色变化）：
| 方法 | 侧重点 |
|---|---|
| 专家 | 技术精准、权威 |
| 务实 | 以交付为导向、注重实用 |
| 创新 | 富有创意、不拘一格 |
评估标准
| 标准 | 基础权重 | 说明 |
|---|---|---|
| 正确性 | 30% | 正确解决问题 |
| 完整性 | 20% | 满足所有要求 |
| 质量 | 20% | 完成度如何 |
| 清晰度 | 15% | 易于理解的程度 |
| 优雅性 | 15% | 简洁/美观的程度 |
权重会根据任务类型调整。
示例
用户：“实现速率限制器的最佳做法是什么？”
技能：
- 将任务归类为代码生成
- 调用 ensemble-orchestrator
- 生成三种方案：
- 简单：使用内存计数器的令牌桶
- 高性能：使用原子操作的滑动窗口
- 可扩展：采用可插拔后端的策略模式
- 评估后选出可扩展方案（得分 8.4）
- 返回完整实现并附上说明
输出：
## Selected Solution
[Full rate limiter implementation with strategy pattern]
## Why This Solution Won
The extensible approach scored highest (8.4) because it provides
a clean abstraction that works for both simple use cases and
complex distributed scenarios. The strategy pattern allows
swapping Redis/Memcached backends without code changes.
## Alternatives
- **Simple approach**: Best if you just need basic in-memory
limiting and will never scale beyond one process.
- **Performance approach**: Best for high-throughput scenarios
where every microsecond matters.
成功标准
- 生成 3 个真正不同的方案
- 提供清晰的评估依据
- 有把握地选出最佳方案
- 概述备选方案及其适用场景
- 让用户理解各种权衡取舍
Token 成本
与单次尝试相比，开销约为 4 倍。适用于：
- 影响重大的架构决策
- 首次尝试往往并非最优的创意工作
- 能从查看备选方案中受益的学习场景
- 将长期维护的代码
集成
- feature-planning：可对架构决策采用集思广益
- code-auditor：可从多个角度进行分析
- plan-implementer：执行获胜方案
评论
支持 Markdown