ensemble-solving

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ensemble Problem Solving

集成式问题解决

Generate multiple solutions in parallel by spawning 3 subagents with different approaches, then evaluate and select the best result.

通过生成3个采用不同方案的子Agent并行工作，生成多种解决方案，再评估选出最佳结果。

When to Use

适用场景

Activation phrases:

"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..."

Good candidates:

Architecture decisions with trade-offs
Code generation with multiple valid implementations
API design with different philosophies
Naming, branding, documentation style
Refactoring strategies
Algorithm selection

Skip ensemble for:

Simple lookups or syntax questions
Single-cause bug fixes
File operations, git commands
Deterministic configuration changes
Tasks with one obvious solution

触发短语：

"给我提供...的可选方案"
"做...的最佳方式是什么"
"探索...的不同实现思路"
"我想看看...的备选方案"
"对比...的不同实现方案"
"我应该用哪种方案来..."

适合使用的场景：

需要权衡取舍的架构决策
存在多种可行实现的代码生成
遵循不同设计理念的API设计
命名、品牌设计、文档风格选择
重构策略制定
算法选型

不适用场景：

简单的信息查询或语法问题
单一诱因的bug修复
文件操作、git命令相关问题
确定性的配置变更
只有唯一明确解的任务

What It Does

功能说明

Analyzes the task to determine if ensemble approach is valuable
Generates 3 distinct prompts using appropriate diversification strategy
Spawns 3 parallel subagents to develop solutions independently
Evaluates all solutions using weighted criteria
Returns the best solution with explanation and alternatives summary

分析任务 判定是否适合采用集成式方案
生成3个差异化的prompt 采用合适的差异化策略
生成3个并行的子Agent 独立开发解决方案
评估所有方案 采用加权评估标准
返回最优方案 附带解释说明和备选方案概述

Approach

实现步骤

Step 1: Classify Task Type

第一步：划分任务类型

Determine which category fits:

Code Generation: Functions, classes, APIs, algorithms
Architecture/Design: System design, data models, patterns
Creative: Writing, naming, documentation

判断任务所属类别：

代码生成：函数、类、API、算法
架构/设计：系统设计、数据模型、设计模式
创意类：文案、命名、文档编写

Step 2: Invoke Ensemble Orchestrator

第二步：调用集成编排器

Task tool with:
- subagent_type: 'ensemble-orchestrator'
- description: 'Generate and evaluate 3 parallel solutions'
- prompt: [User's original task with full context]

The orchestrator handles:

Prompt diversification
Parallel execution
Solution evaluation
Winner selection

Task tool with:
- subagent_type: 'ensemble-orchestrator'
- description: 'Generate and evaluate 3 parallel solutions'
- prompt: [User's original task with full context]

编排器负责处理：

Prompt差异化
并行执行
方案评估
最优方案选择

Step 3: Present Result

第三步：输出结果

The orchestrator returns:

The winning solution (in full)
Evaluation scores for all 3 approaches
Why the winner was selected
When alternatives might be preferred

编排器返回内容包括：

完整的获胜方案
3种方案各自的评估得分
获胜方案的选择理由
备选方案的适用场景

Diversification Strategies

差异化策略

For Code (Constraint Variation):

Approach	Focus
Simplicity	Minimal code, maximum readability
Performance	Efficient, optimized
Extensibility	Clean abstractions, easy to extend

For Architecture (Approach Variation):

Approach	Focus
Top-down	Requirements → Interfaces → Implementation
Bottom-up	Primitives → Composition → Structure
Lateral	Analogies from other domains

For Creative (Persona Variation):

Approach	Focus
Expert	Technical precision, authoritative
Pragmatic	Ship-focused, practical
Innovative	Creative, unconventional

代码场景（约束差异化）：

方案	侧重点
极简优先	代码量最少，可读性最高
性能优先	高效、经过优化
扩展优先	抽象清晰，易于扩展

架构场景（思路差异化）：

方案	侧重点
自顶向下	需求 → 接口 → 实现
自底向上	基础组件 → 组合 → 结构
横向迁移	借鉴其他领域的同类方案

创意场景（角色差异化）：

方案	侧重点
专家视角	技术精准、权威可靠
务实视角	聚焦交付、实用性强
创新视角	创意性强、突破常规

Evaluation Rubric

评估规则

Criterion	Base Weight	Description
Correctness	30%	Solves the problem correctly
Completeness	20%	Addresses all requirements
Quality	20%	How well-crafted
Clarity	15%	How understandable
Elegance	15%	How simple/beautiful

Weights adjust based on task type.

评估项	基础权重	说明
正确性	30%	能正确解决问题
完整性	20%	覆盖所有需求点
质量	20%	实现的精良程度
清晰度	15%	易于理解的程度
优雅度	15%	简洁/优美的程度

权重会根据任务类型调整。

Example

示例

User: "What's the best way to implement a rate limiter?"

Skill:

Classifies as Code Generation
Invokes ensemble-orchestrator
Three approaches generated:
- Simple: Token bucket with in-memory counter
- Performance: Sliding window with atomic operations
- Extensible: Strategy pattern with pluggable backends
Evaluation selects extensible approach (score 8.4)
Returns full implementation with explanation

Output:

undefined

用户： "实现速率限制器的最佳方式是什么？"

技能执行流程：

归类为代码生成任务
调用集成编排器
生成三种方案：
- 极简方案：基于内存计数器的令牌桶实现
- 性能优先方案：基于原子操作的滑动窗口实现
- 扩展优先方案：支持可插拔后端的策略模式实现
评估后选择扩展优先方案（得分8.4）
返回完整实现代码和说明

输出：

undefined

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.

undefined

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.

undefined

Success Criteria

成功标准

3 genuinely different solutions generated
Clear evaluation rationale provided
Winner selected with confidence
Alternatives summarized with use cases
User understands trade-offs

生成3种真正差异化的解决方案
提供清晰的评估依据
有充分理由选出最优方案
总结备选方案的适用场景
用户能理解不同方案的权衡取舍

Token Cost

Token消耗

~4x overhead vs single attempt. Worth it for:

High-stakes architecture decisions
Creative work where first attempt rarely optimal
Learning scenarios where seeing alternatives is valuable
Code that will be maintained long-term

相比单次生成有大约4倍的开销，在以下场景值得使用：

高风险的架构决策
首次生成结果往往不够理想的创意类工作
了解备选方案很有价值的学习场景
需要长期维护的代码

Integration

集成适配

feature-planning: Can ensemble architecture decisions
code-auditor: Can ensemble analysis perspectives
plan-implementer: Executes the winning approach

feature-planning：可对架构决策做集成评估
code-auditor：可集成多种分析视角
plan-implementer：执行获胜的方案