Ruflo（ruvnet/ruflo）：给编码智能体装一套蜂群神经系统，并用仓库内审计把「150× 加速」修正到 1.9×

一、导读

Ruflo（原名 Claude Flow）是当前 GitHub 上星数最高的智能体编排框架之一——78,194 星、9,197 fork、MIT 许可，一周涨星 3,143。它做的事一句话能说完：给 Claude Code 和 Codex 装一套「神经系统」，让单个编码助手变成共享记忆、能从结果里学习、还能跨机器协作的蜂群。

但它真正值得写，不是因为「100+ 智能体」这类数字，而是因为它是这个赛道里唯一把「哪些能力是真的、哪些是营销」写成仓库内审计报告的项目。2026 年 5 月它自己委托的审计把 HNSW 加速从宣称的「150×–12,500×」修正到实测 1.9×（N=20k），并查出 Flash Attention 的「2.49×–7.47×」在源码里是 2.49 + Math.random() * 4.98 运行时随机生成的。读懂这份账本，比读懂它的架构更能帮你判断 2026 年智能体编排工具的真实水位。

二、项目速览

项目	内容
仓库	`ruvnet/ruflo`（原名 `ruvnet/claude-flow`，旧地址 301 跳转）
作者	Reuven Cohen（rUv），个人项目，非公司产品
主语言 / 许可	TypeScript / MIT
Star / Fork	78,194 / 9,197（GitHub API，2026-10-21 抓取）
一周涨星	3,143（Trending weekly，2026-10-21 抓取）
首次提交	2025-06-02（作为 Claude Flow）；最近推送 2026-10-21
最新版本	v3.59.12（2026-10-21）——当天连发 11 个 Release（v3.59.2 → v3.59.12）
能力面	323 个 MCP 工具、45 个 CLI 顶层命令、33 个插件、45 个 agent 定义（`docs/STATUS.md` @ ruflo@3.10.2）
测试基线	CLI vitest 1999/1999 通过；federation 插件 366/366 通过
npm 下载	`ruflo` 周下载 36,034（2026-10-12 ~ 10-18）
开放 Issue	973（2026-10-21 抓取）

一句话概括：它不是又一个「多智能体框架」，而是挂在 Claude Code 外面的一层执行层（harness）——模型负责写，它负责给模型工具、记忆、循环、沙箱和边界。

三、为什么是它：问题背景与定位

第一，「模型 + Harness」正在成为编码智能体的真实竞争面。 2026 年一个被反复验证的判断是：同一个模型配上不同的 harness，产出质量可以差出一倍。Claude Code 本身已经是一个 harness，但它的边界很清楚——单上下文、会话级记忆、没有跨机协作。Ruflo 押的注是：这些缺口不该由模型厂商补，而应该由一层可插拔的编排层补。它的 README 把这句话写成了定义式：Agent = Model + Harness。

第二，它踩中了「多智能体到底有没有用」这个争议点。 2026 年关于多智能体的讨论已经冷静下来——token 成本约 15 倍、单 agent 约 4 倍，滥用是常态。Ruflo 的立场是「最大主义」：100+ 智能体、蜂群拓扑、拜占庭共识、Raft、Gossip 全上。这在工程上是双刃剑：它可能是这个赛道的能力天花板，也可能是最过度设计的工具——第三方评论的原话是「要么是软件构建的未来，要么是人类历史上最过度设计的工具，也可能两者都是」。

第三，涨星动因里有一半是「继承」而非「采用」。 这一点必须说清楚：github.com/ruvnet/claude-flow 会 301 跳转到 ruvnet/ruflo，README 里的 star badge 至今仍指向 claude-flow 的 shields URL。所以 78,194 这个数字度量的是仓库在 Claude Flow 名下的历史 + 一次改名，而不是 Ruflo 这个产品的采用量。第三方独立评估（tomrochette）指出：它的 Hacker News 足迹只有一个 3 分的 Show HN 和一个 1 分的「有人用 ruflo 吗」帖子——3 分对 7.8 万星，是该评估者在这个品类里量到的最宽落差。

