ruflo 蜂群思维 Worker Specialist基于 memory coordination 的 swarm 任务执行专员完整实战指南【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo导读Worker Specialist工作专员是 ruflo原 Claude FlowHive Mind 蜂群体系中的专职任务执行角色它不负责决策、不做侦察而是以接受指令—汇报进度—交付结果为唯一主线通过memory_usage记忆协调通道与 Queen Coordinator、其他 Worker 保持实时同步。本文以 .claude/agents/hive-mind/worker-specialist.md 为骨架结合同目录下 Queen/Scout/Memory Manager 等角色定义与.claude/commands/hive-mind/命令族系统讲解 Worker 的职责协议、状态汇报 schema、依赖管理、并行协作模式并给出可复制到真实多智能体任务中的配置与执行范式。读完你将能独立编写一个守纪律、可观测、可考核的 swarm Worker 智能体并将其接入 ruflo 的 memory 命名空间体系。Worker Specialist 在蜂群架构中的定位ruflo 的 Hive Mind 是一套分层级的多智能体协调体系。在.claude/agents/hive-mind/目录下共定义了五个相互协作的蜂群角色Worker 是其中最接地气的执行层角色定义文件定位Queen Coordinatorqueen-coordinator.md蜂群最高指挥分配资源、下发 directiveCollective Intelligencecollective-intelligence-coordinator.md复杂决策与知识整合顾问Swarm Memory Managerswarm-memory-manager.md记忆命名空间、缓存与同步Scout Explorerscout-explorer.md信息采集与环境侦察Worker Specialistworker-specialist.md任务执行专员本文主角文档开篇对 Worker 的身份定义非常明确You are a Worker Specialist, the dedicated executor of the hive minds will.——即蜂群意志的执行器。它的核心约束是不自主决策、不越权行动一切行为以 Queen 的分配任务为边界一切沟通通过namespace: coordination的记忆通道进行。说明同一角色在plugin/agents/hive-mind/worker-specialist.md目录下存在镜像副本两者内容一致均是同一份角色契约在不同加载路径下的部署。记忆协调通道Worker 与蜂群沟通的唯一语言Worker 所有状态上报都通过mcp__claude-flow__memory_usage这一 MCP 工具完成。在 ruflo 的命令层该工具对应 memory-usage 命令底层支持的动作与参数为--action typestore / retrieve / list / clear--key key记忆键名--value data要写入的 JSON 数据通过命令行等价形式可完成同样的读写例如# 等价于 Worker 的 store 动作 npx claude-flow memory usage --action store --key swarm/worker-1/status --value {status:task-received} # 等价于 Worker 的 retrieve 动作启动前检查依赖 npx claude-flow memory usage --action retrieve --key swarm/shared/dependencies # 查看当前 coordination 命名空间下已有哪些键 npx claude-flow memory usage --action listWorker 约定使用namespace: coordination作为统一命名空间并遵循swarm/worker-[ID]/状态类型的键命名规范。从源码结构可以推断这套命名空间与键值规范让 Queen读取swarm/worker-*/status做合规检查、Memory Manager按coordination命名空间做索引与缓存、其他 Worker读取swarm/shared/*共享进度都能以键前缀 动作的方式对蜂群状态进行可预测的轮询与同步这正是通过记忆协调保持持续通信的落地机制。任务执行协议三段式强制状态汇报Worker 的纪律核心是在任务前、任务中、任务后都必须写状态原文标注 MANDATORY。这并非可选项而是整个蜂群可观测性的根基。START接受任务分配收到 Queen 的 directive 后Worker 立即写入swarm/worker-[ID]/status// START - Accept task assignment mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/status, namespace: coordination, value: JSON.stringify({ agent: worker-[ID], status: task-received, assigned_task: specific task description, estimated_completion: Date.now() 3600000, dependencies: [], timestamp: Date.now() }) }该 schema 字段的实际作用agent/status标识是谁、处于什么状态供 Queen 的 hive-health 监控按agent_compliance清单比对见 queen-coordinator.mdassigned_task任务描述明确边界estimated_completion预估完成时间点示例为Date.now() 3600000即预估 1 小时后完成供 Queen 判断是否存在拖延dependencies预先声明依赖后续与依赖检查呼应timestamp统一使用Date.now()时间戳便于向量时钟/版本对比Memory Manager 同样依赖时间戳做 version 写入。PROGRESS每个关键步骤更新// PROGRESS - Update every significant step mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/progress, namespace: coordination, value: JSON.stringify({ task: current task, steps_completed: [step1, step2], current_step: step3, progress_percentage: 60, blockers: [], files_modified: [file1.js, file2.js] }) }其中progress_percentage给出 0–100 的量化进度steps_completed记录已完成步骤栈files_modified记录实际改动文件——这保证了即使 Worker 会话中断接手的 Worker 也能从记忆里恢复现场对应.claude/commands/hive-mind/hive-mind-resume.md提供的会话恢复能力。质量规范中要求每 30–60 秒写一次状态即任务推进时保持至少分钟级的可见性。按专长拆分的四类 WorkerWorker 不是同质化的执行者。文档给出了三类典型专长每种专长向swarm/shared/共享区写入不同结构的交付物供后续 Worker 与 Queen 直接消费。Code Implementation Worker共享实现细节// Share implementation details mcp__claude-flow__memory_usage { action: store, key: swarm/shared/implementation-[feature], namespace: coordination, value: JSON.stringify({ type: code, language: javascript, files_created: [src/feature.js], functions_added: [processData(), validateInput()], tests_written: [feature.test.js], created_by: worker-code-1 }) }关注点在于可追踪性写明了创建文件、新增函数、配套测试与创建者 ID。后续任何 Worker 接续该 feature 时可通过retrieve该键获取完整实现清单避免重复造轮子或产生文件冲突。Analysis Worker共享分析结论// Share analysis results mcp__claude-flow__memory_usage { action: store, key: swarm/shared/analysis-[topic], namespace: coordination, value: JSON.stringify({ type: analysis, findings: [finding1, finding2], recommendations: [rec1, rec2], data_sources: [source1, source2], confidence_level: 0.85, created_by: worker-analyst-1 }) }Analysis Worker 的产出包含confidence_level置信度这一关键元数据——它让下游消费者如 Collective Intelligence 的加权投票决策可以对每条分析做可信度加权而非把信息当事实全盘接收。Testing Worker共享测试结果// Report test results mcp__claude-flow__memory_usage { action: store, key: swarm/shared/test-results, namespace: coordination, value: JSON.stringify({ type: testing, tests_run: 45, tests_passed: 43, tests_failed: 2, coverage: 87%, failure_details: [test1: timeout, test2: assertion failed], created_by: worker-test-1 }) }测试 Worker 的汇报把数字统计与失败明细分离tests_run/passed/failed/coverage供 Queen 快速评估质量门槛failure_details提供可定位到具体用例如 timeout、assertion failed的原始信息便于修复型 Worker 直接按单处理。值得注意的是三类 Worker 共享同一把键swarm/shared/...但靠type字段区分——这体现了一种约定共享区按主题分键、按类型分内容既保证路由确定性又保证同一主题可被多类 Worker 协同写入。依赖管理开工前必查被阻塞即上报Worker 被明确禁止在依赖未就绪时盲目开工。文档给出标准的依赖检查流程// CHECK dependencies before starting const deps await mcp__claude-flow__memory_usage { action: retrieve, key: swarm/shared/dependencies, namespace: coordination } if (!deps.found || !deps.value.ready) { // REPORT blocking mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/blocked, namespace: coordination, value: JSON.stringify({ blocked_on: dependencies, waiting_for: [component-x, api-y], since: Date.now() }) } }这段逻辑包含两个关键设计读取结果的双重判断同时检查deps.found键是否存在与deps.value.ready依赖是否就绪避免把空结果误判为依赖齐备阻塞状态显式化一旦发现依赖缺失立即写swarm/worker-[ID]/blocked键并声明waiting_for。这样 Queen 的 swarm-health 轮询能立刻发现僵局并重新调度例如调派其他 Worker 先完成component-x而不是让 Worker 空转等待。与之呼应Worker 的 Dont 清单明确包含 Ignore dependency checks不得跳过依赖检查与 Start work without assignment不得无指令开工从正反两面锁死自主性边界。结果交付complete 状态的结构化产出任务收尾时 Worker 写入swarm/worker-[ID]/complete这是 Queen 判断任务闭环与考核 Worker 绩效的依据// COMPLETE - Deliver results mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/complete, namespace: coordination, value: JSON.stringify({ status: complete, task: assigned task, deliverables: { files: [file1, file2], documentation: docs/feature.md, test_results: all passing, performance_metrics: {} }, time_taken_ms: 3600000, resources_used: { memory_mb: 256, cpu_percentage: 45 } }) }deliverables 区分了四种产出类型files交付文件、documentation配套文档示例约定写入 docs/、test_results质量凭证、performance_metrics性能指标可按需留空。同时补报time_taken_ms与resources_used内存/CPU这两项直接喂给 Worker 自身的 Performance Metrics 统计见下文供蜂群做资源配额核算与效率画像。三种工作模式串行 / 并行 / 应急Sequential Execution串行执行这是 Worker 的默认模式严格五步走从 Queen/Coordinator 接收任务验证依赖可用对应上文 Dependency Management按顺序执行任务步骤在每一步汇报进度对应 PROGRESS 上报交付结果对应 complete 上报。Parallel Collaboration并行协作当多个 Worker 处理同一目标时检查是否有同级 Worker 在做相同任务通过读取swarm/worker-*/progress或共享区键判断按各自能力划分工作如 Code Worker 实现、Testing Worker 验证、Analysis Worker 评估通过记忆同步进度各自写 progress并消费对方写入的swarm/shared/implementation-*完成时合并结果。这种模式依赖上一节的专长分工——能力划分 共享区写入正是并行不冲突的前提。实际落地时可用.claude/commands/hive-mind/hive-mind-spawn.md指定 swarm 规模与 Queen 类型npx claude-flow hive-mind spawn Build API --max-workers 4 npx claude-flow hive-mind spawn Research patterns --queen-type adaptive其中--max-workers即蜂群中 Worker 数量的上限对应资源配额约束。Emergency Response应急响应检测到关键任务时Worker 应识别关键任务优先于当前工作处理以最小开销执行跳过非关键汇报、直接干核心步骤立即汇报完成。这一模式与 Queen 的 Emergency Mode绝对权威、绕过共识、危机管理形成上下对齐——紧急状态下Worker 的自主范围反而被收敛为最短路径执行 立即上报仍不赋予其决策权。质量红线Do / Dont 清单Worker 的 Quality Standards 是一组纪律性极强的正反向约束必须遵守Do每 30–60 秒写一次状态遇到阻塞立即上报共享中间结果维护工作日志服从 Queen 的指令。严禁触犯Dont未经分配就开工跳过进度更新忽略依赖检查超出资源配额擅自做自主决策。这五条 Dont 实质上是把执行者不自决的定位从理念落实为可审计的运行时约束。特别是Exceed resource quotas与 Queen 在 queen-coordinator.md 中下发的resource-allocation为 workers 分配 compute/memory 配额直接挂钩——Worker 上报的resources_used就是 Queen 核查配额的依据。绩效画像每任务一报的量化指标Worker 在每次任务后写入自身绩效形成长期可比较的执行档案// Report performance every task mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/metrics, namespace: coordination, value: JSON.stringify({ tasks_completed: 15, average_time_ms: 2500, success_rate: 0.93, resource_efficiency: 0.78, collaboration_score: 0.85 }) }五个维度分别刻画产出量tasks_completed、时延average_time_ms、可靠性success_rate、资源利用resource_efficiency、协作度collaboration_score。该指标的消费方包括Queen作为 hive-health 中swarm_efficiency与后续资源再分配的数据来源Memory Manager见 swarm-memory-manager.md 中每 60 秒的指标协议operations_per_second、cache_hit_rate、sync_latency_ms等两者共同构成蜂群的可观测层Worker 自身通过纵向对比success_rate、average_time_ms的演化识别能力退化或环境变化。集成边界向谁汇报、与谁协作Worker 在整个蜂群组织图中的关系可用一张矩阵归纳关系对象触发场景汇报上级queen-coordinator接收任务分配汇报上级collective-intelligence需要复杂决策时上交汇报上级swarm-memory-manager状态持久化与记忆写入平行协作其他 Worker并行任务分工与合并信息求助scout-explorer需要情报/环境数据时优化求助neural-pattern-analyzer需要执行模式优化这套上对三、侧对三的拓扑保证了一点Worker 永远不会直接面对蜂群全局它只需要知道自己依赖谁、向谁汇报。Queen 的 Command Protocols下发指令 → 监控合规 → 评估结果与 Worker 的 Task Execution Protocol接收 → 汇报 → 交付在记忆键上首尾相接——swarm/worker-[ID]/status、swarm/worker-[ID]/blocked、swarm/worker-[ID]/complete构成一条完整可审计的生命周期轨迹。从仓库结构看蜂群编排层的对应支撑还包括 hive-mind-init 初始化、hive-mind-status 状态查看、hive-mind-memory 记忆操作等命令它们与 Worker 的记忆键规范配合构成了从单 Worker 生命周期到整个蜂群运维的完整闭环。最佳实践总结综合 Worker Specialist 的契约与 ruflo Hive Mind 的实现约定落地一个合格的蜂群 Worker 应遵循以下要点键名即状态机始终使用swarm/worker-[ID]/{status,progress,blocked,complete,metrics}五类键让状态可被机器枚举、可被 Queen 轮询时间戳不可省所有上报都携带Date.now()这是 Memory Manager 冲突解决last-write-wins with versioning与 Queen 延迟判断的前提依赖前置检查写死为流程第一步retrieve后必须同时校验found与value.ready不满足立即写 blocked绝不静默等待共享区产出要带类型与来源swarm/shared/*的写入务必携带type、created_by、confidence_level等元数据保证下游消费者能区分事实与推断汇报频率遵守纪律常规任务 30–60 秒一报应急模式只报 begin/complete把汇报开销与可见性需求做匹配绝不越权未经分配不开工、不自作决策、不超配额——Worker 的专业性恰恰体现在它把执行做到极致把判断让渡给 Queen 与 Collective Intelligence。Worker Specialist 的价值公式可以概括为一句话用纪律化的记忆读写换取整个蜂群对任务状态的无争议共识。对于需要构建可观测、可恢复、可考核多智能体团队的开发者而言这套角色契约与 memory 键规范即使不依赖 ruflo 运行时也可以直接作为设计自己 swarm 编排层时的参考蓝本。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ruflo 蜂群思维 Worker Specialist：基于 memory coordination 的 swarm 任务执行专员完整实战指南
ruflo 蜂群思维 Worker Specialist基于 memory coordination 的 swarm 任务执行专员完整实战指南【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo导读Worker Specialist工作专员是 ruflo原 Claude FlowHive Mind 蜂群体系中的专职任务执行角色它不负责决策、不做侦察而是以接受指令—汇报进度—交付结果为唯一主线通过memory_usage记忆协调通道与 Queen Coordinator、其他 Worker 保持实时同步。本文以 .claude/agents/hive-mind/worker-specialist.md 为骨架结合同目录下 Queen/Scout/Memory Manager 等角色定义与.claude/commands/hive-mind/命令族系统讲解 Worker 的职责协议、状态汇报 schema、依赖管理、并行协作模式并给出可复制到真实多智能体任务中的配置与执行范式。读完你将能独立编写一个守纪律、可观测、可考核的 swarm Worker 智能体并将其接入 ruflo 的 memory 命名空间体系。Worker Specialist 在蜂群架构中的定位ruflo 的 Hive Mind 是一套分层级的多智能体协调体系。在.claude/agents/hive-mind/目录下共定义了五个相互协作的蜂群角色Worker 是其中最接地气的执行层角色定义文件定位Queen Coordinatorqueen-coordinator.md蜂群最高指挥分配资源、下发 directiveCollective Intelligencecollective-intelligence-coordinator.md复杂决策与知识整合顾问Swarm Memory Managerswarm-memory-manager.md记忆命名空间、缓存与同步Scout Explorerscout-explorer.md信息采集与环境侦察Worker Specialistworker-specialist.md任务执行专员本文主角文档开篇对 Worker 的身份定义非常明确You are a Worker Specialist, the dedicated executor of the hive minds will.——即蜂群意志的执行器。它的核心约束是不自主决策、不越权行动一切行为以 Queen 的分配任务为边界一切沟通通过namespace: coordination的记忆通道进行。说明同一角色在plugin/agents/hive-mind/worker-specialist.md目录下存在镜像副本两者内容一致均是同一份角色契约在不同加载路径下的部署。记忆协调通道Worker 与蜂群沟通的唯一语言Worker 所有状态上报都通过mcp__claude-flow__memory_usage这一 MCP 工具完成。在 ruflo 的命令层该工具对应 memory-usage 命令底层支持的动作与参数为--action typestore / retrieve / list / clear--key key记忆键名--value data要写入的 JSON 数据通过命令行等价形式可完成同样的读写例如# 等价于 Worker 的 store 动作 npx claude-flow memory usage --action store --key swarm/worker-1/status --value {status:task-received} # 等价于 Worker 的 retrieve 动作启动前检查依赖 npx claude-flow memory usage --action retrieve --key swarm/shared/dependencies # 查看当前 coordination 命名空间下已有哪些键 npx claude-flow memory usage --action listWorker 约定使用namespace: coordination作为统一命名空间并遵循swarm/worker-[ID]/状态类型的键命名规范。从源码结构可以推断这套命名空间与键值规范让 Queen读取swarm/worker-*/status做合规检查、Memory Manager按coordination命名空间做索引与缓存、其他 Worker读取swarm/shared/*共享进度都能以键前缀 动作的方式对蜂群状态进行可预测的轮询与同步这正是通过记忆协调保持持续通信的落地机制。任务执行协议三段式强制状态汇报Worker 的纪律核心是在任务前、任务中、任务后都必须写状态原文标注 MANDATORY。这并非可选项而是整个蜂群可观测性的根基。START接受任务分配收到 Queen 的 directive 后Worker 立即写入swarm/worker-[ID]/status// START - Accept task assignment mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/status, namespace: coordination, value: JSON.stringify({ agent: worker-[ID], status: task-received, assigned_task: specific task description, estimated_completion: Date.now() 3600000, dependencies: [], timestamp: Date.now() }) }该 schema 字段的实际作用agent/status标识是谁、处于什么状态供 Queen 的 hive-health 监控按agent_compliance清单比对见 queen-coordinator.mdassigned_task任务描述明确边界estimated_completion预估完成时间点示例为Date.now() 3600000即预估 1 小时后完成供 Queen 判断是否存在拖延dependencies预先声明依赖后续与依赖检查呼应timestamp统一使用Date.now()时间戳便于向量时钟/版本对比Memory Manager 同样依赖时间戳做 version 写入。PROGRESS每个关键步骤更新// PROGRESS - Update every significant step mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/progress, namespace: coordination, value: JSON.stringify({ task: current task, steps_completed: [step1, step2], current_step: step3, progress_percentage: 60, blockers: [], files_modified: [file1.js, file2.js] }) }其中progress_percentage给出 0–100 的量化进度steps_completed记录已完成步骤栈files_modified记录实际改动文件——这保证了即使 Worker 会话中断接手的 Worker 也能从记忆里恢复现场对应.claude/commands/hive-mind/hive-mind-resume.md提供的会话恢复能力。质量规范中要求每 30–60 秒写一次状态即任务推进时保持至少分钟级的可见性。按专长拆分的四类 WorkerWorker 不是同质化的执行者。文档给出了三类典型专长每种专长向swarm/shared/共享区写入不同结构的交付物供后续 Worker 与 Queen 直接消费。Code Implementation Worker共享实现细节// Share implementation details mcp__claude-flow__memory_usage { action: store, key: swarm/shared/implementation-[feature], namespace: coordination, value: JSON.stringify({ type: code, language: javascript, files_created: [src/feature.js], functions_added: [processData(), validateInput()], tests_written: [feature.test.js], created_by: worker-code-1 }) }关注点在于可追踪性写明了创建文件、新增函数、配套测试与创建者 ID。后续任何 Worker 接续该 feature 时可通过retrieve该键获取完整实现清单避免重复造轮子或产生文件冲突。Analysis Worker共享分析结论// Share analysis results mcp__claude-flow__memory_usage { action: store, key: swarm/shared/analysis-[topic], namespace: coordination, value: JSON.stringify({ type: analysis, findings: [finding1, finding2], recommendations: [rec1, rec2], data_sources: [source1, source2], confidence_level: 0.85, created_by: worker-analyst-1 }) }Analysis Worker 的产出包含confidence_level置信度这一关键元数据——它让下游消费者如 Collective Intelligence 的加权投票决策可以对每条分析做可信度加权而非把信息当事实全盘接收。Testing Worker共享测试结果// Report test results mcp__claude-flow__memory_usage { action: store, key: swarm/shared/test-results, namespace: coordination, value: JSON.stringify({ type: testing, tests_run: 45, tests_passed: 43, tests_failed: 2, coverage: 87%, failure_details: [test1: timeout, test2: assertion failed], created_by: worker-test-1 }) }测试 Worker 的汇报把数字统计与失败明细分离tests_run/passed/failed/coverage供 Queen 快速评估质量门槛failure_details提供可定位到具体用例如 timeout、assertion failed的原始信息便于修复型 Worker 直接按单处理。值得注意的是三类 Worker 共享同一把键swarm/shared/...但靠type字段区分——这体现了一种约定共享区按主题分键、按类型分内容既保证路由确定性又保证同一主题可被多类 Worker 协同写入。依赖管理开工前必查被阻塞即上报Worker 被明确禁止在依赖未就绪时盲目开工。文档给出标准的依赖检查流程// CHECK dependencies before starting const deps await mcp__claude-flow__memory_usage { action: retrieve, key: swarm/shared/dependencies, namespace: coordination } if (!deps.found || !deps.value.ready) { // REPORT blocking mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/blocked, namespace: coordination, value: JSON.stringify({ blocked_on: dependencies, waiting_for: [component-x, api-y], since: Date.now() }) } }这段逻辑包含两个关键设计读取结果的双重判断同时检查deps.found键是否存在与deps.value.ready依赖是否就绪避免把空结果误判为依赖齐备阻塞状态显式化一旦发现依赖缺失立即写swarm/worker-[ID]/blocked键并声明waiting_for。这样 Queen 的 swarm-health 轮询能立刻发现僵局并重新调度例如调派其他 Worker 先完成component-x而不是让 Worker 空转等待。与之呼应Worker 的 Dont 清单明确包含 Ignore dependency checks不得跳过依赖检查与 Start work without assignment不得无指令开工从正反两面锁死自主性边界。结果交付complete 状态的结构化产出任务收尾时 Worker 写入swarm/worker-[ID]/complete这是 Queen 判断任务闭环与考核 Worker 绩效的依据// COMPLETE - Deliver results mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/complete, namespace: coordination, value: JSON.stringify({ status: complete, task: assigned task, deliverables: { files: [file1, file2], documentation: docs/feature.md, test_results: all passing, performance_metrics: {} }, time_taken_ms: 3600000, resources_used: { memory_mb: 256, cpu_percentage: 45 } }) }deliverables 区分了四种产出类型files交付文件、documentation配套文档示例约定写入 docs/、test_results质量凭证、performance_metrics性能指标可按需留空。同时补报time_taken_ms与resources_used内存/CPU这两项直接喂给 Worker 自身的 Performance Metrics 统计见下文供蜂群做资源配额核算与效率画像。三种工作模式串行 / 并行 / 应急Sequential Execution串行执行这是 Worker 的默认模式严格五步走从 Queen/Coordinator 接收任务验证依赖可用对应上文 Dependency Management按顺序执行任务步骤在每一步汇报进度对应 PROGRESS 上报交付结果对应 complete 上报。Parallel Collaboration并行协作当多个 Worker 处理同一目标时检查是否有同级 Worker 在做相同任务通过读取swarm/worker-*/progress或共享区键判断按各自能力划分工作如 Code Worker 实现、Testing Worker 验证、Analysis Worker 评估通过记忆同步进度各自写 progress并消费对方写入的swarm/shared/implementation-*完成时合并结果。这种模式依赖上一节的专长分工——能力划分 共享区写入正是并行不冲突的前提。实际落地时可用.claude/commands/hive-mind/hive-mind-spawn.md指定 swarm 规模与 Queen 类型npx claude-flow hive-mind spawn Build API --max-workers 4 npx claude-flow hive-mind spawn Research patterns --queen-type adaptive其中--max-workers即蜂群中 Worker 数量的上限对应资源配额约束。Emergency Response应急响应检测到关键任务时Worker 应识别关键任务优先于当前工作处理以最小开销执行跳过非关键汇报、直接干核心步骤立即汇报完成。这一模式与 Queen 的 Emergency Mode绝对权威、绕过共识、危机管理形成上下对齐——紧急状态下Worker 的自主范围反而被收敛为最短路径执行 立即上报仍不赋予其决策权。质量红线Do / Dont 清单Worker 的 Quality Standards 是一组纪律性极强的正反向约束必须遵守Do每 30–60 秒写一次状态遇到阻塞立即上报共享中间结果维护工作日志服从 Queen 的指令。严禁触犯Dont未经分配就开工跳过进度更新忽略依赖检查超出资源配额擅自做自主决策。这五条 Dont 实质上是把执行者不自决的定位从理念落实为可审计的运行时约束。特别是Exceed resource quotas与 Queen 在 queen-coordinator.md 中下发的resource-allocation为 workers 分配 compute/memory 配额直接挂钩——Worker 上报的resources_used就是 Queen 核查配额的依据。绩效画像每任务一报的量化指标Worker 在每次任务后写入自身绩效形成长期可比较的执行档案// Report performance every task mcp__claude-flow__memory_usage { action: store, key: swarm/worker-[ID]/metrics, namespace: coordination, value: JSON.stringify({ tasks_completed: 15, average_time_ms: 2500, success_rate: 0.93, resource_efficiency: 0.78, collaboration_score: 0.85 }) }五个维度分别刻画产出量tasks_completed、时延average_time_ms、可靠性success_rate、资源利用resource_efficiency、协作度collaboration_score。该指标的消费方包括Queen作为 hive-health 中swarm_efficiency与后续资源再分配的数据来源Memory Manager见 swarm-memory-manager.md 中每 60 秒的指标协议operations_per_second、cache_hit_rate、sync_latency_ms等两者共同构成蜂群的可观测层Worker 自身通过纵向对比success_rate、average_time_ms的演化识别能力退化或环境变化。集成边界向谁汇报、与谁协作Worker 在整个蜂群组织图中的关系可用一张矩阵归纳关系对象触发场景汇报上级queen-coordinator接收任务分配汇报上级collective-intelligence需要复杂决策时上交汇报上级swarm-memory-manager状态持久化与记忆写入平行协作其他 Worker并行任务分工与合并信息求助scout-explorer需要情报/环境数据时优化求助neural-pattern-analyzer需要执行模式优化这套上对三、侧对三的拓扑保证了一点Worker 永远不会直接面对蜂群全局它只需要知道自己依赖谁、向谁汇报。Queen 的 Command Protocols下发指令 → 监控合规 → 评估结果与 Worker 的 Task Execution Protocol接收 → 汇报 → 交付在记忆键上首尾相接——swarm/worker-[ID]/status、swarm/worker-[ID]/blocked、swarm/worker-[ID]/complete构成一条完整可审计的生命周期轨迹。从仓库结构看蜂群编排层的对应支撑还包括 hive-mind-init 初始化、hive-mind-status 状态查看、hive-mind-memory 记忆操作等命令它们与 Worker 的记忆键规范配合构成了从单 Worker 生命周期到整个蜂群运维的完整闭环。最佳实践总结综合 Worker Specialist 的契约与 ruflo Hive Mind 的实现约定落地一个合格的蜂群 Worker 应遵循以下要点键名即状态机始终使用swarm/worker-[ID]/{status,progress,blocked,complete,metrics}五类键让状态可被机器枚举、可被 Queen 轮询时间戳不可省所有上报都携带Date.now()这是 Memory Manager 冲突解决last-write-wins with versioning与 Queen 延迟判断的前提依赖前置检查写死为流程第一步retrieve后必须同时校验found与value.ready不满足立即写 blocked绝不静默等待共享区产出要带类型与来源swarm/shared/*的写入务必携带type、created_by、confidence_level等元数据保证下游消费者能区分事实与推断汇报频率遵守纪律常规任务 30–60 秒一报应急模式只报 begin/complete把汇报开销与可见性需求做匹配绝不越权未经分配不开工、不自作决策、不超配额——Worker 的专业性恰恰体现在它把执行做到极致把判断让渡给 Queen 与 Collective Intelligence。Worker Specialist 的价值公式可以概括为一句话用纪律化的记忆读写换取整个蜂群对任务状态的无争议共识。对于需要构建可观测、可恢复、可考核多智能体团队的开发者而言这套角色契约与 memory 键规范即使不依赖 ruflo 运行时也可以直接作为设计自己 swarm 编排层时的参考蓝本。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
