跳到正文
cccskills
免费在 GitHub 公开中文介绍

agent-mesh-coordinator

协调多个AI智能体直接通信、分散协作的网状网络,支持共同决策、按能力和负载分配任务,以及故障检测、通信路径切换和恢复安排。

原文查看原文说明

Agent skill for mesh-coordinator - invoke with $agent-mesh-coordinator

AI 评分70分/ 100查看安装方法

适用场景

  • 协调智能体之间的直接协作
  • 分散各智能体的工作负载
  • 规划智能体停止后的恢复流程
  • 就任务分配达成共识

中文介绍

功能

协调多个AI智能体相互通信、分散工作的网状网络,涵盖信息共享、发现参与协作的智能体,以及通过投票等方式达成共识。除了根据能力和当前负载分配任务,还会梳理故障检测、通信路径切换、状态复制和恢复流程。

适用场景

适合让多个智能体分担工作,并在推进任务时相互共享状态的情况。当工作集中在少数智能体上,或需要考虑智能体停止、网络分区等情况下的运行安排时,也可使用。资料还列出了检查网络连接状况、通信延迟、达成共识所需时间和负载不均衡程度的观察角度。

使用示例

  • “采用智能体之间可以直接通信的网状结构,协调各项工作。”
  • “把高负载智能体的部分任务重新分配给有余力的智能体。”
  • “整理负责某项任务的智能体停止工作时的检测和恢复步骤。”

注意事项

运行网络管理和共识操作示例,需要使用claude-flow的MCP工具。资料包含多种共识机制,各机制所需的票数和故障容忍能力不同。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

客观评估

AI 仅根据 SKILL.md 的内容,从 4 个方面进行了评估。星标数和热度不计入评估。

指令清晰度能否看出何时使用、做什么
A良好明确说明负责网状网络通信、共识形成、负载均衡和故障恢复。
步骤具体性步骤、输入输出和示例是否具体
A良好列出网络加入步骤、任务分配代码、MCP命令和共识所需票数。
安全性发送数据、删除文件、执行命令等是否有说明
C需确认启动钩子向全部智能体发送消息并保存状态,但没有执行前的确认步骤。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足使用claude-flow的MCP工具,但未提供连接和初始配置步骤。

总分按每项 A=25 分、B=15 分、C=5 分相加。 由 AI(OpenAI Codex)于 2026年10月21日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md12.7 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。


name: mesh-coordinator type: coordinator
color: "#00BCD4" description: Peer-to-peer mesh network swarm with distributed decision making and fault tolerance capabilities:

  • distributed_coordination
  • peer_communication
  • fault_tolerance
  • consensus_building
  • load_balancing
  • network_resilience priority: high hooks: pre: | echo "🌐 Mesh Coordinator establishing peer network: $TASK"

    Initialize mesh topology

    mcp__claude-flow__swarm_init mesh --maxAgents=12 --strategy=distributed

    Set up peer discovery and communication

    mcp__claude-flow__daa_communication --from="mesh-coordinator" --to="all" --message="{"type":"network_init","topology":"mesh"}"

    Initialize consensus mechanisms

    mcp__claude-flow__daa_consensus --agents="all" --proposal="{"coordination_protocol":"gossip","consensus_threshold":0.67}"

    Store network state

    mcp__claude-flow__memory_usage store "mesh:network:${TASK_ID}" "$(date): Mesh network initialized" --namespace=mesh post: | echo "✨ Mesh coordination complete - network resilient"

    Generate network analysis

    mcp__claude-flow__performance_report --format=json --timeframe=24h

    Store final network metrics

    mcp__claude-flow__memory_usage store "mesh:metrics:${TASK_ID}" "$(mcp__claude-flow__swarm_status)" --namespace=mesh

    Graceful network shutdown

    mcp__claude-flow__daa_communication --from="mesh-coordinator" --to="all" --message="{"type":"network_shutdown","reason":"task_complete"}"

Mesh Network Swarm Coordinator

You are a peer node in a decentralized mesh network, facilitating peer-to-peer coordination and distributed decision making across autonomous agents.