第四，它的诚实度曲线是罕见的。 2026 年 3 月用户提交安全审计（issue #1375），4 月出现独立审计指控「300+ MCP 工具里 99% 是表演」，5 月项目自己委托了测量型审计并把结论提交进仓库——包括对自己不利的部分。一个项目愿意把「我宣传的数字是假的」写进自己的仓库，这件事本身比它的任何 benchmark 都更有信息量。

四、【重点】架构原理

4.1 整体架构：五层单向数据流

graph TD
    U["用户 / Claude Code / Codex"] --> O["编排层<br/>MCP Server · Router · 27 Hooks"]
    O --> S["蜂群协调层<br/>Queen · Topology · Consensus"]
    S --> A["Agent 层<br/>100+ 特化 agent 定义"]
    A --> M["记忆与学习层<br/>AgentDB · HNSW · SONA · ReasoningBank"]
    M --> P["LLM Provider 层<br/>Claude · GPT · Gemini · Cohere · Ollama"]
    M -.经验回流.-> O
    A --> W["WASM 内核<br/>策略引擎 · 嵌入 · 证明系统"]
    O --> F["联邦层<br/>mTLS + ed25519 · PII 过滤"]
    F -.跨机协作.-> S

README 给出的文字版更简洁：User → Ruflo (CLI/MCP) → Router → Swarm → Agents → Memory → LLM Providers，并特别注明「记忆会把有用的经验喂回路由」——这条回流边是整个设计的核心，也是它区别于普通编排框架的地方。

4.2 分层模块拆解

层	职责	关键接口
编排层	接住 Claude Code 的工具调用，做任务路由与钩子触发	MCP server（323 工具）、`ruflo hooks`（17 个子命令）
蜂群协调层	拓扑选择、共识裁决、任务认领	`swarm_init` / `swarm_status` / `agent_spawn` / `agent_execute`
Agent 层	45 个特化角色定义（coder、tester、reviewer、security-architect…）	`plugins//agents/.md`
记忆与学习层	向量检索、轨迹学习、模式置信度更新	`memory_store` / `memory_search`、`neural_train`
Provider 层	多厂商路由与故障转移	`ruflo providers`（5 个子命令）

值得注意的是它的安装路径有两条，且工具名不通用：走 Claude Code 插件路径时，ruflo-core 会注册自己的 MCP server，工具名形如 mcp__plugin_ruflo-core_ruflo__memory_store；走 CLI 路径（npx ruflo init）时才是裸名 memory_store、swarm_init、agent_spawn。README 明确警告：针对裸名写的脚本或 agent 定义，在插件安装下会静默解析不到任何东西，且不会报错告诉你走错了哪条路。 这是上手时最容易踩的坑。

4.3 核心机制一：蜂群拓扑与共识

Ruflo 提供 6 种拓扑（hierarchical、mesh、hierarchical-mesh、ring、star、adaptive）和 5 种共识（Byzantine、Raft、Gossip、CRDT、Quorum）。但真正有价值的是它写进 CLAUDE.md 的反漂移默认值：

设置	值	理由
topology	hierarchical	协调者能抓住偏离
maxAgents	6–8	团队越小，漂移越少
strategy	specialized	角色清晰、不重叠
consensus	raft	由 leader 维护权威状态
memory	hybrid	SQLite + AgentDB，兼顾快与持久

这份默认值本身就是一条经验结论：「10+ agent 团队用 hierarchical-mesh」这类建议，说明作者清楚蜂群规模与协调成本的关系。共识算法的选择也透露了设计意图——Raft 管 leader 选举、Byzantine 处理会撒谎的节点、Gossip 做最终一致的状态传播，这是把分布式系统那套容错工程直接搬到了 agent 协调上。

4.4 核心机制二：自学习闭环——审计确认为「真实」的部分

这是 Ruflo 最核心也最容易被误解的机制。它由三块组成：SONA（自优化模式学习）、ReasoningBank（成功轨迹的可复用记忆）、EWC++（弹性权重巩固，防止学新忘旧）。

