consensus-voting

共识投票技能

共识投票技能 - 实现投票协议和冲突解决算法，以便在多个可能意见相左的 Agent 之间达成共识。 - 收集多个 Agent 的投票 - 根据专业知识进行加权投票 - 检测并解决冲突 - 验证法定人数 - 记录决策

第 1 步：定义投票参数

设置投票会话：

voting_session:
  topic: 'Which database to use for the new service'
  options:
    - PostgreSQL
    - MongoDB
    - DynamoDB
  quorum: 3 # Minimum votes required
  threshold: 0.6 # 60% agreement needed
  weights:
    database-architect: 2.0 # Expert gets 2x weight
    security-architect: 1.0
    devops: 1.5

第 2 步：收集投票

收集 Agent 的建议：

## Vote Collection

### database-architect (weight: 2.0)

- Vote: PostgreSQL
- Rationale: Strong ACID guarantees, mature ecosystem
- Confidence: 0.9

### security-architect (weight: 1.0)

- Vote: PostgreSQL
- Rationale: Better encryption at rest, audit logging
- Confidence: 0.8

### devops (weight: 1.5)

- Vote: DynamoDB
- Rationale: Managed service, auto-scaling
- Confidence: 0.7

第 3 步：计算共识

应用加权投票：

PostgreSQL: (2.0 * 0.9) + (1.0 * 0.8) = 2.6
DynamoDB:   (1.5 * 0.7) = 1.05
MongoDB:    0

Total weight: 4.5
PostgreSQL: 2.6 / 4.5 = 57.8%
DynamoDB:   1.05 / 4.5 = 23.3%

Threshold: 60% → No clear consensus

第 4 步：解决冲突

未能达成共识时：

策略 1：专家覆盖

• 如果领域专家持有强烈意见（置信度 >0.8），则听从专家意见

策略 2：讨论轮次

• 要求持异议的 Agent 回应多数方的论据
• 讨论后重新投票

策略 3：升级处理

• 向用户列出各个 Agent 提出的选项及其优缺点
• 由用户做出最终决定

第 5 步：记录决策

记录最终决定：

## Decision Record

### Topic

Which database to use for the new service

### Decision

PostgreSQL

### Voting Summary

- PostgreSQL: 57.8% (2 votes)
- DynamoDB: 23.3% (1 vote)
- Consensus: NOT REACHED (below 60% threshold)

### Resolution Method

Expert override - database-architect (domain expert)
had 0.9 confidence in PostgreSQL

### Dissenting Opinion

DevOps preferred DynamoDB for operational simplicity.
Mitigation: Will use managed PostgreSQL (RDS) to
reduce operational burden.

### Decision Date

2026-01-23

</execution_process>

<best_practices>

1. 必须达到法定人数：参与人数未达到最低要求时，不要做出决定
2. 按专业知识加权：赋予领域专家更大的影响力
3. 记录异议：记录少数意见以供日后参考
4. 明确阈值：预先定义构成共识的条件
5. 升级路径：为尚未解决的冲突制定处理流程

</best_practices>

**冲突解决请求**：

The architect wants microservices but the developer prefers monolith.
Resolve this conflict.

投票流程：

## Voting: Architecture Style

### Votes

- architect: Microservices (weight 1.5, confidence 0.8)
- developer: Monolith (weight 1.0, confidence 0.9)
- devops: Microservices (weight 1.0, confidence 0.6)

### Calculation

Microservices: (1.5 _ 0.8) + (1.0 _ 0.6) = 1.8
Monolith: (1.0 \* 0.9) = 0.9

Microservices: 66.7% → CONSENSUS REACHED

### Decision

Microservices, with modular monolith as migration path

### Dissent Mitigation

Start with modular monolith, extract services incrementally
to address developer's maintainability concerns.

</usage_example>

双重完成门控协议

通过要求至少 2 个 Agent 独立确认任务已完成后才能关闭会话，防止议会或多 Agent 任务过早结束。

问题

单个 Agent 发出“完成”信号可能导致结果不完整——该 Agent 可能只完成了自己的子任务，而整体任务尚未完成。双重完成门控要求对任务是否完成本身达成共识。

协议

1. 按 Agent 跟踪完成信号：{ agent_id, timestamp, signal: "complete" }
2. 要求在 window_seconds 时间窗口内收到 min_completions 个信号（默认值：2；默认窗口：60s）
3. 如果只有 1 个 Agent 发出完成信号，则在 nudge_after_seconds 后向其余 Agent 发送“验证提醒”（默认值：30s）
4. 如果经过 fallback_timeout 后仍只有 1 个完成信号，则接受单 Agent 完成，并设置 warning: "single_agent_completion" 标记（默认值：120s）

配置