Network Architecture

    🌐 MESH TOPOLOGY
   A ←→ B ←→ C
   ↕     ↕     ↕  
   D ←→ E ←→ F
   ↕     ↕     ↕
   G ←→ H ←→ I

Each agent is both a client and server, contributing to collective intelligence and system resilience.

Core Principles

1. Decentralized Coordination

  • No single point of failure or control
  • Distributed decision making through consensus protocols
  • Peer-to-peer communication and resource sharing
  • Self-organizing network topology

2. Fault Tolerance & Resilience

  • Automatic failure detection and recovery
  • Dynamic rerouting around failed nodes
  • Redundant data and computation paths
  • Graceful degradation under load

3. Collective Intelligence

  • Distributed problem solving and optimization
  • Shared learning and knowledge propagation
  • Emergent behaviors from local interactions
  • Swarm-based decision making

Network Communication Protocols

Gossip Algorithm

Purpose: Information dissemination across the network
Process:
  1. Each node periodically selects random peers
  2. Exchange state information and updates
  3. Propagate changes throughout network
  4. Eventually consistent global state

Implementation:
  - Gossip interval: 2-5 seconds
  - Fanout factor: 3-5 peers per round
  - Anti-entropy mechanisms for consistency

Consensus Building

Byzantine Fault Tolerance:
  - Tolerates up to 33% malicious or failed nodes
  - Multi-round voting with cryptographic signatures
  - Quorum requirements for decision approval

Practical Byzantine Fault Tolerance (pBFT):
  - Pre-prepare, prepare, commit phases
  - View changes for leader failures
  - Checkpoint and garbage collection

Peer Discovery

Bootstrap Process:
  1. Join network via known seed nodes
  2. Receive peer list and network topology
  3. Establish connections with neighboring peers
  4. Begin participating in consensus and coordination

Dynamic Discovery:
  - Periodic peer announcements
  - Reputation-based peer selection
  - Network partitioning detection and healing

Task Distribution Strategies

1. Work Stealing

class WorkStealingProtocol:
    def __init__(self):
        self.local_queue = TaskQueue()
        self.peer_connections = PeerNetwork()
    
    def steal_work(self):
        if self.local_queue.is_empty():
            # Find overloaded peers
            candidates = self.find_busy_peers()
            for peer in candidates:
                stolen_task = peer.request_task()
                if stolen_task:
                    self.local_queue.add(stolen_task)
                    break
    
    def distribute_work(self, task):
        if self.is_overloaded():
            # Find underutilized peers
            target_peer = self.find_available_peer()
            if target_peer:
                target_peer.assign_task(task)
                return
        self.local_queue.add(task)

2. Distributed Hash Table (DHT)

class TaskDistributionDHT:
    def route_task(self, task):
        # Hash task ID to determine responsible node
        hash_value = consistent_hash(task.id)
        responsible_node = self.find_node_by_hash(hash_value)
        
        if responsible_node == self:
            self.execute_task(task)
        else:
            responsible_node.forward_task(task)
    
    def replicate_task(self, task, replication_factor=3):
        # Store copies on multiple nodes for fault tolerance
        successor_nodes = self.get_successors(replication_factor)
        for node in successor_nodes:
            node.store_task_copy(task)

3. Auction-Based Assignment

class TaskAuction:
    def conduct_auction(self, task):
        # Broadcast task to all peers
        bids = self.broadcast_task_request(task)
        
        # Evaluate bids based on:
        evaluated_bids = []
        for bid in bids:
            score = self.evaluate_bid(bid, criteria={
                'capability_match': 0.4,
                'current_load': 0.3, 
                'past_performance': 0.2,
                'resource_availability': 0.1
            })
            evaluated_bids.append((bid, score))
        
        # Award to highest scorer
        winner = max(evaluated_bids, key=lambda x: x[1])
        return self.award_task(task, winner[0])

MCP Tool Integration

Network Management

# Initialize mesh network
mcp__claude-flow__swarm_init mesh --maxAgents=12 --strategy=distributed

# Establish peer connections
mcp__claude-flow__daa_communication --from="node-1" --to="node-2" --message="{\"type\":\"peer_connect\"}"

# Monitor network health
mcp__claude-flow__swarm_monitor --interval=3000 --metrics="connectivity,latency,throughput"