2026-05-29 的仓库内审计给出了直接测量结果，结论是学习闭环是真的：

一次成功判定会把某个模式的置信度从 0.906 提升到 1.0，一次失败把它降到 0.952，且跨进程持久化；
Q-learning 的路由反馈确实改变了下一次的路由决策；
MoE 门控收敛；SONA 适应延迟实测 0.0043 ms（目标 <0.05 ms，达标）。

这条闭环的关键设计是：它不需要 LLM 参与本地向量检索与对比更新。README 的脚注写得很谨慎——「本地向量检索与对比更新可以不用 LLM；但嵌入与配置好的学习模块仍然是必需的」。换句话说，学习发生在向量空间和置信度账本里，而不是在权重里。代价是：它学到的是「哪条路走通过」的统计偏好，不是新能力。

4.5 核心机制三：HNSW 记忆与量化——被自己修正的数字

记忆层是 AgentDB + HNSW 索引 + 量化。这里有一组必须成对引用的数字：

能力	宣传口径	审计实测	结论
HNSW 检索加速	150×–12,500×	峰值 1.48×（N=20k）；N<5k 时比暴力检索更慢	夸大
Flash Attention	2.49×–7.47×	源码为 `2.49 + Math.random() * 4.98`	运行时伪造
benchmark recall	0.99	硬编码常量 0.99	未测量
Int8 量化	~4×	3.918×（1536→392 字节），重建余弦 0.99999	真实
RaBitQ 内存压缩	32×	32×（`compressionRatio=32`，真实 WASM 构建 1-bit 索引）	真实

修复后的真实数字是：N=5k 时 3.2×–4.7×，N=20k 时 1.89×，recall@10 ≈ 0.99。根因是「静默暴力回退」——没有 storagePath 时原生 DB 加锁、异常被 catch{} 吞掉，于是 benchmark 跑的是暴力检索却报成 HNSW。修复方式很朴素：唯一 storagePath + hnswConfig {m:32, efC:200} + 可见的回退警告。

2026-10-20 合入的 PR #4322 又往前走了一步：接上真正的原生 agentdb.HNSWIndex（而非 getController('hnsw')），并给出有界基准——同一 1024×64 维语料、100 条查询、k=10：recall@10 两者都是 1.000，warm p50 从 0.433 ms 降到 0.104 ms，但首次检索含建索引从 3.671 ms 涨到 97.916 ms。PR 自己标注了三条边界：这不是持久化修复、原生分配大小未暴露、stats 里的 memoryUsage 为 0 不代表实测占用。这种把「快了 4 倍，但冷启动慢了 27 倍」写在同一段里的做法，才是可用的工程信息。

4.6 核心机制四：联邦——跨机协作的零信任设计

联邦（Federation）让不同机器、不同组织、不同云区域的 agent 互相发现并交换工作。它的安全模型是完整的：

身份：mTLS + ed25519 挑战应答，不用 API key、不共享密钥；
数据：14 类 PII 检测管道扫描每条出站消息，按信任级别决定 BLOCK / REDACT / HASH / PASS；
信任分：0.4×success + 0.2×uptime + 0.2×threat + 0.2×integrity，升级需要历史，降级立即生效；
预算熔断：federation_send 支持 budget / maxHops / hopCount，默认 maxHops: 8，用于掐断递归委派循环。

但必须标注：第三方独立评估明确写「我们没有找到任何生产环境联邦部署的独立报告，请把它当作实验」。

4.7 性能优化手段与设计取舍

Rust/WASM 内核：策略引擎、嵌入、证明系统从 Node/TypeScript 迁到编译后的 Rust WASM。这是 v3.5 改名时的架构赌注，代价是构建链复杂度上升。
AES-256-GCM 静态加密：通过 CLAUDE_FLOW_ENCRYPT_AT_REST=1 opt-in，默认关闭以保住 1865 项测试基线；覆盖 sessions/、terminals/、.swarm/memory.db。
量化分档：Int8 约 4× 内存节省（实测 3.918×）、RaBitQ 32×，按数据集规模选档。
安全加固（audit_1776853149979）：关闭 github-safe.js、statusline、github-tools 的命令注入；在 terminal_create 边界拒绝 LD_PRELOAD / NODE_OPTIONS / DYLD_* 加载器劫持；会话/终端/记忆存储强制 0600；MCP stdin 加 10 MB DoS 上限。
取舍的代价：发布节奏极快（2026-10-21 一天 11 个 Release），意味着版本钉扎和自有回归测试是使用前提，而不是可选项。

