ruflo Codex 并行协调器实战指南以codex exec编排多 worker 并行任务【免费下载链接】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本指南围绕 ruflo 生态中的codex-coordinator智能体角色详见 .claude/agents/dual-mode/codex-coordinator.md展开讲解如何在一个交互式会话中通过 shell 后台进程批量拉起 headless Codex worker实现「任务分解 → 并行执行 → 共享内存汇聚结果」的完整闭环。读完本文你将掌握codex exec的正确 spawn 语法、并行与串行两类协调模式、基于 memory namespace 的进程间通信约定以及可直接落地的「功能开发 swarm」示例脚本。一、为什么需要并行协调器角色Claude Code 这类交互式前端适合复杂推理与实时讨论但它一次只能在一个会话里线性推进而 Codex CLI 提供的codex exec是非交互子命令能以单条命令运行到结束并输出最终消息天然可以被 shell 后台化追加实现多路并行。codex-coordinator正是这两者之间的编排层协调器负责想分解、监控、聚合worker 负责做在后台各自独立执行进程之间不直接对话而是统一通过 ruflo memory 读写共享状态。该角色并不是孤立定义。在仓库中它与另两个角色构成一组完整的「双模式」方案.claude/agents/dual-mode/codex-worker.md定义单个 headless worker 的行为契约包括任务前检索 patterns、任务后回写结果.claude/agents/dual-mode/dual-orchestrator.md定义 Claude Code交互 Codexheadless混合编排的路由规则。三个文档在同一目录下互为引用且存在对应的发布镜像副本 plugin/agents/dual-mode/说明它们是作为可复用的 agent 定义被分发的。底层真正执行并行拉起的代码位于 v3/claude-flow/codex/src/dual-mode/orchestrator.ts其文件头注释即写明了这一目标——Runs Claude Code and Codex workers in parallel with shared memory。二、执行模型与架构codex-coordinator的工作架构可以用下面的角色分层图概括原文架构图的文字化保留┌─────────────────────────────────────────────────┐ │ COORDINATOR (You - Interactive) │ │ ├─ Decompose task into sub-tasks │ │ ├─ Spawn parallel workers │ │ ├─ Monitor progress via memory │ │ └─ Aggregate results │ └───────────────┬─────────────────────────────────┘ │ spawns ┌───────┼───────┬───────┐ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ -1 │ │ -2 │ │ -3 │ │ -4 │ │worker│ │worker│ │worker│ │worker│ └──────┘ └──────┘ └──────┘ └──────┘ │ │ │ │ └───────┴───────┴───────┘ │ ▼ ┌─────────────┐ │ MEMORY │ │ (results) │ └─────────────┘要点拆解Coordinator 是唯一的交互角色它运行在前台负责把大任务拆成可并行的子任务然后一次性 spawn 多个后台 workerWorkers 之间是隔离的每个 worker 是一个独立的codex exec进程写入各自工作区互不感知Memory 是唯一的总线worker 完成写resultsnamespacecoordinator 完成后从同一 namespace 读取实现解耦的进程间通信。这个分层模型与源码中DualModeOrchestrator的设计一致在 orchestrator.ts 中协调器用private workers: Mapstring, WorkerResult维护所有被拉起 worker 的状态并通过spawnWorker(config: WorkerConfig)逐个启动后台子进程启动成功后通过事件机制发出worker:started、worker:completed、worker:failed三类信号供上层监控整体进度。关键 spawn 语法约定coordinator 与 worker 两份文档都反复强调以下语法这是整套方案的基石# 语法模板非交互执行 workspace 写权限 跳过 git 仓库检查 codex exec --sandbox workspace-write --skip-git-repo-check prompt codex exec非交互模式运行到结束把最终消息打印到 stdout--sandbox workspace-write授予工作区写入能力代码改动类任务必选--sandbox read-only只读沙箱用于审计、评审、设计类任务杜绝误写--skip-git-repo-check允许在非 git 仓库目录下运行降低启动门槛放入后台使多个 worker 并行wait阻塞等待全部后台进程结束。如果混合了平台Claude worker则 Claude 侧对应语法是claude -p prompt --output-format text 但文档明确约定codex-worker永远使用codex exec启动保持单一启动路径。仓库 orchestrator.ts 的源码注释也原样记录了这一命令形态并补充了模型固定参数[-m M]即codex exec --sandbox workspace-write --skip-git-repo-check -m model prompt以及一条容易踩坑的注意codex exec的 PROMPT 是位置参数必须放在命令最后。三、核心职责Task Decomposition任务分解把复杂任务切分为可并行、边界清晰的子单元每个子单元粒度以数分钟内可完成为准Worker Spawning拉起 worker通过codex exec一次性后台拉起多个 headless Codex 实例Coordination协调跟踪通过共享 memory 跟踪各 worker 的进度与完成状态Result Aggregation结果聚合汇总并组合各 worker 的输出形成最终交付物。四、标准协调工作流三步走Step 1初始化 swarmnpx ruflolatest swarm init --topology hierarchical --max-agents 6--topology hierarchical声明层级拓扑worker 挂在协调器之下--max-agents 6限制本次 swarm 的最大成员数避免无度拉起耗尽资源。从 MCP 侧看这条能力对应仓库 v3/mcp/tools/v2-compat-tools.ts 中的swarm_init工具其路由目标为swarm/init保持了对 V2 生态调用方式的兼容。Step 2并行拉起 worker# 一次性在后台 spawn 全部 worker codex exec --sandbox workspace-write --skip-git-repo-check Implement core auth logic. Store result in results namespace as result-auth-core. codex exec --sandbox workspace-write --skip-git-repo-check Implement auth middleware. Store result as result-auth-middleware. codex exec --sandbox workspace-write --skip-git-repo-check Write auth tests. Store result as result-auth-tests. codex exec --sandbox workspace-write --skip-git-repo-check Document auth API. Store result as result-auth-docs. # 等待所有后台 worker 结束 wait注意每个 prompt 末尾都显式声明了结果存储位置与 keyStore result as result-name这保证了 worker 完成后的产物可被定位。这一步正是 coordinator 把并发执行外包给 shell 的关键——不需要额外的任务队列或调度器。Step 3汇聚结果npx ruflolatest memory list --namespace results所有 worker 写入了统一的resultsnamespace协调器只需一次列举即可拉回全部产物再结合 prompt 中的命名约定识别每个 key 对应的 worker 与子任务。五、两类协调模式5.1 并行 worker 模式Parallel Workers Pattern适合多个相互独立的子任务同时开工。原文用 YAML 描述步骤蓝图description: Spawn multiple workers for parallel execution steps: - swarm_init: { topology: hierarchical, maxAgents: 8 } - spawn_workers: - { type: coder, count: 2 } - { type: tester, count: 1 } - { type: reviewer, count: 1 } - wait_for_completion - aggregate_results5.2 串行流水线模式Sequential Pipeline Pattern适合有依赖链的流程前一个角色的输出是后一个角色的输入例如先出架构、再写实现、最后测试description: Chain workers in sequence steps: - spawn: architect - wait_for: architecture - spawn: [coder-1, coder-2] - wait_for: implementation - spawn: tester - wait_for: tests - aggregate_results两种模式可以自由混编例如混合工作流交互设计Claude Code→ 并行实现Codex workers→ 交互评审Claude Code即是串行阶段套并行 worker 的典型场景具体可参见 dual-orchestrator.md 中 Hybrid Development Flow 的 phase 编排。六、可复用 Prompt 模板6.1 并行协调模板JS 生成 spawn 命令当 worker 数量较多或需要程序化生成命令时可枚举 worker 清单并循环输出 spawn 命令// Template for coordinating parallel workers const workers [ { id: coder-1, task: Implement user service }, { id: coder-2, task: Implement API endpoints }, { id: tester, task: Write integration tests }, { id: docs, task: Document the API } ]; // Spawn all workers workers.forEach(w { console.log(codex exec --sandbox workspace-write --skip-git-repo-check ${w.task}. Store result as result-${w.id}. ); });把输出的命令粘到 shell 执行即可把数组 → 并行进程的过程完全模板化。6.2 Worker 启动模板带记忆读写约束给后台 worker 的 prompt 建议采用固定结构让每个 worker 保持先查记忆、再执行、后回写的行为一致性codex exec --sandbox workspace-write --skip-git-repo-check You are {{worker_name}} ({{worker_id}}). TASK: {{worker_task}} 1. Search memory: memory_search(query{{task_keywords}}) 2. Execute your task 3. Store results: memory_store(keyresult-{{worker_id}}, namespaceresults, upserttrue) 模板里三个占位步骤与 codex-worker.md 定义的 worker 自学习工作流一一对应开工前memory_search检索历史 patterns收工后memory_store把结果写回resultsnamespace并把本次有效做法写入patternsnamespace 供后续 worker 复用其 key 形如pattern-[task-type]。七、MCP 工具集成协调器在 Claude Code 内通过 MCP 工具访问 ruflo 的服务能力实现状态跟踪与数据读写。文档给出了三类代表性调用7.1 初始化协调// Initialize swarm tracking mcp__ruflo__swarm_init { topology: hierarchical, maxAgents: 8, strategy: specialized }strategy: specialized表示各 worker 按角色专业化分工coder / tester / reviewer / docs 等。7.2 跟踪 worker 状态// Store coordination state mcp__ruflo__memory_store { key: coordination/parallel-task, value: JSON.stringify({ workers: [worker-1, worker-2, worker-3], started: new Date().toISOString(), status: running }), namespace: coordination }协调器把自己发起的并行任务登记到coordinationnamespace后续可通过查询该 key 判断任务是否仍在运行。7.3 聚合结果// Collect all worker results mcp__ruflo__memory_list { namespace: results }底层兼容层方面v2-compat-tools.ts 明确将swarm_init映射至swarm/init、agent_spawn映射至agent/spawn说明这些以mcp__ruflo__前缀暴露的工具在 V3 MCP 服务中仍然可用使用旧 V2 调用名也能被正确路由。八、完整示例一次功能开发 Swarm把上述全部要素串起来的可运行脚本完整继承原文脚本#!/bin/bash FEATUREuser-auth # Initialize npx ruflolatest swarm init --topology hierarchical --max-agents 4 # Spawn workers in parallel codex exec --sandbox workspace-write --skip-git-repo-check Architect: Design $FEATURE. Store result as result-${FEATURE}-arch. codex exec --sandbox workspace-write --skip-git-repo-check Coder: Implement $FEATURE. Store result as result-${FEATURE}-code. codex exec --sandbox workspace-write --skip-git-repo-check Tester: Test $FEATURE. Store result as result-${FEATURE}-test. codex exec --sandbox workspace-write --skip-git-repo-check Docs: Document $FEATURE. Store result as result-${FEATURE}-docs. # Wait for all wait # Collect results npx ruflolatest memory list --namespace results运行后user-auth的架构设计、实现代码、测试用例、API 文档四类产物会并行产出并汇总到resultsnamespace每个 keyresult-user-auth-arch等都能明确对应该功能的一个侧面。九、最佳实践清单Size Workers Appropriately单个 worker 的任务控制在 5 分钟内完成避免长任务导致后台进程长时间无产出、难以判断死活Use Meaningful IDs结果 key 要能体现 worker 的职责如result-auth-middleware便于聚合后自动归类Share Contextspawn 之前先把共享上下文接口约定、目录规范、设计约束写入 memory让所有 worker 从同一份上下文出发避免各写各的Pick a Sandbox改动代码用workspace-write审计/评审/纯设计用read-only把只读安全写进启动参数而不是依赖 worker 自觉Error Handling收集结果时检查部分失败——后台进程可能因 prompt 理解偏差或环境问题中途失败聚合阶段必须对缺失 key 做兜底与重试决策。配套的 worker 侧注意事项见 codex-worker.md包括始终追加保证并行结果一律写回resultsnamespace 供协调器收集upsert: true防止重复 key 报错即使部分成功也要回写完成状态便于协调器区分失败与未上报。十、Worker 类型参考表协调器 spawn 时通常用 prompt 中的角色词Architect/Coder/Tester/Reviewer/Docs声明 worker 身份。角色与 spawn 命令的对应关系如下表TypePurposeSpawn CommandcoderImplement codecodex exec --sandbox workspace-write --skip-git-repo-check Implement [feature]testerWrite testscodex exec --sandbox workspace-write --skip-git-repo-check Write tests for [module]reviewerReview codecodex exec --sandbox read-only --skip-git-repo-check Review [files]docsDocumentationcodex exec --sandbox workspace-write --skip-git-repo-check Document [component]architectDesigncodex exec --sandbox read-only --skip-git-repo-check Design [system]注意reviewer与architect因职责是阅读、判断、设计统一使用read-only沙箱真正写文件的coder、tester、docs才使用workspace-write。仓库中可找到与之对应的角色化 agent 定义例如 v3/agents/coder.yaml、v3/agents/tester.yaml、v3/agents/reviewer.yaml以及.claude/agents/core/下的 coder / tester / reviewer 文档可在需要时把具体的 worker 提示词细化到角色专属 prompt。十一、与周边能力的衔接与 codex-worker 的关系coordinator 只负责 spawn 与聚合具体 worker 内部的查模式→执行→回写流程由 codex-worker 契约保证两者配合才能让结果落盘到约定的 namespace与 dual-orchestrator 的关系当任务需要 Claude Code 深度介入设计、调试、评审时由 dual-orchestrator 决定路由并把交互阶段与 headless 阶段串起来coordinator 聚焦在其中并行执行这段可直接运行的内置技能.claude/skills/dual-mode/目录提供了dual-spawn、dual-coordinate、dual-collect等技能的 README分别对应拉起、协调、收集三个动作可作为上述手工命令的封装入口测试保障仓库中 v3/claude-flow/codex/tests/dual-mode-stdin-2947.test.ts 记录了与双模式 worker 标准输入行为相关的回归用例对应真实环境中codex exec若 stdin 未关闭可能导致的挂起问题说明该机制在交付前经过了真实进程级验证。总而言之这套模式的要义可以用一句话概括——coordinator 负责编排与汇聚worker 通过codex exec在后台独立执行所有跨进程通信都经由 memory 完成。理解了 spawn 语法、namespace 约定与两类编排模式你就可以在 ruflo 生态内把任意一个可并行的大型开发任务拆解成一批彼此隔离、结果可聚合的 headless Codex workers。【免费下载链接】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 Codex 并行协调器实战指南：以 `codex exec` 编排多 worker 并行任务
ruflo Codex 并行协调器实战指南以codex exec编排多 worker 并行任务【免费下载链接】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本指南围绕 ruflo 生态中的codex-coordinator智能体角色详见 .claude/agents/dual-mode/codex-coordinator.md展开讲解如何在一个交互式会话中通过 shell 后台进程批量拉起 headless Codex worker实现「任务分解 → 并行执行 → 共享内存汇聚结果」的完整闭环。读完本文你将掌握codex exec的正确 spawn 语法、并行与串行两类协调模式、基于 memory namespace 的进程间通信约定以及可直接落地的「功能开发 swarm」示例脚本。一、为什么需要并行协调器角色Claude Code 这类交互式前端适合复杂推理与实时讨论但它一次只能在一个会话里线性推进而 Codex CLI 提供的codex exec是非交互子命令能以单条命令运行到结束并输出最终消息天然可以被 shell 后台化追加实现多路并行。codex-coordinator正是这两者之间的编排层协调器负责想分解、监控、聚合worker 负责做在后台各自独立执行进程之间不直接对话而是统一通过 ruflo memory 读写共享状态。该角色并不是孤立定义。在仓库中它与另两个角色构成一组完整的「双模式」方案.claude/agents/dual-mode/codex-worker.md定义单个 headless worker 的行为契约包括任务前检索 patterns、任务后回写结果.claude/agents/dual-mode/dual-orchestrator.md定义 Claude Code交互 Codexheadless混合编排的路由规则。三个文档在同一目录下互为引用且存在对应的发布镜像副本 plugin/agents/dual-mode/说明它们是作为可复用的 agent 定义被分发的。底层真正执行并行拉起的代码位于 v3/claude-flow/codex/src/dual-mode/orchestrator.ts其文件头注释即写明了这一目标——Runs Claude Code and Codex workers in parallel with shared memory。二、执行模型与架构codex-coordinator的工作架构可以用下面的角色分层图概括原文架构图的文字化保留┌─────────────────────────────────────────────────┐ │ COORDINATOR (You - Interactive) │ │ ├─ Decompose task into sub-tasks │ │ ├─ Spawn parallel workers │ │ ├─ Monitor progress via memory │ │ └─ Aggregate results │ └───────────────┬─────────────────────────────────┘ │ spawns ┌───────┼───────┬───────┐ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ -1 │ │ -2 │ │ -3 │ │ -4 │ │worker│ │worker│ │worker│ │worker│ └──────┘ └──────┘ └──────┘ └──────┘ │ │ │ │ └───────┴───────┴───────┘ │ ▼ ┌─────────────┐ │ MEMORY │ │ (results) │ └─────────────┘要点拆解Coordinator 是唯一的交互角色它运行在前台负责把大任务拆成可并行的子任务然后一次性 spawn 多个后台 workerWorkers 之间是隔离的每个 worker 是一个独立的codex exec进程写入各自工作区互不感知Memory 是唯一的总线worker 完成写resultsnamespacecoordinator 完成后从同一 namespace 读取实现解耦的进程间通信。这个分层模型与源码中DualModeOrchestrator的设计一致在 orchestrator.ts 中协调器用private workers: Mapstring, WorkerResult维护所有被拉起 worker 的状态并通过spawnWorker(config: WorkerConfig)逐个启动后台子进程启动成功后通过事件机制发出worker:started、worker:completed、worker:failed三类信号供上层监控整体进度。关键 spawn 语法约定coordinator 与 worker 两份文档都反复强调以下语法这是整套方案的基石# 语法模板非交互执行 workspace 写权限 跳过 git 仓库检查 codex exec --sandbox workspace-write --skip-git-repo-check prompt codex exec非交互模式运行到结束把最终消息打印到 stdout--sandbox workspace-write授予工作区写入能力代码改动类任务必选--sandbox read-only只读沙箱用于审计、评审、设计类任务杜绝误写--skip-git-repo-check允许在非 git 仓库目录下运行降低启动门槛放入后台使多个 worker 并行wait阻塞等待全部后台进程结束。如果混合了平台Claude worker则 Claude 侧对应语法是claude -p prompt --output-format text 但文档明确约定codex-worker永远使用codex exec启动保持单一启动路径。仓库 orchestrator.ts 的源码注释也原样记录了这一命令形态并补充了模型固定参数[-m M]即codex exec --sandbox workspace-write --skip-git-repo-check -m model prompt以及一条容易踩坑的注意codex exec的 PROMPT 是位置参数必须放在命令最后。三、核心职责Task Decomposition任务分解把复杂任务切分为可并行、边界清晰的子单元每个子单元粒度以数分钟内可完成为准Worker Spawning拉起 worker通过codex exec一次性后台拉起多个 headless Codex 实例Coordination协调跟踪通过共享 memory 跟踪各 worker 的进度与完成状态Result Aggregation结果聚合汇总并组合各 worker 的输出形成最终交付物。四、标准协调工作流三步走Step 1初始化 swarmnpx ruflolatest swarm init --topology hierarchical --max-agents 6--topology hierarchical声明层级拓扑worker 挂在协调器之下--max-agents 6限制本次 swarm 的最大成员数避免无度拉起耗尽资源。从 MCP 侧看这条能力对应仓库 v3/mcp/tools/v2-compat-tools.ts 中的swarm_init工具其路由目标为swarm/init保持了对 V2 生态调用方式的兼容。Step 2并行拉起 worker# 一次性在后台 spawn 全部 worker codex exec --sandbox workspace-write --skip-git-repo-check Implement core auth logic. Store result in results namespace as result-auth-core. codex exec --sandbox workspace-write --skip-git-repo-check Implement auth middleware. Store result as result-auth-middleware. codex exec --sandbox workspace-write --skip-git-repo-check Write auth tests. Store result as result-auth-tests. codex exec --sandbox workspace-write --skip-git-repo-check Document auth API. Store result as result-auth-docs. # 等待所有后台 worker 结束 wait注意每个 prompt 末尾都显式声明了结果存储位置与 keyStore result as result-name这保证了 worker 完成后的产物可被定位。这一步正是 coordinator 把并发执行外包给 shell 的关键——不需要额外的任务队列或调度器。Step 3汇聚结果npx ruflolatest memory list --namespace results所有 worker 写入了统一的resultsnamespace协调器只需一次列举即可拉回全部产物再结合 prompt 中的命名约定识别每个 key 对应的 worker 与子任务。五、两类协调模式5.1 并行 worker 模式Parallel Workers Pattern适合多个相互独立的子任务同时开工。原文用 YAML 描述步骤蓝图description: Spawn multiple workers for parallel execution steps: - swarm_init: { topology: hierarchical, maxAgents: 8 } - spawn_workers: - { type: coder, count: 2 } - { type: tester, count: 1 } - { type: reviewer, count: 1 } - wait_for_completion - aggregate_results5.2 串行流水线模式Sequential Pipeline Pattern适合有依赖链的流程前一个角色的输出是后一个角色的输入例如先出架构、再写实现、最后测试description: Chain workers in sequence steps: - spawn: architect - wait_for: architecture - spawn: [coder-1, coder-2] - wait_for: implementation - spawn: tester - wait_for: tests - aggregate_results两种模式可以自由混编例如混合工作流交互设计Claude Code→ 并行实现Codex workers→ 交互评审Claude Code即是串行阶段套并行 worker 的典型场景具体可参见 dual-orchestrator.md 中 Hybrid Development Flow 的 phase 编排。六、可复用 Prompt 模板6.1 并行协调模板JS 生成 spawn 命令当 worker 数量较多或需要程序化生成命令时可枚举 worker 清单并循环输出 spawn 命令// Template for coordinating parallel workers const workers [ { id: coder-1, task: Implement user service }, { id: coder-2, task: Implement API endpoints }, { id: tester, task: Write integration tests }, { id: docs, task: Document the API } ]; // Spawn all workers workers.forEach(w { console.log(codex exec --sandbox workspace-write --skip-git-repo-check ${w.task}. Store result as result-${w.id}. ); });把输出的命令粘到 shell 执行即可把数组 → 并行进程的过程完全模板化。6.2 Worker 启动模板带记忆读写约束给后台 worker 的 prompt 建议采用固定结构让每个 worker 保持先查记忆、再执行、后回写的行为一致性codex exec --sandbox workspace-write --skip-git-repo-check You are {{worker_name}} ({{worker_id}}). TASK: {{worker_task}} 1. Search memory: memory_search(query{{task_keywords}}) 2. Execute your task 3. Store results: memory_store(keyresult-{{worker_id}}, namespaceresults, upserttrue) 模板里三个占位步骤与 codex-worker.md 定义的 worker 自学习工作流一一对应开工前memory_search检索历史 patterns收工后memory_store把结果写回resultsnamespace并把本次有效做法写入patternsnamespace 供后续 worker 复用其 key 形如pattern-[task-type]。七、MCP 工具集成协调器在 Claude Code 内通过 MCP 工具访问 ruflo 的服务能力实现状态跟踪与数据读写。文档给出了三类代表性调用7.1 初始化协调// Initialize swarm tracking mcp__ruflo__swarm_init { topology: hierarchical, maxAgents: 8, strategy: specialized }strategy: specialized表示各 worker 按角色专业化分工coder / tester / reviewer / docs 等。7.2 跟踪 worker 状态// Store coordination state mcp__ruflo__memory_store { key: coordination/parallel-task, value: JSON.stringify({ workers: [worker-1, worker-2, worker-3], started: new Date().toISOString(), status: running }), namespace: coordination }协调器把自己发起的并行任务登记到coordinationnamespace后续可通过查询该 key 判断任务是否仍在运行。7.3 聚合结果// Collect all worker results mcp__ruflo__memory_list { namespace: results }底层兼容层方面v2-compat-tools.ts 明确将swarm_init映射至swarm/init、agent_spawn映射至agent/spawn说明这些以mcp__ruflo__前缀暴露的工具在 V3 MCP 服务中仍然可用使用旧 V2 调用名也能被正确路由。八、完整示例一次功能开发 Swarm把上述全部要素串起来的可运行脚本完整继承原文脚本#!/bin/bash FEATUREuser-auth # Initialize npx ruflolatest swarm init --topology hierarchical --max-agents 4 # Spawn workers in parallel codex exec --sandbox workspace-write --skip-git-repo-check Architect: Design $FEATURE. Store result as result-${FEATURE}-arch. codex exec --sandbox workspace-write --skip-git-repo-check Coder: Implement $FEATURE. Store result as result-${FEATURE}-code. codex exec --sandbox workspace-write --skip-git-repo-check Tester: Test $FEATURE. Store result as result-${FEATURE}-test. codex exec --sandbox workspace-write --skip-git-repo-check Docs: Document $FEATURE. Store result as result-${FEATURE}-docs. # Wait for all wait # Collect results npx ruflolatest memory list --namespace results运行后user-auth的架构设计、实现代码、测试用例、API 文档四类产物会并行产出并汇总到resultsnamespace每个 keyresult-user-auth-arch等都能明确对应该功能的一个侧面。九、最佳实践清单Size Workers Appropriately单个 worker 的任务控制在 5 分钟内完成避免长任务导致后台进程长时间无产出、难以判断死活Use Meaningful IDs结果 key 要能体现 worker 的职责如result-auth-middleware便于聚合后自动归类Share Contextspawn 之前先把共享上下文接口约定、目录规范、设计约束写入 memory让所有 worker 从同一份上下文出发避免各写各的Pick a Sandbox改动代码用workspace-write审计/评审/纯设计用read-only把只读安全写进启动参数而不是依赖 worker 自觉Error Handling收集结果时检查部分失败——后台进程可能因 prompt 理解偏差或环境问题中途失败聚合阶段必须对缺失 key 做兜底与重试决策。配套的 worker 侧注意事项见 codex-worker.md包括始终追加保证并行结果一律写回resultsnamespace 供协调器收集upsert: true防止重复 key 报错即使部分成功也要回写完成状态便于协调器区分失败与未上报。十、Worker 类型参考表协调器 spawn 时通常用 prompt 中的角色词Architect/Coder/Tester/Reviewer/Docs声明 worker 身份。角色与 spawn 命令的对应关系如下表TypePurposeSpawn CommandcoderImplement codecodex exec --sandbox workspace-write --skip-git-repo-check Implement [feature]testerWrite testscodex exec --sandbox workspace-write --skip-git-repo-check Write tests for [module]reviewerReview codecodex exec --sandbox read-only --skip-git-repo-check Review [files]docsDocumentationcodex exec --sandbox workspace-write --skip-git-repo-check Document [component]architectDesigncodex exec --sandbox read-only --skip-git-repo-check Design [system]注意reviewer与architect因职责是阅读、判断、设计统一使用read-only沙箱真正写文件的coder、tester、docs才使用workspace-write。仓库中可找到与之对应的角色化 agent 定义例如 v3/agents/coder.yaml、v3/agents/tester.yaml、v3/agents/reviewer.yaml以及.claude/agents/core/下的 coder / tester / reviewer 文档可在需要时把具体的 worker 提示词细化到角色专属 prompt。十一、与周边能力的衔接与 codex-worker 的关系coordinator 只负责 spawn 与聚合具体 worker 内部的查模式→执行→回写流程由 codex-worker 契约保证两者配合才能让结果落盘到约定的 namespace与 dual-orchestrator 的关系当任务需要 Claude Code 深度介入设计、调试、评审时由 dual-orchestrator 决定路由并把交互阶段与 headless 阶段串起来coordinator 聚焦在其中并行执行这段可直接运行的内置技能.claude/skills/dual-mode/目录提供了dual-spawn、dual-coordinate、dual-collect等技能的 README分别对应拉起、协调、收集三个动作可作为上述手工命令的封装入口测试保障仓库中 v3/claude-flow/codex/tests/dual-mode-stdin-2947.test.ts 记录了与双模式 worker 标准输入行为相关的回归用例对应真实环境中codex exec若 stdin 未关闭可能导致的挂起问题说明该机制在交付前经过了真实进程级验证。总而言之这套模式的要义可以用一句话概括——coordinator 负责编排与汇聚worker 通过codex exec在后台独立执行所有跨进程通信都经由 memory 完成。理解了 spawn 语法、namespace 约定与两类编排模式你就可以在 ruflo 生态内把任意一个可并行的大型开发任务拆解成一批彼此隔离、结果可聚合的 headless Codex workers。【免费下载链接】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），仅供参考
