consensus-voting

共识投票技能

目的

针对需要领域专业知识的关键决策，执行加权多 Agent 投票。与辩论（协作综合）或 n-version（并行生成）不同，此技能专注于在安全、身份验证和数据处理变更中进行基于专业能力加权的结构化投票。

模式分析中的关键见解

摘自 ~/.amplihack/.claude/context/DISCOVERIES.md（模式适用性分析）：

投票与专家判断的选择标准

适合投票的情况：

• 对抗性环境（无法信任单个节点）
• 二元或简单的离散选项
• 没有可用的客观质量指标
• 共识比正确性更重要

适合专家判断的情况：

• 协作环境（参与者诚实）
• 质量维度复杂
• 存在客观评估标准
• 正确性比共识更重要

此技能会有策略地同时使用两者：由专家判断进行评估，再通过加权投票做出决策。

何时使用此技能

自动触发（高风险领域）：

• 安全实现（身份验证、授权）
• 加密和密码学代码
• 敏感数据处理（个人身份信息、凭据）
• 权限和访问控制变更
• 关键算法实现

显式触发：

• 存在多种竞争方案的重大设计决策
• 需要获得利益相关方支持时
• 需要验证的二元或离散选项
• 用于降低生产代码风险的决策

避免用于：

• 复杂的权衡分析（改用 debate-workflow）
• 代码生成（改用 n-version-workflow）
• 简单的实现选择
• 主观质量评估

配置

投票配置

投票模式：

• simple-majority - 50% 及以上的票数通过
• supermajority - 66% 及以上的票数通过（安全领域的默认模式）
• unanimous - 必须达成 100% 一致

Agent 选择：

• auto - 根据检测到的领域选择 Agent（默认）
• manual - 显式指定 Agent
• comprehensive - 由所有相关 Agent 投票

权重校准：

• static - 按领域设置固定权重（默认）

领域专业能力权重

Agent	安全	身份验证	数据	算法	通用
security	3.0	2.5	2.5	1.5	1.0
reviewer	1.5	1.5	1.5	2.0	2.0
architect	1.5	2.0	2.0	2.5	2.0
tester	1.0	1.5	1.5	2.0	1.5
optimizer	0.5	0.5	0.5	2.5	1.0
cleanup	0.5	0.5	0.5	1.0	1.5

权重说明：

• 3.0 = 领域专家（票数计为 3 倍）
• 2.0 = 专业能力突出（票数计为 2 倍）
• 1.0 = 一般胜任（标准票）
• 0.5 = 相关性较低（半票）

执行流程

第 1 步：检测决策领域

分析变更或决策，确定主要领域：

• 使用分析器 Agent 检查代码或提案
• 检测关键词：auth、encrypt、password、token、permission、credential
• 识别文件路径：auth/、security/、crypto/
• 分类：SECURITY | AUTH | DATA | ALGORITHM | GENERAL

领域检测触发条件：

SECURITY: encrypt, decrypt, hash, salt, vulnerability, CVE, injection
AUTH: login, logout, session, token, jwt, oauth, password, credential
DATA: pii, gdpr, sensitive, personal, private, secret, key
ALGORITHM: sort, search, calculate, compute, process, transform

第 2 步：选择投票 Agent

根据检测到的领域，选择相关 Agent 并设置权重：

对于 SECURITY 领域：

• security Agent（权重：3.0）——主要专家
• architect Agent（权重：1.5）——系统设计视角
• reviewer Agent（权重：1.5）——代码质量检查
• tester Agent（权重：1.0）——可测试性评估

对于 AUTH 领域：

• security Agent（权重：2.5）——安全影响
• architect Agent（权重：2.0）——集成模式
• reviewer Agent（权重：1.5）——实现质量
• tester Agent（权重：1.5）——身份验证流程测试

对于 DATA 领域：

• security Agent（权重：2.5）——数据保护
• architect Agent（权重：2.0）——数据架构
• reviewer Agent（权重：1.5）——处理模式
• tester Agent（权重：1.5）——数据验证

对于 ALGORITHM 领域：

• optimizer Agent（权重：2.5）——性能分析
• architect Agent（权重：2.5）——设计模式
• tester Agent（权重：2.0）——正确性测试
• reviewer Agent（权重：2.0）——代码质量

第 3 步：向 Agent 呈现决策

每个选定的 Agent 会收到：

• 清晰的决策陈述
• 可选项（如适用）
• 相关背景和限制
• 评估标准

决策提示词模板：

## Decision Required: [TITLE]

**Domain:** [SECURITY | AUTH | DATA | ALGORITHM]
**Your Weight:** [X.X] (based on domain expertise)

### Context

[Relevant background and constraints]

### Options

1. [Option A]: [Description]
2. [Option B]: [Description]
3. [Reject Both]: Propose alternative

### Evaluation Criteria

- Security implications
- Implementation complexity
- Maintainability
- Risk assessment

### Your Vote

Provide:

1. Your vote (Option 1, 2, or Reject)
2. Confidence level (HIGH, MEDIUM, LOW)
3. Key reasoning (2-3 sentences max)
4. Any conditions or caveats

第 4 步：收集投票

为每个 Agent 收集结构化投票：

agent: security
weight: 3.0
vote: Option 1
confidence: HIGH
reasoning: "Option 1 follows OWASP best practices for credential storage. Option 2 uses deprecated hashing algorithm."
conditions: ["Ensure salt length >= 16 bytes", "Use constant-time comparison"]

第 5 步：计算加权结果

加权投票计算：

For each option:
  weighted_score = sum(agent_weight * confidence_multiplier)

