ruflo /ruflo-loop 命令实战构建缓存感知的 12 类后台 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-loop是 ruflo 仓库中ruflo-loop-workers插件提供的核心命令它从参数中解析出 Worker 名称通过claude-flow/cli的hooks worker dispatch派发一个后台 Worker审计、优化、测试缺口分析等并利用 Claude Code 原生的ScheduleWakeup以 270 秒的缓存感知间隔自我续期。读完本文你将掌握该命令的完整参数语义、12 个 Worker 触发名的优先级体系、270 秒心跳与 Prompt 缓存 TTL 的内在关系以及底层hooks_worker-*MCP 工具在源码中的派发与状态判定机制能够据此在自己的会话中稳定运行后台任务循环。一、/ruflo-loop 命令的定位与入口/ruflo-loop的完整定义见 ruflo-loop.md。它是一个标准的 Claude Code 插件命令文件Frontmatter 声明如下name: ruflo-loop description: Start a Ruflo background worker (audit, optimize, testgaps, etc.) on a recurring schedule命令正文的开头直接使用$ARGUMENTS占位符并指示执行者解析 Worker 名称随后给出全部 12 个可用 Worker 的清单与优先级最后给出调度指令通过npx claude-flow/clilatest hooks worker dispatch --trigger WORKER_NAME运行 Worker然后用 delay 为 270scache-warm的ScheduleWakeup预约下一次迭代。从插件整体结构看见 ruflo-loop-workers 插件 README/ruflo-loop与/ruflo-schedule持久化 Cron 模式共同构成该插件的两个命令面并配套 2 个 Skillloop-worker、cron-schedule和 1 个协调 Agentloop-worker-coordinator。整个插件的运行前提是安装ruflo-core插件它提供 MCP server且 CLI 版本固定为claude-flow/cliv3.6 主线。二、12 个后台 Worker触发名与优先级命令文档列出了全部 12 个 Worker按优先级标注这是/ruflo-loop命令参数的合法取值全集Worker 触发名优先级职责auditcritical安全扫描optimizehigh性能优化ultralearnnormal深度知识获取predictnormal预测性预加载mapnormal代码库映射deepdivenormal深度代码分析documentnormal自动文档生成refactornormal重构建议benchmarknormal性能基准测试testgapsnormal测试覆盖分析consolidatelow记忆固化preloadlow资源预加载这份清单并非文档层面的约定而是在 CLI 源码中被当作契约来强制的。hooks_worker-dispatch工具的输入参数 schema 中trigger字段的enum恰好就是这 12 个取值见 hooks-tools.tstrigger: { type: string, description: Worker trigger type, enum: [ultralearn, optimize, consolidate, predict, audit, map, preload, deepdive, document, refactor, benchmark, testgaps], },如果传入了不存在的触发名handler 会直接返回Unknown worker trigger错误并附带全部可用触发名列表方便调用方自查hooks-tools.ts。此外插件的验收脚本 smoke.sh 第 4 步会逐一检查这 12 个触发名是否都被 README 记录任何遗漏都会导致契约验证失败——可以推断文档清单与源码 enum 的一致性是被 CI 级脚本锁定的。三、核心调度循环dispatch 270s 缓存感知心跳/ruflo-loop命令的调度闭环由两步组成# 1. 派发 Worker npx claude-flow/clilatest hooks worker dispatch --trigger WORKER_NAME// 2. 预约下一轮迭代270s缓存处于热状态 ScheduleWakeup({ delaySeconds: 270, reason: next WORKER_NAME iteration })这里的270 秒是整个机制最关键的设计参数其推导过程在仓库文档中有明确解释ruflo-loop-workers README、loop-worker SKILLPrompt 缓存的 TTL 约为 5 分钟300s。若心跳间隔超过 300s下一次唤醒就会发生缓存失效cache-miss多付一次完整上下文的成本而直接取整到 5 分钟则落在临界且最差的区间。因此推荐回退心跳为270 秒——严格小于 5 分钟 TTL让每次唤醒都能读到缓存中的会话上下文。更一般的延迟公式为min(270, cache_ttl * 0.9)即以缓存 TTL 的 90% 作为安全边界loop-worker SKILL。该 270s 心跳契约的属主是ruflo-autopilot插件的 ADR-0001plugins/ruflo-autopilot/docs/adrs/0001-autopilot-contract.mdruflo-loop-workers是承载它的执行基座对于事件驱动的循环建议挂载一个Monitor把 270s 唤醒仅作为安全网。每个 Worker 在两种执行模式下的推荐节奏完整定义在协调 Agent loop-worker-coordinator.md 中Worker优先级触发名loop 间隔Cron 表达式auditcriticalaudit270s*/15 * * * *optimizehighoptimize270s*/30 * * * *consolidatelowconsolidate600s0 * * * *predictnormalpredict270s*/15 * * * *mapnormalmap270s*/30 * * * *testgapsnormaltestgaps270s*/15 * * * *documentnormaldocument600s0 */2 * * *benchmarknormalbenchmark600s0 * * * *deepdivenormaldeepdive270s*/30 * * * *refactornormalrefactor270s*/30 * * * *ultralearnnormalultralearn270s*/15 * * * *preloadlowpreload600s0 * * * *协调 Agent 自身还定义了一个标准工作流先用npx claude-flow/clilatest hooks worker status检查当前 Worker 状态再hooks worker dispatch --trigger WORKER_NAME派发最后按执行模式loop / cron排程下一次检查任务完成后还会通过hooks post-task将成功模式写入patterns命名空间做神经学习沉淀。四、源码层hooks_worker-* 工具的实现细节/ruflo-loop命令最终落到 CLI 侧的 5 个 MCP 工具上全部定义在 hooks-tools.ts 中工具位置用途hooks_worker-listL4453列出 12 个 Worker 及其触发器、状态与能力hooks_worker-dispatchL4502以--trigger worker-name派发一次运行可选--scope/contexthooks_worker-statusL4641查询指定或全部活动 Worker 的运行状态hooks_worker-detectL4699依据上下文检测应当触发哪些 Workerhooks_worker-cancelL5119取消一个运行中的 Worker4.1 dispatch 的入参与默认值从hooks_worker-dispatch的 handler 源码hooks-tools.ts可以读出几个实操相关的细节trigger是唯一必填项context用于传入文件路径或主题未提供时默认default且会经过文本校验validateText防止注入式参数。priority缺省时回退到WORKER_CONFIGS[trigger]中该 Worker 的静态优先级再兜底为normal——这与第二节表中每个 Worker 的优先级标注是对应的。background默认值为true源码为params.background ! false即派发默认非阻塞若显式传false进入同步模式会得到一个诚实的合成完成状态见下。Worker ID 的生成格式为worker_${trigger}_${自增计数}_${时间戳(base36)}L4534可在hooks_worker-status查询时作为workerId使用。4.2 诚实状态queued / no-daemon / synthetic-completeddispatch handler 中最值得注意的是一段带 ADR 注释的实现hooks-tools.ts源码注释引用 ADR-093 F2 与 issue #1845它不再对一个从未真正运行的 Worker 返回status: completed而是依据守护进程daemon的实际存在情况给出四类诚实判定no-daemon读取项目目录下.claude-flow/daemon.pidL4541若 PID 文件不存在或进程探活失败则说明没有可用的 Worker 守护进程。此时派发只是被记录在进程内不会有任何真实工作执行响应中的note会明确提示运行claude-flow daemon start。queueddaemon 存活且background为真时dispatcher 会把任务写成磁盘上的持久队列文件.claude-flow/daemon-queue/${workerId}.json内含workerId、trigger、context、priority、enqueuedAt见 L4587-L4604。守护进程每 5 秒轮询该目录处理完的条目移入.claude-flow/daemon-queue/.processed/。note字段明确告知轮询hooks_worker-status直到status completed——这正对应/ruflo-loop循环中下一轮唤醒前的状态检查动作。mcp-onlydaemon 存活但队列文件写入失败文件系统错误时的降级状态绝不虚报queued。synthetic-completed同步模式background: false下没有进程内 runner记录被标记为完成但注释声明没有真实工作执行建议使用background: true daemon 做真实执行。因此实操中判断一次 dispatch 是否真正会跑应看响应里的daemonAlive、daemonPid、status与note四个字段而不是只看success: true。hooks_worker-list的响应同样暴露了工程约束total: 12、活跃实例按pending/running/completed/failed分桶统计并附带performanceTargets触发检测 5ms、Worker 派生 50ms、最大并发 10L4491-L4495这些指标为设计循环间隔提供了底层依据。五、Loop 模式与 Cron 模式/ruflo-loop 与 /ruflo-schedule 的选择/ruflo-loop属于会话内循环它依赖ScheduleWakeup在当前会话中自我续期节奏由 270s 缓存感知心跳驱动适合活跃开发期的短周期任务。与之配对的 ruflo-schedule 命令 与 cron-schedule Skill 则面向跨会话持久化场景使用 Claude Code 原生的CronCreate/CronList/CronDelete工具任务可以存活于会话重启之后适合 CI 与监控类用途。/ruflo-schedule的用法与默认 cron 表达式继承自 ruflo-schedule.mdUsage: /schedule worker [cron-expression] Workers: audit, map, optimize, consolidate, testgaps, predict, document, benchmark 默认 cron 表达式: - audit, testgaps: */15 * * * * - optimize, map: */30 * * * * - consolidate, document: 0 * * * *# 示例/schedule audit */15 * * * * # 等价创建: CronCreate(audit, */15 * * * *, Run security audit worker)两种模式的选择原则原文出自 cron-schedule Skill/loop会话内、缓存感知、自我调节。用于活跃开发。CronCreate持久化、可存活重启。用于 CI / 监控。两种模式共享同一套派发语义只是调度器不同CLI 侧是npx claude-flow/clilatest hooks worker dispatch --trigger document --scope apiMCP 侧是mcp tool call hooks_worker-dispatch --json -- {trigger: document, scope: api}ruflo-loop-workers README。另外MCP 工具响应中会附带[LOOP_SUGGESTION]与[CRON_SUGGESTION]提示Skill 明确要求遵循这些提示来完成下一轮排程loop-worker SKILL。六、触发名到消费插件的映射12 个触发名是ruflo-loop-workers与其他插件之间的事件契约ruflo-loop-workers只负责触发与排程具体业务由对应插件消费。完整的归属映射源自 插件 README触发名消费插件用途ultralearnruflo-intelligence从深度代码库扫描构建学习语料optimizeruflo-cost-tracker、ruflo-intelligence性能 成本优化建议consolidateruflo-intelligence、ruflo-agentdbEWC 记忆固化predictruflo-intelligence面向即将到来任务的预测路由auditruflo-security-audit、ruflo-aidefence安全 合规审计mapruflo-knowledge-graph构建/刷新实体-关系知识图谱preloadruflo-core、ruflo-rag-memory高频操作前预热缓存deepdiveruflo-goalsdeep-research多来源调查documentruflo-docs生成 API 文档 漂移检测refactorruflo-jujutsu差异感知的重构建议benchmarkruflo-cost-tracker、ruflo-iot-cognitum性能基准testgapsruflo-testgen覆盖缺口检测 测试生成ADR-0001 将这张表确立为契约级文档消费插件可以据此对各自的触发名做单一权威源校验避免拼写漂移。该 ADR 同时锁定了插件的兼容性承诺claude-flow/cliv3.6、worker-history命名空间的归属声明以及以 smoke 脚本为契约的验收方式。七、worker-history 命名空间与状态存储ruflo-loop-workers独占 AgentDB 的worker-history命名空间kebab-case遵循ruflo-agentdbADR-0001 的命名空间约定pattern、claude-memories、default等保留命名空间不得被遮蔽。该命名空间记录每次派发的事件、耗时、成功/失败判定访问时经由memory_*工具按命名空间路由。从源码结构看smoke.sh 的第 6、7 步专门校验 README 中命名空间约定引用与worker-history声明的完整性说明这一存储契约同样被脚本级验收覆盖。八、前提条件、验证方式与适用边界前提条件以当前仓库文档为准需要ruflo-core插件提供 MCP serverhooks_worker-*工具经其暴露插件文档中以mcp__plugin_ruflo-core_ruflo__hooks_worker-dispatch形式引用CLI 固定为claude-flow/cliv3.6 majorminor 版本线要获得真实的后台执行需守护进程存活claude-flow daemon start否则 dispatch 仅返回no-daemon记录状态见 4.2 节。验证方式插件把 scripts/smoke.sh 定义为契约本身共 12 项结构检查——版本号与关键词mcp、background-workers、cache-aware、schedule-wakeup、2 个 Skill 1 个 Agent 2 个命令齐备且 Frontmatter 合法、5 个hooks_worker-*工具被文档引用、12 个触发名齐全、v3.6 版本固定、ruflo-agentdb命名空间约定引用、worker-history声明、270s 缓存感知说明、ruflo-autopilot心跳交叉引用、触发名→消费插件归属表、ADR-0001 状态为 Accepted、Skill 中无通配符工具授权。预期输出bash plugins/ruflo-loop-workers/scripts/smoke.sh # 期望: 12 passed, 0 failed适用边界/ruflo-loop的价值建立在 270s Prompt 缓存 TTL 这一前提上其收益体现在避免重复计费整段会话上下文若宿主环境的缓存 TTL 不同应按min(270, cache_ttl * 0.9)公式重新计算心跳。同时该命令属于会话内自续期机制会话结束后循环即终止——需要跨重启存活的周期性任务应改用/ruflo-schedule的CronCreate路径或在 CI 中以 CLI 直接轮询hooks worker status。【免费下载链接】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 /ruflo-loop 命令实战：构建缓存感知的 12 类后台 Worker 循环
ruflo /ruflo-loop 命令实战构建缓存感知的 12 类后台 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-loop是 ruflo 仓库中ruflo-loop-workers插件提供的核心命令它从参数中解析出 Worker 名称通过claude-flow/cli的hooks worker dispatch派发一个后台 Worker审计、优化、测试缺口分析等并利用 Claude Code 原生的ScheduleWakeup以 270 秒的缓存感知间隔自我续期。读完本文你将掌握该命令的完整参数语义、12 个 Worker 触发名的优先级体系、270 秒心跳与 Prompt 缓存 TTL 的内在关系以及底层hooks_worker-*MCP 工具在源码中的派发与状态判定机制能够据此在自己的会话中稳定运行后台任务循环。一、/ruflo-loop 命令的定位与入口/ruflo-loop的完整定义见 ruflo-loop.md。它是一个标准的 Claude Code 插件命令文件Frontmatter 声明如下name: ruflo-loop description: Start a Ruflo background worker (audit, optimize, testgaps, etc.) on a recurring schedule命令正文的开头直接使用$ARGUMENTS占位符并指示执行者解析 Worker 名称随后给出全部 12 个可用 Worker 的清单与优先级最后给出调度指令通过npx claude-flow/clilatest hooks worker dispatch --trigger WORKER_NAME运行 Worker然后用 delay 为 270scache-warm的ScheduleWakeup预约下一次迭代。从插件整体结构看见 ruflo-loop-workers 插件 README/ruflo-loop与/ruflo-schedule持久化 Cron 模式共同构成该插件的两个命令面并配套 2 个 Skillloop-worker、cron-schedule和 1 个协调 Agentloop-worker-coordinator。整个插件的运行前提是安装ruflo-core插件它提供 MCP server且 CLI 版本固定为claude-flow/cliv3.6 主线。二、12 个后台 Worker触发名与优先级命令文档列出了全部 12 个 Worker按优先级标注这是/ruflo-loop命令参数的合法取值全集Worker 触发名优先级职责auditcritical安全扫描optimizehigh性能优化ultralearnnormal深度知识获取predictnormal预测性预加载mapnormal代码库映射deepdivenormal深度代码分析documentnormal自动文档生成refactornormal重构建议benchmarknormal性能基准测试testgapsnormal测试覆盖分析consolidatelow记忆固化preloadlow资源预加载这份清单并非文档层面的约定而是在 CLI 源码中被当作契约来强制的。hooks_worker-dispatch工具的输入参数 schema 中trigger字段的enum恰好就是这 12 个取值见 hooks-tools.tstrigger: { type: string, description: Worker trigger type, enum: [ultralearn, optimize, consolidate, predict, audit, map, preload, deepdive, document, refactor, benchmark, testgaps], },如果传入了不存在的触发名handler 会直接返回Unknown worker trigger错误并附带全部可用触发名列表方便调用方自查hooks-tools.ts。此外插件的验收脚本 smoke.sh 第 4 步会逐一检查这 12 个触发名是否都被 README 记录任何遗漏都会导致契约验证失败——可以推断文档清单与源码 enum 的一致性是被 CI 级脚本锁定的。三、核心调度循环dispatch 270s 缓存感知心跳/ruflo-loop命令的调度闭环由两步组成# 1. 派发 Worker npx claude-flow/clilatest hooks worker dispatch --trigger WORKER_NAME// 2. 预约下一轮迭代270s缓存处于热状态 ScheduleWakeup({ delaySeconds: 270, reason: next WORKER_NAME iteration })这里的270 秒是整个机制最关键的设计参数其推导过程在仓库文档中有明确解释ruflo-loop-workers README、loop-worker SKILLPrompt 缓存的 TTL 约为 5 分钟300s。若心跳间隔超过 300s下一次唤醒就会发生缓存失效cache-miss多付一次完整上下文的成本而直接取整到 5 分钟则落在临界且最差的区间。因此推荐回退心跳为270 秒——严格小于 5 分钟 TTL让每次唤醒都能读到缓存中的会话上下文。更一般的延迟公式为min(270, cache_ttl * 0.9)即以缓存 TTL 的 90% 作为安全边界loop-worker SKILL。该 270s 心跳契约的属主是ruflo-autopilot插件的 ADR-0001plugins/ruflo-autopilot/docs/adrs/0001-autopilot-contract.mdruflo-loop-workers是承载它的执行基座对于事件驱动的循环建议挂载一个Monitor把 270s 唤醒仅作为安全网。每个 Worker 在两种执行模式下的推荐节奏完整定义在协调 Agent loop-worker-coordinator.md 中Worker优先级触发名loop 间隔Cron 表达式auditcriticalaudit270s*/15 * * * *optimizehighoptimize270s*/30 * * * *consolidatelowconsolidate600s0 * * * *predictnormalpredict270s*/15 * * * *mapnormalmap270s*/30 * * * *testgapsnormaltestgaps270s*/15 * * * *documentnormaldocument600s0 */2 * * *benchmarknormalbenchmark600s0 * * * *deepdivenormaldeepdive270s*/30 * * * *refactornormalrefactor270s*/30 * * * *ultralearnnormalultralearn270s*/15 * * * *preloadlowpreload600s0 * * * *协调 Agent 自身还定义了一个标准工作流先用npx claude-flow/clilatest hooks worker status检查当前 Worker 状态再hooks worker dispatch --trigger WORKER_NAME派发最后按执行模式loop / cron排程下一次检查任务完成后还会通过hooks post-task将成功模式写入patterns命名空间做神经学习沉淀。四、源码层hooks_worker-* 工具的实现细节/ruflo-loop命令最终落到 CLI 侧的 5 个 MCP 工具上全部定义在 hooks-tools.ts 中工具位置用途hooks_worker-listL4453列出 12 个 Worker 及其触发器、状态与能力hooks_worker-dispatchL4502以--trigger worker-name派发一次运行可选--scope/contexthooks_worker-statusL4641查询指定或全部活动 Worker 的运行状态hooks_worker-detectL4699依据上下文检测应当触发哪些 Workerhooks_worker-cancelL5119取消一个运行中的 Worker4.1 dispatch 的入参与默认值从hooks_worker-dispatch的 handler 源码hooks-tools.ts可以读出几个实操相关的细节trigger是唯一必填项context用于传入文件路径或主题未提供时默认default且会经过文本校验validateText防止注入式参数。priority缺省时回退到WORKER_CONFIGS[trigger]中该 Worker 的静态优先级再兜底为normal——这与第二节表中每个 Worker 的优先级标注是对应的。background默认值为true源码为params.background ! false即派发默认非阻塞若显式传false进入同步模式会得到一个诚实的合成完成状态见下。Worker ID 的生成格式为worker_${trigger}_${自增计数}_${时间戳(base36)}L4534可在hooks_worker-status查询时作为workerId使用。4.2 诚实状态queued / no-daemon / synthetic-completeddispatch handler 中最值得注意的是一段带 ADR 注释的实现hooks-tools.ts源码注释引用 ADR-093 F2 与 issue #1845它不再对一个从未真正运行的 Worker 返回status: completed而是依据守护进程daemon的实际存在情况给出四类诚实判定no-daemon读取项目目录下.claude-flow/daemon.pidL4541若 PID 文件不存在或进程探活失败则说明没有可用的 Worker 守护进程。此时派发只是被记录在进程内不会有任何真实工作执行响应中的note会明确提示运行claude-flow daemon start。queueddaemon 存活且background为真时dispatcher 会把任务写成磁盘上的持久队列文件.claude-flow/daemon-queue/${workerId}.json内含workerId、trigger、context、priority、enqueuedAt见 L4587-L4604。守护进程每 5 秒轮询该目录处理完的条目移入.claude-flow/daemon-queue/.processed/。note字段明确告知轮询hooks_worker-status直到status completed——这正对应/ruflo-loop循环中下一轮唤醒前的状态检查动作。mcp-onlydaemon 存活但队列文件写入失败文件系统错误时的降级状态绝不虚报queued。synthetic-completed同步模式background: false下没有进程内 runner记录被标记为完成但注释声明没有真实工作执行建议使用background: true daemon 做真实执行。因此实操中判断一次 dispatch 是否真正会跑应看响应里的daemonAlive、daemonPid、status与note四个字段而不是只看success: true。hooks_worker-list的响应同样暴露了工程约束total: 12、活跃实例按pending/running/completed/failed分桶统计并附带performanceTargets触发检测 5ms、Worker 派生 50ms、最大并发 10L4491-L4495这些指标为设计循环间隔提供了底层依据。五、Loop 模式与 Cron 模式/ruflo-loop 与 /ruflo-schedule 的选择/ruflo-loop属于会话内循环它依赖ScheduleWakeup在当前会话中自我续期节奏由 270s 缓存感知心跳驱动适合活跃开发期的短周期任务。与之配对的 ruflo-schedule 命令 与 cron-schedule Skill 则面向跨会话持久化场景使用 Claude Code 原生的CronCreate/CronList/CronDelete工具任务可以存活于会话重启之后适合 CI 与监控类用途。/ruflo-schedule的用法与默认 cron 表达式继承自 ruflo-schedule.mdUsage: /schedule worker [cron-expression] Workers: audit, map, optimize, consolidate, testgaps, predict, document, benchmark 默认 cron 表达式: - audit, testgaps: */15 * * * * - optimize, map: */30 * * * * - consolidate, document: 0 * * * *# 示例/schedule audit */15 * * * * # 等价创建: CronCreate(audit, */15 * * * *, Run security audit worker)两种模式的选择原则原文出自 cron-schedule Skill/loop会话内、缓存感知、自我调节。用于活跃开发。CronCreate持久化、可存活重启。用于 CI / 监控。两种模式共享同一套派发语义只是调度器不同CLI 侧是npx claude-flow/clilatest hooks worker dispatch --trigger document --scope apiMCP 侧是mcp tool call hooks_worker-dispatch --json -- {trigger: document, scope: api}ruflo-loop-workers README。另外MCP 工具响应中会附带[LOOP_SUGGESTION]与[CRON_SUGGESTION]提示Skill 明确要求遵循这些提示来完成下一轮排程loop-worker SKILL。六、触发名到消费插件的映射12 个触发名是ruflo-loop-workers与其他插件之间的事件契约ruflo-loop-workers只负责触发与排程具体业务由对应插件消费。完整的归属映射源自 插件 README触发名消费插件用途ultralearnruflo-intelligence从深度代码库扫描构建学习语料optimizeruflo-cost-tracker、ruflo-intelligence性能 成本优化建议consolidateruflo-intelligence、ruflo-agentdbEWC 记忆固化predictruflo-intelligence面向即将到来任务的预测路由auditruflo-security-audit、ruflo-aidefence安全 合规审计mapruflo-knowledge-graph构建/刷新实体-关系知识图谱preloadruflo-core、ruflo-rag-memory高频操作前预热缓存deepdiveruflo-goalsdeep-research多来源调查documentruflo-docs生成 API 文档 漂移检测refactorruflo-jujutsu差异感知的重构建议benchmarkruflo-cost-tracker、ruflo-iot-cognitum性能基准testgapsruflo-testgen覆盖缺口检测 测试生成ADR-0001 将这张表确立为契约级文档消费插件可以据此对各自的触发名做单一权威源校验避免拼写漂移。该 ADR 同时锁定了插件的兼容性承诺claude-flow/cliv3.6、worker-history命名空间的归属声明以及以 smoke 脚本为契约的验收方式。七、worker-history 命名空间与状态存储ruflo-loop-workers独占 AgentDB 的worker-history命名空间kebab-case遵循ruflo-agentdbADR-0001 的命名空间约定pattern、claude-memories、default等保留命名空间不得被遮蔽。该命名空间记录每次派发的事件、耗时、成功/失败判定访问时经由memory_*工具按命名空间路由。从源码结构看smoke.sh 的第 6、7 步专门校验 README 中命名空间约定引用与worker-history声明的完整性说明这一存储契约同样被脚本级验收覆盖。八、前提条件、验证方式与适用边界前提条件以当前仓库文档为准需要ruflo-core插件提供 MCP serverhooks_worker-*工具经其暴露插件文档中以mcp__plugin_ruflo-core_ruflo__hooks_worker-dispatch形式引用CLI 固定为claude-flow/cliv3.6 majorminor 版本线要获得真实的后台执行需守护进程存活claude-flow daemon start否则 dispatch 仅返回no-daemon记录状态见 4.2 节。验证方式插件把 scripts/smoke.sh 定义为契约本身共 12 项结构检查——版本号与关键词mcp、background-workers、cache-aware、schedule-wakeup、2 个 Skill 1 个 Agent 2 个命令齐备且 Frontmatter 合法、5 个hooks_worker-*工具被文档引用、12 个触发名齐全、v3.6 版本固定、ruflo-agentdb命名空间约定引用、worker-history声明、270s 缓存感知说明、ruflo-autopilot心跳交叉引用、触发名→消费插件归属表、ADR-0001 状态为 Accepted、Skill 中无通配符工具授权。预期输出bash plugins/ruflo-loop-workers/scripts/smoke.sh # 期望: 12 passed, 0 failed适用边界/ruflo-loop的价值建立在 270s Prompt 缓存 TTL 这一前提上其收益体现在避免重复计费整段会话上下文若宿主环境的缓存 TTL 不同应按min(270, cache_ttl * 0.9)公式重新计算心跳。同时该命令属于会话内自续期机制会话结束后循环即终止——需要跨重启存活的周期性任务应改用/ruflo-schedule的CronCreate路径或在 CI 中以 CLI 直接轮询hooks worker status。【免费下载链接】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），仅供参考