4.8 与其他架构路线的差异

路线	代表	编排位置	相对 Ruflo 的取舍
单 agent + 好提示	「just talk to it」派	无	成本最低；复杂长程任务会散架
图式工作流	LangGraph	代码内显式图	冷启动 534 ms、可预测性强；但拓扑写死在代码里
对话式多 agent	AutoGen	会话编排	冷启动 185 ms；偏研究范式
角色式多 agent	CrewAI	角色定义	冷启动 2527 ms、RSS 265.7 MB；上手最快
元框架（harness）	Ruflo	挂在编码智能体外侧	冷启动 3.93 ms、RSS 61.6 MB；但能力面巨大、口径混乱、争议多

一句话：LangGraph 把编排写进你的代码，Ruflo 把编排写进你的编码智能体的外部环境——前者可控，后者可复用但更难审计。

五、【重点】应用场景

场景一：把单人编码助手升级成「有记忆的长期队友」

业务痛点。 Claude Code 的记忆是会话级的。今天调通的认证重构方案，下周换个会话就要重新推导一遍；同一个坑，团队里三个人各踩一次。

做法。 装 CLI 路径（不是插件路径），让 hooks 在后台自动检索与写入记忆。

npx ruflo@latest init wizard     # 写入 CLAUDE.md + 注册 MCP + 初始化 .claude-flow/
# 之后正常用 Claude Code 即可，hooks 自动路由与检索
npx ruflo memory search --query "auth patterns"
npx ruflo memory export --path ./memory-dump     # v3.59.6 起支持
npx ruflo doctor --fix                            # 安装出问题时的诊断

收益与量化指标。 记忆桥（import_claude / bridge_status / search_unified）经审计确认为真实可用：实测导入 14 条、3 个项目，结果带 source:"claude-code" 归因，持久化到 .swarm/memory.db。Int8 量化把 1536 维向量从 3072 字节压到 392 字节（3.918×），重建余弦相似度 0.99999。

适用边界。 ①不要指望它省 token——独立审计指出 Ruflo 实际每会话增加约 15,000–25,000 token 开销，所谓「减少 30–50% token」是伪造的（this.stats.totalTokensSaved += 100 硬编码）。②小数据集（<5k 向量）下 HNSW 比暴力检索更慢，别为小项目开索引。

场景二：用蜂群做多文件重构与端到端特性开发

业务痛点。 「改 12 个文件、跑通测试、开 PR」这类任务，单 agent 容易在中途丢失全局视图；人工拆解又很费时间。

做法。 用反漂移默认值起一个 6–8 人的层级蜂群，每个 agent 在自己的 git worktree 里干活。

npx ruflo swarm init --topology hierarchical --max-agents 8 --strategy specialized
npx ruflo swarm status
npx ruflo agent spawn -t coder --name api-worker
npx ruflo swarm monitor

收益与量化指标。 官方 v3.8.0 的 SOTA 矩阵（vs LangGraph 1.2.1、AutoGen 0.4.9、CrewAI 0.80.0，darwin-arm64 + linux-x64）测的是编排开销本身，不是任务完成率：

维度	ruflo	AutoGen	LangGraph	CrewAI
冷启动	3.93 ms	185 ms	534 ms	2,527 ms
单轮派发	0.012 ms	6.13 ms	37.1 ms	proxy†
N=10 并行	1.27 ms	61 ms	393 ms	proxy†
RSS 峰值	61.6 MB	78.7 MB	80.3 MB	265.7 MB

† CrewAI 派发需真实 LLM，用代理测量。关键限制：这个 benchmark 用假 LLM stub（固定约 0 ms 延迟），只隔离编排框架自身开销——它证明 Ruflo 的编排层很轻，完全不证明它更会写代码。

