ruflo /ruflo-loop 命令實(shí)戰(zhàn)構(gòu)建緩存感知的 12 類后臺(tái) Worker 循環(huán)【免費(fèi)下載鏈接】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項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/ruflo/ruflo-loop是 ruflo 倉(cāng)庫(kù)中ruflo-loop-workers插件提供的核心命令它從參數(shù)中解析出 Worker 名稱通過(guò)claude-flow/cli的hooks worker dispatch派發(fā)一個(gè)后臺(tái) Worker審計(jì)、優(yōu)化、測(cè)試缺口分析等并利用 Claude Code 原生的ScheduleWakeup以 270 秒的緩存感知間隔自我續(xù)期。讀完本文你將掌握該命令的完整參數(shù)語(yǔ)義、12 個(gè) Worker 觸發(fā)名的優(yōu)先級(jí)體系、270 秒心跳與 Prompt 緩存 TTL 的內(nèi)在關(guān)系以及底層hooks_worker-*MCP 工具在源碼中的派發(fā)與狀態(tài)判定機(jī)制能夠據(jù)此在自己的會(huì)話中穩(wěn)定運(yùn)行后臺(tái)任務(wù)循環(huán)。一、/ruflo-loop 命令的定位與入口/ruflo-loop的完整定義見(jiàn) ruflo-loop.md。它是一個(gè)標(biāo)準(zhǔn)的 Claude Code 插件命令文件Frontmatter 聲明如下name: ruflo-loop description: Start a Ruflo background worker (audit, optimize, testgaps, etc.) on a recurring schedule命令正文的開(kāi)頭直接使用$ARGUMENTS占位符并指示執(zhí)行者解析 Worker 名稱隨后給出全部 12 個(gè)可用 Worker 的清單與優(yōu)先級(jí)最后給出調(diào)度指令通過(guò)npx claude-flow/clilatest hooks worker dispatch --trigger WORKER_NAME運(yùn)行 Worker然后用 delay 為 270scache-warm的ScheduleWakeup預(yù)約下一次迭代。從插件整體結(jié)構(gòu)看見(jiàn) ruflo-loop-workers 插件 README/ruflo-loop與/ruflo-schedule持久化 Cron 模式共同構(gòu)成該插件的兩個(gè)命令面并配套 2 個(gè) Skillloop-worker、cron-schedule和 1 個(gè)協(xié)調(diào) Agentloop-worker-coordinator。整個(gè)插件的運(yùn)行前提是安裝ruflo-core插件它提供 MCP server且 CLI 版本固定為claude-flow/cliv3.6 主線。二、12 個(gè)后臺(tái) Worker觸發(fā)名與優(yōu)先級(jí)命令文檔列出了全部 12 個(gè) Worker按優(yōu)先級(jí)標(biāo)注這是/ruflo-loop命令參數(shù)的合法取值全集Worker 觸發(fā)名優(yōu)先級(jí)職責(zé)auditcritical安全掃描optimizehigh性能優(yōu)化ultralearnnormal深度知識(shí)獲取predictnormal預(yù)測(cè)性預(yù)加載mapnormal代碼庫(kù)映射deepdivenormal深度代碼分析documentnormal自動(dòng)文檔生成refactornormal重構(gòu)建議benchmarknormal性能基準(zhǔn)測(cè)試testgapsnormal測(cè)試覆蓋分析consolidatelow記憶固化preloadlow資源預(yù)加載這份清單并非文檔層面的約定而是在 CLI 源碼中被當(dāng)作契約來(lái)強(qiáng)制的。hooks_worker-dispatch工具的輸入?yún)?shù) schema 中trigger字段的enum恰好就是這 12 個(gè)取值見(jiàn) hooks-tools.tstrigger: { type: string, description: Worker trigger type, enum: [ultralearn, optimize, consolidate, predict, audit, map, preload, deepdive, document, refactor, benchmark, testgaps], },如果傳入了不存在的觸發(fā)名handler 會(huì)直接返回Unknown worker trigger錯(cuò)誤并附帶全部可用觸發(fā)名列表方便調(diào)用方自查hooks-tools.ts。此外插件的驗(yàn)收腳本 smoke.sh 第 4 步會(huì)逐一檢查這 12 個(gè)觸發(fā)名是否都被 README 記錄任何遺漏都會(huì)導(dǎo)致契約驗(yàn)證失敗——可以推斷文檔清單與源碼 enum 的一致性是被 CI 級(jí)腳本鎖定的。三、核心調(diào)度循環(huán)dispatch 270s 緩存感知心跳/ruflo-loop命令的調(diào)度閉環(huán)由兩步組成# 1. 派發(fā) Worker npx claude-flow/clilatest hooks worker dispatch --trigger WORKER_NAME// 2. 預(yù)約下一輪迭代270s緩存處于熱狀態(tài) ScheduleWakeup({ delaySeconds: 270, reason: next WORKER_NAME iteration })這里的270 秒是整個(gè)機(jī)制最關(guān)鍵的設(shè)計(jì)參數(shù)其推導(dǎo)過(guò)程在倉(cāng)庫(kù)文檔中有明確解釋ruflo-loop-workers README、loop-worker SKILLPrompt 緩存的 TTL 約為 5 分鐘300s。若心跳間隔超過(guò) 300s下一次喚醒就會(huì)發(fā)生緩存失效cache-miss多付一次完整上下文的成本而直接取整到 5 分鐘則落在臨界且最差的區(qū)間。因此推薦回退心跳為270 秒——嚴(yán)格小于 5 分鐘 TTL讓每次喚醒都能讀到緩存中的會(huì)話上下文。更一般的延遲公式為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是承載它的執(zhí)行基座對(duì)于事件驅(qū)動(dòng)的循環(huán)建議掛載一個(gè)Monitor把 270s 喚醒僅作為安全網(wǎng)。每個(gè) Worker 在兩種執(zhí)行模式下的推薦節(jié)奏完整定義在協(xié)調(diào) Agent loop-worker-coordinator.md 中Worker優(yōu)先級(jí)觸發(fā)名loop 間隔Cron 表達(dá)式auditcriticalaudit270s*/15 * * * *optimizehighoptimize270s*/30 * * * *consolidatelowconsolidate600s0 * * * *predictnormalpredict270s*/15 * * * *mapnormalmap270s*/30 * * * *testgapsnormaltestgaps270s*/15 * * * *documentnormaldocument600s0 */2 * * *benchmarknormalbenchmark600s0 * * * *deepdivenormaldeepdive270s*/30 * * * *refactornormalrefactor270s*/30 * * * *ultralearnnormalultralearn270s*/15 * * * *preloadlowpreload600s0 * * * *協(xié)調(diào) Agent 自身還定義了一個(gè)標(biāo)準(zhǔn)工作流先用npx claude-flow/clilatest hooks worker status檢查當(dāng)前 Worker 狀態(tài)再hooks worker dispatch --trigger WORKER_NAME派發(fā)最后按執(zhí)行模式loop / cron排程下一次檢查任務(wù)完成后還會(huì)通過(guò)hooks post-task將成功模式寫(xiě)入patterns命名空間做神經(jīng)學(xué)習(xí)沉淀。四、源碼層hooks_worker-* 工具的實(shí)現(xiàn)細(xì)節(jié)/ruflo-loop命令最終落到 CLI 側(cè)的 5 個(gè) MCP 工具上全部定義在 hooks-tools.ts 中工具位置用途hooks_worker-listL4453列出 12 個(gè) Worker 及其觸發(fā)器、狀態(tài)與能力hooks_worker-dispatchL4502以--trigger worker-name派發(fā)一次運(yùn)行可選--scope/contexthooks_worker-statusL4641查詢指定或全部活動(dòng) Worker 的運(yùn)行狀態(tài)hooks_worker-detectL4699依據(jù)上下文檢測(cè)應(yīng)當(dāng)觸發(fā)哪些 Workerhooks_worker-cancelL5119取消一個(gè)運(yùn)行中的 Worker4.1 dispatch 的入?yún)⑴c默認(rèn)值從hooks_worker-dispatch的 handler 源碼hooks-tools.ts可以讀出幾個(gè)實(shí)操相關(guān)的細(xì)節(jié)trigger是唯一必填項(xiàng)context用于傳入文件路徑或主題未提供時(shí)默認(rèn)default且會(huì)經(jīng)過(guò)文本校驗(yàn)validateText防止注入式參數(shù)。priority缺省時(shí)回退到WORKER_CONFIGS[trigger]中該 Worker 的靜態(tài)優(yōu)先級(jí)再兜底為normal——這與第二節(jié)表中每個(gè) Worker 的優(yōu)先級(jí)標(biāo)注是對(duì)應(yīng)的。background默認(rèn)值為true源碼為params.background ! false即派發(fā)默認(rèn)非阻塞若顯式傳false進(jìn)入同步模式會(huì)得到一個(gè)誠(chéng)實(shí)的合成完成狀態(tài)見(jiàn)下。Worker ID 的生成格式為worker_${trigger}_${自增計(jì)數(shù)}_${時(shí)間戳(base36)}L4534可在hooks_worker-status查詢時(shí)作為workerId使用。4.2 誠(chéng)實(shí)狀態(tài)queued / no-daemon / synthetic-completeddispatch handler 中最值得注意的是一段帶 ADR 注釋的實(shí)現(xiàn)hooks-tools.ts源碼注釋引用 ADR-093 F2 與 issue #1845它不再對(duì)一個(gè)從未真正運(yùn)行的 Worker 返回status: completed而是依據(jù)守護(hù)進(jìn)程daemon的實(shí)際存在情況給出四類誠(chéng)實(shí)判定no-daemon讀取項(xiàng)目目錄下.claude-flow/daemon.pidL4541若 PID 文件不存在或進(jìn)程探活失敗則說(shuō)明沒(méi)有可用的 Worker 守護(hù)進(jìn)程。此時(shí)派發(fā)只是被記錄在進(jìn)程內(nèi)不會(huì)有任何真實(shí)工作執(zhí)行響應(yīng)中的note會(huì)明確提示運(yùn)行claude-flow daemon start。queueddaemon 存活且background為真時(shí)dispatcher 會(huì)把任務(wù)寫(xiě)成磁盤(pán)上的持久隊(duì)列文件.claude-flow/daemon-queue/${workerId}.json內(nèi)含workerId、trigger、context、priority、enqueuedAt見(jiàn) L4587-L4604。守護(hù)進(jìn)程每 5 秒輪詢?cè)撃夸浱幚硗甑臈l目移入.claude-flow/daemon-queue/.processed/。note字段明確告知輪詢hooks_worker-status直到status completed——這正對(duì)應(yīng)/ruflo-loop循環(huán)中下一輪喚醒前的狀態(tài)檢查動(dòng)作。mcp-onlydaemon 存活但隊(duì)列文件寫(xiě)入失敗文件系統(tǒng)錯(cuò)誤時(shí)的降級(jí)狀態(tài)絕不虛報(bào)queued。synthetic-completed同步模式background: false下沒(méi)有進(jìn)程內(nèi) runner記錄被標(biāo)記為完成但注釋聲明沒(méi)有真實(shí)工作執(zhí)行建議使用background: true daemon 做真實(shí)執(zhí)行。因此實(shí)操中判斷一次 dispatch 是否真正會(huì)跑應(yīng)看響應(yīng)里的daemonAlive、daemonPid、status與note四個(gè)字段而不是只看success: true。hooks_worker-list的響應(yīng)同樣暴露了工程約束total: 12、活躍實(shí)例按pending/running/completed/failed分桶統(tǒng)計(jì)并附帶performanceTargets觸發(fā)檢測(cè) 5ms、Worker 派生 50ms、最大并發(fā) 10L4491-L4495這些指標(biāo)為設(shè)計(jì)循環(huán)間隔提供了底層依據(jù)。五、Loop 模式與 Cron 模式/ruflo-loop 與 /ruflo-schedule 的選擇/ruflo-loop屬于會(huì)話內(nèi)循環(huán)它依賴ScheduleWakeup在當(dāng)前會(huì)話中自我續(xù)期節(jié)奏由 270s 緩存感知心跳驅(qū)動(dòng)適合活躍開(kāi)發(fā)期的短周期任務(wù)。與之配對(duì)的 ruflo-schedule 命令 與 cron-schedule Skill 則面向跨會(huì)話持久化場(chǎng)景使用 Claude Code 原生的CronCreate/CronList/CronDelete工具任務(wù)可以存活于會(huì)話重啟之后適合 CI 與監(jiān)控類用途。/ruflo-schedule的用法與默認(rèn) cron 表達(dá)式繼承自 ruflo-schedule.mdUsage: /schedule worker [cron-expression] Workers: audit, map, optimize, consolidate, testgaps, predict, document, benchmark 默認(rèn) cron 表達(dá)式: - audit, testgaps: */15 * * * * - optimize, map: */30 * * * * - consolidate, document: 0 * * * *# 示例/schedule audit */15 * * * * # 等價(jià)創(chuàng)建: CronCreate(audit, */15 * * * *, Run security audit worker)兩種模式的選擇原則原文出自 cron-schedule Skill/loop會(huì)話內(nèi)、緩存感知、自我調(diào)節(jié)。用于活躍開(kāi)發(fā)。CronCreate持久化、可存活重啟。用于 CI / 監(jiān)控。兩種模式共享同一套派發(fā)語(yǔ)義只是調(diào)度器不同CLI 側(cè)是npx claude-flow/clilatest hooks worker dispatch --trigger document --scope apiMCP 側(cè)是mcp tool call hooks_worker-dispatch --json -- {trigger: document, scope: api}ruflo-loop-workers README。另外MCP 工具響應(yīng)中會(huì)附帶[LOOP_SUGGESTION]與[CRON_SUGGESTION]提示Skill 明確要求遵循這些提示來(lái)完成下一輪排程loop-worker SKILL。六、觸發(fā)名到消費(fèi)插件的映射12 個(gè)觸發(fā)名是ruflo-loop-workers與其他插件之間的事件契約ruflo-loop-workers只負(fù)責(zé)觸發(fā)與排程具體業(yè)務(wù)由對(duì)應(yīng)插件消費(fèi)。完整的歸屬映射源自 插件 README觸發(fā)名消費(fèi)插件用途ultralearnruflo-intelligence從深度代碼庫(kù)掃描構(gòu)建學(xué)習(xí)語(yǔ)料optimizeruflo-cost-tracker、ruflo-intelligence性能 成本優(yōu)化建議consolidateruflo-intelligence、ruflo-agentdbEWC 記憶固化predictruflo-intelligence面向即將到來(lái)任務(wù)的預(yù)測(cè)路由auditruflo-security-audit、ruflo-aidefence安全 合規(guī)審計(jì)mapruflo-knowledge-graph構(gòu)建/刷新實(shí)體-關(guān)系知識(shí)圖譜preloadruflo-core、ruflo-rag-memory高頻操作前預(yù)熱緩存deepdiveruflo-goalsdeep-research多來(lái)源調(diào)查documentruflo-docs生成 API 文檔 漂移檢測(cè)refactorruflo-jujutsu差異感知的重構(gòu)建議benchmarkruflo-cost-tracker、ruflo-iot-cognitum性能基準(zhǔn)testgapsruflo-testgen覆蓋缺口檢測(cè) 測(cè)試生成ADR-0001 將這張表確立為契約級(jí)文檔消費(fèi)插件可以據(jù)此對(duì)各自的觸發(fā)名做單一權(quán)威源校驗(yàn)避免拼寫(xiě)漂移。該 ADR 同時(shí)鎖定了插件的兼容性承諾claude-flow/cliv3.6、worker-history命名空間的歸屬聲明以及以 smoke 腳本為契約的驗(yàn)收方式。七、worker-history 命名空間與狀態(tài)存儲(chǔ)ruflo-loop-workers獨(dú)占 AgentDB 的worker-history命名空間kebab-case遵循ruflo-agentdbADR-0001 的命名空間約定pattern、claude-memories、default等保留命名空間不得被遮蔽。該命名空間記錄每次派發(fā)的事件、耗時(shí)、成功/失敗判定訪問(wèn)時(shí)經(jīng)由memory_*工具按命名空間路由。從源碼結(jié)構(gòu)看smoke.sh 的第 6、7 步專門校驗(yàn) README 中命名空間約定引用與worker-history聲明的完整性說(shuō)明這一存儲(chǔ)契約同樣被腳本級(jí)驗(yàn)收覆蓋。八、前提條件、驗(yàn)證方式與適用邊界前提條件以當(dāng)前倉(cāng)庫(kù)文檔為準(zhǔn)需要ruflo-core插件提供 MCP serverhooks_worker-*工具經(jīng)其暴露插件文檔中以mcp__plugin_ruflo-core_ruflo__hooks_worker-dispatch形式引用CLI 固定為claude-flow/cliv3.6 majorminor 版本線要獲得真實(shí)的后臺(tái)執(zhí)行需守護(hù)進(jìn)程存活claude-flow daemon start否則 dispatch 僅返回no-daemon記錄狀態(tài)見(jiàn) 4.2 節(jié)。驗(yàn)證方式插件把 scripts/smoke.sh 定義為契約本身共 12 項(xiàng)結(jié)構(gòu)檢查——版本號(hào)與關(guān)鍵詞mcp、background-workers、cache-aware、schedule-wakeup、2 個(gè) Skill 1 個(gè) Agent 2 個(gè)命令齊備且 Frontmatter 合法、5 個(gè)hooks_worker-*工具被文檔引用、12 個(gè)觸發(fā)名齊全、v3.6 版本固定、ruflo-agentdb命名空間約定引用、worker-history聲明、270s 緩存感知說(shuō)明、ruflo-autopilot心跳交叉引用、觸發(fā)名→消費(fèi)插件歸屬表、ADR-0001 狀態(tài)為 Accepted、Skill 中無(wú)通配符工具授權(quán)。預(yù)期輸出bash plugins/ruflo-loop-workers/scripts/smoke.sh # 期望: 12 passed, 0 failed適用邊界/ruflo-loop的價(jià)值建立在 270s Prompt 緩存 TTL 這一前提上其收益體現(xiàn)在避免重復(fù)計(jì)費(fèi)整段會(huì)話上下文若宿主環(huán)境的緩存 TTL 不同應(yīng)按min(270, cache_ttl * 0.9)公式重新計(jì)算心跳。同時(shí)該命令屬于會(huì)話內(nèi)自續(xù)期機(jī)制會(huì)話結(jié)束后循環(huán)即終止——需要跨重啟存活的周期性任務(wù)應(yīng)改用/ruflo-schedule的CronCreate路徑或在 CI 中以 CLI 直接輪詢hooks worker status。【免費(fèi)下載鏈接】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項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/ruflo創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考