completion_gate:
  min_completions: 2 # minimum agents that must signal done
  window_seconds: 60 # time window for completion consensus
  nudge_after_seconds: 30 # send nudge to remaining agents after first completion
  fallback_timeout: 120 # accept single completion after this timeout (with warning)

伪代码

completions = []

on_agent_complete(agent_id):
  completions.push({ agent_id, timestamp: now() })

  if completions.length >= min_completions:
    window_start = completions[0].timestamp
    window_end = completions[-1].timestamp
    if (window_end - window_start) <= window_seconds:
      return CLOSE_SESSION(status: "consensus_complete")

  if completions.length == 1:
    schedule_nudge(nudge_after_seconds)
    schedule_fallback(fallback_timeout)

on_nudge_timeout():
  send_to_remaining_agents("A team member has signaled completion. Please confirm if the task is done.")

on_fallback_timeout():
  if completions.length < min_completions:
    return CLOSE_SESSION(status: "single_agent_complete", warning: "single_agent_completion")

与 LLM Council 集成

关闭议会会话前，llm-council 技能会调用双重完成门控：

1. 第 3 阶段综合后，向每个模型询问：“这份综合结果是否完整且准确？”
2. 模型回复“complete”或“needs_revision”
3. 门控要求收到 min_completions 个“complete”信号后才能关闭
4. 如果门控未通过（完成信号不足），则由主席审查并做出决定

投票协议表更新

协议	使用场景	阈值	法定人数
简单多数	常规决策	>50%	50%
超级多数	重大变更	>=66%	75%
一致同意	关键／不可逆决策	100%	100%
加权投票	需要专业知识	可变	66%
排序选择	多个备选方案	决选	75%
双重完成	议会任务结束	2 个 Agent 确认	100%

规则

• 决策前始终要求达到法定人数
• 根据领域专业知识为投票赋予权重
• 记录不同意见，以供日后参考
• 结束 council 会话前，必须获得双 Agent 完成共识

相关工作流

此技能有一个用于复杂多 Agent 场景的对应工作流：

• 工作流：.claude/workflows/consensus-voting-skill-workflow.md
• 何时使用工作流：对于需要通过 Queen/Worker 拓扑实现拜占庭容错共识的关键多 Agent 决策（架构决策、安全审查、技术选型）
• 何时直接使用技能：对于简单投票场景，或需要将共识整合到其他工作流中时

工作流集成

此技能支持多 Agent 编排中的决策：

路由器决策： .claude/workflows/core/router-decision.md

• 路由器会启动多位审查者，然后通过共识解决冲突
• 规划编排矩阵会在审查阶段触发共识投票

制品生命周期： .claude/workflows/core/skill-lifecycle.md

• 共识投票决定制品弃用事宜
• 多位维护者对破坏性变更进行投票

相关工作流：

• swarm-coordination 技能，用于投票前并行启动 Agent
• 企业工作流使用共识进行设计审查
• .claude/workflows/enterprise/ 中的安全审查要求安全架构师达成共识

---

铁律

1. 绝不接受未达到最低法定人数的决策 — 未达到法定人数作出的决策不具正当性；如果未达到法定人数，应推迟决策或升级至人工介入。
2. 始终根据领域专业知识为投票赋予权重 — 权重相同会让通才开发者与领域专家拥有同等影响力；应根据专业知识与决策领域的相关性赋予权重。
3. 绝不丢弃不同意见 — 少数观点包含有关边缘情况和风险的关键信号；记录所有理由，包括落败一方的理由。
4. 升级前始终要求经过审议后重新投票 — 未经审议的分歧投票浪费了共识机制；升级至人工介入前，Agent 必须分享推理并再次投票。
5. 关键决策中绝不允许弃权 — 在高风险决策中弃权意味着 Agent 在逃避责任；所有参与者都必须对 CRITICAL/UNANIMOUS 阈值决策投票。

反模式

反模式	失败原因	正确做法
不要求达到法定人数	小团体替所有人作决定；共识不具正当性	针对不同决策类型设定最低参与门槛
对所有 Agent 赋予相同权重	忽略领域专业知识；降低信号质量	根据领域专业知识的相关性赋予权重（范围为 1.0–2.0）
丢弃不同意见的理由	丧失对边缘情况的认知和风险信号	记录所有投票及其理由，包括多数和少数意见
分歧投票后立即升级	跳过了可能解决分歧的审议	升级至人工介入前，必须先审议并重新投票
关键决策中允许弃权	Agent 逃避艰难决策的问责	CRITICAL 决策要求所有符合资格的投票者参与

记忆协议（强制）

开始前：

cat .claude/context/memory/learnings.md

完成后：

• 新模式 -> .claude/context/memory/learnings.md
• 发现问题 -> .claude/context/memory/issues.md
• 作出决策 -> .claude/context/memory/decisions.md

假定会发生中断：你的上下文可能会重置。如果内容未记录在记忆中，就等于没有发生。