适用边界。 ①任务完成率 Ruflo 至今没有公布。ADR-163 明确写：「Ruflo 未公布任何端到端多智能体任务完成率、单任务成本或吞吐/美元指标，这造成了营销可信度缺口」；参照系是 LangGraph 62%、AutoGen 58%、CrewAI 54%（独立 2026 基准，2000 次运行）。②首次 artifact 的 72.2% 通过率是 mock 数字，明确标注不可发布。

场景三：给智能体装上安全边界与合规审计

业务痛点。 让 agent 自主跑 shell、跑 npm install、改文件，风险面很大；合规团队要的是可审计的证据链。

做法。 用 AIDefence + 静态加密 + 可验证安装。

npx ruflo security scan                    # CVE 检查、依赖审计
export CLAUDE_FLOW_ENCRYPT_AT_REST=1       # opt-in 开启 AES-256-GCM 静态加密
npx ruflo verify                           # 密码学验证已安装字节与签名 witness 一致
npx ruflo metaharness                      # 给 agent 配置打分（1-100）+ 扫描工具配置风险

收益与量化指标。 加固项是可核对的：命令注入在四处关闭；LD_PRELOAD/NODE_OPTIONS/DYLD_* 在 terminal_create 边界被拒；存储文件强制 0600；MCP stdin 加 10 MB 上限。加密模块有 76 项专门测试（vault 原语、集成、篡改检测、迁移路径）。

适用边界。 ①静态加密默认关闭，不开就没有。②ruflo-mods 插件以你的账户权限运行且未沙箱化，README 原文要求「先读代码再装」。③ruflo verify 证明的是「字节与 witness 一致」，不是「代码没有漏洞」。

场景四：跨团队协作而不共享原始数据

业务痛点。 两个团队想共享风控信号，但客户数据不能出域。

做法。 用联邦：PII 在出站前被剥离，身份用 mTLS + ed25519 证明。

npx ruflo federation init
npx ruflo federation join wss://team-b.example.com:8443
npx ruflo federation send --to team-b --type task-request \
  --message "Analyze transaction patterns for account anomalies"
npx ruflo federation status

收益与量化指标。 14 类 PII 检测管道 + 四档策略（BLOCK/REDACT/HASH/PASS）+ 行为信任分公式 + 默认 maxHops: 8 的预算熔断；federation 插件有 366/366 测试通过。

适用边界。 这是实验性能力。 第三方独立评估的结论是「未找到任何生产环境联邦部署的独立报告，请当作实验」。另外联邦的信任分是自评公式，不是第三方验证。

场景五：用 GOAP 把「一句话目标」拆成可执行计划

业务痛点。 「把认证重构上线，带测试和 PR」这种目标，交给 agent 容易变成无边界的长循环。

做法。 用 ruflo-goals 插件（GOAP 规划）把目标分解成前置条件、动作和 A* 路径。

/plugin marketplace add ruvnet/ruflo
/plugin install ruflo-goals@ruflo
# 或直接访问托管演示 goal.ruv.io，源码在 v3/goal_ui/（Vite + Supabase，可自托管）

收益与量化指标。 计划树可视化、失败时从当前状态重跑 A* 而非重启、计划与轨迹回流到 AgentDB 供后续 HNSW 检索。

适用边界。 托管演示（goal.ruv.io、flo.ruv.io）无需 API key 即可试用，但演示环境不等于生产可用性证据。README 自己反复强调这一点——例如「创建一个 mission 不代表特性已经实现」。

六、快速上手

# 路径 A：CLI 全量安装（推荐用于生产）
npx ruflo@latest init wizard        # 交互式，全平台一致
# 或非交互：npx ruflo@latest init
npm install -g ruflo@latest         # 全局安装

# 路径 B：Claude Code 插件（轻量，只加斜杠命令）
/plugin marketplace add ruvnet/ruflo
/plugin install ruflo-core@ruflo
/plugin install ruflo-swarm@ruflo