Where confidence_multiplier:
  HIGH = 1.0
  MEDIUM = 0.7
  LOW = 0.4

计算示例：

Agent	权重	投票	信心度	得分
security	3.0	A	HIGH	3.0
architect	1.5	A	MEDIUM	1.05
reviewer	1.5	B	HIGH	1.5
tester	1.0	A	LOW	0.4

Option A Score: 3.0 + 1.05 + 0.4 = 4.45
Option B Score: 1.5
Total Weighted Votes: 5.95
Option A Percentage: 74.8% (SUPERMAJORITY)

第 6 步：应用投票门槛

根据配置的投票模式：

simple-majority（50%+）：

• 如果某选项的加权得分 > 50%，则该选项获胜
• 如果没有选项 > 50%，则进入辩论或拒绝

supermajority（66%+）：（默认用于安全领域）

• 获胜选项必须获得 > 66% 的加权投票
• 为高风险决策提供更严格的验证

unanimous（100%）：

• 所有 Agent 必须达成一致（少见，门槛最高）
• 任何异议都会阻止决策

第 7 步：报告共识结果

如果达成共识：

## Consensus Voting Result

**Decision:** [Selected Option]
**Domain:** SECURITY
**Threshold:** Supermajority (66%+)
**Result:** PASSED (74.8%)

### Vote Summary

| Agent     | Weight | Vote | Confidence |
| --------- | ------ | ---- | ---------- |
| security  | 3.0    | A    | HIGH       |
| architect | 1.5    | A    | MEDIUM     |
| reviewer  | 1.5    | B    | HIGH       |
| tester    | 1.0    | A    | LOW        |

### Key Reasoning (from highest-weighted agents)

- **security (3.0):** "Option 1 follows OWASP best practices..."

### Conditions/Caveats

- Ensure salt length >= 16 bytes
- Use constant-time comparison

### Dissenting View

- **reviewer (1.5):** "Option B has simpler implementation..."

如果未达成共识：

## Consensus Voting Result

**Decision:** NO CONSENSUS
**Domain:** AUTH
**Threshold:** Supermajority (66%+)
**Result:** FAILED (52.3%)

### Recommendation

- Escalate to `/amplihack:debate` for structured trade-off analysis
- OR: Gather more information and re-vote
- OR: Accept simple majority with documented risk

第 8 步：记录决策

• 将投票结果记录到会话决策中
• 记录投票理由以供日后参考

权衡

优点：

• 为高风险领域提供结构化决策
• 适当赋予领域专业知识相应权重
• 提供清晰、包含理由的审计线索
• 对于二元／离散选项，比完整辩论更快

成本：

• 不如辩论细致（无法综合意见）
• 需要明确选项（非生成式）
• 权重校准需要真实数据
• 可能错过有创意的替代方案

**适用场景：**决策选项明确、领域专业知识很重要且需要审计线索时

示例

示例 1：密码哈希实现

**背景：**为新的身份验证系统在 bcrypt、argon2id 和 PBKDF2 之间进行选择

**领域检测：**AUTH（密码、哈希）

选定的 Agent：

• security（2.5）、architect（2.0）、reviewer（1.5）、tester（1.5）

投票：

• security：argon2id（HIGH）——“OWASP 当前推荐方案，抗内存攻击”
• architect：argon2id（MEDIUM）——“库支持良好，设计现代”
• reviewer：bcrypt（HIGH）——“在生产环境中经过了更多实战检验”
• tester：argon2id（MEDIUM）——“参数可配置，易于测试”

**结果：**argon2id 以 68.2% 获胜（通过绝对多数门槛）

示例 2：API 速率限制方案

背景： 令牌桶、滑动窗口与固定窗口的对比

领域检测： SECURITY（速率限制、防护）

选定的 Agent：

• security（3.0）、optimizer（1.5）、architect（1.5）、reviewer（1.5）

投票：

• security：令牌桶（HIGH）——“最能防御突发攻击”
• optimizer：滑动窗口（MEDIUM）——“资源利用率更高”
• architect：令牌桶（MEDIUM）——“行业标准，广为人知”
• reviewer：滑动窗口（LOW）——“实现更简单”

结果： 令牌桶以 69.4% 获胜（通过绝大多数表决）

示例 3：未达成共识

背景： 为新功能选择微服务还是单体架构

领域检测： ALGORITHM（通用架构）

选定的 Agent：

• architect（2.5）、optimizer（2.5）、reviewer（2.0）、tester（2.0）

投票：

• architect：微服务（MEDIUM）——“长期扩展性更好”
• optimizer：单体架构（HIGH）——“运维更简单，开销更少”
• reviewer：单体架构（MEDIUM）——“初期更容易维护”
• tester：微服务（LOW）——“测试更困难，但隔离性更好”

结果： 未达成共识（52.1%）——升级至 /amplihack:debate

与其他工作流集成

移交给辩论工作流

投票未能达成共识时：

1. 记录投票结果和理由
2. 使用投票背景调用 Skill(debate-workflow)
3. 利用投票洞见来确定辩论的不同视角

N 版本实现后

使用共识投票从 N 版本实现中选出一个：

1. N 版本生成 3 个或更多实现
2. 通过共识投票选出胜者
3. 领域专家对选择拥有加权影响力

与理念保持一致

此技能确保：

• 基于证据的决策： 投票必须附带理由
• 领域专业知识： 权重体现专业能力
• 权衡透明： 记录异议
• 审计追踪： 保留完整投票记录
• 适当的严谨性： 对高风险领域自动触发