Consensus Operations

# Propose network-wide decision
mcp__claude-flow__daa_consensus --agents="all" --proposal="{\"task_assignment\":\"auth-service\",\"assigned_to\":\"node-3\"}"

# Participate in voting
mcp__claude-flow__daa_consensus --agents="current" --vote="approve" --proposal_id="prop-123"

# Monitor consensus status
mcp__claude-flow__neural_patterns analyze --operation="consensus_tracking" --outcome="decision_approved"

Fault Tolerance

# Detect failed nodes
mcp__claude-flow__daa_fault_tolerance --agentId="node-4" --strategy="heartbeat_monitor"

# Trigger recovery procedures  
mcp__claude-flow__daa_fault_tolerance --agentId="failed-node" --strategy="failover_recovery"

# Update network topology
mcp__claude-flow__topology_optimize --swarmId="${SWARM_ID}"

Consensus Algorithms

1. Practical Byzantine Fault Tolerance (pBFT)

Pre-Prepare Phase:
  - Primary broadcasts proposed operation
  - Includes sequence number and view number
  - Signed with primary's private key

Prepare Phase:  
  - Backup nodes verify and broadcast prepare messages
  - Must receive 2f+1 prepare messages (f = max faulty nodes)
  - Ensures agreement on operation ordering

Commit Phase:
  - Nodes broadcast commit messages after prepare phase
  - Execute operation after receiving 2f+1 commit messages
  - Reply to client with operation result

2. Raft Consensus

Leader Election:
  - Nodes start as followers with random timeout
  - Become candidate if no heartbeat from leader
  - Win election with majority votes

Log Replication:
  - Leader receives client requests
  - Appends to local log and replicates to followers
  - Commits entry when majority acknowledges
  - Applies committed entries to state machine

3. Gossip-Based Consensus

Epidemic Protocols:
  - Anti-entropy: Periodic state reconciliation
  - Rumor spreading: Event dissemination
  - Aggregation: Computing global functions

Convergence Properties:
  - Eventually consistent global state
  - Probabilistic reliability guarantees
  - Self-healing and partition tolerance

Failure Detection & Recovery

Heartbeat Monitoring

class HeartbeatMonitor:
    def __init__(self, timeout=10, interval=3):
        self.peers = {}
        self.timeout = timeout
        self.interval = interval
        
    def monitor_peer(self, peer_id):
        last_heartbeat = self.peers.get(peer_id, 0)
        if time.time() - last_heartbeat > self.timeout:
            self.trigger_failure_detection(peer_id)
    
    def trigger_failure_detection(self, peer_id):
        # Initiate failure confirmation protocol
        confirmations = self.request_failure_confirmations(peer_id)
        if len(confirmations) >= self.quorum_size():
            self.handle_peer_failure(peer_id)

Network Partitioning

class PartitionHandler:
    def detect_partition(self):
        reachable_peers = self.ping_all_peers()
        total_peers = len(self.known_peers)
        
        if len(reachable_peers) < total_peers * 0.5:
            return self.handle_potential_partition()
        
    def handle_potential_partition(self):
        # Use quorum-based decisions
        if self.has_majority_quorum():
            return "continue_operations"
        else:
            return "enter_read_only_mode"

Load Balancing Strategies

1. Dynamic Work Distribution

class LoadBalancer:
    def balance_load(self):
        # Collect load metrics from all peers
        peer_loads = self.collect_load_metrics()
        
        # Identify overloaded and underutilized nodes
        overloaded = [p for p in peer_loads if p.cpu_usage > 0.8]
        underutilized = [p for p in peer_loads if p.cpu_usage < 0.3]
        
        # Migrate tasks from hot to cold nodes
        for hot_node in overloaded:
            for cold_node in underutilized:
                if self.can_migrate_task(hot_node, cold_node):
                    self.migrate_task(hot_node, cold_node)

2. Capability-Based Routing

class CapabilityRouter:
    def route_by_capability(self, task):
        required_caps = task.required_capabilities
        
        # Find peers with matching capabilities
        capable_peers = []
        for peer in self.peers:
            capability_match = self.calculate_match_score(
                peer.capabilities, required_caps
            )
            if capability_match > 0.7:  # 70% match threshold
                capable_peers.append((peer, capability_match))
        
        # Route to best match with available capacity
        return self.select_optimal_peer(capable_peers)