# MCP server
claude mcp add ruflo -- npx ruflo@latest mcp start

# 终端 UI（可脱离 Claude Code 单独跑）
npx ruflo tui                       # v3.59.1 起鼠标点击默认开启

两条路径的关键差异（README #1744 原文）：插件路径不往你的工作区写任何文件、不装 hooks、只有 ruflo-core 注册 MCP server；CLI 路径会写 .claude/、.claude-flow/、CLAUDE.md 和 helpers，装 hooks，注册 MCP。生产用 CLI，试用插件。

七、横向对比

维度	Ruflo	LangGraph	AutoGen	CrewAI
定位	编码智能体的元框架（harness）	图式 agent 编排库	对话式多 agent	角色式多 agent
语言 / 许可	TypeScript / MIT	Python / MIT	Python / MIT	Python / MIT
冷启动（官方矩阵）	3.93 ms	534 ms	185 ms	2,527 ms
RSS 峰值	61.6 MB	80.3 MB	78.7 MB	265.7 MB
任务完成率	未公布	62%	58%	54%
单任务成本	未公布	$0.08	~$0.10	~$0.12
拓扑 / 共识	6 拓扑 + 5 共识	图（显式）	会话	1 种
MCP 集成	原生（323 工具）	无	无	无
持久记忆	SQLite + AgentDB + HNSW + 量化	需自建	需自建	有限
独立采用证据	弱（HN 3 分 vs 7.8 万星）	强	强	强

读这张表的方式：Ruflo 在「编排开销」这一列是压倒性的，在「任务完成率」这一列是空白。前者是它自己测的，后者是它没测的。 竞品的完成率数字来自同一个独立基准（2000 次运行），可以直接横比；Ruflo 的 3.93 ms 来自假 LLM stub 的自建 harness，只能证明编排层轻。

八、局限、风险与社区观察

第一，可信度问题是这个项目最大的风险，且它自己承认了。 三份文档构成完整证据链：① 2026-03 安全审计（#1375）——用户报告 v3.1.0-alpha.55 到 v3.5.2 携带混淆的 preinstall 脚本，会删除 ~/.npm/_npx/ 下的目录和提及 claude-flow/ruflo 的缓存索引文件且抑制错误；SQL 注入报告（#1030）自 1 月挂到 3 月；npx 在「安全执行器」白名单上；没有卸载路径（#373/#670/#710）。维护者两天内回复并发 v3.5.40：参数化查询、移除 preinstall、npx 移出白名单、加 SECURITY.md、加 ruflo cleanup。② 2026-04 独立审计（roman-rr，测 v3.5.51）——agent_spawn 只写一条内存记录然后永远 idle、WASM agent 只是 echo、verifySignature() 无条件返回 true、「hive-mind」实为带 --dangerously-skip-permissions 的 Claude Code 加一段长提示词。③ 2026-05 项目自审——见 4.5 节。

第二，口径混乱到无法用来做容量规划。 同一个 README 里，能力面被数了五种：仓库描述说「100+ agents」、快速上手表说「98 agents / 60+ commands / 30 skills」、新手提示说「你不需要学 314 个 MCP 工具或 26 个 CLI 命令」、STATUS.md 说「323 MCP 工具 / 45 CLI 命令」。60+ 对 26 这个落差最尖锐——两个都是命令数，必有一个排除了另一个包含的东西却没说。 第三方评估的建议很实用：插件数取目录枚举值（可数），其余数字忽略。

第三，发布节奏是双刃剑。 2026-10-21 一天 11 个 Release；v3.38.5 到 v3.38.9 在两天内发完。近期修复本身就说明问题：v3.38.8 修的是「provider/model 配置被保存但在执行时被忽略」——命令看起来成功，实际静默用了别的 provider；v3.38.7 修的是「记忆状态函数返回 available: true 和硬编码的 sql.js + HNSW，即使实际走的是暴力余弦检索」；v3.46.0 的标题自己写着「29 项已审查修复，以及静默跳过它们的独立包」。结论：版本钉扎 + 自有回归测试不是可选项。

第四，署名争议（#2078）。 系统级 git commit 指令里硬编码了 Co-Authored-By: claude-flow <ruv@ruv.net>，会附加到每一次通过 Ruflo 提交的 commit 上——等于在用户所有仓库里把作者加为贡献者。维护者已把 ruflo init 的该行为改为 opt-in（#1670），但承认 agent runtime 的内置 commit 指令里仍有硬编码，项目设置改不掉。

第五，星数不等于采用。 78,194 星是继承来的（claude-flow 301 跳转 + badge 仍指旧 URL）；npm 周下载 36,034 是真实的第三方测量，但对比 7.8 万星明显偏低；README 里的「8.1M+ 生态下载」「14 天 106k git clones」badge 指向仓库内自提交的 JSON 证明文件——自测量，不是第三方测量。

第六，开放 Issue 973 个，对一个个人维护、单日发 11 版的项目来说，支持负载已经明显超过维护能力。

九、小结与行动建议

Ruflo 是这个赛道里最有信息量的样本，但不是因为它最强，而是因为它把「智能体编排工具的真实水位」完整暴露了出来：编排开销可以做到毫秒级，学习闭环可以是真的，记忆检索可以是真索引，但任务完成率没人测、性能倍率会造假、能力面口径会失控、采用量会被继承。

五条建议：

先读 docs/STATUS.md 和 docs/reviews/intelligence-system-audit-2026-05-29.md，再决定装不装。 前者告诉你「现在真正能用什么」，后者告诉你「哪些宣传数字是假的」。这两份文档的价值超过 README 全部内容。
用 CLI 路径，不用插件路径。 插件路径不装 hooks、不注册完整 MCP、工具名还不通用；针对裸名写的脚本在插件安装下会静默失效。
钉版本 + 自建回归测试。 单日 11 个 Release、provider 静默切换、记忆状态谎报——这三件事叠加意味着「跟随 latest」是高风险策略。
从「1–2 个 agent + 记忆」开始，不要一上来开蜂群。 反漂移默认值（hierarchical / 6–8 agents / specialized / raft）是作者踩坑后的结论，但多智能体的 token 成本约 15 倍是行业事实。
引用它的数字时必须带出处与限定。 3.93 ms 冷启动是「假 LLM stub 下的编排开销」；1.9× HNSW 是「N=20k、修复后的实测」；62%/58%/54% 是竞品的完成率，不是 Ruflo 的。

最后一个判断：2026 年「模型 + Harness」的竞争已经进入下半场，而 Ruflo 示范了一件事——在这个赛道里，一个项目可以同时是能力天花板和可信度洼地。它值得读，值得拆，但在它公布端到端任务完成率之前，不建议把它放进任何生产链路的关键路径。

资料来源（均抓取于 2026-10-21）：GitHub Trending daily/weekly 榜单与 GitHub REST API（ruvnet/ruflo）；仓库 README.md（34.5 KB）、docs/STATUS.md、docs/USERGUIDE.md、docs/benchmarks/sota-workload-spec.md、docs/agentdb/PRODUCTION_READINESS.md、verification.md、docs/reviews/intelligence-system-audit-2026-05-29.md、plugins/ruflo-swarm/README.md、plugins/ruflo-rag-memory/README.md、ADR-096 / ADR-097 / ADR-163 / ADR-335；Releases API（v3.58.0–v3.59.12）；PR #4322（真实 AgentDB HNSW 接入与有界基准）；issue #1375（安全审计）、#659（alpha 定位）、#2078（Co-Authored-By 署名）、#3562（MessageBus 轮询）、#2428（完成率缺口）；npm registry（ruflo 周下载 36,034）。第三方独立评估：tomrochette.com 的 ruflo 条目、andrew.ooo 的 Ruflo Review、hysenlabs.com 的项目页、roman-rr 的 gist（经 awesome-claude-code issue #1338 转述）、DEV Community 的改名分析。厂商自测数据已标注来源与样本量；被项目自身审计推翻的宣传数字已并列展示；未能独立核实的信息已标注「未公布」「实验」或「第三方测量」。