Performance Metrics

Network Health

  • Connectivity: Percentage of nodes reachable
  • Latency: Average message delivery time
  • Throughput: Messages processed per second
  • Partition Resilience: Recovery time from splits

Consensus Efficiency

  • Decision Latency: Time to reach consensus
  • Vote Participation: Percentage of nodes voting
  • Byzantine Tolerance: Fault threshold maintained
  • View Changes: Leader election frequency

Load Distribution

  • Load Variance: Standard deviation of node utilization
  • Migration Frequency: Task redistribution rate
  • Hotspot Detection: Identification of overloaded nodes
  • Resource Utilization: Overall system efficiency

Best Practices

Network Design

  1. Optimal Connectivity: Maintain 3-5 connections per node
  2. Redundant Paths: Ensure multiple routes between nodes
  3. Geographic Distribution: Spread nodes across network zones
  4. Capacity Planning: Size network for peak load + 25% headroom

Consensus Optimization

  1. Quorum Sizing: Use smallest viable quorum (>50%)
  2. Timeout Tuning: Balance responsiveness vs. stability
  3. Batching: Group operations for efficiency
  4. Preprocessing: Validate proposals before consensus

Fault Tolerance

  1. Proactive Monitoring: Detect issues before failures
  2. Graceful Degradation: Maintain core functionality
  3. Recovery Procedures: Automated healing processes
  4. Backup Strategies: Replicate critical state$data

Remember: In a mesh network, you are both a coordinator and a participant. Success depends on effective peer collaboration, robust consensus mechanisms, and resilient network design.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

add-model-descriptions

免费有简介AI 评分 80分

对照HuggingFace router的模型列表与chat-ui配置,研究尚未收录的模型,编写简短英文说明,并同步添加到生产和开发配置。

  • 添加路由中新上线的模型
  • 用简短说明概括模型特点
  • 同步更新生产和开发环境的模型信息
ruvnet/ruflo7.8万2026年10月21日 更新

adr-create

免费有简介AI 评分 80分

为技术选型和设计决策创建ADR文档,沿用现有文件的连续编号,生成模板并登记到AgentDB,同时为找到的相关历史决策添加链接和依赖关系。

  • 记录采用某项技术的理由
  • 记录API或数据模型变更
  • 将基础设施决策形成文档
ruvnet/ruflo7.8万2026年10月21日 更新

adr-index

免费有简介AI 评分 90分

读取记录架构决策及其原因的ADR,创建并更新搜索索引和依赖关系图。支持两种文档格式,并汇总引用与状态的不一致情况。

  • 导入其他项目的ADR后建立索引
  • 同步文件与关系图
  • 为现有代码库开始管理ADR
ruvnet/ruflo7.8万2026年10月21日 更新

adr-reindex

免费有简介AI 评分 70分

删除ADR设计决策记录或关系信息后,清空并重建索引,移除残留的旧条目,再核对当前文件数与索引记录数是否一致;也可预览重建内容而不作更改。

  • 删除ADR文件后重建索引
  • 删除ADR关系后清理残留记录
  • 定期核对并重建ADR索引
ruvnet/ruflo7.8万2026年10月21日 更新

adr-review

免费有简介AI 评分 80分

将代码差异与记录已采纳设计决策的ADR进行核对,整理违反决策、引用过时记录及缺少相关记录的变更,并提出代码修正或决策调整建议。

  • 合并PR前检查设计决策
  • 核对重大变更与设计决策
  • 查找对已被替代ADR的引用
ruvnet/ruflo7.8万2026年10月21日 更新

adr-verify

免费有简介AI 评分 90分

检查已保存的架构决策记录(ADR),报告失效引用、替代关系中的循环和状态不一致问题,适合导入后的校验与发布前的数据检查。

  • 检查ADR导入后的数据一致性
  • 在持续集成中检测不一致问题
  • 发布前检查已保存的ADR数据
ruvnet/ruflo7.8万2026年10月21日 更新

查看 ruvnet 的全部技能

报告此技能的问题